©DIGITAL VISION, LTD.
application, power application necessitates a high level
eregulation of the energy industry has resulted in
D the emergence of software that coordinates the
functions in power systems. The complexity of
these vertically split power systems demand stringent
requirements from the employed software. As the mar-
ket rules change, the regulating policies stated by FERC
will need incorporation into the software. By using the
latest technology and applying software management
practices during development, the measurable results
include better designs of the software coupled with high
quality and performance. A variety of commercially
available tools can be used to improve the software
development process. Software modeling and configura-
tion management encompasses two key areas in the
development life cycle.
This article presents an overview of software model-
ing and configuration management as applied to soft-
ware development in deregulated energy markets. It
outlines the requirements for software quality, various
tool features, and challenges ahead in the development
of software for deregulated energy markets.
Software Quality in Power Applications
The quality of the software should meet or exceed the
customer’s expectations and be easily adaptable to
changes. The quality of the software is often related to
the quantity of defects. Fewer defects mean higher quali-
ty. However, software quality is also an integral part of
the full product development cycle that spans require-
ment definition to product release. To develop quality
software, suitable tools to control the development
process must be employed. As in any critical control
H.S. Gill, V. Filipovic-Gledja, and H.P. Mukherjee are with ABB Energy
Information Systems, Santa Clara, California, USA. T.S. Sidhu and L. Cui
are with the University of Saskatchewan, Saskatoon, Saskatchewan,
Canada.
ISSN 0895-0156/01/$10.00©2001 IEEE
of quality. Design discrepancies in a power software
application can result in low reliability of the energy sup-
plied to end-users. This causes monetary and other
kinds of losses to the suppliers as well as the users. The
complexity of power software owes its nature to applica-
tion usage and changing market rules in the deregulated
energy markets. Power system software for present-day
markets should be developed with desired capabilities
and maintenance features in mind. This can be accom-
plished by using a suitable tool for software modeling
and configuration management. Tool selection is deter-
mined by a combination of factors that includes, but is
not limited to, architecture, version control capabilities,
change control management, process management,
reporting, and economics.
Software Development Environments
With the advent of digital technology, the considerable
cost reduction of computer hardware has allowed soft-
ware engineers the opportunity to be provided with
automated tools to support the development process.
Today’s software engineering environments are integrat-
ed around software management systems that offer sup-
port for all software process activities. All products of
the software process can be placed under configuration
management using the appropriate configuration tools.
Software designs can be visualized best using commer-
cially available modeling tools. The use of such software
tools results in quality enhancement of the software sys-
tem and its maintenance. Various software development
environments can be classified as multiuser, cross-plat-
form, and multiproject.
Multiuser Environment
It is common in today’s software development process
October 2001 33
 have specific requirements (rules, policies, etc.) that
