Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 66
66 Cargo Documentation Freight Transportation Role Component Documentation Documentation Freight Data Documentation Freight Data Data Model Standard Documentation Documentation Data Source Documentation Business Process A Documentation Business Process B Documentation Business Process C Documentation Business Process D Documentation Figure 12. National freight data architecture component conceptual model. · A cargo or freight component can be associated with many building the data architecture. The specifications described in physical transportation components and/or freight func- this section are as follows: tions or role components. · A physical transportation component, a cargo or freight · Compare candidate data architecture implementation component, and a freight function or role component can concepts; produce freight-related data. Likewise, freight-related data · Develop implementation plan for national freight data can be associated with many physical transportation com- architecture components; ponents, cargo or freight components, and/or freight func- · Develop lists of components to include in the national freight tion or role components. data architecture; · Develop and implement protocols for continuous stake- holder participation; National Freight Data · Conduct data gap analysis; Architecture Specifications · Conduct data disaggregation need analysis; This section describes some of the most relevant specifica- · Assume a distributed approach (as opposed to a centralized tions to implement and develop the various national freight approach) to freight data repository implementations; data architecture components described in the previous sec- · Use a systems engineering approach for developing the na- tion. Readers should note that the list of specifications is pre- tional freight data architecture; liminary and might need refinement during the process of · Use standard information technology tools and procedures;
OCR for page 67
67 · Develop and/or use standardized terminology and defini- selected. An idea discussed was to develop the data architecture tions for each data architecture component developed; around scenarios or themes, such as business areas or pro- · Implement strong privacy protection strategies; and cesses, levels of government, and/or economic activity. Partic- · Establish integration points with other data architectures ipants identified four potential scenarios or themes, including and standards. MPOs, the private sector, cross-border trade (e.g., Washington State and British Columbia, or Texas and Mexico), and multi- state freight (e.g., I-95 corridor, Great Lakes region). Activities Compare Candidate Data Architecture and requirements in connection with each of these scenarios or Implementation Concepts themes would include structuring a competition for research As previously mentioned, there are several potential imple- teams (each of which would include a university partner, a mentation levels for a national freight data architecture, in- private-sector partner, and a government-level partner) to cluding the following: develop and test competing data architecture concepts, mak- ing sure to include multimodal components in the scenarios · Single-application approach. In this case, the national and tests, and to conduct a follow-up evaluation. The final step freight data architecture would become the manner in would be to merge the best concepts and practices into one which data elements are organized and integrated for a spe- composite program. cific freight application or business process at the national level (e.g., commodity flows). Develop Implementation Plan for National · Intermediate approaches (depending on the number of Freight Data Architecture Components applications). In this case, the national freight data archi- tecture would become the manner in which data elements Part of the analysis will include developing a plan for are organized and integrated for a specific set of applications component implementation depending on the selected data at the national, state, regional, and local levels. architecture implementation level(s). The plan, which should · Holistic, all-encompassing approach. In this case, the na- include both short-term as well as long-term activities, will tional freight data architecture would become the manner enable stakeholders to measure implementation progress and in which data elements are organized and integrated for all identify corrective actions if needed. The plan should include, freight transportation-related applications or business pro- at a minimum, the following activities: cesses at the national, state, regional, and local levels. · Develop lists of components to include in the national It is not necessary to evaluate all of the candidate implemen- freight data architecture; tation levels. However, as the development of the National ITS · Develop and implement protocols for continuous stake- Architecture demonstrated, comparing various data architec- holder participation; ture concepts enabled the ITS community to develop a better · Conduct data gap analysis; understanding of the issues, which, in turn, facilitated the · Conduct data disaggregation need analysis; decision of which data architecture to pursue. In the case of · Develop, test, and validate data models; and the national freight data architecture, it is reasonable to expect · Develop an implementation schedule, including both short- a scalable implementation path that starts with one applica- term as well as long-term activities. tion at one or two levels of decisionmaking and then adds ap- plications and levels of decisionmaking as needed or accord- This chapter describes some of these activities in detail. ing to a predetermined implementation plan until, eventually, reaching the maximum net value. As previously mentioned, Develop Lists of Components to Include data about benefits, costs, or complexity for each level of im- in the National Freight Data Architecture plementation that might enable a quantifiable determination of value are currently not available. Conducting appropriate Following Figure 10, the national freight data architecture benefit-cost analyses to obtain this type of information is a should include one or more of the following categories of necessary activity that needs to occur both at the beginning components (depending on the results of the data architecture and at different phases of implementation of the national comparison analysis above): freight data architecture. A peer exchange recommendation was to use NCFRP as a · Physical transportation components. The physical trans- mechanism for funding the development of alternative data portation components refer to all the components used to architecture concepts and prototype. Participants indicated transport cargo or freight. For each component, it will be the request for proposals should outline clear objectives, while necessary to identify the relevant data models to include in leaving the definition of approaches to the research team(s) the data architecture, using as a reference existing systems
OCR for page 68
68 and databases. Examples of components (which could in- · Business processes. Business processes refer to the various clude subtypes to provide adequate disaggregation level types of activities that different stakeholders have in rela- support) include the following: tion to freight transportation. Depending on the data ar- Vehicle, chitecture implementation level selected, this part of the Container, analysis will include developing formal representations of Transportation network, and freight-related business processes using industry-standard Traffic control system. business process modeling tools. Examples of high-level A mode of transportation describes a functional combi- business processes (which could include subtypes to pro- nation of vehicles, containers, transportation network, and vide adequate support for business processes at different traffic control. Common modes of freight transportation in disaggregation levels) include the following: the United States are air, rail, truck, pipeline, and water. The Commodity flows; developer should note that some applications (e.g., CFS and Congestion management; FAF) use special mode of transportation designations for Customs processing; intermodal movements that do not necessarily conform to Development and economic incentives; the definition above. The national freight data architecture Economic analysis and impact; will need to handle these special cases at the data model level. Energy and climate change; · Cargo or freight. Cargo or freight refers to the various com- Environmental impacts; ponents that describe the goods being transported. For each Hazardous material handling; component, it will be necessary to identify the relevant data Incident response; elements to include in the data architecture, using data ele- Industry and state needs; ments already included in existing standards (e.g., EDI International trade; standards) as a reference. A small sample of components in Logistics management; this category, which could be expanded as needed, includes Marketing and grant funding; the following: On-board security monitoring; Bill of lading, Planning and forecasting; Commodity, Policy development; Invoice, Roadside safety inspection; Item or product, Routing and dispatching; Purchase order, Safety analysis; Shipment, and Transportation infrastructure analysis, design, and Waybill. construction; · Freight functions or roles. Freight functions or roles refer Transportation operations; and to the type of responsibility a stakeholder has in relation to Workforce development and training. freight transportation. Depending on the data architecture One of the first activities while developing the national implementation level selected, this part of the analysis will freight data architecture will be to assemble a prioritized include developing a map of functions and the typical kinds list of business processes for implementation. of freight data that each function requires. A situation in · Data sources. Data sources refer to systems, databases, which this type of mapping is necessary is when trying to data collection programs, reports, and other similar prod- identify different levels of data access to different stake- ucts and activities that can be sources of freight data. Ex- holders. Examples of roles (which could include subtypes amples of data sources (which could include subtypes to to provide adequate support for roles at different disaggre- provide adequate support for data sources at different dis- gation levels) include the following: aggregation levels) include the following: Analyst, Administrative records, Carrier, Census, Fixed infrastructure manager or operator, Data standards, Planner, Mandatory reporting required by laws and regulations, Policymaker, Surveys, Producer or manufacturer, Other private-sector data, and Regulator, Other public-sector data. Researcher, It will be necessary to develop a properly cross-referenced Shipper or receiver, and index of data sources, using as a foundation already existing Third-party logistics or broker. systems such as BTS's TranStats (137). One of the activities
OCR for page 69
69 to complete will be to formulate recommendations for po- · Freight data models. Freight data models refer to the set of tential upgrades to TranStats to include other freight-related data models needed to represent freight data characteristics data sources, including state agencies and private-sector data and processes. Depending on the level of freight data archi- sources. Based on experiences with other systems and ar- tecture implementation selected, this part of the analysis chitectures (e.g., the National ITS Architecture) one of the will include selecting, developing, testing, and validating the requirements in this area also will be to include archived corresponding data models needed. Typical data models freight data capabilities in the data architecture. might include the following: · Freight-related data. Freight-related data refer to the var- Business process model, ious types of data that can be associated with each of the Conceptual data model, components previously mentioned (i.e., physical trans- Logical data model, portation components, cargo or freight, business functions Physical data model, and or roles, business processes, and data sources). Freight- Data dictionary. related data can be associated with just one component or An alternative (or complement) to a data dictionary is in connection with the interaction between two or more a metadata document (138). Examples of metadata stan- components. For example, in the supply chain, a product dards at the federal level are CSDGM (106), described ear- or order must have relevant information about different re- lier, and the Metadata Encoding and Transmission Stan- quirements, situations, and conditions that might influence dard (METS) (139). METS, which is maintained by the the movement from origin to destination. This information Library of Congress, is a standard for encoding descrip- is needed for a variety of reasons, including payment, ship- tive, administrative, and structural metadata about library ment, safety and recall purposes, and documentation to objects. affected stakeholders. · Freight data standards. Freight data standards refer to Some of the most commonly used types of freight data, documents that include specific requirements about struc- as well as types of freight data that users do not have but ture, syntax, and content of freight data. The developer of would see benefit in having, include the following (while the national freight data architecture will not be responsi- developing the national freight data architecture, it will be ble for developing freight data standards. However, at a necessary to assemble a comprehensive inventory of freight minimum, the data architecture developer should formu- data types and prioritize those types for implementation): late recommendations for communication protocols with Descriptions of products shipped or received; organizations responsible for developing relevant data Shipment origins and destinations; standards and include "place holders" for data standard Shipment weight; cross-references in the data architecture. Examples of data Freight volumes; standards that pertain to freight information include the Manifests and waybills; following: Carrier used; Commodity and product classification standards Railroad tonnage data; CPC Commodity inventories; HMIS Licensed carrier data; HS Vehicle inventories; NAPCS Business directories; NMFC Employment by freight activity; NST 2007 Import and export statistics; PLU Mine output data; SCTG Economic data; STCC Transportation infrastructure inventory and condition; Industrial classification standards Pipeline volumes; ISIC Traffic volumes; NAICS Distribution warehouse truck traffic data; SIC Travel time, speed, and delay data; SITC Traffic bottlenecks; Data exchange standards Oversize and overweight permitting and routing data; ANSI ASC X12 standards Safety data; UN/EDIFACT standards Fuel statistics; and OASIS UBL standards Emissions data and estimates. FIPS PUB 161-2
OCR for page 70
70 National ITS standards · Identify and address buy-in and consensus issues, FGDC-sponsored standards (including metadata) · Identify and develop working relationships with data ar- Other standards chitecture champions, ITDS SDS · Develop a "showcase" to bring attention to the issue of METS freight data, and Vehicle classification standards. · Develop a roadmap for collaboration between the public sec- · User interface and supporting documentation. User in- tor and the private sector for more effective data collection. terface and supporting documentation refer to the system components and materials needed to present and dissem- Conduct Data Gap Analysis inate information about the data architecture effectively. As the previous chapter shows, which confirms the find- This report documented the results of a literature review, ings of several reports, freight data are scattered across many surveys, and follow-up interviews with a number of freight systems, jurisdictions, and business processes. Having an stakeholders, primarily planners, shippers, and motor carri- information clearinghouse that describes these freight data ers, to identify user and data needs. Targeted data gap analy- sources and how they relate to the national freight data ses may be necessary to more precisely characterize user architecture will be critical to assist in the process of under- and data needs. This report identified (or further expanded standing and developing the data architecture. Depending on) a few areas where there are freight data gaps. Some gaps on the data architecture implementation level selected, it are related to limitations of current survey-based data col- will be necessary to develop interfaces and materials such lection programs. Other gaps are related to limitations in as the following: supply chain data processes or to the high degree of special- Web-based information clearinghouse. The purpose of ization of certain processes (e.g., shippers may have com- the web-based information clearinghouse is to describe modity data at a high level of disaggregation, but carriers and explain the various components of the national do not need that level of commodity disaggregation to con- freight data architecture interactively. Examples of sys- duct business transactions). tems that can be used as a reference to build this Web- Part of the process to identify data needs will be to develop site include the National ITS Architecture Website (87) a thorough understanding of the relationship between freight and TranStats (137). Companion documentation to performance measures (many of which are still in the research the Web-based system could include data models (see and development phase) and the data needed to support those above), system design documents, and other standard measures. reference materials. Outreach and training materials. Examples of outreach Conduct Data Disaggregation and training materials include brochures, summaries, Need Analysis presentation files, instructor notes, and handouts to as- sist in the process of disseminating information about Plenty of documents provide information about the lim- the national freight data architecture for use in venues, itations of current freight data collection programs, adding such as conferences, workshops, and courses. weight to the idea that current data sources are not suffi- ciently accurate or detailed. The data resolution issue is par- ticularly critical because no statements are currently avail- Develop and Implement Protocols for able that outline (1) the required data disaggregation and Continuous Stakeholder Participation accuracy levels to address current and anticipated data col- Lack of proper stakeholder participation is one of major rea- lection needs from a technical and statistical perspective and sons for systems to fail. The developer of the national freight (2) the corresponding impacts of those requirements on data architecture should develop channels of communication data collection costs and privacy requirements. Developing and mechanisms to ensure and document the participation of those statements is critical in order to identify data collec- stakeholders at every step during the development of the data tion requirements. architecture. Specific requirements, in addition to those in Dimensions to freight data disaggregation could include connection with the implementation of the information clear- areas such as commodity type disaggregation, geographic inghouse and training materials, include the following: disaggregation, temporal disaggregation, financial data dis- aggregation, operating data disaggregation, and privacy re- · Articulate messages clearly, quirements. Conducting the data disaggregation analysis is · Provide clear, uniform guidance, a significant effort. (Note that NCFRP Project 20 will address · Develop communication and marketing strategies, the issue of commodity flow geographic disaggregation).
OCR for page 71
71 Assume a Distributed Approach (as Opposed the country. Considering the complexity that characterizes to a Centralized Approach) to Freight Data freight data processes, it would be advisable to use a systems Repository Implementations engineering approach for the development of the national freight data architecture (and any system implementation As previously mentioned, freight data are scattered across that could result from that effort). Key systems engineering many systems, jurisdictions, and business processes. This prac- principles that could apply to developing the national freight tice is not likely to change any time soon. The availability of data architecture include the following (140): computerized processes that automate the collection and transmission of freight data will continue to increase--and · Keep an eye on the finish line, the freight community should strive for continuous improve- · Stakeholder involvement is key, ment and optimization of those processes. However, in the · Define the problem before implementing the solution, short to mid term, the chances for freight data exchange pro- · Delay technology choices, grams to succeed will depend greatly on the identification of · Divide and conquer, and integration points among disparate data systems; documenta- · Connect the dots--maintain traceability. tion of the location, characteristics, and limitations of those in- tegration points; and the development of tools and processes Another tool in systems engineering that is frequently used, (e.g., data conversion tools and survey tools) to facilitate data the "V" diagram (Figure 13), could also be used for develop- exchange. ing the national freight data architecture (140). The V diagram shows the steps for developing systems, including the integra- Use a Systems Engineering Approach tion of validation activities throughout the process. for Developing the National Freight Data Architecture Use Standard Information Technology Systems engineering is an interdisciplinary approach to Tools and Procedures project development that focuses on the identification of user In addition to the requirement to use a systems engineering needs and required functionality early in the development approach is the requirement to use industry standard informa- process, documenting those requirements, and executing sys- tion technology tools and procedures (including data model- tem verification and validation plans at different points dur- ing, database, and software development tools) to develop the ing the development (140). Systems engineering is frequently various components of the national freight data architecture. used for the development of complex engineering and soft- The choice of tools will need to take into consideration exist- ware projects, including many ITS implementations around ing federal-level enterprise architecture requirements (141). Figure 13. Systems engineering "V" diagram (140).