Itron 921 Gateway/Telco User Manual Utility Network Operational Manual

Download:
Mirror Download [FCC.gov]
Document ID	100349
Application ID	zU4lvJrEPuO8w7SRlkoo1g==
Document Description	Utility Network Operational Manual
Short Term Confidential	No
Permanent Confidential	No
Supercede	No
Document Type	User Manual
Display Format	Microsoft Word - pdf
Filesize	17.78kB (222209 bits)
Date Submitted	2000-05-15 00:00:00
Date Available	2000-10-13 00:00:00
Creation Date	2000-05-15 20:45:44
Producing Software	Acrobat Distiller 4.0 for Windows
Document Lastmod	2000-05-15 20:45:46
Document Title	Utility Network Operational Manual

Innovatec Utility Software System Organization and
Requirements
Compuware Corp.
08/09/99 11:13 AM06/16/99 2:46 PM
Version 0.32
Table of Contents
1 OPEN ISSUES...............................................................................................................................4
2 INTRODUCTION.........................................................................................................................4
3 PRIMARY REQUIREMENTS....................................................................................................5
3.1 SUPPORTED DATABASES ..........................................................................................................6
3.1.1 External databases ..........................................................................................................6
3.2 MULTIPLE DATABASE SET SUPPORT .........................................................................................6
3.3 LOGGING ..................................................................................................................................7
3.4 ARCHITECTURAL CONSTRAINTS ...............................................................................................7
3.5 SERVER DATA MAINTENANCE ..................................................................................................7
3.6 EXTERNAL DATA DISTRIBUTION .............................................................................................7
3.7 SECURITY .................................................................................................................................8
3.7.1 Firewalls .........................................................................................................................9
3.7.2 Attack methods ................................................................................................................9
3.7.3 Export restrictions.........................................................................................................11
3.8 INTERNATIONALIZATION........................................................................................................11
3.9 FACTORY/DEPOT/INSTALLATION WORK F LOW .....................................................................11
4 DERIVED REQUIREMENTS ..................................................................................................13
4.1 SUPPORTED APPLICATIONS ....................................................................................................13
4.1.1 Supported interactive applications ...............................................................................13
4.1.2 Supported autonomous applications .............................................................................16
4.2 SUPPORTED DATABASES ........................................................................................................18
4.2.1 Internal databases .........................................................................................................18
4.3 COM ACCESS ....................................................................................................................2221
4.4 REQUIRED R EQUIREMENTS ................................................................................................2221
4.5 INNOVATEC LOOK AND FEEL .............................................................................................2221
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
4.6 NAVIGATION ......................................................................................................................2322
4.6.1 Keyboard ...................................................................................................................2322
4.6.1.1 Mnemonics ............................................................................................................2322
4.6.1.2 Shortcuts................................................................................................................2423
4.6.2 Mouse ........................................................................................................................2423
4.7 COMPONENTS.........................................................................................................................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 Toolbars.................................................................................................................... 26
4.7.6 Menus ............................................................................................................................26
4.7.7 Statusbar .......................................................................................................................26
4.7.8 Organizing.................................................................................................................2726
4.7.8.1 Group Boxes ..........................................................................................................2726
4.7.8.2 Tabbed Panes .........................................................................................................2726
5 CHANGE LOG ...........................................................................................................................27
1 Open Issues
•
•
What type of location information will we use (e.g., lat, long,
elevation, pole #) for gateways, relays and meters?
What tool will we adopt for network RF planning, and how will
we interface the rest of the system to it?
2 Introduction
The Enterprise Network and Internet Communications (ENICS)
system is a set of software applications that allow either utilities or
Innovatec acting as a service bureau to manage and operate an Innovatec
communications network. The functions required include the ability to
read meters, monitor network operation, install, decommission, swap
and test all elements in the communications network and handle alarms.
In addition, Innovatec must have a means of planning and laying out
communications networks, training users and demonstrating the system
to prospective customers. For development it is desirable to have some
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 database (and applications that use it) already
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 servers.
In addition, in Innovatec’s role as a service bureau, it may be
necessary to site a gateway server and possibly some server functions at
a customer site, while the rest are handled at Innovatec’s offices. For
example, a utility may want to put modems at their site so that calls to
gateways are local calls, while Innovatec administers the network
remotely.
A high level schematic for the Innovatec utility system is shown in
Figure 1. In the schematic, each of the applications is shown as if it was
a traditional monolithic program. However, the Innovatec system is
being designed and implemented as a multitier architecture in which the
user interface is a set of Java applets and HTML pages which use a set of
servants to access various services, such as database access.
Alarm Configuration
Manager
(Interactive)
Field Service
Application
(Interactive)
Meter
Reader
(Interactive)
Network
Exerciser
(Autonomous)
Network Health
Monitor
(Autonomous)
Network
Configuration
Manager
(Interactive)
Alarm Receiver
(Autonomous)
Physical Assets
Tracking
(Legacy)
Field Service
Laptop or Handheld
Field Service
Database
IP or
TCP/
irect
via d l up PPP
d ia
Billing Application
(Legacy)
Network Configuration
Database
Utility Physical
Assets Database
(Legacy)
Billing
Database
(Legacy)
Logging
Database
Network Planning
and Layout
Innovatec
Utility
Server
converter
SW/HW Compatability
Database
Gateway
Server
Alarm Configuration
Database
Network Planning
Database
Production
Network
Network
Emulator
Network
Testbed
Figure 1: High level schematic for the Innovatec utility software system
This document supplies a general organization and partitioning for
the system as well as requirements that apply to all applications. The
requirements for the various components of the system are contained in
their own requirements documents.
3 Primary Requirements
Primary requirements are those that ultimately come from the
customer or are dictated by the basic nature of the application.
1.13.1 Supported Databases
For the purposes of this specification, the databases in the system
are classified into internal and external databases. Internal databases
are those that will be built into a stand alone Innovatec system. External
(or legacy) databases are those that are supplied by a particular
Innovatec customer or a particular 3rd party application. An interface to
an external database may be supplied as part of the customization for a
particular customer, but the information contained in these databases is
not required to run the Innovatec system.
Internal databases are specified in section 4.2.1.
3.1.1 External databases
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 typically consist of the following for each utility.
Database
Billing
Physical Assets
Record Type
Basic
account
information
Meter
information
for a
customer
•
•
•
•
•
•
Data for each •
meter
•
•
•
•
•
•
•
•
•
•
•
Item
Account number
Customer name
Customer address
Account number
Meter type
Meter name
Comment
May be
multiple
records for
each
customer
Account number
Meter name
Meter type
Meter Model
Factory number
Meter brand
Meter size
Zone
Installation date
Installer
Installation time
Location
information
3.2 Multiple database set support
One of the uses of the utility server software will be Innovatec
acting as a service bureau. In order to support this type of operation, the
utility server software shall support multiple sets of independent
databases, 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
appropriate utility specification from the various applications.
3.3 Logging
It shall be possible to log events of interest into an internal
database. These events shall include, but are not limited to, message
transmissions and receptions. It shall be possible for users to configure
the number and the age of events to be maintained in the log.
All attempts by a client application to log into the ENICS system or
a remote configuration server to initially contact an ENICS configuration
server or a remote redistribution server to initially contact an ENICS
server should be logged, whether the attempt is successful or not.
3.4 Architectural constraints
It shall be possible to distribute user interface, database and
server functions over multiple machines. It shall be possible for users to
remotely access the interactive utility programs from remote desktop
computers. It shall be possible to site the WAN interface hardware 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 suffers an ungraceful shutdown.
3.6 External 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 receive data from another ENICS system. This will allow a utility
that does not actually own the 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.
It shall be possible to configure access permission for an external
utility on a meter by meter basis. It shall be possible to configure which
alarms may be distributed to or configured by an external utility on an
alarm by alarm and meter by meter basis. If an external utility has been
granted configuration permission for a particular alarm on a particular
meter, then the utility that grants that permission will no longer 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
configured by an external utility, in case the meters associated with the
external utility or the gateways associated with those meters are
physically modified, reconfigured or replaced.
Both the hosting and receiving ENICS servers shall keep track of
the number and types of data sent/received to/from the remote
distribution server for billing purposes.
3.7 Security
Security considerations for the ENICS system fall into the following
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 doesn’t want them to view)
• Auditing (leave a trail so that attempts to compromise the
system are tracked for later analysis)
The other two areas that are often of concern for browser users in
a networked environment, containment and nonrepudiation, are not of
much concern to users who may run ENICS applets or applications since
all such applets, applications and servers come from a trusted source.
Authentication is a concern in two areas. The first is that only
people authorized by the utility run the ENICS applets/applications,
such as the interactive meter reader, the field service application 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 to receive such data.
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 second is host identification. It shall be
possible for system administrators to allow access to the ENICS system
from an application/applet or a third party using the external data
distribution capability only from some designated set of hosts. Thus a
user attempting to log in using a valid password from a host that is not
in the designated set of hosts would be denied access to the system (with
an appropriate reason given). There shall be a means to indicate that
access from any host are allowed.
Authorization shall be supported by access 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 basis. Thus, a
user might be allowed full access to the interactive meter reader, but no
access to the network configuration manager. All ENICS applications
shall consult the access control list before performing any operation that
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 set of operations is not allowed for a user.
Confidentiality shall be supported through encryption of any
communication between ENICS servers (for external data distribution) or
between ENICS servers and applications/applets that involved
confidential data. If private key exchange is required (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 supported by the logging facility. All attempts to
access (i.e., log into) the system by a user or by an external agent shall
be logged, whether they are successful or not. As much data as possible
should be captured, particularly for unsuccessful logins, including the
login name and the machine name from which the login attempt is made.
1.1.13.7.1 Firewalls
It is anticipated that an ENICS system will typically operate behind
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 encouraged to defeat firewall security using HTTP tunneling or other
techniques. This implies that it will be necessary for ENICS system
administrators to explicitly allow firewall access to outside users on
specified ports. It shall be possible for an ENICS system administrator to
configure the port number(s) used to contact enics servers. This does
not imply that such configuration necessarily must be done on a server
by server basis.
1.1.23.7.2 Attack methods
The following potential attacks should be considered in the design
of the ENICS software:
• Monitoring. A cracker could monitor the data stream in an
attempt to find authorized user names and passwords. A utility
competitor could attempt to monitor the stream of meter reads
to determine which customers could be “cherry picked”.
•
•
•
•
•
•
Monitoring can be defeated through encryption of the data
stream, including any interactions in which passwords are
passed.
Password guessing, dictionary or exhaustive scan (particularly if
driven by a computer program). 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 maiden name) must be addressed by
internal utility processes.
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 employee who was a network
administrator tries to shut down the Innovatec communications
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 sources to the ENICS system.
A computer cracker attempts to gain access to the ENICS
system 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 contained in a client would have been bypassed
because a real ENICS client isn’t being used).
A computer cracker attempts to gain access to the ENICS
system by running an applet 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 internal ENICS server.
A computer cracker 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
•
alarm configuration is necessary. There is currently no effective
answer in these specifications for this form of attack. There is no
potential for harm to the source utility databases or the Innovatec
communications network, however meter data that was set up for
external data distribution could be monitored.
A computer cracker runs a program that bombards the ENICS
system with random packets or bogus login attempts. By using
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 logged, including the host name of the source of the
attempt. Care should be taken that repeated illegal access
attempt by the same source do not fill up the logging database.
This log will aid in tracking down the offending party.
3.7.3 Export restrictions
Some of the strong cryptographic algorithms 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 necessary to plug in a different set of weaker algorithms to
meet export restrictions. The software shall be structured in such a way
that it is possible to easily produce an export version that uses different
cryptographic algorithms than the regular ENICS software.
3.8 Internationalization
There are no plans to export the ENICS software to non English
speaking countries.
Internationalization of the ENICS servers,
applications or applets is not required.
3.9 Factory/Depot/Installation Work Flow
IMUs, relays and gateways are expected to follow a certain work
flow during their lifetimes, as shown in Figure 2Figure 2Figure 2.
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 channel. Gateways should have their WANs activated, if possible.
IMUs, relays and gateways should be tested via the RF and (in the case of
gateways) via the WAN interface (see Gateway Node Noninvasive Test
Procedure Specification). The tool used to perform these functions is the
Factory Commissioning and Test tool.
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
sequentially, but not associated with any specific Innovatec customer.
11
IMUs, relays and gateways are forwarded to a utility depot. At this
point they must be associated with a certain customer (for IMUs) or a
certain location and set of IMUs (for relays and gateways), the association
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, the units may be tested again using the
Field Maintenance and Diagnosis tool.
Field Service
Application
ENICS Server
IMU
(failed or
reused)
Utility
Customer
Site
Depot
Commisioning
Tool
IMU
IMU, Relay,
Gateway
Utility
Depot
Factory
Factory
Commisioning
& Test Tool
Field
Maintainence
& Diagnosis
Tool
Field
Maintainence
& Diagnosis
Tool
Relay,
Gateway
Relay,
Gateway
(failed or
reused)
Field
Maintainence
& Diagnosis
Tool
Gateway &
Relay Pole
Locations
Figure 2: IMU, Relay and Gateway work flow
Gateways and relays will move from the depot to their pole
locations. Gateways and relays are installed and tested 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 and their installation in the gateways verified using
the Field 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
Maintenance and Diagnosis tool.
While both the depot commissioning tools and the network
configuration manager modify the network configuration database, the
depot commissioning tool is limited to filling in id (e.g., IMU utility serial
number) and address fields (e.g., WAN addresses) for units that have
already been entered into the network configuration database. This
12
implies that a unit must have already been added into the system by the
network configuration manager before the depot commissioning tool can
be used to modify its data, and that a null entry for certain fields must
be allowed in the network configuration database for IMUs, relays and
gateways that are marked as not installed.
4 Derived Requirements
Derived requirements are those that are driven by the primary
requirements, but are imposed on ourselves.
1.14.1 Supported applications
For those applications whose user interfaces are implemented
using Java applets, designers/implementers should strive to keep the
applets small, and implement any heavy duty operations in the servers
rather than in the applets themselves.
1.1.14.1.1 Supported interactive applications
Interactive applications are those whose functions are primarily
driven by an explicit user request, such as a meter read or a request to
upload a database from a field service application.
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
sense, but they appear that way to end-users.
“Application”
Purpose
Field
Service Install, decommission,
Application
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.
Required server functionality
• Specify set of service orders for
a particular service person (or
service id).
• Specify what is to be done for
each service order.
• Allow
basic
IMU
communications
parameter
configuration (e.g., set the
channel number).
• Perform basic tests of meter
communication.
• Check that necessary network
setup has been completed to
allow service order function to
proceed for a given meter.
• Download service orders to
individual service laptops.
• Upload modified information
from individual service laptops
13
•
Field
Monitors RF traffic. •
Monitoring and Performs
diagnostic
Diagnosis Tool
tests of meters, relays
and gateways.
•
•
•
•
•
•
Factory
Commissioning
& Test tool
Depot
Commissioning
tool
Interactive
Meter Reader
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 interactively.
The primary users are •
and integrate it into the
databases at the utility end.
Calibrate water meters
Display all RF messages
received (should we allow for
filtering parameters?)
Invoke diagnostic tests for
IMUs, relays and gateways via
the RF interface.
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.
Generates factory log.
If the meter supports an
internal record of factory
commissioning, update that
record
once
tests
and
configuration
have
been
completed.
Isolate
customer/meter
Read meter
particular
14
utility customer service •
people.
•
Network
configuration
manager
Alarm
configuration
manager
Network
Emulator
System
administration
tool
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.
Configure which alarms
should be recognized
for specific IMUs.
•
•
Emulates an Innovatec
communications
network.
Allows the
introduction of alarms
or fault conditions (e.g.,
WAN link goes down)
interactively.
Primary
users
are
utility
trainers and Innovatec
sales people.
•
Allows
system
administrator to
view,
configure
and control the
ENICS
servers
and clients.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Event
viewer
log Allows data in the event •
log tables to be viewed.
Query meter status
Inform user when result of
operation is available.
View network logically.
Supply
data
relating
to
characteristics
of
communications path.
Supply meter and gateway
statistics and logged history.
Set up service orders
Integrate
modified
service
order data into databases.
Activate/deactivate
alarm
notification.
Specify notification method
(e.g., on screen, 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 active clients
Startup/shutdown servers and
clients
Add new hosts to ENICS
system, add or rearrange
utility
servers
in
ENICS
system.
View loading statistics.
Add or delete users.
Add
or
delete
remote
redistribution servers.
Filters events by type, date
and auxiliary characteristics
15
Network
Planning and
Layout tool
Network
Planning
Database
converter
Allows archived event
log data to be viewed.
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 bought
rather than 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 formats and views.
1.1.24.1.2 Supported autonomous applications
An autonomous application is one that runs without significant
user intervention, such as the automatic health monitor.
Application
Purpose
Required
server
functionality
Network exerciser
Test
the
network • Accepts
set
of
software and gateway
messages
and
server, in house. The
timing from a script
primary
users
are
file.
developers and testers • May be possible to
purchase this tool
rather than build it.
Network
health Determines when an • Ability to associate
monitor
element of the network
IMUs with relays
hasn’t been heard of in
and gateways.
some time.
Pings • Ability to send ping
elements
of
the
messages to the
network that may not
communications
be responding.
network.
16
•
ENICS Health Monitor
Periodically 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
malfunction
has
occurred.
Message Monitor
Moves
journaled
sent/received
messages from the
gateway server into the
logging database for
subsequent use by
other applications.
Logged Event Pruner
Deletes data from the
logging database that
is older than some
configurable maximum
age.
The data may
optionally be logged to
an external medium
such as CD-ROM or
tape,
rather
than
deleted.
Gateway Logged Event Periodically gathers up
Gatherer
the error and event
logs maintained in the
gateway nodes.
Alarm receiver
Acts when an alarm is
received.
•
Ability
to
notify
users
when
problems
are
detected.
Tells
the
alarm
receiver when a
suspicious pattern
of
activity
is
detected
or
malfunction occurs.
•
Ability to access
record
of
all
messages sent and
received.
•
Ability to do queries
and deletes on the
logging database.
•
•
Notified
when
an
internal
ENICS •
component wants to
raise an alarm.
Ability
to
cause
alarm
display
applet
to
be
updated.
Ability to cause 3rd
party devices (such
as hip pagers) to be
activated.
17
1.24.2 Supported Databases
While the general set of data present in the internal databases is
derived from the primary requirements, its partition into specific
databases is a high level architecture decision.
1.1.14.2.1 Internal databases
The utility server software shall support access to and
maintenance of the following internal databases, independently for each
utility supported. The databases referred to in this section are abstract
entities introduced for the purposes of requirements analysis and will not
necessarily be implemented as databases in the sense of an JDBC (or
other protocol) database entity. The assignment of data to specific tables
and the assignment of tables to specific databases will be done in part in
the system architecture design and in part in the utility server design.
Database
Network Configuration,
Network Planning
Record Type
Gateway
Item
•
•
•
•
•
•
•
•
Relay
•
•
•
•
Meter
•
•
•
•
•
Supported
WANs
Gateway-IMU
•
•
•
Gateway id
Gateway WAN Type
Hardware
revision
number
Software
revision
number
Operating
system
revision number
Gateway application
(gw.zip)
revision
number
Classes.zip
revision
number
Patch file contents
and revision numbers
Location information
Relay id
Relay
hardware
revision number
Relay
software
revision number
Location information
Utility Id (AKA utility
serial number, pin
number)
Meter type
Location information
Calibration Factor (for
water meters)
WAN type designation
WAN PIN number
Gateway id
Comment
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 compatibility
Use to keep
track of which
gateways,
relays
and
meter versions
are compatible
with
other
versions.
•
Alarm configuration
Alarm activity
information
•
•
•
•
Logging
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.
Keeps track of
interesting
•
•
•
•
IMU
id
that
is
registered
with
gateway
Option relay id that
IMU is registered with
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.
IMU id
Alarm type
Alarm
active
or
inactive
Time of last activation
(or should this be an
alarm history?)
IMU id
Alarm type
Notification
type
specification
Notification type
Device specific data
(e.g., PIN number for
pager,
display
device for on screen
notification)
Time event was logged
Event type
The
of
design
this
19
Authorized users
Authorized external data
distribution targets.
Extern data distribution
meter configuration table
External data distribution
target transaction log
Field Service Application
Database
events
that
happen in the
system.
This
includes but is
not restricted to
message
transmissions
and receptions.
•
Keeps track of
authorized user
names,
passwords and
authorized
hosts.
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
database is
not likely to
be
one
monolithic
table, as the
“auxiliary
information”
may be used
to
do
lookups
in
other tables.
•
•
•
•
•
•
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 name
•
Application Configuration
Database
Auxiliary information
•
•
It may make
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 through a
servant.
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.
Applications that are initiated by and run under the control of the ENICS
server environment (such as the network health monitor) do not require
access permissions. Access permissions are assigned out of the available
options on a user by user basis.
Each application has three sets of permissions. The first “set”
determines whether a user is allowed to access the ENICS server 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
deter a cracker who writes his or her own application, but it will give the
system administrator control over who can run applications under
normal circumstances.
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
communications network. The first access permission is “network use”.
This allows an application to interact with the communications network.
If it is not set, then the application is not allowed to interact with the
communications server. The second network access permission is IMU
read/modify, which determine which types 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
relays. Please note that even an application that has no explicit network
21
access may invoke an operation that will cause the ENICS server to
access the network.
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
implemented. This will allow programs to be written in Visual Basic that
can retrieve information from the ENICS system. The COM interface
shall be design in such a way that it shall not be possible to compromise
ENICS server or Innovatec network communications using the interface.
A set of standard Visual Basic applications should be implemented
for common operations such as gathering reads from a predefined group
of meters and gathering time of use information.
These standard
applications will serve to get Innovatec customer’s started 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.
1.44.5 Required Requirements
All application requirements documents shall include the following:
1. Startup
2. Shutdown
3. I/O interfaces, if any.
4. Required services.
5. Behavior in the event of errors, including but not limited to
internal program errors, communications errors, database
access errors and server access errors.
6. Mechanism for notifying users when a problem is detected (e.g.,
dialog box, logged event).
7. Which events should be logged (e.g., significant user actions).
4.54.6 Innovatec Look and Feel
4.5.14.6.1 Pluggable Look and Feel
All
enics
applications
should
implement
com.innovatec.plaf.InnovatecLookAndFeel look and feel.
the
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 are very light, labels, and text areas
will have black foreground colors. Buttons on the other hand have very
dark backgrounds, so their text will normally be white.
1.1.1.24.6.2.2 Background
Backgrounds for panels should be light and change in color and or
image with different concept area. For example if there are two panels on
one screen that represent different ideas, utility record and meter status,
they should be of different colors to make them easily distinguishable.
Since colors cannot be completely relied upon due to color
blindness, images with different subtle textures should be used as well.
Images can be added by using com.innovatec.ui.BasicPanel instead of
JPanel,
and
setting
the
image
through
BasicPanel.setBackgroundImage.
1.64.7 Navigation
4.6.14.7.1 Keyboard
In general, navigating between components follows these rules.
• Tab or Ctrl-Tab. Moves keyboard focus to the next component or to
the first member of the next group of components. Use Ctrl-Tab when
the component itself accepts tabs, as in text fields, tables, and tabbed
panes.
• Shift-Tab. Moves keyboard focus to the previous component or to the
first component in the previous group of components.
• Arrow keys. Moves keyboard focus within the individual components
of a group of components, for example, within menu items in a menu
or within radio buttons in a group of radio 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
next focusable component to a component. This can be accomplished
by JComponent.setNextFocusableComponent.
1.1.1.14.7.1.1 Mnemonics
Mnemonics are another keyboard alternative to the mouse.
Mnemonics can be used to navigate menus.
Rules of thumb for creating mnemonics:
1. If the mnemonic does not appear in the table of common
mnemonics, choose the first letter of the menu item. For instance,
choose 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
conflict with those of other menu items, choose a prominent vowel.
Mnemonics can 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.24.7.1.2 Shortcuts
All common commands should have a short cut key strokes, these
should be clearly 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 shortcut keys and their purpose:
Common Shortcut combinations include:
Ctrl-N New (File Menu)
Ctrl-O Open (File Menu)
Ctrl-S Save (File Menu)
Ctrl-P Print (File Menu)
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
1.1.24.7.2 Mouse
A user can navigate through applications with the mouse.
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 the text component in
insert mode.
1.74.8 Components
4.7.14.8.1 Primary Windows
A primary window is a window used as primary communication
with the user by the application. This is where the user will return to in
order initiate different functionality. A Primary Window shall consist of a
24
Titlebar giving the name of the application, frame, and what is being
done.
1.1.24.8.2 Secondary Windows
4.7.2.14.8.2.1 Dialogs
Dialogs are small windows used to concisely communicate with the
user.
1.1.1.24.8.2.2 Login Dialog
Prompt the user for login name and password.
Use com.innovatec.ui.LoginDialog.
1.1.34.8.3 Plain Windows
4.7.3.14.8.3.1 Splash Screens
A splash screen is a window with no standard window decorations
(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.innovatec.ui.Jsplash. The application name, version and copyright
information should appear on all splash screens.Applets
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 browser window and
should not add the confusion of creating another 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 complex applet’s frame 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 component, 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 from a button of the same
color as possible.
1.1.1.14.8.5.1 Toolbars
Icons on toolbars will match icons for buttons and or menus.
1.1.64.8.6 Menus
All commands available should also be made available by menu.
As much as possible all menus should have shortcut keys and or
mnemonic associated with them. If a menu shares functionality with a
button is should share the same label.
1.1.74.8.7 Statusbar
Small bar at the bottom used to convey information to the user.
The status bar should be used before a dialog box if at all possible. Error
26
messages should be in Red. Successful completion should be indicated
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 within group boxes should be avoided, they can become
confusing very fast and add very little to the organization of the screen.
Instead of Group boxes consider having titles for areas, labels that
extend slightly more left than the rest.
1.1.1.24.8.8.2 Tabbed Panes
Tabbed panes are the preferred method of breaking large hunks of
data that are only tied together by a process.
5 Change Log
Date
5/17/99, Revision
0.2
5/17/99, Revision
0.2
Applications/
Subsystems
Affected
Description of changes
Changed revision number to 0.2 from
0.1.92
Remove action item for 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,
0.2
Revision
6/4/99, Revision
0.2
6/4/99, Revision
0.2
6/15/99 Revision
0.2
that host identification and the risks it
presents were tolerable and the way 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 configuration database.
Added logging for remote distribution
server 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
supports 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 standard.
Changed typo in Statusbar area that
said successful messages should 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 internal database requirements.
Signoff complete
28

---

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.2
Linearized                      : Yes
Create Date                     : 2000:05:15 20:45:44
Producer                        : Acrobat Distiller 4.0 for Windows
Modify Date                     : 2000:05:15 20:45:46-04:00
Page Count                      : 28

EXIF Metadata provided by EXIF.tools