Knowledge-based systems for transport network analysis: A fifth generation perspective on transport network problems

Tratupn. Rec.A, Vol. 24h. No. I. pp. 3-14. Primed m Great Brirnin.

0191.2607Ml S3.N + 30 C IWI Pergamon Press plc

1990

KNOWLEDGE-BASED SYSTEMS FOR TRANSPORT NETWORK ANALYSIS: A FIFTH GENERATION PERSPECTIVE ON TRANSPORT NETWORK PROBLEMS MICHAELA.P. TAYLOR Departmentof Civil Engineering, Monash University, Clayton, Victoria 3168, Australia Abstract-This paper considers the formative steps in the development of an expert system for route selection in transport networks. It discusses the application of knowledge-based system (KBS) technology to the production of an expert system to provide route guidance information for some groups of urban travellers. There is a focus on the possibilities for applying a ‘fifth generation’ programming language, such as PROLOG, to the solution of network path selection problems, and the maintenance of a dynamic network database. There are significant arguments both for and against the use of the fifth generation languages, and the alternatives are discussed in speculative terms, on the basis of trials and experiments with PROLOG. The paper develops the specifications for a route guidance KBS for urban road travel, noting that one particular concern is that of providing the most suitable advice to a given traveller, rather than the system-wide rating of ‘best’ advice. Driver attitudes, behaviour. preferences, and vehicle characteristics differ widely, and the degree of satisfaction with any advice provided would depend largely on how closely the expert system could match the preferences of the individual traveller. Thus the system would need to gauge the characteristics of the user as well as those of the network under consideration. Further, prototype route guidance KBS are probably better directed at some clearly defined groups of urban travellers, such as commercial vehicle operations, rather than as

community-wide

systems.

This paper considers the formative steps in the development of an expert system for route selection in transport networks. It first discusses the possible applications of ‘knowledge-based systems’ (KBS) in transport planning and transport operations, with particular reference to the provision of information to travellers. The paper considers the application of KBS technology to produce route guidance information for some groups of urban travellers. It then focusses on the possibilities for applying a ‘fifth generation’ programming language, such as PROLOG, to the solution of network path selection problems and the maintenance of a dynamic network database. There are significnat arguments both for and against the use of the fifth generation languages, and the alternatives are discussed in speculative terms, on the basis of trials and experiments with PROLOG. Problems involving path selection are commonly encountered in transport planning and engineering. Indeed, transport network modelling relies on the availability of efficient algorithms for computing a variety of path characteristics. Typical applications include building minimum path trees and computing matrices of interzonal travel costs, and other scheduling problems such as the ‘travelling salesman.’ Although there are well-established routines for solv&g these types of problems using the imperative languages (such as FORTRAN, BASIC, Pascal, and C), there are some conceptual advantages in tackling them with the descriptive ‘fifth generation’ languages (e.g. PROLOG or LISP). The descriptive languages

may permit a more succinct description of an algorithm, with greater efficiency in program development. New problems may also be considered, such as the determination of the exhaustive set of paths between an origin and a destination. One criticism of the descriptive languages is that programs written in them may be much slower in execution that the equivalent imperative codes. This paper suggests that some combination of descriptive language routines with computationally-intensive routines written in an imperative language may provide an effective tool for dynamic path selection and route guidance. BASIC FORlM OF A KNOWLEDGE-B,\SED SYSTEM

The KBS is one form of expert system, in which the subject knowledge is held as a set of facts and rules that may be interrogated and manipulated to provide an inferred solution or explanation for a given problem. This set of facts and rules forms the knowledge base. In the end it is the way that the software uses the knowledge base that provides the definition of a KBS. Figure 1 presents a general view of the structure of a knowledge-based system. The KE%Scombines facts and rules pertaining to a specialised topic _& a ‘knowledge base,’ and uses a set of methods for applying these rules (the ‘inference engine’) to draw conclusions about a specific problem. The inference engine is largely nonalgorithmic, depending on its purpose and configuration it may draw heavy on heuristic procedures. The inferences are based on 3

M. A. I?

4

Fig. 1. Schematic representation

TAYLOR

of a knowledge-based

