Technical Feasibility Study for the Development of an ITS ...

TP 14519E 

Technical Feasibility Study for the Development of an ITS 

Commercial Vehicle Operations Network for Canada 

Prepared by 

Prepared for 

ITS Office 

Transport Canada 

May 2003

This report reflects the views of the authors and not necessarily those of the ITS Office of Transport 

Canada or the co-sponsoring organizations. 

Une traduction de ce rapport est également disponible en français : Étude de faisabilité technique portant 

sur la mise au point de STI pour l’exploitation de véhicules commerciaux au Canada, TP 14519F. 

ii

Executive Summary 

This technical report provides the results of the Commercial Vehicle Operations (CVO) Feasibility Study 

undertaken by SAIC Canada for Transport Canada. SAIC Canada expresses its appreciation at the 

opportunity to work on such an important project for the future of ITS in Canada. 

The purpose of the study was to: 

1. Determine the technical feasibility of implementing a commercial vehicle network for Canada. 

2. Explore the applicability of the United States Commercial Vehicle Information Systems and Networks 

(CVISN) Level I CVO requirements to the Canadian environment. 

3. Assess current readiness of provincial/territorial commercial vehicle safety systems to share safety 

related information amongst Canadian jurisdictions and with the United States. 

4. Specify the requirements to enable information to be exchanged in near real-time through the use of 

carrier snapshots and make such information available at the roadside. 

5. Evaluate the options and costs for developing a Canadian commercial vehicle operation network and 

propose a road map for its implementation across Canada. 

The results of the study, relative to the above scope, are as follows: 

1. A CVO network is feasible for Canada. SAIC Canada reached this conclusion after an extensive 

literature review, interviews with staff in many Canadian jurisdictions, interviews with US ITS experts 

and administrators involved with CVISN and with the CCMTA secretariat. 

2. While there are many lessons to be learnt from the US CVISN system, CVISN itself has limited 

applicability to Canada due to the different regulatory framework, the volume of traffic and the 

geography. One important consideration that SAIC Canada took into account was the recommendation 

from several sources that Canada adopt a centralised system. However not all lessons were technical. 

SAIC Canada found that institutional issues often create major barriers and hurdles to successful 

deployment and that Canada may wish to consider establishing a program similar to the US 

Mainstreaming Program as a means to facilitate the jurisdictions into a common forum. 

3. There is a broad range of readiness across Canada for a data-sharing network. Many jurisdictions are 

highly automated, while others still use many manual processes. A network can be implemented, but 

will not be fully effective until all jurisdictions reach the same level of automation. Specifically until 

inspections are entered directly into a jurisdiction’s databases and inspection data is available in near– 

real time, the system will only be able to provide good information for vehicles from certain 

jurisdictions. 

4. The technical requirements for sharing snapshots are relatively few, but do include many security 

requirements both to ensure the integrity of the data and functionally dealing with the security regime 

at border crossings. However there are several non-technical requirements that need to be addressed. 

These include standardising the safety rating and developing a common identifier for carriers. In 

addition the question of “ownership” of the network needs to be resolved. SAIC Canada recommends 

the CCMTA take ownership of the network and associated systems as they have all the necessary 

mechanisms already in place. 

iii

5. There are many options for the sharing of CVO data and for the network to support it. SAIC Canada 

recommends a centralised system initially using the existing IRE network. This option has the 

advantage of being the cheapest, while building upon the current IRE network’s capability and the 

knowledge base in the jurisdictions. This should result in the quickest implementation for the initial 

sharing of snapshot data. The cost to develop this system is approximately $1.8M, including costs for 

jurisdictions to update their legacy system appropriately. This does not include any outreach costs by 

Transport Canada, nor any costs for jurisdictions to further automate their existing systems e.g. to 

automate the collection of inspection data at the roadside. Total costs over a five-year period, 

including support, would be approximately $4.6M. The initial implementation would only allow for 

the sharing of carrier snapshots and transponder information, and the generation of alarms based on 

Current Trip Information. This supports the initial implementation of the ECRI system being proposed 

by Tri-Global Solutions in a parallel project. Once the initial system is operational it can be expanded 

to include the sharing of additional information, such as credentialing and can be moved to a Virtual 

Private Network (VPN) to allow for a broader range of web-based features. A VPN can be installed 

for approximately $500k, with some potential savings if the IRE network is also converted. 

In addition SAIC Canada was required to look at various aspects of the security regime at the Canada-US 

border, including harmonisation with the US CVISN system, interfacing with the ITDS, Canada customs 

and Canada/ US immigration. As part of this work, a review was performed of the various organisations 

that compile and/or require information related to the transportation of dangerous goods or hazardous 

materials across provincial and international boundaries. With each organisation, possible methods of 

integrating their information sources within an ITS were discussed, as well as the types of information they 

would find useful to acquire from an ITS. 

SAIC Canada also reviewed the present border regime and reviewed several border crossing initiatives 

aimed at improving border security while speeding up crossing time. However SAIC feels that, given the 

present pace of border crossing initiatives, it would be premature to suggest anything specific that a CVO 

network should contribute. 

SAIC Canada has concluded that a system/network as recommended should be relatively easy to harmonise 

with the US CVISN. The basis of the system is presently the snapshot and the snapshot suggested is based 

on the snapshot currently being used in the US. Additionally, the network can be used to access 

information regarding driver and vehicle and ultimately inspection data for US vehicles. As part of the 

ongoing IRE initiative, CCMTA are working with their US counterparts to make US driver and vehicle 

information available in Canada and vice versa. 

SAIC Canada would like to thank Transport Canada for their support, CCMTA secretariat for their 

assistance and access to information regarding IRE and CDE and to all the provincial members of the 

Steering Committee for their support and their co-operation in establishing interviews with staff in their 

Provinces. The work undertaken in this study established a viable process for the development of a Canada 

wide CVO network that can support the sharing of data and build upon initiatives undertaken over many 

years by the CCMTA. 

iv

Table of Contents 

1 Introduction.......................................................................................................................................1 

1.1 Background.........................................................................................................................1 

1.2 References...........................................................................................................................2 

2 Process ..............................................................................................................................................4 

2.1 Task 1: Consult and Review List of Reports/Documents and Consult with Stakeholders..4 

2.2 Task 2: Define Needs/Requirements...................................................................................5 

2.3 Task 3: Review the current technical state of the province/territory 

CVO safety information systems............................................................................6 

2.4 Task 4: Explore US CVISN Level 1 Capabilities ...............................................................6 

2.5 Task 5: Review Existing Systems Architectures supporting Roadside Operations.............6 

2.6 Task 6: Prepare a Technical Report on the System Architecture for a 

Canada Wide CVO network...................................................................................6 

2.7 Co-ordination with ECRI Cost/Benefit Study.....................................................................6 

3 Analysis.............................................................................................................................................8 

3.1 Jurisdictional Readiness......................................................................................................8 

3.1.1 Assessment of Readiness......................................................................................9 

3.1.2 Summary of Jurisdictional Readiness.................................................................10 

3.1.3 Conclusions ........................................................................................................13 

3.2 US Experience with CVISN .............................................................................................14 

3.2.1 CVISN Implementation – Flexible Approach, Phased Development.................14 

3.2.2 Software Code in Public Domain .......................................................................14 

3.2.3 Institutional Framework .....................................................................................15 

3.3 Current State of Canadian CVO Systems .........................................................................15 

3.3.1 IRE and CDE......................................................................................................16 

3.4 The Transportation of Hazardous Materials .....................................................................19 

3.5 Security Issues at the Canada-US Border .........................................................................21 

4 Requirements ..................................................................................................................................25 

4.1 Functional Requirements ..................................................................................................25 

4.2 Technical Requirements....................................................................................................26 

4.3 Administrative Requirements ...........................................................................................26 

4.4 Institutional Considerations ..............................................................................................27 

4.4.1 Ownership...........................................................................................................27 

4.4.2 Agreements.........................................................................................................27 

4.4.3 Sources of Funding.............................................................................................27 

4.4.4 Data Privacy .......................................................................................................27 

4.4.5 Data Concurrency...............................................................................................27 

v

5 Roadside Access..............................................................................................................................28 

5.1 Data Requirements............................................................................................................28 

5.1.1 Snapshots............................................................................................................28 

5.1.2 Current Trip Information ....................................................................................31 

5.1.3 Recent Inspections..............................................................................................32 

5.1.4 Transponder Database ........................................................................................32 

5.2 Data Exchange to roadside................................................................................................33 

5.3 Data Entry and Access......................................................................................................34 

5.3.1 Data Entry...........................................................................................................34 

5.3.2 Entry Into Jurisdictional Database......................................................................36 

6 Data Sharing....................................................................................................................................37 

6.1 Option 1 – Centralised Canadian Safety and Fitness Electronic 

Records (CSAFER) System ............................................................................38 

6.1.1 Option 1 Description ..........................................................................................38 

6.1.2 Technical Challenges..........................................................................................40 

6.1.3 Snapshot Creation and Updating ........................................................................41 

6.1.4 Roadside Access.................................................................................................41 

6.1.5 Maintenance Plan ...............................................................................................42 

6.1.6 Impediments/Issues ............................................................................................42 

6.1.7 Option 1 Advantages and Disadvantages ...........................................................42 

6.2 Option 2 – Decentralised Carrier Safety Information System...........................................43 








6.3 Option 3 – Regional Motor Carrier Data Safety Information System...............................48 








7 Network Scenarios ..........................................................................................................................53 

7.1 Option 1 Use of the Existing IRE Network ......................................................................53 

7.1.1 Description .........................................................................................................53 


7.1.3 Advantages and Disadvantages of Option 1 .......................................................54 

7.2 Option 2 Intranet-based Virtual Private Network (VPN)..................................................55 

7.2.1 Description .........................................................................................................55 


7.2.3 Use of the Existing IRE Network .......................................................................57 

7.2.4 Advantages and Disadvantages of Option 2 .......................................................58 

vi

8 Costing ............................................................................................................................................60 

8.1 Data Sharing Options Cost Elements................................................................................60 

8.2 Network Options...............................................................................................................63 

8.3 Roadside Communication Costs .......................................................................................63 

9 Recommendations and Considerations ...........................................................................................65 

9.1 Recommendation ..............................................................................................................65 

9.2 Factors Considered ...........................................................................................................65 

9.3 Rationale...........................................................................................................................66 

9.3.1 Rationale for Data Sharing Recommendation ....................................................66 

9.3.2 Compatibility with the Canadian ITS Architecture ............................................69 

9.3.3 Rationale for Network Option Recommendation ...............................................70 

10 Considerations/The Way Ahead......................................................................................................71 

11 Conclusion ......................................................................................................................................73 

A Appendix A - Questionnaires....................................................................................................... A-1 

A.1 Canadian Jurisdictions ................................................................................................... A-1 

A.2 US Questions ................................................................................................................. A-7 

B 

Appendix B - Interviewee List ......................................................................................................B-1 

B.1 Canadian Jurisdictions ....................................................................................................B-1 

B.2 US Contacts ....................................................................................................................B-3 

C 

Appendix C - Requirements..........................................................................................................C-1 

D Appendix D – Glossary................................................................................................................ D-1 

E 

Appendix E – Status of Automation of Provincial Systems Supporting CVO..............................E-1 

F Appendix F - Security Issues at the Canada-US Border ............................................................... F-1 

F.1 Introduction..................................................................................................................... F-1 

F.2 Southbound (US) and Northbound (Canada) Importation Process ................................. F-2 

F.3 Summary of Border Crossing and Security Initiatives.................................................. F-11 

F.4 Summary and Recommendations.................................................................................. F-24 

vii

viii

List of Tables 

Table 1- Summary of Jurisdictional Readiness .............................................................................................11 

Table 2 - CDE Incident type usage (as of January 2002) ..............................................................................19 

Table 3 - Canadian Carrier Safety Snapshot - Carrier Identification Information.........................................29 

Table 4 - Canadian Carrier Safety Snapshot - Carrier Safety Information....................................................30 

Table 5 - Current Trip Information Data elements........................................................................................32 

Table 6 - Status of Roadside Inspection ........................................................................................................34 

Table 7 - Option 1 Data Use..........................................................................................................................40 



Table 10 - Data Sharing Cost Elements.........................................................................................................62 

Table 11 - Roadside Communications Costs.................................................................................................64 

Table 12 - Summary of Options ....................................................................................................................65 

Table 13 - Comparison of Options ................................................................................................................67 

Table 14 - Canadian Interviewees ...............................................................................................................B-1 

Table 15 - US Contacts................................................................................................................................B-3 

Table 16 - Requirements .............................................................................................................................C-2 

Table 17 - FMCSA-Designated Functional Requirements........................................................................ F-18 

Table 18 - Vulnerability Definitions ......................................................................................................... F-20 

ix

List of Figures 

Figure 1 IRE System ..............................................................................................................................16 

Figure 2 

Figure 3 

Figure 4 

Figure 5 

Figure 6 

Figure 7 

Figure 8 

Figure 9 

CDE System.............................................................................................................................18 

Option 1 Centralised System....................................................................................................39 

Option 1 Snapshot Creation and Update..................................................................................41 

Option 2 Decentralised System................................................................................................44 


Option 3 Regional Database System........................................................................................49 


IRE Network Configuration.....................................................................................................53 

Figure 10 VPN Network configuration ....................................................................................................56 

Figure 11 

Canadian ITS Architecure........................................................................................................70 

x

Technical Feasibility Study for the Development of an 

ITS Commercial Vehicle Operations Network for Canada 

1 Introduction 

This report presents SAIC Canada’s findings and recommendations to Transport Canada on the technical 

feasibility of the development of an Intelligent Transportation System for Commercial Vehicle Operations 

(ITS/CVO) network. This report is written in accordance with the requirements of RFP No. T8080-01- 

1119 Technical Feasibility Study for the Development of an ITS Commercial Vehicle Operations Network. 

“Present a technical report on the proposed architecture for a CVO network in Canada, including specific 

requirements to enable near real-time information exchange using carrier snapshots and having the 

information available at the roadside. The contractor should look at different possible scenarios for data 

sharing between jurisdictions and with the United States for a CVO network for Canada. The architecture 

should also reflect how a CVO network could be applied to border crossings and should be consistent with 

the ITS architecture for Canada.” 

1.1 Background 

The Council of Deputy Ministers Responsible for Transportation and Highway Safety approved the 

development of a cross Canada commercial vehicle safety inspection network. The network was intended 

to enable the exchange of required safety related information between jurisdictions with electronic access at 

inspection stations, the roadside, and in the future at border crossings, without the need to stop the vehicle. 

As a first step, a federal contribution of $7 million was given to the provinces/territories in November 1999 

to help upgrade their own automated systems in order to enable them to exchange motor carrier safety data. 

Through the involvement of the Canadian Council of Motor Transport Administrators (CCMTA) and its 

inter provincial records exchange (IRE) system, the exchange of data has been verified and this step 

successfully completed. 

As a next step, Transport Canada and the provinces/territories are collaboratively conducting two studies to 

determine the feasibility of proceeding with a CVO network for Canada. SAIC Canada is addressing one 

of these, specifically the requirements for the technical feasibility for the development of a CVO network, 

while the second study to specify the requirements for a cost benefit analysis study of electronic clearance 

and roadside inspection is being undertaken by Tri-Global Solutions. 

The purposes of the feasibility study as laid out in the Terms of Reference were to: 










As noted elsewhere in the report many jurisdictions and Federal agencies both here and in the US are quite 

active in this are. This report presents the best information available at the time the data gathering and 

analysis was done, viz. during the early part of 2002. The situation may have changed in some areas. 

1



1.2 References 

In completing the Feasibility Study, a number of documents were reviewed and in some cases summarised 

by the SAIC team. In addition to the documents specified here, several documents were reviewed 

specifically relating to the regimen at the Canada/US border and the Canada/US initiatives in that area. 

These are listed in Appendix F. 

The general references used are: 

• Carrier Management Sharing and Exchange Requirements Report, Tri-Global Solutions, May 25, 1998 

• Development of Implementation Options for Exchange and Sharing of Carrier Information, Phase II – 

Options for the Exchange and Sharing of Data, Tri-Global Solutions, September 10, 1998 

• Study on ITS Applications within the Canadian Trucking Industry, prepared for Transport Canada by 

Sabounghi & Associates and Delcan Corporation. 

• Canadian ITS Architecture, Transport Canada, TP13668E 

• Introductory Guide to CVISN, Preliminary Version P.2. 

• CVISN Recommendations for Primary Identifiers, Preliminary Version 1.0 White Paper. 

• CVISN Roadside Electronic Screening Preliminary White Paper. 

• CVISN Guide to Safety Information Exchange, POR-99-7191 Draft Version D.1. 

• Safety and Fitness Electronic Records System (SAFER) and Commercial Vehicle Information 

Exchange Window (CVIEW): Version 2.0 Carrier, Vehicle and Driver Snapshots. 

• Introduction to Interprovincial Records Exchange, CCMTA. 

• Draft Policy Options Report, Assessment of Non-Carrier Encouraged Violations of Motor Carrier 

Safety Regulations, SAIC for the Office of Motor Carrier and Highway Safety. 

• CVISN Level 1 Checklist. 

• An ITS Plan for Canada En Route to Intelligent Mobility (TP 13501 E). 

• CVISN Guide to electronic screening, POR-99-7193 Draft Version D.1, October 28, 1999 Prepared by 

JHU-APL for FHWA. 

• Extensible Markup Language (XML) in CVISN Draft Version D1.0 White Paper, January 21, 2000 

Prepared by JHU-APL for FHWA. 

• Early Institutional Lessons from the CVISN Model Deployment: Checklists for Success - Sari Radin, 

Volpe Centre for USDOT ITS-JPO 

• Intelligent Transportation Systems at International Borders: A Cross-Cutting Study - Paul Bellela, 

Booze Allen & Hamilton, for USDOT/FHWA. 

• What We Have Learned about ITS - John Orban, Battelle, for USDOT/FHWA. 

2



• Coutts/Sweetgrass Automated Border Crossing: Phase 1 - Randy Carroll and Jodi Carson, Western 

Transportation Institute, Montana State University, for USDOT/FHWA. 

• Evaluation of Commercial Vehicle Information (CVISN) Systems and Networks Model Deployment 

Initiative, John Orban, Battelle et al, March 2002. 

3



2 Process 

The feasibility study was conducted over a ten-month period from December 2001 through September 

2002. This represents the baseline dates for most of the information gathered. Further revision of the 

report was done in October 2002 and May 2003. Although no new research was conducted. 

SAIC Canada undertook a phased approach to the project consisting of six tasks. These tasks were as 

specified in SAIC Canada’s proposal and mapped directly to the scope items of the Terms of Reference. 

• Task 1: Consult and Review List of Reports/Documents and Consult with Stakeholders. 

• Task 2: Define Needs/Requirements. 

• Task 3: Review the current technical state of the province/territory CVO safety information systems. 

• Task 4: Explore US CVISN Level 1 Capabilities. 

• Task 5: Review Existing Systems Architectures supporting Roadside Operations. 

• Task 6: Prepare a Technical Report on the System Architecture for a Canada Wide CVO network. 

At the end of each task SAIC Canada prepared a summary report for use by the team. A copy of these 

reports was also given to Transport Canada. In accordance with the contract SAIC also prepared monthly 

progress reports for Transport Canada. 

In addition, at all stages of the process SAIC Canada consulted and co-ordinated activities with Tri-Global 

Solutions, who are conducting the parallel project, the ECRI Cost-Benefit Study. 

For purposes of this study the SAIC Canada Team used a limited definition of a CVO network as stated in 

the Terms of Reference. This definition defines a CVO by its fundamental capabilities. 

“The resulting architecture ………. will allow motor carrier safety related information to be exchanged and 

accessed at the roadside and allow for future expansion of the system to potentially include other CVO 

functionalities as described in the architecture (such as credential administration).” 

The following describes the process followed for each phase. 

2.1 Task 1: Consult and Review List of Reports/Documents and Consult 

with Stakeholders 

The first task for the team was to prepare a baseline of knowledge. This was achieved by various activities: 

• Literature Review. The SAIC Canada Team conducted an extensive review of available literature 

including previous Canadian studies and the Johns Hopkins University Applied Physics Laboratory’s 

(JHU APL) extensive CVISN documentation. 

• Identification of Stakeholders. Concurrent with the literature review, the SAIC Canada Team worked 

with Transport Canada and the project’s Steering Committee to identify key stakeholders at the 

province/territory level for follow-up interviews. The Study Team also identified key U.S. CVISN 

states, representatives from FMCSA, CVSA, and AAMVA, and technical staff from JHU-APL for 

follow-up interviews. 

4



• Developed Interview Questions. Based on the results of the literature review, the SAIC Canada Team 

formulated specific questions to be used for stakeholder interviews. These questions were targeted to 

the specific stakeholder or stakeholder group being interviewed. The questions were designed both to 

obtain information on existing processes and systems/networks, requirements/needs that would be met 

by developing an ITS/CVO network and, policy/technical issues/concerns that will need to be 

addressed to enable successful implementation. 

• Conducted Stakeholder Interviews. Interviews were conducted with key stakeholders from both 

Canada and the United States. The interviews were used to obtain the following information: 

o 

o 

o 

End-user requirements – what are the end-user requirements of enforcement personnel for an 

ITS/CVO system, what information needs to be exchanged, how will this information be 

used. 

Existing capabilities – information was obtained on existing degrees of ITS/CVO systems in 

use, the degree of automation, existing systems (platforms, architectures, functionality, etc), 

how is information currently obtained, processed, accessed. 

Existing business processes – collection of information current enforcement processes, 

including the degree to which these are automated, how would implementing an ITS/CVO 

network be integrated into existing processes, would existing processes need to be changed. 

o o Current CVISN Level 1 functionality – where do US states stand with respect to CVISN 

Level 1 deployment and what is available for use by Canada. 

o 

Border crossing requirements – what information would be available from an ITS/CVO 

system to meet border crossing requirements, and how would this information be used, what 

are security requirements. 

• Compilation of Results. As documents were reviewed and interviews completed, the SAIC team 

members prepared summaries of findings. These summaries were in turn distributed to and reviewed 

by other team members. In addition, the findings from the interviews and literature review were used 

to complete the interim reports for Tasks 3 through 5. 

• With respect to the transportation of dangerous goods and hazardous wastes, organisations involved 

with the control of the process were be contacted to evaluate ways in which their programs could be 

linked to the system to be developed. 

2.2 Task 2: Define Needs/Requirements 

The results of stakeholder interviews and the literature review were used to define what was needed from a 

nation-wide ITS/CVO system. Once needs had been defined, requirements were developed to address 

these needs and to establish high-level performance requirements. The development of the requirements 

also included an assessment of requirements developed for CVISN Level 1 as well as a review of CVISN 

implementation experience. Lessons learned from the US experience with CVISN were incorporated into 

the requirements analysis where feasible. 

In addition to identifying requirements, the team also identified a number of implementation and 

institutional issues for consideration by Transport Canada. These issues were also identified through 

stakeholder interviews and the literature review. SAIC Canada’s rationale for including these was based on 

the lessons learned by the US states and guidance provided by stakeholders during interviews that 

proactively addressing these issues would ease implementation and, most importantly, help avoid delays 

and manage costs more efficiently. 

5



2.3 Task 3: Review the current technical state of the province/territory 

CVO safety information systems. 

Jurisdictional readiness to implement ITS/CVO systems was assessed primarily through stakeholder 

interviews. Each of the steering committee members was contacted and provided contacts within their 

jurisdiction. Findings were supported by the literature review. The team identified key issues relating to 

jurisdictional readiness and gained an understanding of differences between the types of ITS/CVO systems 

currently being used and variances between the provinces and territories. 

2.4 Task 4: Explore US CVISN Level 1 Capabilities 

The US CVISN review involved interviews with one prototype state (Maryland), three pilot states 

(Kentucky, Minnesota, and Washington), the Federal Motor Carrier Safety Administration (FMCSA), and 

Johns Hopkins University Applied Physics Laboratory (JHU-APL), the CVISN system architects. In 

addition, the extensive CVISN documentation developed by JHU-APL had previously been reviewed and 

analysed as part of Task 1. The analysis of the US CVISN focused on the applicability of CVISN Level 1 

requirements to Canada, in particular those requirements for ECRI and safety information exchange. 

2.5 Task 5: Review Existing Systems Architectures supporting Roadside 

Operations 

The review of existing Canadian systems was conducted using the stakeholder interviews and literature 

review. The questions developed to guide interviews included a section on existing systems, and the team 

members conducting the interviews also requested copies of documentation, reports, and any other 

available information. All documentation and interview results were reviewed and the outline and concept 

of assessment document developed. 

2.6 Task 6: Prepare a Technical Report on the System Architecture for a 

Canada Wide CVO network 

A primary objective of the study was to develop network scenarios, develop the Canadian snapshot, and 

identify issues that needed to be addressed. The basic format of the Canadian snapshot was developed 

using the literature review and stakeholder interviews, in particular the earlier Tri-Global studies and the 

interviews with FMCSA and JHU-APL, as a resource. The team collectively identified alternative network 

scenarios, identified pros and cons for each scenario, and identified and assessed issues that would impact 

each scenario. 

The final report was prepared between May and August, with all team members contributing written 

sections or providing quality assurance review. The team conducted two internal reviews of the report 

during September. This was done to ensure that the report adequately addressed all requirements of the 

Terms of Reference prior to submitting the final draft for comment and review. The draft report was 

submitted to Transport Canada and other stakeholders for comment and review in mid-September. 

Comments were incorporated in a first formal release in November and into this second revision. 

2.7 Co-ordination with ECRI Cost/Benefit Study 

As specified in the Terms of Reference, the team co-ordinated on a regular basis with the Tri-Global 

Solutions team conducting the ECRI Cost/Benefit Study. This involved the exchange of documents and 

periodic conference calls to: 

• Update the respective teams on issues and project status. 

6



• Discuss and review the documents exchanged by the two teams. 

• Identify and address any potential inconsistencies that existed between the two studies. 

• Discuss how the architecture developed for the Feasibility Study will interface with the proposed ECRI 

systems being developed for the Cost/Benefit Study. This was done to ensure consistency between the 

two studies, and to ensure that the options proposed through each study would be technically 

compatible and interoperable. 

7



3 Analysis 

Prior to developing options for sharing data, important considerations arising from the earlier stages had to 

be taken into account. 

Specifically: 

• Jurisdictional Readiness 

• US Experience with CVISN 

• Current State of Canadian CVO Systems 

• The Transportation of Hazardous Materials. 

• Security Issues at the Canada/US Border 

3.1 Jurisdictional Readiness 

Task 3, as stated in Appendix B Terms of Reference of the Request for Proposal T8080-01-1119 

“Technical Feasibility Study for the Development of an ITS Commercial Vehicle Operations (CV0) 

Network for Canada”, requires the review of the current technical state of the provincial/territorial 

commercial vehicle safety related information systems to assess their readiness to provide the necessary 

data and links to a CVO network. The review includes: 

• The openness of each jurisdiction's architecture for linking to a CVO network 

• A map of systems and data information flows that will support the development of a CVO network. 

• The technical requirements needed to connect/link to a CVO network 

• The time frame and resources required to create links to a CVO network 

This section of the Technical Report presents the review of provincial systems supporting CVO and the 

resultant assessment of the readiness of these systems for connections to a CVO network. The review was 

based on telephone and in-person interviews with representatives from provinces who are involved in 

enforcement, operation, IT and policy for CVO. Seven provinces were contacted for the interviews. They 

were Nova Scotia, Quebec, Ontario, Manitoba, Saskatchewan, Alberta and British Columbia. 

The areas of interest or topics are described in a document "Interview Questions", copies of which were 

distributed to interviewees ahead of the interviews. A copy of the document is shown in Appendix A. 

On-site visits to observe roadside and IT backend operations were conducted in Ontario and Quebec. Other 

CVO and system operation information were collected from Nova Scotia for its Commercial Vehicle 

Inspection Report (CVIR) for roadside operation; from Ontario for its Commercial Vehicle Operator 

Registration (CVOR) operation; from Manitoba for its Carrier Snapshot (C-SNAP); and from Quebec for 

its Mechanical Inspection Certification (CVM), various screen printouts, and system manual for roadside 

operation. 

There is a wide range of capabilities and readiness across the provinces. In addition most jurisdictions are 

continually improving their systems and communication facilities. 

8



3.1.1 Assessment of Readiness 

The openness in architecture of provincial systems is assessed from hardware, operating system, 

application software, communication and user interface points of view. . Many provinces run their CVO 

systems on mainframes with legacy databases, operating systems, application software and communication 

protocols. Since older technologies are mostly proprietary, these systems do not have open architecture for 

migration to modern technologies and integration with newer applications. 

Nova Scotia, Quebec, Ontario, Alberta and British Columbia all have mainframe CVO systems. However, 

Nova Scotia has moved CVO applications to an IBM RS6000 system (the CAPS system) that is linked to 

its original mainframe system. The CAPS system has an open architecture in hardware, software, 

programming language, communications and user interface. 

Ontario is currently in the midst of the province wide legacy renewal program for all its IT systems. MTO 

is completing the VRS Inquiry system that provides CVO applications in a modern technology 

environment with open architecture in hardware, software, programming language, communications and 

user interface. There remains some development work to be done for connection to a CVO network. 

Despite its mainframe backend operation, Quebec has done a lot of work to bring modern technologies and 

open architecture to roadside operation, CVO applications, user interface and communications. Internally, 

the Quebec CVO systems are completely functional and modern in operation. There will be additional 

development work to make the delivery of Quebec CVO information compatible for connection to a CVO 

network. 

British Columbia is currently implementing the Port Mann weigh station with ITS systems, notably WIM 

and AVI for electronic screening and credentialing. The Port Mann station will be part of the Norpass and 

operates like a satellite site of Washington State. This station will have CVISN system components. This 

system installation and development experience would help BC to reduce its effort required for connection 

to a CVO network. 

Nova Scotia, Ontario, Manitoba and Saskatchewan have set up portals for public users to access certain 

carrier information through public internet, and portals for authorised users to access most CVO 

information through private/provincial intranets. A reasonable approach is setting up the CVO network as 

a VPN linking all provincial intranets serving CVO and that all users on this VPN will be authorised users. 

This approach requires that all provinces use/assign same data elements and tags for commonly accessed 

CVO data that all provinces develop web servers and portals, and that CVO information is accessible using 

common browsers. 

With the above analysis and considering the factors used in the review analysis which are: 

• The openness of each jurisdiction's architecture for linking to a CVO network 

