Develop Requirements for System Functions
UCI has a well established methodology for developing the requirements for
sophisticated automation systems and the supporting information infrastructure and
communication networks. This methodology is as follows:
Gather Information
UCI meets with the client to determine the nature and extent of his requirements.
This process can take many forms, many of which are use simultaneously, including:
Determine Conceptual Design and Functional Requirements
Based on the information gathered, UCI determines the conceptual design and
functional requirements. This step is crucial before we start to prepare specifications
which vendors will bid on. Often utilities are familiar with doing certain processes in
certain ways, with different departments assigned to perform precise tasks. However,
if the utility were simply to automate these tasks, many opportunities for improving
efficiency and accuracy would be lost. Rather than just automating each task, the
entire process should be analyzed and re-engineered. For instance, if each
department in isolation were to automate the collection and storage of just the
information they need, and assume that exchange of data with other departments
would remain as paper reports, then the potential efficiency of the overall process
would be seriously compromised.
We therefore develop a conceptual design which covers not only the current process
under consideration, but also other utility processes which may sooner or later need
to be integrated more closely with the current process. We cover many aspects, such
as:
Determine Communications Architectural Infrastructure
UCI recognizes that no system should be an island. The interfaces determined during
the conceptual design must be enabled over well-designed communications
infrastructure. The problem of integrating disparate systems has led to much
discussion, and one basic truth. The key to integration is the use of Open Systems
and International Standards for interfaces between systems. Over the years, the
computer and telecommunications industries have developed parts of the solution.
They have designed many computer and communication standards for linking
computers together in a variety of configurations. Vendors who use these standards
can interconnect their systems. The most common standards include:
However, these standards only address methods of transporting bits and bytes
between computer systems. They do not address the methods of identifying what the
bits and bytes mean. The task of uniquely identifying data as it is exchanged among
many different systems has only started to be addressed in the last few years.
The basic concepts were designed in the computer industry, and are based on Object
Models and Middleware concepts. Middleware allows disparate systems, built by
different vendors on different platforms at different times, to exchange information
using a common methodology and interface, without needing to develop special
methods for each vendor or platform.
Object model standards have been developed specifically for the utility industry by the
IEC TC57 working groups. These standards include:
Security is also a major aspect in designing the communications infrastructure. With
systems increasingly networked, and with competition adding an incentive to have
unauthorized access to data, security must be designed into the infrastructure from
the beginning.
Alternatives in system architecture will be formulated based on the functional
requirements and a set of system design criteria. Such criteria will include but not be
limited to:
UCI has a well established methodology for developing the requirements for
sophisticated automation systems and the supporting information infrastructure and
communication networks. This methodology is as follows:
Gather Information
UCI meets with the client to determine the nature and extent of his requirements.
This process can take many forms, many of which are use simultaneously, including:
- Questionnaire
UCI develops a Questionnaire or Checklist, which is used during the first kickoff
meeting to determine the scope of the requirements. We discuss all the items
on the checklist with the utility’s project team.
Interviews
UCI interviews key utility staff, including the system operators, the computer
support personnel, the telecommunications personnel, planning personnel,
supervisors of field crews, managers, and other staff who will utilize the new
technology. We cover how they currently perform their jobs, as well as what
new functions they will need to perform in the future. Our discussions range
from the utility’s mission statement, to current operational and technical
problems, to “blue sky” wishes, to what color the displays should use to show
transmission lines.
- Documentation
- UCI requests documentation from the utility that covers their existing system
capabilities, those external systems which must be interfaced, the utility’s
operational procedures, and any future plans for expansion or upgrading of
system capabilities. Often this documentation is incomplete or obsolete, so we
supplement it with discussions and questions to key personnel.
Determine Conceptual Design and Functional Requirements
Based on the information gathered, UCI determines the conceptual design and
functional requirements. This step is crucial before we start to prepare specifications
which vendors will bid on. Often utilities are familiar with doing certain processes in
certain ways, with different departments assigned to perform precise tasks. However,
if the utility were simply to automate these tasks, many opportunities for improving
efficiency and accuracy would be lost. Rather than just automating each task, the
entire process should be analyzed and re-engineered. For instance, if each
department in isolation were to automate the collection and storage of just the
information they need, and assume that exchange of data with other departments
would remain as paper reports, then the potential efficiency of the overall process
would be seriously compromised.
We therefore develop a conceptual design which covers not only the current process
under consideration, but also other utility processes which may sooner or later need
to be integrated more closely with the current process. We cover many aspects, such
as:
- SCADA Systems
- Network Analysis applications – real time and study mode, optimization
- Generation applications – real time and planning, unit commitment
- Market applications for the Energy Management System – interchange
scheduling, transaction evaluation, power flow assessment of potential
transactions, OASIS (in the North American market) - Market applications for the Energy Purchasers – power brokering system,
OASIS, transaction management system - Interfaces between Control Centers, either within a utility or between utilities
- Interfaces within Operational Systems, such as the Dispatchers Power Flow,
Optimal Power Flow, Operators Training Simulator - Interfaces between the Transmission Operations System (EMS) and Distribution
Operations Systems (DMS) - Interfaces to the Utility’s Corporate Network and the Public Internet
Determine Communications Architectural Infrastructure
UCI recognizes that no system should be an island. The interfaces determined during
the conceptual design must be enabled over well-designed communications
infrastructure. The problem of integrating disparate systems has led to much
discussion, and one basic truth. The key to integration is the use of Open Systems
and International Standards for interfaces between systems. Over the years, the
computer and telecommunications industries have developed parts of the solution.
They have designed many computer and communication standards for linking
computers together in a variety of configurations. Vendors who use these standards
can interconnect their systems. The most common standards include:
- Lower layer communication protocols: Asynchronous Transfer Mode (ATM),
Frame Relay, Sonet, Ethernet LANs, TCP/IP - Networks with standard routing protocols: Border Gateway Protocol (BGP),
Open Shortest Path First (OSPF) - Upper layer communication protocols: File Transfer Protocol (FTP), Hyper Text
Transmission Protocol (HTTP) - Data exchange between databases: Comma-delimited flat files, Sequential
Query Language (SQL), Remote Database Access (RDA), Hyper Text Markup
Language (HTML), eXtensible Markup Language (XML) - ICCP for inter control center data exchanges
- DNP 3.0 for traditional communications with RTUs
However, these standards only address methods of transporting bits and bytes
between computer systems. They do not address the methods of identifying what the
bits and bytes mean. The task of uniquely identifying data as it is exchanged among
many different systems has only started to be addressed in the last few years.
The basic concepts were designed in the computer industry, and are based on Object
Models and Middleware concepts. Middleware allows disparate systems, built by
different vendors on different platforms at different times, to exchange information
using a common methodology and interface, without needing to develop special
methods for each vendor or platform.
Object model standards have been developed specifically for the utility industry by the
IEC TC57 working groups. These standards include:
- Common Information Model (CIM)
- Generic Interface Definition (GID)
- Device object models based on IEC 61850: for substation automation
equipment, distribution automation equipment, power quality, distributed
energy resources, hydro power plants, and a growing number of other power
system devices.
Security is also a major aspect in designing the communications infrastructure. With
systems increasingly networked, and with competition adding an incentive to have
unauthorized access to data, security must be designed into the infrastructure from
the beginning.
Alternatives in system architecture will be formulated based on the functional
requirements and a set of system design criteria. Such criteria will include but not be
limited to:
- System redundancy
- Operation under energy post-disaster conditions
- Communication support required
- Maintenance requirements
- Interface/integration considerations
- Security
| Copyright UCI 2012, All rights reserved. |
 |
 |
 |
 |
 |
 |
| Consulting Services |