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).
