Planning and Implementing Multimodal, Integrated Corridor Management: Guidebook (2020)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

91 Chapter 5 - Planning for the Technical Components of Integrated Corridor Management Overview The purpose of this chapter is to introduce the design and deployment process for an ICM system, and the processes and plans agencies should perform in preparing for design and deployment. This chapter will consider the processes to take requirements to design, the key questions agencies need to ask to decide how they want to implement ICM, and which components of an ICM system will best fit their needs and requirements. Additionally, since funding limitations are almost always a constraint, this chapter will also discuss how to develop an implementation plan and phase the design and development of an ICM system. The architectural and design process should include a multi-step process which builds to a detailed design, which can be used by developers to develop and deploy the system. Depending on the development process used (waterfall, agile, iterative), this process should be tailored to the design and development process selected. The Dallas ICM program used a formal architecture and design process, which allowed them to consider many alternatives in how the system was built and eventually developed and deployed. Technical Components and Architectures for ICM System Most commonly, ICM is thought of as the technological solution that enables coordinated traffic management based on operational procedures mutually agreed to by the various agency system managers owners and operators. An ICM system integrates agency solutions to support data sharing, create common situational awareness, and foster collaborative and cooperative event and congestion management. There are four primary shared systems that shape the overall technical ICM solution, as shown in Figure 15 and described in the paragraphs following. Figure 15. ICM Technical Solution Components

92 User Interface: Interface for system managers to interact with the ICM. This could be a stand-alone, separate interface or could be attained by customizing the interface of existing systems used by the agency (e.g., adding functionality to an existing Freeway ATMS or Traffic Signal System). Decision Support System (DSS): This is the business logic that will define the operational coordination between agencies for a given event. DSSs are sophisticated centralized applications that use business rules and/or artificial intelligence/machine learning techniques to predict and detect problems with network throughput and suggest cooperative response strategies to mitigate congestion impacts. Integrated Data Exchange (IDE): A centralized data warehouse that collects, fuses, aggregates, and stores data from member agency systems. Business Intelligence (BI): Visualization tools, including reports and dashboards, that capture performance measures to assess how well the ICM system is meeting agency needs and goals. Sample ICM Architectures There is no “standard” architecture for ICM systems. ICM can be built around different system architectures depending on corridor needs, agency capabilities, and available budgets. There are two primary approaches to ICM architectures: (1) Using an existing traffic management system as the primary system and (2) creating a stand-alone, separate system to integrate all the stakeholder systems. These are described briefly below. Using a Master Operational System for ICM: In this architecture, an existing operational system serves as the “Master” system. The DSS, IDE, and BI that exist in this Master System are expanded to include the data and response components for other agency stakeholders. Each system manager uses the user interface of their own system to interact with the ICM. An example is shown in Figure 16 ICM capabilities are added to an existing statewide Freeway ATMS. Data from arterial management and transit management systems are shared with the Freeway ATMS. Incident response plans in the Freeway ATMS are expanded to support recommended signal time changes. The Freeway ATMS also captures multimodal travel times to post travel time for transit and arterials on message signs in the corridor. (Source: FHWA Scoping and Conducting Data-Driven 21st Century Transportation System Analyses) Figure 16. ICM Modal Traffic Management System of Systems Variations to this approach include deploying the DSS and BI as centralized systems, as shown in Figure 17.

93 (Source: FHWA Scoping and Conducting Data-Driven 21st Century Transportation System Analyses) Figure 17. ICM System Integration ICM as an “Umbrella” System: This architecture specifies an ICM system that is separate and apart from each traffic management system. The ICM receives data from each system manager solution but all activity occurs through the shared operational GUI. The DSS, IDE, and BI are centralized, shared subsystems external to the traffic management systems, as shown in Figure 18 (Source: FHWA Scoping and Conducting Data-Driven 21st Century Transportation System Analyses) Figure 18. Modal Integration for ICM

