AN ITMS ARCHITECTURE CONSIDERED
Jim Kerr, Greg Mosley, NET Corporation
SUMMARY
The content of the paper is intended to provide an overview of the driving factors which directly impact the development of an architecture for an Integrated Transportation Management System (ITMS). In many ways, the paper places emphasis on the need for the Transportation Professional and the Systems Engineering Professional to find common ground, such that the requirements of the Transportation Management function drive the development of a Systems Engineered architecture, and in turn the physical systems themselves. In summary the paper, considers the following major themes:
Systems Engineers are advised to consider the scope of the ITMS challenge from the perspective of the benefits which the Transportation community envisage when referring to ITMS. Transportation professionals are urged to consider the means by which they express their requirements to Systems Engineers. Figure 4 contains a very high level system architecture. At first blush, the transportation professional may consider the drawing too detailed to be easily understood. However, the Systems Engineers will undoubtedly require additional detail before embarking on design development. What is required is the ability of the design team to successfully bridge the level of understanding between the Transportation Engineers/Planners and the Systems Engineers. The formation of a Requirements Planning Team made up of representatives from both disciplines is recommended.
The ITMS concept, in a nutshell, endeavors to integrate all modes and all roads into a "system of systems." The position, however, is taken that much variation is present, region to region, in the manner in which comparable agencies operate their specific transportation services. It is suggested that the nature of these variations have a profound impact on the development of an ITMS architecture. As a result, the concept of coupling National System Interfacing Standards (to assure seamless inter-regional travel experienced with such entities as CVO operations) with specific regional ITMS architectures is suggested.
A conceptual ITMS architectural model is presented which essentially applies an onion like structure in the layering of critical system elements. The essence of the model draws on established and emerging open systems standards to provide the cohesive agent in the physical implementation of the architecture.
The conclusion of the paper notes that it is essential for agencies which are co-operatively deploying an ITMS, to develop a regional configuration management plan (CMP) and establish a mechanism to ensure the CMP's integrity remains intact throughout the entire life cycle of the ITMS.
PAPER ORGANIZATION
The paper is organized into four sections as follows:
1. The ITMS Challenge:
Intended primarily for systems engineering staff, this section provides an overview of the types of benefits anticipated within the transportation community in elevating current transportation systems to an integrated operation. The section concludes with a conceptual overview of the functionality envisaged in an ITMS.
2. The Architecture Development Process:
Intended primarily for Transportation Engineers/Planners, this section provides relatively brief description of the recommended steps necessary to establish a comprehensive and robust system architecture, using structured systems engineering principles.
3. Important Conceptual Components for an ITMS ArchitectureorWhere to get started:
Intended for both transportation engineers/planners and systems engineers, this section identifies a number of items which are strongly recommended for consideration in the early stages of development of an ITMS architecture.
4. Conclusions
A number of conclusions are drawn concerning the process and key considerations suggested for the ITMS architecture development process. The concept of establishing and maintaining a formal regional configuration plan (CMP) is introduced.
The paper is intended strictly as a summary overview of the significant factors which are present in the development of a systems architecture. Of these factors, perhaps none is more significant than the ability of the design team to bridge the information gap which typically exists between transportation and systems professionals.
THE CHALLENGE
Integrated Transportation Management Systems (ITMS) seemingly represent the next evolutionary step in the deployment of advanced technologies to meet surface transportation needs. ITMS, as a turn of phrase, itself conjures a vision of an integrated environment of operational, institutional and technological instruments into a common mechanism for covering the full gambit of multi-modal trips planned for our transportation network(s). While, perhaps, there is an overall vision of ITMS which is shared amongst Transportation Engineers and Planners (with allowance for variances in individual opinions), there is still much ground to be covered between this vision and the rather exact science applied by our technologists in the delivery of systems to support day to day operations. Therefore, prior to the development of an ITMS architecture there is a requirement to add definition to the scope of the ITMS challenge. For the benefit of the Systems engineers, Appendix A provides a summary of the scope of this challenge through the examination of the potential benefits associated with ITMS. The following provides a summary of the referenced content:
The traditional application of advanced technologies to surface transportation needs focused on the ability of agencies, acting largely in stand-alone operations, to address both recurring (e.g., rush hour traffic )and non-recurring (e.g., incidents) congestion, through surveillance and typically local control techniques. Benefits of these systems included a generally more efficient movement of persons and goods characterized by increased safety levels and reductions in vehicle hours of delay
ITMS provides the opportunity to gain both incremental and new benefits over the traditional systems through the integration of all transportation agencies' (all modes, all roads) management and information systems. These benefits are associated with an area wide or corridor level response to the full range of mobility needs within a region.
Variances, region to region, in basic operational philosophies and policies have a profound impact on the ultimate ITMS deployed
Deployment of an ITMS provides an opportunity to bridge multi-modal planning and design work with day to day inter-modal operations
Figure 1 provides a conceptual overview of the potential integration of transportation services in a manner which would return the benefits described in Appendix A. Essentially the intent is to establish a critical mass of data and control access which enables area wide transportation management/demand strategies to be deployed both in real time, and as strategic interventions to longer term travel demand patterns. In a nutshell, the intent is to establish a "system of systems" which integrates all modes and all roads.
While figure 1 represents this mass of data as single entity, it is not intended that such an implementation necessarily focus on the establishment of a central depository of fused data. Rather distribution of the system components (data, control sequences) across an open system environment, where data and control integrity reside with the operating agency, may well represent a more effective manner to gain local consensus and hence the deployment of such a system.
Figure 1. Conceptual ITMS
THE ARCHITECTURE DEVELOPMENT PROCESS
Overview
In consideration of the broad technical scope of an ITMS architecture, the balance of this paper focuses on the development of an architecture for the systems found within the many operations centers (transit, ports, traffic, private operations, etc) which comprise an ITMS. An equal or greater length discussion can be made for the supporting ITMS field infrastructure and wide area communications network. However, the first point of interface for ITMS will likely occur in the management centers. As "smart" field devices are deployed, however, expect to see a broader scope for the system integration exercise.
Prior to engaging in a discussion on the steps required in the development of an ITMS architecture, reference is again drawn to figure 1. Depicted in this figure is a conceptual integration of the various elements of any transportation network. To gain an early focus for local agencies, it is often useful to quickly establish a conceptual system architectural model which provides a framework to flush out the technical details necessary to complete the systems engineering process. Also, specific attention needs to be paid to the existing or legacy systems (as opposed to new systems) which are currently in operation. Hence an effort to establish a migration path from the existing case to the ITMS is critical. One approach to deal with this scenario is to introduce an open systems component (hardware and software) which taps the "shared memory" (assuming no licensing violations are incurred) portion of the existing systems, thus gaining access to both data and control parameters.
A measure of success has been gained in the representation of the ITMS implementation as an onion model, where the ITMS applications are layered into the architecture using industry recognized open systems standards. Figure 2 portrays this conceptual model. Each of the concentric circles in the model represent an industry recognized and supported open systems standard. A summary of the critical system interfaces (and hence the need for open system standards) follows:
The core of the onion is made up not a single piece of hardware but rather, the various pieces of hardware (and their operating systems) found amongst all of the agencies involved in the ITMS. To be sure, not all agencies will agree on a common piece of hardware to be used by all, and in certainty attempts to establish hardware to hardware links (where all hardware is not common) will lead to trouble. Therefore, there is a need to elevate the integration effort to a higher systems management level. Recognize, however, open system standards for operating systems do exist and should be fixed in the early stages of development.
The next layer in the onion represents a significant element in the successful integration of the ITMS: data management and Inter-process Communication (IPC). Data Management provides the mechanism to share data between systems and users in a seamless fashion. The inter-process communications process essentially enables real-time interfaces, using an open "publish/subscribe" paradigm. This layer of the model is ideally where all communications between new and existing systems takes place. The need for open systems standards, not proprietary "library" routines, at this level are critical.
Layered on top of the data management and IPC layer are the ITMS applications. The applications include (but are not limited to) signal systems, freeway systems, bus operations, rail operations, emergency services including law enforcement, port operations, CVO needs, etc. The intent is to avoid directly binding applications together by communicating between applications through the data management and IPC layer. Tightly binding application to application is strongly discouraged since even a minor change in hardware, or in the data dictionary can drop the integrated systems out of alignment. Further, the ability to add and delete applications from the ITMS is simplified when the use of open standards effectively allow a "plug and play" environment
The outer layer of the model is the User Interface. Most common today is the use of graphical user interfaces (GUI). Open standards exist for user interfaces which give all operations a common look and feel. This allows remote operation of all applications within the ITMS.
The Development Process
An ITMS architecture is made up of two essential and separate parts, the technical architecture and the information architecture. The components of the technical architecture come from the computer industry vendors; these include workstations, servers, routers, bridges, local-area networks, wide-area networks, peripherals, databases, operating systems, etc. Figure 3 depicts a generalized distributed technical architecture for the Yosemite Area Traveller Information (YATI) system. The components of the information architecture are designed from inside the enterprise by a process called Information Engineering. Information engineering identifies the entities (objects) in an enterprise about which information is stored. It decomposes the functions of the enterprise into processes and builds data models and process models for each functional area. These models are stored in a repository referred to as an encyclopedia or dictionary.
Figure 2. Conceptual Architectural Model
Figure 3. Technical Model (YATI System)
Figure 4 is an example of a information architecture that was developed for the same YATI system. Be warned, figure 4 at first blush may appear to be a very detailed depiction of a complex transportation management and information system in the Yosemite area. However, as detailed as the drawing is, it does not have sufficient detail to allow systems engineers to engage in detailed design. As such, the observation is made that the means by which transportation express their requirements needs to closely track the nomenclatures used by systems engineers to perform actual design work. A number of transportation agencies in the U.S. (e.g., Caltrans) have invested the time necessary to develop a method by which the needs/requirements of the traffic engineers are presented to the systems staff in a manner which directly fits the design paradigm. This approach avoids the cycle of "here is what I want, you figure out if it's implementable and let me know."
The following provides an overview of a structured, systematic process suggested for the development of an ITMS Architecture, such as those presented in figures 1, 2 and 3. The information is presented to highlight the prerequisite types of information required before an architecture, at a regional level, can be developed.
Significant Steps in Developing an Architecture
Operations Concept
The definition of operational concepts is the beginning of the requirements planning phase. A Joint Requirements Planning (JRP) team made up of both transportation professionals and systems engineers is encouraged to be formed in this phase. This team provides the mechanism where key agency personnel (management and users) participate in workshops where operational knowledge is collected and expressed in the form of an Operations Definition. Operations are the principles which govern and establish a need for the system. In the case of a "system of systems," emphasis needs to be placed on the type of interface to be established and the operational procedures to be followed by all participants. System inputs and outputs are identified, and as much of the system's working environment as possible. It cannot be over stated that end users are essential to discovering the subtleties of the complete transportation environment.
Functional System Requirements
The JRP team continues the requirements planning phase by defining the system in terms of major functions that are consistent with the operations document. It is at the functional level that an Integrated Computer Aided Software Engineering (ICASE) tool is used. ICASE is used to diagram the functional system into processes that act as a repository for the system definitions. Data flow and entity-relationship diagrams (similar to that depicted in figure 4) are used to extract system definitions and dependencies from the operations concept document. Through process refinement and decomposition, the JRP team continues to define the functional model until all the system functions are described. The Functional System Requirements document captures the system functional model by specifying the processes and data flows in requirements terminology. User interface proto-typing are often times employed by the JRP team to help clarify requirements and give an overall understanding of the functional system model.
Baseline Performance Requirements
Performance requirements are a distinct part of the Functional System Requirements. Capabilities identified in the system functional model often have resource critical requirements. Timing constraints and storage needs are examples of baseline performance requirements. Typically, these requirements are in terms of operational resource and not physical resource, such as: "the system shall store one year of transit data."
Architectural Alternatives
Within the framework of the functional system requirements (including performance) the system designers evaluated architectural alternatives. Architectural components are chosen based upon technical merits and general cost constraints. System architectures are derived by senior systems engineers to meet functional requirements. Resulting candidate architectures are evaluated by a weighted list of criteria based upon the operational objectives and organizational needs. It is strongly recommended that one criteria of the architectural evaluation process is that of open systems. Open system standards promote the use of portable, inter-operable, and vendor neutral architectures. Open standards allow the implementation of the model depicted in figure 2.
Figure 4. Information Model (YATI System)
Design Stage
With the functional requirements and an architectural model defined, the design team begins the user design phase using a top-down approach. ICASE and proto-typing tools are used to build upon the requirements repository from the requirements planning phase. Object-oriented Design (OOD) is a popular method to continue the design process by translating functional requirements into object classes, object relationships, and object data flows. Proto-typing and story boarding allows the user to get involved in the design process. OOD continues until the system is represented by an object model that defines the software and hardware objects. Functional requirements flow into the object design and are allocated to the software and hardware components. All requirements are traceable into the higher level documents and are verified through testing.
Implementation Stage
Rapid application development is accomplished by using the ICASE tool to analyze, design, code, test, and improve. Implementation becomes an evolving process constantly improving design and regenerating code. Evolving a design is only practical if the system has been cleanly engineered so that it is easy to change. ICASE keeps the repository current with the improvements and code frames are automatically updated. System modules are tested and integrated in a step-wise fashion until the system is fully integrated and ready for acceptance testing. ICASE helps to generate consistent design documentation from the data repository. Design documentation consists of object descriptions, diagrams, data dictionary, traceability matrices, and source code.
IMPORTANT CONCEPTUAL COMPONENTS FOR AN ITMS ARCHITECTUREorWhere to get started
Recognize the Regional Differences
Transportation needs can be summarized as: efficient and safe movement of people, goods and services. On regional and national levels, the ITMS challenge is to provide an inter-connect between all transportation agencies as a common, yet distributed information entity. To consider any given architecture as the ITMS solution, may well lessen the consideration of unique agency needs that vary from region to region. It is suggested in figure 5, that the needs of an agency directly determine the operation concepts and the system performance. Operation concepts determine the functional system requirements which in turn directs the system architecture selection. The system architecture alternatives are the results of system engineers applying functional requirements against today's technologies.
Guide the ITMS Architecture Development
In order to meet the ITMS challenge for a region, the ITMS architecture must provide an effective inter-connect and merge of transportation information while at the same time remaining sensitive to the individual agency's needs. Since it is improbable that one ITMS design can satisfy all needs, it is suggested that a mechanism to guide the ITMS development toward the ITMS vision be established. For discussion purposes it is taken that the ITMS vision focuses on establishing a network of inter-operable transportation management centers that seamless"ly" share information. The solution to the ITMS challenge may well not be associated with a "one size fits all" architecture, rather to guide, influence, and encourage the ITMS vision. Figure 6 shows a two prong mechanism to guide ITMS system development. The first emphasis is in the establishment of an ITMS open standards profile with the second emphasis focusing on the ITMS recommended architectures. Note that the open ITMS standards and recommended ITMS architectures are interjected downstream of the functional system requirements into the architecture alternatives. In this manner, the system design follows the agencies functional requirements and at the same time converges on the ITMS vision.
Specifying Open Standards
X/Open has defined open systems as: "Vendor independent computing environment consisting of inter-operable products and technologies that are commonly available and that have been designed and implemented in accordance with dejure and defacto standards." A further example is taken from Caltrans' statewide Transportation Management Center Master Plan, open systems is defined as: ". . . a non proprietary system that operates on different platforms."
Figure 5. Region's Requirements Flow into Design
Figure 6. Mechanisms to Guide ITMS Design
Figure 2 provided an onion like model to introduce the concept of the use of open systems standards in an ITMS architecture. In defining and applying specific open system standards to support the onion model, necessitates the building of an ITMS Open Standards profile. The process of building and maintaining an ITMS Open Standards profile requires a commitment to research and to staying abreast of industry's dynamic allocations of open standards in the areas of interest. Comprehensive knowledge of current open standards in the area of interest allows the system designer to make informed choices and assemble a profile for an Open ITS architecture. Figure 7 depicts a four step process of generating an open profile to be used in the Open ITS design for an ITMS.
Figure 7. Selecting an Open Standards Profile
Step one is to identify requirements; sources include the ITMS vision, industry's direction, and existing profiles. Step two is the normalization of existing profiles for comparison of similar standards. Step three is the selection of evaluation criteria based upon the requirements. Step four is the evaluation and selection of an Open ITS profile.
The MUSIC Model
One accepted approach for building standard profiles is based upon a popular model for categorizing open standards called the MUSIC model. The MUSIC model was developed and used by the Central Computer and Telecommunications Agency (CCTA) of Britain for categorizing major system partitions. Figure 8 provides a graphical representation of the MUSIC model. The MUSIC acronym defines five major elements in the distributed computing environment, they are:
1. Management Services
2. User Interface
3. System Interface
4. Information and Data Services
5. Communication Services
Applying the MUSIC model to recognized industry profiles (e.g., GOSIP, TCOS, XPG) provide a way of normalizing standards for comparison and evaluation. Evaluation criteria is chosen and weighted as an indication of relative importance to the ITMS vision. In most cases Open Systems definitions of "openness" also fulfill the ITMS vision of inter-operability across modal and jurisdictional boundaries.
Figure 8. The MUSIC Model
CONCLUSIONS
The content of the paper provides an overview of the driving factors which influence the development of an ITMS architecture. Through the course of discussion a number of observations are made concerning the overall process by which an architecture is developed. Reference is made to the need to bring together the shared expertise of transportation and systems professionals in an integrated design team, where each express their requirements in a format and nomenclature familiar to the other. The closing sections of the paper describe the manner in which variances, region to region, will impact the final deployment of the ITMS. In bringing conclusion to the general discussion concerning the development of an ITMS architecture, consideration is now given to the process by which an ITMS is physically defined and ultimately maintained during day to day operations. Reference was made in the body of the paper to ITMS as being a "system of systems" which integrates all roads and all modes. Not referenced was the process by which participating agencies initially baseline their ITMS implementation and keep it aligned through design, implementation and operations. The use of a living, formal Configuration Management Plan (CMP) is recommended for this purpose. The CMP documents all relevant details of the ITMS ranging from open standards profiles through to detailed data dictionaries of the integrated environment. CMPs, as would be expected, tend to be very specific to the implementation which they govern. However, for the purpose of this paper the following general topics are suggested to be appropriate for inclusion in a CMP:
Operational procedures governing the functionality of the deployed, integrated, system
System baseline: describes the existing systems, the vision for new systems to be deployed including open standards to be observed. Acceptable migration paths for any existing proprietary systems to an open architecture will stream line integration efforts
Configuration details: (remember figure 4) Details concerning both hardware and software components are provided
Interface specifications: detailing the manner in which existing systems are integrated and the manner in which new systems are to be integrated
Change Procedures: These outline the process by which participating agencies maintain and tune their individual systems while remaining aligned with the overall ITMS. A configuration management team is suggested with technical representatives from each of the participating agencies
Minimum performance requirements for every composite piece of the entire ITMS.
APPENDIX A
Scope of the ITMS Challenge
In considering broad scope of an ITMS, several key topics surface, including:
What we know about: inter-modal needs, overall ITMS objectives, the probable institution implications and the rising urgency to achieve integrated transportation management.
What we don't know about: specific performance (and storage) requirements, variances in operational practices and procedures region to region, variances in maintenance and system support capabilities region to region, the emerging influence of agency MIS departments on ITMS, and the commitment of private entities in supporting ITMS
The meaning and interrelationship between the terms Inter-Modal and Multi-Modal
What we know about the "Challenge"
The application of advanced technologies to our current and future transportation needs actually address a rather concise scope of mobility improvements. In fact, this scope of improvements can be examined under two basic scenarios associated with urban travel.
Urban traffic congestion can be broadly classified into two demand/capacity scenarios as recurring and non-recurring congestion. Recurring congestion occurs when demand exceeds capacity on a routine basis such as during morning and evening peak periods. Non-recurring congestion occurs when the capacity of a section of roadway is temporarily reduced due to incidents such as stalled vehicles, accidents etc.
Figure 1 graphically depicts the concept of recurring congestion. The capacity of a roadway segment is constant and is represented by the straight line AB. The ordinate of the demand curve varies depending on time of day and typically exceeds capacity during peak hours. C and D represent points at which demand is equal to capacity. The shaded area between the two lines gives the total traffic delay due to recurring congestion. The time difference between the points C and D is the duration of delay.
Figure 2 represents the concepts of non-recurring congestion. In this scenario the demand is within the limits of capacity and the curve AC represents the demand within the capacity limits. Point A represents occurrence of an incident. At this point the demand temporarily exceeds bottleneck (effective) capacity. Point B represents incident removal and beginning of capacity restoration until it reaches point C where free flow conditions are resumed. The shaded area bounded by ABC represents total delay due to the incident and the time difference between A and C is the duration of delay due to the incident.
Concepts of ITS solutions
Several ITS elements are used as solutions to mitigate recurring and non recurring congestion. Some common ITS elements include CCTV cameras and Vehicle Detector Station (VDS) for real time monitoring and surveillance, Entry Control Systems or Ramp Metering Systems (ECS/RMS) to regulate real time demand and to mitigate congestion. CMS, HAR, TAT, Community Access Television (CATV) and Interactive Multimedia Kiosk Systems (IMKS) are used to disseminate real time traffic and traveler information and to regulate on and off-the road demand.
Two traditional methods are employed to reduce delay due to recurring congestion. These methods are regulating the demand and increasing the physical roadway capacity to meet or exceed the demand. A conceptual representation of these two methods are represented in figures 3 and 4.
Figure 3 shows regulation of demand in areas where limited effective capacity due to bottlenecks are incurred. Tools employed to mitigate recurring congestion will assist in reducing the area of the delay envelope bounded by the excess demand curve and the capacity line. A common tool employed in a freeway environment within the Advanced Traffic Management System (ATMS) functional area of ITS for this purpose is ramp metering. Ramp metering regulates the rate of vehicles entering the freeway such that upstream demand is maintained at the same or lower level compared to downstream capacity. By regulating the rate of entry, breakdown in vehicle speeds and increase in delay resulting from overcrowding and turbulence can be minimized. In Figure 3, curve AC represents original demand and curve AB represents regulated demand due to ramp metering. The cross hatched area ABC represents reduction in traffic delay due to ramp metering. Other methods of reducing delay due to recurring congestion include reducing demand before the onset of congestion. These techniques include dissemination of accurate real time pre-trip traffic and traveler information to motorists so they can plan their trip to avoid congestion either on or off the road.
Tools commonly employed for this purpose within the realm of the Advanced Traveler Information System (ATIS) functional area of IVHS include CMS, HAR, TAT, IMKS and personal and public bulletin boards. The ITMS extension is to optimize corridor level capacity through the integration of surface street and freeway operations as well as other modes.
Figure 4 shows the traditional solution for recurrent congestion: physical widening. Line AC represents original capacity. Line AB represents increased capacity due to widening. Cross hatched area shows delay savings due to widening. However, this option is extremely difficult to implement due to socio-economic and environmental considerations.
Figures 5 and 6 show conceptual solutions to non-recurring or incident caused congestion.
Figure 5 shows reduction in effective capacity (line AB) due to an incident.
Demand regulation at incident bottlenecks can be achieved by diverting traffic to alternative routes and by using ATIS elements. In combination with ATMS elements it is possible to achieve greater optimum capacity and safer speeds at the bottleneck locations. Cross hatched area ACD in figure 5 represents reduction in delay due to combination of ATMS and ATIS elements. The ITMS extension provides a more comprehensive tool to provide a far more complete set information concerning modal and route choices.
Figure 6 shows one of the most cost effective ways of mitigating the effects of non recurring congestion on the traffic stream: rapid incident response. Incident management consists of four main stages; identification, verification, response and removal. Rapid identification and verification of incidents using VDS and CCTV, enable the incident management team to mobilize appropriate personnel and equipment and quickly respond to the incident. Reduced time in each of the four stages of incident management results in reduced incident duration and rapid recovery of the traffic stream to normal flow. The line AC in figure 6 shows the original incident clearance time and AB represents new reduced incident clearance time. The Area bounded by EBCD represents the reduction in traffic delay due to rapid incident clearance. The ITMS deployment provides additional data sources (such as probe data from instrumented transit vehicles) to assist in the incident detection and verification process.
Further consideration of the potential for improvements noted above, reveals an underlying layer of institutional coordination and consensus which must be addressed either prior to, or in parallel with the development of an ITMS architecture. While the depth of the issues associated with these topics are left for other papers presented at the subject symposium, the dependency of the development of a useful and useable ITMS architecture on the resolution of the associated issues is noted.
Variables associated with the "Challenge"
While we are able to identify with the scope of improvements associated with an ITMS, there exists a number of associated variables which will vary region to region, and pose a significant potential to significantly impact the development of an ITMS architecture. The following summarizes some of the more critical elements:
Operational Practices and Procedures
Maintenance and System Support Capabilities
Existing Infrastructure
Funding cycles relative to system life
System Performance Requirements
- classes of performances requirement
- probable migration
Individual Agency MIS standards perceived to be applicable to ITMS
Commitment of private industry, region to region
In consideration of the above, the establishment of an ITMS architecture would seem to most likely converge at the regional level. Efforts to normalize an architecture beyond the regional level would be deeply affected and confounded by the variance of the preceding from region to region. Further, an ITMS architecture will need to be sensitive to individual agencies' desire to apply the solutions which they feel most applicable to their specific operation. However, there still exists the requirement to establish a number of interfacing standards at a National level in order for functions such as in vehicle communications, to be functions. With these requirements, and in consideration of the rather obvious need for systems in a common region to be interoperable, the need to establish regional configuration management plans is critical. This concept is pursued further in the closing section of this paper.
Inter-Modal and Multi-Modal
The terms Multi-Modal and Inter-Modal are becoming a common part of the ITS vernacular. However, while the use if the terms is on the rise, a clear definition of the meaning, interpretation, interrelationship and implications of the terms is no yet well defined. For the work currently underway in Southern California where the State shall deliver four separate Intermodal Transportation Management Centers, over the next 6 to 24 months, the need has existed for some time to establish an understanding of these terms and the manner in which an ITMS supports the concepts defined. The following summarizes the definitions currently being applied:
Inter-Modal is considered to focus on the real time activities associated with individuals mode selection and use. Further, inter-modal also refers to the agencies attempts to affect mode selection on a day to day basis and in real time
Multi-Modal is considered to address the planning and design process to establish multi-modal transportation networks. Additionally, the efforts of the agencies to affect travel behavioral patterns over the long term are likewise associated with the term multi-modal.
With these general definitions in place, a number further observations have been posed in Southern California. The following highlights relevant observations which pertain to the subject paper:
A firm and recognizable Inter-Modal operations concept should be the foundation on which the planning and design of a Multi-Modal network is based
An ITMS, in merging data from all modes, can act as a catalyst to bridge multi-modal planning and design with realistic inter-modal operations concepts.
Foreword | Table of Contents | TRB Online Publications Page | TRB Home Page
NRC Home Page