• A map of systems and data information flows that will support the development of a CVO network. 

• The technical requirements needed to connect/link to a CVO network 

• The time frame and resources required to create links to a CVO network 

We concluded that Nova Scotia, Ontario, Manitoba and Saskatchewan have their CVO systems most ready 

for connection to a CVO network. BC and Quebec would be reasonably ready for connection to a CVO 

network. Alberta would be the least ready for connection to a CVO network. 

9



AVI and WIM are systems often used to facilitate mainline electronic screening and credentialing 

operations. While only Ontario and BC have AVI experience, all except Nova Scotia and Manitoba do 

have WIM experience. Although the WIMs in Alberta and Quebec are not currently operational, these 

WIMs can be easily repaired, retrofitted and re-commissioned. On this basis, we concluded that only 

Ontario and BC have their CVO systems most ready for electronic screening and credentialing operations. 

3.1.2 Summary of Jurisdictional Readiness 

Table 1 summarises key points from the results of the interviews that most apply to the creation of a 

Canada-wide data-sharing network. Due to the very diverse operations in each of the jurisdictions, the 

following provides general information only. The specific situation in individual jurisdictions may be more 

complex e.g. a jurisdiction may have more than one type of fixed installation with different conditions 

applying. Where a jurisdiction has advised SAIC Canada of plans to change the situation, it is noted. 

The table includes assessments of the state of readiness of that particular jurisdiction to participate in the 

development and connection to a national ITS/CVO Network, and to participate in the development and 

implementation of electronic screening and credentialing towards CVISN type operation. 

The assessments are presented in the last two rows of the table and are assigned a scale of 1 to 5, 1 being 

the most ready. Based on the items in the table, the rating is a subjective assessment of how a provincial 

CVO system lends itself to the development of a National ITS/CVO Network for inter-jurisdictional data 

exchange, electronic screening and credentialing. A rating of 1 in “Readiness for connection to a CVO 

network” indicates that a provincial CVO system, in its current operating mode and system architecture, is 

most readily adaptable to open-connections and web-based applications. A rating of 1 in “Readiness for 

electronic screening and credentialing” indicates that a province has the most experience, installations and 

supporting infrastructure and systems to implement electronic screening and credentialing. 

Appendix E presents a summary of the current status of provincial CVO systems for the seven provinces 

recorded in Table 1, which forms the basis for the rating. 

10



Table 1 – Summary of Jurisdictional Readiness 

British Columbia 

Alberta 

Saskatchewan 

Manitoba 

Ontario 

Quebec 

Nova Scotia 

NS QC ON MB SK AB BC 

On-line access to Intraprovincial 

vehicle 

information (D&V) Fixed site stations yes yes yes yes yes yes yes 

Mobile site stations yes yes test yes yes no No 


vehicle 

information (CVSA) Fixed site stations yes yes yes yes yes yes yes 

Mobile site stations yes yes test yes yes no No 


carrier 

information (safety, 

profile) Fixed site stations test yes yes yes no yes yes 

Mobile site stations test yes test yes no no no 

Central or 

management offices yes yes yes yes yes yes Yes 

On-line access to Extraprovincial 

vehicle 

information (D&V) Fixed site stations no yes yes yes yes yes yes 

Mobile site stations no yes test yes yes no No 


vehicle 

information (CVSA) Fixed site stations no no no no no no no 

Mobile site stations no no no no no no No 

11




Alberta 



Ontario 

Quebec 

Nova Scotia 



carrier 

information (safety, 

profile) Fixed site stations no no no no no no no 

Mobile site stations no no no no no no no 

Central or 

management offices CDE CDE CDE CDE CDE CDE CDE 

Automated roadside 

inspection Fixed site stations yes yes no no yes no no 

Mobile site stations yes yes no no yes no no 

On-line inspection 

reporting Fixed site stations yes yes test no yes no no 

Mobile site stations yes yes test no yes no no 

Central or 

management offices yes yes yes yes yes yes batch 

Extra-provincial vehicle 

inspection reports sent to Central or 

home jurisdiction management offices 

batch 

wkly 

batch 

wkly 

batch 

wkly 

batch 

wkly 

batch 

wkly 

batch 

wkly 

batch 

wkly 

Provincial data 

Communication network network yes yes yes yes 

Government wireless 

network 

yes 

Provincial Intranet yes yes yes yes yes 

Public Internet yes yes 

Public CDPD yes yes yes 

CVO systems for D&V 

information MF MF 

CVO systems for carrier 

profiles 

CVO systems for 

inspections 

Openness in architecture 

for CVO systems 

RS 

6000 MF 

RS 

6000 MF 

MF / 

Sun HP Sun MF MF 

MF / 

Sun HP Compaq MF MF 

MF / 

Sun HP Compaq MF MF 

(in scales 1 to 5, 1 

being the most open) 1 4 2 1 1 5 5 

12




Alberta 



Ontario 

Quebec 

Nova Scotia 

Development effort 

required for connection 

to a CVO network 


(in scale of 1 to 5, 1 

being the minimal) 1 3 2 1 1 5 4 

AVI experience yes yes 

WIM experience yes yes yes yes yes 

Carrier snapshot (currently available) yes yes yes yes yes yes 

Vehicle snapshot (currently available) yes yes yes 

XML experience (in web access) yes yes 

Access with browser (for CVO info) yes yes yes yes 

Readiness for connection 

to a CVO network 

Readiness for electronic 

screening and 

credentialing 

3.1.3 Conclusions 


being the most ready) 1 3 1 1 1 5 3 


being the most ready) 5 3 1 5 4 4 1 

There are two primary conclusions that can be drawn from this analysis: 

1. There is a wide range of existing technical capabilities and deployments. 

2. The situation is in a state of flux, with many jurisdictions upgrading their existing legacy systems and 

investigating additional applications such as expanded use of laptop computers and wireless access by 

more mobile inspectors, on-line input of inspection data. 

As relates to the development of data sharing network these observations clearly indicate the need for 

flexibility and options. A rigid approach to implementation will run afoul of plans in place in one 

jurisdiction or another, or imply major costs either for the jurisdiction or for Transport Canada. Either way, 

this will negatively impact the acceptability of such a network. Ideally the network should try to take 

advantage of the high degree of automation already present in the jurisdictions. 

13



3.2 US Experience with CVISN 

This section of the report presents those aspects of CVISN deployment that may be worthy of 

consideration. These include technical, institutional, and programmatic considerations. 

CVISN enables carrier data exchange using defined carrier snapshots, data elements, and authoritative 

sources for safety and credentialing data. This is the primary benefit that CVISN offers Canada. While 

both Canada and the US have established national architectures for ITS/CVO, CVISN has established a 

standard carrier snapshot with identified sources for authoritative data. This snapshot is used by all states, 

and the structure and data elements contained in the snapshot have become the operating standard 

supported by the US. 

The CVISN Architecture is based on open standards and interoperability of systems to enable exchange and 

sharing of data. 

The architecture developed for CVISN supports open standards and interoperability of systems. The 

architecture does not mandate the type of system(s) that a state needs to deploy, but instead establishes a 

format whereby states can develop interfaces to facilitate data exchange and sharing without replacing 

existing legacy systems. This approach has helped to reduce deployment and development costs. 

3.2.1 CVISN Implementation – Flexible Approach, Phased Development 

The CVISN program has been designed with a flexible approach to implementation. US states have 

varying levels of existing technical capability and resources (as is the case with Canadian 

provinces/territories) and all states are not able to implement CVISN at the same rate of deployment. The 

implementation approach established for CVISN enables phased development, that is, states incrementally 

deploy systems and/or add functional capabilities as resources are available and technical capabilities 

allow. This also enables states to address their priority needs within the CVISN framework (some states 

have targeted credentials administration, others safety information exchange as priorities, for example). 

This approach appears to offer benefit for Canada, as some jurisdictions (e.g., Quebec, Saskatchewan, 

Nova Scotia and Ontario) have highly automated existing systems, while others remain reliant on manual 

processes and do not yet have a high degree of automation. This approach also enables new or emerging 

technologies to be incorporated into system development – phased deployments enables new or expanded 

functional deployments to be revised to incorporate new/emerging technologies in a manner that a onesize-fits-all 

approach would not provide. An example of this is the emergence of XML and web-based 

applications in US CVISN as an alternative to the original plan on using EDI based transactions. 

3.2.2 Software Code in Public Domain 

Much of the software developed in support of CVISN is in the public domain, meaning that the core code is 

available for use by Canada if desired. This includes the core code for SAFER, the national data exchange 

system as well as for several variations of CVIEW, the state level data exchange system. 

The advantage of reusing this core code, if these systems meet Canadian requirements, is that basic 

development costs would be substantially reduced even if they were not completely eliminated. 

Requirements analysis, provincial/territory specific requirements, and legacy system interfaces would still 

be required, but overall costs would be significantly reduced. 

This is also true of the secondary software and systems that are used to support CVISN in collecting and 

exchanging data. Examples of this include ASPEN – electronic collection of inspection data, and 

SAFETYNET – electronic submission of inspection data to national system. These secondary systems are 

14



also available in the public domain, and can be obtained from the US. This also would help reduce 

development costs, reduce the time lag between collection of data and data uploading to legacy systems, 

and improve the quality of data (reduction in manual entry errors). 

3.2.3 Institutional Framework 

In the US, the Mainstreaming Program established a forum for the US states to meet, identify, and address 

common or regional issues related to the deployment of ITS/CVO. In addition, the follow-on ITS/CVO 

training program and the CVISN workshops helped states gain a better understanding of what systems 

needed to be developed, how these would operate in a state setting, and the nature and type of institutional 

issues that need to be addressed (both intra- and inter- provincially) to enable successful deployments. A 

key concept with this approach is that the CVISN end-users were involved in identifying and resolving 

issues, ensuring that CVISN was developed to meet state needs. 

In addition to the Mainstreaming Program, groups such as ITS America, AAMVA and CVSA also 

established CVISN committees and working groups to address institutional and policy issues related to 

ITS/CVO deployments. The US experience has also benefited from engaging industry through State 

Trucking Associations in dialogue to assure buy in and to work through issues. 

While the focus of this report is on technical aspects of CVISN that offer potential benefit to Canada, SAIC 

Canada’s experience has been that institutional issues often create major barriers and hurdles to successful 

deployment of new systems and technologies such as ITS/CVO. Canada may wish to consider establishing 

a program similar to the US Mainstreaming Program as a means to gather the provinces/territories, which 

are the end users, together in a common forum to identify and address potential institutional barriers that 

would impede system development and deployment. 

3.3 Current State of Canadian CVO Systems 

There are essentially only two Canadian systems that can be built upon to support a CVO network. These 

are the IRE (Inter-provincial Record Exchange) system and the CDE (Carrier Data Exchange) system. 

These systems are both operated by the CCMTA and, while ostensibly independent, are highly interrelated. 

IRE and CDE are inter-related systems, so much so that the concept of the “IRE network” has become 

confused. IRE provides an excellent and well-used vehicle for jurisdictions to find out information about 

drivers and vehicles. Its major drawback is response time, since a jurisdiction requesting information is 

dependent upon the speed of the network and the response time of the jurisdiction being queried; two 

factors they have no control over. However many jurisdictions report excellent response times. 

CDE is a newer system, but is also well received and well used. Primary users are Ontario, Quebec, BC 

and Alberta, with lesser usage in Manitoba and New Brunswick. Usage reflects the amount of interprovincial 

traffic in the various jurisdictions. The primary drawback of the system is the time delay and 

hence the timeliness of the information. Each jurisdiction is presently free to transmit and receive 

information on their own schedule. 

However both systems provide an excellent potential for use in a nation-wide CVO system. A lot of time 

and energy has been put into creating these systems and a lot of effort has been expended by the various 

jurisdictions in support of these systems. 

15



3.3.1 IRD and CDE 

3.3.1.1 IRE 

The IRE system was developed by the CCMTA in 1988 and has been used by all jurisdictions to exchange 

data since the summer of 1989. IRE uses a star network topology with a single connection between a 

gateway in each jurisdiction and a central switch. The central switch is hosted by Quebec. 

Gateway Gateway Gateway Gateway 

Central Switch 

Gateways 

Jurisdictional 

Hosts 


Figure 1 – IRE System 

Presently the communication protocol used by IRE is TCP/IP using a frame relay network supplied by 

AT&T. The connection between each gateway and the central switch is a single permanent virtual circuit 

(PVC). At each jurisdiction, the gateway connects to each jurisdictions computer system (typically 

mainframes) using a variety of protocols such as SDLC or TCP/IP. All gateways within the IRE network 

are Intel based PC’s using IBM’s OS/2 operating system. 

A standard set of transactions have been defined that can be processed across IRE. All transactions are 

enquiry/response based i.e. an inquiry is sent from one jurisdiction to another (or to several) and a response 

is sent back from that jurisdiction. Each jurisdiction is responsible for formatting the enquiries and 

responses into a standard format. Each jurisdiction is free to develop application software to support IRE 

using its own standards and meeting its own functional requirements. 

It should be noted that IRE does not store any data that a jurisdiction can access. The network is purely a 

means of transporting data between jurisdictions' mainframes. 

The IRE network provides several features when transmitting transactions. Some of these are: 

• Store and forward 

• Online and batch 

• Retry 

16



• Message Compression 

• Security 

• Message Validation 

IRE has numerous standard transactions. New transactions must be negotiated between the jurisdictions 

before being implemented. Some typical transactions types provided are: 

• Basic driver license inquiry 

• Driver name search 

• Vehicle inquiry 

• Driver profile inquiry 

• Driver abstract inquiry 

As each jurisdiction stores motor vehicle and driver information in different formats on their own 

mainframe systems, a standard data dictionary is provided for the national definition of data elements. For 

some data elements, the actual data values included in an IRE message must meet the specifications as 

defined in the data dictionary. This ensures that all jurisdictions can interpret an IRE message no matter 

which jurisdiction sent it. As before each jurisdiction has the responsibility to develop the necessary 

software to ensure that IRE message formats and data conform to the dictionary definitions. They are free 

to do this according to their own design and development standards. 

It should be noted that the network itself does not check the validity of individual data elements other than 

the control and routing information within the message header. 

3.3.1.2 CDE 

Carrier Data Exchange is the capability of electronically sending incidents (CVSA inspections, accidents 

and convictions) involving commercial carriers, operating outside their home jurisdictions, back to their 

home jurisdiction. 

Data is exchanged using a “store and pick-up” architecture. When a jurisdiction (source) has incident data 

to exchange with another jurisdiction/s (target), the source jurisdiction will send data to the CDE Server. 

The CDE Server prepares the data for pick-up by the target jurisdiction and stores it in a “mailbox” for the 

target jurisdiction. At some point in time the target jurisdiction will pick-up all available data from the 

Server. 

Presently two means of storing and two means of pick-up are provided. These are by IRE and by FTP. 

In FTP, both source and target jurisdictions will transfer a file contain one or more records. A source 

jurisdiction will transfer a file to the server containing records for several target jurisdictions. A target 

jurisdiction will transfer a file from the server containing all incidents records received by the server from 

source jurisdictions up to that point in time. 

17




AT&T Network 


CDE Server 

Gateway 


Figure 2 – CDE System 

Records transferred by IRE will be transferred to or from the server one record (one IRE transaction) at a 

time. 

Data picked up by a jurisdiction may have been received from one or more jurisdictions and by any 

combination of IRE or FTP. 

There are no constraints upon the jurisdictions as to whether they transfer files or records. No restrictions 

are placed on when the transfers take place except that they cannot transfer files to the server until the 

server has finished processing the previous file from that jurisdiction. 

The CDE server physically resides with the CCMTA secretariat in Ottawa and operates as if it were another 

jurisdiction. 

Figure 2 shows a more physical representation of the network arrangement with the CDE Server included. 

Each jurisdiction’s gateway connects physically to the AT&T network cloud as does the IRE switch in 

Quebec. To enable FTP transactions the CDE server is also physically connected to the network. Similarly 

jurisdictions that wish to transfer incidents by FTP must also connect directly to the network. These 

connections are not shown in figure 2. 

Because of the query/response nature of IRE, when CDE records are transferred by IRE, the records are 

sent as if they were a query and the CDE response is in effect an ACK (acknowledgement). 

Table 2 shows which jurisdictions are using the system as of mid 2002 and which type of incidents they are 

reporting. 

18



Incident Type 

Inspections Records 

Conviction Records 

Accident Records 

Table 2 – CDE Incident type usage (as of January 2002) 

Used by 

All except PE. 

AB, BC, MB, NB, NT, ON, QC, SK send accident 

records. NF, NS, PE, YT do not send them. 

BC, MB, NB, NT, ON, QC, SK send accident 

records. AB, NF, NS, PE, YT do not send them. 

3.4 The Transportation of Hazardous Materials 

The review of Linkages for Transportation of Dangerous Goods and Hazardous Wastes found numerous 

organisations with several databases covering a wide range of material of potential interest to an ITS/CVO 

network. Specifically: 

• Transportation of Dangerous Goods Directorate (TDGD) of Transport Canada 

o Transportation of Dangerous Goods Revised Regulations Schedule 1 Searchable Database - 

Schedule 1 of the new TDG regulations lists all dangerous goods by name and UN number 

and provides information on all classes of dangerous goods, such as, classification, quantity 

exemptions and limitations, special provisions and emergency response plans. A searchable 

version of the Schedule 1 database is available online at 

http://www.tc.gc.ca/tdg/clear/schedule1form.asp 

o 

o 

o 

Dangerous Goods Accident Information System – Database of data compiled annually of 

accidents involving dangerous goods. Approximately 500 records per year are added to the 

database. Some information such as addresses may have to be kept confidential. Database is 

available through Statistics Canada for a fee. 

Canadian Vehicle Survey – A quarterly survey on vehicle transportation patterns that includes 

statistics on the number of kilometres dangerous goods are carried by specific vehicle types. 

Database is available through Statistics Canada for a fee. 

Transport Canada Registered Inspection and Test Facilities for Highway, Portable and 

Intermodal Tanks Database – allows for the verification of current tank registration status. 

• Canadian Transport Emergency Centre (CANUTEC) 

o 

o 

o 

o 

CANUTEC Commercial Products Database - computerised database that consists of 

information on more than 750,000 commercial products. 

CANUTEC Call Statistics – statistics collected on a daily based on number and type of calls, 

transport modes, source of calls, location of incidents and class of dangerous goods involved. 

Available on-line at http://www.tc.gc.ca/canutec/en/stats/stats.htm. 

Emergency Response Guidebook – Guidance information for chemical spill first responders. 

The 2000 version of the guidebook is available on-line in a searchable format at 

http://www.tc.gc.ca/canutec/erg_gmu/erg2000_menu.htm. 

Emergency Response Assistance Plans (ERAPs) – Shippers of certain dangerous goods are 

required to have ERAPs. Transport Canada has an active program to register, inspect and 

approve ERAPs. With direct access to this information via an ITS, officials could verify that 

a shipper has a valid ERAP. 

19



• Transboundary Movement Division (TMD) of Environment Canada 

o 

Canadian Notice and Manifest Tracking System – Computerised system to track hazardous 

waste transboundary movement. Currently the notification information is submitted 

electronically by the shippers and there is a pilot project for customs officials and waste 

receivers to submitted manifests once the shipments reach customs and the final destination. 

There is also a pilot project to include notification and manifest information in a “Smart Card” 

format. 

• Environmental Emergencies Branch (EEB), Environment Canada 

o 

National Analysis of Trends in Emergencies System (NATES) database - compiles 

information related to environmental emergency incidents. 

• Canadian Chemical Producers Association (CCPA) 

o 

CCPA Dangerous Goods Transport Survey - product movement surveys conducted once a 

year on the chemical type, mode of transport, container type and CCPA region of transport 

(The database is a 53 KB Microsoft Excel PC-based spreadsheet). 

These organisations also identified several areas where an ITS could assist them in delivering their 

programs, specifically: 

• Transportation of Dangerous Goods Directorate (TDGD) of Transport Canada 

o 

Data collected through an ITS could be used to assist TDGD in collecting the required 

information for their databases, which in turn assists them with the regulation and control of 

dangerous goods transport. 

• Canadian Transport Emergency Centre (CANUTEC) 

o 

When they are called for an emergency, CANUTEC would like to have quick access to 

shipping document information perhaps through a “SmartCard” or transponder system. 

Required shipping information would include: carrier and consignee information, 24 hour 

emergency telephone number, list of dangerous goods carried (regulated shipping name, UN 

number and classification), ERAP information (if applicable), quantities and forms of 

containment (drums, boxes, IBC, etc.) and Material Safety Data Sheet (MSDS) for materials 

contained in the vehicle. 

• Transboundary Movement Division (TMD) of Environment Canada 

o 

Using a “Smart Card” or transponder system, shippers can make hazardous waste shipment 

information readily available for officials. TMD would like to have a direct link with customs 

officials so that TMD can send notifications of hazardous waste shipments to customs 

officials and customs officials can send TMD manifest information as soon as a shipment 

reaches the border. 

• Environmental Emergencies Branch (EEB), Environment Canada 

o 

During an emergency, EEB would benefit from direct access to information on the types of 

hazardous waste or dangerous goods carried by the vehicle involved (similar to CANUTEC’s 

requirement). Data collected through an ITS system could be used to assist EEB in collecting 

20



the required information for their databases, which in turn assists them to prepare for 

emergencies. 

• Canadian Chemical Producers Association (CCPA) 

o 

CCPA would like to have data on the types of dangerous goods transported through their 

regions by vehicles carrying non-CCPA members’ goods. (CCPA Regional Response 

Centres are sometimes asked to assist with non-CCPA incidents.) They are also interested in 

having direct access to data on spill incidents and on hazardous waste transport. 

While it is not possible at present to define exactly how the above interfaces could be implemented, they 

clearly indicate that there is tremendous potential in this area. Of particular interest is the Transboundary 

Movement Division of Environment Canada where the potential to share information via a transponder 

would benefit both organisations. It is felt that Transport Canada should open discussions with these 

organisations to explore opportunities more fully. 

3.5 Security Issues at the Canada-US Border 

Amendment No. 4 to the Terms of Reference required that: 

“The successful respondent (contractor) will specifically address all security related requirements (i.e. 

driver/vehicle/contents) to ensure the safe and secure movement of goods across the Canada- US border. 

“This will encompass harmonisation with US systems and ensure an integrated approach to the transfer of 

data. Both the transfer of data and accessibility to databases and information will be a primary focus of the 

study. 

“The analysis will address the security regime at the Canada – US border, focusing on the following: 

• Harmonisation and integration with the US “CVISN” system. 

• Interface with ITDS, Canada/US Customs, Canada/US Immigration. 

• Areas where ITS/CVO technology can enhance security at the border, including transport of hazardous 

materials. 

• Level of enforcement, identifying areas where ITS/CVO technology can enhance and optimise 

Customs clearance of drivers and vehicles through automated driver/vehicle and cargo identification, 

while optimising vehicle flow.” 

SAIC Canada’s methodology for addressing the requirements of Amendment 4 was to incorporate these 

into the overall project work plan already developed for the initial tasks specified in the RFP. However, 

based on initial interviews with the US Federal Motor Carrier Safety Administration (FMCSA) and the 

Federal Highway Administration (FHWA) and in response to comments received from Transport Canada 

and the Steering Committee, SAIC Canada expanded the scope of the analysis to include: 

• Assessment of Institutional Setting – Identifying those agencies involved in border crossing and 

security issues and the specific role of each agency. 

• Information Requirements – What information is needed by each agency, what is the information used 

for, what are the sources for the information (both agencies and legacy systems). 

21



• Technology Deployments – What technologies and systems are being used, what are planned 

deployments, what are potential interoperability issues and opportunities. 

• Potential ITS/CVO Applications – What are existing ITS/CVO applications, how is ITS/CVO being 

incorporated into proposed deployments, what information can be provided by ITS/CVO, opportunities 

for interoperability and data sharing. 

SAIC Canada’s initial investigation under the expanded scope included interviews with ITS/CVO Border 

Crossing Specialists at FMCSA and representatives from FHWA’s Office of Intermodalism (the FHWA 

office involved in working with other US Government agencies border crossing issues). In addition, SAIC 

conducted a literature review and Internet search for additional information on border crossing and security 

programs and projects that would address the scope of Amendment 4. 

A major part of the analysis was a review of the major border crossing and security initiatives, programs, 

and field operations tests that are being or have been implemented. These include: 

• Washington State – British Columbia International Mobility and Trade Corridor (IMTC) Commercial 

Vehicle Border Crossing ITS Deployment 

• Free and Secure Trade (FAST) Program 

• US DOT HazMat Driver Background Check – new rulemaking from Transportation Security 

Administration 

• FMCSA sponsored HazMat Safety and Security Field Operations Test 

• International Trade Data System (ITDS) 

• Customs and Trade Partnership Against Terrorism (C-TPAT) 

The results of the analysis are presented in Appendix F of the report. 

In summary, the evolving nature of border crossing and security programs is such that identifying 

ITS/CVO solutions and applications is not feasible at this time. SAIC Canada recommends that Canada 

instead continue to monitor the progress of those programs currently on-going and participate, as feasible, 

in the discussions designed at resolving institutional issues. SAIC Canada believes that this approach will 

offer the following benefits: 

• Waiting for the various border and security initiatives to be fully deployed and implemented will 

enable Canada (and the national ITS/CVO network) to interface with mature systems rather than 

systems being deployed as pilots or field operational tests. This will help ensure that the development 

work needed to establish these interfaces would not have to be changed or modified substantially as 

these systems are being established as production systems. 

• As these border crossing and security initiatives are deployed, data requirements (type of data, 

authoritative source) and data exchange procedures will be tested and established. Having these 

established would also help reduce development costs for Canada – in addition, Canada would also be 

able to identify COTS solutions that could help reduce development and deployment costs. 

• The ITS/CVO network proposed for Canada is recommended for development using open standards 

and interoperable systems. This approach would provide Canada with the needed flexibility to 

interface with a wide variety and type of systems and technologies. The border and security initiatives 

22



are being developed using existing standards, operating protocols, and industry accepted software and 

systems engineering practices. Waiting until these are deployed, as operating systems will enable 

Canada to plan for interfaces within established industry standards and practices, again reducing 

development costs and deployment costs. 

• As important as technology related issues are, an additional benefit of delayed deployment is that the 

institutional issues involved with the border crossing and security initiatives will be further resolved. 

Knowing who will be managing these programs, and how, is as important as knowing what 

technologies and systems are being utilised. It will be particularly important for identifying how to 

resolve any issues that arise between the United States and Canada on such matters as data 

requirements, data availability, privacy concerns, enforcement, and other related topics. 

The reasons for this finding include: 

• Institutional Issues – US Customs and the Immigration Naturalization Service are the two agencies 

leading most border crossing initiatives. The US Department of Transportation is a participant, but the 

missions of the involved agencies are very different. US DOT places significant emphasis on mobility 

and highway safety, which are not the primary program areas of Customs and INS. While a number of 

initiatives are underway that attempt to combine these differing missions (i.e., the Blaine Border 

Crossing Project between Washington State and British Columbia) and address the needs of all 

involved agencies, there is not a complete resolution of institutional issues and differing missions. 

• Creation of Transportation Security Administration – Institutional issues are also complicated by the 

creation of the Transportation Security Administration. TSA has been charged to lead all 

transportation related security efforts, but is a new agency and is dealing with the various issues 

involved with establishing a new agency. FHWA and FMCSA have been involved in security issues, 

but agency responsibilities in this area are changing and have not yet been finalised. 

• Technology Deployments – While many of the deployments at border crossings are using ITS, actual 

ITS/CVO applications are limited. An example of this is the FAST deployment at the Peace Bridge. 

Initial deployment plans considered the use of technologies interoperable with other CVO applications. 

However, the deployment is now moving ahead with a different technology not interoperable with 

ITS/CVO. An additional consideration is that some potential technology deployments are still being 

tested. An example of this is the HazMat Field Operations Test currently being conducted by FMCSA 

– while this FOT is testing a variety of technologies related to security, the project is still one to two 

years from completion and the technologies being tested have not yet been mainstreamed as ITS/CVO 

applications. 

• Information Requirements and Proposed Programs – While many initiatives related to security and 

border crossings have been identified; the programs implementing these initiatives are still being 

developed. An example of this is the proposed background check for HazMat drivers – while this 

program has been under discussion for sometime, it is only now being implemented. Key issues that 

need to be reviewed with this implementation include: 

o 

o 

o 

What information will be required to complete this check? 

What is the authoritative source for this information? 

How will this information be accessed? 

• Potential ITS/CVO Applications – At present, until program requirements and institutional issues are 

further developed, it is difficult to identify potential ITS/CVO applications. The type of safety and 

23



credentials data that could be provided by ITS/CVO applications does not appear to meet the 

requirements of other agencies involved in border crossing and security issues. In addition, while 

some ITS/CVO technologies may be applicable (DSRC standards, transponder applications) a wide 

variety of technologies and applications are being tested and the final applications have not been 

established. 

24



4 Requirements 

Requirements for the Canada-wide ITS/CVO system were developed through the Task 1 Literature Review 

and Stakeholder Interview; the Task 3 review of existing Canadian systems; the Task 4 assessment of 

CVISN Level 1 capabilities; and, the Task 5 review of existing Canadian systems architectures. 

Three subsets of requirements have been identified: 

• Functional. These support the exchange of safety related information. 

• Technical. These define system performance requirements and ensure consistency with the ITS 

architecture for Canada. These also define how additional functionality (future expansion) will be 

incorporated into the existing system. 

• Administrative. These support the development of the system in a cost-effective manner. 

This section provides a summary of the requirements and any assumption that were made in deriving the 

requirement. Where assumptions are made the rationale or justification behind the assumption is also 

given. The complete list of requirements is included as Appendix C. 

In addition, a number of institutional considerations were identified during the course of requirements 

identification and analysis. Many of these are not requirements per se, but rather issues that the SAIC 

Canada team recommends be addressed prior to system development. 

All references to “the system” refer to the Canada-wide ITS/CVO system supporting the exchange of safety 

and Current Trip information between jurisdictions. 

4.1 Functional Requirements 

A total of nine functional requirements were identified. Most of these requirements came directly from the 

RFP and from interviews with the jurisdictions and from interviews with the FMCSA and other US 

authorities in CVO. 

In summary, the systems has to be able to create and store carrier snapshots and make them available to a 

variety of agencies and organisations including other jurisdictions, US jurisdictions and border authorities, 

both Canadian and US. 

A specific requirement that came clear in many interviews is the need to know recent inspection 

