Technologies for uniting the enterprise
This approach can obviously significantly reduce the amount of code which needs to be
written to interface multiple interfaces. However, the integration bus middleware also
generally adds a number of additional features which have significant benefits.
One of the major advantages relates to resynchronization after recovering one system
from an old backup. The bus assigns a sequence number to each event and can store all
events in its own backup or log. Each database will store the number of the last event it
processed as part of each transaction. So when a system is recovered from a backup, it
can ask the bus for all events which have occurred since the last event it processed, to
bring it back up to date.
A similar approach can be used to enable the integration bus to handle disconnected
systems, such as mobile data terminals which are used by field crews. When one of these
systems is connected to the network, it can ask the bus for any events of interest which
have occurred since it was last synchronized (for example facility updates). The mobile
system could also publish events itself, based on any updates which were done in the
field.
Another very useful feature which is offered by some integration bus products is the
ability to manage multiple "channels" and copy or move events between them. This can
be very useful for testing and simulation. For example, suppose a new outage
management system was being implemented and its primary inputs were events generated
by the Customer Information System (CIS) and the SCADA system. A new test channel
could be set up so that all real events generated by CIS and SCADA were copied to that
and could be read by the outage system, but any additional events generated on that
channel would not be seen by the production systems. In addition, a separate channel
might be used to play back trouble call events from a recent storm into a test system, for
training or performance testing purposes. It is very difficult to manage these sort of
scenarios easily with traditional point to point interfaces.
While the examples used so far have focused on integration between major business
systems within a company, some EAI products can also work across the Internet. This
allows the same basic approach to be used for e-commerce between companies.
The idea of an integration bus becomes even more useful if providers of commercial
applications conform to standards for the content of events which should be written to or
read from the bus. The next two sections discuss XML, which is rapidly becoming the
standard of choice for encoding this type of message, and IEC Working Group 14, which
is working on defining utility-specific standards for the content of these messages.
XML
XML (eXtensible Markup Language) is a format which allows structured data to be
stored in a text file. It has rapidly become accepted as the format of choice for
exchanging structured data on the Internet, and is also becoming popular in the EAI
arena. The big reason for the success of XML is that it combines simplicity with great
flexibility. Its simplicity makes it very easy for software to read and write XML files -
and many standard tools are available to help with this. Its flexibility means that it can be
easily used to handle more or less any type of data. XML files are self-describing, which
is another important aspect of the extensibility of the format.
For more information on XML see the references below.
Working group 14
Working group 14 is a standards committee run by the IEC (International Electrotechnical
Commission) Technical Committee 57 (TC57) which is working on an international
standard, referred to as IEC 61968-1. This standard is focused on integration of major
utility applications relating to distribution management, and it is based on an integration
bus approach like the one explained earlier in this paper.
The diagram above gives an overview of the areas covered by WG14. The standard aims
to cover both information exchange between applications - the "events" which should be
published to the bus - and also a Common Information Model (CIM). The CIM is
intended to be an abstract model that represents all the major objects in an electric utility
enterprise. The CIM was originally developed by the EPRI CCAPI project and submitted
to TC57 Working Group 13, which is focused on Energy Management Systems (EMS).
The model is now being extended by WG14 so that it will cover generation, transmission
and distribution. The work of WG14 is being closely coordinated with other relevant
standards initiatives. This includes initiatives focused on utilities, such as WG13 and the
Electric Power Research Institute (EPRI) Control Center Application Program Interface
(CCAPI) Project, and also initiatives with a more general focus, such as the Open
Applications Group (OAG) and the Object Management Group (OMG).
The standard being developed by WG14 will greatly reduce integration cost and effort for
systems which conform, and will make it much easier to switch out one system and
replace it with another.
