Main Page | Data Structures | File List | Data Fields | Globals

ISIS - Integrated Science Instrument Server

Version 2.7

Richard Pogge, OSU Astronomy Department (
2002 December 30 (first version)


Usage: isis [-d] [-v] [-fcfgfile]

where: -d run as a daemon with no interactive keyboard interface -v print version info and exit w/o starting the server -fcfgfile means to use "cfgfile" as the server runtime configuration file instead of the default.


ISIS is a message-passing server that uses connectionless User Datagram Protocol (UDP) network sockets and RS232 serial ports to mediate interprocess communications between elements of the OSU instrument control and image acquisition system (ICIMACS). It can be run either in engineering mode with a simple command-line interface, or (more usually) as a background process.

ISIS provides runtime logging capability for all data-taking system traffic including precision time tagging. The ISIS runtime communications log provides a single point of logging for an instrument system, greatly facilitating troubleshooting by preserving the full interprocess communication history between different data-taking system elements.

Messages passed by ISIS follow the ICIMACS Messaging Protocol Version 2.5 (IMPv2.5) used by all OSU-built instruments. The details of this protocol are described in the IMPv2.5 Specification (300k PDF).

ISIS is a replacement for the older ariel/WC system we used in the past. ISIS assumes all of the basic functions of the ariel daemon and most of the functions of the old WC ("Workstation Computer") MS-DOS PC system. In 2002 we retired the last WC-based MS-DOS system and all OSU instruments since have used ISIS.

ISIS Commands

The following are the ISIS interactive commands:
  Executive Commands (keyboard-only):
    QUIT      Terminate the server session and exit
    HOSTS     Print a table of all currently known client hosts on the screen
    INFO      Display detailed server information on the screen
    HELP      List of server commands
    VERBOSE   Echo all server communications to the screen
    CONCISE   Suppress echoing of communications (opposite of VERBOSE)
    HISTORY   List recently typed commands (like Unix history)
  Communications Control:
    PING      Communications initialization request, responds with a PONG 
    PONG      Communications initialization acknowledge, no response required
    RESTART   Warm restart the server, clear runtime tables, PING fixed ports
    PORTS     lists the active tty ports
    FLUSH n   Flush tty port n of junk
    REMOVE xx Remove host xx from the client host table
    UDPPING ip port Ping the named UDP socket port
    VERSION   Return program version info
    HOST xx   Return info on a client host xx (or xx=all)
    STATUS    Return a server status message
    CONFIG    Displays current configuration with instrument info
    TIME      Report the UTC time and date as FITS-like keywords
    -LOG      Disable the server's runtime log temporarily
    +LOG      (Re)Enable the server's runtime log after -LOG
Note: while the command names are given in all caps to distinguish them, all ISIS commands are case-insensitive):

Runtime Configuration File

The runtime behavior of ISIS is setup via a runtime config file. Here is an example:

# ISIS Server Runtime Initialization File
# MODS1 LBT Observatory Left Direct Gregorian Configuration
# R. Pogge, OSU Astronomy Dept.
# 2010 June 21

# ISIS Server Info

ServerID   IS
ServerPort 6600
ServerLog  /lhome/Logs/ISIS/isis
LogDate    UTC

# List all serial ports we might use here, max 8
# Comment out any unused ports to avoid startup errors

TTYPort /dev/ttyD2
TTYPort /dev/ttyD3

# Define any preset UDP ports we wish to ping on startup or restart, max 8

# MODS1 LBT Config: 
#  M1.IE on mods1 ( port 10700
#  Caliban Agents: M1.CB and M1.CR on mods1data (
#                  ports 10601 and 10602, respectively
#  MODSENV Agent: on mods1data (.131) port 10901
#  MODS1 Dashboard on mods1 port 20801
#  LBTTCS Agent: TC on mods1, port 10801

UDPPort 10700
UDPPort 10601
UDPPort 10602
UDPPort 10901
UDPPort 10801
UDPPort 20801

# Runtime Flags


# Instrument ID (optional)

Instrument MODS1