information about the specific truck, especially if the truck had recently been put out of service or had 

failed an inspection. This Current Trip Information (CTI) needs to be available alongside the snapshot of 

the carrier. The ECRI system is required to make a decision based on the carrier’s safety rating, included in 

the snapshot, and whether there are any alerts against the specific truck, based on CTI. CTI is only 

necessary as a separate entity, if current inspections are not available on a near real-time basis, and 

recognises the fact that presently the mechanism for exchanging inspection data has a delay of up to a 

week. 

In developing these requirements several assumptions were made. These were: 

25



• Jurisdictions are able to obtain adequate information on drivers and vehicles (D&V) through existing 

mechanisms. 

The initial snapshot proposed for the system is the carrier safety snapshot. This is based on the 

assumption that existing mechanisms (IRE, CDLIS, etc) enable jurisdictions to obtain information on 

drivers and vehicles at this time. The most pressing need at present is for carrier safety information, 

which would be addressed through the development of the system. 

• Jurisdictions carrier profile systems have information to create complete and current carrier profiles for 

inter- and intra-jurisdictional carriers. 

The creation of a carrier safety snapshot is based on the assumption that the data needed to populate 

snapshots is currently available. 

• Current IRE system can be used to access snapshots. 

The proposed system could build on existing systems and functionality as a means of ensuring costeffective 

development. This assumption implies that the current IRE system can be expanded to access 

snapshots from jurisdictions. 

4.2 Technical Requirements 

Twenty-one technical requirements were identified. Many of these requirements deal with security issues 

including making the system itself secure as well as proving information to authorities that support border 

crossing security and the security of Hazardous Materials. 

In developing these requirements several assumptions were made. These were: 

• The existing systems and software in the United States are available for reuse in Canada. 

The key assumptions for identifying technical requirements, and cost-effective system development 

and deployment, are that existing systems can be reused or extended. The US Federal Motor Carrier 

Safety Administration has indicated that any CVISN related software or system available in the public 

domain could be made available if requested by Canada. Similar offers were made by U.S. states that 

have implemented all or part of CVISN. 

• The existing Canadian systems can be extended and accommodate commercial vehicle operations 

requirements. 

The addition of the CDE to the IRE indicates the potential for extending the existing Canadian 

systems. 

4.3 Administrative Requirements 

Two administrative requirements were identified. Interviews with the jurisdictions and with the CCMTA 

secretariat clearly indicated that with cutbacks in the public sector most IT departments are stretched to 

provide support to systems currently in use. Therefore the CVO system must place minimal load on those 

resources and must be done for a reasonable budget. 

26



4.4 Institutional Considerations 

During the Task 1 literature review and interviews, a number of issues were identified that should be 

considered as part of the system design and development. These are issues that may have an impact on the 

successful implementation of a Canada-wide ITS/CVO system, and a proactive approach to addressing 

these may avoid many of the implementation delays experienced by the U.S. with the CVISN program. 

4.4.1 Ownership 

A key issue that needs to be resolved is that of who will be responsible for taking ownership of the system. 

That is, which agency, be it at the national, provincial, or territorial level, will assume responsibility for 

requesting R&D and O&M budget funds and will operate and maintain the system once deployed. A good 

architecture is one that sits well with the existing institutional infrastructure and provides clearly defined 

responsibilities for the development, operation, and maintenance of the system. 

4.4.2 Agreements 

Many provinces stated a need for agreements between the provinces before they were willing to share data. 

The expressed desire was for a “level playing field” where provinces shared common data. 

4.4.3 Sources of Funding 

A major constraint that impacted the U.S. CVISN deployment was that participating states had not 

identified the sources of funding needed for R&D and O&M expenditures. Identifying sources of funding 

proactively will help ensure the project is implemented on schedule. 

4.4.4 Data Privacy 

A major concern of the jurisdictions and the motor carrier industry is data privacy; that is, who has access 

to data, how will data be used, and how will data be protected. An agreement governing data use and 

access is something that would address these concerns. A reference for this might be the ITS America 

guiding principles developed for the US CVISN program. 

4.4.5 Data Concurrency 

Before implementation of the system, there needs to be agreement on several data items. A unique, 

standard identifier is needed for each motor carrier to enable all jurisdictions to use a single identifier to 

access safety information. It is not clear if the NSC number can meet this requirement. 

A standardised safety rating or safety rating criteria is needed to help ensure consistency in enforcement 

actions. This will enable jurisdictions to compare similar information when reviewing a carrier’s safety 

records. This issue was discussed at the 2002 CCMTA Annual Meeting as it is an issue elsewhere, but 

remains unresolved. 

27



5 Roadside Access 

This section discusses the various issues associated with roadside access. Firstly it discusses the various 

data that need to be exchanged with the roadside, then how this data can be accessed and finally means for 

entering inspection data. 

The term “roadside” has a variety of meanings across the Canadian jurisdictions, as does the term 

“mobile”, when referring to inspection stations. The range of facilities is extremely varied and ranges from 

quite extensive fixed facilities with buildings and scales, to inspectors in patrol cars who may have radio 

access depending upon terrain. For purposes of this report, the term fixed refers to sites with facilities and 

mobile refers to sites (or cars) with no facilities and which rely upon radios for communications (both voice 

and data). 

5.1 Data Requirements 

5.1.1 Snapshots 

The Request for Proposals (RFP) requires the development of a Canadian version of the U.S. “snapshot” 

(safety related information) that will need to be agreed upon by the jurisdictions to ensure consistency of 

approaches. This will be based on: 

• A review of the required snapshot elements as discussed by the jurisdictions. 

• The information necessary to assist roadside inspectors in making inspection decisions. 

• The information required from each jurisdiction to be read at the roadside weigh scale/inspection 

station or border crossing. 

• The information in each jurisdiction’s safety system capable of being shared in a snapshot with other 

jurisdictions, beyond the safety rating. 

In addition, the RFP requires that this analysis define how a snapshot will be created directly from a 

jurisdiction’s database and how the snapshot information will be queried from roadside. 

In developing a Canadian version of the U.S. snapshot, the SAIC team: 

• Discussed the existing data elements and data sources of the U.S. snapshot with the U.S. stakeholders 

interviewed for the project. 

• Identified snapshot data requirements and the information needed to make inspection decisions during 

interviews with Canadian stakeholders. 

• Reviewed existing carrier profile information currently being used by Canada (for example, 

Manitoba’s C-SNAP carrier profile). 

• Identified data elements that can be obtained at present from each jurisdictions safety system for 

sharing with other jurisdictions, in addition to safety rating information. 

• Reviewed the available literature on snapshots (the Tri-Global “Development of Implementation 

Options for Exchange and Sharing of Carrier Information Project” project reports and the Johns 

Hopkins University Applied Physics Laboratory CVISN documentation). 

28



The U.S. has developed three separately defined snapshots: motor carrier, vehicle, and driver. However, 

the only snapshot that is in common use is the motor carrier. The vehicle snapshot, which will include 

information such as VIN, recent inspection history, credentials status, is under development and has not 

been established as a production system. The motor carrier industry, as well as some government motor 

vehicle departments, has expressed concern about sharing driver information. This is considered personal 

and confidential information, and consensus on issues such as what information should be shared, who 

should have access to this information, and how will this information be used has not been obtained. 

For the purposes of this report, only a motor carrier snapshot is discussed. SAIC Canada does not 

recommend the development of either vehicle, or driver snapshots at this time, but does recommend that 

the system be developed to accommodate these in the future. By waiting for the U.S. to more fully resolve 

the development and policy issues related to vehicle and driver snapshots, Canada will be able to build on 

U.S. snapshots to accommodate Canadian specific needs. This will reduce costs, and enable the use 

existing software/code. This will also provide an opportunity to proactively identify and resolve any issues 

involved with data exchange/sharing for these two snapshots, both within Canada and with the U.S. 

The recommended Canadian carrier safety snapshot is presented in Table 3 and Table 4. The Data Element 

Description column presents a descriptive list of what information should be included in the snapshot. This 

information includes identifying information (unique carrier identifier, legal entity name/type); contact 

information (address, phone number); carrier descriptive information (carrier classification and operation); 

type of cargo carried; and fleet size (vehicles and drivers). Safety information includes carrier safety rating 

and date of rating; inspection history by type (CVSA level) and number, including Out-of-Service orders 

by type and as a percent of inspections; and, carrier accident history. 

The data elements contained in the recommended snapshot blend the requirements of enforcement 

personnel with existing data availability. While it is possible to expand the data elements, those listed 

represent a starting point for establishing a single snapshot that can be compiled and exchanged by 

Canadian jurisdictions. 

The second column, Data Item, describes the information that will be included in the snapshot for each data 

element. This establishes the structure and format of each data element, and also identifies what type of 

information will be required from existing jurisdictional legacy systems. For those data items that are 

described by the term “numeral”, the information that will be included will be actual number of inspections 

by type of inspection, number of out-of-service orders, OOS as a percent of total inspections, and 

information on accident by type. These data items will be derived from each carrier’s safety history. 

Table 3 – Canadian Carrier Safety Snapshot - Carrier Identification Information 

Data Element Description 

Data Item(s) 

Unique Carrier Identifier 

NSC Number 

Carrier Identifier (other) 

USDOT, DUNS, IRP Account 

Legal Entity Name(s) 

Name(s) 

Lengal Entity Type 

Proprietorship, Partnership, Corporation 

Doing Business As Name 

Name 

Legal Entity Address 

Street Number, Street Name, Jurisdiction Name, 

Postal Code 

Business Address 

Street Number, Street Name, Jurisdiction Name, 

Postal Code 

Legal Entity Phone Number 

Area Code, Phone Number 

Legal Entity Phone Number 


Business Phone Number 


Business FAX Number 

Area Code, Fax Number 

Carrier Classification 

For Hire, Private Fleet, Motor Coach 

29




Carrier Operation 

Cargo Carried 

HazMat Status 

Fleet Size 

Number of Drivers 

Data Item(s) 

Intra Provincial (Non HazMat), Extra Provincial 

(Non HazMat), Intra Provincial (HazMat), Extra 

Provincial ( HazMat) 

Type of Cargo Carried i.e. (liquids, passengers, 

Livestock, Paper products etc.) 

Number of Power Units 

Number of Drivers 

Table 4 - Canadian Carrier Safety Snapshot - Carrier Safety Information 

Description 

Data Item(s) 

Safety Rating 

Excellent, Satisfactory Unaudited, Satisfactory, 

Conditional, Unsatisfactory 

Date Of Safety Rating Month (1-12) , Day ( 1-31 ), Year (1990 – 2100) 

Inspection Type 

Vehicle, Driver, HazMat 

Number of Inspections by Type 

Numeral 

Out Of Service By Type 

Numeral 

% Out of Service By Type Numeral 

Out of Service National Average % 

Numeral 

Number of Fatal Accidents 

Numeral 

Number of Injury Accidents 

Numeral 

Number of Tow Away Accidents 

Numeral 

Total Number of Accidents 

Numeral 

5.1.1.1 Creating Snapshots 

SAIC Canada recommends that the functionality for compiling snapshots be built into the systems 

developed to support the exchange and sharing of data rather than have the snapshots created directly by 

the jurisdiction. Alternatives for sharing data are described in section 6 of this document. The description 

of those options includes the process used for creating snapshot and disseminating the snapshot to the 

roadside in that option. 

5.1.1.2 Snapshot Queries 

Snapshot queries from mobile and fixed site enforcement personnel will generally be implemented as 

follows, although specific details are included in each of the data sharing options: 

• Fixed Site Option A: Snapshot information shall be downloaded from the jurisdictional level to an 

Electronic Clearance and Roadside Inspection (ECRI) computer located at the fixed site. Specific 

snapshot requests may be generated by a signal received from a roadside reader used for electronic 

screening that a transponder-equipped vehicle has been detected or by a request from an inspector who 

is conducting a vehicle inspection. This approach assumes that snapshot information is obtained from 

legacy systems on a real time basis in response to a query. Snapshot information is obtained only in 

response to an actual event. 

• Fixed Site Option B: Snapshot information shall be stored in a jurisdictional level data base and 

downloaded to fixed site facilities based on the operational scenarios described in Option A. This 

approach assumes that snapshot information is not obtained from legacy systems on a real time basis in 

response to a query. Rather, historic snapshot information is obtained from legacy systems and stored 

in a jurisdictional level database. The transmission of this data to roadside may be done on a real time 

basis, but the information provided is historic data and not data compiled on a real time basis. 

30



• Mobile Enforcement Personnel: Snapshot information shall be stored in a jurisdictional level database 

and accessed remotely using wireless or hard-line dial-in communication. 

The general operating practices in the U.S. involve downloading snapshot information to an ECRI prior to 

the actual event (e-screening or inspection) and wireless access for mobile enforcement personnel. SAIC 

Canada recommends these as the approach (Option B). 

5.1.2 Current Trip Information 

Although jurisdictions participating in the US CVISN program are developing the ability to access and 

exchange snapshot data on carriers, the data being exchanged is based on a carrier’s safety and credentials 

history. CVISN does not yet facilitate the exchange of real-time information on a carrier’s current trip, that 

is, information on the results of an inspection or enforcement action, taken against the carrier. An 

additional consideration is that even though the results of an inspection or enforcement action may be 

entered into a province or territory’s information systems on a real-time basis, such results may not trigger 

immediate and automatic updates to carrier snapshot data. Many US states rely on manual data entry of 

inspection results and enforcement actions into the SAFETYNET system, which in turn updates FMCSA’s 

MCMIS system and SAFER. Some states are able to upload inspection results from the roadside 

electronically to SAFETYNET, but in general this is not done on a real time basis. 

As a result, enforcement personnel are able to access a snapshot showing the carrier’s history when a 

vehicle is electronically screened or selected for an inspection, but are not able to determine if the vehicle 

in question has been inspected or subject to an enforcement action while on the current trip or within the 

preceding days. Conversely, a motor carrier may be subject to more than one inspection while on a current 

trip (on both an inter- and intra-provincial/territory basis) even though the previous inspection resulted in 

no enforcement actions or OOS orders. 

To address this existing gap, the SAIC Canada team is recommending the development of the functionality 

that will enable the exchange of information on a carrier’s current trip as well as inspection results and 

enforcement actions that have not yet been entered into legacy system databases. This functionality would 

enable enforcement personnel to electronically “post” the results of an inspection or enforcement action for 

later access by enforcement personnel located in another province or territory, or at a different locale within 

the same jurisdiction. This functionality is made possible by the fact that many provinces already enter 

inspection results electronically in real-time at roadside facilities, and that the rest either have plans for, or 

are in the process of, implementing on-line and real-time data entry of inspection results. SAIC further 

recommends that this information be available to enforcement personnel for up to seven days after the data 

is posted. Based on stakeholder interviews, this seven-day period appears to offer adequate time for 

inspection results and enforcement actions to be uploaded to legacy systems at the province/territory level. 

For the purposes of this report, this functionality is defined as Current Trip Information. The data elements 

that would comprise CTI are presented in Table 5 below. CTI is not intended to be as comprehensive as 

the proposed Carrier Snapshot, but does contain information that will enable the identification of the motor 

carrier and the particular vehicle and driver. Having access to the vehicle and driver information is 

necessary in order to correctly link a CTI file with the vehicle/driver currently subject to enforcement 

activity. The other key components of the CTI file would be information on the results of the most recent 

inspection and any resulting enforcement actions (for example, OOS). 

The CTI file would also include a field for enforcement personnel to use to enter comments or alerts. For 

example, if a vehicle ignores an OOS order and continues on its trip, the CTI function could be used to post 

an alert to other jurisdictions or weigh and inspection stations advising them to interdict the particular 

vehicle. 

31



Table 5 – Current Trip Information Data elements 


Data Item(s) 

Unique Carrier Identifier 

NSC Number 

Carrier Identifier (other) 

USDOT, DUNS, IRP Account 

Vehicle Identifier 

Vehicle Identification Number, License Plate 

number or other unique vehicle identifier 

Driver Identifier 

CDL number or other unique identifying number 

or code 

Origin and Destination 

Trip origin and destination for the particular 

vehicle 

Place of Last Inspection 

Name of inspection facility, highway/route 

number, name of province/territory 

Date and Time of Last Inspection 

Time and date of last inspection for the particular 

vehicle 

Level of Inspection Conducted CVSA inspection level (i.e., Level 1 through 5) 

Inspection Results 

Inspection results including Out of Service orders 

or other enforcement actions 

HazMat Cargo at Last Inspection 

If carrier is carrying HazMat cargo, results of 

HazMat inspection 

Alerts or Comments 

Any additional information available or, if the 

carrier is Out of Service, alert to select vehicle for 

inspection to determine if OOS has been resolved 

Compliance Rating for Vehicle 

Vehicle rating - Satisfactory, Conditional, or 

Unsatisfactory 

Additionally the CTI capability can be used to generate an Alert for the ECRI system. Any inspection 

resulting in an infraction can be used to generate an Alert and can be disseminated to the various ECRI 

systems. 

Ultimately the CTI concept can be expanded to a web-based application allowing the “posting” of a wide 

range of information and not limited to inspection data. 

5.1.3 Recent Inspections 

Many jurisdictions have expressed a desire to be able to view recent inspections in other jurisdictions. The 

CDE presently has a database of inspections that have been presented to it. While this database primarily 

contains inspections from out of province vehicles, it also has the capability of holding inspections from a 

province's own vehicles. Some jurisdictions have been proving in-province inspections to CDE. This 

would be the best vehicle for proving recent inspection data to roadside inspectors. However to be most 

effective, all jurisdictions need to send all inspections to the CDE server and the CCMTA needs to make 

this database available. 

The mechanism is already available to populate the database, but more database development is necessary 

to make the data readily accessible and mechanisms need to be developed to allow access to the database. 

It is recommended that IRE transactions be developed to do this. 

5.1.4 Transponder Database 

Tri-Global Solutions are recommending a registry of transponders for the ECRI system. This database 

needs to be made available across the network, such that as new transponders are allocated the information 

is disseminated to the various ECRI systems. Details of what is in the information are part of the Tri- 

32



Global study. Transponder information could be downloaded nightly or at some other predetermined 

interval. 

5.2 Data Exchange to roadside 

Roadside information in the form of Carrier Snapshots is needed to assist in determining weigh station or 

inspection bypass for a carrier. The idea being that unsafe carriers are the ones who should be targeted for 

more frequent inspection. 

Roadside computer systems downloaded with Carrier Snapshot information will permit enforcement 

personnel additional information needed to determine whether or not to require a carrier to pull into a 

weigh station or inspection facility. Carrier Snapshot information immediately available at the roadside, 

used in conjunction with an Electronic Clearance system, will permit automated clearance systems with 

information needed to provide a “green light for bypass” or “red light” for pull in, to be executed in such a 

manner as to permit feed back to the carrier at highway speeds. 

Canada’s CVO network must provide the mechanism by which Carrier Snapshots are provided to Roadside 

and made immediately available for use by an ECRI system. The three options discussed in Section 4 for 

the creation, storage and dissemination of snapshot information permit the downloading of snapshot 

information to roadside computer systems. The physical means for accomplishing this may include: 

• Dial up or dedicated connectivity from the roadside to the jurisdictional, central, or regional database 

• Internet /VPN to the jurisdictional, central or regional database 

• Cellular Digital Packet Data (CDPD) to the Jurisdictional, central or regional database 

• Jurisdictional communication connectivity. 

Most jurisdictions have good connectivity to their fixed sites via their own intranet and it is recommended 

that they continue this activity, upgrading and expanding as necessary, since it is the fixed sites that will 

have the highest data traffic. 

For mobile situations, many jurisdictions are already in the process of upgrading existing systems and are 

taking advantage of technology available in their area as well as reflecting local geographic conditions. 

While no specific recommendations are made regarding this due to those ongoing activities and the 

uniqueness of each jurisdiction, it is important that mobile sites be given better access to driver and vehicle 

information, recent inspections and have the ability to enter inspections they perform. 

Carrier Snapshots obtained either from jurisdictional, regional or centralised system will be downloaded 

based upon a “subscription” or subset of an entire database of snapshots. This does not preclude a 

complete down load of snapshots to the roadside should that be desired. 

The currency of the carrier snapshot information available at the roadside is a function of the currency of 

data in the jurisdictional, regional or centralised system. 

Sharing of current trip information from roadside systems is a function not dependent on the sharing of 

snapshot information or the network used to convey the snapshot information. Operationally, it is desirable 

to provide information to weigh station or inspection facilities further down the road for use by 

enforcement personnel in ensuring that infractions that result in OOS conditions are communicated. Other 

uses include sharing of information whereby an OOS condition is corrected and this information is used to 

ensure continued movement of the carrier. 

33



5.3 Data Entry and Access 

An additional requirement specified in the RFP is to define how inspection results would be recorded into a 

jurisdiction’s database or central/main system from the roadside for inter-provincial/territorial carriers and 

for international carriers. This includes an assessment of how past inspection reports would be accessed. A 

final requirement is a discussion of how inspectors would input inspection data into electronic form and 

how this data would be uploaded in near real-time, taking into account the variation in information links 

between locations. 

5.3.1 Data Entry 

Many Canadian jurisdictions are currently using laptop computers with preloaded software to record and 

capture inspection data. Of the seven provinces interviewed three enter inspection data on-line while the 

other four still use paper and have the data entered at a central location (see Table 6). 

Table 6 – Status of Roadside Inspection 


Alberta 



Ontario 

Quebec 

Nova Scotia 


Automated roadside 

inspection Fixed site stations yes yes no no yes no no 

Mobile site stations yes yes no no yes no no 

In Nova Scotia all safety inspections, CVSA and others, done at fixed site truck inspections stations are 

reported interactively to the CAPS system via the station computers. Enforcement Officers use Internet 

Explorer browser to access information from the CAPS, and transfer CVSA inspection reports to the 

CAPS. At the present time, patrol vehicles are only equipped with mobile radios for voice communication 

over a provincial trunk radio network. Enforcement officers contact either fixed site stations or central 

office in order to get information on vehicle, driver and carrier. However, these patrol vehicles will be 

equipped with in-vehicle computers and printers starting shortly. In-vehicle computers will be ruggedised 

laptop computers with docking facilities and CDPD radio modems. These in-vehicle computers will have 

identical features, functions and operating characteristics as those fixed site station desktop computers. 

Thus, all safety inspections, CVSA and others, done at mobile site stations will be reported interactively to 

the CAPS. 

In Quebec all fixed site truck inspection stations are equipped with, desktop computers and printers. All 

safety inspections, CVSA and others, done at fixed site truck inspections stations are reported interactively 

to the SAAQ system via the station computers. 

All mobile site stations patrol vehicles are equipped with in-vehicle computers and printers. In-vehicle 

computers are ruggedised laptop computers with docking facilities and radio modems. These in-vehicle 

34



computers have identical features, functions and operating characteristics as those fixed site station desktop 

computers. Thus, all safety inspections, CVSA and others, done at mobile site stations are reported 

interactively to the SAAQ system via the in-vehicle computers. 

Currently, in Ontario, all safety inspections, CVSA and others, done at both fixed and mobile site TIS are 

reported in paper form. These reports are sent to the central office, i.e. the Carrier Enforcement Program 

Office in St. Catharines. 

However, in progress with the "legacy system renewal" program, all fixed site TIS will be equipped with 

new computers and client applications to work with the new Inquiry Services System. With the new 

computers and system set-up, there will be additional network ports/connections available for plugging in 

notebook and laptop computers for other authorised users. Also, all mobile site TIS, i.e. patrol vehicles, 

will be equipped with in-vehicle computers and printers. In-vehicle computers are rugged zed laptop 

computers with docking facilities and radio modems. Eventually, all enforcement officers in both fixed and 

mobile site TIS will have browser-based interactive access to the Inquiry Services System for driver, 

vehicle and carrier information from the mainframe databases. 

Parallel to the Inquiry Services System development and testing, a pilot project using notebooks to capture 

inspection data is under planning and development. 

In Manitoba, enforcement officers use desktop or laptop computers for inquiry operation only. CVSA 

inspections are reported in paper form, which are sent to the central office for keying into the CPS. 

When CVSA inspections are done at either fixed or mobile site, vehicle inspection stations in 

Saskatchewan, enforcement officers use laptops to record inspection results. At locations where either 

landline or CDPD communication is possible, the inspection results are entered into the CVSA system 

directly. Paper form CVSA reports are prepared only when the enforcement officer does not have a laptop 

or notebook for recording data or where there is no communication facility nearby. 

Most mobile site vehicle inspection stations, i.e. patrol vehicles, are equipped with in-vehicle computers 

and printers. These are rugged zed laptop or notebook computers with docking facilities and CDPD radio 

modems. These in-vehicle computers have identical features, functions and operating characteristics as 

those fixed site station desktop computers. These in-vehicle computers are installed with applications for 

CVSA inspections data capturing and reporting on-line to the CVSA system. At remote location where 

there is no CDPD coverage, enforcement officers use mobile radios to contact the SHT telecommunication 

office to get driver and vehicle information. Many enforcement officers carry portable load scales in their 

patrol vehicles. 

Currently, all safety inspections, CVSA and others, done at both fixed and mobile site vehicle inspection 

stations in Alberta are reported in paper form. These reports are sent to the Carrier Services headquarters in 

Red Deer and manually keyed into the MOTRIS system. 

There was a proposal put out a while ago on a project for roadside capturing of inspection data of vehicles. 

However, the project has not progressed further. 

Currently, all safety inspections, CVSA and others, done at both fixed and mobile site vehicle inspection 

stations in British Columbia are reported in paper form. These reports are sent to the central office and 

manually keyed into the databases of the two mainframes. There is no roadside data capture capability for 

safety inspection reporting. 

SAIC recommends that all jurisdictions not presently capturing inspections in real-time, consider using 

laptops and preloaded software to capture and record inspection data. This approach offers the benefit that 

inspection data will be captured electronically, eliminating or reducing the need for manual entry. This will 

35



also reduce data entry errors. There are many technologies available and many jurisdictions are exploring 

alternatives including voice recognition software and touch screens. Consequently SAIC Canada has not 

made any specific recommendations regarding the specific technology to be employed, although for those 

without any plans the ASPEN software is readily available. For a fully successful data-sharing network it 

is important that all jurisdictions have their inspections on-line. Many jurisdictions have CVO systems 

capable of updating CTI of inspected vehicles as soon as their inspection results are reported on-line. 

5.3.2 Entry Into Jurisdictional Database 

Inspection data can be uploaded to the jurisdiction level in several ways: 

• Inspections done at a fixed site may be uploaded to an ECRI system as each inspection is completed or 

in a once a day upload of all inspection results. 

o 

o 

The ECRI computer would upload these inspection results to the jurisdiction’s 

CVIEW/CSAFER portal. 

The CVIEW/CSAFER portal would in turn submit the information to the jurisdiction’s legacy 

systems for updating carrier safety records. 

• Inspections done by mobile personnel may be uploaded using wireless communications. This upload 

can be done as each inspection is completed or as a once a day batch submittal. 

o 

o 

Uploads done remotely would be submitted to a CVIEW/CSAFER portal. 

The CVIEW/CSAFER portal would in turn submit the information to the jurisdiction’s legacy 

systems for updating carrier safety records. 

• Inspections done by remote personnel may also be captured on a floppy disk, which in turn is returned 

to a jurisdiction and uploaded directly into legacy systems. 

SAIC Canada recognises that a number of inspections conducted by enforcement personnel will be for outof-province/territory 

carriers. SAIC Canada recommends that the system include the functionality to route 

these inspections to the base jurisdiction, using the unique carrier identifier. As each inspection result is 

received by the inspecting jurisdiction’s CVIEW/CSAFER portal, the unique identifier number will be 

screened by the system. The system will be able to determine if the inspection result should be submitted 

to the inspecting jurisdiction’s legacy systems for updating or forwarded to the base jurisdiction. 

For those out-of-province/territory inspections, the system shall compile and transmit these inspection 

results to the base jurisdiction's CVIEW/CSAFER portal. The base jurisdictions CVIEW/CSAFER portal 

will in turn have the functionality to receive these inspection results and submit them to legacy systems for 

carrier safety history updates. 

A jurisdiction would in turn receive information on inter-provincial/territory motor carriers, including past 

inspection histories, by generating a query to the base jurisdiction. This would enable each jurisdiction to 

obtain information on out-of-province/territory jurisdictions, and would also ensure that each base 

jurisdiction maintains authoritative source status for providing information on carrier safety history and 

status. 

36



6 Data Sharing 

Based upon the interviews and literature reviews conducted as part of this feasibility study, concepts for 

Data Sharing have emerged. Much work in analysing existing Commercial Vehicle Operations Data 

Sharing and Exchange systems has been conducted. The SAIC Canada team has benefited from this 

analysis in outlining the following approaches to Data Sharing of Motor Carrier Safety Information among 

Canada’s Provinces, Territories and the United States. 

With regard to the concepts for data sharing, the following assumptions have been made that apply 

regardless of the data sharing option outlined. Those assumptions are: 

• Provincial legacy systems that contain Driver and Vehicle information and Carrier Profile information 

can be used to create Carrier “snapshots”. 

• That the current IRE can be used as an inter-provincial, international (Canada/United States) 

information sharing network. 

• That U.S. developed CVISN components can be made available to use in development of a Canadian 

Motor Carrier Safety Information Sharing system. 

• Provinces will have specified unique carrier identifiers. 

The requirements discussed in Section 2 of this study also serve as a basis for the data sharing concept 

options. They also apply regardless of data sharing option outlined. 

As discussed in earlier sections, the primary data that needs sharing on an urgent basis are Carrier 

Snapshots and current trip information. Also needing sharing, but to a lesser extent, are carrier profiles and 

inspection data. 

Before discussing the various options, there are some general concepts that apply throughout. Some 

generalisation has been made regarding the systems and equipment in each jurisdiction as well as 

assumptions regarding the outcomes of the ECRI study. These concepts are: 

• Jurisdictions have a variety of central computers control various aspects of their operation, including a 

system for creating and storing carrier profile information. 

• Jurisdictions have both fixed and mobile sites. The actual set-up of these varies somewhat from 

jurisdiction to jurisdiction, but generally fixed sites have “permanent” communication facilities, while 

mobile sites (typically cars) have to rely upon wireless communications. Typically fixed sites have 

permanent computing facilities, while mobile sites, at best have to rely upon laptop equipment. 

• Some (ideally all) fixed sites will be equipped with an ECRI system. The purpose of the ECRI system 

is to control and monitor all aspects of the ECRI operation including making bypass decisions. 

