Besides the powerful transportation modeling capabilities offered by the EMME/2 transportation planning package [4,1], one of its main features is certainly its macro language which allows complex procedures to be automated and standardized.
EMME/2's new graphic interface program Enif [3,2] provides an even more powerful mechanism for controlling the programs from the outside. This is done using Enif's server mode, which allows external client programs to communicate with Enif via an openly specified TCP/IP protocol. Compared to EMME/2 macros, which are directly modeled after EMME/2's sequential dialogs, the client/server approach is more suitable to Enif's inherently non-sequential, event-driven operating mode. It allows arbitrary client programs to be implemented at the user level. Such a client can either be programmed to directly perform some application specific task, like e.g. implementing an interface to a web server which makes Enif generated data and graphics available on-line. Or, alternatively, it can implement a more general interface which only provides the necessary framework which can then be used, via some sort of scripting feature, to perform all kind of different tasks, without any need to write or modify the client program.
The SEnC program presented in this paper is a simple Enif client which belongs to the second category. Essentially, its goal is to read sequential Enif configuration commands from input files and feeds them to a running Enif server. This allows the SEnC program to be used as some kind of ``macro'' processor, which can be used to automate simple tasks, such as e.g. generating automatically the same standard set of graphic output for each new scenario that has been assigned, running an ``automatic'' Enif demonstration, or performing standardized performance benchmarks and/or software validation tests.
An important design goal of SEnC is that the program concentrates exclusively on interfacing with the Enif server protocol. This means that the SEnC program does not depend at all on any particular functionalities of Enif (except for the server's TCP/IP protocol, of course), nor does it make any assumptions on the type of Enif operations the user might want to control with SEnC. This ensures that a particular version of the SEnC program is not restricted to run on a particular release of Enif. So, as new functionalities are added to Enif, they may be readily accessed without the need to modify the SEnC program.
SEnC's ``ignorance'' of Enif's functionalities implies that all tasks that SEnC will perform must necessarily be defined from scratch in the input files processed by SEnC. In order to avoid having to ``reinvent the wheel'' each time SEnC is used for a new task, the input commands are usually read in two parts. First ``reusable'' header files are read in to define useful standard functionalities and bring them into an easily usable form. The file defining the actual task to be carried out is then based on the functions that are defined by the header file and are thus much shorter and easier to understand, even without in-depth knowledge of the internal workings of Enif.