Project A Project B
must be implemented in the software. As such, suitable
1 3 development environments for parallel projects has
5 become inevitable. To keep track of required software
2 4 data and program files, companies using parallel pro-
jects that are engaged in the development process need
sufficient tool support. Moreover, part of the develop-
ment activities may be common to these parallel pro-
Figure 1. Parallel projects environment
jects. To avoid duplication of effort, merging the work
among these projects is a desirable feature. This envi-
ronment can be visualized as depicted in Figure 1.
Two projects (A and B) share common files as repre-
app Applications
sented by the numbered triangles 3 and 4. These pro-
jects have other files that are used by each individual
project (files 1 and 2 for project A and file 5 for project
Architecture B). Project A team members have read-write access to
arc
files 1 and 2 but have read-only access to files 3 and 4
(common files). Similarly, project B team members have
read-write access to file 5 but have read-only access to
dbm Database Management the common files. The possibility exists for a team mem-
ber to have read-write access to one of the common files
and not the other. All such combinations may compli-
cate the parallel project development environment. In
gui Graphical User Interface
Figure 1, files are used to illustrate the environment. In
practice, these files may be replaced by components
that constitute a number of files. The project team mem-
bers may have read-write access to a particular compo-
req Software Requirements nent or part of the component and a read-only access to
other components or parts of a component. These fea-
tures make the development process extremely com-
plex. An assessment of all such permutations and
doc Documentation operating scenarios should be considered when design-
ing a power software system. To ensure product quality
in the development of power system software, software
Figure 2. Types of components
modeling and configuration management requires spe-
for a group of people to be working on the same software cial attention. The following sections describe the appli-
system. Each team member works on a module that is cation of tools used in the development process of
periodically integrated during the development process. power system software.
Being complex in functionality, the power system soft-
ware needs such an environment. The team members
Configuration Management
independently develop the software modules that repre- Due to the onset of deregulated markets and the com-
sent the functions of the software. These modules are plexity of the power system software, the application of
then integrated to build the final system. any configuration management tool requires a detailed
view of the associated data and program (source code,
Cross-Platform Environment object, executable) files. These files can be grouped into
Power system software is based on software packages components, based on their functionality, to aid configu-
that function on different operating systems. Coordina- ration management. Figure 2 shows an example of cate-
tion of these software packages on multiple operating gorizing these files into components. These components
systems, in turn, need middleware Many software com- include files related to specific functions as follows:
panies use this environment to carry out their efforts, ■ Applications: Bus scheduler and network builder,
which also facilitates development in accordance to the power flow module, ancillary services and conges-
preferences of development team involved. tion management, security analysis, etc.
■ Architecture: Database and middleware applica-
Multiproject Environment tions programming interface, event-logging mod-
Most power software companies are engaged in develop- ules, utility tools (porting software, process
ing software for different power pool areas. These areas scheduler), etc.

34 IEEE Computer Applications in Power

■ Database management: Database population and
data management, utility tools (database tuning,
app doc
schema modeling), etc.
■ Graphic User Interface: Interface source files and
library functions, information about configuration
and utility tools (modeling, memory leak), etc.
■ Software requirements: This includes software
requirement documents that keep track of the sys Data req
periodic changes occurring in the software. Storage
■ Documentation: Release notes, software variance
log, user manuals, help files, etc.
Each component is a storage unit in a configuration
management tool, as shown in Figure 3. The contents of
these components can be accessed using the load and dbm mmi
view features of the configuration management tool. Fur-
ther, these components will have unique substructure.
Figure 3. Data storage for configuration management
The subdirectories can be kept the same for uniformity
with the possibility of empty subdirectories. These sub-
structures can vary from one software to another. Figure The object-oriented
4 shows an example of one such component’s substruc- approach of software
ture as viewed using the features of the configuration modeling seems promis- app
management tool. The src, inc, and run directories repre- ing for designing software src
sent the collection of source code, include, and exe- systems for deregulated
cutable files, respectively. energy markets. Because
inc
Team members working on the power system soft- power systems comprise
ware project can load the components necessary to a large number of com-
carry out development efforts. The configuration man- ponents that operate in
agement tool tracks all changes made by team members. conjunction with the op-
As such, any version of a particular file can be retrieved eration of power systems
Figure 4. Substructure of a
and used by any member in the team. Suitable baseline carried out under defined
component
labels can be assigned to keep track of significant mile- system constraints, the
stones accomplished during development. software developed for this purpose must have the
capability to consider these requirements. Deregulation
Power System Software Modeling has further complicated the operation scenario due to
Modeling power system software helps the development the involvement of numerous entities (transmission ser-
teams comprehend, organize, and develop complex sys- vice providers, power suppliers, customers, etc.). Addi-
tems for the present as well as the future. As depicted in tionally, operation is conducted under the policies and
Figure 5, constructing models will help designers focus regulations set forth by electricity regulatory authorities.
on the project on a larger scale without having to get To outline the importance of software modeling, a sam-
into the specific details of individual elements. ple of a system for the deregulated energy markets is dis-
Different modeling approaches are possible for any
software system. The two most commonly used
approaches are algorithmic and object-oriented. The Software Modeling
algorithmic approach is based on procedures and func-
tions. Maintenance of software systems built using algo-
rithmic focus is very difficult. On the other hand, the Requirements Software
Comprehension Maintenance
object-oriented approach has proven to be immensely Design
useful in building systems involving all degrees of size Improvements
and complexity. These commercially available tools
model the software by defining the software components
and their attributes and establishing mutual interaction
among the components. This results in a set of scenarios
that provides a way to describe the system behavior. Quality Enhancement
The dynamic behavior of the individual components can
also be defined in terms of different states of compo-
nents and the transition between these states. Figure 5. Software modeling and software quality