the ‘problem data’ provided by the user, and these pieces of information may be incomplete, uncertain, ambiguous, or even contradictory. The knowledge base contains facts about the topic and rules from which new facts can be deduced. These rules are often of the ‘IF A THEN B’ type (or, in an uncertain or probabilistic environment, something like ‘IF A THEN B [with probability p] OR C [with probability (1 - p])‘. The rules may be taken to represent the ‘expertise’ about the topic. The assembly of this expertise from the ‘experts’ on the topic represents one of the major tasks in developing a KBS. The inference engine provides the methods for using the knowledge base. It selects those facts and rules that best suit the supplied information, connect the pieces of information and so draw conclusions. The inference engine may depend upon a decision tree, a probabilistic model, or some combination of these, to digest redundancies, contradictions, and uncertainties in the problem data. There is more in Fig. 1, however, than just the connection of the knowledge base and the inference engine. The heart of the system is a ‘user interface,’ the means of communication between the user and the program. The choice of appropriate language for the interface is of some importance. The combination of the user interface, the inference eng?;i, and the knowledge base manager is a ‘shell,’ as defined by Allwood (1988). The careful design of the user interface is important if the system is to find respect and application by its users. Of special note within

system and its components.

the user interface are two components lighted in Fig. 1. These are:

that are high-

(i) the ‘knowledge acquisition tools,’ that the KBS can use to extend its database and so learn about its special topic, and (ii) the ‘explanation facility,’ which allows the KBS to inform the user about the decision reached and the way in which the decision was obtained. This provides the means for the user to learn about the topic, and facilitate a transfer of knowledge. KNOWLEDGE-BASED

SYSTEMS

IN TRANSPORTATION

KBS are suitable for application to specific problems that are more amenable to treatment on the basis of rules and relationships rather than by numerical calculations. Further, these problems may be considered on the basis on incomplete or even conflicting information. Superficially at least, it would appear that transportation would be one area of study where KBS would be applicable. In particular, there should be many possibilities for using KBS in the processes of planning and operating transportation systems to enhance the quality of decision making. At the same time, many problems of transportation planning and management can involve the use of complex mathematical models (e.g. for transport network analysis, travel demand estimation, network capacity, and travel cost estimation). KBS

5

Transport network analysis strategies may thus need to be considered in conjunction with algorithmic models of travel behaviour and performance. There are number of reviews of the possible applications of KBS in transportation planning and engineering, for example. Takallou (198.5), Bonsall and Kirby (1986), Ritchie and Harris (1987) and Szwed (1988). A notable feature of these reviews is the relatively few operational KBS reported, especially in the areas of planning and operations. Ritchie and Harris (1987) provided a useful cross-classification of operational and demonstration expert systems by subdividing the field of transportation engineering into the following categories: planning, design, operation and control, management, maintenance, and rehabilitation. Their classification table indicates a predominance of KBS in the areas of design, management, and maintenance. In some respects this outcome is a matter of necessity. As indicated by Ritchie (1987), there are significant forces that have required an attention to existing and impending probIems in (say) pavement management, where large-scale rehabilitation and reconstruction of existing road networks is needed, and where a significant loss of human expertise is occurring through old age and retirement. The other reviews reinforce a further conclusion, that is that KBS developments in transportation have centred on the more ‘traditional’ areas of highway and traffic engineering, (e.g. in engineering design), rather than the broader, possibly multidisciplinary areas of planning and system management and control. This is despite the conclusions of the reviewers (e.g. Bonsall and Kirby, 1986; Ritchie and Harris, 1987 in particular) that these areas are suitable candidates for KBS development. Besides the first assertion that other areas have been more demanding of immediate KBS development, another possible explanation is that transportation planning and systems management require the use of algorithmic and numerical modelling techniques that may not be easily encapsulated in a KBS. It is certainly true that such techniques are highly developed for use in these areas, and that there is considerable interest in their application (e.g. Young and Taylor, 1988). However, it can also be observed that practitioners of transportation planning and management have a healthy disregard for complex computer-based models, which are seen as sometimes wasteful of resources (especially time) and as not always appropriate for many ‘bread and butter’ tasks (e.g. traffic impact assessment for site developments). This issue is discussed in Taylor (1988a). Szwed (1988) indicates the needs for small KBS that can be used for routine tasks in (say) traffic maagement and thus allow engineers to concentrate on higher level work. One common characteristic of transportation planning problems is that they often require extensive knowledge bases that need large scale numerical

operations. This is in keeping with many engineering problems, where the ultimate expert system development would comprise a system that could invoke a mathematical (simulation or optimisation) model of an engineering system to help it answer user enquiries. Although this is possible with existing software and computer languages, there are often practical problems in providing links between software modules derived from different languages. At first examination, this may mean that they are not currently amenable to KBS development given the conventional tools available. However, certain tasks are capable of treatment by alternative procedures. In particular, the type of numerical modelling needed for route guidance is capable of treatment using the descriptive programming languages (e.g. LISP or PROLOG) that are commonly suggested for use in KBS development-see, for example, Taylor (1988b). It is this possibility that provides the focus for the discussion in this paper. DESIGNING

A KNOWLEDGE-BASED

SYSTEM FOR

ROUTE GUIDANCE

An operational route guidance and advice system would be one available to all travellers (drivers) in real-time, able to provide up to date information on travel conditions downstream in the network and to suggest alternatives to drivers to avoid hazards, bottlenecks, and the like. Besides individual convenience, there are real community-wide benefits that would accrue from such a system, which would redistribute vehicle trips to make more efficient use of transport infrastructure. For example, consider Wardrop’s two principles (Wardrop, 1952)-minimum user travel time and minimum total travel time-which are often used as the basis of trip assignment modelling. The minimum user travel time principle asserts that each driver selects a route which minimises the travel time incurred by the driver, given that all drivers are attempting to satisfy the same personal objective and that there is no cooperation between drivers. In game theory terminology this is a competitive game, and its solution is a ‘Nash’ equilibrium point that leads to an overall (community) performance that is inferior to the best possible solution (Sharpe, Roy and Taylor, 1982). This ‘best’ solution is a Pareto optimum, and is represented by Wardrop’s second principle. It is an unstable solution, as it requires the complete cooperation of all travellers to maintain it, while individual travellers may gain personally by deviating from this solution. The first principle (minimum user travel time) is acknowledged as a valid simulation of urban traffic behaviour (e.g. see Taylor, 1984 amongst others). Taylor and Anderson (1984) investigated the differences in travel under the two principles, for peak period operation in the metropolitan Melbourne road network. They found that, for fixed travel demand, the system minimum

M. A. P

6

travel time objective produced a traffic flow pattern that had the same vehicle-kilometres of travel, yet had 7% less vehicle-hours of travel, used 2% less fuel and generated 3% less air pollution. The percentage differences translated into savings of about 7550 veh-h/h of travel, 7700 litres/h of fuel and 1.5 tonne/h of carbon monoxide emissions. A transport management scheme that could reconcile individual driver behavior and system-wide objectives could thus be of significant benefit. Of course, such a system still belongs to the future. It requires a comprehensive metropolitan-wide traffic information system, based on urban traffic control systems which already exist, and direct online communication links between all vehicles and a central system controller. The technology is feasible, witness the Hong Kong road pricing experiment (Pretty, 1988), but its universal acceptance and availability are not. The PROMETHEUS project in Europe is one attempt to develop such a system. A more feasible and manageable system might be directed at a subgroup of drivers, such as bus or commercial vehicle company fleets. Many of these already have two-way communication systems. Route guidance is less important for fixed-route bus operations, but is of considerable use to fleet operations that need only to visit some specified destinations or pick-up points in an area. A KBS for route guidance could reasonably be considered for fleet operations of these limited kinds, on the basis of present technology. COMPONENTS

OF A ROUTE GUIDANCE

KBS

One possible design for an urban area route guidance KBS is shown in Fig. 2. This figure is based on the general schema presented in Fig. 1. Figure 2 includes some specific details that form part of each of the general components of the intended KBS. It does not represent the full system, but rather indi-

Fig. 2. Initial design of a knowledge-based

TAYLOR

cates some of the salient features to be considered. For example, the ‘problem data’ are seen in two parts. The first is the basic trip data about origin, destination, time of day, etc. The second part is information that the system might seek about the characteristics of the traveller. In a road network with many alternatives available, the ‘best’ decision (the preferred route) largely depends on the attitudes and preferred behaviour patterns of the driver, and the characteristics of both driver and vehicle. For example, a stranger or a person unfamiliar with some part of the network to be traversed might prefer a route that kept to the main arterial roads, whilst a ‘local’ might be prepared to accept a route that deviated through the local street system. In some circumstances a driver might seek a route that offered a guaranteed (stable) travel time, whilst in other cases the driver might be prepared to risk taking a route that offered some probability of a very quick journey time, with a large variance in that time also possible. Some drivers might prefer to make turns at traffic signals, other drivers (e.g. ‘rat runners’) might wish to avoid signals and keep off the main roads. The relatively poor acceleration and deceleration characteristics of heavy commercial vehicles may mean that truck drivers seek to avoid routes with many signalised intersections if there are alternatives. even if these are longer or slower. These behaviours and characteristics, amongst many others, are known and visible amongst urban traveller populations. The success of a route guidance advice system would depend entirely upon its ability to provide sati&ctury advice to its users. Satisfaction comes from the delivery of advice that works and is acceptable to the user from the perspective of that individual. The route guidance KBS would need to determine just what this perspective was. This suggests that the ability to learn and model traveller behaviour and preferences should be an integral part of the KBS.

system for road guidance in an urban area.

Transport network analysis The knowledge

base for the KBS would need three

particular components

amongst others (see Fig. 2):

(i) rules and relationships that define the likely ‘stereotype’ of the user, and consequently the preferred or acceptable characteristics of a suggested route; (ii) rules and relationships that enable it to relate existing travel conditions (e.g. levels of congestion) to historical traffic behaviour, so that the system could extrapolate into the future to make decisions about conditions further downstream at some time in the future, and (iii) access to on-line traffic data and information systems, to define the existing network conditions. Similarly, the inference engine would need to select and evaluate alternative paths through the network for the desired journey. This process would be an integral part of the inference engine and, as discussed in the next section, this is quite feasible with existing KBS software. Route selection would depend on knowledge of existing travel conditions and estimation of anticipated future conditions over the period covered by the journey, which would be obtained from the knowledge base as indicated above. Thus the KBS would need some means of estimating spatial and temporal changes in travel demand and network congestion levels over the required time interval. Most probably these means would come from numerical models of travel demand and network performance. An example of such a model, with a suitable level of detail, is the NETCOND module in the MULATM traffic model for dense road networks (Taylor, 1988a). The system would also need a means of interrogating the traveller component of its knowledge base, given information elucidated from the user, to predict the likely characteristics and attitude set of that user and so set the desired route selection criteria. Figure 2 provides a configuration that provides for these requirements. The subsequent section of this paper considers the possibilities for the use of ‘fifth generation’ computer languages (i.e. the languages seen as most useful for the development of KBS) in solving route selection problems.

ROUTE

SELECTION

ROUTINES

IN PROLOG

Route selection is an integral part of much of transport network analysis and modelling. Most problems centre on some variation of the shortest route problem, for example minimum travel costs to all destinations from a specified origin, the minimum path tree or vine from that origin, or the minimum cost path between two specified locations in a network. There are, however, other route selection problems such as the ‘kth shortest path,’ the exhaustive set of alternative paths, the best path passing through a specified node, or the ‘travelling

7

salesman’ tour, that are often of interest in network analysis. Consideration of path selection in networks has been cited in information science as a primary example of the use of PROLOG (e.g. Clocksin and Mellish, 1984; Clark and McCabe, 1984; Smith, 1988). A resurgence of interest in route selection algorithms can be observed in the recent literature (e.g. Van Vuren and Jansen, 1988). This interest has arisen from the installation of route selection algorithms on microcomputers, where questions of computational speed and memory requirements have again surfaced as critical issues. Much of this interest focusses on the efficient manipulation of the ‘housekeeping’ chores associated with execution of the algorithm (Dial er al., 1980). This consideration is an inevitable part of the use of an ‘imperative’ programming language, such as FORTRAN, Basic, Pascal, or C. A program written in these languages consists of lists of elemental instructions on how to find a desired result. This means that the programmer must establish both the general result and the precise details and sequencing of the execution tasks before constructing the program. The program’s efficiency (‘optimising’ compilers not withstanding) largely depends on the prowess of the individual programmer. A modern alternative that may circumvent these considerations of the minutia of programming is to consider the use of a fifth generation ‘descriptive’ programming language, such as PROLOG or LISP. A descriptive language only requires the programmer to define the conditions for a solution. For example, in solving for the optimum values of variable x for a function f(x), the necessary condition for an optimum is x = x* such that the first derivative f’(x*) = 0. A programmer using an imperative language would need to explicitly define the functional form of f’(x). This would not be required in a descriptive language, where the programmer would only have to provide a definition of f’(x) and the conditions that establish an optimum value of x. The fifth generation languages are in many respects metalanguages, in that the program is written as a small set of broad statements, each broad statement may contain many elemental instructions, but the ordering and execution of these is embedded in the language itself. They are no longer the concern of the programmer. The consequence is that a descriptive language program will be very concise, with only a few statements required. This is not to say that programming in a fifth generation language leaves no room for programming expertise and creativity, for the efficiency of the program still depends on many d-ecisions that the programmer must make. For example, marshalling the recursive capabilities of PROLOG into an efficient program requires considerable experience and practice. Descriptive languages can be readily applied to the solution of route selection problems. This is easily seen by considering that the solution of a route

8

M. A. P. -Y t AYLOR

selection problem, a feasible path through the network under the specified conditions, is a set (or, in PROLOG terms, a list) of connected network elements (nodes if the problem concerns tree building, links if it concerns vine building). For example, the node to node path P,, from origin I to destination J is a set {I, i,, i,, . . i,, J} of the nodes, in sequence, that define the path. Kirby and Potts (1969) provide detailed descriptions of these definitions and formulations for a variety of path choice problems. The principal consideration in selecting P,, is that the path does not loop (i.e. no node can appear in it more than once). The route selection problem then reduces to finding the connected set of network elements that satisfies the specified conditions for the particular path choice problem. This is a task that PROLOG, for example, is well equipped for. Some simple examples are given below, as illustrations. These cover the following cases: (i) all possible node-to-node paths in and all possible paths that pass through node, for a given journey; (ii) travel costs on all available paths ified journey, and (iii) all possible link to link paths in with turn bans, for a selected journey.

a network, a specified for a speca network

The basics of the simple PROLOG programs given for these problems are some general ‘predicates’ (PROLOG meta-statements) that test for set membership or append a new element to a set: (i) the predicate member: [Xl_]).

