6. Design
The design phase of the ICMS development effort defines the details of how the system requirements will be satisfied. The FHWA course on systems engineering defines system design as the "appropriate selection of system components and their interconnection so as to meet the system requirements." As shown in the "V" diagram (Figure 1-2) and in Table 1-1, the design phase consists of two phases:
- High-level Design (System Architecture).
- Component-level Detailed Design.
It is important that the results of these design efforts be documented (i.e., design reports) and provided to corridor stakeholders for review and comment. This should include extensive design reviews, such as presentations and walk-throughs, between the design team and stakeholders to ensure that the design approach, system architecture, information flows and interface standards, component designs, etc. are consistent with the ICMS needs and stakeholder expectations. The ICMS integrators and integration testers should also be engaged to review the design and interface specifications and to begin developing plans and test-cases for ICMS integration and integration-testing.
The ICMS traceability matrix, as noted in chapter 5, should also be expanded to map the system and component designs back to the ICMS requirements, thereby documenting their compliance with the ICMS needs and objectives.
High-Level Design
The high-level design stage defines the ICMS architecture. This process includes the development of alternative architectures and their evaluation in terms of functionality (i.e., the ability to provide the selected ICM operational strategies and satisfy the ICMS requirements), performance, cost, and other issues (technical and institutional). Both internal and external interfaces, including the existing network-based ITS systems that will be integrated into the ICMS (i.e., a "system of systems"), and needed industry standards are identified during this step.
Defining Interfaces
The Regional ITS Architecture Guidance Document (Reference 8) describes a process for "Define Interfaces" that is directly applicable to a corridor and an ICMS. This process focuses on identifying the interconnects between the systems and subsystems within the corridor and defining the information that flows between the systems. Specific activities (tailored for an ICMS) are summarized in Table 6-1.
Part of this process is to define the information exchanged between the network-based ITS systems, the ICMS, and appropriate subsystems. In the context of an ICMS, this information will include data (e.g., traffic flow and transit status, incident information, device status, command and control functions), video, and voice. These information flows depict the corridor integration by illustrating the information links between networks and agencies within the corridor. As previously discussed, this integration is not only technical, but operational and institutional as well. The system interfaces that are defined require cooperation and the distribution of shared responsibilities on the part of the owners and operators of each participating system.
Identify Connections:
|
Topology
An important aspect of a system architecture is its overall "topology"; that is, the structure defining the paths and switches that provide the communications interconnection among the nodes (systems and TMCs) of a network, and defining the functional responsibilities of each node. It is an axiom of network design that the relationship between computers (i.e., systems) should mimic the organization it serves. Several topologies exist, but given this axiom, the most likely to be found in a corridor-based center-to-center network are "hierarchical" and "mesh," as summarized below:
- A mesh organization is one in which all participants are peers. All computers in the mesh can essentially access the same types of information. This type of communications is similar to the Internet, in that any center can request information from, or provide information to, any number of centers. This is the likely approach for an ICMS architecture where no corridor operating entity (i.e., "corridor manager") exists; that is, all agencies and systems must interact on an equitable basis (and managed via working groups). However, even in a peer-to-peer topology, there may be restrictions on the types of information that can be accessed by certain participants (e.g., control of individual devices).
- In a hierarchical organization, the "boss" should have access to the top computer in the network. Such a topology might be used where a corridor organization exists that oversees and/or coordinates corridor operations and the deployment of strategies on an on-going basis.
An ICMS may utilize a mix (i.e., hybrid) of topologies; for example, most information flows (traffic flow and transit status, device status, incidents) may conform to the mesh organization, whereas command and control during specific events may be implemented by a hierarchical organization.
A related issue is the use of "hubs" to tie the systems or centers together and how to incorporate them in the ICMS architecture. For example, all information exchanges between the corridor stakeholders and their systems could go through a hub, and in some corridors, the hub(s) may be viewed as a key component of the ICMS architecture, (perhaps functioning as the ICMS Control Center). Explicitly including hubs in the architecture has an ancillary benefit in that such architectures normally have fewer connections and information flows to define and maintain than equivalent architectures that depict the point to point connections between all systems served by a hub. Other corridors may decide that a hub is really a part of the communications infrastructure implementation and therefore should not be reflected in the interfaces defined in the architecture. Both views are valid. A major consideration is the functionality (if any) that the hub includes. A hub that implements ICM functions (e.g., data translation and aggregation, decision support) should probably be included in the ICMS architecture, while hubs that only implement communications functions (e.g., routing, protocol conversion) may be excluded. Regardless, the architecture should reflect the stakeholders' "natural" view of the systems in the corridor and ICM. If the hub is largely transparent to the stakeholders, then it probably should be transparent in the architecture. If it is viewed as an integral part of the overall ICMS, then it should be included as an important part of the architecture.
ICMS Standards
ITS standards need to be identified for each information flow. Of particular interest are the numerous standards that have been developed (and continue to be enhanced) to accommodate the diverse needs of various subsystems and user services of the National ITS Architecture. These ITS standards are intended to handle these needs in two areas: center-to-field (C2F), and center-to-center (C2C), with C2C communications focusing on messages sent between two or more transportation management systems. Several sets of C2C standards have been developed, including:
- NTCIP (National Transportation Communications for ITS Protocol) suite of standards for data exchanges between centers.
- TCIP (Transit Communications for ITS Profiles) family of standards for the automated exchange of information in transit applications.
- IEEE family of standards for incident management communications.
- ATIS standards for data exchanges to support traveler information.
While the focus of ICMS is center-to-center, C2F standards may also need to be addressed in the architecture, particularly for those strategies geared toward improving the operational efficiency of the network junctions (e.g., signal priority for transit, coordination between arterial signals and ramp meters).
Standards for sharing video between corridor systems and stakeholders should also be defined. There are several options to consider, including analog and digital (e.g., MPEG, JPEG, and H.261). New processes such as Video over IP (Internet Protocol) and streaming video allow for the broadcast of video incident images to many user agencies via low-cost communication networks.
Legacy Systems
One of the basic assumptions behind Integrated Corridor Management is that the individual agencies within the corridor are already actively managing their respective networks via ITS systems. As such an ICMS will probably involve several "legacy" systems. A legacy system is, by definition, currently operational and may represent the latest technology embodying the principles of open architecture; however, it may be a closed system with proprietary interfaces, databases, and protocols, as well as limited documentation. In the latter case (i.e., proprietary), full center-to-center integration may not be possible, in which case a simpler system interface (e.g., separate workstation, separate email or browser interfaces) may be the most appropriate approach. Even if the legacy system is not completely closed (as compared to an open systems architecture), it still may be necessary to add a data exchange protocol to the legacy system to facilitate information exchange.
Another consideration is that no single C2C standard exists for an Integrated Corridor Management System. There are, in fact, many such C2C standards to consider (NTCIP, TCIP, IEEE). This leads to a potential issue of "semantic interoperability" between these various C2C standards; that is, are the common data elements and message sets defined in exactly the same way. It may be necessary to incorporate "translators" into the ICMS design that will enable a legacy system to present a standard interface to the other systems and the CCC in the generic corridor. Some translation may also be needed between data elements within different standard messages, although over time, further harmonization of the standard data elements by the standards development organizations should eliminate any such need. It will also be necessary to ensure that all of the desired information and data elements necessary to support the ICM strategies are covered by these standards and their respective data dictionaries and message sets.
Deployment of an integrated corridor management system should use the various C2C standards as appropriate to the individual networks and their respective stakeholders. The integration of an ICMS will likely involve some degree of C2C harmonization (i.e., developing unique corridor-specific translators to define the data being exchanged by systems), particularly where C2C communications and standards are already in place and if automated decision-support mechanisms are going to be used for corridor response plan management. As experience is gained with these C2C translations, the various standards may evolve to provide the necessary harmonization of the data dictionaries and message sets required to minimize the effort needed for corridor integration.
A related issue involves the interfaces to CAD systems that are used by public safety agencies. Many of these are proprietary systems. Moreover, regardless of how these CAD systems are integrated into the ICMS, the interfaces must include appropriate filters to prevent sensitive information from being released, shared, or otherwise compromised.
Finally, it must be remembered that the regional ITS architecture development process includes the identification of specific standards and protocols for communications and information exchange between systems. These regional standards and protocols should serve as the foundation for defining the ICMS C2C linkages, interfaces, and standards, and the selected ICMS standards should be compatible and consistent with the regional standards, whether this involves making adjustments to the recommended corridor standards, regional standards, or some combination of the two.
Detailed Design
During detailed design, each system and sub-system is decomposed into components of hardware, software, database elements, firmware, and/or processes. Component designs then describe in great detail how each component will be developed to meet the required functions of the system, resulting in "build to" specifications and plans that will be used to build or procure the individual components. For hardware components, this step will describe the components and the associated technology in enough detail to be fabricated or purchased. For software, enough detail will be given such that developers can design and then write the individual software modules. If commercial-off-the-shelf equipment is being used, this step is where the alternative candidate products are evaluated and a selection made.
The detailed design activities must also address any additions and enhancements that are required to the existing network-based ITS systems for Integrated Corridor Management. These might include additional field components (surveillance, DMS, CCTV) along the network, the cross-network connections, and/or the network interfaces (e.g., park & ride lots), additions to the central software (e.g., protocol translators), enhancements to the central hardware and software (e.g. upgrading a signal system from a proprietary closed-loop to an "open" and more centralized system to accommodate real-time plan changes), or some combination.
As is the case with all stages of the ICMS life-cycle, stakeholder involvement is a crucial element. This includes periodic technical reviews and a final critical design review to obtain final approval. The types of questions to be addressed at these reviews include: Do the details meet the requirements? Is each component buildable? Are the interfaces and information flows satisfied? Are the details well documented? Do the details of the design map to all allocated requirements (traceability)? Has sufficient redundancy been built into all mission-critical components? etc.