94 User Interface The user interface (UI) provides the software application for users to interact and view the systems and data for the ICM system. UI can be graphical, text-based, or audio-video based, depending upon the underlying hardware and software combination. A graphical user interface (GUI) is the most common UI in newer transportation management systems and provides the user with a graphical means to interact with the system. Potential Solutions Related documents on UI design are available at: Human Factors Guidelines for Transportation Management Centers https://www.fhwa.dot.gov/publications/research/safety/16060/16060.pdf Decision Support System (DSS) The central integration element of the ICMS is the collaborative management of the disparate transportation network systems, which is accomplished by human interaction and automated and non- automated tools. The Decision Support System (DSS) is the central element of many ICMS, connecting the transit management, traveler information services, incident management, arterial management, freeway management, parking management, and other transportation management systems available on the corridor. The DSS provides computer-based aid to agency operators to assist with the decision-making process during operations. It is a tool that is informed by predetermined business rules agreed to by ICM stakeholders. Implementing a DSS is not required as part of all ICM systems, however, it helps agencies access integrated information from a multitude of sources, parses the data with pre-defined business rules, and provides operators with a candidate response plan that was pre-agreed upon by all partner agencies. The DSS does not suggest responses for normal, recurring congestion, but instead assists in responding to incidents and nonrecurring congestion. The DSS evaluates the incident against the pre-programmed rules, which were determined during the ICM planning phase and approved by stakeholder agencies. For example, the rules used for the US-75 DSS include parameters including location of incident, severity of incident, length of queue, direction of travel, available capacity on adjacent arterials, evaluation of network conditions based on system detectors, future forecast of network impacts, and transit readiness to accept additional passengers and parked vehicles at the station. Ultimately, agency operators have the decision-making responsibility and ability to accept, reject, or modify actions suggested by the DSS during incidents. ICM operators in each agency should be aware of the readiness of their system to carry out the response plan and are responsible for communicating their actions to the other partner agencies, whether through the DSS or through other forms of communication. If the involved agencies agree to implement, the DSS can assist in disseminating information on roadway DMS, 511 systems, websites, private sector traveler information tools, various websites, and other integrated traveler information providers. Decision support should begin with agencies cooperatively developing the business process flow for decision-making that they would like to follow. An example of a decision support process that was then converted to a software system is shown in Figure 19 for the US-75 ICM deployment in Dallas.

95 (Source: USDOT: Final Report-Dallas Integrated Corridor Management (ICM) Demonstration Project) Figure 19. Dallas ICM DSS Process In the San Diego I-15 ICM, the regional transportation network is controlled by the DSS, which integrates and provides control abilities for area transportation coordinators. Along with the DSS, two additional systems were developed to support the DSS: • Network Prediction System (NPS) – developed as part of the ICM demonstration to support DSS operations and used to predict origin-destination flows within the I-15 corridor. Real-Time Simulation System (RTSS) – developed as part of the ICM demonstration to support DSS operations and used to manage and execute corridor simulations. To describe the ICM system with integrated DSS, Dion and Skabardonis (2015) developed the diagram in Figure 20 and note that the diagram: “…provides an early conceptual view of the DSS. Core functions of the DSS are represented in the gray box shown in the upper right corner of the diagram. Based on information received from the various transportation systems via the IMTMS web services (shown in the blue boxes surrounding the IMTMS cloud), the DSS would use a rules engine to assess corridor operations and develop suitable response plans. These plans would then be converted into control actions that would be passed back to the relevant systems via the IMTMS web servers. Examples of control actions that may be received by each transportation system are shown in the gray boxes surrounding the IMTMS cloud.”

96 Figure 20 contains the following acronyms: • ATIS (advanced traveler information system) • CAD (computer aided dispatch) • CMS (changeable message sign) • EV (emergency vehicle) • IMTMS (intermodal transportation management system) • RMS (ramp meter stations) • RTMS (regional transit management system) • XML (extensible markup language). (Source: FHWA: Elements of Business Rules and Decision Support Systems within Integrated Corridor Management: Understanding the Intersection of These Three Components) Figure 20. I-15 ICM Concept In general, the DSS deployed for the example ICM projects have reusable components. For example, the rules engine software was a commercial product that can be used for any decision support process automation. Advanced modeling is not necessarily required for a DSS; while it does provide benefit, it has a higher cost. Deciding what components of a DSS are needed are dependent on the data availability of the corridor, the needs and goals of the ICM program, and the available funding. As the capability maturity model for ICM that was developed for NCHRP 12-02 shows, a DSS can be as simple as a set of pre-defined response plans to a very mature software platform that predicts and develops responses dynamically.

