Proposed Canadian automated highway system architecture: object-oriented approach

Proposed Canadian automated highway systemarchitecture: object-oriented approach1

Qoutaiba Al-Qaysi, Said M. Easa, and Nouman Ali

Abstract: Recent advances in the fields of data communication and automated controls make the implementation ofautomated highway systems (AHSs) more possible. Currently, substantial research effort is being made on the design ofintelligent transportation system (ITS) architectures in Europe, Japan, the United States, and Canada. These architec-tures, however, have major limitations inherit in the design methodology used. Most ITS developers use a process-oriented approach for the design of the architecture that reduces its quality attributes (stability and flexibility) to futurechanges. This paper presents an approach to implement object-oriented design methodology in the Canadian intelligenttransportation system (C-ITS) architecture for AHS. It was also shown that the C-ITS architecture needs a backup com-munication system to be integrated within the C-ITS architecture. Such a backup system would aid the reliability offuture transportation systems to be developed based on this architecture. The proposed C-ITS architecture promotesflexibility, stability, and communication and, as such, should be of interest to ITS developers and researchers.

Key words: intelligent transportation systems, architecture, automated highways, object-oriented approach, backupcommunication.

Résumé : Les progrès réalisés dans le domaine des communications des données et des contrôles automatisés rendentl’implantation des systèmes d’autoroutes automatiques plus réalisable. Un effort de recherche substantiel est aujourd’huiréalisé dans la conception d’architectures de systèmes de transports intelligents (STI) en Europe, au Japon, aux États-Unis et au Canada. Ces architectures héritent cependant de limites inhérentes importantes en raison de la méthodologieutilisée. La plupart des développeurs de systèmes de transports intelligents utilisent une approche orientée sur les pro-cédés pour la conception de l’architecture, ce qui réduit ses attributs de qualité (stabilité et flexibilité) par rapport àtout changement futur. Cet article présente une approche pour implanter une méthodologie de conception orientée surl’objet dans l’architecture canadienne de systèmes de transports intelligents pour les systèmes d’autoroutes automati-ques. Il a également été démontré que l’architecture canadienne de STI requiert l’intégration d’un système de commu-nication d’urgence dans l’architecture canadienne de STI. Un tel système d’urgence aiderait à la fiabilité des systèmesde transport futurs qui seront développés selon cette architecture. L’architecture canadienne de STI proposée favorise laflexibilité, la stabilité et les communications et, comme tel, devrait intéresser les développeurs et les chercheurs en sys-tèmes de transports intelligents.

Mots clés : systèmes de transports intelligents, architecture, autoroutes automatiques, approche orientée objet,communication d’urgence.

[Traduit par la Rédaction] Al-Qaysi et al. 969

Introduction

Transport Canada has recently addressed its vision of im-plementing intelligent transportation systems (ITS) into Ca-nadian highway systems (Transport Canada 2003a, 2003b).The vision identified the goals and objectives of such imple-mentation. It was stressed that a common framework shouldbe developed to provide Canadians with safe, smart, strate-gic, and sustainable transportation systems suitable for the

21st century. The second milestone of the vision is the de-velopment of a Canadian intelligent transportation system(C-ITS) architecture. These efforts and others will help crys-tallize the development of a “2050 and beyond” Canadiantransportation system vision (Al-Qaysi 2002).

Civil engineers are among the main stockholders of the C-ITS architecture. In practice, civil engineers are involved inall ITS aspects. Specifically, (i) they are owners and opera-tors of transportation systems, especially federal and provin-

Can. J. Civ. Eng. 30: 955–969 (2003) doi: 10.1139/L03-043 © 2003 CNRC Canada

955

Received on 26 November 2002. Revision accepted 6 May 2003. Published on the NRC Research Press Web site at on25 November 2003.

Q. Al-Qaysi. Roads Department, Dubai Municipality, P.O. Box 67, Dubai, UAE.N. Ali. Department of Civil Engineering, Dalhousie University, Halifax, NS B3J 1Z1, Canada.S.M. Easa.2 Department of Civil Engineering, Ryerson University, 350 Victoria Street, Toronto, ON M5B 2K3, Canada.

Written discussion of this article is welcomed and will be received by the Editor until 30 April 2004.

1This article is one of a selection of papers published in this Special Issue on Innovations in Transportation Engineering.2Corresponding author (e-mail: [email protected]).

I:\cjce\cjce3006\L03-043.vpNovember 20, 2003 2:11:34 PM

Color profile: DisabledComposite Default screen

cial public sector agencies; (ii) they are suppliers,predominantly private sector firms involved in manufactur-ing, designing, developing, and installing ITS products andservices; (iii) they are customers, mainly private sector firmsand associations receiving ITS services for commercial pur-poses; (iv) they are researchers, primarily in Canadian uni-versities involved in the development of ITS applicationsand object-oriented C-ITS architecture; (v) they are involvedin special interest groups, advisory committees, professionalorganizations, and environmental groups; and (vi) they areprofessionals helping transfer information, through educa-tion and training, on the development of C-ITS architecture.

The transportation community in Canada recognizes thatnot only the subsystems that comprise ITS should effectivelycommunicate in a common way but also each subsystemshould have a set of assumptions that are not in conflict witheach other. By 2000, such efforts have produced the C-ITSarchitecture. However, the C-ITS architecture has major lim-itations inherent in the design methodology used. The use ofthe process-oriented (PO) approach for the design of ITSarchitecture reduces the stability and flexibility of the archi-tecture to future changes. Stability is the ability of the archi-tecture to meet present and future needs of the user,designer, and environment, and flexibility is its ability to re-spond to the demands for architecture change without majorimpacts on the architecture. Stability and flexibility are keyquality attributes that may influence the effectiveness of thearchitecture. The needs of the users, designers, and the envi-ronment will change. This raises a legitimate question: Is theC-ITS architecture stable and flexible? Is it possible to intro-duce new capability to a system developed based on the C-ITS architecture without a major impact on the architecturedocumentation and visualization?

Early research in this study concluded that the existing C-ITS architecture did not provide the full stability and flexi-bility necessary for ITS system development (Al-Qaysi et al.2001). The architecture needs a backup communication sys-tem to be integrated with it. This study presents an alterna-tive solution that will provide the ability to promote a stableand flexible architecture. The solution adopts an object-oriented (OO) approach for the documentation and visual-ization of the architecture. In the proposed architecture, anychange will affect a small number of classes that can be eas-ily integrated without noticeable effect on the rest of the ar-chitecture. It is important to visualize partial development ofan example system to illustrate clearly that the entire archi-tecture can be developed using an OO approach. The focuswas on only partial development because of the limited timeand resources available. In the example system, the analysistools included the Unified Modeling Language (UML™)and the Rational Rose® (OMG 2002; RSC 1998).

