UCA 2.0™ for Dummies Part II of II

The Utility Communications Architecture 2.0 (UCA 2.0à¢â€ž-) offers simple and powerful substation intelligent electronic device (IED) integration through logic and communication capabilities. The first article in this series discussed the logic, speed and auto-negotiating communications capabilities of microprocessor-based IEDs. This article discusses UCA 2.0’s networking advantages, including application-level independence and Internet-enabled wide-area communications. When discussing communications networks, it helps to use a standard networking model to break up the functions. This networking model is described and particular aspects of UCA 2.0, which are included in certain sections of the model, are discussed.

The OSI Networking Model

Data transmission within UCA 2.0 is based on the Open Systems Interconnection (OSI) 7-Layer Model, which is a general model for how networks function. It can be used to describe many types of networking schemes, including TCP/IP, Microsoft, Novell, DNP, etc. The model was developed by the International Organization for Standardization (ISO). In addition to the model itself, the ISO developed a complete set of functional protocols for each layer of the model. This protocol stack is sometimes referred to as an OSI protocol stack even though it is probably more accurate to refer to it as an ISO protocol stack. The OSI model can be used to describe virtually all networking schemes while the OSI stack (or ISO protocol stack) usually refers to the specific protocols specified by the ISO. This can be a confusing point, but since this article will refer to both the model and the stack, it is important to know the difference.


The OSI Networking model with all seven layers and their profiles.
Click here to enlarge image

The model breaks down the functions of a network into seven layers: application, presentation, session, transport, network, data link and physical (Figure 1).

Data enters the stack at the application level. In UCA 2.0, CASM and GOMSFE (see previous article) define this data. This means that although MMS is UCA 2.0’s current implementation standard, any appropriate protocol could operate in the application layer, maintaining UCA 2.0’s protocol independence.

Data continues down through all seven layers of the stack, with each layer adding a “shell” of information to be interpreted by the device or devices on the receiving end. These shells provide addressing data for navigating the network’s physical wires and the receiving devices’ logical systems. On the receiving end, the data makes its way up all seven layers. Each shell provides direction and other functions within each layer, until the data reaches the application layer, where the information is used.

The specific functions of each layer are beyond the scope of this article. Instead, they will be discussed in terms of larger functional blocks called profiles.

A-Profiles

A-profiles include the application, presentation and session layers. These layers decide how the information is to be packaged and the form in which it will be sent. Corresponding layers within the devices’ logical systems on the receiving end will recognize the shells added to data in the A-profiles. The shells will also direct the data to the correct application layer.

T-Profiles

T-profiles are the transport and network layers. The transport layer is responsible for ensuring reliable message transfer across the network. The network layer is responsible for providing addressing and routing functions to allow multiple network segments to be interconnected into a larger network. Overall, these layers give directions for data within the network, in contrast to the A-profiles, which provide direction for data within a single device.

L-Profiles

L-profiles are the data link and physical layers of the stack. The data link layer is responsible for controlling access to the network media. The physical layer specifies the system’s wire, voltages, connectors and other physical attributes. With this model in mind, some key features of UCA 2.0 can be better understood.

Application-Level Independence

Because the Application level is independent from the rest of the stack, the data dealt with in this layer doesn’t have to be concerned with any network or security function. There are several benefits to this:

“- Security. Currently, UCA 2.0 is implemented with MMS in the application layer. The security features of MMS are quite formidable. This means the network itself doesn’t have to be secure, since the application layer contains the security. This is like sending a coded message by regular U.S. mail, radio or any non-secure transmission method. Therefore, UCA 2.0 can utilize the Internet’s non-secure wide-area infrastructure without compromising the information’s security.

“- Ease of Implementing New Services. UCA 2.0-compliant IEDs can be connected via any type of physical network, and their dialogues with one another will be identical because the layer in which they interoperate (application) is not affected by any of the underlying protocols. This makes it easier to integrate new systems and modify existing ones.


Data in the application layer is always presented in CASM/GOMSFE-defined MMS terms regardless of how data is transmitted.
Click here to enlarge image

It should be noted that the services defined by CASM and GOMSFE will always lag behind the innovations that manufacturers build into their UCA 2.0-compliant products. The goal of true interoperability will conflict with the goal of product differentiation. If a user or application wants to use these specialized services available in a “server”(IED), then the “client”(SCADA system, another IED, etc.) must be told it is there and how to ask for it. This also occurs with protocols such as Modbus, DNP, etc. The advantage of UCA 2.0 in this case is that the application language will still be MMS (Figure 2). Although a user has to provide instruction on how to use the new services, the user does not have to translate the new instructions into devices’ multiple protocols, since they are all using MMS. Application level protocol translation is usually the hardest, most time-consuming aspect of integration, and UCA 2.0 avoids it by providing a common language to all devices.