97 Potential Solutions Related documents are available at: Elements of Business Rules and Decision Support Systems within Integrated Corridor Management: Understanding the Intersection of These Three Components https://ops.fhwa.dot.gov/publications/fhwahop17027/index.htm Assessment of Emerging Opportunities for Real-Time, Multimodal Decision Support Systems in Transportation Operations, USDOT Contract DTFH61-06-D-00005, Task No. T-10-007 https://nanopdf.com/download/rtmdss-conops-final-2011-05-17_pdf Integrated Data Exchange Many existing transportation management systems were conceived, developed, and implemented as stand-alone, or “stovepipe,” systems and do not always provide for integration of data between systems. Through the development of a single integrated data environment (IDE), all necessary data for ICM can be fused into a single database. The advantages of the IDE approach include the following: • Single view of all data • Single physical database from which all applications can draw data • Some standards exist to assist agencies with development of an IDE (i.e., Traffic Management Data Dictionary, Center-to-Center) While the disadvantages of the IDE approach include the following: • Agencies need to agree on the data model • Impact on all legacy systems, which are required to conform to the new global data model • Complexity increases dramatically with the number of systems and types of data (i.e., ATMS data, transit data) • The process to maintain the IDE may become unmanageable with large numbers of systems Potential Solutions Related documents for data exchange are available at: Integrating Emerging Data Sources into Operational Practice https://transportationops.org/publications/integrating-emerging-data-sources-operational-practice From LOS to VMT, VHT and beyond through data fusion: application to integrated corridor management http://www.ucconnect.berkeley.edu/los-vmt-vht-and-beyond-through-data-fusion-application- integrated-corridor-management-0 Business Intelligence Business intelligence (BI) provides agencies with the tools and technologies for the data analysis of transportation information. BI technologies in transportation provide historical, current, and predictive views of the data within the IDE. BI solutions include reporting, online analytical processing, analytics, data mining, business performance management, benchmarking, and predictive analytics.

98 Potential Solutions Related documents on Business Intelligence are available at: NCHRP 03-128 Business Intelligence Techniques for Transportation Agency Decision Making http://onlinepubs.trb.org/onlinepubs/Conferences/2019/PerformanceData/128.pdf https://apps.trb.org/cmsfeed/TRBNetProjectDisplay.asp?ProjectID=4352 Design Process for ICM The design process for ICM should follow the process and procedures developed as part of the SEMP. For this discussion, it is assumed that a design team, consisting of agency stakeholders, consultants, and system implementors, exists, and performs the high-level activities in the following subsections. Review System Architecture The design team will begin by reviewing system architecture developed in the systems requirements document, ensure understanding, and provide any updates, if deemed necessary. This provides stakeholders with a logical view of the technical integration of the systems needed to cooperatively operate the corridor. Develop and Analyze Design Alternatives The design team will perform the design activity in two stages, high-level and detailed, and obtain feedback from stakeholders at the end of each stage. The design team will also analyze design alternatives for the products and identify some of the key product components and interfaces that trace to the essential system requirements. If required, the design team will develop, build, and conduct some proofs of concept or experiments to design the details of the interface design. The design team will identify the preliminary sequence for integrating the various product components. Alternate product component integration sequences will be evaluated and documented as contingency plans. Identify Product Interfaces The design team will identify the interfaces while deriving the High-Level Design Document from the architecture diagrams, and conduct periodic design reviews and discussions with the appropriate stakeholders to identify all interfaces. The design team will identify the complexities, technical problems, and dependencies between the different product/system components that need to be integrated. Develop Build/ Buy/Reuse Options The design team will identify if there are multiple commercial off the shelf software (COTS), or customizable COTS products and components available to meet the requirements of some components of the system. As discussed in Section 0, an evaluation of which parts of the system can be re-used or modified should be done. The team should also identify which parts of the system will need new development to complete the architecture developed in section 0.

