9. Towards a Decision Support System: (ES/DSS) 

9.2. The concept of Bridges Expert System

9.3. Bridges Expert System Interface
9.3.1. User layer of the OOI
9.3.2. Implementation of the OOI

9.4. Expert System (ES) modules
9.4.1. Initiation of transport models
9.4.2. Templates

9.5. Expert System Software Architecture
9.5.1. Expert System Shell
9.5.2. Parsing
9.5.3. ES/DSS: Data dictionary

9.1. Objective: From an "Open System" to a "Decision Support System"

This chapter presents the development of a key Bridges tool, the software application developed to create Expert Systems (ES) for advanced transport models. The conversion of an "information and modelling" system into a "decision support system" requires intelligent intermediation between the system outputs and the end user requirements to be provided by an Expert System (ES). An ES consists on a set of tools that facilitate navigation by users through all the available system resources (databases, maps, models etc.). Bridges ES/DSS is a friendly application allowing the user to define such Expert Systems for advanced models.

For simple systems, the user interface itself may have enough expert capabilities within to make the development of an Expert System unnecessary. In the case of complex systems, however, when many advanced models are linked to it, an independent module specialised in channelling the knowledge exchange between model answers and end users' specific questions, is indispensable.

The Bridges tool to develop Expert Systems has been empowered with complementary tools such as desktop mapping, GIS and database management. Therefore, once particular Expert System for a given model has been created, it can be tested in a complete Decision Support System frame.

Three categories of possible Expert System/DSS users have been considered:

1. Expert users (modellers, program developers, consultants etc.) who have sophisticated data and models and want to make them accessible, in a controlled and limited manner to other, non-expert users.
2. Novice users that do not necessarily know all the intricacies of each and every model but want to ask specific questions within the range covered by one or more models.
3. An ES/DSS administrator, who maintains a base of models, data, templates, knowledge files and other resources which are necessary to support the questions that the ES/DSS can answer.

An Expert System is a program that behaves like an expert in some, usually narrow, domain, or application. Expert systems have to be capable of solving problems that require expert knowledge in a particular domain. They must possess that knowledge in some form.

Therefore they are also called knowledge based systems. However, not every knowledge based system can be considered to be an expert system. An expert system also has to be capable of explaining its behaviour and its decisions to the user, as human experts do. Therefore, expert systems have to have a friendly user interaction capability that will make the system's reasoning transparent to the user.

It is convenient to divide the expert system into three main modules:

1. A knowledge base
2. An inference engine
3. A user interface

A knowledge base comprises the knowledge that is specific to the domain of application, including such things as simple facts about the domain, rules that describe relations or phenomena in the domain, and possibly also methods, heuristics and ideas for solving problems in this domain. An inference engine knows how to use the knowledge in the base. A user interface caters for smooth communication between the user and the system, also providing the user with an insight into the problem-solving process carried out by the inference engine. It is helpful to view the inference engine and the interface as a module, usually called an expert system shell.

The foregoing scheme separates knowledge from algorithms that use the knowledge. This division is suitable for the following reasons: the knowledge base clearly depends on the application. On the other hand, the shell is, in principle at least, domain independent. Thus a rational way of developing expert systems for several applications consists of developing a shell that can be used universally, and then to plug in a new knowledge base for each application, or extend the existing knowledge base with more information. Of course, all the knowledge bases will have to conform to the same set of formal characteristics that is 'understood' by the shell.

The Bridges Expert System module has been developed using multiple software languages and tools. The most suitable development tool/language was selected for each one of the different sub-modules, as follows.

1. Microsoft Visual Basic 5.0. Used for development of the main Expert System program, templates, database programming, application calls, and mapping utilities.
2. Microsoft Office 97. It is the "default" environment. In particular Access 97, and Excel 97 were used for database applications and testing of small-scale models.
3. ESRI's MapObjects 1.2. MapObjects is a collection of mapping and GIS components including an ActiveX control (OCX) for development environments such as Visual Basic, Visual C++, Access, and others.
4. Amzi! Prolog 4.0 + Logic Server. The Amzi! Prolog implementation is very close to the "Edinburgh Standard" Prolog language. It was used for the development of the ES shell and its interfacing to Visual Basic.