• While the ECRI system needs to access snapshots on a near-real time basis, the snapshots themselves 

will change infrequently. 

Generally none of the options discuss changing the present operation of jurisdictions although many will 

need to upgrade their systems and operations to fully take advantage of both ECRI and data sharing. As a 

result the options also do not discuss the movement of legacy data e.g. inspections. 

37



Since this section deals with data sharing, none of the options attempt to show the network and how the 

various data elements would be transmitted. These options are discussed in detail in Section 5. Similarly 

the options do not attempt to indicate how the various jurisdictional systems would be interconnected. 

6.1 Option 1 – Centralised Canadian Safety and Fitness Electronic 

Records (CSAFER) System. 

6.1.1 Option 1 Description 

This concept involves a centralised system/database to create and store Carrier Snapshot information. 

Motor Carrier Profile Information residing in the provincial legacy systems would be downloaded and 

formatted into a snapshot by CSAFER. Carrier snapshots could be accessed by any Province or Territory 

using the IRE network to query the database. 

CSAFER would be the national repository of Carrier Snapshot information. CSAFER would also permit 

the storage and retrieval of Current Trip Information (CTI) for provincial enforcement personnel at the 

roadside. CTI would be a function used by roadside enforcement personnel for communication of 

enforcement actions to other jurisdictions. CTI information would only be uploaded from roadside to 

CSAFER if a Carrier were inspected and found in violation of Motor Carrier Regulations resulting in an 

enforcement action. 

For jurisdictions to share data they would need to extract carrier profile information from their legacy 

systems and down load it to the CSAFER system. IRE would be the communications mechanism. 

Depending on the formatting scheme (EDI, FLAT FILE or XML) the Gateway may not be required as is 

currently done with CDE. Communications to and from CSAFER from the roadside would need to be 

established via some network. Options include Provincial Dedicated Landline, Provincial Radio network 

(microwave etc.), Dial up, Internet VPN, or CDPD. Section 5 discusses more fully the communications and 

network scenarios for roadside access and data sharing for the purpose of Electronic Clearance and 

Roadside Inspection. 

The Centralised System Concept accommodates communications with U.S. Systems via the existing 

IRE/AAMVANet interface. 

Figure 3 is a high level depiction of the Centralised Canadian Safety and Fitness Electronic Records 

System. While analogous to the U.S. Safety and Fitness Electronic Records System, there are some 

differences between it and the current concept for CSAFER. CSAFER in this implementation would only 

be used to provide Carrier level snapshot information and current trip information. Also, each jurisdiction 

would be the “authoritative source” for carrier information for its based carriers. 

38



Participating Jurisdiction 

CSAFER 

Road Side Computer 

Local Intranet, 

Dial up and 

Wireless 

Network 

Provincial Legacy Mainframes 

Jurisdictional System 

Other Jurisdiction 

AAMVANet 

Other Jurisdiction 

SAFER 

Figure 3 - Option 1 Centralised System 

39



Table 7 shows how data is used by the various system elements in this option. 

Table 7 - Option 1 Data Use 

System Receives Sends Role in Data Sharing 

CSAFER • Carrier Profiles 

• Snapshots • Creates snapshots 

• CTI 

• CTI 

from Carrier Profiles 

• Serves as a CTI 

Roadside 

Mobiles 

• Snapshots (on request) 

• CTI (on request) 

Roadside – fixed • Snapshots (on request) 


ECRI Systems • Snapshots (all) 

• CTI (all) 

Provincial 

Legacy Carrier 

Profile System 

6.1.2 Technical Challenges 

• Requests 

• Inspections 

• Requests 


• Inspections • Carrier 

Profiles 

• CTI 

The technical challenges that this option presents includes: 

Repository 

• Queries CSAFER for 

snapshots and CTI. 

• Provides CTI 

information to the 

legacy systems 

• Queries CSAFER for 





• Serves as a local copy 

of the CSAFER to 

enable real-time 

access. 

• Provides Carrier 

Profiles and CTI 

information to 

CSAFER. 

• Determination of whether a custom developed CSAFER system might better accommodate Canada’s 

requirements 

• Determination of whether the US SAFER system modified to meet Canada’s requirements might better 

accommodate Canada’s implementation. 

• Determination of the data exchange format schemes permitted (i.e. EDI, FLAT FILE, XML etc.). 

• Determination of the method for remote access from roadside systems to CSAFER such as: 

o 

o 

o 

o 

o 

Dedicated landline 

Dial up 

Provoncial Radio Network 

Internet VPN 

CDPD 

40



6.1.3 Snapshot Creation and Updating 

Each jurisdiction is the authoritative source of information for carriers based in that jurisdiction. The 

general process of creating snapshots is shown in Figure 4. As such, each jurisdiction would be responsible 

for providing information to CSAFER from which a Carrier Snapshot would be created. Update of 

snapshot information in this option can be done in one of two ways. 

Jurisdiction A determines 

the need to create a new 

Snapshot 

Carrier Profile 

Information is sent to 

CSAFER 

CSAFER generates new 

Snapshot from Profile 

Information 

Snapshot data is 

uploaded to ECRI 

Systems (either all or by 

subscription) 

Snapshot is stored by 

Jurisdictions for access 

by fixed/mobile site 

enforcement personnel 

Figure 4 – Option 1 Snapshot Creation and Update 

One method for updating information might be a weekly upload of all carrier information that has changed 

in a jurisdiction to CSAFER for formatting into carrier snapshots. CSAFER would format the information 

provided by the jurisdiction into carrier snapshots and update the CSAFER database for use by all 

jurisdictions. Each jurisdiction would upload their changed/new information in the same way. 

Another method might be for a jurisdiction to provide on an as occurring basis, any changed or new 

information to CSAFER. CSAFER would format the information into a snapshot and update the database 

as information is received. 

6.1.4 Roadside Access 

To provide near real-time access to snapshots and CTI, this information needs to be loaded onto each ECRI 

system. This could be done either on a subscription basis i.e. each jurisdiction could request snapshots and 

CTI from only specific jurisdictions or on a duplication basis i.e. the ECRI could completely duplicate all 

snapshots and CTI. With the subscription scheme each ECRI system could have different data depending 

upon what was relevant to the inspection station. 

41



To provide snapshots and CTI to mobile stations, a copy of the data needs to be kept at a central location in 

the jurisdiction. In this case real-time access is not an issue, as mobile stations are not intended to make 

decisions in real-time i.e. it is not intended that mobile sites carry an ECRI system. A mechanism may 

need to be provided to cover the situation of inspection stations that are set up at a fixed location, but do not 

have permanent facilities, but which desire to use ECRI. In this case the ECRI system will either need to 

be programmed with snapshots prior to leaving for the site or, when it is connected to the network on site, it 

can access the central system and obtain snapshots prior commencing operation. If desired mobile stations 

could be given access to a designated ECRI system. 

The ECRI system could be updated nightly when both roadside traffic and network traffic is lightest. 

However failure to update is not a major problem as snapshots will not change often and only CTI 

information could be out of date. If the possibility of out of date CTI information is considered a major 

concern then a mechanism will be required to disseminate at least the Alerts generate by CTI data. 

6.1.5 Maintenance Plan 

This centralised CSAFER approach requires a base from where the physical hardware, network 

connectivity and software can be updated and maintained. If based within a jurisdiction (or provided by a 

national organisation), that jurisdictions IT resources and physical facility might be used to perform 

maintenance that includes: 

• periodic backup of the CSAFER database 

• system and security administration 

• system and application software updates 

• user help and assistance. 

6.1.6 Impediments/Issues 

There are a number of impediments and or issues confronting this option. Some of them include: 

• Identification of the “hosting” organisation or jurisdiction for CSAFER. 

• Development of consensus among jurisdictions regarding the centralised implementation of the CVO 

network. 

• Determination of the funding mechanism(s) for development, implementation and on going operations 

and maintenance of the CSAFER system. 

• Design, development and implementation of Current Trip Information functionality. 

• Reciprocity on sharing of carrier level information between Canada and the United States. 

6.1.7 Option 1 Advantages and Disadvantages 

Advantages: 

• Central Administration of Database and Snapshots. 

42



• Becomes a single “authoritative source” for snapshots. 

• Ability to use the application developed for the US SAFER system. 

• Supports use of Vehicle and Driver Snapshots should they become part of the system. 

• Permits easy implementation for public access to the snapshots should this be desirable. 

• Lowest deployment costs. 

Disadvantages: 

• The need to identify, fund and set-up the Central Administration 

• Need for redundancy to limit single point of failure add to cost 

• Relinquishes some autonomy by the jurisdictions to a central administration to create, store and share 

snapshot information. 

6.2 Option 2 - Decentralised Carrier Safety Information System 


The concept for the decentralised Carrier Safety Information System is based on each jurisdiction being the 

“authoritative source” of data for carriers based in that jurisdiction. Each jurisdiction would create, update, 

store and forward carrier snapshots upon request from other jurisdictions. Snapshots would be created 

from information existing in jurisdictional motor carrier information systems. 

Current trip information would also be shared based on inspection status of a carrier forwarded from the 

roadside to the Carrier Safety Information system. Each function, snapshot exchange and current trip data 

would be exchanged using new IRE Transactions. 

Carrier information (carrier snapshots) needed at the roadside would be downloaded from the jurisdictional 

Carrier Safety Information system. Variations of the decentralised Carrier Safety Information System 

include development of an application to format snapshots from legacy system information or integration 

of a CVIEW application that accepts carrier profile information from the legacy systems, formats and 

stores jurisdictional snapshots. 

Based on interviews with each of the provinces, and status of automation assessment, the decentralised 

option builds upon current provincial architectures and network interconnectivity. It uses the carrier safety 

information resident on provincial legacy systems, and the IRE network to communicate that information to 

other jurisdictions. The carrier information however requires a common format (snapshot). Each 

jurisdiction would need to implement new functionality to format snapshots for use by all Canadian 

jurisdictions. Snapshots could also be shared with the United States for carriers operating internationally. 

Current Trip Information about a carrier could also be communicated using the existing IRE network once 

the trip information was formatted by a roadside system and uploaded to the common IRE network. Again, 

a common format for the information would be needed to communicate this information. Since CTI 

information is not kept for any length of time by any one jurisdiction, the store and forward capabilities of 

the IRE are used to communicate the information to other jurisdictions on the carrier’s route. 

Figure 5 depicts the decentralised concept with both variations. 

43



Other 

Jurisdiction 

Local 

Intranet 

Roadside System 

CVIEW 

Jurisdictional Legacy System 


Jurisdiction 

Network 

Local 

Intranet 


c/w Snapshot Application 


Jurisdiction 

AAMVANet 


SAFER 

Figure 5 – Option 2 Decentralised System 

44



Table 8 shows how data is used by the various system components in this option. 



CVIEW • Carrier Profiles 


• CTI 

• CTI 


• Snapshots from other 

jurisdictions 


Repository 

Roadside 

Mobiles 






• CTI (all) 

Provincial 





• Requests 


• Requests 



• CTI 

Some of the technical challenges this option presents include: 

• Agreement and standardisation of the snapshot format. 

• Definition of the contents and source of Current Trip Information (CTI). 

• Development and co-ordination of a concept of operations for CTI. 

• Development of new IRE transactions (carrier snapshot, and current trip information). 

• Queries CVIEW for 





• Queries CVIEW for 






of the CVIEW to 

enable real-time 

access. 




CVIEW. 

• Potential development and implementation of a program to create, store and forward carrier snapshots 

from Legacy system carrier profile information. 

• Potential development and implementation of a program to query receive and store snapshots from 

other jurisdictions. 

• Determination of whether the US developed CVIEW system can be used to accommodate Canada’s 

requirements. 

45




Each jurisdiction is the authoritative source of information for carriers based in that jurisdiction. . The 

general process of creating a snapshot is shown in Figure 6. Snapshots would be updated by the originating 

jurisdiction when information changes in the carrier profile legacy system of that jurisdiction. Legacy 

system changes would trigger a snapshot update. This could be done on an as occurring basis. Updates 

would occur on a one by one or individual basis. Another approach to updates would be periodic (weekly 

or monthly) whereby all snapshots would be ‘recreated” using the latest information out of the legacy 

system that week or month. The method of updating would need to be co-ordinated with other jurisdictions 

to ensure some consistency with regard to currency of the information among jurisdictions. 



Snapshot 



Local CVIEW (or CVIEW 

Application) 

CVIEW generates new 



Changed Snapshot data 

is uploaded to other 

CVIEW Systems in other 

jurisdictions 




subscription) 



Jurisdiction A for access 

by fixed/mobile site 









decisions in real-time. If desired mobile stations could be given access to a designated ECRI system. 



information could be out of date. 

46




This option requires each jurisdiction to provide needed maintenance for the carrier information system in 

their province. Provincial technical resources would provide: 

• Periodic backup of the carrier information system snapshots (in concert with other jurisdictions) 

• System and security administration 

• System and application software updates/enhancements/fixes 

• User help and assistance. 


The following impediments/issues need to be addressed in order to implement this option. They include: 

• Determination of the funding mechanism for development, implementation and on going operations 

and maintenance for each jurisdictions carrier safety information system. 

• Agreement on the contents of the carrier snapshot and current trip information among all jurisdictions. 

• Adoption of new IRE transactions to accommodate Carrier Safety Information sharing and exchange. 

• Reciprocity on sharing of carrier level information between Canada and the United States. 



• Builds upon current IRE/CDE architecture. 

• Jurisdictions can maintain authoritative control for snapshot information for their registered carriers. 

• Ability to use the US developed CVIEW to create, store and share snapshots. 

• Lends itself to phased implementation and provides flexibility to jurisdictions in its implementation. 

• Lends itself well to use of IRE. 


• Jurisdiction needs to develop and/or integrate capability to create and store snapshot from legacy 

system information. 

• Jurisdiction absorbs majority of the development costs. 

• Highest deployment costs. 

47



6.3 Option 3 – Regional Motor Carrier Data Safety Information System 


This concept involves regional systems/data bases for the creation, storage, and sharing of Motor Carrier 

Snapshot information. A region would be comprised of two or more jurisdictions whose Motor Carrier 

data is housed in a “regional” Motor Carrier Safety Information system database. The Regional Motor 

Carrier Safety Information system and database would be hosted, operated and maintained in one of the 

Region’s jurisdictions. 

Each regional information system would create snapshots for jurisdictions in its region and would share 

snapshot data via the IRE or other common network with the other Regional Systems. Jurisdictions 

comprising a Region would send their Motor Carrier Profile information to the Regional System for 

formatting into snapshot data to be shared. 

Operationally jurisdictions would first query their Regional System for a snapshot of a particular carrier. It 

is anticipated that a majority of carrier snapshot queries would exist in their regional system. If a specific 

snapshot were not resident on the regional system, the regional system would query the other regions for 

the snapshot. 

Development of the regional systems could be accomplished either by designing and developing a custom 

application or modifying the US CVIEW system for use by the defined Canadian regions. 

Figure 7 depicts the regional concept. 

48



SAFER 

Regional 

CSAFER 

Lead Regional Jurisdiction 

Legacy Systems 

Local 

intranet 

Participating 

Regional 

Jurisdiction #1 

AAMVANet 

Participating 

Regional 


Participating 

Regional 


Network 

Participating 

Regional 


Participating 

Regional 


Participating 

Regional 


etc 

Regional 

CSAFER 

Regional 

CSAFER 

Local 


Local 




Figure 7 – Option 3 Regional Database System 

Table 9 shows how data is used by various system elements in this model. 



49





Regional CVIEW • Carrier Profiles 


• CTI 

• CTI 


• Snapshots from other 

regional CVIEWS 


Repository 

Roadside 

Mobiles 






• CTI (all) 

Provincial 





• Requests 


• Requests 



• CTI 

• Queries Regional 

CVIEW for snapshots 

and CTI. 




• Queries Regional 

CVIEW for snapshots 

and CTI. 





of the Regional 

CVIEW to enable 

real-time access. 




Regional CVIEW. 

The regional Motor Carrier Safety Information System concept presents a number of technical challenges. 

Among them are: 

• Determination of whether to develop a custom application or modify the US CVIEW system for use. 

• Determination of the location/jurisdiction to host the regional site. 

• Determination of the jurisdiction(s) that comprise a region. 

• Developing new IRE transactions for Carrier Snapshots and Current Trip Information. 


As with the other two options, snapshot updates in the Regional Concept could be accomplished by: 

• Having each jurisdiction in a region send a periodic up load of all carrier profile information that has 

changed since the last upload to the Regional system. The regional system would then format the 

profile information into a snapshot and the regional database would be updated. 

• Or, having each jurisdiction in the region send carrier profile information that has changed on an as 

occurring basis to the regional system. Again, the regional system would format the information into a 

snapshot and the regional database would be updated. 

50



Figure 8 shows the process from creating and updating the regional snapshot. 



Snapshot 



Regional CVIEW 

CVIEW generates new 



Changed Snapshot data 

is uploaded to other 

CVIEW Systems in other 

regions 




subscription) 



Jurisdiction for access by 

fixed/mobile site 






snapshots and CTI. With the subscription scheme each ECRI system could have different data depending 

upon what was relevant to the inspection station. 



decisions in real-time. If desired mobile stations could be given access to a designated ECRI system. 



information would possibly be out of date. 


The regional approach requires two or more regions to be established. Each province hosting the regional 

system would be responsible for operation and maintenance of the system. Some funding accommodation 

would need to be established among jurisdictions in the region to support the hosting province in their role 

as regional host. Maintenance tasks to be accomplished would include: 

51



• Periodic backup of the carrier information system snapshots (in concert with other regions) 

• System and security administration 

• System and application software updates/enhancements/fixes 


Many of the impediments and issues are common to each of the options. The following are specific to this 

approach: 

• Determination and establishment of regions that include two or more provinces 

• Selection of the Regional Host for the system. 

• Determination of how regional system development, operation and maintenance are funded. 



• Permits sharing of implementation costs on a regional basis. Some regions already have other activity 

done regionally. 

• Adjacent jurisdictions would all share the same information database. 

• Ability to use the US developed CVIEW for each regional implementation. 

• Reduced deployment costs over option 2. 


• The need to synchronise the regional databases with one another. 

• The need to establish regions for data sharing. 

• Increased cost of development due to regional concept. 

• Increased deployment costs over option 1. 

52



7 Network Scenarios 

This section addresses the issues associated with putting a Canada-wide CVO network in place. While the 

options for Data Sharing and for networking are not completely independent they can be discussed 

separately. 

7.1 Option 1 Use of the Existing IRE Network 

7.1.1 Description 

The IRE network has already proven amenable to extension when additional transaction types were added 

to support CDE. It is a relatively logical extension to add additional transaction types to support additional 

data sharing and the distribution of snapshots and CTI. The actual transaction types would depend upon 

several of the choices made in each of the Data Sharing options. In many cases the data would flow 

somewhat similar to the present CDE using either a series of IRE transaction to send carrier profile 

information or to request snapshot information. Alternatively, as with CDE, data could be transferred in a 

flat file using FTP. 



(Mobile) 


(Mobile) 

IRE/CDE 

Network 

Gateway 

Provincial 

Local Network 

(Intranet) 

ECRI System 


Jurisdictions 


(Fixed) 


Figure 9 – IRE Network Configuration 

Jurisdictions wishing to use IRE transactions can connect their legacy systems to the IRE gateway via their 

internal network and can FTP directly. In all data sharing options the Snapshot server will appear as 

another node(s) on the IRE network. 

53



From a networking perspective this will require minimal changes to the existing IRE network, although 

additional bandwidth may be necessary. Jurisdictions may need to purchase additional networking 

equipment (hubs, routers etc.). 

Using Option 1 of the Data Sharing Options as an example only, the transactions would be similar to the 

following (reference Figure 2 – Option 1 Snapshot Creation and Update): 

• Jurisdiction A sends a Carrier profile to the appropriate snapshot server. 

• The Snapshot server acknowledges. 

• Snapshot server sends snapshot(s) to all or to appropriate ECRI servers. This is likely a timed event to 

minimise network traffic. 

• ECRI servers Acknowledge. 

The above scenario requires the creation of two new transaction types to support sending a Carrier Profile 

and for sending a Snapshot. Additional transactions would need to be generated to support activity such as 

subscription if that mechanism is chosen. 


The technical challenges of this approach are relatively small and consistent with work previously done on 

CDE. Many of the issues typically associated with developing a network e.g. security, have already been 

addressed. While the specifics are very dependent upon exactly which data sharing option is chosen, some 

of the challenges are: 

• Defining new transaction types and associated functionality. 

• Assessing bandwidth of existing IRE network. 

• Develop mechanisms to support regional snapshot servers, subscription of snapshot and snapshot 

distribution. 

7.1.3 Advantages and Disadvantages of Option 1 

7.1.3.1 Advantages 

• Consistent with current practise in the jurisdictions. 

• Low cost 

• No need for additional support contracts. 

• Use of existing provincial Intranet 

• Uses a private Internet 

• Very secure and predictably scalable 

• With fixed size transactions, consistent near real-time network responses possible 

54



• Permit phased participation by province 

• Faster deployment for most provinces 

• Less expensive to develop 

• Lends itself well to US access. 

7.1.3.2 Disadvantages 

• Does not lend itself well to newer technologies such as XML and making data available across the 

Internet. 

• Need clear demarcation of responsibility for development parties. 

• Slower deployment for a few provinces. 

• Additional costs to operate and maintain the IRE network. 

7.2 Option 2 Intranet-based Virtual Private Network (VPN) 

7.2.1 Description 

All provinces operate their CVO systems with client access through one or a combination of provincial data 

networks, public cell phone networks, public CDPD networks, provincial telecommunication networks, and 

provincial Intranets. Not all provinces possess or utilise all the mentioned networks. An Intranet is often 

defined as a network connecting an affiliated set of clients (such as company employees or authorised 

users) using standard Internet protocols (e.g. TCP/IP and HTTP). Thus, provincial Intranets, provincial 

data networks and telecommunication networks are essentially private networks. 

Some provinces offer browser-based client services to access most of their CVO information and update 

some of their CVO information. These clients are either provincial government employees or authorised 

provincial Intranet users. A few provinces, notably Ontario and Manitoba, offer browser-based public 

clients to access some of their CVO information through the Internet. From conversations with 

interviewees, many more provinces are either considering expanding their client services through the 

Internet or contemplating offering client services through the Internet. Regardless of their intentions, 

browser-based client service over Internet or Intranet appears to be the emerging technology to consider for 

inter-provincial data exchange and data sharing activities. 

Since all provinces have Intranets for internal businesses, provincial IT employees are experienced and 

familiar with development and implementation of web servers and portals. Intra-provincially, the 

infrastructure for the support of an ITS/CVO Network is already in place, though not necessarily 

supporting all the functions at this time. It is tempting to extend a provincial Intranet to other provinces. 

However, this approach is not cost effective and expensive to maintain, since Intranet client sites (nodes) 

are connected to their server(s) via private leased lines or landlines. Distance and scalability become a 

major problem when extended provincial Intranets are used to form the basis of an ITS/CVO Network. A 

possible solution is the concept of Virtual Private Network or VPN. 

55




(Mobile) 


(Mobile) 

Internet 

VPN Server 

Provincial 

Local Network 

(Intranet) 

ECRI System 


Jurisdictions 


(Fixed) 

Jurisdictional Legacy Systems 

Figure 10 – VPN Network configuration 

A VPN is a private network that uses a public network, usually the Internet, to connect remote sites (nodes) 

or users together. Instead of using dedicated leased lines, a provincial VPN uses "virtual" connections 

routed through the Internet from the province's private network, i.e. the provincial Intranet, to clients in 

other provinces. 

The concept of VPN over Intranet offers an alternative network scenario that should be considered for the 

development of an ITS/CVO Network. For the ITS/CVO Network application, the VPN in question would 

be of Intranet-based site-to-site (i.e. province-to-province) configuration. The site-to-site connection will 

be through the Internet, and each site is a province's VPN server. Thus, each province will have its own 

VPN over its own Intranet and connected to the Internet. 

Depending on the current state of technologies used, the extent of network coverage and available client 

services in a province's Intranet, Intranet-based VPN has the potential of facilitating faster and less 

expensive deployment of an ITS/CVO Network. An Intranet-based VPN makes use of existing 

infrastructure in a province. An Intranet-based VPN server may be created as applications in a partition of 

existing IT computer systems in a province. An Intranet-based VPN, once developed and created, typical 

has the features of intrinsically open architecture, scalability, and simplified network topology. The 

ITS/CVO Network in effect becomes a virtual network with "universal" connectivity. 

The development of an ITS/CVO Network based on the concept of Intranet-based VPN is mostly the effort 

for the creation of the VPN server. Typically, there will be three parts to the development of this type of 

VPN server; 1) the interfaces to the provincial Intranet and CVO systems; 2) the web portal for client 

56



services; and 3) the interfaces to the extra-provincial VPNs. While the part of development of interfaces to 

the provincial Intranet and CVO systems requires efforts from each individual province since these 

interfaces are very province-specific, the other two parts may be developed by a single entity. 


Since VPN uses a public network (the Internet), it suffers the same problems as any other public networks. 

Specifically, there are security, scalability, reliability, network management and policy management 

concerns of the virtual network. In theory, any public user can assess or hack into the VPN, the Internet 

has unlimited bandwidth, the Internet has good QoS (Quality of Service) most of the time and network and 

policy management can be reasonably controlled. An ITS/CVO Network built on Intranet-based VPN 

presents major technical challenges in security, scalability and reliability of the network. Meeting these 

technical challenges, considerations must be given to the followings in developing the VPN: 

Security - 

• Firewall to provide a strong barrier between the VPN and the Internet 

• Encryption to ensure data from one VPN can only be read by the intended receiver VPN 

• Internet Protocol Security Protocol (IPSec) using Tunnelling to encapsulate packets 

• Authentication to ensure the identity of all communicating parties. 

Scalability - 

• Bandwidth on demand versus fixed bandwidth 

• ATM versus Frame Relay for bandwidth requirement for the province 

QoS - 

• Use of standard QoS mechanism 

• Application of network traffic management tools and practice 

• Merits of third party "managed VPN services" 

7.2.3 Use of the Existing IRE Network 

While VPN by definition uses the Internet public network, it is possible to create a restricted-access 

Internet network by using the existing IRE network as the transportation medium. This, however, does not 

benefit from the public and openness of the Internet. 

On the other hand, the use of the existing IRE network in the construct of the ITS/CVO Network based on 

the concept of Intranet-based VPN does present some unique solutions to the above-described technical 

challenges, on the following grounds: 

Security - 

• The IRE network is a private network with no "public" accesses 

57



• IP address routing is easily controllable 

• All communicating parties are presumably authorised and authenticated 

Scalability - 

• The IRE network operates on a third party Frame Relay facility 

• The network is presumably contracted for scalability 

QoS - 

• The IRE network is provided by a third party "managed services" facility 

The use of the existing IRE network can significantly benefit the operation of the ITS/CVO Network by 

offloading all CDE type activities that incur large size file transfers among jurisdictions. The ITS/CVO 

Network response time per transaction becomes more predictable and near real-time responses may be 

consistently achievable. 

7.2.4 Advantages and Disadvantages of Option 2 

The advantages and disadvantages of a VPN, without IRE are: 



• Use of public Internet 


• Provinces need only to develop part of the VPN specific to itself 

• Other parts of the VPN common to all provinces 


• Probably less expensive to develop 

• Open architecture, choice of emerging technologies, adaptable to network changes 

• Unrestrictive client services by the network 


• The public Internet is not as secure. There also could be scalability concerns. 

• Need clear demarcation of responsibility for development parties and consensus of web contents 

• Slower deployment for a few provinces. Not fully operational on a national level until all provinces 

deploy. 

58



However, if the option to use IRE in conjunction with a VPN is selected there are additional advantages 

and disadvantages. 



• Use of "private" Internet 

• Very secure and predictably scalable 

• Managed VPN services for guaranteed QoS 

• With fixed size transactions, consistent near real-time network responses possible 


• Province need only to develop part of the VPN specific to itself 

• Other parts of the VPN common to all provinces 


• Probably less expensive to develop 

• Open architecture, choice of emerging technologies, adaptable to network changes 

• Unrestrictive client services by the network 


• Additional costs to operate and maintain the IRE network 

59



8 Costing 

Costing has been broken into three main sections, dealing with the options for data sharing, networking 

options and roadside access. SAIC Canada has drawn extensively upon its own experiences as well as the 

experiences of the US. The SAIC team has identified cost information from CVISN deployments in the 

US. This information was obtained from interviews done as part of the study as well as the report 

completed by Battelle for the US Department of Transportation ITS Joint Program Office entitled 

“Evaluation of Commercial Vehicle Information (CVISN) Systems and Networks Model Deployment 

Initiative”. 1 

In addition, since December of 1994, the United States Department of Transportation's Joint Program 

Office for Intelligent Transportation Systems has been actively collecting information regarding the impact 

of ITS projects on the operation of the surface transportation network. Data collected under this effort is 

available in their ITS Benefits Database. 2 

The costs presented in this section are to be considered for budgetary purposes only and are normally 

considered as being a Rough Order of Magnitude (ROM). The costs are at a very high level and cannot be 

refined until a specific network design is chosen. Excluded from these costs are any outreach activities 

(workshops etc.) that Transport Canada may wish to undertake. 

8.1 Data Sharing Options Cost Elements 

For purposes of this study the following cost elements were identified: 

• Start up (deployment)/Non recurring cost elements for ITS/CVO deployments include the following 

elements: 

o 

o 

o 

o 

Snapshot Server Development. While each option has different developments, in each case 

there is a snapshot server to be developed. In both Options 2 and 3, although there is no 

central server, the server can be developed in such a way as to permit deployment in each 

jurisdiction or region without additional development. 

Server Costs. This would be the cost of purchasing the appropriate server hardware and 

operating software. 

Jurisdictional Costs. These costs would be the costs associated with each jurisdiction 

developing interfaces to its existing/legacy systems. 

Regional Costs. In the case of Option 3, these are the costs associated with regional 

development i.e. each region must make decisions and have them implemented. 

Post Deployment cost elements for CVISN Deployments include: 

o 

Annual Maintenance Costs - Central. This is the cost associated with the maintenance of the 

hardware and software that does not belong to the jurisdiction or region (even if located in the 

jurisdiction). 

1 

2 

A complete copy of this report can be read or downloaded from the following web site location. 

http://www.itsdocs.fhwa.dot.gov/\JPODOCS\REPTS_TE\/13677.html 

This database can be accessed from the following web site location. 