The proposed approach is characterized as follows:• Apply a well-defined OO approach (Booch 1997) to the

requirements and components of a proposed system. Thisstep encompasses the activity from need analysis andphysical class diagram to use cases and scenarios.

• Adopt UML™ to visualize the proposed system require-ments. The UML™ became the de facto industry standardfor OO software development.

• Partially develop a proposed Canadian Automated High-way System (CAHS) based on the C-ITS architecture re-

quirements to promote the stability and flexibility of theexisting system.

• Adopt and maintain close links among the C-ITS architec-ture requirements, CAHS requirements, and physicalclasses of the system to generalize the findings and expe-rience to the C-ITS architecture.The methodological framework applied throughout vari-

ous phases of this study depended mainly on techniquesassociated with the OO architecture development, calledobject-oriented analysis and design (OOAD). These tech-niques provide the tools that allow the user to visualize theproblem clearly. There is no standard analysis method fordetermining the effect of quality attributes on system archi-tecture. The lack of such a method hinders the developmentof a clear relationship between architecture stability (repre-sented by a backup communication system) and system us-ability and functionality (represented by user and functionalrequirements). Therefore, meaningful results and physicalinsight into the effect of architecture attributes are better ob-tained through modeling and visualization.

The following sections describe the characteristics of au-tomated highway systems and the existing process-orientedapproach to the C-ITS architecture development. The pro-posed object-oriented approach and its adaptability to thechanging technology are then described, followed by theconcluding remarks.

Automated highway system

It is useful to describe briefly the history and characteris-tics of the automated highway system (AHS) for which theproposed approach was developed. The AHS refers to a sys-tem that will automate vehicles (cars, buses, and trucks)operating on special lanes, where drivers totally relinquishvehicle control to on-board and infrastructure computers.Once the computer takes over, drivers can take both handsoff the steering wheel, both feet off the pedals, and both eyesoff the road. The primary goal of AHS is to improve the ca-pacity and safety of transportation systems in both urban andrural area. The AHS is expected to produce the most notice-able improvement in efficiency and safety among other ITSbundles (Easa 1999).

In the United States, AHS was a user service of the na-tional architecture developed during the Intermodal SurfaceTransportation Efficiency Act (ISTEA) period (US DOT2003). In Japan, the industry used AHS as a short versionfor an advanced cruise-assist highway system and its stagedevelopments (AHSRA 2003). Such developments includeinformation provision services (AHSi), control support ser-vices (AHSc), and automated cruise services (AHSa). In thatsense, AHS means not only the automated cruise service, butalso the general name of these systems.