October 2001 35
 • Public Market • State Estimator proper implementation. An approach
Information • Load Forcast to modeling this scheduling system
• Generation and • Historical Information
Load Schedule would be to visualize each portion of
• Ancillary Service Bids the system into smaller portions. Fig-
ure 7 shows the load forecast mod-
ule divided into submodules. The
load forecast module requires input
ISO User Interface
Power Management System
of weather data, actual load, and
user parameters. This module
includes the functionality to compare
Saved Generator the ISO load forecast with the aver-
Scheduling Cases Schedule Data age load forecast provided by the
(Previous System Scenario)
scheduling coordinators.
(Available Capacity)
User preferences are obtained, his-
(Facilitate Formulation torical load data is searched, and a
of Network Model) sample load curve is generated. Later,
Network Model Builder it compares the actual load from the
automatic generation control (AGC)
• Foward and Real-Time Markets subsystem and gives error estima-
• System Dispatch tions to the user about the load fore-
• Status of • Congestion Management
casts. To model this component, the
Circuit Breaker
• System
complexity of the system must be
Interconnections considered. Individual objects are
• Loss Factors defined as shown in Figure 8.
Full Network Model Various Scheduling Applications The figure shows the load forecast
module to be composed of a number
Figure 6. ISO scheduling system of components, each of which has

cussed in the following section.

Figure 6 shows a block diagram of the schedul-
ing system network of an independent system
operator (ISO).
A detailed network represents the transmis-
sion network for performing functions such as
congestion management, determining transmis- Weather Forecast and
sion congestion prices, forecasting transmission Actual Weather Data
loss responsibilities, and conducting transmis-
sion assessment. The network model builder is
able to construct the network model for use by
Load
various scheduling application functions. For Forecast
each network model, load and generation condi- User Settings Predicted Load
tions are specified, and any scheduled out-of-ser-
vice transmission equipment are mentioned. The
network model provides the capability to repre-
sent the network conditions over all 24-hour peri-
ods. Additionally, the network model reloads
previously stored saved cases and uses model
data from online (power management system
state estimator) models. Historical Load
From the description of the network model, it
is clear that this component of the scheduling Figure 7. Load forecast module of a network builder
system is very complex and involves diverse
functionality. Its realization in software needs extensive several attributes and operations. The exchange of infor-
design, hence, the need to model the power applications. mation among the components takes place in the opera-
It is obvious that modeling of the component will be tions. The interface provides abstraction for
useful in better understanding its requirements and implementing functions that can be provided by individ-

36 IEEE Computer Applications in Power

 To ensure product quality in the development of power system
software, software modeling and configuration
management require special attention