http://www.benefitcost.its.dot.gov/ 

60



o 

Annual Maintenance Costs - Local. These are the costs associated with hardware software 

maintenance of equipment belonging to the jurisdiction. 

For all options there are a combination of a cost incurred centrally, and costs incurred solely in a 

jurisdiction (or a region). 

Many aspects of the Data Sharing options are analogous to the CVISN deployment in the US. The main 

similarity is the implementation of CVIEW systems by states to facilitate sharing of safety information 

within a state and among states. The US Federal Motor Carrier Safety Administration initially developed 

the Safety and Fitness Electronic Records (SAFER) System, which is the US central repository for 

Intrastate Carrier Safety Information and the CVIEW. SAFER was the basis for the refinement and 

development of the CVIEW system. CVIEW has been reengineered for other platforms or modified to 

incorporate specific state requirements by some states most notably Washington State and Kentucky. 

CVIEW is particularly analogous to our Option 2, Decentralised Model. Hence US experience in 

developing/modifying CVIEW provides a good basis for estimating Option 2 costs. 

While Option 1, the Centralised System is architecturally analogous to the US development and 

deployment of the SAFER system, SAFER is a much more complex system than being proposed for Option 

1. Hence SAIC Canada believes US experience in developing/modifying CVIEW also provides a good 

basis for estimating Option 1. 

Data Sharing Option 3 or Regional option currently has no analogous counterpart in the US, but is also 

similar in complexity and concept to CVIEW. Hence CVIEW experience has been used for Option 3 

costing as well. 

The US CVIEW is a software system that provides carrier, vehicle and driver safety and credential 

information to fixed and mobile roadside inspection stations. CVIEW provides an interface to state legacy 

systems and the Federal SAFER system. Upgrade to the Federally funded “core” CVIEW system 

incorporates roadside functions common to electronic screening and Safety Information Exchange. The 

cost for CVIEW development as reported by Kentucky was $325,000.00 US for statewide capability. This 

“start-up cost” permits the software to be installed at multiple sites across a state. Similar costs were 

reported by Washington State for their re-engineering and deployment of CVIEW. Their costs were 

approximately $340,000.00 US. Kentucky also reported estimated $80,000.00 US for annual post 

deployment operating costs consisting of two full time staff members to maintain, troubleshoot and consult 

on software development. This was used as the basis for the annual maintenance costs centrally as well as 

approximately half that amount for the costs in each jurisdiction. 

The costs of the various Data Sharing options are shown in Table 10. The cost of each element is shown as 

well as both a total cost and a Net Present Value (NPV) based on a five-year period. 

61



Table 10 – Data Sharing Cost Elements 

Cost Element Option 1 

($000) 

Option 2 

($000) 

Option 3 

($000) 

Non-Recurring Costs 

Snapshot Server $525 $525 $525 

Development 

Server Costs $25 - $60 see note 4 $25 - $60 see notes 3, 4 $25 - $60 see notes 3, 4 

Jurisdictional Costs $100 See note 2 $100 See note 2 $100 See note 2 

Regional Costs N/A N/A $100 See note 5 

Recurring Costs 

Annual Maintenance $120 $120 $120 

Costs Centrally 

Annual Maintenance $50 $50 $50 

Cost local 

Total Costs 

Total (over 5 years) see $4 665 $6 525 $5 725 

note 6 

NPV (at 8%) see note 6 $3 860.86 $5 353.79 $4 765.91 

Notes: 

1 – All figures are $k and in Canadian dollars. Where converted from US estimates, an exchange rate of 

1.5 has been used. 

2 – As each jurisdiction has different systems and different development policies and procedures, it is not 

possible to provide individual estimates at this time. Cost would be similar to the costs the jurisdiction 

incurred in developing the IRE system. An average cost of $100k has been used. Also although difficult to 

assess at this point in time, it is reasonable to assume that there would be some increased costs in Option 3. 

3 – In the case of option 2 this cost would be per jurisdiction and in the case of option 3 per region. 

4 – The actual configuration of the server may vary significantly depending upon the degree of redundancy 

required and the anticipated traffic. 

5 – While there is a great deal of uncertainty regarding the Regional cost at this point (see comments in 

note 2) they have been estimated to be about the same as a jurisdiction’s cost alone. 

6 – In order to calculate total cost and a net present value (NPV) the following assumptions were made 

• All development and deployment will take place in the first year. 

• Deployment will take place in 12 jurisdictions and, in the case of option 3, four regions. 

• $60k was used as the server cost for options 1 and 3 and $40k was used for option 2. 

• Maintenance costs will start in the second year. In the case of multiple server options (2 and 3) it was 

assumed that each server will require one quarter of the central costs as well as the central costs. This 

would cover the costs of maintaining each server and upgrading each server with changes developed 

centrally. 

• A rate of 8% was used. 

62



• Detailed cost build-up 

Year 1 cost: Option 1 = snapshot server development cost + server cost + 

12x(jurisdictional cost) 

Option 2 = snapshot server development cost + 12x(server cost) + 

12x(jurisdictional cost) 

Option 3 = snapshot server development cost + 4x(server cost) + 

12x(jurisdictional cost) + 4x(regional cost) 

Year2-5 Costs, each year: 

Option 1 = annual maint. cost central + 12x(annual maint. cost local) 

Option 2 = annual maint. cost central + 12(annual maint. cost local) + 

12x(0.25x annual maint. cost central) 

Option 3 = annual maint. cost central + 12x(annual maint. cost local) + 

4x(0.25x annual maint. cost central) 

8.2 Network Options 

The major costs of the network options are in the purchase and integration of hardware. For purposes of 

this study, it is assumed that software costs are primarily associated with the data sharing and hence are 

included there. 

Of the two options discussed the pure IRE option has effectively zero cost, although it may be necessary to 

purchase additional equipment for interconnecting servers (hubs, routers etc.) to the IRE network and 

additional bandwidth from AT&T as time progresses. Also if other agencies wish access to the network 

they will need to be provided with additional gateways. 

The costs of the VPN alternative are very dependant on exactly how the VPN is designed and it is beyond 

the scope of this study to do such a network design. The cost of VPNs varies greatly depending upon the 

exact requirements. However a low-end solution would start with approximately $40k for equipment such 

as low-end VPN Concentrators by CISCO or Ascend/Lucent, at each jurisdiction, for a total cost of $480k 

(assuming 12 jurisdictions are connected). While installation is normally provided free of charge, 

additional costs of approximately 15% could be incurred depending upon the approach chosen for 

installation. A low-end solution would be the most likely choice given the relatively low traffic that would 

be using the VPN. High-end solutions can handle high volumes off traffic and are intended for enterprises 

with large numerous of sites and numerous remote users (i.e. many thousand). Equipment for this number 

of users can start at over $100k. However one of the major advantages of VPN is that the equipment and 

services are usually highly scaleable i.e. they can be made to grow as the need grows, without major 

reconfigurations. Hence a low-end solution provides an ideal starting point. 

In most cases VPNs are used to replace existing leased lines and often result in large savings. Similarly, 

some savings may result if the IRE and CDE systems are replaced by the same VPN. 

8.3 Roadside Communication Costs 

As noted above the US DOT has done extensive analysis of cost for a variety of cost issues associated with 

ITS, including networking equipment and roadside communication costs. As noted in the discussion on 

jurisdictional readiness, many jurisdictions already have extensive communication capability to the 

roadside. It is beyond the scope of this project to provide a detailed analysis of each jurisdiction’s present 

configurations. For those jurisdictions considering installing additional capability to the roadside, Table 11 

is an extract from the US DOT analysis covering roadside communications equipment. All figures are in 

US dollars. 

63



Subsystem/Unit Cost 

Element 

Lifetime 

(years) 

Capital 

Cost ($000) 

Table 11 – Roadside Communications Costs 

O&M Cost 

($000/year) 

Low High Low High 

Roadside Telecommunications (RS-TC) 

DS0 Communication Line 20 0.5 1 0.6 1.2 56Kbps capacity. Leased with typical distance from 

terminus to terminus is 8-15 miles, but most of the cost 

is not distance sensitive. 

DS1 Communication Line 20 0.5 1 4.8 8.4 1.544Mbps capacity (T1 line). Leased with typical 

distance from terminus to terminus is 8-15 miles, but 

most of the cost is not distance sensitive. 

DS3 Communication Line 20 3 5 24 72 44.736 Mbps capacity (T3 line). Leased with typical 

distance from terminus to terminus is 8-15 miles, but 

most of the cost is not distance sensitive. 

ISP Service Fee 0.12 0.18 Monthly service fee ($10 to $15 per month). 

Direct Bury Armour Encased 

60 0.02 Cost is per mile. 

Fibre Cable 

Conduit Design and 

65 0.02 Cost is per mile. 

Installation – Corridor 

Twisted Pair Installation 12 0.02 Cost is per mile. 

Fibre Optic Cable Installation 20 0.02 Cost is per mile. 

Telephone Drop 1 3 0.2 0.3 Cost is per drop. 

Cellular Communication 0.5 0.3 0.4 Cost is for one unit. 

900 MHz Spread Spectrum 

9 0.15 0.4 Cost is per link. 

Radio 

Microwave Communication 15 0.3 0.7 Cost is per link. 

Wireless Communications, 

0.18 0.2 125 Kbytes/month available usage. 

Low Usage 

Wireless Communications, 

0.6 0.7 1,000 Kbytes/month available usage. 

Medium Usage 

Wireless Communications, High Usage 

20 0.5 1 1.2 1.8 3,000 Kbytes/month available usage. 

Call Box 10 5.9 0.714 Capital cost includes call box and installation. O&M is 

cost per unit (per year) for service maintenance contract 

and annual cellular service fee. 

Notes



9 Recommendations and Considerations 

The preceding sections have identified various options for data sharing and for networking of a CVO/ITS 

network. These can be summarised as follows: 

Option 

Data Sharing 

Option 1 

Option 2 

Option 3 

Networking 

Option 1 

Option 2 

Table 12 – Summary of Options 

Description 

Centralised model. A single, central point for 

generating snapshots. 

Decentralised model, with the alternative of 

embedding the CVIEW application in a 

jurisdiction's legacy system. Snapshot generated 

in each jurisdiction and distributed around the 

network. 

Regional model. A snapshot generation system in 

each region. 

IRE/CDE based. 

VPN with the alternative to use IRE for some 

functions. 

The above options were analysed and studied from the perspective of how well they meet the requirements 

as laid out in this report as well as several additional factors. 

This section first presents the final recommendation of that analysis followed by a discussion of how that 

recommendation was arrived at. 

9.1 Recommendation 

SAIC Canada recommends that Transport Canada adopt a centralised model for the data-sharing 

network and an IRE based communications network, moving towards a network consisting of a 

VPN and IRE based transactions. 

This should be considered only a preliminary recommendation until such time as formal proposals have 

been reviewed by the various stakeholders and funding issues resolved. It is further recommended that 

Transport Canada enter into negotiations with the CCMTA with a view to having them take responsibility 

for all aspects of the system including development, maintenance and inter-provincial agreements. 

The following sections expand on the rational for these recommendations. 

9.2 Factors Considered 

Generally speaking all the options satisfy the requirements established by the team. It was therefore 

necessary to consider other factors in making a determination of the best option. One factor the team 

discussed, but decided to leave out of the decision making process was the issues of funding mechanisms. 

While some options lend themselves well to centralised funding, all options require the various 

jurisdictions to do development, in some cases as small as creating an interface to some new IRE 

transactions. Until a determination has been made of how the project can be funded it was decided to leave 

this factor out. 

65



The factors considered were: 

• Status / Currency of exiting infrastructure. To what extent are the jurisdictions ready for a CVO 

network? 

• Degree of COTS/GOTS integration vs. Custom development. The extent to which custom 

development would be needed versus reusing software. 

• Ease of interface with legacy systems and US systems. 

• Ability of current networks to support CVO functions and how well the options blend with those 

existing networks. 

• Operations and Maintenance considerations. 

• Implementation complexity. This has a direct impact on cost. 

• Implementation time frame. 

• Implementation resources. This has a direct impact on cost. 

• Cost of implementation. 

9.3 Rationale 

9.3.1 Rationale for Data Sharing Recommendation 

The following table (Table 13) compares the various options using the factors described above. 

Based on the above the major difference in the options becomes one of cost. The proposed solution is the 

cheapest. Additionally the centralised option was recommended by several of the interviewees in the US. 

As well this option is similar conceptually to the existing IRE and CDE networks. 

66



Table 13 – Comparison of Options 

Factor Option 1 Option 2 Option 3 

Status / Currency of existing 

infrastructure. 

Degree of COTS/GOTS 

integration vs. Custom 

development. The extent to which 

custom development would be 

needed versus reusing software. 

Ease of interface with legacy 

systems and US systems. 

Ability of current networks to 

support CVO functions 

Operations and Maintenance 

considerations. 

This option works best when all the 

jurisdictions are at a similar level 

of sophistication and readiness. 

Could reuse SAFER software, 

although CVIEW may be the better 

choice. 

Somewhat complicated interface to 

legacy systems, but easier access to 

US systems. 

Works well with current IRE and 

CDE although central concept is 

not well supported in IRE concept, 

however CDE is a central concept 

as well. 

Requires central resources and 

resources in each jurisdiction, 

although based on the IRE 

experience there should be minimal 

software maintenance. 

Given the wide range of 

jurisdictional readiness, this option 

provides the most flexibility. 

Jurisdictions are primarily limited 

to developing interfaces to existing 

All jurisdictions in a region would 

have to be at similar states of 

readiness 

legacy systems. 

Could reuse CVIEW software Could reuse CVIEW software 

Easy access to legacy systems, but 

access to US systems will need to 

be centralised. 

Works well with current IRE and 

CDE 





software maintenance. This option 

does have a slighter higher 

hardware maintenance cost due to 

the increase number of servers, but 

this cost is relatively low. 

Implementation complexity. Medium Medium High 

Implementation time frame. Medium Medium Medium 

Somewhat complicated interface to 

legacy systems. Access to US 

systems somewhat more 

complicated. 

Regional concept is new to IRE. 





software maintenance. This option 

also requires regional resources.



Factor Option 1 Option 2 Option 3 

Implementation resources. Central with some in each 

jurisdiction 

Cost of implementation. Medium. This option has similar 

costs to option 2 

Cost of Deployment Low. This system requires only a 

central server, albeit a large 

redundant one. 

Central with some in each 

jurisdiction 

Medium. This option has similar 

costs to option 1. 

High. Requires a server in each 

jurisdiction. 

In addition to central resources and 

some in each jurisdiction, this 

option requires some regional 

resources – at least some resource 

representing the region. 

High. This option has the higher 

cost due to the increased 

complexity of the regional concept. 

Medium. Requires a server in each 

region. 

Support Costs Low High. 12 servers need support Medium. Four servers need 

support 

NPV over Five Years Low High Medium



9.3.2 Compatibility with the Canadian ITS Architecture 

This section discusses the extent to which the chosen solution is compatible with the Canadian ITS 

Architecture. Since the ITS architecture covers both a Physical and a Logical Architecture, the 

compatibility discussion covers both areas. 

While the proposed solution is consistent with the architecture many of the functions and processes in the 

architecture were not part of the Terms of Reference for the study. In many cases the authors of the 

architecture have included functions and process that are therefore not covered by the solution. 

9.3.2.1 Physical Architecture 

The Physical Architecture is represented by the “sausage” diagram from the Canadian ITS Architecture 

(see Figure 11). The Commercial Vehicle Administration Sub-System and the Commercial Vehicle Check 

Sub-System cover most of the proposed CVO network. 

These two sub-systems are conceptually the same as the CSAFER and the ECRI system. While many of 

the functions provided by these two sub-systems in the ITS Architecture are not presently planned in either 

CSAFER or the ECRI system they are not excluded. 

9.3.2.2 Logical Architecture 

The Logical Architecture consists of numerous processes. The proposed solution covers some of the 

processes in 2.3 - Manage Commercial Vehicles. Specifically the CSAFER system supports processes in 

2.3.3 – Provide Roadside Commercial Vehicle Safety including 2.3.3.3 Administer Commercial Vehicle 

Roadside Safety Database. The ECRI system supports the remaining processes in 2.3.3 including 2.3.3.1 

Provide Commercial Vehicle Checkstation Communications (CVCS), 2.3.3.2 Provide Commercial Vehicle 

Inspector Handheld Terminal Interface (CVCS), 2.3.3.4 Carry-out Commercial Vehicle Roadside Safety 

Screening (CVCS) and 2.3.3.5 Carry-out Commercial Vehicle Roadside Inspection (CVCS) 

Both systems have the capability to support other functions in 2.3 including those associated with 

credentialing 

69



Figure 11 – Canadian ITS Architecure 

9.3.3 Rationale for Network Option Recommendation 

Most of the above factors for consideration apply to the data networking options. The recommendation for 

networking is the VPN option, but starting out with using IRE for the initial implementation. Some of the 

reasons for choosing this approach are: 

• Allows for a quick start using proven technology. 

• A pure IRE based approach does not lend itself well to emerging technologies such as XML and to 

more extensive use of the Internet. 

• The networking aspect of the system can be implemented with little more than the creation of new IRE 

transactions, reformatting of messages and tagging of data for browser access. This is a technique that 

is familiar to the various jurisdictions although they will be extracting data from systems not current 

served by IRE or CDE. 

• In conjunction with the chosen data sharing option, the combined system has many similarities to the 

existing IRE applications i.e. a front-end system similar to the IRE Gateway, interfacing with legacy 

systems for the formatting of data. 

• Moving to a VPN will allow for increased use of the Internet and web based tools, while still retaining 

the security required. 

70



10 Considerations/The Way Ahead 

Before proceeding with the CVO/ITS network there are several considerations that should be taken into 

account. It is recommended that these be put into place before proceeding. 

• To get a buy-in for the concept it will be necessary to run a variety of workshops and information 

sessions to develop a consensus on institutional and technical issues that will need to be resolved for 

the program to meet its objectives. This will also help bring together all of the stakeholders who will 

need to be involved in the development of the CVO/ITS network at the federal, provincial, and 

territorial levels as well as industry. US experience with the Mainstreaming Program and the followon 

ITS/CVO Training Courses and CVISN Project Planning Workshops has shown that this improves 

the situation dramatically. Stakeholders include operations (enforcement) and IT staff in the 

jurisdictions, program managers in the jurisdictions, CCMTA and CCMTA secretariat. 

• Funding approaches. Transport Canada needs to look at its funding mechanisms. Funding needs to be 

available to develop the common CVIEW system and for the jurisdictions to develop legacy interfaces. 

Additional funding needs to be available to the CCMTA secretariat to update the IRE gateways and to 

provide additional bandwidth on the network if this is necessary. 

• Transport Canada and jurisdictions need to share the commitment to move to a VPN implementation 

within a reasonable time frame and with suitable funding in place. 

• Development of a common Carrier Snapshot, CTI data elements etc. The elements presented in this 

report need to be agreed to or modified. 

• Potential Need for new IRE transactions. 

• Development of a concept of operations and methodology for CTI. 

• A decision needs to be made on funding mechanisms. 

• A decision needs to be made on who will “own” the system. It is felt by the SAIC Canada team that 

the logical owners would be the CCMTA. They already have the mechanisms in place to reach 

agreements with all the relevant jurisdictions. If Transport Canada were to attempt to develop the 

system, they would need to duplicate all of those mechanisms. 

• A standardised safety rating or safety rating criteria is needed to help ensure consistency in 

enforcement actions. This will enable jurisdictions to compare similar information when reviewing a 

carrier’s safety records. The SAIC Canada team is aware that this is an open issue, subject to 

discussion at CCMTA committee meetings, but its resolution is critical. 

• A unique, standard identifier is needed for each motor carrier to enable all jurisdictions to use a single 

identifier to access safety information. It is not clear if the NSC number can meet this requirement. 

While it is possible that the NSC can be used in the system, the wide range of formats will increase 

complexity and potentially lead to confusion and errors. 

• A major concern of the jurisdictions and the motor carrier industry is data privacy; that is, who has 

access to data, how will be data used, and how will it be data protected. An agreement governing data 

use and access is something that would address these concerns. A reference for this might be the ITS 

America guiding principles developed for the US CVISN program. 

71



• CDE has been capturing inspections in a simple database. If access to this database were made 

available on the network .it can then be queried either by inspectors or customs staff. This will require 

new IRE transactions and software on the CDE server. This capability is required in order to provide 

the 45 day inspection database describe in the Tri-Global Solutions parallel project. 

• Related to the above, all jurisdictions should be encouraged send all inspections to CDE (i.e. all of 

their own). It will be necessary to decide what to do about older inspections, presently resident on 

jurisdictional legacy systems 

• All jurisdictions should increase the frequency of sending data through CDE to at least daily. 

• The transportation of Hazardous Materials is an important consideration for commercial vehicles 

operations. While no specific recommendations are possible at this time, the possibility of linking the 

transponder to several existing databases provides an excellent opportunity to improve the tracking and 

safety of these shipments. Further study with agencies involved in HazMat to investigate further the 

ways they can help Transport Canada and vice versa (see section 3.4). 

• Further investigation is needed with CCRA. SAIC Canada was not able to talk directly with any 

CCRA representatives although the experiences of the team and US experiences have been reflected in 

this report. While there are many Canada/US border initiatives, the opportunity to link CCRA with 

information regarding inspections and Current Trip Information as well as HazMat must be 

investigated in more detail. 

72



11 Conclusion 

The purpose of the study as laid out in the Terms of Reference was to: 










The results of the study, relative to the above scope, have been documented in this report and are as 

follows: 

1. A CVO network is feasible for Canada. SAIC Canada reached this conclusion after an extensive 

literature review, interviews with staff in many Canadian jurisdictions, interviews with US ITS experts 

and administrators involved with CVISN and with the CCMTA secretariat. 

2. While there are many lessons to be learnt from the US CVISN system, CVISN itself has limited 

applicability to Canada due to the different regulatory framework, the volume of traffic and the 

geography. One important consideration that SAIC Canada took into account was the recommendation 

from several sources that Canada adopt a centralised system. However not all lessons were technical. 

SAIC found that that institutional issues often create major barriers and hurdles to successful 

deployment and that Canada may wish to consider establishing a program similar to the US 

Mainstreaming Program as a means to facilitate the jurisdictions into a common forum. 

3. There is a broad range of readiness across Canada for a data-sharing network. Many jurisdictions are 

highly automated, while others still use many manual processes. A network can be implemented, but 

will not be fully effective until all jurisdictions reach the same level of automation. Specifically until 

inspection are entered directly into a jurisdiction’s databases and inspection data is available in near – 

real time, the system will only be able to provide good information for vehicles from certain 


4. The technical requirements for sharing snapshots are relatively few, but do include many security 

requirements both to ensure the integrity of the data and functionally dealing with the security regime 

at border crossings. However there are several non-technical requirements that need to be addressed. 

These include standardising the safety rating and developing a common identifier for carriers. In 

addition the question of “ownership” of the network needs to be resolved. SAIC Canada recommends 

the CCMTA take ownership of the network and associated systems as they have all the necessary 

mechanisms already in place. 

5. There are many options for the sharing of CVO data and for the network to support it. SAIC Canada 

recommends a centralised system initially using the existing IRE network. This option has the 

advantage of being the cheapest, while building upon the existing IRE network’s capability and the 

knowledge base in the jurisdictions. This should result in the quickest implementation for the initial 

73



sharing of snapshot data. The cost to develop this system is approximately $1.8M, including costs for 

jurisdictions to update their legacy system appropriately. 

SAIC Canada recommends that Transport Canada proceed with the development of a data-sharing network 

that will support Electronic Clearance and Roadside Inspections. Such a network can be put in place 

building upon US experiences while creating a solution that uniquely addresses Canadian requirements. 

Transport Canada can also draw upon work already done in Canada in the creation of the IRE and CDE 

systems, while moving to add new capability using a Virtual Private Network. 

74



Questionnaires 

A 

Appendix A – Questionnaires 

Attached are questionnaires that were used for interviews both in Canada and in the US. In all cases the 

questions were intended to open up discussions. This was particularly so in the US, where few specific 

questions were asked. Canadian jurisdictions were asked more focused questions to solicit information 

about their specific operations and about their IT systems. 

A.1 Canadian Jurisdictions 

Thank you for agreeing to take the time to talk with us and answer the questions attached. These questions 

are intended to provide information to our team to help us complete a feasibility study on the use of 

Intelligent Transportation System for a Commercial Vehicle Operation network. 

For our purpose, Commercial Vehicle Operation (CVO) encompasses vehicle registration, fuel tax 

payment, insurance policy, carrier permits for inter-provincial, intra-provincial and inter-state operations, 

carrier permits for dangerous goods transportation, special permits for oversize and overweight goods, 

safety and inspection records, drivers and carrier operating status. 

Your input to this process is extremely valuable as part of our assessment of the current situation and to 

gain a better understanding of the issues affecting your aspect of the work. We have included all questions 

here so that you may have an insight into the types of information we are gathering as a whole. 

Field Operation Enforcement staff is asked to answer Section 1 of the questionnaire. 

Central Office Data Entry staff is asked to answer Section 2 of the questionnaire. 

IT System Operation and Support staff is asked to answer Section 3 of the questionnaire. 

CVO Program Managers are asked to answer Section 4 of the questionnaire. 

Please be prepared to answer the questions as fully and as honestly as you can, as only this way can we 

properly assess the feasibility and what needs to be done. Depending upon the answers received, the 

interviewer may ask additional clarifying questions. 

A-1




Section 1 

Enforcement Personnel – Mobile and Fixed Sites 

1. How do you presently select vehicles for inspection? 

2. What information are you now able to obtain about a vehicle pulled in for inspection? 

a. Company? 

b. Vehicle? 

c. Driver? 

3. How do you obtain this information at present? 

4. How long does it take to obtain this information? 

5. Have you ever had a situation occur where you were not able to obtain the information you needed? 

6. How current is the information you are able to obtain? 

a. Carrier’s safety history? 

b. Results of recent inspections? 

c. Driver history? 

7. How accurate is the information you are able to receive at present? 

8. If you put a vehicle out-of-service, do you have any way to let other jurisdictions know about this? 

9. Do you have any way of checking whether or not a vehicle has been put out of service or received a 

citation during the current trip? 

10. When a vehicle is inspected, how do you record the results? 

a. Paper form? 

b. Computer? 

11. How often do you submit the results of inspections to your headquarters so that the information can be 

entered into the central database? 

12. How is this submission done? 

a. Fax? 

b. Hand delivery? 

c. Electronically? 

13. Are you familiar with the concept of carrier snapshots? 

14. Of all the information shown in the snapshot, which is most useful to you in doing your job and why? 

15. What additional information do you think is needed? 

A-2




Section 2 

Data Entry – Central Office 

1. How many inspections reports do you receive a month? 

2. How long does it take to enter these? 

a. Average time per report? 

b. Average number entered per week? 

3. How is data entry done? 

4. Who does data entry, and how many people are needed? 

5. How big is your backlog, and what would it take to eliminate the backlog? 

6. What is the error rate in data entry? 

7. What are the causes of data entry errors? 

a. Difficulty in reading handwriting? 

b. Data entry errors? 

8. What is the process for correcting incorrect data? 

a. Carrier request? 

b. Specific form(s) that need to be completed? 

A-3




Section 3 

IT Personnel - Backend Operation, System Support 

1. Are there different applications for supporting CVO? What are they? 

2. Are there different computer systems supporting different CVO applications? 

3. When a query is made from a user, how is the response returned? Real-time or batch? 

4. Can users access the CVO computer system on-line and if so are there many different ways for a user 

to get connected to the system? For example, telephone line, leased line, wireless, and cellular. 

5. Is the database for CVO centralised or distributed? 

6. If the database is distributed, how are records updated, synchronised and replicated? 

7. What are the hardware and software platforms for the CVO computer system? 

8. Are the CVO applications platform specific? 

9. Are entries of CVO data performed on-line or batch? 

10. Are front-end processors, communication and transaction, used in the CVO computer system? 

11. Are CVO records archived and if so, how? 

12. What system now serves as the authoritative source for CVO information? 

13. How is data retrieved from this system? 

14. How current is the information in this system? 

15. Is EDI currently being used in any applications? 

16. Can you see any impediments that would prevent using XML in CVO applications? 

17. Do you think XML would provide any advantages in CVO applications? 

18. Are these systems accessed by anybody else? 

A-4




Section 4 

Enforcement Personnel – Program Managers 

1. Do you believe that your personnel at fixed and mobile facilities are able to obtain adequate and 

accurate information about motor carriers? (explain) 

2. What additional information do you believe these personnel need to better do their jobs? (explain) 

3. What do you think are the main problems with providing these personnel the information they need? 

(explain) 

a. Accessing information? 

b. Providing quality/timely information? 

c. Communications? 

4. To what extent are your processes automated? 

a. Use of computers to record inspections? 

b. Automated downloading of inspection information? 

c. Wireless communications capabilities? 

d. Automated database to store inspection report data? 

5. What percentage of your annual budget is committed to compiling and entering inspection report data? 

6. How many staff do you need to enter inspection reports or other CVO data? 

7. How accessible is the data, and how do you access the data? 

a. Computer queries? 

b. Reports? 

c. File searches? 

8. Are you familiar with the concept of snapshots? 

9. What information do you think is the most important? 

10. What information do you think will be the most difficult to obtain? 

11. What type of communications capabilities would you like your personnel at mobile and fixed facilities 

to have access to? 

a. Wireless? 

12. Which of the following do you think is most important? 

a. Accuracy of information provided to field personnel? 

b. Real-time exchange of information? 

i. Real-time communications? 

ii. Real-time data v. historical data? 

c. Ability to exchange data between jurisdictions 

i. Historical information? 

ii. Current information such as out-of-service? 

d. Ability to download information directly from the field? 

i. Inspection reports? 

ii. Out-of-service and other enforcement actions? 

13. Do you have any concerns about exchanging data with another jurisdiction? (explain) 

a. Information about another jurisdiction’s carriers? 

b. Information about your jurisdiction’s carriers? 

A-5




14. What safeguards do you believe are needed to ensure the proper use of data exchanged with another 

jurisdiction? 

a. Signed agreements? 

b. Guiding principles? 

15. Are there any legal or policy prohibitions on sharing information? 

16. What do you believe are the biggest problems you face with automating your processes? 

a. Budget? 

i. Capital? 

ii. Operating/Maintenance? 

b. Technical personnel? 

c. Procurement of hardware? 

17. What conditions or criteria do you believe that a carrier must meet in order to receive a green light? 