The # character denotes comments, and appears in the first character of the line. Inline comments are not supported by this simple parser. Blank lines are ignored by the parser, and may be included in any number desired to improve the human readability of a config file.

Runtime parameters are designated by keyword/value pairs, for example:

 ServerID   IS
We adopt the convention that keywords and values are case insensitive, to remove any ambiguity.

If an unknown keyword is given in a config file, a warning message is printed but the rest of the config file continues to be read and processed. Unknown keywords are ignored.

In operational settings, a default runtime config file is provided, defined at compile time by the ISIS_CONFIG parameter in the isisserver.h header file. A user can override this default by giving the name of the desired config file on the command line.

Many runtime parameters can be changed during a session with interactive commands or via remote command interfaces like isisCmd. However, any changes made to these parameters will not be preserved for future sessions. This provides a way to safeguard a public server configuration against changes by careless users (or forgetful support staff who ignore the protocol that after tweaking a server during troubleshooting, they should stop and restart ISIS to ensure that the default startup configuration is recovered).


ISIS was built from the ground up starting from the many excellent coding examples given in Gray J.S., Interprocess Communications in Unix, 1997 (Prentice Hall), specifically example programs 10.10 and 10.13, and then it began to evolve rapidly from there. The more advanced parts of the network socket interface also made heavy use of W. Richard Stevens' excellent "Unix Network Programming, Volume 1, Network APIs: Sockets and XTI" (Prentice Hall, 2nd edition).

ISIS uses select() for I/O multiplexing. We have found that even in fairly busy instrument systems with a lot of traffic, the actual data rates for the message is small enough that on modern computers a single-threaded ISIS can keep up, even with incoming messages spaced by as little as 10us apart. Thus ISIS is kept simple and does not require multithreading.

UDP sockets were adopted because we noted that ISIS is just for message passing, and the messages in our system never exceed a few hundred bytes in length (the maximum limit is 4096 bytes including the ASCII 13 terminator character). This is well below the maximum number of bytes per packet, and so we would never be subject to problem of UDP not guaranteeing the order of packet arrival in a multi-packet datagram.

Similarly, none of the communications traffic in an ICIMACS data-taking system requires use of streams or persistent connections. In many enviroments, both lab and field deployments, a connection-less socket is preferred. The ISIS server can be made very lightweight, without the difficult parts of a multi-connection TCP server to guard against file descriptor accumulation, dangling sockets, hung connections, and so forth. Because an ICIMACS message is a datagram, using UDP sockets was the right tool for the job.

Note that individual data-taking system programs, as needed, will include TCP socket clients, for example to communicate with some telescope control systems (e.g., the BAIT protocol system based on TCP sockets at the MDM 1.3m telscope), or to interface with various internet appliances that use TCP (e.g., Comtrol DeviceMaster network serial port servers). What the different programs do not implement are TCP server functions, keeping them simple and lightweight.

The ISIS messaging system has proven fast, flexible, and very robust with tens of thousands of operational hours logged at many observatories with a variety of instruments from simple imaging cameras to a complex, multi-mechanism spectrograph like MODS.

ISIS uses the GNU readline and history utilties for the CLI when enabled.

Starting with the MODS1 testing at LBT in 2010, we rarely if ever run ISIS in interactive command mode, but instead run it as a background task via the -d runtime option.

Modification History

  2003 Jan 4 - initial testbed version [rwp/osu]
  2003 Jan 15 - first production version, deployed at CTIO [rwp/osu]
  2003 Feb 15 - post-run updates from CTIO field testing [rwp/osu]
  2003 Sept 14 - Modified extensively to generalize code and
                 introduce better timing practices [rwp/osu]
  2004 May 11 - overhauled package organization, now compiles under g++
                (not pretty at first), also introduced Doxygen markup
                for all comment blocks to bring up to our current
		documentation standard [rwp/osu]
  2009 Mar 18 - modifications for version 2.x, including daemon mode
                and cleanup of old junk we never use anymore [rwp/osu]
  2010 Apr 14 - further modifications for operation as a background
                pseudo-daemon, introducing the -d option [rwp/osu]

Generated on Tue Apr 16 17:04:08 2013 for ISIS Server by  doxygen