Amzi Prolog was used, as it is fully integrated with the rest of Visual Basic code.

According to the above technical description, the objective of an ES is to become the module that will allow a user to formulate questions to the whole information and modelling system, transform them into a series of calls to transport models and databases, and present the end results either through a specific user friendly interface, or through the user's own routines.

Since the ES must also be used as an independent module, special emphasis was placed on the development of direct access to database utilities and GIS mapping functions from within the ES. Thus, such functions are either called directly when needed from the Visual Basic code, or they are available as separate tools from the ES/DSS menu (VisData for databases, and ES/DSSview for maps).

Note that since there is an infinite variety of models and data that could be used within a given open system, the ES/DSS provides the tools for automating the preparation of such menus and requests. By using the ES/DSS tools the model developer, who knows all the details of his/her model, can prepare suitable questions that an unsophisticated user may safely ask the model. This is particularly true for complex models, such as those built with VIA and MEPLAN. Typically, they involve huge amounts of data (hundreds of Megabytes, or Gigabytes), which reside in various files, require calling various sub-modules, making assumptions, and knowing which data to select for presentation under given conditions. Having the ES/DSS, the modeller, who knows what valid questions one may ask the model, can prepare a template (an ASCII file) for each one of the questions, test them out, and then submit just the necessary data with the template to the ES/DSS administrator. The ES/DSS automatically parses the templates and based on them generates simple menus containing the questions for the novice user. In cases of missing data or logic assumptions concerning the model's execution, the modeller may prepare an additional knowledge base file stating the preconditions for each assumption needed to run a model, or to select a model parameter.
For example, for a question like "What are the flows on Spata bypass, during airport construction?" the answer may be obtained through an SQL statement properly phrased in the template. The modeller knows in which tables the data are located, and under what names, knows the SQL syntax (or the simpler template syntax) so he can write a template for the question. The ES/DSS parses the template, and shows on its menu the much simpler question "What are the flows etc.". When the novice user starts the ES/DSS he may find this, as well as other related questions, grouped under the "Spata airport construction" category of models. When the question is selected, the ES/DSS fetches the results and displays them in the appropriate form (e.g., a listing, a graph, a map etc.).
ES/DSS will facilitate the following options:

1. Database utilities for querying, updating, obtaining reports etc., through an ETIS interface link;
2. Comparative answers to user questions relating to alternative scenarios/ options;
3. Establishment of expert rules to estimate missing data;
4. Initiation of transport models appropriate to the functionality requested by the user; and
5. Evaluation of model results according to multi-criteria models (e.g. Should I recommend this corridor as opposed to another?).

The ES/DSS is a combination of an Object Oriented Interface (OOI) and an expert system (ES). Options (1) and (2) can be handled directly by the OOI. Options (3), (4) and (5) can be provided through an expert system module that will "know", depending on the question, which model data to use, how to fill in data gaps and what kinds of results to display to the user. Interaction with the ES is also achieved through the OOI utilities. "Knowing" means that a knowledgeable person has prepared ahead of time the necessary template or knowledge base files, and has provided the corresponding data, so that the template(s) can be parsed and executed correctly. The facilities offered by the ES/DSS to support the above options, are explained in the following chapters of the report.

Once a set of questions has been properly set up and tested, then a "user" may go directly to the "Q&A" menu of the ES/DSS, browse through the available questions, select one, provide any additional values that may be needed (e.g., display ranges, desirable colours etc.) and get the result.