18. Are you familiar with by-pass criteria employed with existing screening programs? 

19. Do these criteria seem adequate to you? (explain) 

20. Has your jurisdiction considered electronic screening by-pass criteria? 

21. Under what circumstances will a carrier be permitted to by-pass an inspection station? 

22. Will carriers need to pre-enrol in a program or will a jurisdiction allow a carrier to install a transponder 

and participate (Maryland model – carriers will be told of any condition/issue that may impact receipt 

of a green light, but no enrolment conditions are placed on the carrier)? 

23. How many inspection stations, both fixed and mobile do you have – can we obtain a map that shows 

where they are located? 

24. How many inspections are done annually? 

25. Do you have the ability at present to share information between inspection facilities on an intraprovincial 

basis? If so, how is this done? What information is shared? 

26. How are US vehicles treated. 

A-6




A.2 US Questions 

Interview Questions/Topics for the Canadian CVO Network IT Feasibility Study – American 

Association of Motor Vehicle Administrators (AAMVA). 

1. What is AAMVA’s role current role if any with regard to CVISN? 

2. Is AAMVAnet anticipated to remain a method of connectivity to SAFER from the states? 

3. Describe what if any connectivity to US systems using AAMVAnet that the Canadian provinces 

currently use. 

4. Can you describe the high level architecture of AAMVAnet? Protocol’s etc? 

5. Does AAMVAnet provide VAN services i.e. format conversion etc? 

6. What if any are the future plans for AAMVAnet? 

7. Do the Canadian provinces participate in CDLIS? 

8. What are the strengths of CDLIS with regarding to Drivers and Safety enforcement? 

9. Can CDLIS be accessed via wireless communications? 

10. Does CDLIS share information with NCIC or NLETS? 

11. In AAMVA’s view, what has worked well with CVISN implementation and what has not? 

12. What is AAMVA’s view regarding implementation of a “driver” snapshot in SAFER? What are the 

barriers to its implementation? 

13. With regard to Safety Information Exchange for Motor Carrier information what if any advice or 

Lessons learned would AAMVA provide Canada? 

14. Does AAMVA engage in any dialog with Canada regarding motor carrier and safety? 

A-7




CVISN Pilot States (Washington, Kentucky, Minnesota) 

• XML vs. EDI implementation for message sets 

• Regional Vs state based implementation of CVIEW data exchange/sharing 

• Role of SAFER and MCMIS as "authoritative sources" of data 

• Modes of access to SAFER --- dial up Vs. internet Vs. VAN 

• Status of ASPEN as a PC Roadside Inspection capture system 

• Status of Roadside access systems to CVIEW and or SAFER for enforcement and or electronic 

clearance purposes. 

• views on necessary communications infrastructure to support data exchange. 

• degree of customisation done to the JHUAPL Version of CVIEW 

• what drove the changes, what Level of effort resource wise is necessary to maintain. 

• technically what would you have done differently 

• what would you keep the same 

• How are you implementing the interface to the roadside. 

• what training was required for enforcement and systems personnel 

• Lessons learned that they may want to share in terms of data sharing and exchange for Canadian 

Provinces. 

• Views on long-term operation and maintenance of implemented systems. 

A Particular component of the study will be to analyse in detail the carrier snapshots that are currently 

being developed for the US CVISN program. This analysis will focus on: 

• what data is included in the snapshot, how is this data compiled, what is the authoritative source for 

this data; 

• how were the data elements contained in the snapshot identified, prioritised, and accepted as the key 

elements; 

• were or are there any data elements that are not included, and if so, why; 

• is there concern within or between industry and government about what data should or should not be 

included in the snapshot (i.e., driver information); 

• what are the key carrier identifiers being used, and how were these accepted as the standard identifiers 

(for example, US DOT number or other specific carrier identifiers). 

A-8




Topic Areas for Discussion with FMCSA 

CVISN 

• TOPIC 1 – What does FMCSA Envision for CVISN Level 2? 

• TOPIC 2 – With 20/20 Hindsight, what would FMCSA have done differently regarding the CVISN 

architecture? What concepts worked and what concepts did not? 

• TOPIC 3 – Would the US/FMCSA be agreeable to providing SAFER or CVIEW code to Canada as a 

baseline to implementation of an ITS/CVO Data Exchange/Sharing network for Canada? 

• TOPIC 4 – What is FMCSA’s views CVISN implementations by states. 

• TOPIC 5 – General Discussion on Roadside clearance and Security. 

Border Crossings 

• Since Sept. 11, 20002 - what steps is the US, specifically FMCSA taking to ensure the free movement 

of Motor Carrier Traffic between the US and Canada? 

• What have been the success stories regarding pilot programs for expedited border crossing for Motor 

Carriers? What technologies and or procedures benefit expedited border crossing? 

• What steps would FMCSA like to see Canada adopt with regard to Motor Carrier data sharing and 

exchange? 

• What if any new security steps does FMCSA see necessary for Canadian Motor Carriers to operate in 

the US? 

• What would FMCSA like to see from Canada with respect to US motor carriers operating in Canada? 

• What initiatives if any is FMCSA taking with US customs and INS with regard to Motor carrier Border 

Crossing? 

• What types of information does FMCSA need from Canadian Motor Carriers entering the US? What 

information would be needed to facilitate electronic screening and clearance of motor vehicles at 

border crossings? 

A-9




Topic Areas for Commercial Vehicle Safety Alliance Discussion 

• Border and International 

• Driver Snapshots and Information Systems 

• Data Exchange 

• Communications Infrastructure 

• Electronic Screening 

• Lessons Learned 

Topic Areas for discussion with CVISN Prototype State - Maryland 

• General Discussion 

• XML vs. EDI 

• CVIEW 

• Security Issues 

• Other Points 

JHU-APL questions 

A particular component of this task will be to analyse in detail the carrier snapshots that are currently being 

developed for the US CVISN program. This analysis will focus on: 

• what data is included in the snapshot, how is this data compiled, what is the authoritative source for 

this data; 

• how were the data elements contained in the snapshot identified, prioritised, and accepted as the key 

elements; 

• were or are there any data elements that are not included, and if so, why; 

• is there concern within or between industry and government about what data should or should not be 

included in the snapshot (i.e., driver information); 

• what are the key carrier identifiers being used, and how were these accepted as the standard identifiers 

(for example, US DOT number or other specific carrier identifiers). 

A-10



Interviewee List 

B 

Appendix B – Interviewee List 

B.1 Canadian Jurisdictions 

Table 14 – Canadian Interviewees 

Jurisdiction Name of Interviewee Responsibilities 

Nova Scotia Department of Don Evans 

Enforcement Operation 

Transportation and Public 

Works 

Dave Munroe 

Enforcement Administration 

Carla Laybolt 

Vehicle Compliance 

Wayne Richard 

IT Operation 

Societe de l'assurance 

Alain Leblanc 

Carrier Enforcement, Operations 

automobile du Quebec (SAAQ) 

Claude Corbeil 

Vice President Highway Safety 

Hélène Brunelle 

System and Data 

Lisa Allard 

Vehicle Inspection 

Marcel Hamel 

Director, Highway Control 

Ministry of Transportation of 

Ontario 

Phil Cooke 

Manager, Carrier Enforcement 

Program Office (CEPO), Carrier 

Safety & Enforcement Branch 

Paul Groeneveld 

Head, Enforcement Program 

Evaluation, CEPO 

Paul Brown 

Regional Enforcement Coordinator, 

Central Region 

Wayne Gott 

Technical Support, CEPO 

Robert Monster 

Vehicle Standards Engineer, 

CEPO 

Chris Mustachi 

Carrier & Information Solutions 

Manager, Application 

Development & Delivery Office, 

RUS Applications Branch 

Dennis Yee 

Business Analyst, Information 

Technology Branch 

Manitoba Transportation and 

Government Services 

Saskatchewan Highways and 

Transportation 

Henry Wong 

Dwight Solon 

Doug Howie 

Paul Iwkowo 

Piper Werbrowski 

Rennie Alina 

Randy Prokopchuk 

John Meed 

Brian Lanktree 

Dave Fowler 

Senior ITS Engineer, ITS Office 

Manager, Compliance Services 

CVSA Training and 


Data Base Operation, CVO 

Manager, Compliance Services 

Data Entry - Offence Notices 

Regional Manager, Highway 

Transportation Patrol, Easter 

Region 

Manager, CVSA Program 

Support Analyst, Service 

Delivery Section 

System Analyst, Service 

Delivery Section 

B-1





Saskatchewan Government 

Insurance Corporation (SGI) 

Kwei Quaye 

Manager, Traffic Safety 

Program Evaluation 

Jarbis Pelletier 

IT Projects and Systems Support 

Alberta Transportation and 

Utilities 

Wayne Lilley 

Manager, NCS/OA, Carrier 

Services 

Kim Durdle 

Director, Carrier Services 

Lana Kennedy 

NCS/OA Specialist, Carrier 

Services 

Jacquie Peterson 

Compliance Co-ordinator/ 

Accreditation Manager, 

Inspection Services 

EDS Linda Tarnowski Applications Specialist 

Ken Monk 

Systems and Network Specialist 


Perry Therrien 

Cameron Jackson 

B-2




B.2 US Contacts 

Table 15 – US Contacts 


Washington State DOT Bill Goforth CVISN Systems Architect 

FMCSA Jeff Secrist CVISN Deployment Program 

Manager 

KY Transportation Cabinet Jim Ramsey Director of Information Systems, 

CVISN System Architect 

Minnesota DOT Chris Conway CVISN Systems Architect 

Johns Hopkins University Paul North 

SAFER Program Manager 

Applied Physics Laboratory 

MD Motor Vehicle 


Debbie Rodgers 

Vehicle Services Manager, 

CVISN Technical Manager 

Johns Hopkins University DJ Waddell 

CVISN System Architect 

Applied Physics Laboratory 

Commercial Vehicle Safety Stephen Keppler 

Director of Policy and Programs 

Alliance 

FMCSA Milt Schmidt International Border Crossing 

Expert 

American Association of Motor Jay Maxwell 

Head of AAMVANet 

Vehicle Administrators 

Michigan DOT Kunwar Rajendra Michigan/Ontario Border 

Crossings 

New York State DOT Gerry Cioffi New York/Ontario Border 

Crossings 

B-3




C 

Appendix C – Requirements 

The following tables provide the requirements developed during task 1 of the study. 

Each requirement has been uniquely numbered using a prefix to indicate the type of requirement. 

• T – Technical 

• F – Functional 

• A - Administrative 

C-1

Table 16 – Requirements 

No. Category Sub-Category Description Source Comment 

F001 Functional General The system shall create and 

store current snapshots of interprovincial 

carriers and make 

them available to other 


F002 Functional General The system shall create 

snapshots from carrier profile 

data held by each jurisdiction. 

Interviews with Jurisdictions The system will have the capability to access a 

jurisdiction’s legacy system to compile and store 

snapshot information on inter-provincial carriers. 

The system shall also make these available to 

other jurisdictions. Snapshots refer to Carrier 

Snapshots. 

Interviews with Jurisdictions Each jurisdiction’s data will remain the 

authoritative source for carrier data. This 

requirement ensures that snapshot data is 

collected from existing authoritative sources. 

This also ensures that additional data sources do 

not need to be developed to support the system. 

F003 Functional General The system shall allow 

jurisdictions to create and store 

snapshots for its own intraprovincial 

carriers on an 

optional basis. 

F004 Functional General The system shall make intraprovincial 

snapshots available 

on an inter-provincial basis. 

Interviews with Jurisdictions Many jurisdictions have the capability to create 

intra-jurisdictional carrier profiles (an example is 

the Manitoba Carrier Snapshot C-Snap). To 

avoid duplication, the system shall provide 

jurisdictions with the capability to create these 

intra-jurisdiction profiles as well as interjurisdictional 

profiles. This additional capability 

would be implemented at the discretion of a 

jurisdiction. 

Interviews with Jurisdictions, 

FMCSA CVISN program 

guidelines. 

In the event that an intra-jurisdictional carrier is 

determined to be operating on an interjurisdictional 

basis, enforcement personnel will 

be able to access snapshot information on that 

carrier’s safety record.


F005 Functional General The system shall create interand 

intra-provincial snapshots 

in the same format. 

Literature review – JHU-APL 

CVISN documentation 

Establishing a common format for inter- and 

intra- jurisdictional snapshot avoids duplication 

of development efforts and is more costeffective. 

This also ensures that information 

provided on each type of carrier operation use 

common data formats, thus ensuring consistency 

in data analysis and interpretation. 

F006 Functional General The system shall make 

available current trip 

information (CTI) on 

commercial vehicles 

enforcement actions. Current 

trip information will be made 

available for at least seven 

days. 

Interviews with Jurisdictions This requirement ensures that information on 

any enforcement actions against a carrier during 

a current trip (for example, results of an 

inspection) is available for at least seven days. 

The intent of this is to ensure that adequate time 

is provided for the entry of this data into a 

jurisdiction’s legacy systems. 

F007 Functional General The system shall have the 

ability to exchange snapshots 

and current trip information 

with the United States. 

Transport Canada, CCMTA, 

CVSA, FMCSA 

This addresses the requirement that the system 

be able to exchange information with the United 

States. 

F008 Functional Accessibility The system shall make 

snapshot and CTI information 

available to fixed and mobile 

enforcement. 

F009 Functional Accessibility The system shall make 

snapshot and CTI information 

available to other government 

entities and third party users. 

Transport Canada These requirements address the information 

exchange and data sharing requirements 

specified in the RFP. 

Transport Canada These requirements address the information 

exchange and data sharing requirements 

specified in the RFP.


T001 Technical Security The system shall make 

snapshots available to 

authorities responsible for 

border crossing. 

T002 Technical Security The system shall provide access 

to Dangerous Goods/Hazardous 

Materials (HazMat) 

information. 

T003 Technical Security The system shall be designed to 

permit access to carrier 

information with jurisdictions 

and individuals who are 

authorised access to the 


Transport Canada Amendment 4 to the RFP required that the 

system functionality be expanded to address 

security requirements. The principle securityrelated 

requirement identified during the course 

of Task 1 was to ensure that border crossing 

agencies were able to access carrier snapshot 

information. The snapshot proposed for Canada 

also includes information on Dangerous Goods 

and Hazardous Materials. Access to this 

information will enable border crossing agencies 

to identify particular carrier types and/or loads 

that if compromised would cause a security 

threat. 

Transport Canada Amendment 4 to the RFP required that the 

system functionality be expanded to address 

security requirements. The principle securityrelated 

requirement identified during the course 

of Task 1 was to ensure that border crossing 

agencies were able to access carrier snapshot 

information. The snapshot proposed for Canada 

also includes information on Dangerous Goods 

and Hazardous Materials. Access to this 

information will enable border crossing agencies 

to identify particular carrier types and/or loads 

that if compromised would cause a security 

threat. 

Transport Canada This requirement addresses the need to protect 

sensitive information and to limit its 

dissemination to only authorised jurisdictions 

and individuals.


T004 Technical Security The system shall employ 

security techniques to protect 

information from surreptitious 

manipulation (hacking), 

unauthorised access, intrusion 

(virus protection) and 

intentional corruption. 

Interviews with Jurisdictions This requirement addresses the need to ensure 

that system security is implemented to prevent 

deliberate attempts to corrupt system 



permit additional interfaces to 

Canadian customs and or 

immigration systems for the 

purpose of expediting border 

crossing of commercial 

vehicles between Canada and 

the United States. 

Transport Canada These requirements address the need for driver, 

vehicle and carrier information at the Canada / 

US border to permit National Security (Canada 

and the US) concerns to be addressed as well as 

to expedite movement of commercial vehicles 

and cargo between the nations. The system may 

provide information needed by the International 

Border Clearance Program (IBC) and other ITS 

border clearance programs/systems 

(International Trade Data System (ITDS) and the 

Detroit-Windsor Truck Ferry Inc. system to 

track trucks and prevent dangerous goods from 

illegally crossing the Ambassador Bridge and 

Detroit – Windsor Tunnel).



allow the exchange of 

authorised information with 

United States Customs and 

immigration authorities for the 

purpose of expediting border 

crossing of commercial 

vehicles and their drivers 

between Canada and the United 

States. 

T007 Technical Performance The response time shall be near 

real time. There will be no 

appreciable delay in responses 

to queries, either from fixed or 

mobile enforcement or from 

other jurisdictions. 

Transport Canada These requirements address the need for driver, 

vehicle and carrier information at the Canada / 

US border to permit National Security (Canada 

and the US) concerns to be addressed as well as 

to expedite movement of commercial vehicles 

and cargo between the nations. The system may 

provide information needed by the International 

Border Clearance Program (IBC) and other ITS 

border clearance programs/systems 

(International Trade Data System (ITDS) and the 

Detroit-Windsor Truck Ferry Inc. system to 

track trucks and prevent dangerous goods from 

illegally crossing the Ambassador Bridge and 

Detroit – Windsor Tunnel). 

Transport Canada This addresses the requirement stated in the RFP 

that the system be capable of exchanging data on 

a near real time basis. It should be pointed out 

however that although the response may be 

required to be near real time, actual data 

updating and dissemination of snapshots does 

not. 

T008 Technical Performance Snapshot data shall be available 

for Electronic Clearance 

purposes within 500 ms. of the 

request by the ECRI system. 

Tri-global Technical 

Requirements 

This is a requirement from the parallel project 

studying Electronic Clearance and Roadside 

Information systems. This requirement however 

is not meant imply anything about the proposed 

architecture or the storage and access of the 

snapshot. This requirement can be met by 

preloading the ECRI system with all or a subset 

of the snapshot data.


T009 Technical Performance Updates to Carrier Profile Data. 

Each jurisdiction is responsible 

for maintaining its carrier 

profile data. This data is the 

authoritative source data used 

to create snapshots. 

Analysis of FMCSA CVISN 

Program Level 1 

Requirements 

T010 Technical Performance Updates to Snapshots. 

Snapshots do not need to be 

updated on a near real time 

basis to incorporate changes in 

the carrier profile. Given that 

changes in the carrier profile 

(such as the results of an 

inspection) may not be entered 

into the system real time, 

updating of snapshot 

information on a periodic basis 

provides time for carrier profile 

data to be entered into legacy 

systems. 



Requirements 

T011 Technical Performance Updates Current Trip 

Information. CTI will be 

available on a near real time 

basis, whenever implemented 

by a jurisdiction. 



Requirements 

T012 Technical Performance The system will be available 

twenty-four hours a day, seven 

days a week. 

Interviews with Jurisdictions Enforcement activities may happen at any time 

of day or night, literally. Commercial traffic 

operates at throughout the day, seven days a 

week. The system needs to be accessible to 

enforcement personnel whenever needed.


T013 Technical Implementation The system will be developed 

using cost effective 

implementation, reusing 

existing software and systems 

where cost effective. 

Transport Canada To be effective, the system development and 

deployment must be affordable. Given tight 

government budgets, a system that requires a 

substantial development investment may not be 

viable. A system that uses existing software and 

builds on existing systems as much as possible 

will be less expensive than a system developed 

from scratch. Many components of the proposed 

system have been developed and implemented in 

the United States and Canada, so a cost-effective 

approach will make the proposed system more 

affordable without compromising technical 

effectiveness. 

T014 Technical Implementation The system shall use 

technology that is current, but 

shall utilise emerging 

technologies and standards 

wherever reasonable. 

Interviews with Jurisdictions Technologies available for ITS are in a state of 

continuing improvement, and the system needs 

to be able to incorporate new, more efficient 

technologies as feasible. An example of this is 

the shift in emphasis in the United States CVISN 

program from EDI based systems to those 

incorporating XML. At the time CVISN was 

initially implemented, EDI was state-of-the-art 

and XML was in a developmental phase and not 

available as a production system. XML is now 

emerging as state-of-the-art.


T015 Technical Implementation The system must be developed 

in such a way that final 

deployment is not based on 

obsolete technology. 


FMCSA 

Technologies available for ITS are in a state of 

continuing improvement, and the system needs 

to be able to incorporate new, more efficient 

technologies as feasible. An example of this is 

the shift in emphasis in the United States CVISN 

program from EDI based systems to those 

incorporating XML. At the time CVISN was 

initially implemented, EDI was state-of-the-art 

and XML was in a developmental phase and not 

available as a production system. XML is now 

emerging as state-of-the-art. 

T016 Technical Implementation The system shall be compatible 

with the Canadian ITS 

Architecture. 

T017 Technical Implementation The ITS/CVO Network for 

Canada shall be designed and 

developed in accordance with 

the Canadian National ITS 

Architecture. 

Transport Canada This complies with the requirement specified in 

the RFP. 

Transport Canada This addresses the need to ensure that Canadian 

CVO systems adhere to the national architecture. 

As the governing document, the National 

Architecture provides the framework for the 

development of Intelligent Transportation 

Systems, including CVO in Canada. 

T018 Technical Implementation The ITS/CVO Network for 

Canada shall be designed and 

developed using recognised 

standards and protocols to 

assure interoperability among 

and between Canadian and 

United States jurisdictions. 

Interviews with Jurisdictions This addresses the need to abide by technical 

standards in the design, development and 

implementation of the ITS/CVO network.


T019 Technical Implementation The system shall have the 

flexibility to allow interfacing 

with different implementations 

of driver D&V systems and 

carrier profile systems. 

Analysis of existing Canadian 

Systems 

Each province has a unique set of existing 

legacy systems. It is important that the system 

be developed to interface with these existing 

legacy systems. This will ensure cost-effective 

implementation by not requiring jurisdictions to 

upgrade or replace legacy systems in order to 

interface with the system. 

T020 Technical Implementation The system shall have 

extensibility to accommodate 

increased capacity over time. 

T021 Technical Implementation The system shall be developed 

with a phased approach to 

allow development based on 

jurisdictions’ requirements, 

needs, and capabilities. 

Transport Canada As specified in the RFP, the system shall be 

developed so as to incorporate additional CVO 

or other applications, such as electronic 

credentialing. This addresses those 

requirements. 


analysis of FMCSA CVISN 

program level 1 requirements 

Jurisdictions have specific needs and 

requirements that depend on such characteristics 

as the type of commercial vehicle operations, 

population density, geography, and degree of 

urbanisation. The system needs to be developed 

so that each jurisdiction is able to incorporate 

these requirements. An additional consideration 

is that each jurisdiction has varying levels of 

automation, technical resources, and supporting 

infrastructure. The system needs to be 

developed so that jurisdictions currently lacking 

a highly sophisticated infrastructure are not 

penalised but instead may phase in development 

in a manner that matches those jurisdictions’ 

technical and budget resource availability.


A001 Administrative General The system shall be designed in 

such a way to minimise the 

impact on the normal IT 

operation and maintenance in 

the jurisdiction. 

A002 Administrative Cost Although no stated cost ceiling 

or target has been identified, 

the system shall be designed to 

minimise R&D and O&M 

costs. 


CCMTA 


CCMTA, Transport Canada 

Similar to identifying a cost-effective method for 

system development and deployment, the 

system, the system should be designed to be 

incorporated and integrated into existing IT 

operations for each jurisdiction. This will help 

control operations and maintenance costs, and 

will provide an incentive to encourage system 

deployment by jurisdictions. 

All stakeholders a cognisant of the limited funds 

available and that if the system is too expensive 

it will not be viable.



Glossary 

D 

Appendix D – Glossary 

The following list provides a glossary of abbreviations commonly used with ITS. Not all have been used 

within this document, but are provided here as a general reference. 

AAMVA 

ACK 

ANSI 

API 

APL 

ATM 

ATMS 

AVC 

AVCS 

AVI 

AVL 

BER 

CA 

CANUTEC 

CAPS 

CASE 

CCMTA 

CCPA 

CD 

CDE 

CDLIS 

CDPD 

CD-ROM 

CEN 

CI 

CIA 

CMM 

CMV 

COTS 

CRA 

CSFR 

C-SNAP 

CSS 

CTI 

C-TPAT 

CVCS 

CVIEW 

CVIR 

CVISN 

CVL 

American Association of Motor Vehicle Administrators 

Acknowledgement 

American National Standards Institute 

Application Processing Interface 

The Johns Hopkins University Applied Physics Laboratory 

Asynchronous Transfer Mode 

Advanced Traffic Management System 

Automatic Vehicle Classification 

Advanced Vehicle Control System 

Automatic Vehicle Identification 

Automatic Vehicle Location 

Bit Error Rate 

Credentials Administration 

Canadian Transport Emergency Centre 

Computer-Aided Planning System 

Computer Aided Software Engineering 

Canadian Council of Motor Transport Administrators 

Canadian Chemical Producers’ Association 

Compact Disk 

Carrier Data Exchange 

Commercial Driver’s License Information System 

Cellular Digital Packet Data 

Compact Disk – Read Only Memory 

Comité européen de normalisation 

Credentialing Interface 

Custom Interface Agreement 

Capability Maturity Model 

Commercial Motor Vehicle 

Commercial Off The Shelf 

Canada Revenue Agency 

Carrier Safety Fitness Rating 

Carrier Snapshot 

Cascading Style Sheets 

Current Trip Information 

Customs and Trade Partnership Against Terrorism 

Commercial Vehicle Checkstation Communications 

Commercial Vehicle Information Exchange Window 

Commercial Vehicle Inspection Report 

Commercial Vehicle Information Systems and Networks 

Commercial Vehicle Licensing 

D-1



Glossary 

CVM 

CVO 

CVOR 

CVSA 

DMV 

DOB 

DOM 

DOT 

DPIU 

DSRC 

DVIS 

ECRI 

EDI 

EDL 

ERAP 

ETC 

ETR 

FAQ 

FAST 

FHWA 

FMCSA 

FMS 

FTP 

GIS 

GOTS 

GPS 

GUI 

GVW 

GVWR 

HAZMAT 

HOS 

HTML 

HTTP 

I/F 

I/O 

IEEE 

IFTA 

IMTC 

INS 

IP 

IRE 

ISDN 

ISO 

ISP 

ITDS 

Certificat de vérification mécanique (Certificate of Mechanical Fitness) 

Commercial Vehicle Operations 

Commercial Vehicle Operator Registration 

Commercial Vehicle Safety Alliance 

Department of Motor Vehicles 

Date of Birth 

Document Object Model 

Department of Transportation 

Data Processing Interface Unit 

Dedicated Short Range Communications 

Driver/Vehicle Inspection System 

Electronic Clearance and Roadside Inspection 

Electronic Data Interchange 

Electronic Data Library 

Emergency Response Assistance Plan 

Electronic Toll Collection 

Electronic Toll Road 

Frequently Asked Questions 

Free and Secure Trade 

Federal Highway Administration 

Federal Motor Carrier Safety Administration 

Fleet Management System 

File Transfer Protocol 

Geographical Information System 

Government Of The Shelf 

Global Positioning System 

Graphical User Interface 

Gross Vehicle Weight 

Gross Vehicle Weight Rating 

Hazardous Material 

Hours of service 

HyperText Markup Language 

Hypertext Transfer Protocol 

Interface 

Input/Output 

Institute of Electrical and Electronics Engineers 

International Fuel Tax Agreement 

International Mobility and Trade Corridor 

Immigration Naturalization Service (U.S.) 

Internet Protocol 

Inter-Provincial Records Exchange 

Integrated Services Digital Network 

International Organization for Standardization 

Internet Service Provider 

International Trade Data System 

D-2



Glossary 

ITS 

ITS-JPO 

IVHS 

JHU/APL 

LAN 

LSI 

MCMIS 

MDT 

MOA 

MOU 

MSDS 

NAFTA 

NATES 

NHTSA 

NORPASS 

NPV 

NT 

NTSB 

OOS 

OOSD 

OOSV 

OS/OW 

OSI 

PC 

PDA 

POE 

POP 

PSC 

PSTN 

PUC 

PVC 

RF 

RFP 

RFTA 

ROC 

SAAQ 

SAFER 

SAIC 

SDLC 

SQL 

SSN 

TCP/IP 

UML 

UN 

Intelligent Transportation System(s) 

Intelligent Transportation System Joint Program Office 

Intelligent Vehicle-Highway System 

The Johns Hopkins University Applied Physics Laboratory 

Local Area Network 

Legacy System Interface 

Motor Carrier Management Information System 

Mobile Data Terminal 

Memorandum of Agreement 

Memorandum of Understanding 

Material Safety Data Sheets 

North American Free Trade Agreement 

National Analysis of Trends in Emergencies System 

National Highway Traffic Safety Administration 

North American Pre-clearance and Safety System 

Net Present Value 

New Technology (Microsoft Operating System) 

National Transportation Safety Board 

Out of Service 

Out of Service Driver 

Out of Service Vehicle 

Oversize/Overweight 

Open System Interconnection 

Personal Computer 

Personal Data Assistant 

Port of Entry 

Post Office Protocol 

Public Service Commission 

Public Service Telephone Network 

Public Utility Commission 

Permanent Virtual Circuit 

Radio Frequency 

Request for Proposal 

Regional Fuel Tax Agreement 

Roadside Operations Computer 

Société de l’assurance automobile du Québec (Automobile Insurance Society of 

Quebec) 

Safety and Fitness Electronic Records 

Science Applications International Corporation 

Synchronous Data Limk Control 

Structured Query Language 

Social Security Number 

Transmission Control Protocol/Internet Protocol 

Unified Modeling Language 

United Nations 

D-3



Glossary 

URL 

USDOT 

VIN 

VMS 

WAN 

VPN 

WIM 

WRA 

WSDOT 

XML 

Universal Resource Locator 

United States Department of Transportation 

Vehicle Identification Number 

Variable Message Sign 

Wide Area Network 

Virtual Private Network 

Weigh-In-Motion 

Western Regional Agreement 

Washington State Department of Transportation 

eXtensible Markup Language 

D-4



Status of Automation of 

Provincial Systems Supporting CVO 

E 

Appendix E – Status of Automation of Provincial Systems 

Supporting CVO 

Quebec 

Quebec is considered fully automated for most CVO activities, including electronic roadside inspection and 

backend processing activities. The SAAQ system produces carrier profiles, carrier snapshots and vehicle 

snapshots for use by the enforcement officers. Lacking are the system components for electronic screening 

and electronic credentialing. 

Quebec has the infrastructure to support intra-provincial and extra-provincial data and information 

exchanges in real-time. However, the SAAQ Network is of proprietary nature that is only opened to 

SAAQ, some Quebec government agencies, and other authorised non-governmental users. In the context of 

a national ITS/CVO Network, Quebec needs to develop an interface for connecting to this network. 

Ontario 

