Intelligent Grid Architecture ? Putting the Pieces Together

As the operating scenarios of the above application domains are fleshed out, it soon becomes apparent that there are opportunities and needs for cross-application communication. For example, the WAMACS function detects a system instability and determines that it needs to shed load in the sub-second time frame. It is clear that there needs to be a communication interface between the WAMACS applications and the Smart Home and Microgrid environments. In order to achieve this cross-domain communication, an architecture is needed to define the parts of the system as well as to define how they interact.

The architecture process defines a set of plausible scenarios (Enterprise Activities) spanning the entire energy enterprise (utility, industrial, commercial and residential). The scenarios then enable analysis on the data and resulting communication requirements needed to construct a complete, high-level set of functions for the communications infrastructure to enable the envisioned functionality. The requirements can be categorized as:

• Communication configuration requirements, such as one-to-many, mobile, WAN, and LAN
• Quality of service and performance requirements, such as availability, response timing, and data accuracy
• Security requirements, such as authentication, access control, data integrity, confidentiality, and non-repudiation
• Data management requirements, such as large databases, many databases across organizational boundaries, and frequent updates
• Constraints and concerns related to technologies, such as media bandwidth, address space, system compute constraints, and legacy interface
• Network management requirements, such as health and diagnostics of infrastructure and equipment, remote configuration, monitoring, and control

Putting together the pieces, there are several guiding principles that show the way to an architecture. According to the IntelliGrid Architecture Report cited earlier, an architecture should be technology independent, based on standard common services, a common information model, and generic interfaces to connect it together. Figure 5 is a conceptual view of such an architecture. While adapters can accommodate the above heterogeneity, to achieve interoperability using off the shelf components, we need standards for what data is exchanged and how data is exchanged. Furthermore, these standard information models and interfaces must be applicable to a variety of utility services. A standardized common information model solves what is exchanged. A standardized set of abstract interfaces solves how data is exchanged. A single technology for every environment will never be agreed upon so adapters will still be required to convert between different technologies.

It should be noted that the IEC 61850 communication protocol, "Communication Networks and Systems for Utility Automation," meets these requirements today. This protocol defines internationally standardized models for protection, control, metering, monitoring, and a wide range of other utility objects.

In addition, it defines a standard set of abstract services to read and write to these models. Most importantly, it provides a mechanism for self-description of the data models to any requesting client. This feature becomes of paramount importance for auto configuration as the number of devices in a domain becomes large, for example, millions of electric meters.