How it Works
Itron
Loading...
920

Itron 920 User Manual

Utility Network Operational Manual
Innovatec Utility Software System Organization and
Requirements
Compuware Corp.
08/09/ 99 11:13 AM
Vers i on 0.3
1
Table of Con t ents
3.1 Supported Databases ............................................................................................................................ 4
3.1.1 External databases.........................................................................................................................4
3.2 Multiple database s et supp ort..............................................................................................................4
3.3 Logging.................................................................................................................................................4
3.4 Architectural constraints ......................................................................................................................5
3.5 Server data maintenance.......................................................................................................................5
3.6 External Data Distribution...................................................................................................................5
3.7 Security.................................................................................................................................................5
3.7.1 Firewalls........................................................................................................................................6
3.7.2 Attack methods.............................................................................................................................. 6
3.7.3 Export restrictions.........................................................................................................................7
3.8 Internationalization...............................................................................................................................7
3.9 Factory/Depot/Installation Work Flow...............................................................................................7
4.1 Supported applications......................................................................................................................... 8
4.1.1 Supported interactive applications ............................................................................................... 8
4.1.2 Supported autonomous applications..........................................................................................11
4.2 Supported Databases ..........................................................................................................................11
4.2.1 Internal databases.......................................................................................................................122
4.3 COM Access.....................................................................................................................................144
4.4 Required Requirements....................................................................................................................144
4.5 Innovatec Look and Feel ..................................................................................................................155
4.5.1 Pluggable Look and Feel ..........................................................................................................155
4.5.2 Colors ..........................................................................................................................................15
4.5.2.1 Foreground/Text ..................................................................................................................15
4.5.2.2 Background ..........................................................................................................................15
4.6 Navigation.........................................................................................................................................155
4.6.1 Keyboard......................................................................................................................................15
4.6.1.1 Mnemonics.........................................................................................................................155
4.6.1.2 Shortcuts.............................................................................................................................165
4.6.2 Mouse ........................................................................................................................................166
4.7 Components......................................................................................................................................166
4.7.1 Primary Windows......................................................................................................................166
4.7.2 Secondary Windows..................................................................................................................166
4.7.2.1 Dialogs................................................................................................................................166
4.7.2.2 Login Dialog ......................................................................................................................166
4.7.3 Plain Windows ..........................................................................................................................177
4.7.3.1 Splash Screens....................................................................................................................177
4.7. 4 A spl ash sc reen s hould be impleme nted using com.innovatec.ui.Jsplash. The application name, version and copyright information should appear on all splash screens.
App lets.................................................................................................................................................177
4.7.5 Buttons.......................................................................................................................................177
4.7.5.1 Toolbars..............................................................................................................................177
4.7.6 Menus...........................................................................................................................................18
4.7.7 Statusbar ......................................................................................................................................18
4.7.8 Organizing...................................................................................................................................18
4.7.8.1 Group Boxes ........................................................................................................................18
4.7.8.2 Tabbed Panes........................................................................................................................18
5 Change Log................................................................................................................................................19
2
Open Issu es
What type of loc a tion information will we use (e. g., lat, long, elevatio n, 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?
Introduction
The Enterprise Network and Internet Communications (ENICS) system is a set of s oftware app lica tions that allow either utilities or Innovatec acting as a se rvic e bu rea u to manage and operate an Innovatec c ommunications network. The functions required include the ability to read meters, monitor network operation, install, decommission, swap and test all e le ments in the communications network and handle alarms. In addition, Innovatec must have a means of pla nning and lay ing o ut commu nica ti ons net w orks, t rai ni ng user s and d emonst ra ti ng the sy stem to prospect i ve 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 databas e s that are not part of the Innovatec syste m. 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 databas e. Finally, it should be possible to log events of interest for later analysis either by utility perso nnel or applications in the Innovatec syste m. Innovatec plans to e ventually us e the sys te m for very large installations (on the order of 10 million meters or more). Thus, it is necess ary to a rchitect a nd build the syste m in such a way that its functions can be distributed a cros s multiple machines and possibly multiple serve rs . In addition, in Innovatec’s role a s a s ervic e 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 office s . For example, a utility may want to put modems at their site so that calls to gateways are local c a lls , while Innovatec a dministers the network remotely. A high level s chematic for the Innovatec utility sys tem is s hown in Figure 1. In the schematic, each of the applications is shown as if it was a traditional
Field Service
Application
(Interactive)
Alarm Configuration
Manager
(Interactive)
Network
Configuration
Manager
(Interactive)
Meter
Reader
(Interactive)
Network
Exerciser
(Autonomous)
Network Health
Monitor
(Autonomous)
Alarm Rec eiver
(Autonomous)
monolithic program. However, the Innovatec sys tem 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. T his 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.
Field Service
Database
Field Service
Laptop or Handheld
via direct TCP/IP or
d i al u p PPP
Physical Assets
Tracking (Legacy)
Billing Ap plic ation
(Legacy)
Network Configuration
Database
Logging
Database
Network Planning
and Layout
converter
Network Planning
Database
Production
Network
Innovatec
Utility
Server
Gateway
Server
Network
Emulator
Utilit y Ph y s ical
Assets Database
(Legacy)
Alarm Configuration
Network Testbed
Billing
Database
(Legacy)
SW/HW Compata bility
Database
Database
Figure 1: High level s chematic for the Innovatec utility softw are system
3
Primary Requirements
Primary requirements are those that ultimately come from the customer or are dictate d b y the bas ic nature of the application.
Supported Databases
For the purposes of this specification, the databases in the system are classified into internal and external databases. Internal database s are those that will be built into a stand alone Innovatec syste m. External (or legacy) data ba s e s are those that are supplied by a pa rticular Innovatec customer or a particular 3
rd
party application. An interface to an external database may be supplied as pa rt 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 0.
External Databases
While it is po s s ible for the set of external databas e s to b e c omposed , in principle, of anything or nothing, we anticipate that the external databas e s will typically c onsis t of the following for each utility.
Database Record Type Item Comme nt
Billing Basic a c co unt information Account number
Customer name
Customer address Meter informatio n for a customer
Account number
Meter type
Meter name
May be multiple records for each customer
Physical Assets Data for each meter Account number
Meter name
Meter type
Meter Model
Factory number
Meter brand
Meter size
Zone
Installation date
Installer
Installation time
Location information
M ult iple Datab ase S et S upport
One of the uses of the utility server software will be Innovatec a cting as a service bureau . In order to support this type of operation, the utility server software shall support multiple sets of independent databas e s , one for each utility Innovatec s upports . It shall be the responsibility of the Innovatec Utility Server to distinguish between sets of databas e s for different utilities, given an appropriate utility spec ifica tion from the various a pplic a tions.
Logging
It shall be pos sible to log events of interest into an internal databas e . These ev ents s hall 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 a ttempts by a c lient applica tion 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.
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 co mputers. 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 a nd are generally used for network maintenance and other functions.
Server data maintenance
To the extent that is co nsiste nt with maintaining the integrity of the various d ata ba s e s , use r vis ible da ta shall not be lost if a server or server machine suffers an ungraceful shutdown.
External Data Distributi o n
In addition to interacting with an Innovatec co mmunications network, it shall be pos s ible for the ENICS system to distribute data to and/or receive data from another ENICS system. This will allow a utility that does not actua lly own the meters for a particula r cus tomer to gather data about a meter from the utility that does own the meter. T he interactions supported in this mode are limited to scheduled reads, on demand reads, informational alarms, informational alarm configuration and basic meter statu s information. Informational ala rms 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 c onfigure access permission for an external utility on a meter by meter basis . It shall be poss ible to c onfigure which alarms may be distribute d 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 bee n configured by an external utility, in case the meters as s oc ia ted 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.
Security
Security consideratio ns for the ENICS sys te m fall into the following four areas: Authentication (is the use r or utility really who he, she or it says they are) Authorization (is the user or utility allowed to pe rform the opera tion they are reques ting) Confidentiality (prevent an outside obs e rve r from viewing data that the utility doe s n’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 a uthorized by the utility run the ENICS apple ts /a pplic a tions, suc h as the interactive meter reader, the field service a pplic atio n or the network configuration manager. The sec ond is that data dis tribute d to a n 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. T he first is pa s s word authentication. All users s hall be requ ired to e nter a pas s word before using any ENICS application/applet with a user interface. Passwords shall be stored internally in a form that is cryptographically secure. The se c ond is host identification. It shall be possible for system administrators to allo w 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. T hus a us e r atte mpting to log in using a valid pass word 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.
5
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 applicatio n basis . T hus, a us e r 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. Applica tions/applets should provide a visual indication of forbidden operations (e.g., grayed out controls) if a set of ope rations is not allowed for a use r.
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 atte mpts 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 unsucce s s ful logins, including the login name and the machine name from which the login attempt is made.
Firewalls
It is anticipated that an ENICS system will typically operate be hind a firewall. The firewall is set up to d eny 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 neces s a ry 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.
Attack Methods
The following potential attacks s hould be c onsidered in the design of the ENICS software: Monitoring. A cracker could monitor the data stream in an attempt to find authorized user names and pass words. A utility competitor could atte mpt to monitor the stream of meter reads to determine which c ustomers could be “cherry picked”. Monitoring can be defeated through encryption of the data stream, including any interactions in which passwords are pass ed. Password guess ing, dictionary or exhaustive s can (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 addres s e d b y internal utility process e s . A legitimate user attempts operations that he or she is not authorized to perform. This is a ddress ed 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 pass words. Note that internal utility proces ses a re re sponsible for making sure that only correct hosts a re ide ntified as le gitimate sources to the ENICS syste m. 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 ass igning his machine the same host address a s a legitimate ENICS server. This ca n 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 app lication that claims to be a ENICS serve r that is set u p for external data distribution. T his is handled using host identification. The crack er may attempt to defea t host identification by ass igning his machine the s a me host
6
Loading...
+ 13 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use