Ontario is considered automated for many CVO activities. MTO has been automated for information 

gathering and retrieval for decades, although current processes are neither integrated nor efficient for user 

access to D&V and carrier information. MTO has the experience and installations to support both mainline 

and ramp electronic screening and credentialing activities. MTO has numerous sites equipped with Weighin-Motion 

(WIM), Automatic Vehicle Identification (AVI), Licence Plate Reader (LPR) and other ITS 

technologies. MTO was the participant of the Advantage CVO and the ITBCS projects. Advantage CVO 

program has now evolved into the NorPass and the ITBCS was the Ontario/Michigan/New York bordercrossing 

project. With the existing mainframe systems, databases and applications, MTO produces both 

carrier and vehicle snapshots for use by enforcement officers and authorised users in Ontario. 

What is lacking is the automation of roadside capture of inspection data and other infraction processes. To 

address this, MTO is actively involved in a pilot project for the development of a notebook device and 

applications for roadside data capturing. The notebook applications will also likely be implemented in the 

TIS client workstations. This will, in effect, provide on-line data entry of inspection reports anywhere in 

Ontario. However, there is no time frame for completing this project. 

The VRS Inquiry system is well on its way to completion. It is expected that the complete rollout of the 

VRS Inquiry system will be completed within the next 18 months. By then all fixed and mobile site TIS 

will be on-line to the VRS Inquiry system via the MTO Intranet. Users will use web browsers to access 

driver, vehicle and carrier information. It will become a seamlessly integrated and efficient system. Webbased 

applications are implemented with XML. 

MTO has the infrastructure to support intra-provincial and extra-provincial data and information exchanges 

in real-time. With the new VRS Inquiry system appearing on the MTO Intranet, MTO needs only to 

develop web portals in support of data exchanges in a national ITS/CVO Network. 

Right now, public can access different levels of information from the Internet with most browsers. 


Saskatchewan is considered fully automated for most CVO activities, including electronic roadside 

inspection and backend processing activities. The SGI MVD Inquiry system produces carrier profiles and 

carrier snapshots. However, SHT personnel have access only to carrier snapshots, in addition to D&V and 

carrier information. The non-accessibility to the CPS appears to be more on political than technical issues. 

Nevertheless, SGI will need to put in an application that allows SHT personnel to access the CPS. 

E-1





At the present time, Saskatchewan does not have the equipment and installations to implement electronic 

screening and credentialing. Since SHT enforcement officers do not have access to carrier profiles at fixed 

and mobile site vehicle inspection stations, electronic screening and credentialing do not appear to be high 

on priorities of CVO. 

Saskatchewan has the infrastructure to support intra-provincial and extra-provincial data and information 

exchanges in real-time. For connection to a national ITS/CVO Network, Saskatchewan would need to 

develop an interface and a web portal if information is to be accessible with web browsers. 

Nova Scotia 

Nova Scotia is on its way to automate most CVO activities, including electronic roadside inspection and 

backend processing activities. The CAPS produces carrier snapshots at the moment, and will shortly be 

able to produce carrier profiles and vehicle snapshots for use by enforcement officers. Lacking are the 

system components for electronic screening and electronic credentialing. Nova Scotia does not have the 

equipment and installations to implement electronic screening and credentialing. 

Nova Scotia has the infrastructure to support intra-provincial and extra-provincial data and information 

exchanges in real-time. For connection to a national ITS/CVO Network, Nova Scotia apparently needs 

only to develop a web portal for information exchange applications. 


Manitoba has minimum automation for CVO activities, except for backend processing and information 

inquiry activities. However, the information access is based on browser technology that makes the 

information housed in the Manitoba CPS and D&V systems easily adaptable to extra-provincial inquiries. 

Right now, public can access carrier snapshots with a web browser. 

Manitoba has the infrastructure to support intra-provincial and extra-provincial data and information 

exchanges in real-time. For connection to a national ITS/CVO Network, Manitoba apparently needs only 

to develop a web portal for information exchange with other jurisdictions. 

On the other hand, Manitoba has quite a way to go before electronic roadside inspection can become a 

reality. Electronic screening and credentialing will take an even longer time to materialise. 

Alberta 

Alberta is considered lagging in automation for many CVO activities. AT&U has a reasonable IT 

infrastructure for manual operations of information entry, retrieval, maintenance and updates. 

AT&U does not have any automation in place for information gathering and retrieval for CVO. 

Automation is the basis for electronic screening and credentialing. AT&U has a fixed site vehicle 

inspection station equipped with Weigh-in-Motion (WIM) system. But this WIM system has been out-ofservice 

for a long time and AT&U has no plan to re vitalise the system. 

The Partner-in-Compliance (PIC) program is a useful approach towards establishing and tracking the safety 

compliance status of commercial vehicles. However, it is currently a manually administered program with 

no prospect for automation any time soon. 

Although there was a proposal for automating roadside capture of inspection data and uploading captured 

data to CVO systems, there are no planned activities to proceed further with the proposal. 

E-2





There are quite a lot of modernisation activities that need to take place for the AT&U systems to support 

CVO and the national ITS/CVO Network. 

• The CVO systems communication network would be upgraded to support both landline and mobile 

connections. 

• Mobile site vehicle inspection stations (i.e., patrol vehicles for enforcement officers) would have 

access to information from CVO systems. 

• The mainframe infrastructure and applications would be developed to support non-proprietary 

communication and messaging protocols, for example, Internet technologies to provide web access to 

CVO data from CVO systems. 

• On-line, two-way, real-time interfaces among CVO systems would be developed for both intra- and 

extra-provincial vehicle activities. 


ICBC and BCT&H are heavy mainframe users. All CVO applications are platform specific in hardware 

and software, thus making transition to automation and adaptation of modern technologies somewhat 

challenging. 

BC does have one "toll" site on eastbound Coquihalla Highway that is equipped with WIM and 

management information systems. BC is in the process of equipping the Port Mann site near the 

BC/Washington border with WIM and CVISN compatible system. The Port Mann site would operate as a 

Washington State satellite within the NORPASS network. These sites are adaptable to electronic screening 

and electronic credentialing. 

Thus potentially, BC has the basic components to automate some CVO activities at least from the roadside, 

for example, electronic screening and electronic credentialing. The bigger challenges are the migration of 

data and applications from legacy systems to modern technology platforms. There is also the lack of 

automation efforts for roadside data capture. This situation may require more development efforts by 

ICBC to integrate its 

E-3



Security Issues as the 

Canada-US Border 

F 

Appendix F – Security Issues at the Canada-US Border 

F.1 Introduction 

Amendment No. 4 to the Terms of Reference required that “the successful respondent (contractor) will 

specifically address all security related requirements (i.e. driver/vehicle/contents) to ensure the safe and 

secure movement of goods across the Canada- US border. 

This will encompass harmonisation with US systems and ensure an integrated approach to the transfer of 

data. Both the transfer of data and accessibility to databases and information will be a primary focus of the 

study. 

The analysis will address the security regime at the Canada – US border, focusing on the following: 

• Harmonisation and integration with the US “CVISN” system. 

• Interface with ITDS, Canada/US Customs, Canada/US Immigration. 

• Areas where ITS/CVO technology can enhance security at the border, including transport of hazardous 

materials. 

• Level of enforcement, identifying areas where ITS/CVO technology can enhance and optimise 

Customs clearance of drivers and vehicles through automated driver/vehicle and cargo identification, 

while optimising vehicle flow.” 

SAIC Canada’s methodology for addressing the requirements of Amendment 4 was to incorporate these 

into the overall project work plan already developed for the initial tasks specified in the RFP. However, 

based on initial interviews with the US Federal Motor Carrier Safety Administration (FMCSA) and the 

Federal Highway Administration (FHWA) and in response to comments received from Transport Canada 

and the Steering Committee, SAICCanada expanded the scope of the analysis to include: 

• Assessment of Institutional Setting – Identifying those agencies involved in border crossing and 

security issues and the specific role of each agency. 

• Information Requirements – What information is needed by each agency, what is the information used 

for, what are the sources for the information (both agencies and legacy systems). 

• Technology Deployments – What technologies and systems are being used, what are planned 

deployments, what are potential interoperability issues and opportunities. 

• Potential ITS/CVO Applications – What are existing ITS/CVO applications, how is ITS/CVO being 

incorporated into proposed deployments, what information can be provided by ITS/CVO, opportunities 

for interoperability and data sharing. 

SAIC Canada’s initial investigation under the expanded scope included interviews with ITS/CVO Border 

Crossing Specialists at FMCSA and representatives from FHWA’s Office of Intermodalism (the FHWA 

office involved in working with other US Government agencies border crossing issues). In addition, SAIC 

conducted a literature review and Internet search for additional information on border crossing and security 

programs and projects that would address the scope of Amendment 4. The results of this analysis are 

presented in this section of the report. 

F-1





F.2 Southbound (US) and Northbound (Canada) Importation Process 

As a first step in addressing the requirements of Amendment 4, SAIC reviewed documents summarising 

the current border crossing operations. The intent of this analysis was to identify what agencies are 

involved and what role they play, what existing processes are, and what data elements are required. The 

following is a breakdown of participants and their roles in the clearance of commercial shipments 

southbound importation through US Customs and northbound importation through CCRA. 3 

F.2.1 Importer (Consignee) 

The importer is responsible for everything that is declared and filed with US Customs/CCRA and is 

responsible for ensuring that all necessary information on the shipment is obtained from the exporter. 

Among the importer’s responsibilities are: 

• Ensuring that relevant information presented to US Customs/CCRA for a shipment is accurate. 

• Payment of duty and tax to US Customs/CCRA. 

• Provide any import permits to US Customs/CCRA. 

• Payment of fines from inaccurate or omitted shipment information. 

• Record keeping for five years for US Customs on shipment details - type of good imported, product 

quantity, price and product origin. The CCRA requires record keeping for six years and records must 

be located in Canada, in either paper or electronic format. If an importer wants to keep records outside 

Canada, the importer must obtain written CCRA approval. 

F.2.2 Exporter (Shipper) 

The exporter is many times the seller of a product and arranges for transportation of a particular shipment. 

The exporter provides the motor carrier with customs documentation necessary to facilitate entry into either 

the United States or Canada. The information that supplied by the exporter to the motor carrier includes: 

• Company name and address, location of the shipper. 

• Company name and address, location of item producer, if not the shipper. 

• Consignee’s company name, address location and Internal Revenue Service number. 

• Specific product and shipment information including complete description, value of product, quantity, 

packing, weight, monetary currency of sale transaction and country of product origin. This 

information is usually contained in a US Customs pro-forma invoice or a standard commercial invoice. 

3 

This material is adapted from reports prepared in conjunction with the evaluation of the Washington 

State – British Columbia International Mobility and Trade Corridor (IMTC) 

Commercial Vehicle Border Crossing ITS Deployment. The evaluation is being conducted by SAIC 

(primary report authors are Erik Wik, Dan Stock, and Mark Jensen) under FHWA Contract DTFH61- 

96-C-00098, SAIC Task 9827. 

F-2





F.2.3 Motor Carrier 

The motor carrier transports the shipment to and from Customs’ processing facilities. The carrier is 

normally responsible for reporting a pending shipment to US Customs/CCRA. When a shipment arrives at 

the Canada-US border, the motor carrier submits the necessary documentation to their designated broker 

and then to Customs under a manual paperwork based process. 

F.2.4 Customs Broker 

The customs broker constantly reviews evolving customs practices as well as enactment of laws and 

regulations that impact trans-border shipments to effectively represent the importer in dealing with US 

Customs/CCRA. Customs brokers are licensed by US Customs/CCRA to serve as an intermediary between 

the US government/Canadian government and the importer. The importer grants the customs broker legal 

authority to act as the importer’s agent through a power of attorney arrangement. Some services rendered 

by the customs brokers include: 

• Preparation and submission of required custom release documents and information to US 

Customs/CCRA and other governmental agencies. 

• Obtaining timely release of goods from US Customs/CCRA custody 

• Filing entry documents with US Customs/CCRA on behalf of the importer 

• Paying required duties, taxes and fees to US Customs/CCRA on behalf of importer 

F.2.5 US Customs/CCRA 

US Customs/CCRA enforces laws, regulations and administrative policies to ensure admittance of only 

approved goods into their respective nations, preventing entry of potential goods that could represent a 

security risk while minimising any disturbance to the commercial community in the importing and 

exporting of goods. Following are some of the duties performed by US Customs/CCRA: 

• Reserve the right to deny access, search, seize or request additional information concerning a shipment 

or goods being imported into their nation. 

• Properly assess and collect customs duties, excise taxes, fees and monetary penalties if applicable on 

imported goods. 

• Maintain detailed information profiles pertaining to all US/Canadian importers past and present. This 

importer profile will in part determine the ability of an importer to participate in special customs 

initiatives designed to simplify and speed up the customs clearance process such as the Free and 

Secure Trade (FAST) program. 

• Collect accurate import and export data for creation of international trade statistics. 

• Enforce import prohibitions and restrictions. 

• Prevent illegal trade practices from occurring such as provisions relating to quota enforcement, antidumping 

regulations for specific products from designated countries and patent/trademark 

infringements. 

F-3





F.2.6 US Customs Import Process (Southbound) 

Clearance of imported goods through US Customs involves these specific steps: entry (release and 

summary), inspection, appraisement and classification, and liquidation. 

F.2.6.1 Customs Entry 

The customs entry process entails not only the shipment arrival at the US Customs border facility, it also 

the process of presenting documentation for clearing the shipment through customs. Imported goods not 

entered in a timely manner are sent to a warehouse until it is claimed. The importer is held liable for 

storage fees relating to the holding of their goods. If goods go unclaimed for one year, the goods are 

auctioned off or destroyed. 

Customs entry is normally a two-step process consisting of the physical release of goods from US Customs 

custody and accounting of goods to US Customs called entry summary. 

The release is the authorisation from US Customs to proceed to deliver goods to their US destination. 

Release documents must be filed within 5 days of a shipment’s arrival at a US port of entry, but is normally 

done prior to or at the time of physical arrival. These documents given usually to the customs broker 

contain the required information to make possible the release of goods from customs custody. Some of the 

required information includes: 

• Company name and address location of the shipper 

• Company name and address location of item producer, if not the shipper 

• Company name, address location and Internal Revenue Service number of the consignee. 

• Company name, address location and Internal Revenue Service number of the shipment buyer, if not 

the consignee. 

• Detailed product and shipment information such as complete content description, shipment value, 

product quantity and packing, weight, monetary currency of sale transaction and country of product 

origin. 

• Information required by other governmental agencies if applicable. A permit, license or other 

certification may be required on certain imported goods. The importer must comply with these agency 

regulations in order for their shipment to be released. Some agencies requiring import information 

include the US Department of Agriculture, US Department of Energy, Environmental Protection 

Agency and the Food and Drug Administration. 

F.2.6.2 Required and Supplemental Documents 

The two traditional documents that cover the required information for US Customs are the Inward Cargo 

manifest that is created by the motor carrier and the US Customs Invoice created by the exporter. In lieu of 

the US Customs Invoice other documents may be utilised to convey required information such as the Bill of 

Lading, Commercial Invoice or packaging lists. 

US Customs Invoice 

The Customs Invoice is the fundamental document ordinarily provided to the motor carrier, usually 

prepared by the exporter. The Customs Invoice is used to establish the classification of imported goods, 

F-4





shipment value for duty, tax and tariff rates. The accurate completion of this document aids in the customs 

clearance process. 

Inward Cargo Manifest 

This cargo manifest supplies an itemised list of shipment contents that is presented to US Customs to 

expedite customs clearance in either paper or preferably electronic copy. The motor carrier creates the 

manifest based on information provided by the shipper. The motor carrier must forward this manifest to 

the importer’s customs broker in order to obtain a release from US Customs. This manifest is designated a 

specific identifiable number by US Customs that enables monitoring to ensure clearance and the shipment 

closure process are completed. 

Bill of Lading 

The information on the Bill of Lading must be consistent with the information listed on the Commercial 

Invoice. It must contain a complete and accurate description of the goods including number of 

boxes/pallets/cartons, weight, shipping terms and name and address of consignee. The motor carrier 

provides a copy of the Bill of lading with the exporter as proof of the transfer of goods from shipper to 

motor carrier. A copy is also sent to the importer and the motor carrier keeps a third copy for their records. 

Commercial Invoice 

This document is an invoice with a complete description of the goods being shipped, along with the proper 

valuations and currency information. This document forms the basis of the terms by which the importer 

pays the exporter, but it is also used as a source to assist customs brokers in clearing goods through 

customs for the importer. Commercial Invoices come in many forms and do not conform to a rigid format. 

They may be substituted for a US Customs Invoice as long as the same prescribed information is covered 

and must be pre-approved by US Customs. 

Certificate of Origin 

The broker to determine the correct rate of duty under the North American Free Trade Agreement 

(NAFTA) uses the Certificate of Origin. If this document is missing, the highest rates may be applied to 

each consignment, and U.S. Customs may not allow the goods into the country. 

Packing List 

This document contains a detailed listing of shipment contents including product quantities, model 

numbers, product dimensions, net and gross weights. The packing list should also specify whether 

configured by carton, crate or pallet. This document is not required by US Customs, but the customs 

broker uses it to supply additional shipment information to US Customs. This information is especially 

useful should US Customs request a physical examination of shipment contents. 

Transportation and Exportation (T&E) Customs Bond - may be required if final destination of goods is 

outside the U.S. 

F.2.7 Role of Customs Broker in Release 

The customs broker is presented with all the necessary information and relating documentation from 

importer, exporter and the motor carrier. The customs broker then reviews the documents and contacts the 

relevant party if any necessary information is missing or to clarify inaccuracies. This allows the customs 

broker to submit a release package to US Customs. 

F-5





F.2.8 Surety Bond 

This bond guarantees that the importer will pay all applicable duties, taxes, fees and fines to US Customs 

for their shipment. Having a bond on file with US Customs allows the importation of goods prior to the 

payment of duties, taxes, fees and fines. The surety bond designates the importer of record to US Customs. 

Bonds can be obtained from a surety firm, which is an insurance company authorised by the US Treasury 

Department to underwrite customs bonds. The surety bond-issuing firm will be called on to provide 

payment when an importer cannot or will not fully pay the US government. There are single transaction 

bonds that cover only a single shipment at one point of entry. More common for commercial purposes in 

the continuous bond that covers multiple shipments at a point of entry for an annual premium. 

F.2.9 US Customs Release Methods 

Truck shipments are typically released within minutes or hours. Ocean arriving shipments may take 

several days, hence the five-day window for customs release. There are three principle means of having 

goods released with each having impact on the rate of the release. 

F.2.9.1 Border Cargo Selectivity 

Border Cargo Selectivity is the standard US Customs release method. The motor carrier submits an Inward 

Cargo Manifest to US Customs. The motor carrier then submits customs documentation from the shipper 

to the customs broker that includes the US Customs Invoice and/or other supporting documents. The 

customs broker reviews this information and transmits a release package electronically to US Customs via 

the Automated Broker Interface (ABI) that can result in expedited release. 96% of all entries are submitted 

to US Customs by ABI. This allows US Customs minimal time to analyse shipment details prior to arrival 

and assign a “relative risk” to each shipment. The customs broker gives the motor carrier a paper release 

package. The motor carrier then proceeds to the US Customs facility and presents the release package 

along with the Inward Cargo Manifest. US Customs then reviews this information along with the 

transmitted information from the customs broker and makes a decision to either release the shipment or 

direct a physical inspection. 

F.2.9.2 Line Release 

The current line release system for US Customs is the Border Release Advanced Selectivity System 

(BRASS). This is an expedited release method for repetitive land border crossing shipments. For a 

shipment to be eligible for line release, the customs broker must submit a line release application for each 

distinct product that an importer intends to ship. When accepted for line release, an exporter affixes the 

line release barcode label to the top right section of the Customs Invoice. A US Customs officer wands the 

barcode into the Customs system, matches the barcode and invoice information, and releases the shipment. 

The cargo release data is transmitted to ACS (Automated Commercial System, US Customs current 

system), which establishes an entry and the requirement for an entry summary, and forwards release 

information to relevant parties to the transaction (customs broker, importer, motor carrier and exporter). 

F.2.9.3 Pre-Arrival Processing System (PAPS) 

The Pre-Arrival Processing System is a motor carrier driven US Customs system devised to speed up 

customs releases and reduce congestion at border crossings. This system allows for advance customs 

clearance of motor carrier shipments prior to the shipment physically crossing the border. The process is 

initiated when a motor carrier or the shipment’s importer or exporter requests a PAPS release by 

forwarding the necessary documentation to the customs broker in advance of the physical arrival of the 

goods. A specially formatted barcode must be attached to the PAPS documentation. When the motor 

F-6





carrier arrives at the inspection booth, US Customs will scan the barcode and verify that the broker has 

prepared the PAPS release. Unless US Customs requests a secondary inspection, the motor carrier and the 

cargo are formally released. 

F.2.10 Entry Summary 

Any imported goods are not legally entered (registered) until the goods have been released by US Customs 

and estimated duties and taxes have been paid. Entry summary information must be filed within 10 days 

from the date of release and estimated duties and taxes paid. The customs broker files the entry summary 

on behalf of the importer. 

F.2.11 Inspection 

In order to confirm admissibility and compliance, US Customs has the discretion to search and seize any 

goods imported into the United States. There are many reasons that goods may need to be examined. 

Some of these reasons it may be deemed necessary to inspect shipments to determine: 

• Value of the goods for US Customs purposes for assessment of duties 

• Whether the shipment contains prohibited products or substances 

• Whether the requirements of other governmental agencies have been satisfied 

• Whether the amount of goods listed on an invoice is correct, and that no shortage or overage is present 

in the shipment 

• Country of origin marking is present and is accurate 

F.2.12 Appraisement and Classification 

US Customs determines the ultimate appraisement of the dutiable value and correct duty rate to be applied 

to a shipment. The dutiable value of goods is the value on which the assessment of duties and taxes is 

based. The Harmonized Schedule (HS) classification number determines the duty rate of goods. Rates of 

duty for imported goods vary depending upon the country of origin. 

F.2.13 Liquidation 

Liquidation is the final step in the entry process and is the finalisation of the import transaction by US 

Customs. At the point when US Customs is satisfied with the entry including the payment of duties and 

taxes, the entry is liquidated. Usually, commercial entries are liquidated within 314 days after the entry 

was filed. Most are liquidated much earlier. 

F.2.14 CCRA Importation Process (Northbound) 

CCRA believes that most parties to a shipment voluntarily comply with relevant importation laws. Parties 

that comply with the law will only be subject to occasional random examinations. This examination policy 

reduces a shipment’s release time and ultimate costs to import commercial goods. CCRA maintains 

compliance and commodity profiles to target shipments for examination based on risk-management 

principles to determine if a shipment should be deemed high-risk or low-risk. 

F-7





F.2.14.1 

Step 1 - Registering an Import Business 

Commercial importers must acquire a Business Number for their CCRA import account. 

The Business Number consists of 15 digits that identify the import business account to CCRA. The 

Business Number must be displayed on most customs documents being presented to CCRA. 

F.2.14.2 

Step 2 - Reporting a Shipment 

The carrier under traditional circumstances reports your shipment to the CCRA when it arrives at the 

international border entry point. The motor carrier must report commercial goods imported into Canada on 

an approved cargo control document (CCD). It is not necessary to utilise a cargo control document when 

using line release processing options. 

The cargo control document 

The motor carrier uses the cargo control document to report a shipment to the CCRA. The cargo control 

document serves as the initial record of the shipment's arrival to the CCRA. This document is also used for 

all shipments moved in-bond to an inland customs office, sufferance warehouse, or bonded warehouse. The 

motor carrier also sends a copy of the cargo control document to the importer and shipper to inform that the 

shipment has arrived. The CCD contains a bar-coded cargo control number where the first four numbers 

represent a unique carrier code to identify the motor carrier. 

The shipper prepares any required documents for import entry. These documents are normally faxed or 

sent electronically to the Canadian broker prior to the shipment arrival. In some cases, these documents can 

be filed with CCRA up to 5 days ahead of shipment arrival. If required documents are missing, the broker 

contacts the shipper to obtain the needed paperwork. The required documents include the Bill of Lading, 

Certificate of Origin, Canada Customs Invoice or Commercial Invoice and Packing List. 

F.2.14.3 

Step 3 - Getting Shipment Release 

There are two methods to attain release of a shipment from CCRA. The first method is release with full 

accounting and payment at that time and the second method is release on minimum documentation (RMD). 

Release on minimum documentation (RMD) 

Release on minimum documentation is a method to fast-track shipment release by accounting for and 

paying for shipments after CCRA releases them. The importer or broker must affix the transaction number 

in bar-coded format to the release documents. CCRA identifies each shipment with a unique 14-digit 

transaction number. This transaction number is used to identify shipments throughout the customs process. 

Each importer using RMD is assigned a unique five-digit account security number. This number will 

always appear as the first five digits of the transaction number. 

For an importer to utilise RMD, the importer must post security with CCRA to ensure payment. This 

monetary security can be posted either locally or nationally depending on the nature of the importers’ 

business. An importer may use any of the following as monetary security: 

• Cash 

• Certified check 

• Transferable Government of Canada bonds 

F-8





• CCRA (Revenue Canada) customs bonds that a registered Canadian bank or approved financial 

institution has issued 

The goal of RMD is to facilitate processing import release requests that are complete, accurate, and do not 

require CCRA examination of goods or review of permits. CCRA has set the following time processing 

goals for RMD transactions. 

• EDI submission to CCRA 45 minutes 

• EDI machine submission to CCRA 5 minutes 

• Paper based submission to CCRA 2 hours 

RMD release documentation requirements 

Unless an examination is requested on a shipment, CCRA will release a shipment under RMD when 

presented a completed cargo control document, any necessary import permits and two copies of a properly 

completed invoice by the motor carrier at the border entry. RMD requires that a shipment’s invoice must 

contain: 

• Importers name and the import account number 

• Exporter's name 

• Unit of measure and quantity of goods 

• Estimated value of the goods in Canadian dollars 

• Detailed description of the goods 

• Country of origin for the goods 

• Bar-coded transaction number affixed to the invoice 

CCRA Line Release 

There are two basic CCRA line release options that speed up the release processing times of commercial 

goods and reduce traffic congestion at international border crossings. 

Pre-Arrival Review System (PARS) 

The Pre-Arrival Review System (PARS) enables release information that contains a shipment's estimated 

time and date of arrival, the invoice data and the original copy of any required permits. PARS 

documentation can be submitted up to 30 days before the goods physically arrive in Canada. Canada 

Customs can process this advance documentation; enter the cargo control number; and either a recommend 

a shipment for release or recommend an examination take place once the goods arrive at the border. The 

release recommendation will be ready when your goods arrive if submitted to PARS at least: 

• EDI 1 hour in advance 

• Paper 2 hours in advance 

F-9





Frequent Importer Release System (FIRST) 

The Frequent Importer Release System (FIRST) is the other prominent line release option. If an importer 

has an established compliance record, the importer can apply for FIRST privileges to obtain release of lowrisk, 

low-revenue shipments that are imported on a regular basis. If an importer qualifies, CCRA supplied 

an authorisation number that appears on an importer’s pre-approved import document that identifies your 

FIRST shipments. When the goods arrive at the border, the motor carrier presents the import document 

with the bar-coded authorisation and transaction number, a description of the goods, and necessary 

invoices. CCRA inputs the bar code into their computer system to confirm that the importer has FIRST 

privileges for the shipment in question. The CCRA officer then decides whether to release the shipment or 

refer it for examination. 

Electronic Data Interchange (EDI) Release 

EDI release allows electronic transmission of release data, including invoice information, to the 

Accelerated Commercial Release Operations Support System (ACROSS). A CCRA officer reviews the 

information and transmits the release decision back electronically, normally to the customs broker. 

F.2.14.4 

Step 4 - Examining a Shipment 

CCRA has the authority to randomly select shipments for examination to verify compliance with CCRA 

regulatory requirements, detect prohibited or restricted items, and fulfil other government agency 

regulatory requirements. The frequency of examinations depends in part on an importer’s established 

compliance pattern and that of other organisations involved with the shipment as well as the type of goods 

being imported. 

F.2.14.5 

Step 5 - Accounting for a Shipment 

The final step in the CCRA importing process is to submit a final accounting package for shipments 

imported into Canada. A typical complete accounting package consists of the following documents: 

• 2 copies of the cargo control document 

• 2 copies of the invoice 

• 2 copies of a completed Canada Customs Coding Form 

• Import permits, health certificates, or forms required by other Canadian federal government agencies 

• Certificate of Origin (for example NAFTA) 

These documents can be presented as either paper copies or if granted CCRA authorisation, the documents 

can be transmitted via EDI. 

The invoice 

Three available invoicing options are permitted to CCRA: 

• A Canada Customs Invoice that either the importer or the shipper can fill out 

• A commercial invoice containing the same information as the Canada Customs Invoice 

F-10





• A commercial invoice that indicates the buyer, seller, country of origin, price paid or payable, and a 

detailed description of the goods, including quantity, and a Canada Customs Invoice that provides the 

remaining information. 

Canada Customs Coding Form 

When accounting for imported commercial goods, the importation is documented on the Canada Customs 

Coding Form. This form must include the following shipment information: 

• Importer’s name and the import account number 

• Description of the goods 

• Direct shipment date 

• Tariff treatment 

• Country of origin 

• Tariff classification 

• Shipment Value for duty 

• Appropriate duty or tax rates 

• Calculation of duties payable to CCRA and other Canadian federal agencies 

CCRA receives 96% of all the Canada Customs Coding Forms using electronic submission. This system is 

called CADEX and provides parties to a shipment with access to reports and files to assist in the electronic 

preparation of the Canada Customs Coding Form. CADEX enables direct electronic transmission of 

Canada Customs Coding Form information to the CCRA computer system over telecommunications lines. 

Payment 

CCRA allows to methods to pay any duties on goods under RMD release. The importer can pay every 

month based on a CCRA monthly bill or the importer can make any number of interim payments based on 

the daily statements sent by CCRA. If an accounting package is not presented or if the CCRA is unable to 

validate the package within the five-day time period, CCRA will charge you a late-accounting penalty for 

each shipment. If an importer repeatedly files accounting packages late, an importer may receive a notice 

requiring accounting for the goods on time for a specified period. 

F.3 Summary of Border Crossing and Security Initiatives 

The next step in the analysis conducted for Amendment 4 was to identify the major border crossing and 

security initiatives, programs, and field operations tests that are being or have been implemented. These 

