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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.