ual components. In Figure 8, the central load-forecaster
component has attributes such as location, day, hour,
error percentage, etc. Also, the operation forecast load
collects information from all other components such as
UserData, WeatherData, and HistoricalLoadData to gen-
erate the forecast load. The ForecastedLoadInterface
helps to create an abstraction for the load forecast com-
ponents for a 24-hour period. Similarly, all other compo-
nents used in the network model builder (Figure 7) can
be modeled.
Software modeling helps to understand the relation-
ship between the objects inside the parent module and
the components of other modules, where it sends or
receives information. The maintenance of the design
structure and its ongoing changes can be handled
effectively by this approach. Over time, this results in
higher productivity with enhanced software quality.
Challenges Ahead
With the evolving power mar-
ket scenarios and the emer-
gence of diverse software,
software quality is bound to
invite more attention than
ever before. This poses strong
challenges to companies who
nia market structure, combined with an imbalance of
supply and demand, has led to higher than usual whole-
sale prices.
In addition, FERC urged California regulators and
other policymakers to resolve issues that have placed
consumers at risk. This includes delays in citing new
generation and transmission capacity, and the imple-
mentation of additional retail demand response pro-
grams. Implementation of deregulation related rules and
policies would require changes to the existing software
systems. In the near future, software developed using
modeling and configuration techniques will be able to
easily adapt to the changing requirements.
Open Platforms
With the advancement of software technology, new soft-
ware packages have emerged on the horizon that are
compatible with multiple operating systems. The prolif-
eration of operating systems has necessitated that the
WeatherData
location
dryTemperature
illumination
humidity
rainfall
otherWeatherData

are involved in developing getWeatherData() ForcastedLoad

dataRefinement() hourNumber
deregulated energy system etcWeatherData() loadMW
peakLoad
software. peakHour
Information Collected on otherForecastedLoad
Hourly or Daily Basis
Changing Market Policies generatedForecast()
UserData etcForecastedLoad()
The U.S. Federal Energy Regula- location LoadForecaster
Instantaneous Hourly and
tory Commission (FERC) recent- range
Information location Intermittent
relaxationFactor day
ly approved several actions to Collection Information
smoothingFactor hour
otherUserData errorPercentage
revamp California’s power mar- otherLoadForecaster
getUserData()
kets over the next 2 years. This setUserData() forecastLoad()
ForecastedLoadInterface
calculateSmoothingValue() etcLoadForecaster()
is to ensure that sufficient sup- etcUserData()
hourNumber
peakLoad
ply is available to meet load peakHour
otherForecastedLoad
and reserve requirements. One-Time Information
FERC also approved changes to Collection transferForecast()
etcForecastedLoad()
protect wholesale customers HistoricalLoadData
from unreasonable rates during location
day
the time it will take to adopt peakLoad
peakHour
long-term market remedies. otherHistLoadData
FERC has proposed these storeData()
actions to contain the high retrieveData()
etcHistLoadData()
prices faced by California con-
sumers in the summer of 2000.
Its report noted that the Califor- Figure 8. Logical model of the load forecast module

October 2001 37
 With the evolving power market scenarios and the emergence
