This document is meant to provide answers to some frequently ask questions for client version 1.0 Beta of the CISN Display, and other recent releases. As advancements are made to the client, and software shortcomings are addressed these questions will inevitably change, and new ones will appear. For updated information please contact your organizational CISN Display support representative for the latest documentation.
System
Requirements: Before running the CISN Display you'll need a
recent JAVA Runtime Environment (JRE) 1.4.X or higher, installed on your
computer. It's available from SUN
Microsystems at http://java.com/en/index.jsp.
Select the download button for your operating system and follow the installation
procedures as outlined. Some operating systems may require “Administrative
Privileges” to execute the install-shield, or load JAVA plug-ins.
1. What operating system
will the client application run on?
The CISN
Display client software has been tested on Win98, Win2000, Win XP, Mac OS X,
Solaris UNIX 2.8 and Red Hat Linux 7.3, 9.0 operations systems, and found to be
compliant. In general Java written
software is not specific to any particular platform, but does require a
properly installed JAVA runtime environment (JRE) to function correctly. The
JRE allows different operating systems to execute the Java code, and is freely
available from Sun Microsystems at http://java.com/en/index.jsp.
2. What is the optimum
processor speed, and how much RAM is required?
It is
difficult to specify a hardware configuration for every operating system; however
we anticipate the majority of users to run the client software on PC-based
platforms. For these users, testing has shown excellent software-performance on
computers with a Pentium III, 1GHz processor or higher. Less than this recommended capacity may noticeably degrade
the CISN Display's graphics capabilities, and might also increase the lag-time in
running of other desktop applications. In every case a bigger, faster processor
will always improve performance.
One point
of little compromise is the amount of RAM required for satisfactory
performance. Java programs tend to be high-performance applications, thus
trials have shown that about 384-512 Mb of RAM seems adequate for operation of
the CISN Display along with other common desktop programs (Web browsers,
e-mail, word processors, office suites etc.). Less than this recommended amount
will likely diminish that program's performance.
Lastly, an
adequate monitor should also be used in conjunction with a reliable computer. Testing
has shown that at minimum, the monitor should display at a resolution of at
least 1024 x 768, with 16 Mb or more of video card memory.
3. What is the bandwidth
requirement?
Bandwidth
consumption of by the CISN Display should be considered nominal by any
standard. The XML messages the client receives are on average less than 1000
ASCII characters in length; this translates to a file size of 1KB or
smaller. Therefore, even a slow 28 kbps
modem should have no trouble keeping up with this traffic load. Note however that when users begin
accessing Web URLs, made available by the CISN Display, to view analytic
products such as ShakeMaps, Felt Reports, and digital waveforms; bandwidth
usage will increase since these are no longer text-string messages, but graphic
images such as JPEGs and GIFs.
4. Will I
need a separate machine? Most of our
computers already run multiple programs and are in constant use.
Since this
is a Java application there is no need use the DOS OS as with CUBE/REDI; thus
tying up the computer with one application. Therefore, a separate computer is not required
as long as recommended minimum hardware specifications are satisfied. However,
if the resources are available this should not prevent users from running the
CISN Display on a dedicated machine, as is the norm with the emergency response
applications.
5.
What type of map files are compatible with the GIS mapping tool?
The OpenMap program integrated within the CISN
Display handles many standard GIS data formats, including ESRI Shapefiles,
NIMA’s RPF, VPF, DTED and also CSV (Comma Separated Values). However, at
present the mapping engine only reads files utilizing “geo-referenced”
(Lat/Long) coordinates and not “universal transverse Mercator” (UTM) projected
vector-images. It has been discovered
that there are numerous shapefiles available on the Web in the UTM convention,
which are not compliant with OpenMap.
However, GIS specialists inform us that re-projecting a UTM referenced
layer into the lat/long coordinate system is a relatively trivial task when the
source files in are available. Additionally, OpenMap does not currently support
the viewing of 'raster' type images, such as JPEGs, TIFFs, GIFs or BMPs. The modification to allow the viewing of these
raster images is a considerable endeavor, and thus likely not to be implemented
any time soon. However, if users request it and development resources become
available, then this project may be undertaken. You can read more about OpenMap
support of file formats at: http://openmap.bbn.com/cgi-bin/faqw.py?req=show&file=faq09.001.htp.
6. What are
the network and firewall issues, and will IT Staff need to be consulted about
the requirements?
Communications between the CISN
Display client and the QuakeWatch Servers is handled by a standard Internet
connection, and the CORBA (common object request broker architecture) protocol. CORBA is a robust and reliable,
application-level protocol that is currently used in online banking applications,
telephone networks, and utilities organizations to name a few. The CISN Display’s implementation of the
CORBA protocol affords one distinct advantage over HTTP, in that is provides a
stateful connection between two nodes. This allows the client to know the
current state of its connection to the server, and display this status to the
user.
The client and server communicate
with each other via two IP addresses on ports 39977 and 39988. This fact leads
many network administrators to try and run the CISN Display service through a
Web-proxy, which filters and caches Web-pages from the Internet. However, this strategy will not work because
Web-proxies were only designed to handle HTTP traffic, and not other protocols.
Therefore, a network route that
avoids these HTTP filtering devices is necessary in all cases. In any event dynamic host configuration
protocol (DHCP), as well as Network Address Translation (NAT) are supported in
the CISN Display's communications middleware, as well as expiration of IP
addresses as long as they are renewed.
We
recognize that “Internet Security” is a top concern to many organizations, and we
are working towards addressing these issues as they arise. Now available is the relay-QuakeWatch Server (relay-QWS)
that is intended for deployment on an organization’s local networks. This relay-QWS
is meant to run behind a firewall, or on the DMZ of a private network, and act
as the messaging server for all internal clients behind the firewall. Local operators will administer the relay-QWS
service to host as many internal users as the organization deems
necessary. This addition to the software
suite will required only a single set of port openings to communicate back to a
remote, primary QWServer on the public Internet. This is in contrast to the multiple port
openings needed for each CISN Display client that would otherwise connect to
the QWServers individually. Interested
users are welcomed to download and install the software for local testing.
7. What will be the
ongoing staff requirements for maintaining the system?
Primary
day-to-day maintenance requirements will be to ensure the client is connected
to one of the available QuakeWatch Servers.
A good “Connection Status” is indicated by a green light at the
bottom-right corner of the CISN Display window.
In addition to this connection indicator, there are pop-up dialogue
boxes that alert the user if the server link is lost after numerous attempts to
reconnect, or if switching to an alternate QuakeWatch Server fails. In the
event of a lost connection, the CISN Display client will first try to
reestablish the original server connection, and after a given number of attempts
it will try to connect to an alternate server until its list of alternates has
been exhausted.
Therefore,
ensuring client connectivity to the server will likely be job-one. However, there are a number of modifiable
options: interface color settings, GIS layer imports (of organizational
inventories) and alarms thresholds configurable by the user. After initial setup of these parameters, no
additional tinkering should be necessary. Lastly, fixes to known software bugs, and
requests for enhancements to client tools/behaviors will fall under the CISN’s
purview. Thus, the CISN will provide
users with the client updates, and internal organizational staff will perform
these software upgrades as necessary.
8. What type of training
will my staff receive to understand and interpret the data coming in?
To a large extent much of the CISN Display’s look and feel will be familiar to many former CUBE/REDI users. Additionally, there are interface color options to provide users with a choice an earthquake schema similar to that of the CUBE/REDI Display, or one that resembles the “Recent Earthquake” maps publicly available on the Web. These two design considerations were purposely made to reduce the learning curve in using this new application. However, there are a number of tools that may be new to many users, and will require some basic instruction.
One new
feature is the availability of clickable URLs created after a significant event
is detected by the Seismic Network. For
these events a “dot” or an “S” appears ahead of the event information in the
right-hand "Earthquake Column".
These symbols indicate the availability of Web-based products,
associated to specific earthquake events on your CISN Display. Clicking one of the URLs, available in the in
the "Information Panel" under “Products” and "ShakeMap"
buttons, will launch a separate browser window taking the user to the Web
site. As the user views these Web-based
products and analyzes the data, the CISN Display will continue to receive
earthquake information and plot new data on its display. It’s important to remember that not all
earthquakes will generate Web-based products, as the availability of this
information is dependent on the magnitude and location of the event. These services are mostly available for
events of magnitude 3.0 or above.
Another new tool is the addition of a GIS mapping
engine. This utility not only allows
users to plot public infrastructure data, such as cities centers, urbanized
zones, interstate highways and county lines, but also the display of key assets
critical to the operational readiness of an organization. These GIS layers should be imported into the
mapping program (done through ‘Layers | Add Layers’ in the menu bar), well
before any major seismic activity, or emergency occurs. The additional GIS layers may be left
deselected, and then later activated when a significant earthquake occurs, so
that emergency managers can perform a thorough assessment of potentially damage
to facilities and lifelines.
Lastly, the production release the CISN Display will
feature comprehensive user documentation, to include this FAQ document, and
other online help pages. Eventually,
outreach efforts will include site visits by CISN member personnel to regional
emergency responders and other critical infrastructure organizations with
Emergency and 24/7 operations centers. These
visits will provide hands-on installation, configuration and operation's
instructions, and address questions specific to each organization.
9. Can you feed the CISN Display the QPager input; is it backwards compatible with CUBE formatted messages?
At present the application does not support CUBE/REDI
messages and is not backwards compatible with the QPager/Creatalink
receivers. The CISN Display only
interprets messages formatted in a new XML schema. This schema is much more verbose than the
CUBE format, and likely not supported by the bandwidth restrictions on
traditional commercial paging networks.
However, this does not preclude individuals from writing software to
convert CUBE formatted messages into the XML format, or vice versa. The XML schema and DTD files will be made
available to interested organizations who may wish to write a module to convert
one format to the other.
10. Is the server
software available and how hard is it to run?
Yes, the server software is available to critical
users, and other regional Seismic Networks that wish to mirror the QuakeWatch
service, or create a private relay-QWS machine. For other governmental agencies, and private
organizations the relay-QWS will provide nearly the same scalability as a
public QuakeWatch Server, but will require less configuration to setup. This should permit organizations outside the
seismic network community to operate an internal server and provide the service
to as many organizational users as needed.
Just like
CISN Display, the QuakeWatch software is also written in JAVA, and thus will
require a proper JRE installation on an adaquet server machine. If users are running a public QuakeWatch
server, then they will need to connect to a Quake Data Distribution Systems
(QDDS) hub to receive earthquake alerts (in the future QDDS is expected to
evolve into a more sophisticated transport layer). If they are running a relay QuakeWatch server
then the user will need to connect to an available public QuakeWatch server. Installation, setup and maintenance should
not be overly complicated for most systems administrators, and manageable in
the long-term by end-users.
11. I was off-line during
an earthquake sequence. Can I request
old or missed messages from the server?
The ability to request missed messages from the services
is an automatic behavior in the CISN Display client. This client performs this recovery whenever a
client/server connection is first initiated, and thereafter anytime the client detects
a loss of connectivity to the server, and successfully reconnects. The request of missed messages currently
extends back 72 hrs. The length of time
the client tries to reconnect to the server is a user-configurable parameter
located under ‘Tool’ > ‘Settings’ > ‘Connection’.
No. This is another automated behavior of the CISN Display client. The client will automatically reconnect to an alternate server if its connection to the primary server becomes unavailable, or telemetry is lost to that location. The servers now share a list of available QuakeWatch servers, and this list is passed on to all clients connected to the server. If a server is taken down for maintenance, or for any other reason, the client's reconnect strategy will attempt to link up to one of the other available servers on its list. It will continue trying until it finds an available QWServer, or its list become exhausted.
13. Why does the
earthquake list for the CISN Display and the old CUBE/REDI differ; don't they
use the same data source?
The two programs do use the same
data sources, but due to a number of application differences the two lists will
likely never appear identical. First,
the CISN Display list earthquake messages from outside the California-Nevada
region. In fact this is a user
configurable filter that can be narrowed, or widened, to include any geographic
region of the world. Thus, modifying
this behavior will affect the number of events you see on your display.
Secondly, the CUBE/REDI has a
M1.8 lower-magnitude threshold, meaning that only events above this magnitude
cutoff will be plotted on the screen. By
contrast the CISN Display has no lower threshold (unless the user sets one
manually), so it will display earthquakes of all magnitude sizes. This may account for many of the additional
earthquakes that appear on the CISN Display; since smaller earthquakes are more
frequent in occurrence than larger ones.
Another contributing factor to the
discrepancy between the two earthquake lists, are the differences in the
messaging and communications protocols used in the two applications. The CISN Display employs a full-featured
messaging protocol (CORBA) at the application level, which virtually assures
users will receive all transmitted earthquake messages. By contrast, CUBE/REDI supports no such strategy
to recover from data-gaps, since it protocol is purely simplex. In addition, the paging protocol (POCSAG)
used by CUBE/REDI between the client and messaging source, is vulnerable to
adverse meteorological conditions. Hence
electrical storms, rain showers, smoke from fires, and solar flare activity can
severely attenuate the signal received by a CUBE/REDI machine. This may dramatically reduce the number of
earthquakes displayed by the CUBE/REDI.