99 Update Requirements Traceability Matrix (RTM) for System Requirements The High-Level Design Document and the System Requirements Specifications will be reviewed together with the design team and stakeholders to verify that the proposed system of system solution satisfies the system requirements. Preliminary Design Review (PDR) The Preliminary Design Review is a meeting with the stakeholders and the design team to review and approve the preliminary design. The goals of the PDR are to: • Verify the technical content of the design document and its interfaces are complete and traceable • Ensure the selected design methodology has been followed in producing the architectural design • Obtain approval from the stakeholders to proceed into detailed design Update Preliminary Design Document Based on the output of the PDR, the design team will update the design document based on the feedback received from stakeholders and will resolve the technical and design related issues that arise due to the feedback. Baseline Design and Bill of Materials The design team will verify the review feedback has been incorporated into the design document and then send the documents to stakeholders to obtain formal approval to baseline the Design Document and Bill of Materials (BoM) and communicate the availability of the Final Design Document to all stakeholders. System Gaps Identification and prioritization of system gaps found in the ConOps and design phases of the ICM development provide the first steps in ICM implementation planning. Gaps should include field infrastructure, data sources, and agreements necessary for the ICM program and systems to operate more effectively. Major Issues and Challenges Almost every location that has planned or implemented ICM has found gaps in their field infrastructure, in the data provided by stakeholder systems, and their operational policies. Both the Dallas and San Diego ICM deployments received additional funds to deploy vehicle occupancy detectors for transit vehicles, so that the real-time passenger counts were available when considering transit diversion as a potential strategy. The Florida Department of Transportation (FDOT) District 5 ICM program is considering a policy change that will allow detour route recommendations to be provided on their DMS. The current policy is to provide general “Use Alternate Routes” guidance, rather than providing specific detour routing. System Gap Checklist • Document current and planned devices within corridor. • Document remaining implementation strategies and plans into an implementation plan. • Document areas that need additional infrastructure to provide effective responses.

100 Potential Solutions Through the development of the concept of operations and implementation plan, stakeholders should develop a list of current systems, data, and policies that impact ICM operations. Based on the overall concepts and strategies, agencies need to identify the gaps within their systems and infrastructure that would prevent them from implementing the strategies associated with ICM. Many improvement projects have direct impacts on the operations of ICM programs, including projects in the following categories: • Projects that fill in gaps within existing Intelligent Transportation System (ITS) deployments by completing critical systems • Projects that enhance interagency cooperation • Projects that increase the reliability of the existing transportation system • Projects that promote multimodal usage Infrastructure Gaps As part of the strategies identified within the ConOps, identification of field infrastructure improvements may be necessary. These include communication to devices, additional or upgraded devices (i.e., Traffic Signal Controllers, DMS), and detectors. Data Gaps Data is the key element of most multimodal, multiagency ICM systems. During the planning and development of an ICM system, data will most likely be the most challenging and time consuming for the development team. A data dictionary should be developed early in the planning process to document all data types, elements, and formats so that the development team can use a common format for all data that will be used, and the interfaces between systems are developed. Additionally, gaps in the data needed for ICM operations should be identified early in the planning process, and potential solutions explored. For instance, the US-75 ICM program initially planned to use the Texas Department of Transportation (TxDOT) Center-to-Center for all data. Once design and development began, the resolution and content of the data was found to be insufficient for some of the ICM operations. Within the C2C system, lane speeds and volumes were averaged across all lanes, while the ICM system needed each lane’s data separately for model calibration and validation. “Real-time” transit vehicle location and occupancy information was not available, so the USDOT provided additional funding to install a cellular based Automated Vehicle Location (AVL) system on the DART light rail vehicles, and automated passenger counters to provide occupancy. The system provides updates to the ICM system every 60 seconds, which was found to be enough for the ICM operation. Policy Gaps The most common policy issue to occur in the locations that have planned and implemented ICM is providing specific alternative route recommendations to the public. Many areas have policies that prevent specifying detour routes due to liability. The San Diego ICM program deployed permanent trailblazer/wayfinding signs along detour routes, which provided turning and route guidance to travelers. Additionally, all projects associated with ICM should be planned and programmed in the TIP of the local MPO or through the STIP. Implementation Planning This section discusses the development of an implementation plan that supports the ConOps and provides guidance on the immediate next steps required for agencies to successfully deploy the ICM system.