of diverse software, software quality is bound to invite more
attention than ever before
power system software support the operating system. A
practice by companies developing power system soft-
ware was to provide in-house platforms for implementa-
tion of the power software system. This required
customer utilities to spend additional resources on the
infrastructure to support these in-house development
systems. The present day trend is to provide open plat-
form systems that have the capability to run on any spe-
cific operating system without the need by the utilities to
incur additional financial burden. One such platform has
recently been developed by ABB that will change how
the deregulated energy systems are presently operating.
Concerted efforts are being directed in developing such
innovative and versatile system infrastructure compo-
nents, which are related to the software engineering con-
cepts used as the foundation. Attention has been drawn
to power system engineers to make optimal utilization of
such concepts in the deregulated energy markets.
Diverse Software
With different vendors constantly being added to the
software solution providers, the range of available power
system software packages is increasing. Due to this
trend, compatibility between the software packages can
be an issue, making software development environments
more complex than ever. Software quality is a major con-
cern when different software packages are working hand-
in-glove with each other.
It is expected that software requirements in deregulat-
ed energy markets will be stringent. With the importance
of software quality being paramount, the use of tools for
software configuration and software modeling will be a
basic necessity.
Acknowledgments
The authors thank the Research and Development group of ABB Ener-
gy Information Systems in Santa Clara, California, for their ideas and
suggestions that contributed to the creation of this article
For Further Reading
M. Shahidehpour and M. Marwali, Maintenance Scheduling in Restruc-
tured Power Systems, Norwell, MA: Kluwer, 2000.
“Hemisphere Report,” Forbes Magazine, 15 Dec. 1997.
T. Quatrani, Visual Modeling with Rational Rose 2000 and UML, 2nd
ed., Reading, MA: Addison-Wesley, Feb. 2000, p. 7.
I. Sommerville, Software Engineering, 4th ed., Reading, MA: Addison-
Wesley, 1992, ch. 18.
G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Lan-
guage User Guide, 5th ed., Reading, MA: Addison-Wesley, Oct. 1999, ch. 1.
ABB Energy Information Systems, Energy News (Source: Reuters),
November 2000.
“Restructuring the Thin-Stretched Grid,” IEEE Spectrum, Jun. 2000,
38 IEEE Computer Applications in Power
pp. 43-49.
R.F. Hirsh, Power Loss: The Origin of Deregulation and Restructuring
in the American Utility System, Cambridge, MA: MIT Press, 1999.
D. Sparks, “The California Electricity Market,” IEEE Power Engineer-
ing Review, Jun. 1999, pp. 11-12.
Biographies
Harjeet Singh Gill is an applications engineer at ABB Energy Informa-
tion Systems, Santa Clara, California. He received his B.Sc. degree from
Government College, Chandigarh, India, in 1985, B.E. (Hons.) degree
from Panjab University, Chandigarh, India, in 1989, and the M.Sc. and
Ph.D. degrees from the University of Saskatchewan, Saskatoon,
Saskatchewan, Canada, in 1997 and 2000, respectively. He is involved in
developing software systems in association to deregulated energy mar-
kets and administering configuration environment of products. His
interests include software engineering, system administration, and
power system analysis.
Visnja Filipovic-Gledja is the Customer Focus director at ABB Ener-
gy Information Systems. She received her Ph.D. from McMaster Univer-
sity, Ontario, Canada. Her research on developing a probability-based
model for predicting the loading of transmission lines is highly
acclaimed and has earned her a patent for her work. Her vast experi-
ence in the software and engineering disciplines has garnered her posi-
tions of heavy responsibilities. She is focusing her efforts on process
improvements to ensure the quality of software products delivered by
the company. The implementation of the capability maturity model
constitutes a prominent part of her priority initiatives. Software engi-
neering and power system analysis form her major working interests.
Himadri Prasad Mukherjee is a consulting engineer at ABB Energy
Information Systems. He received his M.S. in electrical engineering
from Arizona State University with a dual major in power systems and
computer science in 1996, and B.Tech. degree from Regional Engineer-
ing College, Kurukshetra, India. He is a member of the IEEE and has
over 5 years of professional experience in power systems software
development and switchgear manufacturing.
Tarlochan S. Sidhu received his B.E. (Hons.) degree from the Pun-
jabi University, Patiala, India, in 1979 and his M.Sc. and Ph.D. degrees
from the University of Saskatchewan in 1985 and 1989, respectively. He
worked for the Regional Computer Center, Chandigarh, India, develop-
ing software for computer-based systems, and Punjab State Electricity
Board in India in distribution system operation and thermal generating
station design. After obtaining his Ph.D. degree, he joined Bell-Northern
Research Ltd., Ottawa, Canada, and worked on a software development
project. In 1990, he joined the University of Saskatchewan, where he is
presently professor and graduate chairman in the Department of Elec-
trical Engineering. He is a senior member of the IEEE, registered profes-
sional engineer in Saskatchewan, and a chartered engineer in the UK.
His research interests include applications of computers and newer
technologies for achieving improved protection and monitoring of
power systems.
Lan Cui received her B.Sc. and M.Sc. (Hons.) degrees in electrical
engineering from the Shandong University of Technology, Jinan, China,
in 1988 and 1991, respectively. Currently completing an M.S. degree
from the University of Saskatchewan, she has experience in designing
substations and associated protection schemes, strategy analysis of
reactive power optimization in distribution systems, developing
automation software for resource management, power system security,
and contingency analysis. Her professional interests include software
engineering, computer programming and algorithmic analysis, and
power system reliability.