The ES/DSS has its own Interface (OOI) for communicating with its users. The OOI comprises a set of menus, forms, dialog boxes etc. which are either preset or generated at run-time to facilitate the user dialogues.
The preset part of the OOI guides the user through the standard options of calling an ES/DSS module (data dictionary, template parser, expert system etc.), or a utility (Visdata, ES/DSSview etc.).

On the other hand, certain parts of the OOI are generated based on the information contained in the templates and knowledge base files available during ES/DSS execution. It comprises menus, list boxes, input boxes, maps, graphs etc. that are generated either in order to prompt the user or to display the answers to user questions. Essentially, the ES/DSS provides a shell for generating this part of the OOI. The expert user prepares templates, defining the questions that will be included in the OOI as well as the answers that will be displayed.

Thus, the run-time OOI of the ES/DSS is actually "developed" by the expert users that prepare and test their templates and then make them available, through the ES/DSS to the novice users (simply "users").

For a given model that we want to be included in the ES/DSS, the OOI development work starts off by defining:

1. What kinds of questions a user may ask ETIS
2. What kinds of problems ETIS can solve
3. What kinds of information will be accessible
4. Which models will be used
5. Which databases can be accessed
6. Which application programs will be interfaced

The starting point of course is the existing ES/DSS interface, with the sample models, data, maps etc. that it already contains. However, using the ES/DSS facilities, an expert user can extend this interface so that it can connect to distributed databases, diverse software models, and even commercial packages. This follows an Object Oriented approach, and, at this point, it has been programmed in the ES/DSS using the ActiveX technology available through Visual Basic, Access, MapObjects and Amzi Prolog.

At the user level, there is an effort to keep these implementation details of the ES/DSS, invisible as far as possible. All systems peripheral to ETIS are made accessible through this single interface in a uniform and simple manner. For this reason we have included two important utilities in the ES/DSS program:

• The Visdata program, which provides most of the MS Access functions to the ES/DSS users, without any royalties or additional costs. In this way ES/DSS users can examine and update all kinds of database files (Access, dBase, Excel etc.) as well as files needed to run the ES/DSS models.
• The ES/DSSview program, which is a simple GIS application using ESRI's MapObjects. It also provides ES/DSS users, free of charge, with basic GIS functions for viewing various kinds of GIS files (ARC/INFO, MapInfo, shapefiles, bitmaps etc.), as well as basic editing and shapefile creation capabilities.
• The integration into Bridges/Communication System of Bridges/ES makes all other capabilities included in a system accessible from Bridges/ES.

A critical aspect of the ETIS system is that with its ability to interconnect with various databases, models etc., it becomes very complex in terms of knowing what to do and why. The user does not need to know what all the various databases and models are but only what kinds of question the system can answer. Therefore, the OOI of the ES/DSS was designed to comprise two layers:

• A higher, user oriented layer; and
• A lower, application specific layer.

The user oriented layer is the one, which is visible to the user. The application specific layer is not directly visible to the user but it comprises the tools that make models, databases, GIS utilities etc., available to the end user.

The user layer of the Object Oriented Interface enables the user to supply the necessary information for the problem at hand, and, also allows the ES/DSS to present the user with the available information, the problem formulation and the results.

The ES/DSS, through the use of hierarchical menus, boxes with grouped input, standard models etc. guides the user through a series of questions such as:

1. Do you want specific flow/socio-economic/ land use data?
2. Do you want to run a specific transport model?
3. What is the geographical area that you want to evaluate?

These are examples of the infinite number of questions that can be prepared through the ES/DSS templates and knowledge based files and presented to the user in the simple manner described above, through the user layer of the OOI.

The system applies the user choices from among the set of questions/options to build a formulation of the problem, select appropriate databases, query certain data from a given database, select the appropriate transport model and prepare the necessary input data set for running the model(s).

Also, the ES/DSS through the OOI may obtain additional information about the user's preferences in order to derive the appropriate indicators and present the results in the most suitable format, e.g., which colour, on what map, with graphs, charts, tables etc.