member(X,

[_]H]) if member(X,

H)

is a recursive declaration that element X belongs to a set if the ‘head’ (first element) in the set is X, or if X belongs to some subset within the full set; (ii) the predicate append: append([ 1, B-list, B-list).

append(Tail_old,

All possible node-to-node paths

Figure 3 shows a PROLOG program that can compute all of the available routes between a specified origin-destination node pair, using the predicate go, and all of the paths (if any) that pass through a nominated node, using the predicate go-via. These are perhaps the simplest of the route selection problems. The only facts required by this program are the link connections between the nodes, that form the network (i.e. the ‘fact’link(a, b) means that there is a link from node a to node b). Note that travel in the reverse direction along a link is indicated by the ‘rule’ can-go, which has two parts. The first is that a trip can go from a to b if there is a link between the two nodes (i.e. link(a, b) exists) the second is that a trip can go from b to a if there is a link from a to b. If there were any one-way links, say described by a new type of fact one_way_link(a. b), then directional travel could be included by adding the (third) rule can_go(a, b) if one_way_link(a,

member(X,

append([X]Tail_old],

tines written in other languages (in particular TurboC, Borland’s version of C). This capability to interface with procedural codes may offer the means to combine the advantages of the descriptive language with efficient routines for performing numerical calculations. For example, the recollection of the history of the program run is an intrinsic part of the descriptive language, which is shown to best effect in the processes of recursion and back-tracking that are important ingredients in path tracing. Numerical procedures for estimating network travel times, delays, and congestion levels are needed to provide the information on which path tracing can be based.

B-list, [X]Tail_new])

if

B-list, Tail-new)

which adds the element X to an existing set (B-list) to form a new list whose first element is X. Each of the examples offers a simple TurboPROLOG program, that clearly indicates the brevity of the required source code. Turbo-P&OLO_G (Borland International, 1986) was selected because it requires a program structure and variable typing scheme that provide coherent links between other languages (e.g. Pascal) and PROLOG, that may aid in the interpretation of the programs. TurboPROLOG was designed for personal computers, can be compiled, and offers links to programs and rou-

b)

