Innovatec Utility Software System Organization and
Requirements
Compu war e Corp.
08/09/ 99 11:13 AM 06/16/99 2:46 PM
Version 0.32
Table of Contents
1 OPEN ISSUES...............................................................................................................................4
2 INTRODUCTION.........................................................................................................................4
3 PRIMARY REQUIREMENTS....................................................................................................5
UPPORTED DATABASES
3.1 S
3.1.1 External databases..........................................................................................................6
ULTIPLE DATABAS E S ET SUPPORT
3.2 M
OGGING
3.3 L
RCHITECTURAL CONSTRAINTS
3.4 A
ERVER DATA MAINTENANCE
3.5 S
XTERNAL DATA DISTRIBUTION
3.6 E
ECURITY
3.7 S
..................................................................................................................................7
.................................................................................................................................8
3.7.1 Firewalls .........................................................................................................................9
3.7.2 Attack methods ................................................................................................................9
3.7.3 Export restrictions.........................................................................................................11
NTERNATIONALIZATION
3.8 I
ACTORY/DEPOT/INSTALLATION WORK FLOW
3.9 F
4 DERIVED REQUIREMENTS..................................................................................................13
UPPORTED APPLICATIONS
4.1 S
4.1.1 Supported interactive applications ...............................................................................13
4.1.2 Supported autonomous applications.............................................................................16
UPPORTED DATABASES
4.2 S
4.2.1 Internal databases.........................................................................................................18
4.3 COM A
4.4 R
4.5 I
CCESS
....................................................................................................................2221
EQUIRED REQUIREMENTS
NNOVATEC LOOK AND FEEL
4.5.1 Pluggable Look and Feel ..........................................................................................2221
4.5.2 Colors........................................................................................................................2322
4.5.2. 1 Foreground/Text.....................................................................................................2322
4.5.2. 2 Background............................................................................................................2322
AVIGATION
4.6 N
......................................................................................................................2322
4.6.1 Keyboard...................................................................................................................2322
4.6.1.1 Mnemonics............................................................................................................2322
4.6.1.2 Shortcuts................................................................................................................2423
4.6.2 Mouse ........................................................................................................................2423
OMPONENTS
4.7 C
.........................................................................................................................24
4.7.1 Primary Windows..........................................................................................................24
4.7.2 Secondary Windows ..................................................................................................2524
4.7.2.1 Dialogs..................................................................................................................2524
4.7.2.2 Login Dialog..........................................................................................................2524
4.7.3 Plain Windows...........................................................................................................2524
4.7.3.1 Splash Screens........................................................................................................2524
4.7.4 A splash screen should be implemented using com.innovatec.ui.Jsplash. The
application name, version and copyright information should appear on all splash screens.Applets
..........................................................................................................................................................2625
4.7.5 Buttons.......................................................................................................................2625
4.7.5 .1 Tool b a r s .................................................................................................................... 26
4.7.6 Menus ............................................................................................................................26
4.7.7 Statusbar .......................................................................................................................26
4.7.8 Organizing.................................................................................................................2726
4.7.8.1 Group Boxes ..........................................................................................................2726
..........................................................................................................6
.........................................................................................6
...............................................................................................7
..................................................................................................7
.............................................................................................7
........................................................................................................11
.....................................................................11
....................................................................................................13
........................................................................................................18
................................................................................................2221
.............................................................................................2221
2
4.7.8 .2 Tabbed Panes.........................................................................................................2726
5 CHANGE LOG...........................................................................................................................27
3
1 Open Issues
• What type of location information will we use (e.g., lat, long,
elevation, pole #) for gateways, re lays and meters?
• What tool will we adopt for netw ork RF planning, and how w ill
we interface t he rest of the system to it?
2 Introduc tion
The Enterprise Network and Internet Communications (ENICS)
system is a set of software applications that allow either utilities or
Innovatec acting as a se r vice bureau to m anage and operate an Innovatec
communications network. The functions required include the ability to
read meters, monitor network operation, install, decommission, swap
and test a l l elements in t h e communications ne t work and handl e a l arms.
In addition, Innovatec must have a means of planning and laying out
comm uni cati on s ne tw or ks, tr ain ing use rs a nd dem onst ra tin g th e syste m
to pr ospect ive cu stome rs. For deve lopme nt it is de sira ble t o have som e
means of exercising the communications network in a more intensive
manner than we have been able to in the past.
It will be necessary to update and possibly gather data from
databases that are not part of the Innovatec system. For example, a
utility may have a billing d atabase (and app lications that use it) alrea dy
in place. Data from scheduled reads might be placed into this billing
database.
Finally, it should be possible to log events of interest for later
analysis either by utility personnel or applications in the Innovatec
system.
Innovatec plans to eventually use the system for very large
installations (on the order of 10 million meters or more). Thus, it is
necessary to architect and build the system in such a way that its
functions can be distributed across multiple machines and possibly
multiple se rvers.
In addition, in Innovatec’s role as a service bureau, it may be
ne cessa r y to sit e a ga tew ay ser ve r an d possi bly som e se r ve r f un ction s a t
a customer site, while the rest are handled at Innovatec’s offices. For
examp le, a utility may want to put modems at the ir site so th at calls to
gateways are local calls, while Innovatec administers the network
remote ly.
A high le vel schem atic for the In novatec utility syste m is show n in
Figure 1. In the sch em atic, each of the applications is show n as if it wa s
a traditional monolithic program. However, the Innovatec system is
being de signe d and implemented as a multitier archite cture in which th e
user interfa ce is a set of Java applets an d HTML pages w hich u se a set of
servant s t o acces s various services, such as da t a base a ccess.
4
Alarm Configuration
Manager
(Interactive)
Meter
Reader
(Interactive)
Network
Exerciser
(Autonomous)
Field Service
Application
(Interactive)
Laptop or Handheld
Field Service
Database
Network Configuration
Database
Logging
Database
Network Planning
and Layout
Configuration
(Interactive)
Field Service
Network
Manager
via direct TCP/IP or
d i al u p PPP
Network Health
Monitor
(Autonomous)
Alarm Rec eiver
(Autonomous)
Physical Assets
Tracking
(Legacy)
Billing Ap plication
(Legacy)
Utilit y Ph y s ical
Assets Database
(Legacy)
Billing
Database
(Legacy)
Innovatec
Utility
Server
converter
Network Planning
Database
Production
Network
Gateway
Server
Network
Emulator
Alarm Configuration
Network
Testbed
Database
SW/HW Compatability
Database
Figure 1: High level s chematic for the Innovatec utility softw are syst em
This d ocume nt supplie s a gen eral org aniz ation and par titioning for
the system as well as requirements that apply to all applications. The
re quir ements for t he various com pone nts of th e syst em a re conta ined in
their own requirements documents.
3 Primary Requirements
Primary requirements are those that ultimately come from the
cust omer or are dictated b y t he basic nature of th e a pplica t i on.
5
1.1
3.1 Supported Databases
For the purposes of this specification, the databases in the system
are classified into internal and external databases. Internal databases
are th ose th a t will be built into a stand a lone Innovatec system. External
(or legacy) databases are those that are supplied by a particular
rd
In nova te c custom e r or a p art icular 3
party application. An in terface to
an external database may be supplied as part of the customization for a
particular customer , b ut the information containe d in these databases is
not req ui red to run the Innovatec system.
Internal databases are specified i n section 4.2.1.
3.1. 1 E xter nal datab ases
While it is possible for the set of external databases to be
composed, in principle, of anything or nothing, we anticipate that the
external databases will typ ically consi st of the following for each utility.
Database Record Type Item Comment
Billing Basic
account
information
Meter
information
for a
customer
• Account number
• Customer name
• Customer address
• Account number
• Meter type
• Me ter n ame
May be
multiple
records for
each
customer
Physical Assets Data for each
meter
• Account number
• Me ter n ame
• Meter type
• Meter Model
• Factory num ber
• Meter br a nd
• Meter size
• Zone
• Installa tion d a te
• Installer
• In stallation tim e
• Location
information
3.2 Mul t iple database set support
One of the uses of the utility server software will be Innovatec
acting as a service bureau. In orde r to support this type of operation, the
6
utility server software shall support multiple sets of independent
database s, one for each utility Innovatec supports.
It shall be the responsibility of the Innovatec Utility Server to
distinguish between sets of databases for different utilities, given an
appr opriate utility spe cif ication from the various app lications.
3.3 L og gi ng
It shall be possible to log events of interest into an internal
database. These events shall include, but are not limited to, message
tra nsm issions a nd r e cept ions. I t sh all be possib le for user s to conf ig ure
the number and the age of events to be maintained in the log.
All attempts by a clien t application to log into the ENIC S system or
a remote configura tion serve r to initially contact an ENIC S configura tion
server or a remote redistribution server to initially contact an ENICS
server should be log ged, wh ether the a t te mpt is su ccessful or not.
3.4 Arch itect ural constrai nts
It shall be possible to distribute user interface, database and
ser ve r functi ons ove r mu ltip le ma chine s. I t sha ll b e possib le for use r s to
remotely access the interactive utility programs from remote desktop
comp uter s. I t sh all be possib le to si te th e WAN int erfa ce har dware on a
machine that is physically separate from the machine(s) that host the
databases and are generally used for network maintenance and other
functions.
3.5 Server data maintenance
To the extent that is consistent with maintaining the integrity of
the various databases, user visible data shall not be lost if a server or
server machine suf fers a n ungra ceful shutdow n.
3.6 Ext ernal Data Distribution
In addition to interacting with an Innovatec communications
network, it shall be possible for the ENICS system to distribute data to
and/or r ece ive data from an other ENICS system . This will allow a utility
that does not actually own th e meters for a particular customer to gather
data about a meter from the utility that does own the meter. The
interactions supported in this mode are limited to scheduled reads, on
demand reads, informational alarms, informational alarm configuration
and basic meter status information. Informational alarms include low
flow threshold, prepay alarms and other alarms that indicate usage
violations but that are not associated with a possible physical failure.
Alarms that do indicate a physical failure (such as runaway alarms),
shall not be configurable by an external utility and shall not be
distributed to an external utility.
7
It shall b e possible to conf igur e a ccess p er mission for an ext erna l
utility on a me ter by me ter basis. It shall be p ossible to configure w hich
alarms may be distributed to or configured by an external utility on an
alarm b y alar m and me ter by m eter ba sis. If a n external utility has b een
granted configuration permission for a particular alarm on a particular
meter , the n the utility that grants that permission will no longe r be able
to configure or receive that alarm for that meter. Note that the owner
utility will still need to keep track of the alarms that have been
configure d by an external utility, in case the m eters associated with the
external utility or the gateways associated with those meters are
physically m odified, re conf ig ur ed or rep laced.
Both the hosting and receiving ENI CS servers shall keep track of
the number and types of data sent/received to/from the remote
distribution server f or b illin g p urposes.
3.7 Security
Security considerations for th e ENICS syste m fall into the f ollowing
four areas:
• Authentication (is the user or utility really who he, she or it
says they are)
• Authorization (is the user or utility allowed to perform the
operation they are requesting)
• Confidentiality (prevent an outside observer from viewing data
that the utility d oe sn’t wa n t them to view)
• Auditing (leave a trail so that attempts to compromise the
system are tr acked f or late r analy si s)
The othe r two area s tha t are ofte n of conce rn f or brow ser use rs in
a networked environment, containment and nonrepudiation, are not of
much concern to users who may run ENICS applets or applications since
all such app l ets, appli cations and ser vers come from a tr usted sou rce.
Authentication is a concern in two areas. The first is that only
people authorized by the utility run the ENICS applets/applications,
such a s the i nter active me ter re ader , the fiel d ser vice appl ication or the
network configuration manager. The second is that data distributed to
an outside utility is sent only to systems that have been explicitly
authorized t o recei ve such d ata.
Authentication in the ENICS system consists of two elements. The
first is password authentication. All users shall be required to enter a
password before using any ENICS application/applet with a user
interface. Passwords shall be stored internally in a form that is
cryptographically secure . The se cond is host identification. It shall be
possib le for syste m administrator s to allow access to the ENICS syste m
from an application/applet or a third party using the external data
distr ibution capability only from some designated set of hosts. Thus a
8
user atte mpting to log in using a valid password f rom a host that is not
in the de si g nated set of hosts would be de nied access to t he syste m ( with
an appropriate reason given). There shall be a means to indicate that
acce ss from any host ar e allowed.
Authoriz a tion shall be supported by a ccess control lists. It shall be
possible to assign permissions on a user by user, utility by utility (for
external data distribution) and application by application basi s. Thus, a
user might be allowed f ull acce ss to the intera ctive meter reader, but no
access to the network configuration manager. All ENICS applications
shal l con sult the a ccess c on tr ol li st b ef or e perf orm in g any oper ati on th at
might be forbidden by the access control list. Applications/applets
should provide a visual indication of forbidden operations (e.g., grayed
out controls) if a se t of operations is not allowed for a user.
Confidentiality shall be supported through encryption of any
comm uni cati on be tw ee n ENI CS se r vers (f or exte rn al data d istr ib ution ) or
between ENICS servers and applications/applets that involved
confiden tial data. If private key exchange is require d (e. g., to use a DES
algorithm), then the private keys shall be encrypted when they are
exchanged (e.g., with a public key encryption technique ).
Auditing shall be supporte d by the logging facility. All atte mpts to
acce ss (i.e ., log into) t he syst em b y a user or by an exte rnal agent shal l
be logge d, w heth er t hey are succe ssful or n ot. As much da ta as possi ble
should be captured, particularly for unsuccessful logins, including the
login name and the machine name from which the login attempt is m ade.
3.7.1 Firewalls
1.1.1
It is anticipa ted that an ENICS syste m will ty p ically oper ate behin d
a firewall. The firewall is set up to deny access to unauthorized users
contacting the system from outside the local network (e.g., through the
Internet). ENICS applications, applets and servers are neither required
nor en couraged to defeat firew all security using HTTP tunn eling or othe r
techniques. This implies that it will be necessary for ENICS system
administrators to explicitly allow firewall access to outside users on
spe ci fied por t s. It shall be p ossi b l e for an ENICS syst em admi nistrator to
configure the port number(s) used to contact enics servers. This does
not im ply t hat such config urati on ne cessar ily mu st be done on a se rve r
by server basis.
3.7.2 Attack methods
1.1.2
The following potential attacks sho uld be considere d in the design
of the ENICS software:
• Monitoring. A cracker could monitor the data stream in an
attem p t to fin d authorized user names and p a sswords. A utility
competitor could attempt to monitor the stream of meter reads
to determine which customers could be “cherry picked”.
9
Monitoring can be defeated through encryption of the data
stream, including any interactions in which passwords are
passed.
• Password guessing, d i ct i onary or e x h austive scan (particularly if
dr i ven by a computer pr og ram ) . Password choice rules plus the
use of a reasonably large salt (to complicate reverse dictionary
construction by an insider) should make this very difficult.
Note some part of the enforcement of good password choices
(e.g., don’t use your wife’s maide n name) must be addressed by
inter n a l utility p rocesses.
• A legitimate user attempts operations that he or she is not
authorized to perform. This is addressed by access control
permissions.
• A legitimate user attempts operations from a suspicious
location ( e.g., a disgruntled former empl oy ee wh o wa s a netw ork
adm in istr at or tr ies to shu t dow n t he In nova te c comm un icat ion s
network by deregistering all the meters from the gateways and
erasing them from the utility database from his home
computer). This is addressed using host identification in
addition to passwords. Note that internal utility processes are
responsible for making sure that only correct hosts are
identified as legitimate source s to the ENICS system.
• A computer cracker attempts to gain access to the ENICS
syste m by running an applet or application that claims to be a
standard ENICS applet. This is handled by keeping password
and host identification contained on the server (any
authentication containe d in a client would have been bypassed
because a re a l ENI C S clie n t isn’t being used).
• A computer cracker attempts to gain access to the ENICS
system by running an apple t or application that claims to be an
ENICS configuration server portal. This is handled by host
identification. The cracker may attempt to defeat host
identification by assigning his machine the same host address
as a legitimate ENICS server. This can be defeated by
configuring a firewall to refuse incoming packets from a host
that has the same address as an intern al ENICS server .
• A computer cra cker attempts to gain access to meter data and
some alarm configuration capability by running an applet or
application that claims to be a ENICS server that is set up for
external data distribution. This is handled using host
identification. The cracker may attempt to defeat host
identification by assigning his machine the same host address
as a legitimate machine that is the target for external data
distribution. This cannot be defeated using firewall
configuration, since external access for on-demand reads and
10
ala rm conf ig ura tion is ne ce ssar y. There is c urrently no effective
answer in these specifications for this form of attack. Ther e is no
potential for harm to the source utili ty databases or the Innovatec
communications network, how ever met er dat a t hat w as set up for
external data distribution could be monitored.
• A computer cracker runs a program that bombards the ENICS
syste m with ra nd om packe ts or bog us log in a tte m pts. By usin g
up the available bandwidth, access to the ENICS system by
legitimate users is prevented (i.e., a denial of service attack).
There is no way to automatically defeat this type of attack.
Rejects of improper access attempts to the ENICS system
should be log ged , includ ing t he host name of the sour ce of t he
attempt. Care should be taken that repeated illegal access
attem pt by the same source do not f ill up the logging data base.
This log will aid in tracking down the offe n d in g p arty .
3.7. 3 E xp or t restr ic tions
Some of the str ong cr yp togr a ph ic algorith ms that we plan to use to
protect data confidentiality are export restricted. This means that if an
ENICS system is deployed outside of the borders of the United States
that it may be necessar y to plug in a d ifferent set of weaker algorithms to
me e t exp ort r e str iction s. The sof tw ar e sha ll b e str uctur ed in such a wa y
that it is possible to easily produce an export version that uses different
cryptograp h ic algor ithms than the regular ENICS software.
3.8 Int ernationalization
There are no plans to export the ENICS software to non English
speaking countries. Internationalization of the ENICS servers,
applications or apple ts is not required.
3.9 F act ory/Depot/Inst allati on Work Flow
IMUs, relays and gateways are expected to follow a certain work
flow during their lifetimes, as shown in Figure 2Fig ure
IMUs, relays and gateways are assembled at the factory. At this
point IMUs and relays are assigned a Utility Serial Number (i.e., pin #)
and a ch an nel. Ga tewa ys sh ould h ave th eir W ANs act ivat ed , if possib le .
IMUs, relays and gat eways sh oul d be t este d via the R F and (i n the case of
gateways) via the WAN interface (see Gateway Node Noninvasive Test
Procedure Specification). The tool used to perf orm these functions is the
Factory Commissionin g and Te st t ool .
IMUs, relays and gateways are manufactured in response to
projected demand, rather than for a specific utility order. Therefore, at
the factory utility serial numbers (i.e., pin numbers) are assigned
seq u entially, but not associa t ed w i t h any specific Inn ovatec cust omer.
2Figure 2.
11
IMU s, r elay s and gateways are forw arded to a utility de pot. At this
point they must be associated with a certain customer (for IMUs) or a
certain location and set of IMUs (for re l ays an d gatew a ys), the associ ati on
loaded into the network configuration database and work orders
generated and IMUs registered with their respective gateways. These
functions are preformed (directly or indirectly) using the Depot
Commissioning tool. In addition, th e units ma y be te sted again using the
Field Maintenance and Diagn osis tool.
Factory
Factory
Commisioning
& Test Tool
Figure 2: IMU, Relay and Gateway work flow
ENICS Server
IMU, Relay,
Gateway
Depot
Commisioning
Tool
Field
Maintai nence
& Diagnosis
Tool
Utility
Depot
IMU
(fa il e d or
reused)
Relay,
Gateway
(fa il e d or
reused)
IMU
Relay,
Gateway
Field Service
Application
Utility
Customer
Site
Field
Maintai nence
& Diagnosis
Tool
Field
Maintai nence
& Diagnosis
Tool
Gateway &
Relay Po le
Locations
Gateways and relays will move from the depot to their pole
locations. Gate ways and rela ys are installed and teste d using the Field
Maintenance and Diagnosis tool. Once gateways and relays have been
installed, the IMUs move from the depot to customer sites, where they
are installed, tested an d their installation in th e gateways verifie d using
the Fie ld Service Application tool.
At some point in their lives IMUs, relays or gateways may be
replaced due to suspected failure or other reasons. These units go back
to the depot. Suspected failures may be explored using the Field
Mainten a n ce a n d Diagnosis tool.
While both the depot commissioning tools and the network
configuration manager modify the network configuration database, the
depot comm issioning tool is limite d to filling in id (e.g ., IMU utility se rial
number) and address fields (e.g., WAN addresses) for units that have
already been entered into the network configuration database. This
12
imp lie s that a unit m ust have a lre ady b een adde d int o th e sy ste m by t he
ne twor k conf igura tion m anage r befor e the de pot comm issionin g too l can
be used to m odify its data, and that a n ull entry for certain fields must
be allowed in the network configuration database for IMUs, relays and
gatew a ys tha t are marked as not installed.
4 Der i ve d Requirements
Derived requirements are those that are driven by the primary
requirement s, but a re imposed on ou rselves.
1.14.1 Supported applications
For those applications whose user interfaces are implemented
using Java applets, designers/implementers should strive to keep the
applets sm all, and implement any heavy duty operations in the se rvers
rather th an in the applets themselves.
1.1.14.1.1 Supp or ted int er ac tive applications
Interactive applications are those whose functions are primarily
driven by an explicit user request, such as a mete r read or a request to
uploa d a da t abase from a fi eld service a pplica t i on.
The Innovatec utility server system implements services for the
following user visible applications. These “applications” are not
necessarily implemented as monolithic applications in the traditional
sen se, b u t t hey ap pear that wa y to end-users.
“Application” Purpose Required server fun ctionality
Field Service
Application
Install, decommission,
swap, calibrate, and
test meters in the field.
The primary users are
field service people.
Operates on a field
service laptop or
handheld computer
that may be out of
communication with
the rest of the system
for long periods of time.
• Specify set of service orders for
a particular service person (or
service id ).
• Specify what is to be done for
ea ch service order.
• Allow basic IMU
communications parameter
configuration (e.g., set the
channel numbe r ).
• Perform basic tests of meter
communication.
• Check that nece ssary network
setup has been completed to
allow service order function to
pr oceed for a g i ven meter.
• Download service orders to
individual service laptops.
• Upload modified information
from in dividual service lapt ops
13
Field
Monitoring and
Diag nosis T ool
Factory
Commissioning
& Test tool
Depot
Commissioning
tool
Interactive
Meter Rea der
Monitors RF traffic.
Performs diagnostic
tests of meters, relays
and gateways.
Checks IMUs and
relays to make sure
they’re properly
programmed with the
correct Utility Serial
Number, produces
factory log, performs
noninvasive gateway
testing.
Connects specific IMU,
relay and gateway ids to
customer accounts and
locations. Permits
gateways, relays and
IMUs to be replaced
with identical units.
Query meter readings
and status interactive ly.
The primary users are
and integrate it into the
database s at th e utility end.
• Calibrate water meters
• Display all RF messages
received (should we allow for
filtering pa ra meters?)
• Invoke diagnostic tests for
IMUs, relays and gateways via
the RF inte rfa ce .
• Reprogram IMU
communications parameters
(e.g., meter utility id, channel
number, power).
• Query for all meters on a
channel.
• Scan channels for a meter
• Download gateway error and
event logs via RF.
• Perform pings via the WAN
from a gateway to the utility
(for WAN problem diagnosis),
invoked via the RF interface?
• Checks IMUs and relays for
correctly programmed Utility
Serial Number and default
channel
• Performs noninvasive gateway
test.
• Genera t es fa ct ory log .
• If the meter supports an
internal record of factory
commissioning, update that
record once tests and
configuration have been
completed.
• Isolate particular
customer/meter
• Read meter
14
Network
configuration
manager
Alarm
configuration
manager
Network
Emulator
System
administration
tool
Event log
viewer
utility customer service
people.
Configure Innovatec
communications
network, perform
network diagnostics,
manage hardware and
software versions,
support field service
operations. The
primary users are
network maintainers at
the utility.
Configur e which alar ms
should be recognized
for spe cif ic IMUs.
Emulates an Innovatec
communications
network. Allows the
introduction of alarms
or fault condition s (e .g .,
WAN link goes down)
interactively. Primary
users are utility
trainers and Innovatec
sales people.
Allows a system
administrator to
view, configure
and control the
ENICS servers
and clie n ts.
Allows data in the event
log tables to be viewed.
• Query me ter status
• Inform user when result of
oper a tion is availa b le.
• View netw ork logically.
• Supply data relating to
characteristics of a
communication s path.
• Supply meter and gateway
statistics and logge d history.
• Set up service orders
• Integrate modified service
order data into databases.
• Activate/deactivate alarm
notification.
• Specify notification method
(e.g., on scr ee n, hip pager).
• Replaces the gateway server’s
gateway agent.
• Reads network configuration
from a network configuration
database.
• Displays logical view of the
network.
• Allows a trainer or sales
person to interactively
introduce alarms and fault
conditions.
• View server configuration
information
• View act i ve clients
• Sta rtup/shutdown se rvers and
clients
• Add new hosts to ENICS
system, add or rearrange
utility servers in ENICS
system.
• View load in g statistic s.
• Add or dele te users.
• Add or delete remote
redistribution servers.
• Filters events by type, date
and auxiliary characteristics
15
Network
Planning and
Layout t ool
Network
Planning
Database
converter
Allows archived event
log data to be vie wed .
Contains RF
propagation models
that allow an Innovatec
communications
network to be laid out
(e.g., site gateways and
relays given meter
locations, taking into
account RF propagation
characteristics).
Primary users are
network planners.
This tool will be b ought
rather tha n built.
Converts from the file
formats used by the
network planning and
layout tool and imports
the data into the
internal Innovatec
Network and Planning
database.
specific to the event type.
• Off the shelf tool will have its
own file forma t s and views.
•
1.1.24.1.2 Supp or ted aut onom ous app lications
An autonomous application is one that runs without significant
user inte rvention, such as the automatic hea lth m onitor .
Application Purpose Required server
functionality
Network exerc i s er T es t t he netwo rk
software and gateway
server, in house. The
primary users are
developers and te sters
Network health
monitor
Determines when an
element of the network
hasn’t been heard of in
some time. Pings
elements of the
network that may not
be responding.
• Accepts set of
messages and
tim ing fr om a scrip t
file.
• May be possible to
purchase this tool
rather th an build it.
• Ability to associate
IMUs with relays
and gateways.
• Ability to send ping
messages to the
communications
network.
16
ENICS He a lth Monitor Per iodically scans the
event log looking for
suspicious patterns of
activity, such as
multiple blocked login
attempts. Monitors
the internal health of
ENICS
processes/threads to
determine if a
malfunction has
occurred.
Message Monitor Moves journa led
sent/received
messages from the
gatew ay server into the
logging database for
subsequent use by
other a p p lications.
Logged Event Pruner Deletes data from the
logging database that
is older than some
configura ble maxim um
age. The data may
optionally be logged to
an external medium
such as CD-ROM or
tape, rather than
deleted.
Gateway Logged Event
Gatherer
Per iodically gather s up
the error and event
logs maintained in the
gateway nodes.
Alarm receiver Acts when an alarm is
received.
Notified when an
internal ENICS
component wants to
raise an alarm.
• Ability to notify
users when
problems are
detected.
• Tells the alarm
receiver when a
suspicious pattern
of activity is
detected or a
malf unction occurs.
• Ability to access
record of all
messages sent and
received.
• Ability to do que rie s
and deletes on the
logging database .
•
• Ability to cause
alarm display
applet to be
updated.
• Ability to cause 3
rd
party devices (such
as hip pagers) to be
activated.
17
1.24.2 Supp orted Databases
While the general set of data present in the internal databases is
derived from the primary requirements, its partition into specific
dat abases is a hi gh le vel arch i t ectur e decision.
4.2.1 Inte rna l data bas e s
1.1.1
The utility server software shall support access to and
ma inte nance of the fol lowing inte rna l d atab ases, indepen den tly f or ea ch
utility suppor ted. The da tab ases referred to in th is se ction are abstract
entities introduced for the p ur p oses of re q uireme n ts an a lysis and w ill not
necessarily be implemented as databases in the sense of an JDBC (or
other protocol) database entity. Th e assignmen t of data to specific tables
and the assig nme nt of table s to specific datab ases will be done in pa rt in
the system architecture design a n d in part in the utility se rver design.
Database Record Type Item Comment
Network Co n figuration,
Network Planning
Gateway
Relay
Meter
Supported
WANs
Gateway-IMU
Gateway id
•
Gateway WAN Type
•
Hardware revision
•
number
Software revision
•
number
Operating system
•
revision numb er
Gateway application
•
(gw.zip) revision
number
Classes.zip revision
•
number
Patch file contents
•
and revision n umbers
Location information
•
Relay id
•
Relay hardware
•
revision numb er
Relay software
•
revision numb er
Location information
•
Utility Id (AKA utility
•
serial number, pin
number)
Meter type
•
Location information
•
Cali bra t ion F a ct or (for
•
water meters )
WAN type designation
•
WAN PIN numb er
•
Gateway id
•
Patch file
may be a
separate
record type
or even in a
separate
table.
Location
information
may include
lat, long,
elevation
and pole #.
Location
information
may include
lat, long,
elevation
and pole #.
Location
information
may include
lat, long,
elevation
and pole #.
18
association
information
Software/Hardware
version c omp atibility
Alarm configuration Alarm activity
Logging Keeps track of
Use to keep
track of which
gateways,
relays and
meter versions
are compatible
with other
versions.
information
Alarm
notification
information
Notification
type record.
Typically
there’ll be one
of these for
every
notification
destination/des
tination type.
E.g., one for
each pager that
could be
notified that an
alarm has
arrived.
interesting
IMU id that is
•
registered with
gateway
Option relay id that
•
IMU is registered w i t h
•
IM U id
•
Alarm type
•
Alarm active or
•
inactive
Time of last activation
•
(or should this be an
alarm histo ry ?)
IM U id
•
Alarm type
•
Notification type
•
specification
Notificatio n ty pe
•
Device specific data
•
(e.g., PIN number for
a pager, display
device for on screen
notification)
Ti me event was logg ed
•
Event ty pe
•
This is
intended to
act as an
error
checking
mechanism.
This
database is
static from
the utilities
point of
view, and
would be
supplied by
Innovatec
each time a
new
gateway,
relay or IMU
version came
out.
The design
of this
19
events that
happen in the
system. This
includes but is
not restricted to
message
transmissions
and receptions.
Authorized users Keeps track of
authorized user
names,
passwords and
authorized
hosts.
Authorized external data
distribution targets.
Extern data distribution
meter configuration table
External data distribution
targ et transac ti o n log
Field Service Application
Database
Application Configuration
Database
Keeps track of
other ENICS
servers to
which data may
be distributed.
Keeps track of
what alarms
and status are
available to an
external utility
and what
alarms may be
configured.
Keeps track of
the
transactions
performed by
an external
utility (e.g.,
number meter
reads) for
billing
purposes.
Keeps track of
work orders
that have been
generated or
uploaded
Keeps track of
user settable
options for the
various
applications
Auxiliary info rm ation
•
•
•
•
Meter utility id
•
Transaction type
•
Number transactions
•
•
Service order number
•
Installer
•
Open/close dates
•
IMU information
•
Customer information
•
IMU location
•
information
Time stamps for as
•
found/as left changes
Application Name
•
User n ame
•
database is
not likely to
be one
monolithic
table, as the
“auxiliary
information”
may be u se d
to do
lookups in
other tables.
It may ma ke
sense to
keep this
data in the
NT registry
20
(possibly on a
per user basis,
where that
makes sense).
on the
server.
However the
interface the
applets and
applications
see should
be t h r ou g h a
servan t.
4.3 Permissions
Access control permissions (or just permissions) in the ENICS
system apply to all applications (including both Java applications and
applets) that may be initiated outside of the server environment.
Application s that a re initiate d by and run un der the control of the ENI C S
server e nvironment (such as the ne twork health monitor) do not require
acce ss per missions. Access perm i ssi ons are a ssi gned out of t he availab le
options on a user by user basis.
Each application has three sets of permissions. The first “set”
determines whether a use r is allow ed to access the ENI CS se rver while
running a particular application. For example, a user may be granted
permission to run the Interactive Meter Reader, but not the Network
Configuration Manager. This is not a security measure, since the only
way the ENICS server has to know what application is being run is for
the application to tell it. Thus, this sort of permission won’t be able to
dete r a cracker who writes his or her own a pplication, b ut it will give the
system administrator control over who can run applications under
nor mal circumst ance s.
The second set controls access to the various database tables in
the system. An application may have read, modify and append
permission for a table . Append is a restricted type of write access that
allows an application to add new records to a table, but not to either
modify or read records that already exist. Modify access implies both
read and append access. For databases that contain information that is
associated with particular users, users may be granted permission to
read or modify data for themselves only or for all users.
The third set of permissions controls access to the
comm unicat ions n etw ork. The f irst a ccess pe rm ission is “ netw ork use ”.
This allows an app lication to inter act with the comm unications n etwor k.
If it is not set, then the application is not allowed to interact with the
communications server. The second network access perm ission is IMU
read/modify, which determine which type s of messages that can get or
set IMU information are allowed to be sent. The third network access
permission is network read/modify, which determines which messages
can be sent that may read information from or modify gateways and
rela ys. Please note that even a n application that ha s no explicit netw ork
21
access may invoke an operation that will cause the ENICS server to
acce ss t he n etwork.
1.34.4 COM Access
In order to support miscellaneous analysis and data gathering
capabilities, a COM interface to the ENICS business objects shall be
imple mente d. This will allow progra ms to be written in Visual Basic that
can retrieve information from the ENICS system. The COM interface
shal l be de sign in such a wa y tha t it sh all not b e possi ble to com pr om ise
ENICS se rver or Innovatec networ k comm u nications using the interfa ce.
A set of stand ar d V isual Basi c ap plica tion s should be im pl eme nt ed
for comm on ope ra tion s such a s ga the r ing rea ds fr om a pre def ine d gr oup
of meters and gathering time of use information. These standard
applications will serve to get Innovatec customer ’s star ted using the more
exotic functions of the system quickly and also server as examples for
Innovatec customer IT departments that wish to implement their own
data analysis programs.
4.5 Required Requirements
1.4
All application requirements documents shall include the following:
1. Startup
2. Shutdown
3. I/O interfaces, if any.
4. R equired services.
5. Behavior in the event of errors, including but not limited to
internal program errors, communications errors, database
acce ss errors a nd server a ccess errors.
6. Me chanism for notifying users when a problem is detected (e.g.,
dial og box, logged event).
7. W h ich events should be logged (e.g., significan t user actions).
4.6 Innovat ec Look and Feel
4.5
4.5.14.6.1 Plugg able Look an d Feel
All enics applications should implement the
com.innovatec.plaf.InnovatecLookAndFeel look and feel.
import com.innovatec.plaf.InnovatecLookAndFeel;
...
static{
try{
UIManager.setLookAndFeel( new InnovatecLookAndFeel() );
}
catch( Exception e ){}
}
22
1.1.24.6.2 Colors
4.5.2.14.6.2.1 Foreground/Text
Foreground colors should contrast extremely with the background.
Since most of our background colors ar e very light, la b els, and text areas
will have black foreground colors. Buttons on the othe r hand have very
dark b ackg rounds, so their text will nor mally be white.
1.1.1.2
image with different concept area. For example if there are two panels on
one screen that re prese nt different ide as, utility re cord and me ter status,
they shoul d be of diff eren t colors to ma ke th em easily distinguishab le.
blindne ss, images w ith d ifferent subtle te xtures should be used as we ll.
Images can be added by using com.innovatec.ui.BasicPanel instead of
JPanel, and setting the image through
BasicPanel.setBackgroundImage.
1.6
4.6.14.7.1 Keyboard
• Tab or Ctrl-Tab. Moves keyboard focus to the next component or to
• Shift- Ta b. Move s ke yboard f ocus to the previous component or to the
• Arrow keys. Moves keyboard focus within the individual components
4.6.2.2 Background
Backgr ounds for panels should be light and chang e in color and or
Since colors cannot be completely relied upon due to color
4.7 Navigation
In general, navigating between components follows these rules.
the fir st m em ber of t he ne xt gr oup of com pone n ts. U se Ct rl -Tab whe n
the component itself accepts tabs, as in text fields, tables, and tabbed
panes.
first comp onent i n the previous gr oup of com p onen t s.
of a gr oup of comp one nt s, f or e xam ple, with in men u item s in a me n u
or w i t hin r a dio buttons in a g roup of ra dio buttons.
Most of the keyboard navigation is taken care of by Java, some
changes in tab order may need to be implemented by specifying the
ne xt focusabl e comp onen t t o a component . This ca n b e a ccomplished
by JComponent.setNextFocusableComponent.
1.1.1.14.7.1.1 Mnemonics
Mnemonics are another keyboard alternative to the mouse.
Mnemon i cs can be used t o navigate menus.
Rule s of thumb fo r creating mnem onics:
1. If the mnemonic does not appear in the table of common
mn emon ics, choo se the f ir st le tter of the me nu it em. For in sta nce ,
choo se J for Justify.
23
2. If the first letter of the menu item conflicts with those of other
menus, choose a prominent consonant. For instance, the letter S
has already been designated as the mnemonic for the Style
command. Therefore, choose the letter Z as the mnemonic for the
Size command.
3. If the first letter of the menu item and the prominent consonant
conf l ict with t hose of oth er men u i t ems, choose a prominen t vowel.
Mnemon i cs ca n be set by AbstractButton.setMnemonic.
Mnemonics can also be added to any item with a label. This can
make it very easy to go directly to a component and add information.
A mnemonic can be added to a component via the label by
JLabel.setLabelFor and JLabel.setDisplayMnemonic.
1.1.1.2
should be cle arly labeled on the menu and or button for that command.
The same shortcut key cannot refer to different actions in the
application. Here is partial list of shor tcut keys and the ir pur p ose:
1.1.2
Specifically clicking once on an enabled button should cause that
buttons action to occur. Clicking once on an editable text component
should cause the text caret to be placed and put th e text comp onent in
insert mode.
4.7.1.2 Shortcuts
All com mon com ma nd s shou ld have a shor t cut k e y str oke s, these
Common Shortcut combinations include:
Ctrl-N New (File Menu)
Ctrl-O Open (File Me n u)
Ctrl-S S a ve (File Menu)
Ctrl-P P rint (File Men u)
Ctrl-Z Undo (Edit Menu)
Ctrl-X Cut (Edit Menu)
Ctrl-C Copy (Edit Menu)
Ctrl-V Paste (Edit Menu)
Ctrl-F Find (Edit Menu)
Ctrl-A Select All (Edit Menu)
F1 Help
Ctrl-Q Exit Application
4.7.2 Mouse
A user can navigate through applications with the mouse.
4.8 Components
1.7
4.7.14.8.1 Primary W indows
A primary window is a window used as primary communication
with the user by the app lication. This is where th e user will re turn to in
order initiate differen t functionality. A Primar y Window shall consist of a
24
Titlebar giving the name of the application, frame, and what is being
done.
4.8.2 Secon dary W indows
1.1.2
4.7.2.14.8.2.1 Dialogs
Dial og s are small wind ows used t o concisely com municate with the
user.
1.1.1.24.8.2.2 Login Dialog
Prompt the user for login name and passwor d.
Use com.innovatec.ui.LoginDialog.
1.1.3
4.8.3 Plain Windows
4.7.3.14.8.3.1 Sp lash Screen s
A spla sh scr e en is a w in dow wit h no stan da rd win dow de cor ation s
(titlebar, close, minimize , maximize icons) that informs the user that the
software is loading and what exactly the program is.
A splash screen in ENICS shall consist of the Innovatec logo, an
image for the application, the application logo, version, and copyright
information.
25
1.1.44.8.4 A splash screen should be implemented using
com. in no vatec.u i. Jspl ash.
The appl icat ion n ame, version and copyr ight
information should appear on all spl as h s c r eens.Ap plets
Applets can be broken down into two types, simple and complex.
How an applet is displayed depends on what type of applet it is. A simple
applet would consist of one screen, no menus, no toolbars, no status bar.
This type of applet should be displayed within the br ow ser window and
should not add the confusion of creating anothe r frame.
A complex applet is one that needs to be interacted with from
another frame. A separate frame allows clear delineation between the
applet’s menus, toolbars, statusbar, and the browser’s equivalent. A
code snippet for a compl ex app l et’s f rame could look like this:
public void init(){
...
frame = new JFrame();
frame.getContentPane().add( panel );
...
}
public void start(){
...
frame.setVisible( true );
...
}
public void stop(){
...
frame.setVisible( false );
...
}
This will make the applet a non-visual comp onent, and the visual
components are added the frame itself.
1.1.54.8.5 Buttons
Buttons should be different colors from each other and the
background, colors can be repeated, but as far fr om a button of the same
color as possi ble.
1.1.1.1
4.8.5.1 Toolbars
Icons on toolbars will m a tch icons for buttons and or menus.
1.1.6
4.8.6 Menus
All command s availa b le should also be made available b y menu.
As much as pos sible all me nus shoul d have shor tcut key s and or
mn emonic a ssociat ed w ith the m. If a me nu shares funct ionalit y w ith a
button is should shar e the same la bel.
4.8.7 Statusbar
1.1.7
Small bar at the bottom used to convey information to the user.
The status bar should be use d be f ore a dialog box if at all possible. Error
26
me ssage s should b e in Re d. Succe ssful com ple tion sho uld be indi cated
with black.
For implementation use com.innovatec.ui.StatusBar.
1.1.84.8.8 Organizing
4.7.8.14.8.8.1 Group Boxes
Used to group like concepts. Group boxes should used sparingly
and group boxes w it hin group boxes should be avoid ed, they can becom e
conf using ve ry f ast and add ver y litt le to the organ ization of the scr een.
Instead of Group boxes consider having titles for areas, labels that
exten d slightly more left than the rest.
1.1.1.2
data that a re only tied together by a process.
4.8.8.2 Tabbed Panes
Tabbed panes are the pr eferred m ethod of br eaking large hunks of
5 Change Log
Date Applications/
Subsystems
Affected
5/17/99, Revision
0.2
5/17/99, Revision
0.2
Description of changes
Change d revision number to 0. 2 f rom
0.1.92
Remove action item f or authentication
of remote redistribution servers. It
was decided in requirements review
27
5/17/99, Revision
0.2
5/17/99, Revision
0.2
5/18/99, Revision
0.2
5/18/99, Revision
0.2
5/18/99, Revision
0.2
5/18/99, Revision
0.2
5/18/99, Revision
0.2
5/18/99, Revision
0.2
6/4/99, Revision
0.2
6/4/99, Revision
0.2
6/4/99, Revision
0.2
6/15/99 Revision
0.2
that host iden tification and the risks it
pre se n ts were tole r a b le and the w a y to
go.
Added meter model to physical assets
database.
Moved PIN number and calibration
factor data out of the specs for the
physical assets database and into the
network configur ation database.
Added logging for remote distribution
serve r applications.
Added alarm by alarm and meter by
meter configuration for remote data
distribution.
Added use of factory commissioning
signature in IMU for factory
commissioning tool if the meter
supp orts it.
Remove requirements for physical
display of Innovatec communications
network.
Updated shortcut keys: Changed Exit
Application from F4 to Ctrl-Q.
Assigned find to Ctrl-F and Paste to
Ctrl-V which is Windows standa rd.
Changed typo in Statusbar area that
said successf u l me ssag es sh ould be in
red, should be in black.
Add requirements for ENICS Health
monitor, add requirement for alarm
monitor to allow for server generated
alarms (in addition to alarm
messages).
Added requirements for COM
interface.
Add field service application database
to intern a l d ata b ase requir em ents.
Signoff complete
28
Loading...