22.6 Practical Considerations
22.6.1 Choosing the Vendor
22.6.1.1 Choosing a Platform Vendor
In choosing a platform (SCADA, DMS, TCOMS) vendor there are several characteristics that should be
kept in mind (these should be considered as a rule of thumb based on experience of what works and
what does not). Choosing the right vendor is as important as choosing the right software package.
Vendor characteristics that the authors consider important are:
.A strong ‘‘product’’ philosophy. Having a strong product philosophy is typically a chicken and egg
proposition. Which came first, the product or the philosophy? Having a baseline SCADA
application can be a sign of maturity and stability. Did the platform vendor get there by design
or did they back into it? Evidence of a product philosophy includes a baseline system that is in
production and enhancements that are integrated in a planned manner with thorough testing on
the enhancement and regression testing on the product along with complete and comprehensive
documentation.
.A documented development and release path projected three to five years into the future.
.By inference from the first two bullets, a vendor who funds planned product enhancements from
internal funds.
.A strong and active user group that is representative of the industry and industry drivers.
.A platform vendor that actively encourages its user group by incentive (e.g., dedicating part of its
enhancement funding to user group initiatives).
.A vendor that is generally conservative in moving its platform to a new technology; one that does
not overextend its own resources.
.Other considerations.
.As much as possible, purchase the platform as an off-the-shelf product (i.e., resist the urge to ask
for customs that drive your system away from the vendor’s baseline).
.If possible, maintain=develop your own support staff.
All ‘‘customization’’ should be built around the inherent capabilities and flexibility of the system (i.e., do
not generate excessive amounts of new code). Remember, you will have to reapply any code that you may
have developed to every new release; or worse, you will have to pay the vendor to do it for you.
22.7 Standards
22.7.1 Internal Standards
The authors highly recommend the use of standards (internal to your organization) as a basis for
ensuring a successful distribution automation or SCADA program. Well-documented construction
standards that specify installation of RTUs, switches, and line sensors with mechanical and electrical
specifications will ensure consistent equipment installations from site to site. Standards that cover
nontrivial, but often overlooked issues can often spell the difference between acceptance and rejection
by operational users and provide the additional benefit of having a system that is ‘‘maintainable’’ over
the 10–20 years (or more) life of a system. Standards that fall in this category include standards that
cover point-naming conventions, symbol standards, display standards, and the all-important operations
manual.
22.7.2 Industry Standards
In general, standards fall into two categories: standards that are developed by organizations and
commissions (e.g., EPRI, IEEE, ANSI, CCITT, ISO, etc.) and de facto standards that become standards