101 Major Issues and Challenges Once stakeholders are supportive of the ICM project, the ICM concept has been developed, and expected benefits of the system have been assessed, one of the next major challenges is to determine which agencies will provide resources or initial funding for preliminary activities. Often, an ICM project will be funded incrementally, which can add complications and uncertainty to the project schedule. And many times, ongoing operations and maintenance costs for the ICM system are not factored into the overall project cost estimates. Ongoing operations require ongoing funding, so it is necessary for ongoing sponsors to pay to support the system. Procurement is a state of the ICM planning process that is not explicitly shown in the systems engineering “V-Diagram,” it is something that the ICM team needs to think ahead for. According to the USDOT, historically, the procurement of goods and services to support ITS deployments represents a major obstacle for transportation agencies responsible for deploying complex information technology systems. NCHRP 03-77 Guide to Contracting ITS report15 states that the use of inappropriate procurement methods may result in project cost-overruns, final designs that do not satisfy functional requirements, and long-term maintenance failures. An appropriate method of procuring ITS (including ICMS) must be flexible enough to accommodate the uncertainties of complex system acquisitions, while at the same time rigid enough to ensure that the responsibilities of the participants are fully defined, and their interests protected. To overcome the challenge of procuring ITS, transportation agencies must institutionalize innovative procurement methods. Implementation Plan An implementation plan is not required by the “V-Diagram” but is critical for the successful implementation of an ICM project. The implementation plan supports the ConOps and builds on the High- Level Requirements document developed for the ICM system. The purpose of the plan is to foster improved interagency planning and operational coordination, ITS interoperability, and intermodal connectivity and management of the ICM assets. While there is no standard outline for an implementation plan, subtasks in Task 10 such as project sequencing, funding strategies, and procurement mechanisms all belong in this document, if it was not already covered in the SEMP. Other sections relevant to an implementation plan include, but are not limited to: • Implementation Strategy – FHWA’s Integrated Corridor Management: Implementation Guide and Lessons Learned report recommends a seven phase ICM Implementation Process, as reiterated in Figure 21. 15 National Cooperative Highway Research Program, Guide to Contracting ITS, NCHRP Project 03-77, 2006.

102 (Source: FHWA’s Integrated Corridor Management: Implementation Guide) Figure 21. Integrated Corridor Management Implementation Process Phases • Definitions for all Projects and Project Tasks – All work tasks and activities needed to accomplish the ICMS goals need to be defined, including, but not limited to, overall project management, construction management, testing and acceptance, participation in training, and other administrative tasks such as financial and contract support. • Cost Estimates/Funding Sources – The costs for each project and the associated tasks need to be estimated (including contingencies) and funding sources and responsibilities identified. • Needed Resources – The resources for each task, including which agencies are responsible for providing these resources, must be identified and obtained. This may include personnel, equipment, test equipment, and other facilities. The time frame for when these resources are needed also is identified. • Project Sequencing and Schedule – An understanding of the individual ICMS projects and their dependencies, the associated project tasks, and the needed resources and budgets are combined into an ICMS Program Schedule, showing key milestones and inter-dependencies between projects and tasks. • Procurement Strategy – Decisions regarding which ICM system sub-components will be developed in-house vs. contracted out to another agency, consultant, or system integrator. Deciding which sub-components will be grouped into each contract is also necessary. • Performance Management – The work done in Phase 7 to designate performance metrics and data sources can be formally documented here in the implementation plan. Example ICM Implementation Plans include the following: • Broward County Metropolitan Planning Organization and Florida Department of Transportation, Broward County Interstate 95 Integrated Corridor Management Plan, Implementation Plan, February 2018. • Virginia Department of Transportation, Northern Virginia East-West ICM Corridor Planning Study, Implementation Plan, September 2017. • El Paso Metropolitan Planning Organization, Texas Department of Transportation, et. al., El Paso IH-10 Integrated Corridor Management, Implementation Plan, June 2017.

103 Design and Development Planning Checklist • Identify dependencies between ICMS projects to come up with an optimal project sequence. • Explore Federal-aid, state, and local agency funding opportunities. • Obtain funding commitments from as many sources as needed. • Determine which ICMS project(s) will require procurement. • Develop documentation needed to solicit development and deployment services needed. • Document an agreed upon systems engineering process in a SEMP. • Document remaining implementation strategies and plans into an implementation plan. Potential Solutions Project Sequencing The Regional ITS Architecture Guidance Document16 recommends the following activities for the ICM team to define project sequencing: • Gather initial project sequence information from existing regional planning documents. • Define the projects for the corridor in terms of the ICMS architecture prepared in previous steps. • Evaluate each ICMS project, considering: – Costs and benefits – Technical feasibility – Institutional issues – Readiness (agreements in place, funding available, policy decisions, data requirements, etc.). • Identify the dependencies between ICMS projects based on the inventory, functional requirements, and system interfaces. Identify projects that must be implemented before other projects can begin. • Develop an efficient project sequence that takes the feasibility, benefits, and dependencies of each project into account. • Like traditional planning, project sequencing is a consensus building process and should not be viewed as a ranking of projects. Stakeholders should begin with existing planning documents and focus on short-, medium- and long-term planning decisions. Funding Strategies Funding for ICM projects and the ongoing operations and maintenance of the system will likely come from a wide variety of sources, including Federal-aid, state, and individual agency budgets. Just as ICM projects are generally multiagency in nature, the funding for these types of projects tends to also come from multiple agencies. Several available Federal grant options include Advanced Transportation and Congestion Management Technologies Deployment (ATCMTD) and Infrastructure for Rebuilding America (BUILD). However, the ATCMTD grant program is anticipated to end in 2020, after the fifth and last round of grants is issued, and only one project for ICM has been selected per year. ICM projects can be funded as part of the traditional Federal-aid highway program.. Some areas have begun to use the metropolitan planning organization (MPO) to consolidate funding for ICM programs. In San Diego, the MPO (SANDAG) was the lead agency and continues to fund the program. In Dallas, the ICM program has transitioned from the Dallas Area Rapid Transit (DART) to the North Central Texas 16 National ITS Architecture Team, Regional ITS Architecture Guidance: Developing, Using, and Maintaining an ITS Architecture for your Region (Version 2.0), July 2006.