which would prevent travel from b to n in that case. The program constructs a path as an ordered set of links. It will automatically seek all of the possible paths without intervention by the user. This version does not consider the costs of travel on the network, all that is required is the existence of the links. The clauses of Fig. 3 comprise the main body of the program, the exact search and recursion methods belong inside the PROLOG language. Node-to-node path costs

The next complication in route selection is to include a link cost in the knowledge base. This is done in the program in Fig. 4, which redefines the link predicate to include a cost value. As well as finding the available paths, this program will indicate the path travel costs as well. The next step is to select the ‘best’ of these paths (e.g. the minimum travel cost path(s)). Link-to-link paths

Road traffic network modelling, especially when considered at the ‘dense network’ level (Taylor, 1988a), involves route selection that includes considerations of the relative difficulties of making left

9

Transport network analysis /*Simple Network Path Trace Finds all possible paths in a simple grid network using thru_route. Finds all possible paths passing through grid network, using vlsit_mute. l /

a specified

node, in a simple

domains node = symbol path = node’ predicates link(node,node) can-go(node,node) go(%de.node) go_via(node,node,node) thru_route(node.node.path) visit route(node.node.node,path) member(node,path) /’ The network is a_______h_______c

/* path is a list of nodes

l/

/* link between 2 nodes l / /* defmes link Uow direction /* path to be used l / /* path through a specified

node

l/

l/

!&______~____.._l I

Il

I

g_______h_______i

/

clauses link(a,d). lmk(d.g). link($). link(h.i). can-go&Y) if link(X.Y). can_go(X,Y) if link(Y,X). go(1.J) if thru_route(I,J,[I]). ~W~bj:

link(b,c). link(e,f).

link(b,e). link(e.h).

link(c,f). link(f,i).

fail.

go(_._). thru_route(I.I,Path):writefPath), nl. thru_route(I,~Dest&Path):can_go(I,J) and not(member(J.Path)) and thru route(J.Destn,[J 1Path]). go_via(I,J,KJ if visit_route(I,J,K,[I]). fail. g”-via(&?;oute(I I K,Path):/* path constrained membCr(~Pat~ j, write(Path), nl. visit_route(I,Destn,K,Path):can go(1.J) and notrmemberfJ.Path)) and visii route(J;Destn,k[J 1Path]). member(X.pl J). member(X,LIH]) if member(X,H). Fig. 3. A Turbo-PROLOG

to go through

program to find (a) all possible node-to-node (b) all possible paths through a selected node.

and right turns and through movements at junctions. In some cases certain turns may be prohibited, for example in traffic management schemes designed to increase intersection throughput and capacity. The algorithms that solve these route selection problems are known as ‘vine’ algorithms (Kirby and Potts, 1969). The vine path may be twisted and winding in a network with many turn bans, possibly passing through any one node on more than one occasiona violation of the no-looping requirement of the node-to-node (tree) algorithms discussed previously. The vine path is actually a path between links, and consists of a set of connected turns. A turn may be represented by the three nodes (i, j, k) that define it (i.e. the turn is the movement from node i thrbugT node j to node k). Thus Fig. 5 provides a PROLOG program that is the vine equivalent of the tree program of Fig. 3. The use of this program to determine the full set of possible legal paths through a complicated maze of one-way streets and many turn bans provides a useful case study application. Thus the

K */