The user may have the option to supply information on problem parameters, e.g., transport mode and network alternatives. Alternatively, the system may find/ propose default values for certain problem parameters, e.g., transport, socio-economic, land use etc.

The user interface is menu/form driven. All model or standard query related information is grouped under a single menu path along with the necessary selection and data input boxes, command buttons etc.

Thus, the OOI serves as a graphic and textual tool for query input and result output. It is based on menus, browsers and graphers for result curves and so on, complemented by a graphical interface for presentation of geographical data.

The main task of ES/DSS is to offer a User friendly Interface where Expert or Novice users can pose questions and the ES/DSS will try to find the answers by calling Databases or Transport Models, either locally or throughout Europe via Internet Servers. Finally the ES/DSS offers a number of Viewing techniques for the interpretation of results.

1. The ES/DSS OOI is Menu Driven with linkage/GIS/ database capabilities.
2. The main concept is the Query which is expressed either through a Template or with the Visual Query Selection (menus, list boxes etc).
3. There are GIS capabilities, Zoom, Pan, Mark, Display Map, Hide Map, which can be activated in two ways: through Menu options or through a GIS palette.
4. The User must define Thematic Layer(s), Driving Variables and Properties in order to form the question.
5. The User chooses the Map to display and select Areas of Interest.
6. Thematic Layers, Driving Variables and Properties belong to Methods which are organised in Class Hierarchies.
7. A Collection of Methods is contained in a Template. Templates are saved in ASCII files.
8. When the User prepares a Template for the ES/DSS, the Template Compiler is activated. The output of the Template Compiler is specific SQL code and a Visual Path where the User may select the Answering Path that the ES/DSS will follow in order to answer the question. The Expert User may change part of the solution path by rewriting one or more methods and by applying Testing and Debugging techniques.
9. The whole Query process can be Saved so the User can call it again to modify it or just evaluate the results.
10. When the ES/DSS has the answer to the Question, the User must supply Viewing output parameters. The ES/DSS has the capability to display results through GIS palette, Excel, Access or a GIS package, such as ARC/Info.
11. The User may supply Criteria and Weights in order to apply multi-criteria evaluation to a given problem.
    

The ES comprises (or makes use of) the following modules:

• A Template parser that interprets user queries (specified by means of the OOI).
• A Query processor that executes SQL queries. It also calls the appropriate modules (e.g., ES/DSS core, transport model, database) and/or inspects the corresponding parts of the ES knowledge base.
• An ES shell that applies rules in order to determine which modules to use under given conditions or to apply realistic assumptions for missing data. The ES shell processes Rule files (or knowledge based files). A rule file is an ASCII file containing simple rules for processing of models.
• A Multi-Criteria Evaluator that combines results from the diverse sources above to be used in a multi-criteria model.

These ES/DSS modules can be called separately or in combination with each other. Thus, the first two modules are called during Template parsing and execution. The ES shell module is used specifically for processing Rule files.

The main module is the Query processor which allows the user to form queries for the Manager systems of the OOI to process. Its main task is to analyse and separate user queries into sub-queries and to pass the sub-queries to other modules. Additionally, it is able to answer some kinds of queries by itself. This holds in particular for queries which focus on items already stored in the ETIS database or that can be deduced by means of default values or the user's current assumptions. Before passing information to other modules, the Query Manager checks the consistency of data and results, keeps track of the user's current assumptions, and applies rules to attempt to provide realistic assumptions for missing data.
The ES modules (1), (2) and (4) have been developed in Visual Basic and the ES shell module (3) has been developed in Prolog, whereas all its screen I/O is passed to Visual Basic and handled by the ES/DSS's interface.

All access to the above ES/DSS functions is provided through the Object-Oriented Interface (OOI) described previously.

While transport models exist in all varieties, simple and complex, they mostly require large amounts of data and time for their preparation, calibration, testing, running, and presentation of results. Once they are set up considerable expertise is required to understand what they really do, and what answers they can safely provide to an external user. However, in order to be useful to the user community outside of the model developers group, models need customisation and careful design to control what the inexperienced user may do with them.