include: 

• Washington State – British Columbia International Mobility and Trade Corridor (IMTC) Commercial 

Vehicle Border Crossing ITS Deployment 

• Free and Secure Trade (FAST) Program 

F-11





• US DOT HazMat Driver Background Check – new rulemaking from Transportation Security 


• FMCSA sponsored HazMat Safety and Security Field Operations Test 

• International Trade Data System (ITDS) 

• Customs and Trade Partnership Against Terrorism (C-TPAT) 

A brief summary of these programs is presented in this section of the SAIC report. This summary was 

developed from a review of two sources of information: a literature review of documents on each project or 

initiative; and, an Internet search. A list of references used in developing this summary is included at the 

end of this section. 

F.3.1 IMTC 4 

The Washington State – British Columbia International Mobility and Trade Corridor (IMTC) Commercial 

Vehicle Border Crossing ITS deployment seeks to be the first fully operational and bi-national electronic 

commercial vehicle operations (CVO) border crossing system in North America. At a total investment of 

$4.35 million, this ITS deployment will represent the largest single investment in CVO border crossing ITS 

technology to date. This deployment will provide the opportunity for a working model system that coordinates 

shippers, truckers, and selected government agencies into one system. 

The project is being implemented in two phases. The Phase I system uses transponder tags to track in-bond 

containers that are imported by vessel to the ports of Seattle and Tacoma bound for Canada by means of 

over-the-road shipment. The tags are installed in the cab of the truck and contain a serial number that 

references shipping manifest data to identify the particular container. Tag readers with AVI functionality 

have been installed at the exit gates of the APL Limited terminal at the Port of Seattle, the Maersk-SeaLand 

terminal at the Port of Tacoma, and at the US Customs trucking lane approach to the Blaine, Washington 

international border. As the truck and container passes through a Maersk-Sealand or APL terminal gate, 

the following data can be recorded or verified and communicated over the Internet to the TransCore 

“TransCorridor” AVI System: Vehicle ID (Transponder Serial Number); Date & Time of Entrance Event; 

and Shipping Facility ID. 

The technologies currently deployed are shown in the graphic on the following page. To date, the State of 

Washington and the Province of British Columbia have been exchanging WIM data, and Washington is 

also providing BC with electronic screening software. The project also uses the DSRC standard for 

exchanging data between AVI and transponders. The project, however, does not use a transponder that is 

interoperable with E-Screening applications. 

Phase II is a continuation of the Phase I effort that includes improved northbound systems approaching 

Canada, a southbound waiting area for commercial trucks approaching the United States, a Canadian WIM 

system, and further integration of Trade Corridor Operating System information management system. This 

Internet-based system links the shipping line’s information system and US Customs’ Automated Manifest 

System (AMS). Currently, the system is being operated in San Diego, CA, at a TransCore service centre. 

TransCor 5 e will also provide the system integration and support for this deployment. For security and 

privacy protection, information from the TCOS is only available to authorised, registered users. 

4 

5 

Adapted from SAIC - A Combined IMTC Commercial Vehicle Border Crossing ITS Deployment: 

Evaluation Plan / Detailed Test Plans. October 2002 

TransCore is the vendor providing services to the project. 

F-12





The TransCore system provides for all tracking and data functions to be viewed and managed over the 

Internet. This is accomplished via the user (e.g. a shipping company) logging on to the “TransCorridor” 

web site, and entering in a pre-authorised user name and password. 

Transponder AVI readers will be expanded in location and integrated into TCOS. Canada has constructed a new 

truck parking area on the north side of the border to facilitate a reduction in southbound congestion. The WIM 

system on the Canadian side will allow critical vehicle information to be electronically read and forwarded to 

border officials and simultaneously disseminated via TCOS. These ITS-based solutions are all part of the entire 

bi-national effort to implement ITS solutions that will increase efficiency and reduce costs. 

F-13





Deployed ITS – CVO technologies across the Seattle – Tacoma and southern British Columbia regions. 

Source: SAIC - A Combined IMTC Commercial Vehicle Border Crossing ITS Deployment: 

Evaluation Plan / Detailed Test Plans, page A-4. October 2002 

F-14





F.3.2 Free and Secure Trade (FAST) Program 

Some of the FAST program features include: 

• Increased integrity in supply-chain management processes by offering expedited clearance processes to 

those carriers and importers who have enrolled in the U.S. Customs – Trade Partnership Against 

Terrorism (C-TPAT) or Canada's Partners in Protection (PIP) - similar programs that call for clients' 

use of business processes hat minimise exposure to criminal elements 

• Streamlined and, where appropriate, integrated registration processes for drivers, carriers, and 

importers minimising administrative requirements while ensuring that only low-risk 

• Trade chain participants with sound and secure business practices are extended the privileges of the 

FAST program 

• Expedited clearance of low risk shipments by reducing the information required to meet customs 

requirements, dedicating lanes at major crossings to FAST participants, using common technology, 

and focusing limited physical examinations on matters related to public security and safety 

• Integrated and advanced technology, such as transponders used by both the U.S. and Canada, 

facilitating the clearance of low-risk shipments and mitigating the costs of participation to clients 

• Dedicated compliance account managers who will build and maintain client partnerships 

• Monitor clients' compliance with program requirements 

For low-risk goods being imported from Canada into the United States by a pre authorised importer, a preauthorised 

carrier, and a registered driver, minimal data will be transmitted in advance of the arrival of the 

shipment at the border to US Customs. When the shipment arrives at the border, it will be processed 

through a dedicated lane where the driver will present his registration card and, using bar code or 

transponder technology, identify the shipment. Whether low-risk goods are moving into the US or Canada, 

they will be cleared expeditiously through dedicated lanes using compatible technology. At present, 

however, it does not appear that the transponders being used are interoperable with similar transponders 

being used for ITS/CVO applications. 

The benefits of the FAST program will be available to only those drivers, carriers, and importers who have 

been pre-authorised by the United States and Canada. Drivers authorised to use the FAST program will 

have a demonstrated history of complying with all relevant legislative and regulatory requirements. 

Importers and carriers authorised to use the FAST program will have a demonstrated history of complying 

with all relevant legislative and regulatory requirements, and will have made an investment in securityenhancing 

business practices as required by the US C-TPAT and/or Canadian PIP programs. The joint 

United States-Canada Free and Secure Trade (FAST) initiative is now operational and include Detroit 

MI/Windsor, Ontario, Canada; Port Huron MI/Sarnia, Ontario; and Buffalo NY/Fort Erie, Ontario. 

Security Questionnaire 

Customs Trade Partnership Against Terrorism (C-TPAT) 

Partners in Protection (PIP) 

U.S./Canada Highway Carrier 6 

6 

Source – www.customs.gov 

F-15





Security is an important element of our partnership. We are looking to our partners to ensure that sound 

security measures are implemented to help protect Canada and the United States from any unwanted 

persons or goods that could pose a threat to either country. At a minimum, carriers must address the 

following security elements: 

Physical Security 

• Describe what measures are in place to protect the physical security of your company’s facilities and 

conveyances. 

• What measures are in place to prevent theft of goods at your premises or while in transit? 

• What security measures are in place with respect to shipping and receiving controls? 

• What security measures are in place to protect your automated systems? 

• Describe your security program’s internal controls and method to report and correct problems. 

• Describe the changes you envision making to improve security. Identifying perceived weaknesses or 

gaps would not necessarily prohibit participation in C-TPAT or PIP. Customs is committed to working 

with you to identify effective corrections and adjustments to your processes that will result in a more 

secure supply chain operation. 

Personnel Security 

• Describe what pre-employment screening, recruiting practices and periodic background checks are 

conducted on your employees. 

• Describe the training your employees are given on security awareness and procedures. 

• What is your code of conduct policy regarding security violations? 

• What internal controls are in place for reporting and managing problems related to personnel security? 

Service Provider Requirements 

• What security standards do you take to protect your property, conveyances and freight when 

employing service providers? 

• Describe your plans to include major service providers and international trade chain partners in your 

enhanced security measures, such as the: 

I. Customs-Trade Partnership Against Terrorism (C-TPAT); 

II. Carrier Initiative Program (CIP); 

III. Super Carrier Initiative Program (SCIP); 

IV. Business Anti-Smuggling Coalition (BASC); 

V. Partners In Protection; 

F-16





VI. Customs Self-Assessment (CSA). 

F.3.3 US DOT HazMat Driver Background Check 7 

The Transportation Security Administration, in conjunction with the Federal Motor Carrier Safety 

Administration and the Research and Special Programs Administration, has announced final rules requiring 

background checks on commercial drivers certified to transport hazardous materials. The final rule, which 

impacts an estimated 3.5 million drivers, appears in the May 6 Federal Register. Under the rule, all drivers 

are required to undergo a routine background that will include a review of criminal, immigration, and FBI 

records. 

All drivers who hold HazMat endorsements will be checked by TSA (names and social security numbers). 

A fingerprint background check will be implemented within 180 days of the May 6 publication of the rule, 

which is effective immediately. Under the new rule, States cannot issue or renew a HazMat endorsement to 

a commercial driver’s license unless TSA has completed a background check of the applicant. 

TSA does not plan to furnish motor carrier employers with the results of the background checks. 

Following the background check, a driver who is disqualified from transporting hazardous materials may 

continue to transport non-hazardous cargo. 

F.3.4 FMCSA HazMat Safety and Security Field Operations Test 8 

In Cupertino with industry, and on behalf of the Federal Highway Administration (FHWA), FMSCA is 

sponsoring the Hazardous Materials Transportation Safety and Security National Field Operational Test. 

The purpose of this project is to test methods for leveraging technology and operations to improve HazMat 

transport security, safety, and operational efficiency. 

The operational test scenarios will address technology system solutions via the following risk areas 

inherent in the HazMat (HM) movement chain: 

• Driver verification; 

• Off-route vehicle alerts; 

• Stolen vehicles (both tractors and untethered trailers); 

• Unauthorized drivers; 

• Cargo tampering; and 

• Suspicious cargo deliveries. 

Four test scenarios have been developed that will test both technology components and integrated systems. 

The test scenarios will demonstrate an integrated operational approach that will highlight 23 of the 25 

FMCSA-identified functional operational risk activities as feasible. Table 17 presents the functional 

requirement elements for this project, which fall into the following HazMat movement chain action stages: 

the pickup of HazMat from the shipper; the en-route HazMat transportation; and the HazMat shipment to 

the receiver at the final destination. As part of this test, a vulnerability assessment was conducted to 

7 

8 

Adapted from http://www.truckline.com/infocenter/news/050603_hazmat.html. 

Adapted from - SAIC, “Hazardous Material Transportation Safety and Security Field Operational Test 

Final Evaluation Plan” Contract DTFH61-96-C-00098 Task 9851, March 2003. 

F-17





identify possible vulnerabilities against which technologies and integrated solutions could be tested. Each 

of the functional requirements is matched with the particular vulnerability it addresses. Table 18 defines 

the vulnerabilities identified through the vulnerability assessment. 

Action Stages 

Pickup HazMat (HM) from 

Shipper. 

En-Route HazMat 

Transportation. 

Table 17 – FMCSA-Designated Functional Requirements 

Functional Requirement Vulnerability Addressed 

Items/Description 

1.1 HM driver identification V-12,V-17,V-20 

and verification by the 

shipper. 

1.2 HM cargo verification by 

the driver, dispatcher, and 

receiver. 

1.3 HM driver identification 

and verification by the vehicle. 



dispatcher. 

1.5 HM cargo tampering alert 

to the driver and the 

dispatcher. 

1.6 Remote cargo locking and 

unlocking by the dispatcher. 


and verification by dispatcher. 


and verification by roadside 

safety enforcement officers. 

2.3 HM cargo location 

tracking by the dispatcher. 

2.4 HM cargo route adherence 

by the dispatcher and roadside 

safety enforcement officers, as 

required based on the quantity 

and type of HM being 

transported. 

2.5 Untethered trailer 

notification and tracking by 

the dispatcher. 

2.6 HM cargo tampering alert 

to the driver and the 

dispatcher. 



2.8 Real-time emergency alert 

message notification by the 

driver to the dispatcher. 

V-13,V-17,V-20, V-25, V-26 

V-12,V-17,V-20 

V-12,V-17,V-21 

V-13,V-15,V-17,V-23 

V-13, V-15, V-17, V-23, V-24 

V-12, V-17, V-21, V-23, V-26 

V-12, V-17, V-21, V-23, V-26 

V-10,V-15,V-17,V-20,V-23, V- 

25, V26 

V-17, V-23 

V-15, V-17, V-23, V-24 

V-13, V-15, V-17, V-23, V-25, 

V26 

V-13, V-15, V-17, V-23, V-24 

V-17, V-23 

F-18





Action Stages 

HazMat Delivery to Receiver. 

Functional Requirement 

Items/Description 

2.9 Real-time emergency alert 

message notification by the 

vehicle after the vehicle is 

involved in a crash 9 . 

2.10 Real-time emergency 

alert messages notification by 

the vehicle to the dispatcher if 

vehicle senses an unauthorized 

driver. 

2.11 Real-time emergency 

alert message notification by 

the dispatcher to local and 

state law enforcement officials 

and emergency responders. 

2.12 Remote HM vehicle 

disabling by the driver. 

2.13 Remote HM vehicle 

disabling by the dispatcher. 


and verification by the vehicle 

if the vehicle is motionless for 

10 minutes. 





receiver. 

3.3 HM cargo verification by 

the receiver. 

3.4 Receiver confirmation of 

received cargo to the driver 

and dispatcher. 

3.5 Auditable log of all 

shipments to be kept by the 

motor carrier. 

Vulnerability Addressed 

None 

V-12, V-17, V-21, V-23 

V-17, V-23 

V-15, V-17, V-23 

V-15, V-17, V-23 

V-12, V-17, V-21, V-23 

V-13, V-15, V-17, V-23, V-24 

V-12, V-17, V-20, V-21 

V-10, V-13, V-17, V-20, V-25, 

V26 

V-10, V-13, V-17, V-25, V26 

None 

9 

Functional requirement 2.9 was proposed in the original SOW; it is not going to be included in the 

FOT scenarios. 

F-19





SOW 

No. 

Table 18 – Vulnerability Definitions 

V-1 High Population nearby 

V-2 Traffic Congestion 

V-3 Large on-site HazMat quantities 

V-4 Access to critical infrastructure 

Vulnerabilities 

V-5 Frequent stops at traffic control devices 

V-6 Slow speeds passing target areas 

V-7 Unknown shipper/consignee (illegal purposes) 

V-8 Carrier employees redirecting en-route bulk shipments 

V-9 Truck Queuing 

V-10 Lack of Delivery Notification 

V-11 Predictable scheduled shipments 

V-12 Limited driver verification 

V-13 Limited load verification 

V-14 No depart/load verification on shipments 

V-15 Unattended loaded HazMat (trailer) 

V-16 Uncontrolled accumulation of inbound inventory 

V-17 Uncontrolled outbound waste shipments 

V-18 Deliveries left in unsecured location 

V-19 No consignee present at delivery 

Technologies to be tested include wireless satellite and terrestrial communications with GPS, electronic 

cargo seals, electronic supply chain manifests, biometric systems and automated login for driver 

authentication, panic buttons, routing and geo-fenced mapping software, and untethered trailer tracking. 

The FOT is on going and scheduled for completion in 2005. 

F.3.5 ITDS 10 

Trade participants (traders) are required to submit information to appropriate trade agencies for both 

imports and exports. The purpose of this is to enable agencies to determine, for example, the legal 

admissibility of imported merchandise, the duty applicable to imported merchandise, the safe or unsafe 

condition of a truck intended to be used on U.S. highways, or whether food products are safe for 

consumption. At present, this information is provided to individual agencies using automated systems, 

paper forms, or a combination of systems and forms. The United Nations Conference on Trade and 

Development (UNCTAD) has estimated that submission of redundant information and preparation of 

documentation is equal to 4 - 6% of the cost of the merchandise. 

The ITDS will enable traders to submit standard electronic data for imports or exports to the ITDS, which 

will in turn distribute this standard data to the federal agencies that have an interest in the transaction. The 

10 

Source - http://www.itds.treas.gov/itdsovr.html#ITDS 

F-20





ITDS will provide each agency with only that information relevant to its mission and reduce or eliminate 

existing requirements for traders to submit the same information to multiple federal agencies. The ITDS 

system will support the processes of multiple agencies, including data collection, processing, use, 

dissemination, and storage. In addition to assisting federal government agencies in the processing of 

import and export transactions, ITDS will provide the framework to collect information on behalf of those 

agencies and will enable Customs to more effectively assist them in enforcing laws and regulations relating 

to international trade. 

The ITDS is being developed in conjunction with the Customs Automated Commercial Environment 

system (ACE). 11 

In December 2001, the ITDS Board established the following high-level requirements for the ITDS 

system: 12 

DESIGN 

1. All functionality of the ITDS pilot should be in the first increment of ACE implementation. 

2. All transaction types should be merged into one front end system with data made available 

simultaneously to all participating agencies based upon their legal right to have such information. 

3. The ITDS-ACE shall perform an integrated risk assessment process on behalf of each participating 

agency if required by that agency. 

4. Customs and each participating agency must establish suitable communications capability –equipment, 

protocols, MOUs, etc.-- to process ITDS-ACE transmitted transactions between the system and each 

participating agency. 

5. In the short term, the preferred method of arrival notification for ITDS-ACE truck shipments will be 

Dedicated Short-Range Communications (DSRC) equipment. DSRC equipment shall read the 

transponder identification numbers of participating commercial vehicles entering the compound. The 

DSRC system shall transmit the transponder identification numbers to the ITDS-ACE system as reads 

occur. Bar code readers will be the primary backup method of arrival notification. 

DATA 

1. Within the system, there can be logical groupings for transactions having pre-approval to provide 

various levels of minimal data upon entry (such for as low-risk repetitive shipments) 

2. ITDS-ACE will support agency specific OMB approved data requirements to accommodate either 

integrated or interfaced risk assessment processes. 

3. The ITDS-ACE system should provide the trade with importing and exporting requirements. Initially, 

this will be provided via a Website by commodity with links to specific information (licenses, visas, 

health certificates, etc.), to be provided by participating agencies. In the future, the ITDS-ACE project 

office will explore the possibility of such information being provided in detail by the agencies and then 

11 

12 

The Automated Commercial Environment will provide Customs with an integrated, fully automated 

information system that will enable the collection, processing and analysis of commercial import and 

export data. See - 

http://www.customs.ustreas.gov/xp/cgov/toolbox/about/modernization/ace/ace_fact_sheet.xml 

Source - http://www.itds.treas.gov/ITDSHighRequireDec6.htm 

F-21





pulled automatically by HTS item number, and agency product code if needed, either within the 

system itself or via an interactive Website. 

4. Data elements from the ITDS Standard Data Set must be collected via the ITDS-ACE system, as 

defined in the agency-specific data requirements addendum or grid, for all information collections 

approved by OMB and required by the agencies. 

5. The ITDS-ACE project office will provide each participating agency with identifying information for 

carriers, drivers, manufacturers, etc. collected during the registration process. Each participating 

agency will provide data to the ITDS-ACE project office to perform the requisite risk assessments (if 

the agency is choosing the integrated risk assessments approach) or will provide the outcome of their 

internal risk assessment back to the ITDS-ACE system (if the agency is choosing the interfaced 

approach). 

6. The ITDS-ACE system will populate an ID reference table with the information collected at 

registration. 

7. For DOT agencies, the required registration field information will be needed to participate in ITDS. 

The registrants will be screened to verify carriers’ compliance with appropriate requirements. 

8. The ITDS-ACE system shall convert DUNS numbers to agency specific numbers as needed. 

9. The ITDS-ACE system will collect transportation identifiers and supporting information as part of the 

declarations (i.e. transportation, goods) that the trade community generates and submits. 

MANAGEMENT AND SECURITY 

1. Development and maintenance of the ITDS-ACE infrastructure shall be provided by USCS on behalf 

of the ITDS-ACE Board of Directors. 

2. Development of core functionality is a USCS responsibility. 

3. The ITDS-ACE system must conform to all appropriate federal requirements regarding information 

security including, but not limited to, the following: OMB Circular No. A-130—Management of 

Federal Information Resources (which references The Privacy Act) 

• OMB Memorandum M-97-16—Information Technology Architectures 

• SED 23 (Rev 2.0), Section 2.2.3 Security 

• SED 22IVI, Section 3—Technical Reference Model 

• TD 84-1—Treasury Security Manual. 

4. At a minimum, the ITDS-ACE project office and each agency shall conform to an agreed upon policy 

regarding data communication security. Reasonable efforts will be undertaken to protect the system 

and databases from unauthorised access. 

5. Agencies shall ensure that only authorised personnel are provided ITDS-ACE system access, subject to 

the agreed upon security policy. 

F-22





6. Agencies shall provide the ITDS-ACE project office a list of personnel authorised for access and 

maintenance of agency-specific files. 

7. out the actions which Customs and agency personnel will be required to take for each risk assessment 

factor. For example, if a driver does not have a valid CDL or a shipment contains a product not precleared 

as low risk by the FDA-- what actions Customs and agency personnel should take. The 

possible risk assessment results should be listed in a table along with their definitions and actions. A 

sample follows: 

OPERATIONAL 

1. The ITDS-ACE system should be available to all importers, carriers, brokers, and other parties to a 

trade transaction. 

2. The ITDS-ACE system must provide agency-specific access to review data and to initiate 

administrative and enforcement actions. 

3. The combined system must provide agencies with secure, controlled access to the ITDS-ACE database 

and data listing to verify completeness, accuracy, and sufficiency of data for agency-specific use and 

allowing agency-specific access only to that data for which the agency has the statutory right to 

review. 

4. Where applicable, definition of each agency's risk assessment and communication requirements is an 

agency responsibility as is providing updates of such material. 

5. The ITDS-ACE project office shall be responsible for establishing and maintaining communications 

links with the port facilities. 

6. The ITDS-ACE system shall perform an integrated risk assessment process on behalf of each 

participating agency if requested by that agency. 

7. The ITDS-ACE system shall store the pre-arrival transportation screening results. 

8. The ITDS-ACE system shall display the pre-arrival screening results as part of the primary inspector’s 

computer generated display. 

9. The USCS primary inspector shall communicate the agency clearance instructions to the driver as 

described by each agency. 

F.3.6 C-TPAT (Customs and Trade Partnerships Against Terrorism) 

US importers and their supply chain partners should be particularly aware that, of these key initiatives, the 

C-TPAT program (Customs-Trade Partnership Against Terrorism) already has begun to significantly 

impact the US import trade. Membership in C-TPAT requires the full visibility of a participant's and their 

partners' supply chain security measures. The program asks participants to assess their international supply 

chains, develop a security improvement plan if necessary, strengthen security where weaknesses appear, 

establish policies regarding security practices, communicate policies and security requirements to their 

international supply chain partners, and monitor and improve security of their supply chains on an ongoing 

basis. 

U.S. Customs has been actively approaching companies to become C-TPAT members since the program's 

launch in April 2002. C-TPAT is broad and pervasive, with membership open not only to importers, but 

also to virtually the entire supply chain. As of mid-September 2002 more than 500 companies have joined 

F-23





the program, by the end of November the number was at over 1100, with the number of participating 

companies increasing daily. 

While U.S. Customs has publicly recognised that C-TPAT must be flexible enough to suit a participant's 

specific security needs and can't be cost-prohibitive, how much Customs will require importers to increase 

security measures currently remains unclear. Customs may impose strict guidelines that increase security 

measures over what may already be in place, a development that will inherently increase costs. C-TPAT 

participants will need to find a cost-effective way to protect business interests while satisfying border 

security interests. 

C-TPAT members will encounter fewer cargo inspections at the border, be assigned an account manager 

serving as a direct point of contact with Customs, enjoy a self-policing relationship, have access to the C- 

TPAT membership list, and be eligible for account-based processes through the Automated Commercial 

Environment portal. Also, "low risk" importers can obtain the expansion of "low risk" treatment to all 

divisions within the company and receive immediate entitlement to benefits. All participants will also be 

eligible for the expedited movement of goods across the U.S.-Canada border under the FAST program. 

F.4 Summary and recommendations 

In sum, the evolving nature of border crossing and security programs is such that identifying ITS/CVO 

solutions and applications is not feasible at this time. SAIC recommends that Canada instead continue to 

monitor the progress of those programs currently on-going and participate, as feasible, in the discussions 

designed at resolving institutional issues. SAIC believes that this approach will offer the following benefits 

to Canada: 

• Waiting for the various border and security initiatives to be fully deployed and implemented will 

enable Canada (and the national ITS/CVO network) to interface with mature systems rather than 

systems being deployed as pilots or field operational tests. This will help ensure that the development 

work needed to establish these interfaces would not have to be changed or modified substantially as 

these systems are being established as production systems. 

• As these border crossing and security initiatives are deployed, data requirements (type of data, 

authoritative source) and data exchange procedures will be tested and established. Having these 

established would also help reduce development costs for Canada – in addition, Canada would also be 

able to identify COTS solutions that could help reduce development and deployment costs. 

• The ITS/CVO network proposed for Canada is recommended for development using open standards 

and interoperable systems. This approach would provide Canada with the needed flexibility to 

interface with a wide variety and type of systems and technologies. The border and security initiatives 

are being developed using existing standards, operating protocols, and industry accepted software and 

systems engineering practices. Waiting until these are deployed, as operating systems will enable 

Canada to plan for interfaces within established industry standards and practices, again reducing 

development costs and deployment costs. 

• As important as technology related issues are, an additional benefit of delayed deployment is that the 

institutional issues involved with the border crossing and security initiatives will be further resolved. 

Knowing who will be managing these programs, and how, is as important as knowing what 

technologies and systems are being utilised – in particular for identifying how to resolve any issues 

that arise between the United States and Canada on such matters as data requirements, data 

availability, privacy concerns, enforcement, and other related topics. 

F-24





The reasons for this finding include: 

• Institutional Issues – US Customs and the Immigration Naturalization Service are the two agencies 

leading most border crossing initiatives. The US Department of Transportation is a participant, but the 

missions of the involved agencies are very different. US DOT places significant emphasis on mobility 

and highway safety, which are not the primary program areas of Customs and INS. While a number of 

initiatives are underway that attempt to combine these differing missions (i.e., the Blaine Border 

Crossing Project between Washington State and British Columbia) and address the needs of all 

involved agencies, there is not a complete resolution of institutional issues and differing missions. 

• Creation of Transportation Security Administration – Institutional issues are also complicated by the 

creation of the Transportation Security Administration. TSA has been charged to lead all 

transportation related security efforts, but is a new agency and is dealing with the various issues 

involved with establishing a new agency. FHWA and FMCSA have been involved in security issues, 

but agency responsibilities in this area are changing and have not yet been finalised. 

• Technology Deployments – While many of the deployments at border crossings are using ITS, actual 

ITS/CVO applications are limited. An example of this is the FAST deployment at the Peace Bridge. 

Initial deployment plans considered the use of technologies interoperable with other CVO applications. 

However, the deployment is now moving ahead with a different technology not interoperable with 

ITS/CVO. An additional consideration is that some potential technology deployments are still being 

tested. An example of this is the HazMat Field Operations Test currently being conducted by FMCSA 

– while this FOT is testing a variety of technologies related to security, the project is still one to two 

years from completion and the technologies being tested have not yet been mainstreamed as ITS/CVO 

applications. 

• Information Requirements and Proposed Programs – While many initiatives related to security and 

border crossings have been identified; the programs implementing these initiatives are still being 

developed. An example of this is the proposed background check for HazMat drivers – while this 

program has been under discussion for sometime, it is only now being implemented. Key issues that 

need to be reviewed with this implementation include: 

o 

o 

o 

What information will be required to complete this check 

What is the authoritative source for this information 

How will this information be accessed 

• Potential ITS/CVO Applications – At present, until program requirements and institutional issues are 

further developed, it is difficult to identify potential ITS/CVO applications. The type of safety and 

credentials data that could be provided by ITS/CVO applications does not appear to meet the 

requirements of other agencies involved in border crossing and security issues. In addition, while 

some ITS/CVO technologies may be applicable (DSRC standards, transponder applications) a wide 

variety of technologies and applications are being tested and the final applications have not been 

established. 

References 

1. HazMat Transport News, Volume 1 Number 306, p. 1721. March 21, 2003 

2. Wik, Erik, Jensen, Mark, Science Applications International Corporation, “Washington State – British 

Columbia International Mobility and Trade Corridor (IMTC) Commercial Vehicle Border Crossing 

ITS Deployment. Part A – Evaluation Plan Part B – Detailed Test Plans”. Prepared for FHWA 

Contract DTFH61-96-C-00098; SAIC 9827 

F-25





3. International Mobility and Trade Corridor Project News, Volume 3, Issue 1, March 2002 and Volume 

3, Issue 2, October 2002 

4. Rojas, Martin, American Trucking Associations, “Statement of the ATA – U.S. Treasury Advisory 

Committee o the Commercial Operations of the United States Customs Service: Subcommittee on U.S. 

Border Security Technical Advisory Group and Customs Trade Partnership Against Terrorism”, June 

14, 2002 

5. ATA Truckline, “New HazMat Background Check Rule Now In Effect”, May 6, 2003 

6. Booz-Allen & Hamilton, “Ambassador Bridge Border Crossing System (ABBCS) Field Operations 

Test – Final Evaluation Report”, May 2000. 

7. Booz-Allen & Hamilton, “International Border Electronic Clearance (IBEX) Document 9890.IBEX.01 

– Final Evaluation Report”, July 1998. 

8. SAIC, “Hazardous Material Transportation Safety and Security Field Operational Test Final 

Evaluation Plan” Contract DTFH61-96-C-00098 Task 9851, March 2003. 

9. http://www.itds.treas.gov/index.html 

10. www.customs.gov 

11. U.S./Canada Border Highway Carriers/Free and Secure Trade program (FAST) C-TPAT Agreement to 

Voluntarily Participate 

12. U.S./Canada Border Highway Carriers/Free and Secure Trade program (FAST) C-TPAT Supply Chain 

Security Profile Questionnaire* 

13. U.S./Canada Border Highway Carriers/Free and Secure Trade (FAST) Program Application (PDF) 

14. http://www.wccog.org/imtc/imtcbriefing.html. 

15. http://www.customs.ustreas.gov/xp/cgov/toolbox/about/modernization/ace/ace_fact_sheet.xml 

F-26

Technical Feasibility Study for the Development of an ITS ...

Create successful ePaper yourself

Delete template?

Save as template?