In Canada, the category of services in the C-ITS architec-ture that correlates to AHS is called vehicle safety and con-trol systems (Transport Canada 2003c). The specific userservice (# 7.6) is called automated vehicle operation thatis defined in the architecture documentation as the marketpackage that enables “hands-off” operation of the vehicle onthe automated portion of the highway system. The imple-mentation requires lateral lane holding, vehicle speed andsteering control, and AHS check-in and check-out. This

© 2003 NRC Canada

956 Can. J. Civ. Eng. Vol. 30, 2003



market package currently supports a balance in intelligenceallocation between an infrastructure and the vehicle, pendingselection of a single operational concept by the AHS consor-tium. The specifications of the C-ITS architecture state that“ITS shall include an automated vehicle operation (AVO)service” and “AVO service shall be provided by an auto-mated highway system (AHS), the target level system”.Based on this broader view, the Canadian AVO service wastermed in this paper as AHS.

The United States, Europe, and Japan changed their strat-egy from a headlong drive toward the creation of AHS, in fa-vor of development that follows a more orderly, measuredsuccession of phases (AHSRA 2003). Japan has had clearervision for the present and future of its transportation system.The approach presented in this paper would help Canada tobe a part of this multilateral, multidisciplinary development,whether it is staged or headlong drive, especially since Can-ada has advanced automobile and automobile-supporting in-dustries. The AHS is used in industry as a user service andas a system, and the C-ITS architecture was developed in thepaper within these limitations.

The AHS concept was first introduced in the UnitedStates by General Motors in General Motors Futurama, dis-played at the 1940 New York Worlds Fair. The United StatesIntermodal Surface Transportation Efficiency Act (ISTEA),which was passed in 1991, called for the development of anAHS prototype. In California, the highway automation wassuccessfully demonstrated in 1997 (Bement et al. 1998). Thepartial development of the C-ITS architecture presented inthis paper was based on the AHS concept. This developmentrepresents an example of the potential that the OO approachhas in promoting the establishment of such research pro-grams in Canada.

The advantages and liabilities of a fully developed AHShave been debated for some time, despite the proven advan-tages concerning its positive impact on highway capacity, ef-ficiency, safety, adverse driving behaviour, exhaust emission,and energy consumption. The liabilities of fully developedAHS involve issues such as long-term impacts, vehicle costs,reliability, and social equity (Shaldover 1998). The Trans-portation Research Board reported the need for researchin the area of liability and communication (Bement et al.1998).

In the precursor system analysis of an AHS final report,two main concepts of integrating automated highways intothe freeway system are described: shared space and dedi-cated space concepts (Easa 1999). In the first concept, bothautomated and manual vehicles use common right-of-wayand common entrance and exit ramps. The second concept isbased on the need to build new dedicated lanes for auto-mated vehicles served by exclusive ramps (US DOT 1997).For AHS to become a leading model in the Canadian trans-portation system, it should have the ability to fulfil most ofthe requirements indicated in the documentation of the C-ITS architecture.

Existing process-oriented approach

The PO approach has been selected to provide the founda-tion for the structural development concept of C-ITS. Inprinciple, the technique is that the developers define what

the system should do before deciding how it should do it.The new system architecture specification evolved from aseries of data-flow diagrams. The concept itself is not new,beginning in the early 1960s, although it was fully acceptedonly after the publication of a paper by Stevens et al. (1974).

The PO approach starts with user need and system expec-tation. The documentation covers unsatisfied desires (userneeds), proposed solution (system concept), and its mainfeatures. The documentation of user needs is organized in ahierarchical manner. The user needs form the base of theuser requirements that are analysed to extract the process(functional) requirements. The terminator of the physical ar-chitecture and its context are developed at this stage.

The development of the C-ITS architecture starts withprocess decomposition, whose primary objectives are to(i) create hierarchical layers of processes that can be brokento a “primitive” level; (ii) construct a leveled set of data flowdiagrams using several concepts (Gane and Sarson 1979;DeMarco 1982; Yourdon 1991); and (iii) define specifica-tions for low-level process definitions and decomposition ofdiagrams to show the hierarchical structure logical level setof diagrams. Bachmann et al. (2000) showed that the logicalview should take into account requirements such as perfor-mance and system availability. It should address concurrency,distribution, and fault tolerance. The C-ITS architecture didnot clearly address these aspects. The physical architecture isthe last task in the PO approach. It represents the grouping ofprocesses into physical units, locations, and communicationpaths (Hatley and Pirbhai 1987). The grouping is then reorga-nized to form marketable units. Issues such as simplicityin system development and maintenance, localization ofchange, maximum opportunity for re- use of components,good management of variability, protection of data from ille-gal access, and better management of complexity can bebetter addressed by using an OO alternative (Jesty et al.1998).

The existing PO approach is illustrated in Fig. 1, whichshows a conceptual C-ITS architecture visualizing “0 Man-age ITS” that captures the eight main processes of the archi-tecture. Note that “Manage ITS” is the main process fromwhich all recognized processes within the C-ITS architectureare derived. The “0” is the number of the processes accord-ing to the existing C-ITS architecture. These processes com-municate with each other in addition to responding torequests from the terminators of the system. A process isvisualized with a circle and a terminator with a rectangle. Adouble-headed arrow symbolizes the communication. How-ever, for illustration purposes the figure shows only thedouble-headed arrows connecting the activity “ProvideDriver and Traveler Services. 6” with other processes, inaddition to some example terminators. In this level of visual-ization, the context of the messages shows only the origin ordestination of the message.

It is worth noting that ITS architecture models the logicaland physical structures of the system, forged by strategicand tactical design decisions applied during the develop-ment. For example, the Turbo architecture (McTrans Soft-ware Center 2003) can be an effective tool to create regionalor project architectures, maintain consistency between them,and generate a variety of architecture reports and diagrams.However, the linkage depends on the PO structure of the

© 2003 NRC Canada

Al-Qaysi et al. 957



main architecture. In the PO architecture, there is no system-atic organization of the information processed in the system.In addition, the architecture requires an enormous effort toorganize new functions and specify the information used inthem when the system is changed and (or) expanded. Fur-ther, the data are distributed everywhere, making it difficultto specify the areas of impact. This is unlike the proposedOO approach, where changes to the system architecture willbe local and will have no or minimal effect on the remainderof the system.

The C-ITS architecture is merely a high level startingpoint for the development of an ITS program by the prov-inces, regions, or other stakeholders, and it may be changedto suit the particular needs and stage of the ITS programagency. Further, as ITS programs evolve, such high level ar-chitecture is used to eventually develop architectures at theregional and project levels. Therefore, it is expected thatthese architectures, while linked back to the high levelversion, will be changed to incorporate more detail andinformation. In the current PO approach of the C-ITS archi-tecture, stability is usually incorporated via a thorough in-vestigation of stakeholders’ needs, both current and future.Flexibility is usually accommodated through periodic up-dates. Although this approach is effective if administeredproperly, it is time-consuming. It is critical that early in thedevelopment of the C-ITS architecture, the interests of allCanadian provinces are reflected and buy-in from all stake-holders is achieved (Transport Canada 2003b). The proposed

OO approach would provide more stable and flexible archi-tecture that reflects stakeholders’ wishes.

The C-ITS architecture aims to provide a vehicle for com-municating ITS to interested stakeholders and developers inCanada. To achieve this, the quality attributes of the systemarchitecture are built within the documentation and visual-ization of the architecture (Barbacci et al. 1995). The presentstudy was designed to address concerns about two quality at-tributes of the architecture (stability and flexibility) and thesolution to these concerns. The solution was achieved usingthe OO approach along with a backup communication sys-tem in the documentation and visualization of the C-ITS ar-chitecture.

Proposed object-oriented approach

The proposed CAHS architecture was partially developedusing the OO approach. The partial development is reflectedby the fact that the communication from the actors to thesystem was monitored in one direction. Only partial devel-opment was made in this study because of limited time andresources. The system requirements were considered thesame as those provided in the C-ITS documentation. In thearchitecture documentation, AVO (a user service in the C-ITS architecture) can be achieved by integrating AHS that isthe target level system for this user service. The partial de-velopment of the C-ITS architecture (i.e., CAHS) is intendedto prove that the architecture needs a backup communication

© 2003 NRC Canada

958 Can. J. Civ. Eng. Vol. 30, 2003

Fig. 1. Conceptual diagram of existing process-oriented approach of the intelligent transportation system (ITS) architecture.



system. This development depends on the logic that sinceCAHS possess most C-ITS architecture requirements, the re-sult of the analysis can be directly generalized to the C-ITSarchitecture.

Three types of analysis (scientific, documental, and vi-sual) were used to prove that stability and flexibility couldnot be maintained in the C-ITS architecture without adopt-ing an OO approach and a backup communication systemintegrated within the C-ITS architecture. Before the OO ap-proach and related analysis is presented, it is useful to de-scribe two analytical tools that support the proposed OOapproach: Rational Rose® and Unified Modeling Language.

Supporting analytical tools

Rational Rose®

Rational Rose® is a graphical software-modeling tool thatuses UML™ as a primary notation (RSC 1998). The rosemodel is a picture of the system architecture. The UML™helps describe how the system will work and generates doc-umentation to visualize the requirement. The model is usedto obtain a high-level view of the system, break down thesystem to manageable pieces, describe the system functionallogic, and trace the requirement to the various systemclasses. The management of the information and logicwithin such a complex system as CAHS requires the use ofsuch tools. The model supports two elements of the pro-posed OO approach, namely component-based developmentand controlled interactive development.

Rational Rose® creates a working environment for the im-plementation of abstraction. Abstraction uses a subset ofclasses and model elements to present the model in an easyway to comprehend and modify. It gives a chance to experi-ment with different configurations and system arrangementsto achieve the research goals. This tool allows the analyst toidentify and design related objects, map them to architec-tural components, and partition services across the rosemodel.

Many Rational Rose® features are used in the analysis,design, and iterative construction. It was a logical decisionto use in our development for• use-case analysis to capture the functionality and the com-

ponent of the system• object-oriented modeling• user configurable support for UML™• semantic checking• support for controlled interactive development• round-trip engineering• data definition language generation and integration with

data modeling tools• documentation generation• rose scripting for integration and extensibility• object linking and embedding (OLE) linking• OLE automation

Rational Rose® provides a Windows platform for our de-velopment in the following areas: model browser, in-placeediting, reduced levels of dialog boxes, and wizards for fre-quent operations.

Unified Modeling Language™The proposed OO approach was developed using UML™

to communicate the solution to various stakeholders. Thesystem was organized into building components called archi-tecture that are in response to user requirements. TheUML™ is a graphical language for specifying, visualizing,constructing, and documenting the artifacts of software sys-tems. The UML™ is an evolution from such OO methods asBooch (1997) and has its latest version published by ObjectManagement Group in 2002. The UML™ has buildingblocks and well-formed rules that made it, after the stan-dardization, the de facto visual modeling language for thesoftware and systems industry. The basic building models ofUML™ are• model elements (e.g., classes, interfaces, components, and

use cases)• core relationships (e.g., associations, generalization, and

dependencies)• diagrams (e.g., class diagrams, use-case diagrams, and se-

quence diagrams)Some computer science symbols and terminology related

to model elements and relationships (used later in this paper)are described in Tables 1 and 2.

In addition to the building blocks, other foundation con-cepts include well-formed rules, where the UML™ modeladheres to the semantic syntactic rules that are related to it.Another important aspect of UML™ is the unifying concept.For example, the classifier instant-dichotomy means anobject is an instance of a class or a class is a clarifier of anobject. Another concept that unifies modeling the system ofUML™ is the relation of modeling activities versus time.The UML™ architecture includes an interaction betweentwo organizational concepts, namely metamodel architectureand package structure.

The UML™, which supports Rational Rose®, enablescommunication of decisions that are not obvious or cannotbe abstracted from the code itself. It helps visualize impor-tant strategic and tactical characteristics of the proposed sys-tem architecture. The UML™ provides means to exploremultiple solutions, manage complexity, decrease develop-ment cost by reducing development life-cycle time, andmanage the risk of mistakes.

Scientific analysis of Canadian automated highwaysystem

The initial analysis of CAHS requirements led the re-search team to assume the list of classes shown in Table 3.This list will demonstrate the usability of the system andwill be in the upper level of class visualization. Theseclasses can be considered as the base classes for the pro-posed C-ITS architecture. Note that at this point classes 7and 11 are not shown in Table 3 (for example, class 7 willbe discussed later in modeling the backup communicationsystem). The scientific study contains both functional anduser requirements of the C-ITS architecture. Both use casesand system classes were created. The study aims to traceeach requirement to the classes that are responsible for thefunctionality of the CAHS requirements, especially back-bone communication (class 6), to demonstrate the need for abackup communication system.

© 2003 NRC Canada

Al-Qaysi et al. 959



In the scientific analysis, the following tasks were per-formed• description of user and functional requirements, called re-

quirement description (RDescription)• functional requirement number, called functional require-

ment number (FunctionalR #)• user requirement number, called user requirement number

(UserR #)• functional requirement number assigned to the use case

and called use-case number (UseC #)• description of the created class number to trace the re-

quirements to the responsible class, called class responsi-bility number (ClassR #)

• automated number created to keep track of the study andcalled the Canadian automated highway system number(CAHS #)The first four tasks were derived from the C-ITS architec-

ture. The results were documented in the CAHS require-ments and class responsibility database that helped trackvarious relations. The scientific analysis of CAHS require-ments led to tracing the requirements to its classes. Thestudy covers 689 requirements back to their responsibleclasses (Al-Qaysi 2002).

A snapshot of the CAHS database used for scientific anal-ysis is shown in Fig. 2. A backbone communication class(class 6) was created to represent the four communication

channels available in the C-ITS architecture. If this commu-nication class exists with a specific participating class, thismeans that the functionality requirement for this class can-not be achieved without communication. Within the bound-aries of the study, it was possible to trace most of therequirements to the responsible classes. The results showthat the communication class participates in the fulfillmentof most functionality requirements, thus highlighting thecritical role of communication in the CAHS architecture.One of the most important findings of this study is the needfor a backup communication system to improve system reli-ability and functionality. The scientific analysis helpedmodel and document the findings in an OOAD methodol-ogy. The need for a backup communication system was suc-cessfully illustrated. As previously mentioned, since CAHSpossesses most C-ITS architecture requirements, the findingsof the scientific analysis can be generalized back to the C-ITS architecture.

Visual analysis of Canadian automated highway systemThe purpose of this OOAD activity is to visualize the pro-

posed behaviour. This is achieved by modeling system func-tionality through the intended system use case. Thisinformation is extracted from the documentation require-ment that is provided in the CAHS documental analysis. Theuse-case relation is analyzed to form what is called the use-

© 2003 NRC Canada

960 Can. J. Civ. Eng. Vol. 30, 2003

Class name Class No. Class general description

Automated highway system 1 MTICa

Centres 2 Location of the centres subsystemsWayside 3 Location of the wayside subsystemsTravellers 4 Location of the travellers subsystemsVehicles 5 Location of the vehicles subsystemsBackbone communication 6 MTIC communicationArchived data management 8 MTIC archived dataCommercial vehicle administration 9 MTIC commercial vehicles administrationEmissions management 10 MTIC emission managementFleet and freight management 12 MTIC fleet and freight managementInformation service provider 13 MTIC information service providerMaintenance management 14 MTIC maintenance managementToll administration 15 MTIC toll administrationTraffic management 16 MTIC traffic managementTransit management 17 MTIC transit managementEmergency management 18 MTIC emergency managementCommercial vehicle check 19 MTIC commercial vehicle checkIntermodal terminal 20 MTIC intermodal terminalParking management 21 MTIC parking managementRoadway 22 MTIC roadwayToll collection 23 MTIC toll collectionPersonal information access 24 MTIC personal information accessRemote traveller support 25 MTIC remote traveller supportCommercial vehicle 26 MTIC commercial vehicleEmergency vehicle 27 MTIC emergency vehicleIntermodal container 28 MTIC intermodal containerMaintenance vehicle 29 MTIC maintenance vehicleTransit vehicle 30 MTIC transit vehicleVehicle 31 MTIC vehicle

aManage traffic information and control.

Table 1. Canadian automated highway system (CAHS) classes with general descriptions.



case model. The use-case model is defined as an out view ofthe system, and one of the first activities is to identify theactors of the system. Actors are not part of the system, butthey interact by requesting a service or by providing infor-mation to the system to fulfill another actor request.

The following steps are used in the visual analysis (thefirst three are accomplished using the OOAD technique).• Develop use-case diagrams that define the architecture

boundary, the external actors, and the services provided.• Develop sequence (interaction) diagrams that describe

how the implied objects of the system cooperate to pro-vide the services defined in the use case.

• Develop class diagrams that define the abstract elementsthat comprise the architecture of the system.

• Analyze the extent to which the backbone communicationclass participates in fulfilling the most sequenced dia-grams to obtain a successful scenario.The use-case modeling of CAHS includes context dia-

gram, main actors, use cases, physical classes initial look,and class diagram.

Context diagramThe CAHS context diagram shown in Fig. 3 provides the

developers with a better understanding of the environmentin which the system will perform its tasks. It provides theimaginary boundaries in which the developers have the au-thority to change. The two directional arrows indicate thetwo-way communication between the actor and the system,either by requesting service from the system or by partici-pating in the fulfillment of another actor request. As men-tioned previously, CAHS is partially developed using theOO approach, where the communication from the actor tothe system was monitored in only one direction because oflimited time and resources. The main objective was to provethe need for backup communication. Since CAHS possessesmost C-ITS architecture requirements, the analysis resultscan be directly generalized to the C-ITS architecture.

Main actorsThere are four categories of actors in CAHS as implied in

Fig. 3.

© 2003 NRC Canada

Al-Qaysi et al. 961

Construct Description Syntax

Association A relationship among two or more classifiers that involves connections among theirinstance

Aggregation A special form of association that specifies a whole–part relationship between theaggregate (whole) and the component part

Generalization A taxonomic relationship between a more general and a more specific elementDependency A relationship between two modeling elements, in which a change to one modeling

element (the independent element) will affect the other modeling element (thedependent element)

Realization A relationship between a specification and its implementation

Table 3. Core elements of UML™.

Construct Description Syntax

Class A description of a set of objects that share the same attributes, operations, methods, relation-ships, and semantics

Use case A sequence of transactions performed by a system in response to a triggering event initiated byan actor

Actor A stereotype of a class and can be shown with a special icon on a use-case diagram. It modelsan object outside the domain of the system itself that interacts directly with the system

Package Packages serve to partition the model of a system. They are clusters of highly related classesthat are themselves cohesive, but are loosely coupled relative to other clusters. It can capturea high-level design of the system by creating a class diagram that consists only of packages

Interface A named set of operations that characterize the behaviour of an elementComponent A modular, replacement, and significant part of a system that packages implementation and

exposes a set of interfaces

Node A run-time physical object that represents a computational resource

Constraint A semantic condition or restriction

Table 2. Core elements of UML™.



• Human actors — These are human entities that interactwith the system, such as archived data administrator, com-mercial vehicle drivers, managers, and inspectors.

• Environment actors — These are environmental entitiesthat interact with the system, such as roadway and road-way environment.

• Systems actors — These are system entities that interactwith the system, such as a department of motor vehicles,medical facility, rail operations, national meteorologicalservice provider, and custom agency.

• Other system actors — These are other system entitiesthat interact with the system, such as other traffic manage-ment, other parking, other information service provider,and other archives.In each of the above four categories, the actors that inter-

act with CAHS (by requesting a service or participating inthe fulfillment of other actors requests) were identified. Thedetails of these actors are given in Al-Qaysi (2002). As anexample, the actors related to “systems” are shown in Fig. 4.

Use casesTo describe a significant portion of the proposed system

usage, use cases are modeled. In such modeling, the systemcaptures “who does what” within the system and “for whatpurpose”. The CAHS inherited the required usability andfunctionality from the C-ITS usability and functionality de-tailed in its PO architecture. In this study, an OO vision isimplemented to develop a flexible and stable architecture.This compatibility led to generalizing the outcome of thispartial development of the C-ITS architecture. One of theobjectives of this paper is to promote the idea of having aparallel architecture with the existing efforts, to invite otherstakeholders and developers to ITS arena, such as softwareengineers.

To prepare the use-case view of CAHS, the requirementswere subject to analysis and visualization in UML™ to ex-tract the possible required capability of the system. The de-composition of CAHS use cases was done to the extentneeded to capture the limitations within the architecture.

© 2003 NRC Canada

962 Can. J. Civ. Eng. Vol. 30, 2003

Fig. 3. Object-oriented visualization of Canadian automated highway system (CAHS) context diagram in UML™.

Fig. 2. Snapshot of Canadian automated highway system (CAHS) requirements and class responsibility database for scientific analysis.



Figure 5 shows the OO visualization of the first level usecase “0 Manage CAHS” and nine second level use cases thatare drilled into the first level use case. Drilling into the sec-ond level use cases results in the third level that contains 54subuse cases. For example, Fig. 6 shows the OO visualiza-tion of the third level subuse cases related to the second

level use case “8 Manage Archive Data”. All other subusecases are presented in Al-Qaysi (2002).

Physical classes initial lookAs previously mentioned, the list of classes shown in Ta-

ble 3 was assumed for the initial analysis of CAHS require-

© 2003 NRC Canada

Al-Qaysi et al. 963

Fig. 4. Object-oriented visualization of some “systems actors” for Canadian automated highway system (CAHS) in UML™.

Fig. 5. Object-oriented visualization of use cases related to “0 Manage CAHS” in UML™.



© 2003 NRC Canada

964 Can. J. Civ. Eng. Vol. 30, 2003

Fig. 6. Object-oriented visualization of use cases related to “8 Manage Archive Data” of Canadian automated highway system (CAHS)in UML™.

Fig. 7. Object-oriented visualization of physical architecture overview of satellitic automated highway system (SAHS) in UML™ (note:without satellitic backup communication, the system corresponds to Canadian automated highway system (CAHS)).



ments. These classes can be considered as the base classesof the proposed C-ITS. The requirement analysis of CAHStargets to capture a common description of related objects.These objects have common attributes, operations, relations,and semantics. The class that represents related groupswithin CAHS was identified using the OO approach.

Class diagramThe basic visualization of CAHS classes and their rela-

tions are illustrated in Fig. 7 (excluding the satellitic backupcommunication class and with the word “satellitic” removed

from the classes that have the word “vehicle” associatedwith them). An example of CAHS scenario is captured usingthe sequence diagram illustrated in Fig. 8 (excluding thesatellitic backup communication class). Note that the back-bone communication is active and handles all communica-tions during the fulfillment of the requirement. Thissequence diagram allows the user to capture the functionalresponsibility of each class and the data required to performsuch functionality. The major finding from the visual analy-sis is that the backbone communication class is active in thefulfillment of the sequence diagram functionality. The com-

© 2003 NRC Canada

Al-Qaysi et al. 965

Fig. 8. Object-oriented visualization of sequence diagram for satellitic automated highway system (SAHS) use-case “support securityand coordination” in UML™ (note: without satellitic backup communication, the system corresponds to CAHS).



munication comes in and out of the backbone communica-tion class, and without it no functionality can be assured.This is true for almost all sequence diagrams of CAHS. Notethat the satellitic backup communication in Figs. 7 and 8 isdiscussed later.

Documental analysis of Canadian automated highwaysystem

In the documental analysis, the flow of events is capturedin the partial development of CAHS using text format. Thenumbering for this documentation is related to the numberof the processes in the C-ITS architecture. The documenta-tion captured the communication from the actors to the vari-ous classes that are needed to perform the desiredfunctionality. For each third level use case, the focus was ononly one-way communication in the documental analysis,where only the actors are communicating with the systemand subsystems. The system and subsystems will meet mostrequirements of the actors but will not directly give specificanswers to the actors.

This documental analysis is based on the requirementsthat are provided by the C-ITS architecture. For each CAHSuse case, the following features are analyzed and docu-mented.• Characteristic information — This defines information

that pertains to the particular use case. Each piece ofinformation is important in understanding the purpose be-hind the use case.

• Main success scenario — This scenario describes thesteps that are taken from a trigger event to goal comple-tion when everything works without failure. It also de-scribes any required cleanup that is done after the goal hasbeen reached.

• Scenario extensions — This is a listing of how each stepin the main success scenario can be extended. The exten-sions are followed until either the main success scenario isrejoined or the failed end condition is met. The step refersto the failed step in the main success scenario and has aletter associated with it. For example, if the main successstep is three, the scenario extension will be 3a.

• Related information — The documentation may cover ad-ditional information related to the use case.

• Open issues — The documentation may provide insightinto unresolved questions. These are the items that seemto apply but could not be fit into the use case at this stageof development. In CAHS, the open issue is the failure ofthe backbone communication system. The CAHS partialdevelopment in this study proves that a communication

problem will occur if current C-ITS architecture is imple-mented.Examples of the documentation of the characteristics in-

formation and main success scenario for CAHS use-case4A.4 “support security and coordination” are shown in Ta-bles 4 and 5, respectively. All other 9 (first level) use casesand 54 (second level) use cases are presented in Al-Qaysi(2002). To illustrate, the main success scenario for step twoin Table 5 is to exchange the message “4.4.1.2 Manage Tran-sit Emergencies” from class 33 to class 6 (backbone commu-nication). If class 6 fails, a scenario extension step 2a ismodeled, in which the sequence of events will be in the di-rection of switching to the conventional vehicle–highwaysystem.

In the documental analysis, the extent to which the back-bone communication class participates in fulfilling a use-case successful scenario is monitored. Documentation ofalmost all CAHS use cases shows that the backbone commu-nication class is an essential participant in obtaining a suc-cessful scenario.

Adaptability to technology changes

The developers of the C-ITS architecture have attemptedto make it technologically natural (for example, the architec-ture specifies only the required data but does not specifyhow particular data elements could be collected.). However,the technology plays an important role in the attributes ofdata and functions within the architecture. Consider an actorthat may request a service of another actor. These interac-tions of the actor are accomplished using data and functionswhose attributes may depend on technology. For example, adata transfer rate from one device to another (often mea-sured in megabits or megabytes per second) is an attributethat may depend on the technology used to collect the data.Clearly, the technology affects the attributes of data andfunctions that are encapsulated in classes and form an inher-itance within the architecture.

One of the advantages of the proposed object-oriented C-ITS architecture is its ability to meet the needs of the userand the developer as time and technology change. The OOapproach allows the developer to make changes to one ormore elements of the architecture with no or little effect onthe remaining elements. To illustrate, consider the additionof a satellitic backup communication (class 7) to the CAHSphysical architecture class diagram. This backup communi-cation class represents the satellitic backup for the four-communication channels available in the C-ITS architecture,

© 2003 NRC Canada

966 Can. J. Civ. Eng. Vol. 30, 2003

Goal in context Support security and coordination

Scope CAHSLevel StrategicPrecondition System is ON and the backbone communication

system is functioningSuccess end condition Security is coordinated and supportedFailed end condition Security is not coordinated and supportedPrimary actor 32, 33, and 34Trigger event System clock

Table 4. Characteristics information pertaining to Canadian automated highway system(CAHS) use-case 4A.4: Support security and coordination.



where the backbone communication class is in its generalform.

This backup communication class can be added to theproposed CAHS architecture with no or minimal effect onthe rest of the physical architecture, as shown in Fig. 7. Thisfigure shows the object-oriented visualization of the physicalarchitecture class diagram in UML™, with the satelliticbackup communication system added to administer commer-cial vehicles. Note that the word “satellitic” is added to allsubsystems containing the word “vehicle” and the entire sys-tem is now called satellitic automated highway system(SAHS) instead of CAHS. The purpose of SAHS partial de-velopment is to prove that our solution for backup communi-cation is adequate and the OO-based architecture providesstability and flexibility.

In SAHS partial development, note that there are now twoclasses that will fulfil the communication aspects of thearchitecture, namely the backbone communication and thesatellitic backup communication. The latter will handle thecommunication if the former malfunctions. The SAHS archi-tecture has five backup communication requirements(i) monitor backbone communication system at all times,(ii) take over if and when malfunction occurs in the back-bone communication, (iii) direct communication to the sate-llitic backup wireless communication system when amalfunction occurs in the backbone communication,(iv) continue monitoring all communication channels if andwhen the backbone system regains its functionality shoulddiscontinue the satellitic backup wireless communicationsystem, and (v) send a message to the user when the mal-function occurs in the backup wireless communicationsystem. Since SAHS possesses most C-ITS architecture re-quirements plus the preceding five requirements, the analysisresult can be directly generalized to the C-ITS architecture.

The satellitic backup communication system is easily in-corporated in the UML™ sequence diagram of the object-oriented visualization. For example, Fig. 8 shows thesequence diagram for SAHS use-case “support security andcoordination”. Note that the numbering system used is thesame as that of the C-ITS architecture to simplify the com-parison. The two brackets at the end of the message textmean that the message is a function of the data required byeach message.

One of the main components of the redundant satelliticbackup communication system is the stratospheric satellite.This unmanned solar-driven satellite can be used as a wire-less communication platform in the satellitic backup com-munication system. More details regarding these satellitescan be obtained from NASA Dryden Flight Research Center(NASA 2002). The other important part of the satelliticbackup communication system is the intelligent digital mo-dem (IDM). The IDM is located inside every system andsubsystem of SAHS. The main duty of IDM is to monitorSAHS communication channels. In the event of malfunction-ing of the SAHS communication, the IDM will divert thecommunication to the stratospheric satellite communicationplatform. If the stratospheric satellite communication plat-form fails, the IDM will initiate a message to the actor totake over the related operation.

Work on ITS standardization is carried out by the techni-cal committees of the International Organization for Stan-dardization (ISO) (ISO 2003). For example, the technicalcommittee on intelligent transport systems (TC 204) initiallyhad 16 working groups out of which 12 are currently active.The role of standardization in both PO and OO approachesis similar, but in the latter the standards are attached toclasses of the architecture. The AHS class may have subsys-tem classes for which the committee needs to develop stan-

© 2003 NRC Canada

Al-Qaysi et al. 967

Step From Action description To

1 17 4.4.1.1 Manage transit security 172 33 4.4.1.2 Manage transit emergencies 63 6 4.4.1.2 Manage transit emergencies 304 33 4.4.1.3 Provide transit system operator security interface 65 6 4.4.1.3 Provide transit system operator security interface 176 34 4.4.1.4 Provide transit external interface for emergencies 67 6 4.4.1.4 Provide transit external interface for emergencies 178 33 4.4.1.5 Provide transit driver interface for emergencies 69 6 4.4.1.5 Provide transit driver interface for emergencies 30

10 17 4.4.1.6 Collect transit vehicle emergency information 1711 32 4.4.1.7 Monitor secure area 612 6 4.4.1.7 Monitor secure area 2513 33 4.4.1.8 Report traveller emergencies 614 6 4.4.1.8 Report traveller emergencies 2515 33 4.4.2 Coordinate multiple agency responses to incidents 616 6 4.4.2 Coordinate multiple agency responses to incidents 1717 33 4.4.3 Generate responses for incidents 618 6 4.4.3 Generate responses for incidents 1719 34 4.4.4 Coordinate transit disaster response 620 6 4.4.4 Coordinate transit disaster response 17

Table 5. Main success scenario pertaining to Canadian automated highway system (CAHS)use-case 4A.4: support security and coordination.



dardization. Such subsystem classes include trafficimpediment warning, adaptive cruise control, forward vehi-cle collision warning, manoeuvring aid for low speed opera-tion, lane departure warning, and side obstacle warning.

Concluding remarks

This paper has presented an object-oriented approach forthe Canadian automated highway system architecture thatprovides important advantages over the existing PO ap-proach. The two main objectives of this study were (i) toprovide a stable and flexible C-ITS architecture and (ii) tointegrate a backup communication concept with the new C-ITS architecture. Based on this study, the following com-ments are offered.1. There is no standard method of analysis for determining

the effect of quality attributes on the C-ITS architecture.The lack of such a method hinders the development ofa clear relationship between architecture stability andflexibility, and system usability and functionality (repre-sented by user and functional requirements). Therefore,meaningful results and physical insights into the effectof architecture attributes are better obtained through sci-entific, documental, and visual analysis. This three-partanalysis, conducted on the CAHS conceptual architec-ture, showed that the backbone communication class isparticipating in almost every functionality of the system.With the proposed OO-based architecture changes to thearchitecture are local, and therefore stability and flexi-bility are achieved.

2. The need for a backup communication system in thepartial object-oriented CAHS architecture was demon-strated. The OOAD technique simplified changes to thearchitecture design when a backup communication sys-tem was integrated with CAHS, and the new system wascalled SAHS. It was shown that the solution for backupcommunication was adequate. That is, in the partial de-velopment of SAHS, two classes were provided to takeover the communication responsibility: backbone com-munication and backup communication. If the backboneclass malfunctions, the backup class will take over.

3. The main objectives of developing the C-ITS architec-ture are not only to ensure that the architecture subsys-tems reflect their effectiveness in communicating in acommon way and that each subsystem has a set of as-sumptions that are not in conflict with each other, butalso to establish a common ground to aid future trans-portation system developments. Such efficient commonground would aid motivations for combining safety andtechnology developments. The proposed SAHS architec-ture has achieved these objectives.

4. The ISO technical committee for ITS and its system ar-chitecture subcommittee identified the OO methodologyand UML™ as alternative methods to model the archi-tecture of the entire ITS system. In addition, worldwidesoftware and system engineering communities havebeen developing architectures in different modeling lan-guages in the past and are gradually standardizing themto UML™ using the OO methodology. This paper pro-motes the harmonization of the C-ITS architecturedevelopment at both system and project levels. More re-

alistically, however, the OO approach may make sensefor certain applications such as AHS and modelingmore detailed architecture at project level.

5. The concept of an intelligent digital modem (IDM) andthe use of a stratospheric satellite as a communicationplatform were introduced in this paper. A generalizationof these classes was modeled within the backup commu-nication class. Future research should (i) investigate theeffect of the C-ITS architecture characteristics on qual-ity attributes, especially those not addressed in thisstudy (e.g., safety and environmental soundness) and(ii) characterize the mutual effects and dependency ofquality attributes on each other to ensure satisfactoryfulfillment of the C-ITS architecture requirements. Moredetailed analysis of these requirements is needed andmay include case-specific requirements and features,studying the impact of integration of an atmospheric ve-hicle (Sky Car) and atmospheric highway concepts intoSAHS architecture development.

6. The civil engineering field has had major impacts on theimplementation of new technologies such as biotechnol-ogy, nanotechnology, electronic commerce, and ad-vanced communications and information technology. Itis critical that civil engineers understand and use thesetechnologies in practice. In addition, universities shouldstrive to make changes to a traditional civil engineeringcurriculum that reflect these new driving forces in civilengineering (Clough 2000). The study presented in thispaper represents a good example of a multidisciplinaryapproach to addressing a civil engineering problem.

7. As part of future directions of this study, the proposedSAHS architecture should be extended by focusing onthe full development of SAHS architecture that coversthe two-way path of the communication message (com-munication between the actors and the system). Futureresearch should also seek applications where the OO ap-proach may bridge the transition from the high-levelfunctionality statements of the existing C-ITS architec-ture to the more detailed project level specifications.These situations would benefit from the flexibility andstability offered by, for example, the backup communi-cations via a satellite. As such, the OO approach pro-posed in this paper should be of interest to ITSdevelopers and researchers.

Acknowledgment

The authors are grateful to Dr. Peter Hitchcock andDr. Denis Riordan (Faculty of Computer Science atDalhousie University) for their perceptive observations andhelpful suggestions during the conduct of this study. The au-thors are also grateful to two anonymous reviewers for theirthorough and most helpful comments.

References

AHSRA. 2003. Cruise-assist systems demonstrations around theworld [online]. Advanced Highway System Research Associa-tion, Tokyo, Japan. Available from [accessed 6 November 2003].

Al-Qaysi, Q., Ali, N., Easa, S.M., Hitchcock, P., and Riordan, D.2001. Proposed object-oriented approach for Canadian auto-

© 2003 NRC Canada

968 Can. J. Civ. Eng. Vol. 30, 2003



mated highway systems. Annual meeting of Transportation As-sociation of Canada, Halifax, N.S. TAC, Halifax N.S.

Al-Qaysi, Q.H 2002. Satellitic automated highway system: Visualmodeling of the requirements using rational rose and UML.Ph.D. thesis, Dalhousie University, Halifax, N.S.

Bachmann, F., Bass, L., Carriere, J., Clements, P., Garlan, D.,Ivers, J., Nord, R., and Little, R. 2000. Software architecturedocumentation in practice: documenting architectural layers.Tech. Rep. No. CMU/SEI-2000-SR-004, Software EngineeringInstitute, Carnegie Melon University, Pittsburgh, Pa.

Barbacci, M., Klein, M.H., Longstaff, T.A., and Weinstock, C.B.1995. Quality attributes. Tech. Rep. No. CMU/SEI-95-TR-021/ESC-TR-95-02, Software Engineering Institute, Carnegie MelonUniversity, Pittsburgh, Pa.

Bement, A.L., Richardson, H.H., Dahms, L.D., Deen, T.B.,Fearnsides, J.J., Finkelstein, M.M., Larson, T.D., Leveson, N.G.,Major, J.E., Nichols, R.J., Rivard, J.G., Roos, D., Shackelford,W., Sheridan, T.B., and Wormely, D.N. 1998. National auto-mated highway system program — a review. Committee for areview of the national automated highway system consortiumresearch program. Special report 253, Transportation ResearchBoard, National Research Council, Washington, D.C.

Booch, G. 1997. Object-oriented analysis and design: with applica-tion. Addison-Wesley, New York, N.Y.Clough, G.W. 2000. Civilengineering in the next millenium [online]. CEE New Millen-nium Colloquium. Available at http//:web.mit.edu/civenv/www/colloquium.clough.html [accessed 7 November 2003].

DeMarco, T. 1982. Controlling software projects. Prentice-Hall,Englewood Cliffs, N.J.

Easa, S.M. 1999. Automated highways. In Encyclopedia of electri-cal and electronic engineering. Edited by J.G. Webster. JohnWiley & Sons, New York, N.Y.

Gane, C., and Sarson, T. 1979. Structured systems analysis.Prentice-Hall, Englewood Cliffs, N.J.

Hatley, D.J., and Pirbhai, I.A. 1987. Strategies for real-time systemspecification. Dorest House Publishing Co., Inc., New York,N.Y.

ISO. 2003. Technical committees [online]. List of technicalcommittees. International Organization for Standardization.Available from http://iso.ch/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeList.TechnicalCommitteeList [accessed 7November 2003].

Jesty, P.H., Gaillet, J., Franco, G., Leighton, I., and Schultz, H.1998. Guidelines for the development and assessment of intelli-gent transportation system architectures. Telematics for Trans-port Project CONVERGE-SA (TR1101). The European Union,Brussel, Belgium. Deliverable DSA2.3.

McTrans Software Center. 2003. Turbo architecture [online]. Uni-versity of Florida, Gainesville, Fla. Available from http://itsarch.iteris.com/itsarch/html/turbo/turbooverview.htm [accessed 7 No-vember 2003].

NASA. 2002. Dryden flight research center [online]. Helios. Avail-able from http://www.dfrc.nasa.gov/ [accessed 7 November2003].

OMG. 2002. OMG Unified Modeling Language specification, Ver-sion 1.4 [online]. Object Management Group, Needham, Mass.Available from http://www.cgi.org/docs/formal/01-09-67.pdf[accessed 7 November 2003].

RSC. 1998. Rational Rose 98: Using Rational Rose. Rational Soft-ware Corporation, Cupertino, Calif.

Shaldover, S.E. 1998. Why we should develop a truly automatedhighway system. Transportation Research Record 1651. Trans-portation Research Board, Washington, D.C. pp. 66–73.

Stevens, W.P., Mayers, G.J., and Constantine, L.L. 1974. Struc-tured design. IBM System Journal, 13(2): 115–139.

Transport Canada. 2003a. An intelligent transportation systems(ITS) plan for Canada: en route to intelligent mobility [online].Transport Canada, Ottawa, Ont. Available from http://its-sti.gc.ca/en/downloads/its_plan.pdf [accessed 7 November 2003].

Transport Canada. 2003b. ITS architecture for Canada [online]. Trans-port Canada, Ottawa, Ont.. Available from http://its-sti.gc.ca/Architecture/english/static/content.htm [accessed 7 November2003].

Transport Canada. 2003c. Development of a Canadian architecturefor intelligent transportation systems (ITS) [online]. TransportCanada, Ottawa, Ont.. Available from http://its-sti.gc.ca/en/down-loads/canadian_architecture.htm [accessed 7 November 2003].

US DOT. 1997. Precursor system analysis of automated highwaysystems. Department of Transportation, Washington, D.C.

US DOT. 2003. The national ITS architecture [online]. U.S. De-partment of Transportation. Washington, D.C. Available fromhttp:// iteris.com/itsarch/ [accessed 7 November 2003].

Yourdon, E. 1991. Modern structured analysis. Prentice-Hall,Englewood Cliffs, N.J.

© 2003 NRC Canada

Al-Qaysi et al. 969



Proposed Canadian automated highway system architecture: object-oriented approach

Documents

Transcript of Proposed Canadian automated highway system architecture: object-oriented approach