The ES/DSS provides a solution to the above problem, of model integration and results dissemination. By writing a set of Templates the modeller can control what kind of questions a user may safely ask his model. Also by providing the subset of data the modeller wants to distribute (ASCII files, database tables, maps etc.) he can provide a useful package for information retrieval and processing that can be highly valuable for administrators or other interested parties.

This purpose is achieved in the ES/DSS by two means:

• Preparation of Templates, one for each type of function that the modeller wants to make available to end users.
• Generation by the ES/DSS of a Query path, after parsing Templates registered in the ES/DSS database.

The process of Template preparation involves the following:

1. Selection of a data set (ASCII files, database files, GIS files) to be used along with the template.
2. Writing the Templates. For each question that a user might ask the model, a different Method is written. Methods can be organised in one or more template files. Also they are grouped for easier classification of menus and retrieval by the user.
3. Testing-debugging each method. Using the ES/DSS the modeller can run each method separately and check whether it produces the desired results.
4. Submitting the templates to the ES/DSS end user, or to a central ES/DSS administrator. The ES/DSS has the option of applying a password to restrict template use, and of locking the template source file from unauthorised use, or tampering by non-expert users.

Once a template is available to the end user, all its methods appear as entries in a list table, where the user may select which methods to register for further use. When a method is registered it is also placed automatically in a set of hierarchical menus that guide users through its execution.
From then on, a user may just browse through these menus, select a method, specify further parameters that the method may need, provide display options, and view the results. This sequence of menu selections guides the user through the valid options to final completion of his request. Each path on the menu hierarchy constitutes a Query path which is available to all ES/DSS users.

Additionally, a modeller may prepare a Rule file which contains rules for selection of models under a set of conditions, for filling data gaps, for conditional execution of program files and other options. Each rule file is considered as a knowledge base of the ES shell. It is an ASCII file that contains a set of rules written in an "IF conditions THEN action" format. It is checked-tested-debugged in a similar manner to the Template file, by the modeller. The result of processing the Rule file is that the ES/DSS may ask the user additional questions as these are encountered in the knowledge base rules.

Finally, the user may provide a Data Dictionary (DD) for all the parameters used in the above Template and Rule files. The DD is an Access database file that contains the hierarchies, names, definitions, units, default values etc. of all the parameters of the model.

The implementation of "initiating transport models" in the ES/DSS is as follows.

1. The OOI application layer handles the Template and Rule files.
2. The OOI user layer generates and processes the Query paths.
3. The ES/DSS modules (Template parser - Query processor - ES shell) are executed in sequence.
4. Depending on the output of each module the corresponding ES/DSS (Core-Model-Database-Application) Manager system is called.

Template: An ASCII file that contains a Model's Methods submitted by the Modeller. Each Method consists of reserved keywords that the ES/DSS engine tries to parse, analyse and store. It guides the ES/DSS engine on how to execute a specific method and act on the model's data.
The purpose of Templates is to give the modellers a tool that allows them to make some of their model's functions available to outside users in a controlled, yet user friendly manner.

Templates are a well known solution that has been adopted by many commercial applications such as MS Word and MS Excel. The basic idea of a Template is an ASCII file with commands, arguments and possibly some data. It is not a substitute for Macros or a Scripting language or a data file, it just "drives" the application providing definitions and orders.
As we have already mentioned, the Modeller cannot normally submit the real Model but just a set of data output results. ES/DSS can further process the data in order to produce answers to certain specific questions posed by the users. But how can the ES/DSS act on those data? What rules and restrictions must ES/DSS follow? If the Modeller were always present he/she would apply some special touches to produce good results. But now we need a "driver" that will guide ES/DSS on how to act on those data. This "driver" is the Template.