paths

for a given

trip,

predicate turn(i, j, k) in Fig. 5 defines a permissible turning movement at node (or junction) j, from the approach leg (i, j) into the departure leg (j. k). This turn is automatically treated as a one-way movement. The predicate go(a, b, P) defines a vine path (P) through the network (i.e. a path consisting of a sequence of turning movements) from node u to node b. Figure 5 indicates that this predicate depends on the predicate vine(a, X, b, P) which determines the existence of a path from a to b that uses the link (a, X) as its first component. The vine predicate has four alternative definitions, which cover the full set of possible circumstances. These are in increasing oiaer of complexity: 1. the node a is both the origin and the destination, so that the path is trivial; 2. nodes a and b are directly connected by a link in the network, so that the path is (u,b); 3. the nodes a and b are directly connected by a

10

M. A. P. TAYLOR /’ Path cost calculator

~rv.iv.i;Savelcost for each path between a specified node = symbol path = node* cost = integer predicates link(node,node,cost) connected(node.node,cost) route(node,node,cost.pathl append(path,path.path) member(node.path) clauses link(m.s.1). link(m,b.2). hk(w,p,S). link(p,f,3).

origin node and a destination

l/

node

/* path is a list of nodes */

/* link definition has a travel cost */ /’ accounts for two-way links l / /’ oath has a cost associated with it l/

’

* link(m,p,3).

link(s.w.3).

connected(i.J.D1 if 1inkCI.J.D). connected(I,J.Dj if link(J;I;Dj. route(I,J,D,[I.Jl) if conne&d(I.J,D). /* if nodes I and J form a link in the network then the path is [I, J] and the path cost is the link cost D route(1,J.D.P) if connected(I.K,Dl) route(K,J.DZ,PZ) not(memberUP2j)

l/

and and, and

app~nd([I].F%P) &d D = Dl + D2. /* if I and J are seoarated

then this rule uses recursion io build a path wit6 cost D ‘/

append([].B 1ist.B list). append( [Head 1TaJ Old&B list.[Head append(TailIOld,BJist,Tail_New). member(X,(X[ J). member(X,LIH]) if member(X.H). Fig. 4. A Turbo-PROLOG

program

1Tail-New])

if

to find all possible node-to-node travel cost on each path.

turning movement in the network (i.e. the path comprises the two links (a, X) and (X, 6) which is written as path (n. X, b), and 4. the nodes a and b are not directly connected, and the path thus consists of a set of turning movements, written as (a, X, . . , Y, b). In this (general) case the program uses recursion to track the path between a and b. The recursion works by reducing the subpaths back to the direct turning movement connection (i.e. (3) above) under the constraint that no link (i, j) can occur more than once in a path. The predicate member for determining legitimate path membership in the node-to-node problem (Fig. 3) is replaced by an equivalent predicate reudy_in(i, j, P) for the vine. This predicate determines whether or not the network link defined by the two nodes i and j is already included in the path P. A traffic maze problem

The ‘Floyd’s Knob’ traffic maze problem described by Gardner (1962) provides an interesting case study for the application of the PROLOG vine path program defined by Fig. 5. The maze is shown in Fig. 6. This apparently simple grid road network is bedevilled by an illogical pattern of turn bans and one way streets. The only legitimate movements at any junction are those indicated by-an arrowhead on the departure leg of the junction. The basic problem is to seek a legal path from start to finish. One solution to this problem that finds a minimum distance path is to use a minimum path vine algorithm

paths

for a given trip, and the

such as that given by Kirby and Potts (1969). Given the complexity of the ‘traffic management’ system in Floyd’s Knob, the question of just how many possible solutions exist may be raised? The PROLOG program defined in Fig. 5 is able to solve this ‘exhaustive set of paths’ problem. The ‘database’ for the problem consists of the set of turn(i, j, k) predicates (facts) that define the network connectivity. Using the node labelling system shown on Fig. 6 and beginning at the node start, the first twelve facts for Floyd’s Knob are turn(start, fu, a), tum(sturt, f, g), turn(u, f, start), turn(u, b, g), turn(a, f, k), trtm(c, 6, g),

turn(b, g, I), turn(d, e, j),

turn(d, e. j), tum(e, j, i),

turn(e, d, c), turn(f, u, b),

.

There are 100 such facts in total. Insertion of these facts into the PROLOG program in Fig. 5 (in place of the existing set of facts) enables the solution of the exhaustive set of legal paths through the maze. The program found eight alternative routes that solve the problem. These fall into three groups that are defined by path length, and all paths within each group bear strong similarities. Let the distance unit of measurement be the block length. There are four minimum distance paths (of length 30 block units), shown in Fig. 7. Then there are two paths of length

11

Transport network analysis /’ Vine Trace This program fmds all paths domains node = symbol path = node* predicates go(node,node,path) vine(node,node,node.path) tum(node,node.node) already_in(node.node.path) clauses tum(a.b,c). tum(a.b,d). tum(c,e,g). tum(cM). tum(d,e,f). tum(e,d.b). tum(e,g,h). tum(f,e,d). tum(g,h.i). tum(h,f,e). tum(i,h,f). /* test network is ~~~~~~~~~~~~~.~~~.___* a b C _____*

between specified nodes in a network with turn bans l/ /’ path is a list of nodes ‘/ /’ /* /’ /’

sets required journey ‘/ defines the existence of a path defmes an allowable turn ‘1 vine-version of ‘member’ l/

tum(b.c,e). tum(c,b,a). tum(e,c,b). tum(f,h,i). turn(h,ge).

l/

tum(b.d,e). tum(d,b,a). tum(e,th). turn(g,e,c). turn(i,h,g).

l -_____* I *me_-__*

d l -------____*

I

*---_____*

e

l ____*

f

I I *__._*

l _____ h ’ g l __._______________ ’ l/

go(From,To.Path) if vine(From,Thru,To,Path). vine(From,From,From,[From]). vine(From,To,To.[From,To]) if turn(From,To._),!. vine(From,Thru,To,[From,Thru,To]) if turn(From,Thru,To),!. vine(From,Thru,To,~rom 1Pathl]) if turn(From,Thru.Via) and vine(Thru,Via,To,Pathl) and not(afready_in(From,Thru,Pathl)). /* this set of rules builds a vine path between the nodes From and To for the various alternative degrees of connection between the two nodes l/ ahe@_m(XY.[XY IJ). aheady_m(XY,LI HI) if already_in(XY,H). Fig. 5. A Turbo-PROLOG

program to find all possible node-to-node paths for a given trip in a network with turn bans.

Fig. 6.‘The Floyd’s Knob traffic maze (after Gardner, 1962).

12

M. A. P.

TAYLOR

Fig. 7. The family of minimum distance paths for the Floyd’s Knob traffic maze. (Four paths. each of length 30 units.)

32 block units (Fig. 8) and two paths of length 38 block units (Fig. 9). The paths shown in Figures 7. 8, and 9 form the exhaustive set of solutions to the traffic maze problem. The limited number of alternative paths makes this problem amenable to solution by this method. If all turns were permitted in the Floyd’s Knob network then there would be an extremely large number of solutions, and the program would be less useful as a result. However, that problem would be better solved by a node-to-node

method. This suggests that care is needed in the selection of the appropriate solution strategy for path selection problems.

CONCLUSIONS

The simple programs described above are clear evidence of the advantages of program development using a fifth generation language. They are com-

Fig. 8. The family of ‘second best’ distance paths for the Floyd’s Knob traffic maze. (Two paths. each of length 32 units.)

Transport network analysis

13

Fig. 9. The remaining set of possible solutions to the Floyd’s Knob traffic maze. (Two paths of length 38 units.)

plete, and yet brief. The elemental computing and housekeeping chores belong solely to the internal working of the particular implementation of the language, all the programmer has to do is to define the necessary conditions for the required solution. All of the above problems have been solved and implemented as computer programs written in other languages, so in that respect they are not novel. However, it is the brevity of the programs that is of particular interest, as is the observation that they can be easily written in the languages seen as most suitable for the ‘query-and-answer’ and rule-based interrogations and inferences that characterise KBS software. The ability to pass network cost information to them, for real networks with time-dependent travel conditions, needs to be investigated before fully operational versions could be considered for inclusion in a KBS of the route guidance or travel advice type described earlier in this paper. However, the systems appear feasible for future research, development, and prototyping. There are some other questions, such as the relative speeds of computation of the PROLOG programs compared to conventional programs for the same tasks, but if these routines are seen as parts of some larger KBS, then this concern is of less interest-the mechanics of the computation of an individual route are then less important than the ability to provide satisfactory advice about route selection to a user in a realistic time period. A knowledge-based system for problems of route selection and travel advice is a most exciting development, and this paper has at least demonstrated the value and feasibility of such work. It remains to expand these simple methods into a prototype of the desired system in future research. n(r)

24:1-a

REFERENCES

Allwood R. _I.(1988) Using expert systems shells for urban engineering applications. In Newton P. W., Taylor M. ‘A. P. and Sharpe R. (eds), Desktop Planning. Melbourne, Hargreen Publishing Co. Bonsall P. and Kirby H. R. (1986) The role of expert systems in transport. In Bonsall P. and Bell M. G. H. (eds). Information Technology Applications in Transport. Utrecht, VNU Science Press. Borland International (1986). Turbo PROLOG: The Natural Language of Artificial Intelligence. Owners Handbook. Scotts Valley, CA: Borland International. Clark K. L. and McCabe F. G. (1984) Micro-PROLOG: Programming in Logic. Englewood Cliffs, NJ: Prentice Hall. Clocksin W. F. and Mellish C. S. (1984) Programming in Prolog 2nd edition. New York: Springer-Verlag. Dial R. B., Glover F., Karney D., and Klingman D. (1980) Shortest path forest with topological ordering: an algorithm description in SDL. Transpn. Res.-B, 148, 343347.

Gardner M. (1962) The traffice maze in Floyd’s Knob. Scientific American 207, 134-135. Kirby R. F. and Potts, R. B. (1969) The minimum route problem for networks with turn penalties and prohibitions. Transp. Res. 3, 397-408. Pretty R. L. (1988) Road pricing: a solution for Hong Kong? Transpn. Res.-A, 22A. 319-328. Ritchie S. G. (1987) Expert systems in pavement management. Transpn. Res.-A, 21A. 145-162. Ritchie S. G. and Harris R. A. (1987) Expert systems in transportation engineering. In Maher M. L. (ed.). Expert Systems for Civil Engineers. New York: ASCE. Sharpe R., Roy J. R. and Taylor M. A. P. (1982) Optimizing urban futures. Environment and Planning, B9,209220. Smith P (1988). Expert System Development fn Prolog and Turbo-Prolog Sigma Press: Wilmslow, Cheshire. Szwed N. (1988) Expert systems in traffic management. In Hadgraft R. G. and Young W. (eds.), Knowledge-Based Systems in Civil Engineering. Monash University, Melbourne: Department of Civil Engineering.

14

M. A. P. TAYLOR

Takallou H. (1985) Knowledge-based expert systems: what’s happening in transportation engineering? ITE Journal, 55, 33-38. Taylor M. A. P. (1984) A note on using Davidson’s function in equilibrium assignment. Transpn. Res.-B 18B, 181199. Taylor M. A. P. (1988a) Computer models for traffic systerns applications. In Newton P. W., Taylor M. A. P. and Sharpe R. (eds.), Des&top Planning. Melbourne: Hargreen Publishing Co. 264-275. Taylor, M. A. P. (1988b) Floyd’s Knob revisited: a fifth generation approach to traffic network problems. In Hadgraft R. G. and Young W. (eds.), Knowledge-Based

Sysrems in Civil Engineering, Monash University: Melbourne: Department of Civil Engineering. Taylor M. A. P. and Anderson M. (1981) Energy and emissions in a metropolitan road transport system. Proceedings of the 12th Australian Road Research Conference, U, 63-78.

Board

Van Vuren T. and Jansen G. R. M. (1988) Recent developments in path finding algorithms: a review. Transpn. Planning and Tech. U, 57-71.

Wardrop J. G. (1952) Some theoretical aspects of road traffic research. Proceedings of the Institution of Civil Engineers, 1, 325-379. Young W. and Taylor M. A. P. (1988) A review of Australian traffic system design models. Transport Reviews, 8, 19-38.