The Integrated Corridor Management: Implementation Guide and Lessons Learned document is intended for use by adopters of integrated corridor management (ICM) approaches and strategies to address congestion and travel time reliability issues within specific travel corridors. It introduces the topic of ICM and identifies the type of information system, known as the integrated corridor management system (ICMS), used to support transportation network managers and operators in applying ICM.
The U.S. DOT partnered with eight transportation agencies in large metropolitan areas, referred to as "Pioneer Sites," to research effective means of implementing ICM approaches in their major travel corridors. The guide discusses lessons learned that arose during the U.S. Department of Transportation’s (U.S. DOT’s) research initiative.
System architectures can be described from many perspectives using various methods and modeling techniques. Some are described as logical or functional views, physical views, operational views, communications views, and security views. Details of these views can be captured in data, process, and behavior models to aid in the definition of the system. The logical view captures the functions, flows, controls, and decomposition of a system. The following lessons learned apply to developing a system architecture using the logical view for an ICM program.
- Define system boundaries. Gaining agreement on the system boundaries is one of the first steps in initiating the architecture.
- Develop a functional decomposition and requirements hierarchy. Sound methods for functional decomposition and requirements hierarchy should be defined in the SEP section of the SEMP. These methods will serve as the basis for developing the architecture and will be an important guide for reviewers and stakeholders that attend the walkthroughs. Make sure all subsystems are defined and decomposed logically, and make sure internal interfaces are defined for the system.
- Develop a final draft logical architecture before conducting the requirements walkthrough. The final draft architecture will help walkthrough participants to visualize the system and help to verify the functional requirements.
- Define the system and external systems. Do not get overwhelmed by the organization, documentation, and definition of external systems and then run out of gas on the definition of the system itself.
- Maintain logical abstraction when developing the logical architecture. If put in the position where a portion of the system is being reverse engineered, maintain logical abstraction when developing the logical architecture. Do not label the functions in the logical architecture with names that were designated for a completed physical system.