The Modeller may also submit some independent programs along with a data set. Again ES/DSS needs to know how to "call" those programs in order to activate the Model. The "driver" is again the Template.
The Template is an ASCII file that can be written in an Operating System, using any editor or word processor that supports the ASCII format. Because the file is in ASCII format it can be exchanged between heterogeneous operating systems like Windows NT, UNIX, VAX VMS etc. without the intervention of any filter. This ASCII file will be read by the ES/DSS application and parsed line by line.

Each Template file consists of one Module and one or many Methods. The Module can represent a whole Model and each Method a procedure or function of a model. The ES/DSS application supports many Modules in one Template but this is not advisable for reasons of clarity. Each Method consists of a set of predefined keywords and their arguments

The ES/DSS Core Engine is a Windows Menu-driven Application, written in Visual Basic 5.0. The back-end database is ACCESS and the linking library is DAO 3.5. ES/DSS Core Engine is also a Shell where independent programs - utilities have been incorporated.

The Administrators have the possibility of adding further independent programs into this Shell in the future.

The Modellers can have a copy of ES/DSS and test their Model Templates. So ES/DSS can serve as a workbench for Modellers where they can try many variations of Methods just by writing a simple Template file. This is much simpler than programming the execution sequence of those methods independently.

The End Users sit in front of an ES/DSS application copy and enjoys a rich set of Tools and Utilities all presented through a friendly User Interface. They can pose a question to the Expert System, search for a specific Method using keywords, browse database tables, and examine results in a digital map.

Internally, ES/DSS stores Methods in memory Objects and all of them are tied together into a Collection. Keywords of the Method are stored as a Collection inside the method-object. The combination of Object Oriented Programming and Collections gives great flexibility for Method manipulation and storage. All the actions that ES/DSS performs have been coded as Classes that can expose Methods and Properties. A Collection operates like a memory storage device, we can add and remove "elements", dynamically at run time, easily. Imagine what happens when those "elements" are Objects, which means memory structures that store other sub-elements and so on. This gives great flexibility to store and manipulate keywords and their context lines.

Reads an ASCII template file and analyses it line by line for syntactical and logical validity. Loads a new Method into memory as an object structure.
Initially the User selects a pathname for the Template file. ES/DSS reads this file from disk and tries to "parse" (i.e. analyse it line by line) the ASCII file. If a syntax or logical error occurs the Parser displays an error message and terminates.

When all Method's keywords have been analysed successfully, the Parser checks for existence of this Method in memory. If the Method does not exist in memory, Parser loads Method as a new Object into Methods Collection.

Execute one or all or a combination of Methods loaded in memory. Store Methods in a Database and execute them in the future at any time without parsing. When the Parser finishes its job, all the available Methods in Memory can be executed sequentially or can be registered into the Methods Database. One Method may call another Method and this gives great flexibility for Modellers in creating scenarios. In addition, Methods that are stored in the Database can be executed directly at any time in the future avoiding the parsing process. This can be achieved because Methods stored in the Database are locked, so end users cannot change them. This guarantees that Methods have no syntactical or logical errors.

This is an Access database with Data Dictionary Tables, Queries, Forms and Reports. Modellers should complete the Forms with all the necessary data that best describe the characteristics of their Model. There are sample data in the database that will help the Modellers understand the nature of the data that has to be supplied.

The purpose of Data Dictionary is to allow recording and updating of all the necessary parameter information that is needed in order to run an ES/DSS model.

The Data Dictionary (DD) describes in a Table format all the variables external to the module, which the ES/DSS should know about. An external variable is a variable that could be used or referred to by another module. Variables internal to a module (that the ES/DSS does not have to know about) are not described in the DD.

The Templates describe in a standardised format (combined with pseudo-code when necessary) all public functions of the module, which we call methods. A method is any function of the given module that can be called or accessed from another module. Functions internal to the module are not considered as methods (the ES/DSS does not have to know about them) and there is no need to describe them with Templates.

info@mcrit.com