104 Council of Governments (NCTCOG) to manage and coordinate funding for the program. TxDOT has continued to provide funding for a large portion of the project and has provided NCTCOG funds for parts of the 511DFW systems. Procurement Mechanisms Typically, the initial development and deployment of an ICMS will entail multiple projects, with each project requiring a specific form of stand-alone procurement documents covering a subset of the complete system design. Potential ICM projects may span a wide range of technology procurements, including, but not limited to17: • Procurement and deployment of additional ITS field devices (such as CCTV, surveillance, and DMS) along the various networks and cross-network connections. It is also possible that this specific activity may involve multiple projects, with each agency having a project covering its specific network. • Installation or expansion of a communications network connecting the various Transportation Management Centers serving the corridor. • Infrastructure improvements such as minor roadway widenings, expansions of park and ride lots, etc. • Central hardware procurement (several agencies often purchase servers, workstations, and related equipment off an agency or statewide contract). • Software development, including new ICM software programs and enhancements to existing network-specific software and firmware. • Systems integration. The ICM team needs to decide which activities should be done in-house by the system’s owner’s organization and which activities should be done by another agency, consultant, or system integrator. The decision model to identify an appropriate procurement approach proposed by NCHRP 03-77: Guide to Contracting ITS report includes the following activities and considerations: • Making fundamental decisions, such as the possibility of outsourcing and the procurement of consultant services. • Determining whether the procurement should be performed as a single contract or multiple contracts. • Categorizing the project with respect to complexity and risk. • Assessing transportation agency resources and capabilities as well as the environment in which the project will be procured. • Selecting the applicable systems engineering processes and candidate procurement packages, and then applying differentiators to the candidate procurement packages to reduce their number. • Involving agency procurement personnel to assist in making the final selection of the most appropriate procurement package. • Selecting the necessary terms and conditions to be included in the contract. • Determining whether a system integrator is needed to deliver a fully functional ICMS. ICMS procurement documents should include specifications and plans addressing critical elements of the ICMS implementation, including the following: • The integration of all the hardware, software, and/or database components into a fully functional ICMS, including responsibilities for developing and inputting ICMS and individual network system database information (e.g., response plans, any graphic displays). • The testing procedures, including criteria for acceptance of each component, subsystem, and system. These specifications should also address who is responsible for developing and approving the 17 Accessed at: https://ntlrepository.blob.core.windows.net/lib/jpodocs/repts_te/14284_files/chapter_7.htm.

105 test procedures, who is responsible for conducting and monitoring the test, and procedures in the event a test is not completed successfully. • The training and documentation that are to be provided by the hardware and software suppliers and the system integrator, and when they are to be delivered. • Warranties and ongoing system support. • Intellectual property. • Licensing agreements for pre-existing technologies and privately funded developments brought to the ICMS project and hardware and software developed during and for the ICMS project using public funds. Summary and Conclusion For planning for the design and development of the ICM system, stakeholders need to consider the technical aspects of integration, the gaps in their systems that need to be corrected, and the system validation and verification processes that should be followed. This chapter has provided some of the key design and deployment processes for an ICM, and the processes and plans agencies should perform in preparing for design and deployment. This chapter has provided some of the lessons learned from other agencies who have implemented ICM, the key questions agencies need to ask to decide how they want to implement ICM, and which components of an ICM will best fit their needs and requirements.