Self-description helps solve this problem as well. For example, a UCA 2.0-compliant IED may offer event files in COMTRADE or another format not currently standardized by UCA 2.0. The object containing this file will respond to MMS’s generic “read” command with instructions on how to transmit the information. A user never learns another version of “read” to execute the service, since the object itself tells the client how to handle the information.

Networking Protocols

The T-profiles contain the TCP/IP and OSI stack protocols associated with networking in UCA 2.0. The following description of TCP/IP and the OSI stack are meant as generalizations of function. Both protocols can be implemented in ways other than those described below. This description serves as an example of the difference between local-area network (LAN) and wide-area network (WAN) protocols.

TCP/IP


TCP/IP breaks data into smaller pieces that are easier to transmit over the wide area and re-assembles them on the receiving end.
Click here to enlarge image

Most people are probably more familiar with TCP/IP than OSI because TCP/IP is used by commercial Internet browsers such as Netscape Navigator and Internet Explorer. Historically, TCP/IP is optimized for transporting streams of data from point A to point B, or application to application. It may break up a large piece of data into smaller pieces that can travel across wide areas more easily, and then be re-assembled on the receiving end (Figure 3).

TCP/IP streams may have built-in timers that detect the data stream’s end. Therefore, TCP/IP may sit idle for a short period while waiting to see if more data will show up. These time lags are evident when downloading a Web page to a desktop browser. Such pauses are unacceptable for time-critical functions within a substation.

Due to the prevalence of the Internet, the routers and gateways that exist on WANs are more commonly set up to deal with TCP/IP rather than OSI. For this reason, and for the timing issues on the local area, TCP/IP is an ideal protocol for WANs.

OSI Stack

OSI stack protocols are oriented more toward packets than streams. These packets have a clear beginning and end signal. If a client receives an incomplete packet, it is simply discarded and a new one is requested. The client will not sit idle, waiting for the rest of the information to appear. Due to this and its relative prevalence to TCP/IP in wide-are gateways, OSI is better suited for high-speed communication on the LAN.

Ethernet

While UCA 2.0 does not specify any particular physical medium for the L-profiles, the substation LAN demonstrations sponsored by EPRI and AEP do specify the use of 10/100Mbps Ethernet. When UCA was still in the theoretical phase, AEP led a movement to produce practical results and standards that would prove the viability of UCA to electric utilities. Using a series of theoretical models of several worst-case scenarios in the substation, 10Mbps on a switched hub (or 100Mbps Ethernet on a shared hub) emerged as the most suitable medium for UCA 2.0. AEP and EPRI have sponsored a series of meetings where vendors of UCA 2.0-compliant devices have all interoperated on an Ethernet LAN. The number of vendors, devices and the services they perform increase with each meeting. For more information on these meetings, visit ftp.sisconet.com/epri/subdemo.

No Certifying Body

With all the flexibility afforded by UCA 2.0, such as multiple protocols and new services, certification is still an issue. A Modbus Plus product, for instance, has been certified by Schneider Automation to communicate with any other device that is Modbus Plus certified. UCA currently has no formal certifying body to test devices that bear the tag “UCA 2.0-Compliant.” However, UCA 2.0 does have two aspects that serve the same purpose. First, the protocols used within UCA are usually international standards, not vendor-specific protocols. They are well established, and they benefit from economies of scale and a common knowledge base; proprietary, vendor-specific platforms do not. Second, the self-describing services of UCA 2.0-compliant devices simplify communication between the devices.

UCA 2.0-compliant does not mean interchangeable, but it does mean interoperable. One vendor’s UCA 2.0-complaint device cannot be pulled out of the wall and another vendor’s device installed without modifying the network. However, because the application language and terminology are constant, modification is a far easier task than with register-based protocols. Also, since the devices interoperate in the application level, little or no physical wiring is required for such a change.

Summary

In the coming years, several forces will push for communication standardization within the electric utilities. The costs of integration, redundant equipment for different departments and communications media developed specifically for the utilities will have to be reduced for utilities to remain competitive. Resources that can help solve these problems are available from the computer industry. Ethernet communications and object-oriented design methods can save money and add functionality to LANs and WANs. UCA 2.0 seeks to make these benefits available as soon as possible.

Conrad Oakley is a freelance technical writer retained by Bitronics Inc., a manufacturer of high-speed UCA 2.0-Compliant IEDs and other measurement solutions (www. bitronics.com). This series was based on the document “UCA 2.0- The Basics” available on the Bitronics Website. UCA 2.0 is a registered trademark of EPRI.

Previous articlePOWERGRID_INTERNATIONAL Volume 5 Issue 3
Next articlePOWERGRID_INTERNATIONAL Volume 5 Issue 4

No posts to display