Itron 920 Operational Instructions(ulitlity software....?)

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