**2008-09 Closed Architecture CRs**

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           5032

  **External               SAFER CR 1716
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Add Target Indicator to the T0028 transaction

  **Status:**              Closed Approved

  **Disposition:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.

  **Description:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.\
                           \
                           \[2007-07-26\] Not voted on. Approved by FMCSA for SAFER
                           7.3.\
                           \
                           \[2007-05-18\] Presented at 2007-05-17 CVISN ACCB
                           meeting.\
                           \
                           \[2007-05-03\] During the CVISN Deployment Workshop in
                           March 2007, the stakeholders requested the addition of the
                           PRISM Target Indicator to the T0028 transaction.\
                           \
                           T0028 transaction currently extracts all data uploaded
                           from the XML input files. Data uploaded via the PRISM
                           Vehicle File (PVF) are currently not part of the T0028
                           transaction. Therefore, states implementing CVISN and
                           PRISM may need to download two sets of vehicle
                           registration files. This change would allow users to
                           receive all key information via the T0028 transaction.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       9/21/2007 8:13:07 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          5/3/2007 5:19:18 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/21/2007 8:13:07 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           5031

  **External               SAFER CR 1697
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/SAFETYNET/ASPEN

  **Synopsis:**            Modify T0018 Inspection Report Input Transaction to accept
                           new values from Level VI inspections

  **Status:**              Closed Approved

  **Disposition:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.

  **Description:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.\
                           \
                           \[2007-07-26\] Not voted on since already approved for
                           SAFER 7.3.\
                           \
                           \[2007-05-17\] Presented and discussed at the 5/17/07 ACCB
                           meeting. Post for review and vote on 6/21.\
                           \
                           \[2006-11-01\] Current implementation of the Level VI
                           inspection data capture and reporting is flawed.
                           Enhancements will enable better data quality and easier
                           recording. Effects Aspen, SAFETYNET, MCMIS, and the SAFER
                           web services. Database changes will be required.\
                           This enhancement is requested by the CVSA RAM Subcommittee
                           and has the full support of the FMCSA HM Division.\
                           \
                           \[2007-05-03\] Volpe reported that ASPEN and SAFETYNET
                           users are impacted by this CR.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       9/21/2007 8:09:05 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          5/3/2007 5:12:18 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/21/2007 8:09:05 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           5030

  **External               SAFER CR 1695
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/SAFETYNET/ASPEN

  **Synopsis:**            Modify T0018 Inspection Report Input Transaction to allow
                           for PASA value

  **Status:**              Closed Approved

  **Disposition:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.

  **Description:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.\
                           \
                           \[2007-07-26\] Not voted on since already approved for
                           SAFER 7.3.\
                           \
                           \[2007-05-17\] Presented and discussed at the 5/17/07 ACCB
                           meeting. Post for review and vote on 6/21.\
                           \
                           \[2007-05-03\] Volpe reported that ASPEN and SAFETYNET
                           users are impacted by this CR.\
                           \
                           \[2007-04-24\] Modify the SAFER Inspection Upload XML
                           Schema to allow for an indicator to show an inspection was
                           conducted in conjunction with a Pre-Authority Safety
                           Audit.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       9/21/2007 8:07:33 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          5/3/2007 5:07:31 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/21/2007 8:07:33 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           5007

  **External               WA, Proactive Data Quality focus group, SCR 1841
  Reference:**             

  **Category:**            Proactive Data Quality Monitoring

  **Component:**           SAFER/MCMIS

  **Synopsis:**            T0031 Data Timeliness Monitoring

  **Status:**              Closed Approved

  **Disposition:**         \[2008-05-03\] Closed. Verified by B. Goforth.

  **Description:**         \[2008-05-03\] Closed. Verified by B. Goforth.\
                           \
                           \[2008-04-21\] At 2008-04-17 ACCB meeting, Volpe announced that SCR 1841 T0031 Timeliness Monitoring has been implemented.\
                           \
                           \[2007-07-26\] Discussed at ACCB meeting. IT Systems Change Request has been submitted. Telecon will be held in next two weeks.\
                           \
                           \[2007-05-18\] At 2007-05-17 CVISN ACCB meeting, it was noted that this CR needs to go via FMCSA to MCMIS team for preliminary analysis and estimate.\
                           \
                           \[2007-04-19\] submitted by Bill Goforth, WA, 360-705-7365, gofortb@wsdot.wa.gov\
                           discussed at CVISN ACCB meeting 2007-04-19\
                           \
                           Greater visibility is needed to monitor data timeliness for the T0031 (carrier data) transactions.\
                           \
                           There are on-going problems with timeliness of T0031 carrier updates from SAFER. Delays of 3 or more weeks have been seen in some cases. The extent of this issue is not clear and there
                           appear to be a number of causes for T0031 data timeliness problems.\
                           \
                           There are known problems with data timeliness in the following areas:\
                           - receiving new carrier data\
                           - MCS150 updates\
                           - MCMIS status changes\
                           - ISS scores and SAFERSTAT data changes\
                           - MCSIP Level changes\
                           \
                           The improvements proposed by this change request will greatly enhance visibility of the frequency and magnitude of T0031 (carrier) data quality and timeliness problems. They will also
                           allow CVISN states to easily determine if their carrier data problems are a SAFER issue or a local CVIEW issue. This visibility will reduce support costs and help Volpe management and the
                           CVISN states better manage their CVISN support resources.\
                           \
                           This change request proposes the following improvements:\
                           \
                           1. Establish performance objectives and create and monitoring processes to monitor the timeliness of T0031 data. Specifically this includes; clear performance objectives, measurement
                           strategies, daily exception reports and monthly summary/trend reports to monitor processing delay times for MCSIP level, ISS score, MCMIS status, added carriers, and critical MCS150
                           changes required by PRISM (including carrier name and address changes).\
                           The goal is to have processing delays be 24 hours or less on business days. With this goal in mind, measurement objectives and strategies are needed for each of the mentioned data elements
                           that are realistic and reflect existing processing limitations. CVISN stakeholders need to agree on these measurement objectives. For example, a measurement objective for ISS score changes
                           might be to have all A&I changes to be delivered in T0031 files within 6 business days (allowing for A&I data quality checking time) and all non-sufficient data ISS changes in SAFER
                           delivered in T0031 files within 1 business day. The specifics regarding these objectives cannot be refined without practical input from the MCMIS and SAFER support teams.\
                           A related secondary objective will be to log all incidents where a performance objective is not met so that it will be possible to track the frequency of a particular performance related
                           problem.\
                           \
                           2. Capture tracking data for all T0031 UD and BL download files and related subscription files. T0031 Tracking data will be stored in table form and consist of one row per update per
                           carrier. Each row would contain the T0031 download file name and (at a minimum) the critical T0031 data elements consistent with item 3. below.\
                           A web page will be provided to allow CVISN states to view the T0031 tracking data for a specific USDOT number.\
                           \
                           3. Create a MCMIS control file. This file will be a tab separated variable text file (TSV file or equivalent) and will contain one record per carrier. The proposed control file will be
                           created daily. The control file will consist of the following MCMIS data elements (associated SAFER data element names are used here for sake of clarity):\
                           CARRIER_ID_NUMBER\
                           CARRIER_NAME\
                           TAX_ID_NUMBER\
                           DATE_ADDED\
                           MCMIS_STATUS\
                           MCMIS_STATUS_DATE\
                           MCSIP_LEVEL\
                           MCSIP_LEVEL_DATE\
                           MCMIS_TRANSACTION_DATE\
                           MCS150_UPDATE_DATE\
                           ISS_SCORE\
                           ISS_SCORE_DATE\
                           SAFESTAT_CATEGORY\
                           SAFESTAT_DATE\
                           SAFETY_RATING\
                           RATING_DATE\
                           \
                           Because this control file will be used to measure the effectiveness of the MCMIS/SAFER interface, it must be created independently of the MCMIS/SAFER interface.\
                           \
                           Tests where the above data elements are dumped to a text file from the CVIEW CARRIER table indicate that the proposed control file will be 39 to 40 MB after being zipped. In these tests,
                           it took less than 5 minutes to create this file. But this may not be reflective of the time taken to do this in MCMIS if there are multiple tables that contain this information.\
                           \
                           It is hoped that there will be a minimum impact to MCMIS to create this control file. Testing will need to be performed by the MCMIS support team to determine the impact of creating this
                           file.\
                           The proposed MCMIS control file is key to the success of this change request. The data in this control file will be used to:\
                           \
                           1. Allow more proactive T0031 data quality management - Volpe and CVISN states will be able to proactively monitor data quality and take corrective action when necessary. In other words,
                           data timeliness problems could be identified and fixed without CVISN states having to report the problems to Volpe Technical Support. This will save considerable time for technicians at
                           Volpe and for technicians in the CVISN states.\
                           \
                           2. Quickly isolate timeliness and missing data issues as either Volpe or a CVISN state (CVIEW) issue - Using the control file and the T0031 tracking data (2. above), it will be possible
                           for a CVISN state or Volpe to quickly determine the extent of a timeliness problem and whether the problem was at Volpe or on the CVISN state side. If the carrier data in question has been
                           output to a T0031 file, it will be possible to easily identify which T0031 file it is contained in by looking at the T0031 tracking data.\
                           \
                           3. Monitoring of T0031 Timeliness trends - Using the control file and the T0031 tracking data (2. above), it will be possible to write simple SQL scripts to determine how many carrier
                           updates failed to meet the 24 hour timeliness objective. Timeliness analysis will be performed separately for each of the above mentioned data elements. This will be done on a monthly
                           basis and used as a high level management tool to determine the priority and extent of carrier data timeliness issues.\
                           \
                           4. Check CVIEW Carrier data accuracy and avoid unnecessary T0031 baseline downloads - The control file will allow CVISN states to verify the accuracy and completeness of their local CVIEW
                           carrier data and determine when it is necessary to perform a T0031 baseline download. This allows CVISN states to do a better job of keeping their carrier data in synch with SAFER and
                           avoid unnecessary T0031 baseline downloads.\
                           \
                           5. Emergency fixes - The control file can be used by a CVISN state as an interim emergency workaround to update critical CVIEW carrier data while T0031 timeliness issues are being
                           addressed. This would help to prevent crisis situations for Volpe and CVISN states when critical T0031 data is missing. It is recognized that there would be inherent data synchronization
                           problems in using this file as a data source. Whether the advantages outweighed the risks is a question that a CVISN state would need to carefully consider before using the control file in
                           this way.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact Summary:\
                           SAFER\
                           MCMIS (minimal?)\
                           States may choose to use or not

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       6/20/2008 10:23:37 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          4/19/2007 5:01:06 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           6/20/2008 10:23:37 AM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4988

  **External               SAFER CR 1173
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/SAFETYNET/ASPEN

  **Synopsis:**            T0018 Inspection Report Input Transaction must be updated
                           to support special characters.

  **Status:**              Closed Fixed

  **Disposition:**         \[2007-04-19\] Closed. Deployed.

  **Description:**         Users are able to upload inspections without a properly
                           formatted inspection report number.\
                           Aspen needs to test to ensure that the report number is 12
                           Characters long.\
                           The SAFER Inspection Web Service should reject inspections
                           where the report number is not 12 characters long.\
                           \
                           \[2007-04-19\] Presented and discussed at the 4/19/07 ACCB
                           meeting.\
                           More information is needed from Volpe as to whether there
                           is impact on states.\
                           \
                           \[2007-05-03\] Volpe reported that ASPEN and SAFETYNET
                           users are impacted by this CR. It was implemented in SAFER
                           5.2 April 2007.\
                           \
                           \[2007-05-17\] Presented and discussed at the 5/17/07 ACCB
                           meeting. Voting is NA since already implemented.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       5/17/2007 5:30:02 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          4/6/2007 4:35:54 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/3/2007 4:49:55 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4987

  **External               SAFER CR 1172
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/SAFETYNET/ASPEN

  **Synopsis:**            T0018 Inspection Report Input Transaction must be updated
                           to check for valid Report Number.

  **Status:**              Closed Fixed

  **Disposition:**         \[2007-04-19\] Closed. Deployed.

  **Description:**         The SAFER Inspection Web Service should reject inspection
                           reports without a properly formatted inspection report
                           number. The report number must be 12 characters long.\
                           \
                           This change will require versioning of the T0018
                           transaction.\
                           \
                           \[2007-04-19\] Presented and discussed at the 4/19/07 ACCB
                           meeting.\
                           More information is needed from Volpe as to whether there
                           is impact on states.\
                           \
                           \[2007-05-03\] Volpe reported that ASPEN and SAFETYNET
                           users are impacted by this CR. It was implemented in SAFER
                           5.2 April 2007.\
                           \
                           \[2007-05-17\] Presented and discussed at the 5/17/07 ACCB
                           meeting. Voting is NA since already implemented.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       5/17/2007 5:29:47 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          4/6/2007 4:34:48 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/3/2007 4:50:20 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4966

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Add new architecture flow CVS-to-CVCS to report
                           "commercial vehicle disable status"

  **Status:**              Closed Approved

  **Disposition:**         \[2007-05-17\] Closed. Incorporated into National ITS
                           Architecture.

  **Description:**         \[2007-05-17\] Closed. Incorporated into National ITS
                           Architecture.\
                           \
                           \[2007-05-17\] Approved by FMCSA.\
                           \
                           \[2007-04-19\] Recommended for approval at the 4/19/07
                           ACCB meeting.\
                           \
                           \[2007-03-16\] Presented at the 3/15/07 ACCB meeting.\
                           This CR does not have an impact on CVISN states at this
                           time. The CR will be posted to the CVISN System
                           Architect's list serv for 30-day review.\
                           \
                           \[2007-03-12\] There is an architecture flow named
                           \"commercial vehicle disable\" that enables the Fleet and
                           Freight Management Subsystem (FMS) to disable the
                           Commercial Vehicle Subsystem (CVS) of a particular
                           vehicle. Via a recent change request (CR 4778), the flow
                           was added to the interface from the CVS to Commercial
                           Vehicle Check Subsystem (CVCS). The motivation for adding
                           the flow from CVS to CVCS was to alert the CVCS staff that
                           the disable flag had been sent to the vehicle. The
                           definition for the flow is \"This flow safely disables a
                           specific commercial vehicle,\" which looks odd going from
                           the CVS to the CVCS. For this reason, we propose replacing
                           "commercial vehicle disable" from CVS to CVCS with a new
                           flow named \"commercial vehicle disable status.\" The new
                           flow would be defined as \"This flow provides the status
                           of the disable flag in the commercial vehicle.\" The
                           "commercial vehicle disable" architecture flow would
                           continue to be used as originally planned from the FMS to
                           CVS.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/21/2007 8:17:38 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          3/12/2007 8:33:15 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Low

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           9/21/2007 8:17:38 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4965

  **External               SAFER CR 1612
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVISN

  **Synopsis:**            Develop a new transaction for ISS scores

  **Status:**              Closed Disapproved

  **Disposition:**         \[2006-04-19\] Closed deleted.

  **Description:**         CVISN users have requested a separate output transaction
                           that would consist of at least the following data fields:\
                           \
                           DOT Number\
                           ISS Score\
                           ISS update date\
                           \
                           More data can be added to suit the user\'s need.\
                           \
                           The ISS data is currently part of the MCMIS transaction
                           (T0031). Each record consists of over 100 data elements.
                           Having a transaction specific to ISS data will help to
                           reduce the size of download and processing time.\
                           \
                           The ISS transaction will be developed in a way that will
                           help to improve the timeliness of the data to the end
                           users.\
                           \
                           \[2007-03-16\] Presented and discussed at the 3/15/07 ACCB
                           meeting.\
                           Chris Campbell said that this CR was written to help
                           address the problem experienced by WA with delayed receipt
                           of ISS scores. Chris suggested that SAFESTAT values be
                           included in this transaction as well, if they are in sync
                           with the ISS scores. Gary DeRusha noted that PRISM uses
                           the "target indicator" and "MCSIP Step" instead of the ISS
                           score to decide whom to inspect. He questioned why CVISN
                           states do not use the target indicator. Bill Guiffre asked
                           whether this new transaction was just a work-around for
                           the download speed problem and whether it would be needed
                           if the real problem was fixed. This CR will be posted to
                           the CVISN System Architect's list serv for comment from
                           other states, and the ISS issue will be addressed at the
                           CVISN Deployment Workshop.\
                           \
                           \[2007-04-19\] Presented and discussed at the 4/19/07 ACCB
                           meeting.\
                           This is a workaround for the ISS Score. It was created in
                           February when the MCMIS transfer had significant delays.
                           Since the focus is to get the data in a timely manner, if
                           SAFER CR 1613 to improve MCMIS processes is implemented,
                           this would resolve the issue with ISS data. CR was
                           withdrawn by WA.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       4/19/2007 5:03:48 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          3/8/2007 12:53:39 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           4/19/2007 5:03:48 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4948

  **External               WA
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVISN Architecture

  **Synopsis:**            T0023 E-Screening Enrollment Transaction is Ineffective

  **Status:**              Closed Disapproved

  **Disposition:**         \[2006-04-12\] Closed deleted.

  **Description:**         \[2007-02-23\] Bill Goforth, WA\
                           \
                           The T0023 transaction does not work in a context where
                           multiple states share e-screening administration
                           responsibility for the same carrier. An example would be a
                           carrier with a mid-west fleet and east coast fleet. The
                           state that sends the T0023 transaction for the east coast
                           fleet will override the T0023 transaction sent by a
                           mid-west state for the mid-west fleet. It may also be
                           necessary to control authorization on a vehicle by vehicle
                           basis. This is not possible with the current design of the
                           T0023 transaction.\
                           \
                           In addition, authorization for screening within a specific
                           state is the decision of that state not the jurisdiction
                           that sends the T0023 transaction for a group of states. So
                           it would seem that each state is the authoritative source
                           for its screening authorization. But there is no way for
                           individual states to submit a T0023 transaction for their
                           state only for a carrier without deleting the
                           authorizations for all other states for the carrier. (The
                           SAFER ICD says "The authorizations in the transaction
                           shall completely replace any existing authorizations
                           previously established for that carrier").\
                           \
                           When Washington uploads T0023 transactions, we authorize
                           all carriers to operate in all states. We have never had a
                           carrier request authorization for specific states and not
                           others. They have already found ways to disable their
                           transponders when they travel through states where they
                           don't want to use their transponders.\
                           \
                           For these reasons, we feel that the T0023 transaction is
                           either unnecessary or needs to be redesigned. Washington
                           would prefer to have this transaction done away with.\
                           \
                           \[2007-02-26\] Chris Campbell, Iteris, supporting ID, SC,
                           UT, WY, SD, OK, AK\
                           We also agree with this CR. It is a useless transaction
                           set for all of our clients.\
                           \
                           \[2007-03-16\] Presented and discussed at the 3/15/07 ACCB
                           meeting.\
                           WA and SD support this CR. Chris Campbell asked what the
                           impact would be on the T0029 delivery (would the T0029
                           sub-folder structure be eliminated?). This CR will be
                           posted to the CVISN System Architect's list serv for
                           comment from other states and will be addressed at the
                           CVISN Deployment Workshop.\
                           \
                           \[2007-04-12\] Per discussion at the Workshop and AI #99
                           assigned there, CR 4948 "T0023 E-Screening Transaction is
                           Ineffective" will be closed and WA will write a new CR for
                           the preferred option regarding T0023.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       4/12/2007 12:30:18 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          2/26/2007 5:37:55 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           4/12/2007 12:30:18 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4837

  **External               CR 4836; SAFER CR 536, SCR 1613
  Reference:**             

  **Category:**            New XML Web Services Transaction

  **Component:**           SAFER/CVISN

  **Synopsis:**            Request for new XML transaction to provide near real-time
                           OOSO changes to PRISM and CVISN users.

  **Status:**              Closed Approved

  **Disposition:**         \[2008-01-22\] Closed - released with SAFER 8.1

  **Description:**         \[2007-08-23\] Discussed at ACCB meeting. It was noted
                           that SCR 536 \"Improve timeliness of critical fields for
                           PRISM business processes\" is included in the scope of SCR
                           1613, scheduled for SAFER 7.3.1 October 2007 release.\
                           \
                           \[2007-07-26\] Discussed at ACCB meeting. SCR 536 is on
                           the list for SAFER 7.3, but may not be needed if SCR 1613
                           is implemented.\
                           \
                           \[2007-05-17\] Mentioned at 2007-05-17 CVISN ACCB meeting.
                           Scheduled for SAFER 7.3.\
                           \
                           \[2007-01-19\] Discussed at the 1/18/07 ACCB meeting.\
                           Gary DeRusha (Volpe) explained SAFER CR 536 and noted that
                           the PRISM program is embracing Web services technology. It
                           was noted that the corresponding ECCB RFC has been
                           approved. The SAFER part is on a schedule for development
                           this year, but a MCMIS commitment is still needed. Doug
                           Deckert (WA) noted that this near real-time OOSO change
                           information will be useful to CVISN roadside enforcement
                           as well as to PRISM users.\
                           \
                           \[2007-01-17\] Salazar (from SAFER CR 536)\
                           \
                           Architecture CR 4836/SAFER CR 536 proposes changes to
                           MCMIS and SAFER to make OOSO changes available to users
                           via SAFER in near real-time. That proposal involves
                           creating a new trigger in MCMIS that would notify SAFER
                           when a change is made to the out of service status of a
                           carrier by submitting a job into an asynchronous queue
                           maintained within Oracle. The job would contain
                           information that would be inserted into a new table within
                           SAFER indicating that a change had been made in MCMIS
                           since the last daily MCMIS to SAFER update routine.\
                           \
                           To minimize the impact on SAFER, the carrier table in
                           SAFER would not be updated as a result of the change in
                           MCMIS. Instead, the job submitted by the MCMIS trigger
                           would load the USDOT Number into a table created in SAFER
                           that contains the USDOT number, MCSIP Step and a timestamp
                           field. A trigger in SAFER would then retrieve the
                           carrier's MCSIP Step from MCMIS and update the current
                           timestamp.\
                           \
                           This CR requests that this information be made available
                           via a new SAFER Web Services transaction. That transaction
                           would check to see if a change had been made to the out of
                           service status of a carrier since the last daily MCMIS
                           update to SAFER and, if so, it would use the resulting
                           MCSIP Step value when returning carrier census data to the
                           user. If a change had not been made, all field values
                           would come from the SAFER carrier table.\
                           \
                           While these changes were originally proposed to support
                           PRISM users, this real-time information would also be
                           useful to roadside enforcement.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       1/22/2008 12:57:26 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          1/17/2007 10:33:53 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           1/22/2008 12:57:26 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4836

  **External               SAFER CR 536, SCR 1613
  Reference:**             

  **Category:**            MCMIS Update of OOSO activity to SAFER in Near Real-Time

  **Component:**           SAFER/MCMIS

  **Synopsis:**            Request for OOSO change to be made available to SAFER in
                           near real-time.

  **Status:**              Closed Approved

  **Disposition:**         \[2008-01-22\] Closed - released with SAFER 8.1

  **Description:**         \[2007-08-23\] Discussed at ACCB meeting. It was noted
                           that SCR 536 \"Improve timeliness of critical fields for
                           PRISM business processes\" is included in the scope of SCR
                           1613, scheduled for SAFER 7.3.1 October 2007 release.\
                           \
                           \[2007-07-26\] Discussed at ACCB meeting. SCR 536 is on
                           the list for SAFER 7.3, but may not be needed if SCR 1613
                           is implemented.\
                           \
                           \[2007-01-19\] Discussed at the 1/18/07 ACCB meeting.\
                           Gary DeRusha (Volpe) explained SAFER CR 536 and noted that
                           the PRISM program is embracing Web services technology. It
                           was noted that the corresponding ECCB RFC has been
                           approved. The SAFER part is on a schedule for development
                           this year, but a MCMIS commitment is still needed. Doug
                           Deckert (WA) noted that this near real-time OOSO change
                           information will be useful to CVISN roadside enforcement
                           as well as to PRISM users.\
                           \
                           \[2007-01-17\] Salazar (from SAFER CR 536)\
                           \
                           The FMCSA PRISM program utilizes the SAFER database to
                           provide its users with MCMIS carrier census data necessary
                           to comply with several PRISM program requirements. States
                           maintain a local version of this data by processing a
                           batch file after SAFER has been updated with a daily MCMIS
                           activity transaction file. Due to timing delays inherent
                           with these batch file updates, PRISM implementation
                           procedures require that users verify the out of service
                           status maintained in MCMIS if during processing the
                           carrier disputes the value of the data maintained locally.
                           Recently, PRISM has suggested that States utilize existing
                           SAFER Web Services as an alternative to using their local
                           systems to access the value of certain carrier census
                           data. However, this approach only addresses the timing and
                           logistical problems associated with getting the daily
                           transaction batch files from SAFER to the State users.
                           When necessary, on-line web browser access to MCMIS to
                           validate data values is still required due to the timing
                           differences between what is in SAFER and the actual value
                           maintained in MCMIS.\
                           \
                           To help resolve this problem, PRISM requests that a
                           trigger be built in MCMIS to monitor the OOS_Carrier table
                           that is updated whenever an out of service order is issued
                           or rescinded. The only function of this trigger would be
                           to notify SAFER in real time when a carrier has a change
                           made to its Out of Service Status. The notification would
                           be done by initiating a request to the Oracle Database
                           Management System job queue that would in turn pass that
                           USDOT Number to SAFER using an existing database link. A
                           trigger in SAFER would then retrieve the carrier's MCSIP
                           Step from MCMIS using an indexed key search through that
                           same database link. Together these enhancements should go
                           unnoticed by end users but they would allow subsequent
                           inquiries using a new SAFER web services transaction to
                           return the latest out of service status of the carrier in
                           near real-time mode. The PRISM team will work with SAFER
                           to specify the contents of this new transaction
                           separately.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    RFC MCMIS Update of OOSO Activity to SAFERv4.doc

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       1/22/2008 12:56:25 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          1/17/2007 10:19:08 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           1/22/2008 12:56:25 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4795

  **External               SAFER CR 1429
  Reference:**             

  **Category:**            XML subscription enhancement

  **Component:**           SAFER

  **Synopsis:**            States request a capability for a state to select to
                           receive the most recent record or all records for a given
                           VIN, via the subscription process.

  **Status:**              Closed Approved

  **Disposition:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.

  **Description:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.\
                           \
                           \[2007-07-26\] Not voted on. Approved by FMCSA for SAFER
                           7.3.\
                           \
                           Further discussion with the CVISN stakeholders has
                           determined that the subscription page shall provide the
                           following selections:\
                           1. Filter to receive the most recent record determined by
                           Last_Update_Date\
                           2. Filter to receive the most recent registration record
                           determined by the Registration_Start_Date.\
                           \
                           With the combination of using the IRP_Status_Code filter,
                           the user shall be able to select the most recent active
                           registration data.\
                           \
                           \[2007-05-17\] Update to SAFER 1429 analysis presented at
                           2007-05-17 CVISN ACCB meeting:\
                           \"There is an existing filter called \"Duplicates\" for
                           the T0028V2 transaction. Selection of \"Duplicates\" will
                           allow the state to receive all records. De-selecting this
                           option means the state will only receive one registration
                           record per VIN.\
                           \
                           The SAFER development team will need to analyze whether
                           the \"Duplicates\" filter can be enhanced to retrieve the
                           latest registration record. If not, a new filter will be
                           created to support the future business rule changes in the
                           T0022 transaction.\"\
                           \
                           \[2007-02-12\] Correction\
                           The discussion at the 1/18/07 ACCB meeting centered on the
                           meaning of "most recent record", \"most recent
                           registration record\", and on how states would use this
                           information.\
                           \
                           Gary DeRusha noted that this CR was meant to grandfather
                           the current behavior, i.e., provide that a state may
                           choose to receive only one registration record for a given
                           VIN and state. However, since the SAFER VIN table has been
                           restructured (SAFER Release 5.1), records are not
                           overwritten, and it is possible for more than one
                           registration record to exist for a given VIN and state.
                           This CR was intended to address multiple registration
                           records for a given VIN within a state.\
                           \
                           It was proposed that the REGISTRATION_START_DATE in the
                           SAFER VIN table be the field that determines the "most
                           recent registration record". It was also proposed that a
                           state be able to filter on any one of the following
                           options:\
                           a. Retrieve the most recent registration record for which
                           STATUS = "Active"\
                           b. Retrieve the most recent registration record regardless
                           of STATUS value\
                           c. Retrieve the most recent registration record for which
                           STATUS = "Active", but if no such record exists, then
                           retrieve the most recent registration record for which
                           STATUS = "Inactive"\
                           \
                           Users did not agree on the definition of \"most recent
                           record\". States were not in agreement what the rule
                           should be if there are registrations from more than one
                           jurisdiction. This discussion is still open.\
                           \
                           \[2007-01-18\] Discussed at the 1/18/07 ACCB meeting.\
                           APL and Volpe will reword the CR and repost to the
                           listserv for another 30-day comment period.\
                           \
                           \[2006-12-18\] Discussed at the 12/14/06 ACCB meeting.\
                           States on the call supported recommending for FMCSA
                           approval. Will be posted to the listserv for 30-day
                           review.\
                           \
                           \[2006-12-08\]\
                           Background:\
                           The SAFER subscription capability allows states to filter
                           on certain fields, thus restricting the data that they
                           receive. Subscription service currently exists for T0028
                           V2 (IRP Registration (Cab Card) Output Transaction) and
                           T0031 (MCMIS Safety & Census Update Output Transaction).\
                           \
                           With the SAFER 5.1 Release, the SAFER VIN table has been
                           restructured to prevent data from being overwritten. This
                           means the SAFER database may contain multiple records for
                           the same VIN.\
                           \
                           Change Request:\
                           At the November 2006 ACCB meeting, states requested that a
                           filter be implemented for all output transactions to give
                           states the option of receiving only the most recent
                           registration record for a given VIN or all registration
                           records for a given VIN. This will support SAFER CRs 50
                           and 1386 (Architecture CRs 2562 "Request to review SAFER
                           business rule regarding multiple VINs" and 4788 "Transfer
                           of Vehicle License Plate"). (NOTE: Architecture CR
                           2562/SAFER CR 1386 was disapproved 2006-12.)

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       9/21/2007 8:09:31 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          12/8/2006 1:31:11 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           9/21/2007 8:09:31 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4789

  **External               SAFER CR TBD
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER

  **Synopsis:**            Implement SAFER-CVIEW interface for Unified Carrier
                           Registration (UCR) information

  **Status:**              Closed Disapproved

  **Disposition:**         \[2008-01-17\] Disapproved by FMCSA.

  **Description:**         \[2008-01-15\] Volpe reported at CVISN ACCB meeting that
                           FMCSA has decided not to implement the requested FTP
                           interface. It is recommended that states use the Indiana
                           portal.\
                           \
                           \[2007-11-30\] Approved by J. Secrist.\
                           \
                           \[2007-11-29\] Recommended for FMCSA approval by vote of
                           16-0. An RFC will be submitted to HEAT via Jeff Secrist
                           and Janet Curtis.\
                           \
                           \[2007-10-22\] Discussed at 2007-10-18 ACCB meeting.\
                           \
                           Per the discussion at the ACCB meeting, this CR is hereby
                           updated to request the capability for CVISN states to
                           upload and download the UCR data using the XML / FTP
                           Interface with which CVISN stakeholders are familiar.\
                           \
                           The UCR data elements are:\
                           o UCR Registration Company US DOT Number\
                           o UCR Registration Company MC/MX Number\
                           o UCR Registration Company Freight Forwarder Number\
                           o UCR Registration Company MC/MX Tag\
                           o UCR Registration Intrastate Vehicles Indicator\
                           o UCR Registration Fee Payment Flag\
                           o UCR Registration Year\
                           o UCR Registration Update Date\
                           o UCR Registration Base State\
                           o UCR Registration Operating State\
                           \
                           To upload UCR data, states will need to develop Web
                           Service Client Software that invokes the FMCSA Upload Web
                           Service. Indiana has developed a client and is currently
                           testing with Volpe.\
                           \
                           \[2007-09-21\] Discussed at 2007-09-20 ACCB meeting.\
                           This architecture CR relates to new SAFER CR 1875:\
                           \
                           The State of Indiana requested a UCR output transaction
                           that will provide a carrier some of the MCS-150 data,
                           broker information and UCR data.\
                           \
                           Directed by the FMCSA, this output transaction will be
                           developed as high priority in addition to the September
                           release 2007 as a new phase of the UCR project.\
                           \
                           To be consistent with the first and second phases, this
                           output transaction will be developed using web services.\
                           Once implemented, a daily output file will be created to
                           capture the updates received by SAFER.\
                           \
                           The data elements and schema will be provided by Volpe at
                           a later date.\
                           \
                           This has been approved by FMCSA and is being implemented,
                           so will not be voted on by ACCB.\
                           \
                           \[2007-01-19\] Discussed at the 1/18/07 ACCB meeting.\
                           Jingfei Wu (Volpe) noted that the implementation of the
                           SAFER capability to upload UCR data from a state system is
                           ahead of schedule and waiting for a Texas team to have a
                           state system ready for beta testing. The draft high-level
                           system specification has been posted to the ACCB
                           Collaboration site for states to reference.\
                           \
                           \[2006-12-18\] Discussed at the 12/14/06 ACCB meeting.\
                           Volpe reported on a meeting that was held by FMCSA in the
                           first week of December. An extension on deploying the UCR
                           capability was not granted. Texas has volunteered to
                           deploy a state UCR system that will be made available for
                           other states to use. Eventually there will be one
                           centralized system. Volpe is finalizing the requirements
                           and beginning the design for changes to SAFER. There will
                           be a two-phase implementation.\
                           • Phase 1: By January, SAFER will have a component ready
                           for testing with a state UCR system. Volpe will publish
                           the XML schema and interface documentation.\
                           • Phase 2: By February-March timeframe, the Federal
                           applications (Query Central, ISS, and MCMIS) will have the
                           functionality to pull the UCR information from SAFER.\
                           States are waiting for the UCR Board to tell them what the
                           fees and the application are for UCR. There will not be a
                           UCR credential; the only way to check will be
                           electronically.\
                           \
                           \[Initial posting\]\
                           Summary:\
                           Unified Carrier Registration (UCR) is being established to
                           replace the Single State Registration System (SSRS). The
                           FMCSA program office has committed to the UCR board to
                           provide a capability to store the states' UCR registration
                           fee into a centralized application and to display the UCR
                           registration status to the roadside. The current
                           recommendation is to leverage SAFER\'s architecture to
                           store the UCR information and display to the roadside via
                           Query Central and ISS. According to the requirement, SAFER
                           needs to implement an input transaction using web service
                           technology to process the UCR data uploaded from states
                           and store it in the SAFER database.\
                           \
                           Volpe will need to provide interface control documentation
                           and to implement a certification process with states' UCR
                           systems.\
                           \
                           The next step will be for the staff to discuss
                           requirements with the UCR board. This is expected to
                           happen before the end of November 2006. It has not yet
                           been determined whether this change would involve a change
                           to an existing XML transaction or creation of a new
                           transaction type.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       1/22/2008 11:03:35 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          11/21/2006 11:46:17 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           1/22/2008 11:03:35 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4788

  **External               SAFER CR 1386
  Reference:**             

  **Category:**            SAFER/PRISM

  **Component:**           

  **Synopsis:**            Transfer of Vehicle License Plate

  **Status:**              Closed Disapproved

  **Disposition:**         \[2006-12-18\] Closed - disapproved.

  **Description:**         Summary:\
                           The business case is that a registrant transfers a license
                           plate from a vehicle (vehicle A) previously in their fleet
                           to a vehicle (vehicle B) that was not in SAFER already.
                           Currently, changes to the SAFER Vehicle Registration Table
                           differ, depending on whether the change was submitted via
                           the CVISN XML or the PRISM PVF method.\
                           \
                           When the transfer is made via the XML T0022 IRP
                           Registration (Cab Card) transaction, SAFER updates the
                           registration record for that plate by replacing the
                           vehicle A registration data with vehicle B data. Vehicle
                           A\'s registration data is no longer in any record.
                           Therefore, a query using state/license plate number will
                           return the one updated vehicle registration record that
                           shows vehicle B\'s data.\
                           \
                           When the transfer is made via the PVF method, a new
                           registration record for vehicle B with the new license
                           plate number is created. Thus, PRISM is able to access
                           both vehicle registration records.\
                           \
                           Proposal:\
                           The CVISN/PRISM subcommittee of the ACCB recommends that
                           SAFER be changed so that the processing for a license
                           plate transfer via an XML transaction is the same as the
                           processing for a transfer via PVF.\
                           \
                           Rationale:\
                           With the restructured SAFER tables and the anticipated
                           capability of requesting subscriptions based on last
                           update date, states will have the option of receiving both
                           records or just the most recent record. (A new CR will be
                           written to allow this selection via the subscription
                           process. This would support SAFER CRs 50 and 1386.) Many
                           states have said they want to see both records and let the
                           roadside folks figure out which one is current, while
                           other states say they only want to see the most recent.\
                           \
                           \[2006-12-18\] Discussed at 12/14/06 ACCB meeting.\
                           Volpe has determined that the current CVISN handling of
                           vehicle license plate transfer is correct and PRISM will
                           be changed. This CR is closed, disapproved.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       12/18/2006 8:48:58 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          11/21/2006 11:45:06 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           12/18/2006 8:48:58 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           4778

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Update CVISN Architecture to better address Expanded CVISN capabilities.

  **Status:**              Closed Approved

  **Disposition:**         \[2006-12-18\] Approved by J. Secrist.

  **Description:**         As part of the CVISN program, the Federal Motor Carrier Safety Administration (FMCSA) defined an initial set of capabilities that
                           could be deployed incrementally by a state and its motor carriers. Those "Core CVISN" capabilities focus on electronically exchanging
                           safety and credentialing information, electronically processing interstate registration and fuel tax credentials and filings, and
                           implementing transponder-based roadside electronic screening at one fixed or mobile site. The Expanded CVISN initiative builds on Core
                           CVISN to continue to enhance the safety, security and productivity of commercial vehicle operations and to improve access to and
                           quality of information about commercial vehicle operations for authorized public and private sector users. Through extensive outreach
                           in 2004, FMCSA engaged stakeholders to identify the capabilities necessary to achieve the goals of Expanded CVISN. This CR proposes
                           changes to the CVISN Architecture and the National ITS Architecture to better support Expanded CVISN capabilities.\
                           \
                           New Terminators:\
                           \* Driver Identification Card - This terminator represents the portable entity (e.g., a smart card) that enables the transfer of
                           electronic identification information about a driver. This may include license information, biometrics, and other data to identify the
                           driver.\
                           \
                           New Architecture Flows:\
                           \*cv driver credention - Driver information (e.g., identity, biometrics, address, date of birth, endorsements, restrictions) stored on
                           a driver's license or other official identification card used to identify a driver of commercial vehicles.\
                           \* cv repair status -- Information about the completion of a repair to a commercial vehicle.\
                           \* cv driver record -- Information typically maintained by a state driver licensing agency about a driver of a commercial vehicle
                           including driver identification data, license data, permit data, and driving history details.\
                           \* cv driver record request - A request for information about a commercial vehicle driver.\
                           \
                           Modified Subsystem description: Commercial Vehicle Check System (CVCS)\
                           \
                           Modified Equipment Package (EP) Name: CV Safety and Security Administration\
                           \
                           Modified EP descriptions: CV Information Exchange, CV Safety and Security Administration, Credentials and Taxes Administration, Fleet
                           Administration, Manage CV Driver Identification, Citation and Accident Electronic Recording, Roadside Safety and Security Inspection\
                           \
                           Added EP: In-Vehicle Signing System\
                           \
                           Modified architecture flow descriptions:\
                           \* safety status information -- Safety information such as safety ratings, security ratings or flags, inspection summaries, and
                           violation summaries. A unique identifier is included. Corresponds to the safety and security portion of CVISN \"snapshots.\" The
                           status information may be provided as a response to a real-time query or as a result of a standing request for updated information
                           (subscription). This may also include information about non-U.S. fleets for use by U.S. authorities, and information regarding U.S.
                           fleets made available to Mexican and Canadian authorities. The query flow is not explicitly shown.\
                           \* credentials information -- Response containing full vehicle fuel tax and registration credentials information. \"Response\" may be
                           provided in reaction to a real-time query or a standing request for updated information. The query flow is not explicitly shown.\
                           \
                           \
                           Flows added to the CVISN Architecture Flow Diagram:\
                           accident report: CVAS to CVCS\
                           accident report: CVAS to Other CVAS\
                           accident report: Other CVAS to CVAS\
                           alerts and advisories: Alerting and Advisory Systems to CVAS\
                           alerts and advisories: Alerting and Advisory Systems to CVCS\
                           citation: CVAS to CVCS\
                           citation: CVAS to Other CVAS\
                           citation: Other CVAS to CVAS\
                           commercial vehicle disable: CVSAg(CVS) to CVCS\
                           cv driver record: CVAS to CVCS\
                           cv driver record: CVAS to CVOIR\
                           cv driver record: CVAS to FMS\
                           cv driver record: CVAS to Other CVAS\
                           cv driver record: Other CVAS to CVAS\
                           cv driver record request: CVCS to CVAS\
                           cv driver record request: CVOIR to CVAS\
                           cv driver record request: FMS to CVAS\
                           cv driver record request: CVAS to Other CVAS\
                           cv driver record request: Other CVAS to CVAS\
                           cv driver credential: Driver ID Card to CVCS\
                           cv driver credential: Driver ID Card to CVSAg(CVS)\
                           cv driver credential: Driver ID Card to FMS\
                           cv repair status: FMS to CVAS\
                           expected driver identity characteristics: CVSAg(CVS) to CVCS\
                           freight equipment information: CVSAg(CVS) to CVCS\
                           \
                           These changes will be reflected in the CVISN Architecture document. In that document, the architecture flows will also be mapped
                           between specific equipment packages (new Table 2).\
                           \
                           \[2006-10-19\] Presented at the 10/19/06 ACCB meeting.\
                           Attendees recommended that this be approved. The CR will be posted to the CVISN System Architects\' listserv for an additional 30-day
                           comment period.\
                           \
                           \[2006-11-20\] Recommended for FMCSA approval at the 11/16 ACCB meeting.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           IMPACT SUMMARY:\
                           ACCB Items:\
                           1. CVISN Architecture Flow Diagram - delivered 1/5/07\
                           2. CVISN Architecture Document - delivered 1/5/07

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       1/8/2007 12:23:01 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          10/12/2006 8:10:30 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           1/8/2007 12:23:01 PM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4777

  **External               WA; SAFER CR 1508
  Reference:**             

  **Category:**            Request for summary reports

  **Component:**           SAFER

  **Synopsis:**            Request for summary data reports that can be used by
                           states to do a quick check of their CVIEW data quality.

  **Status:**              Closed Approved

  **Disposition:**         \[2007-01-23\] Approved by J. Secrist.

  **Description:**         Summary data can be used by states to do a quick check of
                           their CVIEW data quality. It also provides a way to track
                           growth of the various types of data (vehicles, fleets,
                           IFTA accounts, Carriers, etc.) in SAFER.\
                           \
                           Following are suggested monthly reports, tabulated by
                           state:\
                           \
                           1. total carriers, carrier updates for month\
                           2. total IRP accounts, active IRP accounts, IRP account
                           updates for month\
                           3. total fleets, active fleets, fleet updates for month\
                           4. total vehicles, active vehicles, vehicles updates for
                           month\
                           5. total IFTA accounts, active IFTA accounts, IFTA account
                           updates for month\
                           \
                           If possible the states would like to be able to specify
                           the time frame for the monthly summary report to allow
                           synchronization of the report with our local processing
                           cycle. If not, there should at least be an established cut
                           off date each month so that states will be able to
                           determine which of their transactions should or should not
                           be included in the report. \[WA 2006-10-20 comment\]\
                           \
                           \[2006-10-19\] Presented at the 10/19/06 ACCB meeting\
                           \
                           \[2006-11-20\] Recommended for FMCSA approval at the 11/16
                           ACCB meeting.\
                           \
                           \[2007-01-15\] Volpe: The SAFER development team will need
                           to further clarify the above requirements with the
                           stakeholders. For example, when it says \'updates for the
                           month\', does that mean the total count of updates for
                           that transaction SAFER received?\
                           \
                           The suggested reports are doable and should be a good way
                           for tracking the growth of the data.\
                           \
                           Not sure about how that would that help the data quality
                           checking unless other data elements are included in the
                           report template.\
                           \
                           \[2007-01-23\] Approved by J. Secrist. More input will be
                           solicited from the states at the CVISN Deployment
                           Workshop.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       5/7/2007 4:50:21 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          10/12/2006 6:50:10 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           5/7/2007 4:50:21 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4776

  **External               WA; SAFER CR 1507
  Reference:**             

  **Category:**            SAFER Upload Change Tracking

  **Component:**           SAFER

  **Synopsis:**            A SAFER Web page and/or Web service query capability is
                           needed that will allow a state to retrieve all XML
                           transaction data for a vehicle, fleet, or other uploaded
                           entity that is uploaded by a state using a T0019, 20, 21,
                           22 or 24 transaction.

  **Status:**              Closed Approved

  **Disposition:**         \[2007-01-23\] Approved by J. Secrist.

  **Description:**         SAFER Upload Change Tracking: A SAFER Web page and/or Web
                           service query capability is needed that will allow a state
                           to retrieve all XML transaction data for a vehicle (VIN),
                           fleet or other uploaded entity that is uploaded by a state
                           using a T0019, 20, 21, 22 or 24 transaction.\
                           \
                           This is a SAFER data integrity related enhancement. The
                           primary purpose of this enhancement is to aid with
                           troubleshooting of problems where a state is not receiving
                           data from another state or a state's data is not appearing
                           in SAFER.\
                           \
                           The queried information needs to include the XML upload
                           file name and time stamp for each XML file where matching
                           data is found.\
                           \
                           The process used to extract the XML data must use
                           "relaxed" versions of the XSD's for the above transactions
                           so that no fields are required. The intent here would be
                           to capture as much data as possible from the incoming XML
                           files so that that even XML transactions that are rejected
                           by SAFER would be logged in the tracking database (as much
                           is practical).\
                           \
                           14 months worth of data should be kept so we can find the
                           data for the last vehicle renewal for a vehicle.\
                           \
                           The primary key fields for each transaction type would be
                           the key fields used to perform a query. The only
                           exceptions to this would be: 1) T0022 transaction -- allow
                           query by VIN or LICENSE_PLATE_NUMBER and 2) T0024
                           transaction -- allow query by VIN or TRANSPONDER_ID.\
                           \
                           \[2006-10-19\] Presented at the 10/19/06 ACCB meeting.\
                           While several states supported implementation of this
                           capability, others questioned why Volpe's monitoring is
                           not adequate. Volpe noted that this capability would
                           enable states to do their own analysis, as sometimes the
                           reason for an upload failure is related to states'
                           business rules. It was agreed that this CR would be posted
                           to the CVISN System Architects listserv for further
                           comment.\
                           \
                           \[2006-11-20\] Recommended for FMCSA approval at the 11/16
                           ACCB meeting.\
                           \
                           \[2007-01-15\] Volpe. To fulfill this request, a SAFER
                           query function needs to be implemented and the information
                           will be displayed via the SAFER web page. The preliminary
                           requirements from the ACCB are listed below:\
                           1. The record should contain the XML upload file name with
                           corresponding upload date.\
                           2. Use \"relaxed\" versions of the schemas that the input
                           transactions are using\
                           3. Track all input transaction file names including the
                           ones that failed. This implies the processing status
                           should be one of the data element as well.\
                           4. Tracking scope consists of 14 months worth of data to
                           cover the last renewal information for a vehicle.\
                           5. The searching parameters for each transaction would be
                           limited to the key fields in each transaction.\
                           The SAFER team will need to clarify the above requirements
                           further with the stakeholders before designing such
                           capability.\
                           \
                           \[2007-01-23\] Approved by J. Secrist. More input will be
                           solicited from the states at the CVISN Deployment
                           Workshop.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       5/7/2007 4:50:10 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          10/12/2006 6:49:06 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           5/7/2007 4:50:10 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           4764

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Eliminate distinction between wireline and wireless lines on CVISN Architecture Flow Diagram

  **Status:**              Closed Approved

  **Disposition:**         \[2007-01-08\] Closed; document delivered.

  **Description:**         Different line types are used on the CVISN Architecture Flow Diagram to indicate Wireline (Fixed Point Communications), DSRC, Wide
                           Area Wireless, and Other Transactions. The distinction between wireline and wireless communications is no longer of value for CVO
                           applications.\
                           \
                           Fix: Use a single line type for both wireless and wireline communications.\
                           \
                           \[2006-09-22\] Presented at the 9/21/06 ACCB meeting.\
                           Attendees recommended that this be approved. The CR will be posted to the CVISN System Architects\' listserv for an additional 30-day
                           comment period.\
                           \
                           \[2006-10-19\] No dissenting comments. Recommended for FMCSA ECCB approval.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           IMPACT SUMMARY:\
                           ACCB Items:\
                           1. CVISN Architecture Flow Diagram - delivered 1/5/07\
                           2. CVISN Architecture Document (contains diagram) - delivered 1/5/07

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       1/8/2007 12:23:15 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/18/2006 9:29:52 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           1/8/2007 12:21:30 PM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           4763

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Add source and destination equipment packages for CVISN architecture flows

  **Status:**              Closed Approved

  **Disposition:**         \[2007-01-08\] Closed; document delivered.

  **Description:**         The National ITS Architecture shows source and destination equipment packages for each architecture flow that is exchanged between EPs
                           in different subsystems. The CVISN Architecture document does not.\
                           \
                           Fix: Add a table to show source and destination equipment packages for each flow.\
                           \
                           \[2006-09-22\] Presented at the 9/21/06 ACCB meeting.\
                           Attendees recommended that this be approved. The CR will be posted to the CVISN System Architects\' listserv for an additional 30-day
                           comment period.\
                           \
                           \[2006-10-19\] No dissenting comments. Recommended for FMCSA ECCB approval.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           IMPACT SUMMARY:\
                           ACCB Items:\
                           1. CVISN Architecture Document - delivered 1/5/07

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       1/8/2007 12:23:25 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/18/2006 9:28:01 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           1/8/2007 12:21:15 PM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------
  **CR Number:**           4762

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Slightly expand scope of CVISN Architecture document

  **Status:**              Closed Approved

  **Disposition:**         \[2007-01-08\] Closed; document delivered.

  **Description:**         The CVISN System Design Description document is no longer maintained. It contained several high-level diagrams and
                           descriptions should be updated and made accessible to all states in a current document.\
                           \
                           Fix: The only document that is being maintained is the CVISN Architecture. Expand the scope of the CVISN
                           Architecture document to include selected high-level diagrams and descriptions. In particular:\
                           • Move the brief description of Core CVISN capabilities into the CVISN Architecture document.\
                           • Annotate the latest version of the sausage diagram (see CR 4758) to highlight CVO aspects and move it into the
                           CVISN Architecture document.\
                           • Add the table of standard identifiers to the CVISN Architecture document.\
                           • Add the brief descriptions of the 41 Expanded CVISN Capabilities to the CVISN Architecture document. These were
                           documented in APL document SSD-PL-05-0202, Expanded Commercial Vehicle Information Systems and Networks (CVISN)
                           Summary Report, June 2005.\
                           \
                           \[2006-09-22\] Presented at the 9/21/06 ACCB meeting.\
                           Discussion focused on the attachment, CR4762_CVISNArchScope_VB1.pdf. In figure A, page 2, the title should refer to
                           \"Core CVISN\" instead of \"CVISN Level 1\". With regard to the Vehicle Plate ID standard identifier for vehicles
                           figure C, page 6, Volpe suggested that the reference for country codes to the FHWA Code Directory should be replaced
                           with a reference to ISO standard 3166, since that is what is now being used. On that same page, there was also
                           confusion about the two standard identifiers for vehicle; the line between the Vehicle Identification Number and
                           Vehicle Plate ID was in the wrong place. The attachment has been updated and renamed CR4762_CVISNArchScope_R1.pdf.\
                           \
                           Attendees recommended that this be approved. The CR and revised attachment will be posted to the CVISN System
                           Architects\' listserv for an additional 30-day comment period.\
                           \
                           \[2006-10-19\] No dissenting comments. Recommended for FMCSA ECCB approval.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           \
                           IMPACT SUMMARY:\
                           ACCB Items:\
                           1. CVISN Architecture Document - delivered 1/5/07

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CR4762_CVISNArchScope_R4.ppt\
                           CR4762_Identifiers.doc

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       1/8/2007 12:23:35 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/18/2006 9:21:48 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           1/8/2007 12:20:55 PM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           4760

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Update CVISN Architecture to keep pace with changes to the National ITS Architecture (Versions 5.1 and 5.1.1).

  **Status:**              Closed Approved

  **Disposition:**         \[2007-01-08\] Closed; document delivered.

  **Description:**         Description:\
                           The CVISN Architecture document should be updated to align with changes made in Version 5.1.0 and 5.1.1 of the National ITS
                           Architecture. The changes include:\
                           \
                           1. Architecture flow trip identification number was replaced by trip identification number input from CV Driver to CVSAg(CVS).
                           (Version 5.1)\
                           \
                           2. Version 5.1 of the National ITS Architecture organized the functional requirements by Equipment Package (EP) and added them to the
                           physical architecture database and hypertext. In connection with those changes, the descriptions for these Equipment Packages were
                           revised: Credentials and Taxes Administration, CV Information Exchange, CV Safety Administration, International CV Administration,
                           Citation and Accident Electronic Recording, International Border Crossing, Roadside Electronic Screening, Roadside HAZMAT Detection,
                           Roadside Safety and Security Inspection, Roadside WIM, On-board Cargo Monitoring, On-board CV Electronic Data, On-board CV Safety and
                           Security, On-board Driver Authentication, On-board Trip Monitoring, Vehicle Location Determination, Vehicle Mayday I/F (name
                           modification as well), Vehicle Probe Support, Vehicle Toll/Parking Interface, Fleet Credentials and Taxes Management and Reporting,
                           Fleet HAZMAT Management, Fleet Maintenance Management, Freight Administration and Management, and Manage CV Driver Identification. The
                           revised EP descriptions clarify the functions assigned to each package.\
                           \
                           3. Updated terminator description: Alerting and Advisory Systems\
                           \
                           4. Updated ITS Standards Information (5.1.1) "The ITS standards area was updated to make it consistent with the new ITS Standards
                           Program website. Many minor changes were made to the ITS standards information so that the two sites are completely consistent in the
                           standards information that is presented. Changes were made to standards document numbers and standards titles and several standards
                           were added/removed to match current ITS standards activities. The DSRC 915 Mhz standards group description was updated to reflect
                           feedback from the CVO community." Further analysis required to determine if these changes impact the CVISN architecture.\
                           \
                           Fix: Update the CVISN Architecture document to match the new flow name, equipment package descriptions, and terminator description.\
                           \
                           \[2006-09-22\] Presented at the 9/21/06 ACCB meeting.\
                           Attendees recommended that this be approved. The CR will be posted to the CVISN System Architects\' listserv for an additional 30-day
                           comment period.\
                           \
                           \[2006-10-19\] No dissenting comments. Recommended for FMCSA ECCB approval.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           IMPACT SUMMARY:\
                           ACCB Items:\
                           1. CVISN Architecture Document - delivered 1/5/07

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       1/8/2007 12:23:45 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/15/2006 10:00:15 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           1/8/2007 12:20:34 PM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           4758

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Bring the CVO Subsystems Interconnect (\"sausage\") diagram into alignment with the corresponding National ITS Architecture diagram.

  **Status:**              Closed Approved

  **Disposition:**         \[2007-04-09\] Closed

  **Description:**         The following changes need to be made to the CVO diagram to bring it into alignment with changes made to Version 5.0 of the National
                           ITS Architecture:\
                           1. Add Security Monitoring subsystem\
                           2. Change Wireline Wide Area Communications to Fixed-Point to Fixed-Point Communications\
                           3. Add \"(Mobile)\" to Wide Area Wireless Communications label\
                           4. Change Personal Information Access to Wide Area Wireless (Mobile) Communications\
                           5. Change Roadside label to Field\
                           The attached file shows the proposed changes.\
                           \
                           \[2006-09-22\] Presented at the 9/21/06 ACCB meeting.\
                           Attendees recommended that this be approved. The CR will be posted to the CVISN System Architects\' listserv for an additional 30-day
                           comment period.\
                           \
                           \[2006-10-19\] No dissenting comments. Recommended for FMCSA ECCB approval.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           IMPACT SUMMARY:\
                           ACCB Items:\
                           1. CVISN System Design Description (not currently maintained)\
                           2. Introductory Guide to CVISN (not currently maintained)

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CR4758 Natl ITS Arch Sausage w CVO highlights.ppt

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       4/9/2007 9:25:12 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/14/2006 2:57:23 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Low

  **Priority:**            No

  **Type:**                Adaptive Change

  **Closed On:**           4/9/2007 9:25:12 AM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4727

  **External               SAFER CR 960
  Reference:**             

  **Category:**            Intrastate SafeStat data

  **Component:**           SAFER/Web Services

  **Synopsis:**            Synopsis: SAFER needs to be enhanced to handle Intrastate
                           SafeStat data.\
                           \
                           Summary: SAFER needs to be enhanced to receive the
                           intrastate SafeStat score from A&I and store in newly
                           added columns in SAFER database. The ISS snapshot Web
                           services maintained by SAFER will be modified to include
                           the intrastate SafeStat score.

  **Status:**              Closed Approved

  **Disposition:**         \[2007-01-23\] Approved by J. Secrist. Scheduled for SAFER
                           5.2.

  **Description:**         The ISS development team requested to include intrastate
                           SafeStat data into ISS to support the single carrier
                           refresh snapshot and monthly database refresh.\
                           \
                           SAFER needs to be enhanced to receive the intrastate
                           SafeStat score from A&I and store in newly added columns
                           in SAFER database. The ISS snapshot Web services
                           maintained by SAFER will be modified to include the
                           intrastate SafeStat score. It was determined that the
                           intrastate SafeStat score currently is stored in MCMIS
                           work tables and is being updated after each regular
                           SafeStat run.\
                           \
                           ISS development team will need to modify the monthly
                           database refresh routine to receive the intrastate
                           SafeStat score.\
                           \
                           The SAFER team will need to develop a script to extract
                           data via database link to MCMIS and load into the SAFER
                           database.\
                           \
                           \[2006-07-26\] Discussed at the 7/20/06 ACCB meeting.\
                           Intrastate ISS values are calculated monthly with the
                           SafeStat runs, but are not currently posted in MCMIS
                           production or to SAFER. Currently, these intrastate
                           carriers have their ISS values listed in SAFER as
                           \"Insufficient Data\" (when, in fact, they could have many
                           inspections). This proposal would begin to populate the
                           intrastate SafeStat and ISS values to SAFER and include an
                           additional indicator to indicate that these values are
                           based on the intrastate SafeStat results. This will
                           involve a change to the T0031 MCMIS Census and Safety
                           output transaction. The current proposed change will add
                           the value \"N\" to the list of possible values for the
                           Indicator field.\
                           \
                           \[2006-08-16\] From SAFER Version of the CR\
                           From Allen Day:\
                           Here are the table names and logic to determine
                           intra-state ISS and SafeStat values from work tables on
                           MCMIS. These work tables are available after the SafeStat
                           run has been validated until the next SafeStat run
                           validation process begins.\
                           \
                           Intra-State ISS\
                           Table: iss_work\
                           safestat_run_ind = \'S\' (intra state SafeStat) iss_group
                           1-46 Safety Based ISS Values iss_group 98-99 Insufficient
                           Data ISS Values\
                           \
                           Intra-State SafeStat\
                           Table: SafeStat_Information\
                           safestat_run_ind = \'S\' (intra state SafeStat)
                           safestat_category \'A\',
                           \'B\',\'C\',\'D\',\'E\',\'F\',\'G\',\'H\' (Safety
                           Based/Sufficient Data) safestat_category = \'I\'
                           (insufficient data/no safestat scores)\
                           \
                           If you need more detailed information on SafeStat
                           Indicators (RAI, EHI, AII,etc.) you can use the following
                           join information to get the desired information:\
                           \
                           FROM safestat_information a, ss_info_census b,
                           ss_info_review c, ss_info_inspection d,
                           ss_info_recordable_crash e, ss_info_enforcement f,
                           ss_info_crash g\
                           WHERE a.safestat_information_id (+) =
                           b.safestat_information_id and\
                           b.safestat_information_id = c.safestat_information_id (+)
                           and\
                           b.safestat_information_id = d.safestat_information_id (+)
                           and\
                           b.safestat_information_id = e.safestat_information_id (+)
                           and\
                           b.safestat_information_id = f.safestat_information_id (+)
                           and\
                           b.safestat_information_id = g.safestat_information_id (+)
                           and\
                           a.safestat_score_date= \'safestat_run_date\' and\
                           safestat_run_ind = \'safestat_run_indicator\' (\'M\'onthly
                           run, intra\'S\'tate SafeStat)\
                           \
                           \[2006-10-19\] Status reported at 10/19/06 ACCB meeting.\
                           Implementation was deferred from SAFER 5.1 but is on the
                           list for FY07.\
                           \
                           \[2007-01-23\] Approved by J. Secrist. Scheduled for SAFER
                           5.2

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       5/7/2007 4:50:56 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          7/19/2006 1:18:07 PM

  **Entered By:**          Roberts Onna Beth

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           5/7/2007 4:50:56 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4640

  **External               SAFER CR 2555
  Reference:**             

  **Category:**            XML transaction processing time is too long-change the
                           file size

  **Component:**           SAFER/CVIEW

  **Synopsis:**            NE reports that it takes approximately 12-15 hours to
                           process baseline XML transaction files due to XML tag
                           overhead.\
                           \
                           Summary: During discussion at the March ACCB meeting,
                           states and Volpe suggested several alternatives for
                           alleviating some of the transaction processing time
                           problems.\
                           \
                           Proposal: Recommend that FMCSA support further
                           investigation by the developers into methods to alleviate
                           the processing burden of exchanging data between SAFER and
                           state CVIEWs.

  **Status:**              Closed Fixed

  **Disposition:**         \[2006-10-19\] Closed. Fixed per SAFER 5.1.

  **Description:**         During the March ACCB meeting, several comments were made
                           as to the time it takes to process XML transactions. CR
                           2555 (Change the file size limit) was incorporated into
                           this new CR.\
                           \
                           State comments:\
                           \
                           - XML tag overhead is hideous, carrying a lot of XML tags.
                           Why not use on-demand on-call into the host system and not
                           transport these files?\
                           \
                           - Need a method of sending and receiving data so that
                           files are not so big and rebaselining does not occur so
                           frequently.\
                           \
                           Volpe comments:\
                           \
                           - SAFETYNET still uses flat files, but they will be phased
                           out. FMCSA supports XML, not flat files.\
                           \
                           - Suggest sending transactions as update instead of a
                           refresh - only send fields that have changed instead of
                           the whole record.\
                           \
                           - Suggest that states filter out the records they don\'t
                           want by using the subscription method.\
                           \
                           \[2006-04-25\] Presented at the 4/20/2006 ACCB meeting.\
                           The CR will be posted to the CVISN System Architects
                           listserv for 30-day review and comment period. The
                           creation of this CR was an action item from the previous
                           ACCB meeting discussion. CR 2555 was linked to this CR in
                           StarTeam as one of the possible solutions to alleviate the
                           processing burden for CVIEWs. One state brought up the
                           fact that CR2555 was completely different from this CR and
                           suggested that the two CRs should be posted separately.
                           APL explained that they were linked together, not
                           incorporated as one, because both had to do with
                           processing transactions.\
                           \
                           \[2006-05-26\] Discussed at the 5/18/06 ACCB meeting.\
                           The ACCB approved the recommendation that FMCSA support
                           further investigation by the developers into methods to
                           alleviate the processing burden of exchanging data between
                           SAFER and state CVIEWs.\
                           \
                           \[2006-10-19\] Status reported at the 10/19/06 ACCB
                           meeting.\
                           NE will report later this year as to whether this issue
                           has been resolved by the implementation of the
                           subscription capability (Architecture CR 2412 - SAFER CR
                           10) in SAFER 5.1.\
                           \
                           \[2006-12-18\] Discussed at the 12/14/06 ACCB meeting.\
                           Nebraska has tested the subscription capability but will
                           wait until early 2007 to implement it. They will report
                           back in February as to whether the subscription capability
                           relieves the processing problems.\
                           \
                           \[2007-03-27\] John Casteel, NE.\
                           Nebraska recently changed our SAFER T0031 download process
                           to utilize the new SAFER T0031 subscription service. We
                           have been using the subscription service for about a month
                           now and last week was the first time we took the T0031
                           baseline files using this new feature. Shown below are the
                           Nebraska download/database update times reported from the
                           February regular T0031 baseline run compared to the
                           processing times for the March subscription T0031 baseline
                           run.\
                           \
                           Regular T0031 (February 2007)\
                           Download = 5 hours 12 minutes\
                           DB Update = 7 hours 33 minutes\
                           Total Processing Time = 12 hours 45 minutes\
                           \
                           Subscription T0031 (March 2007)\
                           Download = 1 hour 54 minutes\
                           DB Update = 2 hours 38 minutes\
                           Total Processing Time = 4 hours 32 minutes\
                           \
                           In our case, we reduced total processing time for T0031
                           baseline files by about 75% (12 plus hours down to 4 plus
                           hours). I expect other states that decide to use the SAFER
                           T0031 subscription service would also see reduced
                           processing times, but their percentage may differ from
                           Nebraska. The variance would depend on what fields and how
                           many fields the state identifies in their subscription
                           service with SAFER.

  **Fix:**                 New subscription capability implemented.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/29/2007 3:31:18 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          4/10/2006 5:24:21 PM

  **Entered By:**          Roberts Onna Beth

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           12/11/2006 8:28:09 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4626

  **External               
  Reference:**             

  **Category:**            Add capability for multiple DBA names in SAFER

  **Component:**           SAFER/MCMIS

  **Synopsis:**            Modify MCMIS and SAFER to accommodate multiple DBA name
                           fields.\
                           \
                           Summary:\
                           Currently, SAFER and MCMIS contain one DBA field. Several
                           states have expressed a need for multiple DBA names, while
                           several states are against multiple DBA names. Currently,
                           some states concatenate multiple DBA names in the single
                           DBA name field in MCMIS and state systems handle the
                           multiple names. If this change were approved and
                           implemented, both MCMIS and SAFER would need to be
                           changed.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2006-06-23\] Disapproved

  **Description:**         \[Barbara Hague, MO - 10-27-2005\] requested information
                           on how to handle multiple \"Doing Business As\" (DBA)
                           names that are concatenated in the DBA field in the SAFER
                           T0031 transaction.  In Missouri, divisions of one legal
                           entity use the same DOT \# but have different DBA names.
                           How do states use the DBA data?  What is the purpose of
                           having a string of multiple names in one data field? If
                           the state cannot clearly assign legal responsibility, how
                           can it assign responsibility for Safety?\
                           \
                           \[Doug Deckert, WA - 02-23-2006\] Multiple DBA names may
                           assist enforcement in identifying the carrier. It was
                           noted that often a truck will have a name and USDOT on its
                           side and the name is neither the legal name nor the
                           registered DBA name. Also, a driver may give a carrier
                           name that again does not match either of the search names
                           in SAFER.\
                           \
                           Since the DBA name originates in MCMIS, via completion of
                           the MCS-150 form, any change in the number of DBA fields
                           must be made in MCMIS. In turn this will affect SAFER and
                           the CVIEWs.\
                           \
                           This issue was posted to the CVISN system architect\'s
                           listserv in February. Some of the comments include:\
                           \
                           \[MD DJ Waddell - 03-02-2006\] As an example, a CV
                           enforcement officer would use a browser-based interface to
                           CVIEW to find the listed DBA names for a carrier whose
                           vehicle is presently sitting on the static scale. If the
                           name on the door doesn\'t match any in the list, then pull
                           \'em in to show paper.\
                           \
                           \[NY Stephen Trudell - 03-03-2006\] New York would like a
                           limit of 3 DBAs. NY inspection people feel that this
                           number of DBA entries would capture the vast majority of
                           carriers with multiple DBAs. If a carrier utilizes more
                           than 3 DBAs, then a red flag should go up.\
                           \
                           \[WA Doug Deckert - 03-03-2006 \] There may be times when
                           a carrier will use a DBA name in one state and a different
                           DBA name in another state. Often when an officer looks up
                           the USDOT \# they will see a legal name and a DBA name
                           that doesn\'t match the DBA given by the trucker or on the
                           side of the truck. Providing multiple DBA names (hopefully
                           with a match) would help both the officers and the
                           carriers (really the truck drivers) make things go more
                           smoothly while the officer is inspecting paperwork or the
                           commercial vehicle. Agree with the idea of three DBAs
                           allowed and then raise a warning.\
                           \
                           \[MT Jodee Alm - 03-09-2006\] Montana agrees that there
                           should be a least 2 DBA\'s. But more than just the
                           states\' CVIEWs, SAFER, and MCMIS will be affected by this
                           change. One has to remember what feeds into their CVIEWs.
                           For Montana, we may also look at having to update our IRP,
                           IFTA and Permitting Applications, plus any reports or
                           forms that are printed with this information.\
                           \
                           \[TX Tammy Duncan - 03-10-2006\] Texas DPS strongly feels
                           there should be only a single DBA allowed per carrier. If
                           a carrier wants to operate under additional names, they
                           should apply for different operating authority and/or US
                           DOT numbers.\
                           \
                           Texas deals with approximately 300,000 commercial vehicle
                           inspections and 16,000 commercial vehicle crashes
                           annually, and verifies the carrier information on every
                           inspection and crash report. DPS believes very strongly
                           that adding additional DBAs will make the process for
                           creating and maintaining carrier profiles exceptionally
                           more difficult.\
                           \
                           If you allow multiple DBAs, where do you draw the line\...
                           Two, three, twenty? It is felt that the current limit of
                           one DBA is more than sufficient to consistently ensure
                           proper identification of a motor\
                           carrier.\
                           \
                           \[FMCSA Sharon Owenson - 03-10-2006\] Another aspect of
                           changing the number of DBA names is the FMCSA regulations.
                           49 CFR 390.21(b)(1) states that the legal name or a single
                           trade name of the motor carrier operating the
                           self-propelled CMV, as listed on the motor carrier
                           identification report (Form MCS-150) and submitted in
                           accordance with Section 390.19. All FMCSA systems are set
                           up to use only one DBA name. Using the legal name on the
                           trucks and the trade name will allow you to use any trade
                           name you want on the side of the truck as long as the
                           officer can match the legal name and the USDOT number. In
                           these instances where you have multiple DBA names, the DBA
                           field would be left blank in MCMIS.\
                           \
                           Example: JOHN DOE dba FARM & COUNTRY STORE USDOT XXXXXXX\
                           \
                           Also, in response to the Texas suggestion that a company
                           apply for other USDOT numbers and authority, it is
                           important to remember that there can be only one USDOT
                           number per company. You must set up a separate corporation
                           to have another USDOT number. Hopefully that is what
                           Texas\
                           meant.\
                           \
                           \[2006-04-25\] Presented at the 4/20/2006 ACCB meeting.\
                           This CR will be posted to the CVISN System Architects
                           listserv for a 30-day comment period and a vote.\
                           Action: States are requested to respond by 2006-05-17 to
                           these questions:\
                           1. Does the state support modifications to MCMIS and SAFER
                           to carry multiple DBA names?\
                           2. If \"yes\", how many DBA names and how would the state
                           use the multiple names?\
                           \
                           \[2006-05-26\] Discussed at the 5/18/06 ACCB meeting.\
                           The text string comes from the FMCSA MCS150 entry form.
                           The current usage is uncontrolled. Even if more DBA Name
                           fields are provided, there are no edit checks to keep from
                           continuing to concatenate the DBA Names in one or more
                           fields. Some states felt that the amount of effort needed
                           to implement this CR would be put to better use on more
                           important CRs. The comments received on this CR will be
                           tallied by APL and posted to the listserv.\
                           \
                           \[2006-06-23\] This CR was disapproved at the 6/22/06 ACCB
                           meeting.\
                           After further discussion, the ACCB decided that the time
                           and effort required to implement this CR would be better
                           spent on more critical CRs. Participants agreed that this
                           CR should be disapproved.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Roberts Onna Beth

  **Modified Time:**       1/2/2007 2:35:22 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/22/2006 4:15:49 PM

  **Entered By:**          Roberts Onna Beth

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           1/2/2007 2:35:22 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           4529

  **External               SAFER CR 486, SAFER CR 799
  Reference:**             

  **Category:**            SAFER/CVIEW

  **Component:**           SAFER Web services

  **Synopsis:**            Expand SAFER Web services to other XML transactions to
                           support CVISN users. This includes the six input
                           transactions and five other output transactions with which
                           SAFER interacts with CVIEW.

  **Status:**              Closed Approved

  **Disposition:**         \[2006-09-18\] Closed; incorporated into SAFER Release
                           5.1.

  **Description:**         This CR is an extension of CR 2444 (SAFER CR 21), which
                           was in SAFER version 4.4. The SAFER Web services
                           implemented in CR 2444 provides a query function for the
                           CVIEW states to retrieve information directly from SAFER
                           when data is not available in the local CVIEW system. This
                           function is available for T0028, T0031 and T0032. This CR
                           will apply Web services technology to all transactions.
                           Because of the scope of the enhancement, implementation of
                           Web services to the other five output transactions will
                           occur in SAFER version 5.0 (Feb 2006). The implementation
                           of Web services to the input transactions will be made in
                           SAFER version 5.1 in August 2006.\
                           \
                           \[2006-01-25\] Presented and discussed at the 1/19/06 ACCB
                           meeting.\
                           Andrew Wilson explained the Web services approach to
                           retrieving data from SAFER. CVIEW will be able to query
                           SAFER for data via Web Services. Volpe is in the process
                           of folding the Web services documentation into the ICD.
                           The documentation will include a requirements document for
                           this CR and individual specification documents for each
                           transaction. There will be two phases to the
                           implementation of this CR. The T0025, T0026, T0027, T0030,
                           and possibly T0029 will be included in SAFER v5.0 (Feb
                           2006). All of the input transactions will be included in
                           the v5.1 release (Aug 2006). There are no plans to
                           discontinue the current FTP services.\
                           \
                           \[2006-05-04\] Presented at the 4/20/06 ACCB meeting.\
                           The input transactions to be included are T0019, T0020,
                           T0021 and T0022. This CR will be implemented in SAFER
                           Release 5.1 in August.\
                           \
                           \[2006-05-15\] SAFER CR 799 created in response to April
                           ACCB meeting and incorporated into this CR.\
                           \"This CR is an extension of CR 486 that has been
                           implemented in SAFER version 5.0 for the output
                           transactions. The SAFER web services implemented in SAFER
                           CR 21 and SAFER CR 486 provide query function for the
                           CVISN states to retrieve information directly from SAFER
                           when data is not available in the local CVIEW system. This
                           function is available for T0025, T0026, T0027, T0028,
                           T0030, T0031 and T0032. This CR will apply web services
                           technology to T0019, T0020, T0021, and T0022 input
                           transactions. The implemenation of web services to the
                           input transactions will be made in SAFER version 5.1 in
                           August 2006.\"\
                           \
                           \[2006-05-26\] Discussed at the 5/18/06 ACCB meeting.\
                           SAFER CR 799 was spawned from SAFER CR 486 to include
                           input transactions T0019, T0020, T0021 and T0022 and will
                           be implemented in SAFER Release 5.1 in August.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/18/2006 7:09:51 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          1/20/2006 6:23:57 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           9/18/2006 7:09:51 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           3958

  **External               VOLPE CR 432
  Reference:**             

  **Category:**            SAFER Web services

  **Component:**           SAFER

  **Synopsis:**            SAFER Web service issues

  **Status:**              Closed Fixed

  **Disposition:**         \[2005-09-22\]Discussed at ACCB mtg. Should not have been
                           an ARCH CR only SAFER CR for ACCB information. Closed.

  **Description:**         From Volpe CR 432:\
                           JHUAPL reported four issues with the current SAFER Web
                           services. The detailed information is contained in the
                           attachment.\
                           \
                           Basically, the issue has been identified in the following
                           areas:\
                           \
                           1. Transaction Authentication\
                           It is found that a couple query transactions using Web
                           services do not enforce authentication from the client
                           system. As matter of fact, this issue was already fixed in
                           the test system when the SAFER team was working with NDSU
                           development team.\
                           \
                           2. Error in globalTypes.xsd. Mexico shows up twice in the
                           list of permissible jurisdictions.\
                           This can be corrected along with the SAFER CR 306 in the
                           October release. The Volpe center will distribute the
                           updated globalTypes.xsd by September 16th.\
                           \
                           3. Document element attributes. The XML namespace tags are
                           correct for T0001 and T0032 but incorrect for T0031 and
                           T0028.\
                           This problem was fixed in T0032 when Wisconsin reported
                           it. A similar fix can be applied to T0031 and T0028. Volpe
                           should check with the Web service users before deploying
                           the changes in the production version to avoid adverse
                           impact.\
                           \
                           4. The XML declaration is missing from the T0001
                           transaction.\
                           Volpe has evaluated this and propose to fix it in the next
                           deployment of the test service.\
                           \
                           \[2005-09-22\] Disscussed at the ACCB meeting on 9/22/05.\
                           It was determined that this CR should have been a SAFER CR
                           for ACCB information only and not an Architecture CR.
                           Closed

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    PSE-05-028.doc

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       10/4/2005 8:37:19 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/19/2005 8:10:39 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           10/3/2005 8:50:39 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           3830

  **External               SAFER CR 800, CR 3115, Volpe CR 431
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Add the following data to the Carrier Snapshot, which will
                           be distributed via T0031 V2: (1) a count of the number of
                           inspections in the last 24 months that had the OS/OW field
                           checked, and (2) HazMat permit data.

  **Status:**              Closed Approved

  **Disposition:**         \[2006-09-18\] Closed; incorporated into SAFER Release
                           5.1.

  **Description:**         At the 6/23/05 ACCB meeting, OK requested that the T0031
                           contain a count of how many inspections in the last 24
                           months had the OS/OW field checked. This request was
                           originally added to CR 3115.\
                           \
                           \[2005-08-22\] During the 8/18/05 ACCB meeting it was
                           decided that this portion of CR 3115 would be separated
                           out into its own CR so the inclusion of CR 3115 could
                           proceed in the next SAFER update (Oct 3). Volpe checked
                           with the MCMIS team concerning the request for the count
                           of how many inspections in the last 24 months had the
                           OS/OW field checked. There is no such field at this time,
                           and it will require a new calculation.\
                           \
                           \[2005-09-22\] Discussed at 9/22/05 ACCB meeting.\
                           This CR was created because the data requested from MCMIS
                           was not available to be incorporated into CR 3115 for the
                           October 3rd Release of SAFER. Recommended for Approval.\
                           \
                           FMCSA has requested that HazMat permit databe added to the
                           company snapshot in the future release. This CR has been
                           approved by FMCSA to be implemented in FY 2006.\
                           \
                           \[2006-01-25\] Presented and discussed at the 1/19/06 ACCB
                           meeting.\
                           This CR may be implemented in two phases. It is expected
                           that the HazMat part of the CR will be included in SAFER
                           v5.0 (Feb 2006). The OS/OW record count may not be ready
                           by February and would then be included in SAFER v5.1 (Aug
                           2006).\
                           \
                           \[2006-03-21\] Presented at the 2006-03-23 ACCB meeting.\
                           This was not released in SAFER 5.0 as planned. The SAFER
                           side of the implementation is done, but the MCMIS side
                           still needs to be completed. This CR will be implemented
                           in SAFER Release 5.1 in August.\
                           \
                           \[2006-05-04\] Presented at the 2006-04-20 ACCB meeting.\
                           The MCS-150 fields will also be added to this CR. This CR
                           will be implemented in SAFER Release 5.1 in August.\
                           \
                           \[2006-05-15\]\
                           SAFER CR 800 covers the MCS-150 fields (see above) as
                           follows:\
                           \"This is continuation of CR 431. In summary, the follow
                           data are requested to be included in the T0031v2
                           transaction. 1. Jamie Vasser requested to include domicile
                           country code to be used by long haul mexican carrier
                           insurance verification.in ASPEN, ISS, SAFETYNET. Louisiana
                           has requested to add the reords count for the over size /
                           over weight commercial vehicles inspected during the 24
                           months period to the T0031 transaction. 2. PRISM requested
                           to include additional MCS 150 data fields. 3. FMCSA has
                           requested to add HazMat permit data to the company
                           snapshot. 4. Louisiana has requested to add the reords
                           count for the over size / over weight commercial vehicles
                           inspected during the 24 months period to the T0031
                           transaction. This will requires MCMIS to calculate the
                           count and modify the materialized view to include the
                           inspection count. Once MCMIS modifies the program. SAFER
                           load will be changed accordingly. ACCB meeting has
                           approved this CR for FMCSA consideration in 09/2005. This
                           CR has been approved by FMCSA to be implemented in FY
                           2006. SAFER has implemented part of the changes during
                           release 1.The rest will be implemented in release 2 in
                           August 2006.\"\
                           \
                           \[2006-05-26\] Discussed at the 5/18/06 ACCB meeting.\
                           Deadline for adding new data elements is mid June, 2006.
                           Currently, the new data elements to be included in the
                           T0031 v2 transaction for SAFER Release 5.1 in August are:
                           domicile country code, additional MCS 150 fields, HazMat
                           permit data and the count of how many inspections in the
                           last 24 months had the OS/OW field checked.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/18/2006 7:09:36 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/19/2005 7:22:57 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           9/18/2006 7:09:36 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------
  **CR Number:**           3671

  **External               SAFER CR 306
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Add CANU to GlobalType.xsd

  **Status:**              Closed Fixed

  **Disposition:**         \[2007-01-17\] Closed - fix deployed 12/14/06.

  **Description:**         \[2005-06-21\] SAFER CR 306\
                           This change request is created to address Call \# 80885 initiated by Cambridge Systematics.\
                           \
                           While processing data for the state of Connecticut, it was found the globalTypes.xsd file did not have
                           one of the Canadian jurisdiction abbreviations: CANU for Nunavut.\
                           \
                           The globalTypes.xsd needs to be updated to reflect this change.\
                           \
                           \[2005-06-29\] Presented and discussed at the 6/23/05 ACCB meeting.\
                           This CR was submitted by CSI after the new Canadian jurisdiction code \"CANU,\" for Nunavut, was found
                           in data for Connecticut. Alana Gourneau (SD) offered to talk to CSI for further information /
                           clarification of this CR. CR remains open pending further discussion.\
                           \
                           \[2005-08-02\] Presented and discussed at the 7/28/05 ACCB meeting.\
                           Volpe noted that this should be addressed at the enterprise-level and changed in all FMCSA systems.
                           Changes need to be coordinated within FMCSA as well as with the states. It was requested that schema
                           changes coincide with software release dates and that states receive adequate notice, at least 30 days.
                           Volpe will discuss with FMCSA and get back to ACCB.\
                           \
                           \[2005-08-19\] Discussed at the 8/18/05 ACCB meeting\
                           This change can be made to SAFER independently from other enterprise applications. Volpe can make the
                           change in the October 3 release. Volpe will send out the revised schema by mid-September. This CR was
                           recommended for FMCSA approval.\
                           \
                           \[2006-03-21\]\
                           Fixed in SAFER v4.9 October 2005\
                           \
                           \[2006-10-19\] This change has not been implemented, but is expected to be deployed in the next few
                           weeks.\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact on SAFER:\
                           \
                           \
                           Impact on States:\
                           \
                           \
                           Impact on architecture:\
                           \
                           \
                           Impact on documentation:

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       1/17/2007 3:28:38 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/21/2005 8:32:19 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           1/17/2007 3:28:38 PM
  --------------------- -- --------------------------------------------------------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------
  **CR Number:**           3670

  **External               SAFER CR 143, SAFER CR 302, SAFER CR 348
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Develop a Business Use Case for E-screening Enrollment and Transponder ID Management/SAFER capability to
                           support Transponder \"Opt-Out\" Process

  **Status:**              Closed Approved

  **Disposition:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.

  **Description:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.\
                           \
                           \[2007-07-26\] Not voted on. Approved by FMCSA for SAFER 7.3.\
                           \
                           After a series of discussions on E-Screening business re-modeling, instead of implementing the Opt-In
                           approach, the CVISN stakeholders proposed a Transponder \"Opt-Out\" Process for carriers that wish to
                           decline E-Screening in specific states. The document created by Bill Goforth from WA is attached to this
                           CR.\
                           \
                           This new proposal requires SAFER to make the following changes:\
                           \
                           1. SAFER shall allow any state to change any transponder data and its associated opt-out information via
                           the new transaction T0024 v2.\
                           2. SAFER shall have the capability to capture the changes for transponder, opt-out information, who made
                           the changes, change date in the system and allow tracking via SAFER web query.\
                           3. SAFER shall discontinue the T0023 transaction.\
                           4. SAFER shall enhance the T0024 transaction to add the data elements for the opt-out information. The
                           complete data elements in the T0024 V2 will contain the following:\
                           -VIN (mandatory)\
                           -transponder_number\
                           -transponder_jurisdiction (mandatory)\
                           -transponder_update_date (mandatory)\
                           -opt_out_jurisdiction\
                           -opt_out_state\
                           -opt_out_country\
                           -opt_out_change_date\
                           -op_out_change_carrier\
                           -safety_carrier (mandatory)\
                           -activity_code (mandatory)\
                           -last_update_date (mandatory)\
                           \
                           5. SAFER shall send all above transponder information to all states via the T0029 transaction unless the
                           states are on the opt-out state list.\
                           6. SAFER shall generate T0029 for updated e-screening transactions and baseline generation.\
                           7. SAFER shall place the T0029 data files in the T0029 FTP root directory. SAFER shall remove the states
                           directory at a later time when all states are ready to switch to the T0029 root directory for download.\
                           \
                           The proposed process requires CVISN states to perform the following:\
                           1. Update XML schema to the new T0024 v2\
                           2. Program CVIEW to add logic to the T0029 processing to ignore transponder for screening when their
                           jurisdiction is on the opt_out_jurisdiction list for the transponder.\
                           3. Program CVIEW to point to the T0029 FTP directory for T0029 download.\
                           4. Responsible for making changes to the opt_out jurisdiction data for the transponder and submit the
                           updates via a T0024 update file to replace all previous opt-out jurisdictions for the transponder with
                           the new opt_out jurisdictios.\
                           \
                           \[2006-11-21\] Discussed at the 2006-11-16 ACCB meeting.\
                           Volpe has not completed development of a Business Use Case for e-screening enrollment and transponder
                           management, and it was requested that they participate in the E-Screening Focus Group.\
                           \
                           \[2006-07-26\] Discussed at the 7/20/06 ACCB meeting.\
                           The ACCB agreed that this CR should be added to the list of e-screening issues and discussed further.
                           Architecture CR 3670 asks Volpe to develop a Business Use Case for E-screening Enrollment and
                           Transponder ID Management. The E-screening Use Case could be used as a mechanism to clarify the existing
                           e-screening process for the stakeholders. This SAFER CR was incorporated into Arch CR 3670 (Synopsis:
                           Develop a Business Use Case for E-screening Enrollment and Transponder ID Management), which will be
                           discussed along with other issues in the E-screening Enrollment focus group.\
                           \
                           \[2006-05-17\] Discussed at 2007-05-17 CVISN ACCB meeting. Volpe has rewritten SCR 302 to be the
                           replacement for Architecture CR 4948 \"T0023 E-Screening Enrollment Transaction is Ineffective\" which
                           was withdrawn at the 2007-04-19 ACCB meeting.\
                           \
                           \[2006-05-04\] SAFER CR 302 Presented at the 4/20/06 CVISN ACCB meeting.\
                           Transaction T0023 contains a list of states to which a carrier authorizes SAFER to send its vehicles'
                           transponder IDs. If a carrier wants to remove an authorized jurisdiction, the state sends in another
                           T0023 without the jurisdiction that is no longer authorized. SAFER needs a capability to inform the
                           no-longer-authorized state and delete the transponder information associated with all vehicles owned by
                           the particular carrier. There was some discussion regarding a similar capability for adding an
                           authorized vehicle. The ACCB suggested that VOLPE update the CR to explain the process in more detail.
                           Volpe needs to modify the CR to make sure the interpretation of the request is correct and resubmit to
                           the ACCB.\
                           \
                           \[2005-11-28\] Discussed at the 11/17/05 CVISN ACCB meeting.\
                           This CR and SAFER CR 143 (Modify the XML T0029 transaction not to include records that do not have
                           transponder information) will be combined for further analysis and to develop a Business Use Case for
                           e-screening enrollment and transponder ID management to enable states to see how it ties into their
                           business processes. The Business Use Case will be presented to the ACCB for further discussion. The
                           synopsis was changed to reflect this change.\
                           \
                           \[2005-08-02\] Presented and discussed at the 7/28/05 ACCB meeting\
                           Cambridge Systems, Inc. (CSI), explained the reasoning behind the request for a delete function for the
                           T0024 transaction.\
                           \
                           • A T0023 transaction is sent to SAFER authorizing States A, C, and D to receive vehicle transponder
                           data.\
                           • A new T0023 transaction is sent to SAFER authorizing States E, C, and D to receive vehicle transponder
                           data.\
                           • Delete transponder numbers from State A's vehicles since they are no longer authorized to receive the
                           data.\
                           \
                           Volpe will look into the requirement for SAFER to send out a T0024 with blank transponder numbers to
                           delete the transponder numbers from State A's vehicle records. Volpe also suggested sending out a T0024
                           that includes the transponder numbers when a State is added to the T0023 transaction. This CR will
                           remain open pending further SAFER analysis.\
                           \
                           \[2005-06-29\] Presented and discussed at the 6/23/05 ACCB meeting.\
                           It was suggested that resending the T0023 Carrier Authorization Input Transaction (E-Screening
                           Enrollment) with a state removed would accomplish the goal of removing an authorized jurisdiction. Alana
                           Gourneau (SD) offered to talk to CSI for further information/clarification of this CR. CR remains open
                           pending further discussion.\
                           \
                           \[2005-06-21\] SAFER CR 302\
                           This change request is created to address Call \# 79695 initiated by Cambridge Systematics.\
                           \
                           During recent development work on the Electronic Screening transaction for Connecticut, Cambridge
                           Systematics described a business case scenario which SAFER does not handle in the current design of
                           SAFER.\
                           \
                           Transaction T0023 contains a list of states that the carrier authorizes SAFER to send its vehicles\'
                           transponder IDs to. If the state sends in another T0023 with one authorized state removed, does SAFER
                           send out information to that state to remove those transponders?\
                           \
                           It seems to suggest that when a carrier removes an authorized jurisdiction from the T0023 transaction
                           SAFER needs a capability to inform the state and delete the transponder information associated with all
                           vehicles owned by the particular carrier.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact on SAFER:\
                           The proposed change required a new data value added to the activity_code to reflect the revocation of an
                           authorization for a particular jurisdiction.\
                           \
                           In addition, the T0029 transaction will need to be modified to send out an update file containing empty
                           transponder information for the vehicles owned by that particular carrier.\
                           \
                           Impact on States:\
                           \
                           See list above. The state will need to use the new activity code =20 in T0023 transaction to indicate
                           the revocation of the previously authorized jurisdiction.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/21/2007 8:08:06 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          6/21/2005 8:29:46 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           9/21/2007 8:08:06 AM
  --------------------- -- --------------------------------------------------------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------
  **CR Number:**           3115

  **External               SAFER174; Arch CRs 2443,2637,2933,3039,3040,3830, 732
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Create T0031V2 transaction to send additional company information to CVISN states\
                           \
                           Summary: This transaction will be versioned to add company data to the T0031 transaction.\
                           \
                           Action: States are requested to comment as to whether there are additional MCMIS data fields they would
                           like to see added to the T0031v2 transaction not currently seen in the T0031 transaction.

  **Status:**              Closed Approved

  **Disposition:**         \[2005-09-22\] Closed Approved. In SAFER Release 4.8

  **Description:**         MMA has requested that Company OOS flag and OOS date be added to the T0031 transaction.\
                           \
                           SAFER has received OOS date and OOS flag from MCMIS since January 2005. In order for SAFER to deliver
                           new data elements, a new version of the T0031 transaction will be created. States interested in
                           receiving the new data elements will be required to change their XML schema and the program to accept
                           the new data from the new T0031 transaction. States not interested in receiving those data will continue
                           to use the current version of T0031.\
                           \
                           \[2005-04-25\] Presented and discussed at the ACCB meeting on 2005-04-21.\
                           This transaction will be versioned to add additional MCMIS data fields to the transaction (T0031v2).
                           States will only have to make modifications to their systems if they want these fields. Volpe asked the
                           states if there are other MCMIS data fields that should be included in the new transaction. This CR will
                           be posted to the CVISN System Architects list serv for comment and review.\
                           \
                           \[2005-05-34\] Presented and discussed at the ACCB meeting on 2005-05-19.\
                           Volpe has additional data fields that could be added to this transaction. They will update the CR and
                           post it to the CVISN Systems Architect list serv for comment by the states. Architecture CR 3040 (SAFER
                           152) - Add Carrier OOS data to the carrier snapshot, and Architecture 2933 (SAFER 124) - New values for
                           REIVEW_REASON_NOT_RATED were recommended for FMCSA approval late last year as a versioned T0031. It was
                           suggested that both of these CRs be closed and incorporated into Arch CR 3115.\
                           \
                           \[2005-05-27\] Jingfei Wu (Volpe) posted the following updates to SAFER CR 174 (Arch CR 3115) to the
                           list serv.\
                           Since 01/04, the company snapshot has been modified a couple times to accept the new data elements from
                           MCMIS. However T0031 has not been updated to reflect the new changes, although the CRs have been created
                           for them. At the ACCB meeting of May 2005, the states suggested combining all related CRs into the
                           current CR, which is SAFER CR174. All new data elements that SAFER is receiving from MCMIS will be
                           included in the T0031v2 transaction.\
                           \
                           Therefore, the following data elements will be added into the new version of the T0031 transaction
                           called T0031v2:\
                           OOS data\
                           HM Safety Permit data\
                           New Entrant Code\
                           New values for Review_Type\
                           New values for Review_Reason_Not_Rated\
                           \
                           The following CRs will be closed and referenced to CR 3115 (SAFER CR 174) for future status updates: CR
                           3039 (SAFER CR144), CR 3040 (SAFER CR 152), CR 2933 (SAFER CR 124), CR 2443 (SAFER CR 12).\
                           \
                           \[2005-06-29\] Discussed at the 6/23/05 ACCB meeting.\
                           OK requested that the new MCS150 data elements be added to T0031V2 MCMIS Safety and Census Update Output
                           Transaction. This would require MCMIS work and needs FMCSA approval. SAFER CR 109 addresses the MCS150
                           fields and remains open pending further discussion with the MCMIS team. Action Item: Terri Ungerman (OK)
                           will compile a list of the new MCS150 elements that are not contained in the T0031v2 MCMIS Safety and
                           Census Update Output Transaction and will send the list to Volpe.\
                           \
                           OK also requested that T0031V2 contain a count of how many inspections, conducted within the last 24
                           months, included overweight enforcement. Volpe said that this could be accomplished during the weekly
                           MCMIS load by adding it to the program that performs the counts. This would require additional MCMIS
                           work.\
                           \
                           \[2005-07-25\] Architecture CR 2637 (SAFER CR109) will be closed and referenced to CR 3115 for future
                           updates.\
                           \
                           \[2005-07-25\] Volpe replaced description for SAFER CR 174, new description follows.\
                           During the past year, the company snapshot (former carrier snapshot) has been modified a couple times to
                           include the new data elements in the data transferring process coming from MCMIS to SAFER. These new
                           data are displayed through the SAFER web site to the general public and enforcement users, however,
                           these data are not available for the XML CVIEW states via the Carrier Safety and Census output
                           transaction (T0031). In the past, some states have requested adding certain data to the T0031
                           transactions, and these requests have been documented in CR144 (Arch 3039), CR152 (Arch 3040), CR124
                           (Arch 2933), CR109 (Arch 2637), CR12 (Arch 2443).\
                           \
                           In order to support the forthcoming new company snapshot changes and provide the CVIEW users new data
                           that are consistent with those displayed on the SAFER web site, it was decided to consolidate all
                           previous Change Requests that are related to the company snapshot/T0031 changes into this Change
                           Request. Upon approval by FMCSA, a new version of the T0031 transaction will be implemented in SAFER to
                           include all new data that SAFER receives and will receive from MCMIS but not yet in the current T0031
                           transaction. The following is the proposed list of the new data fields that will be added to the T0031V2
                           transaction in the SAFER 4.8 release in September:\
                           \
                           \* OOS data\
                           \* HM Safety Permit data\
                           \* New Entrant Code\
                           \* New values for Review_Type,\
                           \* New values for Review_Reason_Not_Rated\
                           \* MCS-150 new data elements \[See notes below from CR 2637\]\
                           \* Registrant carrier\
                           \* Tow away carrier\
                           \* cargo tank only carrier\
                           \
                           States interested in receiving the new data elements through T0031V2 will need to change the CVIEW
                           programs and use the new XML schema T0031v2. States not interested in receiving these data can continue
                           to use the current version of T0031 without making any changes.\
                           \
                           The Volpe Center is asking the CVIEW users to review the proposed data fields listed above to see if the
                           CR has captured your data requests and if any there is any additional data you would like to add to the
                           T0031V2 transaction.\
                           \
                           \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\
                           MCS-150 New Values (from Arch CR 2637):\
                           \[2004-06-29\] At the 6/23/05 ACCB meeting, Terri Ungerman (OK) to look into the data elements on the
                           MCS150 form that don\'t appear to be in the T0031. The hope is that any missing items could be added to
                           the T0031 when it is revised. The results are listed below.\
                           \
                           1. Field 14 on the MCS150 form (Principal Contact Cellular Phone Number). This may be referred to by the
                           LU User ID in the T0031, but it wasn\'t clear to me that it is referencing the same data.\
                           \
                           2. Field 21 on the MCS150 form includes options to circle E.Intrastate Shipper and F. Vehicle
                           Registration Only. In the T0031 it appears that there is a field for Intrastate Shipper - HM, and a
                           field for Hazmat status but I\'m not sure how these correspond with item E on the MCS 150. There
                           doesn\'t appear to be any field in the T0031 to accommodate F. Vehicle Registration Only.\
                           \
                           3. Field 26 of the MCS150 is a table of values. In the T0031 it appears the totals for some of the
                           columns are provided for, but not the individual table entries.\
                           \
                           4. Field 27 of the MCS150 is also a table where the T0031 appears to provide the column totals but not
                           individual values.\
                           \
                           5. There doesn\'t appear to be places in the T0031 where the officer names are provided as shown on the
                           MCS 150 form field 29.\
                           \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\
                           \
                           \[2005-08-02\] Presented and discussed at the 7/28/05 ACCB meeting\
                           The design document for T0031v2 will be sent to FMCSA for review next week. Volpe will consult the MCMIS
                           team as to the feasibility of adding the count of how many inspections in the last 24 months had the
                           OS/OW field checked and report at the next ACCB meeting. Recommended for FMCSA approval.\
                           \
                           \[2005-08-19\] Discussed at the 8/18/05 ACCB meeting\
                           Volpe checked with the MCMIS team concerning the request for the count of how many inspections in the
                           last 24 months had the OS/OW field checked. There is no such field at this time, and it will require a
                           new calculation. Therefore, this item will be removed from CR 3115, and new Architecture and SAFER CRs
                           will be created for it. CR 3115 will be included in the October 3 release.\
                           \
                           \[2005-09-22\] Discussed as part of SAFER 4.8 Release. Incorporated CR 732 into this CR.\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact on SAFER:\
                           \
                           \
                           Impact on States: States interested in receiving the new data elements through T0031V2 will need to
                           change the CVIEW programs and use the new XML schema T0031v2. States not interested in receiving those
                           data can continue to use the current version of T0031 without making any changes.\
                           \
                           \
                           Impact on architecture:\
                           \
                           \
                           Impact on documentation:

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       10/3/2005 11:02:44 AM

  **Modified By:**         Roberts Onna Beth

  **Entered On:**          4/15/2005 9:36:52 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           10/3/2005 11:02:03 AM
  --------------------- -- --------------------------------------------------------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------
  **CR Number:**           3114

  **External               SAFER CR 173, SCR 18
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Enhance T0032 transaction to include additional company information.\
                           \
                           Summary: This transaction will be versioned to add additional company information to the L&I
                           transaction.\
                           \
                           Action: States are requested to comment as to whether there are additional L&I data fields they would
                           like to see added to the T0032v2 transaction not currently seen in the T0032 transaction.

  **Status:**              Closed Approved

  **Disposition:**         \[2007-01-23\] Approved by J. Secrist. Scheduled for SAFER 5.3.

  **Description:**         Missouri has requested that the following data elements be added to the T0032 transaction:\
                           \-\--Add the carrier\'s business street, business city, business state, and business zip to the T0032
                           xml file. \-\--Add BOC3 yes or no indicator to the T0032 XML file.\
                           \-\--Add Blanket Company field to the T0032 XML file.\
                           \-\--Dependent upon the criteria of the statuses, we might need a status effective date for the
                           Common_Auth_Status and Contract_Auth_Status fields if the status and the dates are not timed properly.\
                           \
                           General statements from Missouri:\
                           Missouri is implementing a new web-based system for a one-stop shop and would like to use federal data
                           for filing requirements for the Single State Registration Program. If we have sufficient information, we
                           can continue to monitor federal data and use the data without additional filing requirements in our
                           state. This would allow us to know immediately when the federal authority is inactive and can take the
                           same action at the state level in conjunction with our credentials issued. In order to use this data, we
                           believe that additional data elements for this program are needed as outlined below.\
                           \
                           The T0032 file, which contains information about authority granted under the MC number, does not contain
                           the business address. This address which is defined as the carrier\'s principle place of business where
                           their headquarters are located, is needed within this file for use by states under the SSRS program
                           because some reciprocity agreements waive fees based on principle place of business. I know that a
                           physical address is in the T0031 file address, and although in most instances is the same address as
                           what would be shown in the T0032 file, it has a different definition. That address is defined as where
                           the safety records are maintained and can be made available. In Missouri\'s experience, for the most
                           part, these two addresses are the same. We have found, however, that they can be, and in some cases are,
                           different and must be respected as different. This makes it more important that we have the right
                           address with the right definition. States can get into trouble if we either collect or fail to collect
                           proper fees for other jurisdictions.\
                           \
                           Also, in looking historically at the Licensing and Insurance file, we find that the status of the
                           carrier shows ACTIVE and the BOC3 file shows \"NO\" quite often. This tells us that the BOC3
                           requirements are not being met and the carrier is in noncompliance even though the status is ACTIVE.
                           What would be helpful to Missouri is to have that field in the T0032 file along with the Blanket Company
                           field. We could then police that requirement and have the carrier file it when it is not on file. If we
                           could rely on the data to be filed when it should be, we would not need this information.\
                           \
                           \[2005-04-25\] Presented and discussed at the ACCB meeting on 2005-04-21.\
                           This transaction will be versioned to add additional company information to the transaction (T0032v2).
                           States will only have to make modifications to their systems if they want these fields. Volpe asked the
                           states if there are other L&I data fields that should be included in the new transaction. This CR will
                           be posted to the CVISN System Architects list serv for comment and review.\
                           \
                           \[2005-05-04\] Wisconsin posted the following request for additional data fields via the CVISN System
                           Architects list serv.\
                           From enforcement: Not sure what\'s there now, but we will need to have real-time access to operating
                           authority information for ALL carriers. The FMCSA requires that we place carriers operating without
                           authority or beyond the scope of their authority out-of-service at the roadside.\
                           From Insurance/Authority/SSRS program: It would be nice if we had accurate information on true legal
                           name, company officers, EIN number and when they are revoked what is the specific reason why.\
                           \
                           \[2005-05-24\] Presented and discussed at the ACCB meeting on 2005-05-19.\
                           Volpe will check on the availability of the additional fields requested by WI. The CR was recommended
                           for FMCSA approval.\
                           \
                           \[2005-05-27\] Volpe\'s response (via list serv) to additional fields requested by WI:\
                           After checking with the L&I team, it appears that ownership/company officers and EIN are stored in
                           MCMIS. SAFER currently gets EIN from MCMIS via the MCMIS load program but not ownership/company
                           officers. We need to add ownership/company officers to the company snapshot in order to get the data
                           from MCMIS. SAFER also receives the legal name from MCMIS, not L&I, but they are the same legal name. If
                           you could verify that this is the legal name you are asking for, that would be great.\
                           \
                           Operating authority does not apply to \"ALL carriers\" but only to for-hire, which is a small subset. As
                           far as L&I goes, they are only revoked because of insurance lapses.\
                           \
                           \[2005-06-29\] Presented for informational purposes at 6/23/05 ACCB meeting.\
                           This CR was presented for informational purposes only since it was already recommended for FMCSA
                           approval last month. Volpe responded to WI\'s request for additional fields in the T0032 Licensing and
                           Insurance Update transaction. EIN and ownership/company officers are currently stored in MCMIS. SAFER
                           currently gets EIN from MCMIS via the MCMIS load program but not ownership/company officers. Volpe would
                           need to add ownership/company officers to the company snapshot in order to get the data from MCMIS.
                           Volpe suggested that since the snapshots were being changed, the additional fields should be requested
                           from MCMIS. These fields will be incorporated in the T0031V2 MCMIS Safety and Census Update Output
                           Transaction under CR 3115.\
                           \
                           \[2006-03-21\]\
                           This is an August release candidate for T0032 transaction.\
                           \
                           \[2006-05-04\] Presented at 4/20/06 ACCB meeting.\
                           The enhancements will be incorporated in the T0032v2 transaction.\
                           \
                           \[2006-10-19\] Status reported at the 10/19/06 ACCB meeting. Volpe will discuss FY07 implementation of
                           this capability with FMCSA. It will need coordination with L&I.\
                           \
                           \[2007-01-23\] Approved by J. Secrist. Scheduled for SAFER 5.3.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact on SAFER:\
                           \
                           \
                           Impact on States:\
                           \
                           \
                           Impact on architecture:\
                           \
                           \
                           Impact on documentation:

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/19/2008 12:32:25 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          4/15/2005 9:32:35 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           5/7/2007 4:50:36 PM
  --------------------- -- --------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           3094

  **External               SAFER CR 164
  Reference:**             

  **Category:**            SAFER XML, EDI

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Add a check constraint to SAFER for the value of
                           IRP_WEIGHT_CARRIED.

  **Status:**              Closed Approved

  **Disposition:**         \[2006-09-18\] Closed; incorporated into SAFER Release
                           5.1.

  **Description:**         \[2005-02-14\] contents from Volpe CR 164\
                           This CR is created for a defect identified by MDCVIEW &
                           APLCVIEW. Some vehicle data provided by SAFER has
                           IRP_Weight_Carried with a null, blank or zero value. It is
                           suggested that there should be a constraint for the value
                           of IRP_Weight_Carried submitted from CVIEW.\
                           \
                           If Vehicle_IRP_Juris.IRP_Jurisdiction is not null, the
                           Vehicle_IRP_Juris.IRP_Weight_Carried must be a number
                           greater than 10,000. Blank, null and zero weights should
                           not be allowed.\
                           \
                           In the current design of SAFER,
                           Vehicle_IRP_Juris.IRP_Jurisdiction and
                           Vehicle_IRP_Juris.IRP_Weight_Carried are both mandatory
                           fields for XML input. However there is no specific
                           requirement for the input value. The datatype of
                           Vehicle_IRP_Juris.IRP_Weight_Carried is Varchar(8) which
                           allows blank, null and zero values to exist in SAFER.\
                           \
                           Volpe will perform technical analysis to determine whether
                           the value checking shall be implemented during the input
                           process or at the database level.\
                           \
                           \[2005-03-01\] Presented and discussed at the 2/17/05 ACCB
                           meeting.\
                           Volpe pointed out that SAFER release 4.9 will already make
                           this a mandatory field whenever a jurisdiction is
                           provided, which meets a significant objective of the CR.
                           The remaining significant issue is to block zero values.
                           The ACCB decided that this CR could be incorporated into
                           SAFER CR 139 (Arch CR 3013): Standardization of data
                           values in XML input transactions and will be discussed at
                           the next ACCB meeting.\
                           \
                           This CR was therefore disapproved and closed\
                           \
                           \[2006-03-30\] Presented at the 2006-03-23 ACCB meeting.\
                           No edit checks are done on this element, so that zero,
                           null or blank weights are possible. This data element
                           holds the \"cab card weight\" for each jurisdiction, and
                           the value is used for e-screening. The original response
                           to the CR included a lower bound of 10,000 pounds, but,
                           after discussion, it was decided to simply require a
                           numerical value greater than zero. The ACCB originally
                           closed this CR in February, 2005, and included the
                           contents in SAFER CR 139/Architecture CR 3013. Both CRs
                           will be re-opened in their original state instead of
                           including this problem in the new Phase 2 CR for 139/3013.
                           This CR is a candidate for SAFER Release 5.1 in August.\
                           \
                           \[2006-05-04\] Presented at the 2006-04-20 ACCB meeting.\
                           Instead of deleting the IRP_Weight_Carried limit from the
                           CR, the ACCB agreed on updating the CR to state that the
                           IRP_Weight_Carried must be a number greater than 6,000
                           pounds. This CR is a candidate for SAFER Release 5.1 in
                           August.\
                           \
                           \[2006-05-26\] Discussed at the 5/18/06 ACCB meeting.\
                           Volpe updated this CR to set the constraint at 6000 lbs.
                           Some states use a lower threshold for IRP_WEIGHT_CARRIED.
                           This CR will be reposted to the listserv requesting
                           comments from the states regarding the lowest boundary
                           allowed for the edit check on IRP_WEIGHT_CARRIED.\
                           \
                           APL will re-post to the CVISN System Architects' listserv
                           asking the states to comment on what they think the lowest
                           threshold should be for the IRP_WEIGHT_CARRIED field.\
                           \
                           \[2006-06-23\] Discussed at the 6/22/06 ACCB meeting.\
                           The ACCB decided to recommend this CR for FMCSA approval,
                           setting a lower limit of 4000 pounds for
                           IRP_Weight_Carried.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       1/23/2007 12:42:52 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          2/14/2005 3:46:44 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           9/18/2006 6:58:18 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- -----------------------------------------------------------------------
  **CR Number:**           3041

  **External               SAFER CR 149
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Business rule check for T0024.\
                           \
                           Summary: Ensure that the Safety USDOT number in the vehicle
                           registration table matches the carrier ID in the carrier authorization
                           table.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2004-12-16\] Closed - not an architecture CR

  **Description:**         \[2004-11-23\]\
                           Implement a business rule in T0024 (vehicle transponder ID input
                           transaction) to validate that the Safety USDOT number
                           (CVIS_DEFAULT_CARIER) in the vehicle registration table (based on the
                           VIN provided in the T0024) matches the USDOT number in the carrier
                           authorization table (CARRIER_ID_NUMBER from the T0023 transaction,
                           carrier escreening authorization input transaction).\
                           \
                           The current T0029 (vehicle transponder output transaction) requires
                           that the Safety USDOT number in the vehicle registration table match
                           the carrier ID number in the carrier authorization table, therefore
                           failure to match will result in transponder data not being sent out.\
                           \
                           \[2004-11-22\] Presented and discussed at the ACCB meeting on
                           2004-11-18.\
                           Volpe is continuing their analysis of this CR.\
                           \
                           \[2004-12-16\] It was decided this is not really an architecture CR so
                           the architecture CR will be closed. The SAFER CR remains open.\
                           \
                           Impact on architecture:\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       12/16/2004 3:06:52 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          11/16/2004 7:25:53 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           12/16/2004 3:06:52 PM
  --------------------- -- -----------------------------------------------------------------------

  --------------------- -- -----------------------------------------------------------------------
  **CR Number:**           3040

  **External               SAFER CR 152
  Reference:**             

  **Category:**            SAFER carrier snapshot

  **Component:**           SAFER/MCMIS

  **Synopsis:**            Add carrier out-of-service data to the carrier snapshot\
                           \
                           Summary: New data elements related to OOS are available in MCMIS and
                           could be added to the carrier snapshot T0031. It is not known whether
                           CVISN stakeholders would like to receive this data via the snapshot.\
                           \
                           Action: States are requested to comment as to whether the T0031 should
                           be versioned to include OOS data.\
                           \
                           Recommended for FMCSA approval as a versioned T0031.

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2005-06-17\] Closed - incorporated into CR 3115

  **Description:**         \[2004-11-16\] from Volpe CR 152\
                           FMCSA has requested that the carrier out-of-service data be added to
                           the carrier snapshot. In order for that to happen, the snapshot will be
                           revised to include the new data elements. MCMIS and SAFER will modify
                           the loading program to support the changes.\
                           \
                           Once implemented, ISS, SAFETYNET and SAFER web will be receiving OOS
                           data through SAFER.\
                           \
                           \[2004-11-22\] Presented and discussed at the ACCB meeting on
                           2004-11-18.\
                           Volpe is preparing documentation on the OOS data elements that are
                           available. APL will post the CR to the CVISN System Architects list
                           serv for comments to see if the states want to receive this data.\
                           \
                           \[2004-12-16\] Presented at the ACCB meeting on 2004-12-16.
                           Stakeholders expressed an interest in receiving the OOS data with the
                           understanding that a new version of T0031 be developed and the current
                           T0031 continue to be available. Recommended for FMCSA approval.\
                           \
                           \[2005-06-17\] Closed - incorporated into CR 3115\
                           \
                           \
                           Impact on architecture:\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       6/21/2005 9:21:56 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          11/16/2004 7:21:43 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           6/17/2005 7:35:19 AM
  --------------------- -- -----------------------------------------------------------------------

  --------------------- -- -------------------------------------------------------------------------
  **CR Number:**           3039

  **External               SAFER CR 144
  Reference:**             

  **Category:**            SAFER ELQ

  **Component:**           SAFER/MCMIS, CVIEW, PIQ

  **Synopsis:**            Modify SAFER to accept New Entrant Code from MCMIS\
                           \
                           Summary: A new data element \"New Entrant Code\" is available in MCMIS
                           and could be added to the carrier snapshot T0031. It is not known whether
                           CVISN stakeholders would like to receive this data element via the
                           snapshot.\
                           \
                           Action: States are requested to comment as to whether the T0031 should be
                           versioned to include the New Entrant Code.\
                           \
                           Recommended for FMCSA approval as a versioned T0031.

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2005-06-17\] Closed - incorporated into CR 3115

  **Description:**         \[2004-11-16\] from Volpe CR 144\
                           A request to add the New Entrant Code data element to the SAFER database
                           Company Snapshot has been approved by FMCSA. Modifications will need to
                           be made on MCMIS and SAFER to incorporate the new code to the carrier
                           snapshot.\
                           \
                           Once implemented, ISS, SAFETYNET, PIQ, and CVISN states will be able to
                           receive the new entrant code data. The new data will be displayed on
                           SAFER Web site as well.\
                           \
                           The detailed design and analysis are attached to this CR.\
                           \
                           The estimated time on coding and testing is about 4 weeks.\
                           \
                           \[2004-11-22\] Congress has required the FMCSA to establish minimum
                           requirements for new motor carriers seeking federal interstate operating
                           authority. These minimum requirements include having the carrier certify
                           that it has systems in place to ensure compliance with the Federal Motor
                           Carrier Safety Regulations, and a safety audit conducted within the first
                           18 months of the carrier\'s interstate operation. Beginning January 1,
                           2003, all new motor carriers (private and for-hire) operating in
                           interstate commerce must apply for registration (USDOT Number) as a \"new
                           entrant\". After being issued a new entrant registration, the carrier
                           will be subject to an 18-month safety-monitoring period. During this
                           safety-monitoring period, the carrier will receive a safety audit and
                           have their roadside crash and inspection information closely evaluated.
                           The carrier will be required to demonstrate it has the necessary systems
                           in place to ensure basic safety management controls. Failure to
                           demonstrate basic safety management controls may result in the carrier
                           having their new entrant registration revoked.\
                           \
                           Presented and discussed at the ACCB meeting on 2004-11-18.\
                           APL will post the CR with the New Entrant Code attachment to the CVISN
                           System Architects list serv for comments to see if the states want to
                           receive this data.\
                           \
                           \[2004-12-16\] Presented at the ACCB meeting on 2004-12-16. Stakeholders
                           expressed an interest in receiving the codes with the understanding that
                           a new version of T0031 be developed and the current T0031 continue to be
                           available. Recommended for FMCSA approval.\
                           \
                           \[2005-06-17\] Incorporated into CR 3115.\
                           \
                           \
                           \
                           Impact on architecture:\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    SAFER Company New Entrant Code.pdf

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       6/17/2005 7:34:09 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          11/16/2004 7:18:12 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           6/17/2005 7:34:09 AM
  --------------------- -- -------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           3013

  **External               Arch CR 4651; SAFER CR 139, SAFER CR 164
  Reference:**             

  **Category:**            SAFER XML, SAFER ICD

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Standardization of data values in XML input transactions.\
                           \
                           Summary: Data elements input to SAFER must be standardized
                           to ensure data quality and integrity.

  **Status:**              Closed Approved

  **Disposition:**         \[2006-03-30\] Closed Approved

  **Description:**         \[2004-10-18\] During the 9/23 ACCB meeting Volpe led a
                           discussion regarding left-justification of the
                           CVIS_DEFAULT_CARRIER field. This is a data integrity issue
                           that applies to many data elements, especially to those
                           that could be interpreted as either character or numeric.
                           Each XML transaction needs to be reviewed, but a general
                           approach to addressing this issue is needed. Volpe will
                           write one or more CRs to address this issue. The solution
                           for the immediate problem with Nebraska registration data
                           is that Nebraska will left-justify the values in the
                           CVIS_DEFAULT_CARRIER field and re-baseline - this specific
                           instance is addressed in Arch CR 2954 (SAFER CR 138). Arch
                           CR 3013 (SAFER CR 139) addresses the general problem.\
                           \
                           \[2004-10-18\] From SAFER CR 139\
                           When searching data against the SAFER database, it has
                           brought to our attention that some key data fields
                           submitted from the XML input transactions are provided in
                           an inconsistent manner.\
                           \
                           A good example is that the IRP_ACCOUNT_NUMBER in T0020 can
                           have leading zeros, leading space and etc. Another example
                           is IRP_CARRIER_ID_NUMBER OR CVIS_DEFAULT_CARRIER in T0022
                           where leading zeros and null can be an issue to CVISN or
                           PRISM states.\
                           \
                           This CR is intended to address the need to standardize the
                           input data fields as to how the data value should be
                           provided to SAFER. The result of this effort shall improve
                           the data integrity and data quality of the SAFER
                           database.\
                           \
                           The Volpe Center is conducting technical analysis on all
                           XML input transactions and the SAFER database. Based on
                           the analysis, a draft of SAFER data requirements will be
                           developed and distributed to the stakeholders for review
                           and discussion.\
                           \
                           \[2004-10-25\] Presented and discussed at the 2004-10-21
                           ACCB meeting.\
                           This CR will be posted to the CVISN System Architects list
                           serv for review.\
                           \
                           \[2004-11-22\] Presented and discussed at the ACCB meeting
                           on 2004-11-18.\
                           Recommended for FMCSA approval. Volpe is continuing their
                           analysis of this problem and will report back. Approved
                           for Volpe to work on standards. When complete, a draft of
                           SAFER data requirements will be distributed to the
                           stakeholders for review and discussion.\
                           \
                           \[2005-03-01\]\
                           Contents of SAFER CR 164: This CR is created for a defect
                           identified by MDCVIEW & APLCVIEW. Some vehicle data
                           provided by SAFER has IRP_Weight_Carried with a null,
                           blank or zero value. It is suggested that there should be
                           a constraint for the value of IRP_Weight_Carried submitted
                           from CVIEW.\
                           \
                           If Vehicle_IRP_Juris.IRP_Jurisdiction is not null, the
                           Vehicle_IRP_Juris.IRP_Weight_Carried must be a number
                           greater than 10,000. Blank, null and zero weights should
                           not be allowed.\
                           \
                           In the current design of SAFER,
                           Vehicle_IRP_Juris.IRP_Jurisdiction and
                           Vehicle_IRP_Juris.IRP_Weight_Carried are both mandatory
                           fields for XML input. However there is no specific
                           requirement for the input value. The datatype of
                           Vehicle_IRP_Juris.IRP_Weight_Carried is Varchar(8) which
                           allows blank, null and zero values to exist in SAFER.\
                           \
                           Volpe will perform technical analysis to determine whether
                           the value checking shall be implemented during the input
                           process or at the database level.\
                           \-\-\-\-\-\-\-\--End SAFER CR 164\
                           \
                           \[2005-03-01\] Architecture CR 3094 (SAFER CR 164) was
                           presented and discussed at the 2/17/05 ACCB meeting.\
                           Volpe pointed out that SAFER release 4.9 will already make
                           this a mandatory field whenever a jurisdiction is
                           provided, which meets a significant objective of the CR.
                           The remaining significant issue is to block zero values.
                           The ACCB decided that this CR could be incorporated into
                           SAFER CR 139 (Arch CR 3013): Standardization of data
                           values in XML input transactions and will be discussed at
                           the next ACCB meeting.\
                           \
                           \[2005-03-21\] SAFER CR 139 was presented and discussed at
                           the 3/17/05 ACCB meeting.\
                           Volpe took a first cut at standardizing data elements by
                           looking at the key identifiers in transactions T0019,
                           T0020, T0021, T0022 and T0024 and presented an Excel
                           spreadsheet to the ACCB. The key identifiers potentially
                           handle numbers in the input files with varchar2 as the
                           data type in the database. Leading zeroes/spaces, trailing
                           spaces and nulls are a common problem. It was mentioned
                           that some states use leading zeroes as part of the number,
                           such as, IRP_account_number. Others use special characters
                           in the License_plate_number. States suggested taking the
                           spreadsheet back to their IRP folks for review and then
                           providing feedback to Volpe. The spreadsheet is attached.\
                           \
                           \[2005-04-25\] Presented at the 4/21/05 ACCB meeting.\
                           Volpe will compile the comments received and continue
                           their analysis of the CR. States are encouraged to review
                           the excel spreadsheet and send comments via the list
                           serv.\
                           \
                           \[2005-08-02\] Presented at the 7/28/05 ACCB meeting.\
                           Seven states have commented on Volpe's proposed solution,
                           which was posted to the list serv after the June ACCB
                           meeting. Volpe will post the updated spreadsheet to the
                           CVISN System Architects list serv and solicit a final
                           round of comments.\
                           \
                           \[2005-08-05\] Jingfei Wu (Volpe) posted the following to
                           the CVISN System Architects list serv:\
                           \"Enclosed is the latest spreadsheet containing the
                           states\' comments on the proposed standardization
                           solution. Since this will be the final round of posting,
                           states are recommended to submit any suggestions they
                           might have to the Volpe Center.\"\
                           The spreadsheet has been attached to this CR.\
                           \
                           \[2005-08-19\] Discussed at the 8/18/05 ACCB meeting\
                           The spreadsheet will be updated with additional comments
                           received from Maryland and Texas. Volpe will post the
                           updated spreadsheet to the CVISN System Architects list
                           serv. There will be some consideration as to how existing
                           standards can be incorporated into the spreadsheet.\
                           \
                           \[2005-09-22\] Discussed at the 9/22/05 ACCB meeting\
                           Andrew Wilson discussed a new Summary Spreadsheet that
                           Volpe developed based on the spreadsheet containing all of
                           the state's comments. He proposed to consolidate today\'s
                           discussion to include three main suggestions:\
                           1. Take out leading and trailing spaces.\
                           2. Allow leading zeroes in some fields.\
                           3. Eliminate leading zeroes where the carrier_id_number is
                           used.\
                           \
                           \[2005-12-20\] Volpe\'s summary of the discussion and
                           comments from the CVISN ACCB state participants:\
                           \"The common data problem in the XML input transactions
                           are found to be leading zeroes, leading spaces, trailing
                           spaces, zeroes and null. When the data for the same fields
                           are inconsistently provided through different transactions
                           containing this sort of data problem, users are not be
                           able to perform query join to generate meaningful reports.
                           The ACCB has suggested SAFER to programmatically remove
                           them without changing the data provided by the states. The
                           following is the list of requirement that SAFER needs to
                           implement in order to address the data format issues:\
                           \
                           1. Remove leading and trailing spaces for all key fields
                           listed in the spreadsheet: CR3013-SAFER139_data
                           standardization_102505.xls.\
                           2. Allow leading zeroes in these fields such as
                           IFTA_license_number, Fleet_number, IRP_account_number,
                           VIN, and license_plate_number.\
                           3. Eliminate leading zeroes where USDOT number is used
                           such as carrier_id_number and SAFETY_carrier.\
                           \
                           Data fields such as VIN and license plate number may have
                           special characters as part of the data. SAFER will
                           implement validation check against the existing standards.
                           SAFER will also perform validation for USDOT number
                           against the MCMIS data source which is the authoritative
                           source for the carrier information. \"\
                           \[end Volpe summary 12/20/05\] See also 12/19/05
                           spreadsheet attachment\
                           \
                           \[2006-01-05\] Presented and discussed at the 12/22/05
                           ACCB meeting.\
                           The ACCB decided that states will be required to recertify
                           based on the new data standards and re-baseline their data
                           in order to improve data quality in SAFER. This CR will be
                           implemented in SAFER Release 5.0 due out in late February
                           2006. The new data standards will be enforced for each
                           state as they recertify. After recertification, SAFER will
                           reject the records that do not conform to the new data
                           standards.\
                           \
                           \[2006-01-25\] Presented and discussed at the 1/19/06 ACCB
                           meeting.\
                           VIN validation was the topic of discussion for this CR.
                           Jingfei Wu (Volpe) pointed out that only the data
                           formatting rules will be enforced, and the IFTA/IRP/VIN
                           validation will be in the following release of SAFER after
                           receiving comments from stakeholders. Some states
                           expressed an interest in getting a warning for invalid
                           VINs instead of rejections. Validation is done at the
                           jurisdiction site because of home-made VINs that the state
                           considers valid. These VINs would fail the VIN validation
                           routine at SAFER. It was suggested that states send their
                           VIN patterns to Volpe so SAFER can check against those as
                           well. Phase 1 of the implementation will be to enforce the
                           edit checks for the formatting rules listed in the
                           specification document. After a state is recertified, the
                           rules will be enforced for that state. Phase 2 of this CR
                           will enforce IFTA/IRP/VIN validation.\
                           \
                           Phase 1 will be implemented in the February 2006 release
                           of SAFER v5.0. The SAFER CR 139 Specification has been
                           added as an attachment to this CR.\
                           \
                           \[2006-03-23\] Presented at the 2006-03-23 ACCB meeting.\
                           Phase 1 of this CR was released in SAFER 5.0. Edit checks
                           are in place, and states need to recertify their CVIEWs by
                           the end of the Calendar Year 2006. The VIN/IRP account /
                           IFTA account validation checks will be implemented in
                           Phase 2. Iteris asked if the states will have to recertify
                           again when Phase 2 is released. Volpe said yes. States
                           asked if Phase 2 validation rules would cause SAFER to
                           reject the records. Volpe said that would be up to the
                           stakeholders. If the stakeholders only want a warning and
                           not a rejection, then recertification wouldn't be
                           necessary. This CR will be closed, and the Phase 2 changes
                           will be documented in new Architecture and SAFER CRs.\
                           \
                           \[2006-04-19\] CR 4651 created to cover Phase 2 changes\
                           \
                           \[2006-05-04\] 4/20/06 ACCB meeting.\
                           This CR was closed, and the Phase 2 (VIN/IRP/IFTA)
                           validation checks will be documented in Architecture CR
                           4651 (SAFER CR 705) "Implement VIN, IRP Account and IFTA
                           Account validation for SAFER XML Service input
                           transaction".\
                           \
                           \[2006-05-15\] Volpe changed the wording of SAFER CR 164
                           to the following:\
                           Synopsis: Add a check constrain to IRP_weight_carried\
                           \"This CR is created for an enhancement suggested by
                           MDCVIEW & APLCVIEW. At the April 2006 ACCB discussion,
                           stakeholders have provided detail information regarding
                           the edit check for IRP_weight_carried. The previous
                           description of the CR has been moved to the comments tab.
                           The follow is the updated describtion of this CR. In the
                           current SAFER system, IRP_weight_Carried is a mandatory
                           field in T0022 transaction. However there is no specific
                           requirement for the input value. The datatype of
                           Vehicle_IRP_Juris.IRP_Weight_Carried is Varchar(2) which
                           allows blank, null and zero to exist in SAFER. The
                           stakeholders suggested to implement an edit check for
                           IRP_weight_carried to improve the data quality in SAFER.
                           The edits shall mandate the IRP_Weight_Carried is a number
                           greater than 6,000 pounds. Blank, null and zero should not
                           be allowed.\"

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CR139_data standardization.xls\
                           2004-05-20 CR3013-SAFER139_data
                           standardization_Comments.xls\
                           2004-05-21 CR3013-SAFER139_data
                           standardization_Comments.xls\
                           2005-12-19 CR3013-SAFER139_data
                           standardization_Comments.xls\
                           2006-01-25_CR 139 Specification.doc

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       5/15/2006 10:42:59 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          10/18/2004 2:19:57 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           3/30/2006 7:33:40 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           3012

  **External               SAFER CR 119
  Reference:**             

  **Category:**            Inspection reports

  **Component:**           SAFER

  **Synopsis:**            Expand the inspection report storage in SAFER to 180 days

  **Status:**              Closed Approved

  **Disposition:**         \[2004-10-25\] Closed; incorporated into SAFER release 4.6

  **Description:**         \[2004-10-18\] From SAFER CR 119\
                           FMCSA requested the retention time for Inspection Reports
                           be doubled from 90 days to 180 days.\
                           \
                           The change was approved by Janet Curtis and Jeff Hall,
                           7/15/04.\
                           \
                           It was incorporated into SAFER 4.6 and put in production
                           as of 09/07 2004.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact on documentation: (note: none of these documents
                           are maintained.)\
                           ACCB Documents Affected:\
                           Snapshot White Paper\
                           COACH Part 1\
                           COACH Part 3\
                           COACH Part 5\
                           Other Documents Affected:\
                           CVISN Guide to Safety Information Exchange\
                           SCOPE Workshop - Session 5

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       10/25/2004 1:37:55 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          10/18/2004 8:11:12 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           10/25/2004 1:37:55 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           3011

  **External               SAFER CR 112
  Reference:**             

  **Category:**            SAFER ELQ service

  **Component:**           SAFER

  **Synopsis:**            Add third possible value \"U\" to post crash field

  **Status:**              Closed Approved

  **Disposition:**         \[2004-10-18\] Incorporated in SAFER release 4.6

  **Description:**         \[2004-10-18\] from SAFER CR 112\
                           In order to support Query Central and PIQ post crash
                           processing:\
                           1) Add the third value \"U\" for unknown\
                           2) Change the code so that SAFER stores\"Y\", \"N\" or
                           \"U\" instead of \"0\" or \"1\", in order to support Query
                           Central. (this part of the CR has been subsumed by a new
                           CR, #117)\
                           \
                           Attached \[to the SAFER CR\] is the email from Gary
                           Talpers requesting the change.\
                           \
                           The estimated time to design, code and test this CR is
                           about 60 hours.\
                           \
                           FMCSA has determined how the post crash will be
                           interpreted:\
                           OOS violation existed prior to crash = counts in SafeStat\
                           OOS violation resulted from crash = does not count in
                           SafeStat\
                           Inspector can\'t determine = does not count.\
                           \
                           This CR has been approved \[by Janet Curtis, FMCSA,
                           8/23/04\] and will be implemented in SAFER 4.6 in
                           September.\
                           \
                           \*\*\*\*\[2004-11-11\] Note - requested by the roadside
                           system and is displayed in PIQ. Doesn\'t show up in CVISN
                           transactions. There is some question whether or not this
                           should be an Arch CR.\
                           \
                           OBR-Closed. In Release 4.6\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact on SAFER:\
                           \
                           \
                           Impact on States:\
                           \
                           \
                           Impact on architecture:\
                           \
                           \
                           Impact on documentation:

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/21/2006 11:52:04 AM

  **Modified By:**         Roberts Onna Beth

  **Entered On:**          10/18/2004 8:09:44 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           3/21/2006 11:52:04 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2954

  **External               SAFER CR 131; ARC CR 2728; SAFER CR 138
  Reference:**             

  **Category:**            Mandatory Data Elements for T0022 and T0028

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Volpe is reviewing the mandatory data elements in T0022 to
                           see if there is a need to change some of the optional
                           fields to mandatory so they provide meaningful information
                           to the states.\
                           \
                           Summary: The vehicle registration data currently in SAFER
                           comes from three kinds of input: PRISM PVF file, CVISN EDI
                           input, and XML T0022 transaction. Although the processing
                           logic of XML, EDI and PVF data files are similar, the
                           required data elements are different. Some of the
                           mandatory fields are commonly required by all three data
                           submissions, and others are only mandatory for one source
                           but not for the other sources.\
                           \
                           Proposal: Data elements in XML T0022 transaction will be
                           made mandatory, conditional mandatory, or optional as
                           indicated in the attached table.

  **Status:**              Closed Approved

  **Disposition:**         \[2005-10\] Closed - implemented in SAFER 4.8

  **Description:**         \[2004-09-16\] Volpe supplied SAFER CR 131 (description
                           follows) in response to action item #4 of the 8/19 ACCB
                           meeting.\
                           The vehicle registration data currently in SAFER comes
                           from three kinds of input: PRISM PVF file, CVISN EDI
                           input, and XML T0022 transaction. Although the processing
                           logic of XML, EDI and PVF data files are similar, the
                           required data elements are different. Some of the
                           mandatory fields are commonly required by all three data
                           submissions, and others are only mandatory for one source
                           but not for the other sources.\
                           \
                           Volpe is reviewing the mandatory data elements in T0022 to
                           see if there is a need to change some of the optional
                           fields to mandatory so they provide meaningful information
                           to the states. For example, if states provide values for
                           REGISTRATION_START_DATE, states would be able to determine
                           the current base state for an operating vehicle by looking
                           at REGISTRATION_START_DATE and IRP_BASE_STATE. In other
                           instances, potential data collisions would have been
                           avoided if SAFER and PRISM both provided values for the
                           same list of required fields. There is concern that
                           authoritative data source and non-authoritative data
                           source could overwrite each other\'s data.\
                           \
                           The attached table (PDF file) is the proposed list of
                           mandatory fields for XML T0022. The list was produced by
                           merging the required fields being used by CVISN including
                           E-Screening and PRISM. The Volpe Center recommends that
                           CVISN states and PRISM states review the required field
                           list to see whether or not the fields need to be converted
                           and whether or not it is feasible to provide the data for
                           those required fields.\
                           \
                           The advantages of having all input transactions populating
                           the common mandatory fields are listed below:\
                           1. A single XML transaction would support both CVISN and
                           PRISM program. Therefore there would be no need to develop
                           a new variant transaction of T0022.\
                           2. There would be no potential data collision since the
                           updates from all data sources would provide the values for
                           the same list of mandatory fields.\
                           3. It would address concerns raised by Washington State in
                           CR 2728 so that one would be able to determine the current
                           base state of an operating vehicle.\
                           \
                           \[2004-09-27\] Presented and discussed at the 2004-09-23
                           ACCB meeting.\
                           Volpe is reviewing the mandatory data elements in T0022 to
                           see if there is a need to change some of the optional
                           fields to mandatory so they provide meaningful information
                           to the states. The list was discussed and modified. One
                           question discussed was whether there should be a
                           \"conditional mandatory\", to handle cases such as Alaska
                           and Hawaii being exempt from IRP, certain fields be
                           mandatory for PRISM only, etc. Sharon Holland,
                           representing Alaska, proposed that fake data be submitted
                           for IRP state/weight for Alaska. The updated list will be
                           posted to the CVISN System Architects list serv.\
                           \
                           \[2004-10-18\] At the 9/23 ACCB meeting Volpe led a
                           discussion regarding left-justification of the
                           CVIS_DEFAULT_CARRIER field. This is a data integrity issue
                           that applies to many data elements, especially to those
                           that could be interpreted as either character or numeric.
                           The solution for the immediate problem with Nebraska
                           registration data is that Nebraska will left-justify the
                           values in the CVIS_DEFAULT_CARRIER field and re-baseline.
                           Volpe created SAFER CR 138 to address this specific
                           instance. SAFER CR 139 was created to address the problem
                           in general.\
                           \
                           \[2004-10-25\] Presented and discussed at the 2004-10-21
                           ACCB meeting.\
                           I was decided that REGISTRATION_START_DATE should be
                           mandatory because it is used by states to determine which
                           registration is the most current. In addition,
                           IRP_WEIGHT_EXPIRE_DATE will be mandatory. The T0022
                           mandatory/optional list will be updated to reflect this
                           and will be reposted to the list serv. CR 2954 will be
                           posted to the CVISN System Architects list serv for
                           comments and will be voted on at the November ACCB.\
                           \
                           \[2004-11-22\] Presented and discussed at the ACCB meeting
                           on 2004-11-18.\
                           The use of IRP_Carrier_ID_Number and SAFETY_CARRIER was
                           discussed. The IRP_CARRIER_ID_NUMBER indicates ownership
                           and is the IRP applicant. However, list serv and meeting
                           comments confirmed that not all states use this field, so
                           it should remain optional. SAFETY_CARRIER
                           (cvis_default_carrier) is the party responsible for
                           safety, generally the operator. This field should be
                           \"conditional mandatory\" because it is: optional for
                           CVISN-only states, mandatory for e-screening, and
                           mandatory for PRISM. Thus, no further changes were made to
                           the T0022 Mandatory_Optional List, and CR 2954 is
                           recommended for FMCSA approval.\
                           \
                           \[2005-10-05\] Implemented in SAFER v4.8 - closed.\
                           \
                           Impact on SAFER:\
                           1. The T0022 and T0028 schema files will need to be
                           changed.\
                           \
                           Impact on States:\
                           1. XML States will need to update corresponding schema
                           files for CVIEW.\
                           2. XML States will need to re-certify for T0022
                           transaction.\
                           3. No impact on EDI States\
                           \
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CR2954_T0022MO list.pdf\
                           CR2954_T0022MO list_V04.pdf\
                           CR2954_T0022MO list_V05.pdf\
                           CR2954_T0022MO list_V06.pdf

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       10/5/2005 10:48:40 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/16/2004 12:17:51 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/5/2005 10:48:40 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           2936

  **External               SAFER CR 348; SAFER CR 302
  Reference:**             

  **Category:**            New data element needed

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            A source, other than the authoritative source, may submit e-screening enrollment data to SAFER. States requested a data element to track the source of the transponder
                           data.\
                           \
                           Summary: Any state can update e-screening information (XML T0024). States do not object to an unauthorized state submitting transponder information for another state, as
                           long as the vehicle registration data is not affected.\
                           \
                           Proposal: Add a data element to track the source of the transponder data.

  **Status:**              Closed Approved

  **Disposition:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.

  **Description:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.\
                           \
                           \[2007-01-23\] Approved by J. Secrist. Scheduled for SAFER 7.3.\
                           \
                           \[2006-10-19\] Status reported at the 10/19/06 ACCB meeting.\
                           Implementation was deferred from SAFER 5.1 but is on the list for FY07. This CR is related to Architecture CR 3670 (SAFER CR 302). E-screening issues are being addressed
                           by the E-Screening Enrollment Focus Group, which needs to document business rules and use cases and bring that material before the ACCB.\
                           \
                           \[2006-05-26\] Discussed at the 5/18/06 ACCB meeting.\
                           Architecture CRs 2936 (e-screening data) and 2798 (IRP registration data) deal with Authoritative Source. Volpe will check with FMCSA to see if both can be incorporated
                           in SAFER Release 5.1. If not, then maybe CR 2936 can be included in 5.1 and CR 2798 in Release 5.2.\
                           \
                           \[2006-05-04\] Presented and discussed at the 4/20/06 ACCB meeting.\
                           At the March 2006 ACCB meeting, states requested that Architecture CR 2798 (SAFER CR 122), which addresses management of update authority for vehicle registration data,
                           be implemented in SAFER Release 5.1. Since Architecture CR 2936 addresses management of update authority for transponder data, states suggested that the scope of
                           Architecture CR 2798 be expanded to include other transactions, including transponder data. Volpe pointed out that the testing requirements for implementing the CR would
                           expand significantly. Volpe said that the implementation of Architecture CR 2798 (SAFER CR 122) will create audit tables only and will not involve sending output
                           transactions. Volpe will re-write these CRs. APL suggested they be kept as separate CRs, but reflect this discussion about what the states really want.\
                           \
                           \[2006-03-21\]\
                           Pending in SAFER. This is to be implemented in August release of SAFER.\
                           \
                           \[2005-08-02\]\
                           This CR was recommended for FMCSA approval in October 2004, but a SAFER CR was not written. Volpe now has created SAFER CR 348 and will discuss it with FMCSA.\
                           \
                           \[2004-10-25\] Presented and discussed at the 2004-10-21 ACCB meeting.\
                           There were no dissenting votes so the CR was recommended for FMCSA approval.\
                           \
                           \[2004-09-27\] Presented and discussed at the 2004-09-27 ACCB meeting.\
                           CR 2936 will be posted to the CVISN System Architects list serv for comments and will be voted on at the October ACCB.\
                           \
                           \[2004-08-23\] At the teleconference on 2004-08-16 to discuss CR 2798, it was noted that any state can update e-screening information (XML T0024). States did not object
                           to an unauthorized state submitting transponder information for another state, as long as the vehicle registration data is not affected. Washington requested a data
                           element to track the source of the transponder data.\
                           This was also mentioned at the 2004-08-19 ACCB meeting.\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD\
                           \
                           Impact on states:\
                           If the information is just captured in a SAFER table,none.\
                           If XML transactions are versioned to accept/report this data element, then states exchanging escreening data would need to use the versioned schemas and may need to
                           change processing.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       9/21/2007 8:05:47 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          8/23/2004 12:22:08 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           9/21/2007 8:05:47 AM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2935

  **External               SAFER CR 130, 487
  Reference:**             

  **Category:**            SAFER XML interface

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Expand scope of capability to delete a record\
                           \
                           Summary: This CR requests that the delete capability
                           (reference CR 2563) be expanded to include additional
                           transactions.\
                           \
                           Proposal: The XML delete transactions will be implemented
                           in accordance with the requirements expressed in this CR.

  **Status:**              Closed Fixed

  **Disposition:**         \[2005-07-07\] Closed fixed

  **Description:**         \[2004-08-18\] Three States responded to question posted
                           to CVISN System Architects list serv regarding expanding
                           the delete capability requested in CR 2563.\
                           \
                           Proposed Requirements\
                           \
                           - The system shall ensure that a user can only modify data
                           owned by that user.\
                           - Each delete operation shall archive the deleted data,
                           and output it in a corresponding SAFER output transaction
                           to notify CVISN participants of the deletion.\
                           - A restore operation shall be created for use by Volpe
                           should it become necessary to restore data that was
                           removed in a delete operation.\
                           \
                           This shall apply to transactions:\
                           T0019\
                           T0020\
                           T0021\
                           T0022\
                           T0023\
                           T0024\
                           \
                           \
                           \[2004-09-27\] Presented and discussed at the 2004-09-23
                           AVVB meeting.\
                           This CR will be posted to the CVISN System Architects list
                           serv for comment and will be voted on at the October ACCB
                           meeting.\
                           \
                           \[2004-10-25\] Presented and discussed at the 2004-10-25
                           ACCB meeting.\
                           There were no dissenting votes so the CR was recommended
                           for FMCSA approval.\
                           \
                           \[2005-07-07\] Closed fixed\
                           \
                           \
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD\
                           \
                           Impact on States:\
                           There is not impact if states chose not to use this
                           capability.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/19/2008 12:32:54 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          8/23/2004 11:01:21 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           7/7/2005 10:12:53 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2933

  **External               SAFER CR 124
  Reference:**             

  **Category:**            Changes to SAFER-CVIEW interface for
                           REVIEW_REASON_NOT_RATED

  **Component:**           SAFER/MCMIS, SAFER/CVIEW

  **Synopsis:**            New values for REVIEW_REASON_NOT_RATED are in the carrier
                           data received by SAFER from MCMIS.\
                           \
                           Summary: Since the FMCSA-sponsored CVIEW will not accept
                           the new values, Volpe has implemented a workaround to
                           change the values.\
                           \
                           Proposal:\
                           The CVISN states change their CVIEW to accept the new
                           values so that the data in their CVIEW databases will be
                           consistent with the data displayed on the SAFER web site.
                           A schema change will be required; the transaction T0031
                           will be versioned to T0031V2 and will be available in the
                           January 2005 release of SAFER.

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2005-06-17\] Closed - incorporated into CR 3115

  **Description:**         Four new values (V, W, X, Y) were added to the
                           REVIEW_REASON_NOT_RATED field. Changes have been made in
                           the SAFER database to allow the new values to be loaded
                           from MCMIS to SAFER.\
                           \
                           In order to support the current SAFER/CVIEW interface, a
                           separate procedure has been modified to include a script
                           that will convert the new values to \'Q\' before
                           scheduling the T0031 job. This extra step will be
                           performed for every T0031 run until the XML CVIEWs are
                           ready to accept the new values.\
                           \
                           In order for CVIEW to accept the new values, the T0031
                           schema file will need to be updated to include the new
                           values to REVIEW_REASON_NOT_RATED. The Volpe Center will
                           be responsible for providing the updated schema file to
                           the CVISN states. In addition, if CVIEW uses a database
                           constraint for the REVIEW_REASON_NOT_RATED field, it will
                           need to be changed to allow the new values to be applied.\
                           \
                           \[2004-08-23\] SAFER CR 124 presented and discussed at the
                           ACCB meeting on 2004-08-19.\
                           This CR is related to architecture CR 2443 (SAFER CR 12)
                           in that it involves new values for a data element being
                           sent from MCMIS to SAFER. As with CR 2443, Volpe has
                           developed a workaround to support the T0031 transaction,
                           namely converting the new values to \"Q\". Volpe would
                           like to implement a schema change at the same time that
                           the schema change is made for CR 2443. States on the call
                           were in agreement that both changes should be made at the
                           same time. An architecture version of this CR will be
                           written and will be posted to the list serv for comments.
                           This change will be included in the beta-test T0031V2. As
                           noted above, T0031V1 will remain available to states until
                           2005-01-01.\
                           \
                           \[2004-09-27\] Presented and discussed at the 2004-09-23
                           ACCB meeting.\
                           This CR is related to CR 2443. Because additional values
                           are expected, implementation of this CR has been postponed
                           until the January release of SAFER. Beta-testing with the
                           states will begin in early October. This CR will be posted
                           to the CVISN System Architects list serv.\
                           \
                           \[2004-10-25\] Presented and discussed at the 2004-10-21
                           ACCB meeting.\
                           There were no dissenting votes so the CR was recommended
                           for FMCSA approval. Two states posted list serv comments
                           in favor of relaxing constraint checking in these
                           situations. Volpe will reconsider this if the situation
                           arises in the future.\
                           \
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD\
                           \
                           Impact on States:\
                           XML states would have to use the versioned schema. If they
                           have a database constraint on the REVIEW_REASON_NOT_RATED
                           field, or if they do any processing based on the value of
                           that field, that processing may need to change.\
                           Utah noted that changes could probably be done in one
                           day.\
                           There seems to be no impact on EDI states, as any unknown
                           value of REVIEW_REASON_NOT_RATED is mapped to \"Other\".\
                           \
                           \[2005-06-17\] Closed - incorporated into CR 3115

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       6/17/2005 7:36:21 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2004 8:00:31 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           6/17/2005 7:36:21 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2805

  **External               SAFER CR 105; WI-Tania Rossouw 608.267.2400
  Reference:**             

  **Category:**            SAFER Web services

  **Component:**           SAFER

  **Synopsis:**            Add T0032 (Licensing and Insurance Output Transaction) to
                           the SAFER Web services capabilities.\
                           \
                           Summary: Implementation of a web service capability is in
                           beta testing for several XML transactions. This capability
                           is expected to be available in SAFER 4.6 due to be
                           released in September, 2004.\
                           \
                           Proposal: Add T0032 to the SAFER Web services
                           capabilities.

  **Status:**              Closed Fixed

  **Disposition:**         \[2005-07-07\] Closed - deployed in SAFER 4.7

  **Description:**         \[7004-07-14\] Submitted by Tania Rossouw of Wisconsin.\
                           Add T0032 (Licensing and Insurance Output Transaction) to
                           the SAFER Web services capabilities. We would like to be
                           able to query SAFER for authority and insurance
                           information.\
                           \
                           \[2004-07-19\] Presented at the 7/15/04 ACCB meeting.\
                           This CR will be posted to the CVISN Systems Architects
                           list serv for review and will be discussed at the August
                           ACCB meeting.\
                           \
                           \[2004-08-19\] No disssenting votes, so recommended for
                           FMCSA approval.\
                           \
                           \[2005-07-07\] Closed - deployed in SAFER 4.7\
                           \
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD\
                           \
                           Impact on States:\
                           There is not impact if states chose not to use the Web
                           services capability.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       7/7/2005 10:09:54 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          7/14/2004 2:16:46 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           7/7/2005 10:09:54 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------
  **CR Number:**           2798

  **External               SAFER CR 122; DJ Waddell - MD - 240-228-5878
  Reference:**             

  **Category:**            Business rules/process to clarify data source

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Synopsis: Data integrity issues are resulting from a source other than the
                           authoritative source submitting vehicle registration data to SAFER.\
                           \
                           Summary: A source other than the authoritative source can submit vehicle
                           registration data to SAFER. If the authoritative source later updates the
                           information, the data already in SAFER may be overwritten. Business
                           rules/process need to be established (a) to clarify the source of data and (b)
                           to coordinate data entry/update by authoritative source and authorized but not
                           \'authoritative\' source.\
                           \
                           Proposal: The proposal consists of several clauses.\
                           \
                           1. A state (in most cases, a \"non-participating\" state) may authorize another
                           state to send vehicle registration data to SAFER on its behalf; this must be
                           documented by letter/email. Letter/email will also be required to withdraw the
                           authorization.\
                           2. A new table in SAFER will be created to keep track of which states are
                           authorized to send vehicle registration data to SAFER for any given state. The
                           default would be that only the IRP base state would be authorized to send
                           vehicle registration data to SAFER.\
                           3. Volpe will consider whether the new table is also the appropriate place to
                           store contact information.\
                           4. If a state that is not authorized according to the process attempts to send
                           vehicle registration data (XML T0020, T0021, or T0022) for another state to
                           SAFER, the XML transactions will be rejected and the IRP base state will be
                           notified that an unauthorized state has attempted to send vehicle registration
                           data on its behalf.\
                           5. The REGISTRATION_START_DATE will be a mandatory field and
                           REGISTRATION_EXPIRE_DATE will be a mandatory field in the vehicle registration
                           data.\
                           6. The table will be posted in some form on the CVISN website.

  **Status:**              Closed Approved

  **Disposition:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.

  **Description:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.\
                           \
                           A source other than the authoritative source, such as an escreening enrollment
                           system, can submit vehicle registration data to SAFER. If the authoritative
                           source (e.g. IRP base state) later updates the information, the data already in
                           SAFER, such as the escreening enrollment information, may be overwritten.
                           Business rules or a process need to be established (a) to clarify the source of
                           data and (b) to coordinate data entry/update by authoritative source and
                           authorized but not \'authoritative\' source.\
                           \
                           \[2007-07-26\] sbs\
                           \
                           At the 2007-05-23 Escreening focus group meeting, the CVISN stakeholders agreed
                           that SAFER shall be enhanced to track if the registration data in SAFER comes
                           from the authoritative source or not.\
                           \
                           Most of the CVISN states submit T0022 transactions via their own state CVIEW
                           system. The irp_base_state in the registration data matches the state code in
                           the T0022 data file name. States that do not have CVIEW but need to send the
                           vehicle registration data to SAFER have to let states with a CVIEW send data for
                           them. This SCR allows SAFER to track which state sends the data to SAFER and to
                           indicate if the data is being verified by the authoritative source.\
                           \
                           To support this request, the CVIEW states shall send and SAFER shall accept,
                           store and send the following data elements:\
                           1. Sending_State. The state who sends the T0022 transaction data for the
                           authoritative state.\
                           2. Verification_Source. The type of mechanism used to verify the registration
                           data. The valid data value for this data element will be NLETS, Commercial
                           Vehicle Officers and Transponder Administrators, and IRP.\
                           3. Verification_Date. The date the registration data is verified by a
                           authoritative source.\
                           \
                           SAFER T0022 xml schema and T0028 XML schema will be modified to add the above
                           three data elements.\
                           \
                           States will be required to update the new schema files for the September 2007
                           SAFER 7.3 release.\
                           \
                           HISTORY\
                           \
                           \[2007-05-17\] Discussed at 2007-05-17 CVISN ACCB meeting. The requirements need
                           to be finalized and reported to the CVISN ACCB. Scheduled for SAFER 5.3.\
                           \
                           \[2007-01-23\] Approved by J. Secrist. Scheduled for SAFER 5.2.\
                           \
                           \[2006-10-19\] Status reported at the 10/19/06 ACCB meeting.\
                           Item 5 in the proposal of the CR was corrected to "The REGISTRATION_START_DATE
                           will be a mandatory field and REGISTRATION_EXPIRE_DATE will be a mandatory field
                           in the vehicle registration data." Volpe will discuss FY07 implementation of
                           this capability with FMCSA.\
                           \
                           \[2006-05-26\] Discussed at the 5/18/06 ACCB meeting.\
                           Architecture CRs 2936 (e-screening data) and 2798 (IRP registration data) deal
                           with Authoritative Source. Volpe will check with FMCSA to see if both can be
                           incorporated in SAFER Release 5.1. If not, then maybe CR 2936 can be included in
                           5.1 and CR 2798 in Release 5.2.\
                           \
                           \[2006-05-04\] re discussion of CR 2936 at 4/20/06 ACCB meeting.\
                           At the March 2006 ACCB meeting, states requested that Architecture CR 2798
                           (SAFER CR 122), which addresses management of update authority for vehicle
                           registration data, be implemented in SAFER Release 5.1. Since Architecture CR
                           2936 addresses management of update authority for transponder data, states
                           suggested that the scope of Architecture CR 2798 be expanded to include other
                           transactions, including transponder data. Volpe pointed out that the testing
                           requirements for implementing the CR would expand significantly. Volpe said that
                           the implementation of Architecture CR 2798 (SAFER CR 122) will create audit
                           tables only and will not involve sending output transactions. Volpe will
                           re-write these CRs. APL suggested they be kept as separate CRs, but reflect this
                           discussion about what the states really want.\
                           \
                           \[2006-03-30\] Presented at the 2006-03-23 ACCB meeting.\
                           Currently, State A can submit registration data for State B, and SAFER would not
                           reject the transaction. A proposal was developed by a subcommittee of the ACCB
                           and later approved and recommended for FMCSA approval in September 2004. SAFER
                           CR 122 is pending and Volpe said that it was not a current candidate for the
                           SAFER 5.1 release in August. States on the call felt strongly that the issue of
                           management of update authority should be resolved as soon as possible and that
                           the CR should be considered a high priority for the 5.1 release.\
                           \
                           \[2004-09-27\] Presented and discussed at the 2004-09-23 ACCB meeting.\
                           Item 3-5 was modified to read: \"The REGISTRATION_START_DATE will be a mandatory
                           field and REGISTRATION_EXPIRE_DATE will be a conditionally mandatory field in
                           the vehicle registration data.\"\
                           \
                           This CR was recommended for FMCSA approval. It will also be posted to the CVISN
                           System Architects list serv for review.\
                           \
                           \[2004-09-08\] There is a correction to the minutes of the 19 Aug ACCB meeting.
                           Item 3-5 should read: \"5. The REGISTRATION_START_DATE and
                           REGISTRATION_EXPIRE_DATE will be mandatory fields in the vehicle registration
                           data.\"\
                           \
                           \[2004-08-23\] This CR was discussed at the July and August ACCB meetings, and
                           at a special teleconference on August 16, 2004. The proposal described in the
                           \"Synoposis\" section was developed and refined at those meetings. Corrected
                           minutes from the 2004-08-16 meeting are attached to this CR.\
                           \
                           \[2004-08-11\] Andrew Wilson posted a document and a spreadsheet to the CVISN
                           System Architect list serv. Both are available via the Attachments tab.\
                           1. The attached Word document contains some background notes for the upcoming
                           conference regarding CVISN Architecture CR 2798.\
                           2. The attached spreadsheet contains the number of IRP records by IRP base state
                           currently in the SAFER database. The relatively small number of records for some
                           states are typically records that were entered to support E-Screening enrollment
                           or PRISM vehicle targeting for another State.\
                           \
                           \[2004-07-19\] Presented and discussed at the 7/15/04 ACCB meeting.\
                           This CR will be posted to the CVISN Systems Architects list serv for discussion;
                           no decision is being proposed at this time. A conference call will be scheduled
                           for the week of August 16 if states are interested.\
                           \
                           \[2004-07-12\] per DJ Waddell 7/8/04\
                           Scenario: Vehicle operators want to enroll in Maryland's e-screening program,
                           but their IRP base state has not provided registration data for the vehicle to
                           SAFER.\
                           \
                           Maryland's e-screening enrollment system collects data from the registrant,
                           creates a vehicle registration record in CVIEW, and then enrolls the specified
                           carrier and vehicle for the Maryland e-screening program. Data details are
                           below. Maryland's e-screening enrollment program is operated by state agencies
                           under the Maryland DOT, as is Maryland's IRP office.\
                           \
                           Once the registration data is entered, the e-screening enrollment process may
                           proceed, collecting the transponder number and the jurisdictions to enroll for.
                           Technically, transponder number is part of the Vehicle_VIN table, so it is
                           registration data.\
                           \
                           The registration data is sent to SAFER by MD CVIEW.\
                           \
                           Analysis is needed on potential data collisions. If an authoritative source for
                           vehicle registration data begins to contribute data to SAFER, and provides an
                           update to one of the registration records entered by another source, the new
                           data will probably overwrite the data already in SAFER. For example, if the IRP
                           base state updates registration data entered by the MD e-screening program, this
                           would probably un-enroll the vehicle from MD E-Screening, since transponder
                           number and CVIS_DEFAULT_CARRIER USDOT number would probably not be provided by
                           the IRP base state, and they would probably be replaced by NULL.\
                           \
                           A process is needed to \"close the loop\" with non-participating states to
                           inform them of data submitted listing them as the IRP Base State, and to request
                           new expiration dates when license plates are renewed for enrolled vehicles. For
                           example, MD would like to have in place ASAP an email list for the IRP offices
                           for each jurisdiction. Then when a vehicle registration record is created or
                           modified for e-screening enrollment, an email would be sent (possibly/someday
                           automatically) to the corresponding jurisdiction\'s designated IRP office. MD
                           proposes that the change go into CVIEW and SAFER with no action from the base
                           jurisdiction, as it does now, with a plan/process in place so that it could be
                           retracted if the base jurisdiction objects, with any eye to automating that
                           process as well.\
                           Vehicle Registration Data Fields:\
                           \
                           Mandatory Fields:\
                           VIN\
                           License plate number\
                           License plate state (= IRP base state)\
                           Registration expiration date\
                           IRP registered weight for the e-screening state\
                           USDOT number of the carrier responsible for the safe operation of the vehicle\
                           Transponder identifier\
                           \
                           Optional Fields:\
                           Title number\
                           Title jurisdiction\
                           Owner name\
                           Unit number\
                           Model year\
                           Make\
                           Type\
                           Fuel type\
                           GVW\
                           Unladen weight\
                           Number of axles (truck)\
                           Number of seats (bus)\
                           Registration start date\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Impact on architecture:\
                           None\
                           \
                           Impact on documentation:\
                           SAFER ICD\
                           \
                           Impact on States:\
                           States will need to implement the process described in the proposal.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CR2798 analysis_V02.doc\
                           CR2798 IRPCounts.xls\
                           ACCB CR 2798 Minutes 2004-08-16_v2.doc\
                           Minutes of CVISN ACCB Meeting August 19 2004 - Correction to CR 2798.rtf

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/21/2007 8:07:04 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          7/12/2004 8:59:22 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/21/2007 8:07:04 AM
  --------------------- -- --------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2728

  **External               WA Bill Goforth - GofortB@wadot.wa.gov; Volpe CR 131
  Reference:**             

  **Category:**            T0022 processing rules

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            LAST_UPDATE_DATE and REGISTRATION_EXPIRE_DATE are not
                           enough to determine the current base state for a vehicle.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2004-09-27\] Closed - superceded by CR 2954.

  **Description:**         \[2004-06-28\] Submitted by Bill Goforth (WA)\
                           Vehicle VIN 1XKWDB9X6YR837650 is in our CVIEW database as
                           NE vehicle, plate 56283 with a registration expiration
                           date of 12/31/02. The vehicle changed ownership from NE
                           carrier USDOT# 2605 to WA carrier USDOT# 236380 sometime
                           in 2003. The latest WA transaction for the vehicle has a
                           registration expiration date of 10/31/04. The problem is
                           that the LAST_UPDATE_DATE for NE is 12/30/03 and the
                           transaction date (LAST_UPDATE_DATE) for the latest WA
                           transaction is 10/18/03. We are using LAST_UPDATE_DATE to
                           determine the current base state for a vehicle. In this
                           situation, we erroneously recognize NE as the current base
                           state. We have approximately 500 vehicles that have this
                           problem.\
                           \
                           We have considered trying to use both LAST_UPDATE_DATE and
                           REGISTRATION_EXPIRE_DATE to determine the current base
                           state. But this does not always work. OR vehicles register
                           all of their vehicles through 12/31 of the current year.
                           We have had vehicles that were registered in OR on 1/1/03,
                           then are sold during 2003 to a carrier in WA and are
                           registered from the point of purchase through the same
                           time the following year (for example 8/1/03 through
                           8/1/04). OR vehicles are given a 3 month grace period to
                           reregister in OR. This means that there is 3 month window
                           (1/1/04 to 3/1/04) where we can\'t tell which state is the
                           vehicle\'s base state.\
                           \
                           We would like to propose adding an IS_CURRENT_BASE_STATE
                           indicator to the VEHICLE_REGISTRATION table and to the
                           T0022 transaction. This indicator would be used by states
                           that report the sale of a vehicle (or otherwise need to
                           report an unknown ownership status) to indicate that the
                           next transaction received (from a new base state) that
                           reports a valid vehicle registration can be distinguished
                           as the current base state for the vehicle. So in this case
                           NE would set IS_CURRENT_BASE_STATE = \'0\' and WA would
                           set IS_CURRENT_BASE_STATE = \'1\'. This would allow states
                           to more accurately determine the current base state.\
                           \
                           This problem could obviously be solved in many different
                           ways and the above solution is only intended as an
                           alternative. Another alternative might be to have a
                           TRANSACTION_CODE element that is required on the T0022. So
                           there would be a transaction code for sale of a vehicle,
                           deletion of a vehicle, etc. TRANSACTION_CODE could then be
                           used to determine that a state is no longer the current
                           base state or that ownership is unknown.\
                           \
                           Further clarification from Bill Goforth\...\
                           Normally the problem occurs within a period of a few
                           months. That is, the vehicle is sold prior to its
                           expiration in the old base state, then purchased and
                           registered in the new base state. The problem occurs when
                           the \"vehicle sold\" transaction occurs in the old base
                           state after the \"new vehicle registration\" transaction
                           occurs in the new base state.\
                           \
                           \[2004-07-19\] Presented and discussed at the 2004-07-15
                           ACCB meeting.\
                           This CR will remain open pending further analysis. Volpe
                           and Washington will discuss whether or not sufficient
                           information already exists to determine the current base
                           state.\
                           \
                           \[2004-08-23\] Discussed at 2004-08-19 ACCB meeting, but
                           Washington was not on the call.\
                           Volpe has sent an email to WA in which they proposed that
                           REGISTRATION_START_DATE be made mandatory in T0022 and
                           T0028. Volpe will write a corresponding SAFER CR.\
                           \
                           \
                           \[2004-09-16\] Volpe supplied SAFER CR 131 in response to
                           action item #4 of the 8/19 ACCB meeting.\
                           See corresponding architecture CR 2954.\
                           \
                           \[2004-09-27\] Presented at the 2004-09-23 ACCB meeting.\
                           Per discussion with Washington State, CR 2728 will be
                           closed and the expanded issue of mandatory fields will be
                           continued in CR 2954.\
                           \
                           \
                           Impact on States:\
                           XML states would have to use a versioned schema.\
                           There would be no impact on EDI states.\
                           \
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/27/2004 1:55:28 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/29/2004 6:07:19 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/27/2004 1:55:28 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2664

  **External               Volpe CR 110
  Reference:**             

  **Category:**            SAFER database

  **Component:**           SAFER

  **Synopsis:**            Archive inactive carrier and vehicle records

  **Status:**              Closed Deferred

  **Disposition:**         \[2004-06-17\] Closed - turned over to Volpe as SAFER CR.

  **Description:**         The SAFER database contains historical carrier and vehicle
                           records that are no longer active. To improve the data
                           quality of the SAFER, one of the efforts being considered
                           is to develop procedures and tools to manage the SAFER
                           data.\
                           \
                           \[2004-01-15\] Presented and discussed at the 1/15/04 ACCB
                           meeting.\
                           States were in favor of archiving inactive carrier and
                           vehicle data two years after the registration expiration
                           date.\
                           \
                           \[2004-06-21\] Discussed at the 6/17/04 ACCB meeting.\
                           This is really a SAFER maintenance CR, the architecture CR
                           will be closed and this CR will be turned over to Volpe.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       6/22/2004 6:09:05 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          6/3/2004 3:58:56 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           6/22/2004 6:09:05 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2639

  **External               Volpe CR 104
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Provide L&I data to CVIEW users for carriers that do not
                           have USDOT#.

  **Status:**              Closed Deferred

  **Disposition:**         \[2004-06-16\] Withdrawn

  **Description:**         SAFER CR 104:\
                           \"Wisconsin had proposed that SAFER receive all intrastate
                           carrier data from L&I applications and this will benefit
                           CVIEW states from enforcement and credential perspectives.
                           The original email is attached to this CR.\
                           \
                           Currently, the L&I application does not send carrier data
                           to SAFER if the carrier has no USDOT number. As a result,
                           SAFER does not have data for those intrastate carriers
                           that have no USDOT numbers.\
                           \
                           To support this business requirement, modification needs
                           to be made in the L&I loading process, SAFER database
                           table and T0032 transaction so that CVIEW users would
                           receive intrastate carrier data from SAFER.\
                           \
                           Further analysis at Volpe suggested that adding carriers
                           without USDOT# to T0032 would increase the data volumn for
                           download. Instead, SAFER will provide those carrier data
                           to the states via the SAFER web service interface. This
                           function will be implemented in conjuction with
                           \[Volpe\]CR 105.\"\
                           \
                           \[2004-05-24\] Presented and discussed at the 5/20/04 ACCB
                           meeting.\
                           There was much discussion of the situations in which MC
                           numbers and US DOT numbers are issued, or not issued.
                           Additional analysis of the business rules is required.
                           Wisconsin will provide a more detailed description of the
                           business rules to the community.\
                           \
                           \[2004-06-16\] Wisconsin requested that this CR be
                           withdrawn, as more investigation needs to be done on the
                           business rules.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/16/2004 12:31:32 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          5/24/2004 8:27:02 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           6/16/2004 12:42:33 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2638

  **External               Volpe CR 101
  Reference:**             

  **Category:**            CVISN Architecture and Standards

  **Component:**           SAFER/CVIEW, SAFER/PRISM

  **Synopsis:**            Enhance T0022 transaction to allow states to submit
                           temporary authority vehicles to SAFER.\
                           \
                           Summary: The SAFER XML service requires that the license
                           plate/state be unique for vehicle records submitted via
                           the T0022 input transaction. This CR requests that SAFER
                           allow states to submit non-unique license plate/state and
                           that SAFER would modify the data to produce a unique code
                           (example: \"TEMP + last 6 digits of VIN\").\
                           \
                           Proposal: States participating in recent ACCB meetings
                           have recommended that this CR be disapproved. States
                           should change their CVIEW or equivalent system so that the
                           license plate/state submitted in a T0022 input transaction
                           to SAFER is unique. SAFER should not modify data received
                           by the state to create unique license plate/state.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2004-07-19\] Closed - disapproved.

  **Description:**         From SAFER CR 101:\
                           The SAFER XML service as implemented currently requires
                           the license plate/state be unique for vehicle records
                           submitted via the T0022 input transaction. The Vehicle
                           records submitted with a duplicate plate/state value (like
                           TEMP/MA) are being rejected due to the existing business
                           rule logic. As a result, the states are not able to send
                           the temporary vehicle data to SAFER as the temporary
                           license plate numbers issued by the states are often not
                           unique.\
                           \
                           In order to support this business function, changes need
                           to be made during the T0022 data submitting and processing
                           process so that a unique plate value will be assigned to
                           the temporary vehicle. One of the suggestions is the
                           states will use a common phrase (such as TEMP) for all
                           temporary vehicles they are submitting in the T0022
                           transaction. SAFER will identify it as a temporary vehicle
                           and automatically generate a numerical value to associate
                           with the common phrase. The combination of both will make
                           the License Plate field unique for the temporary vehicle
                           of a given state.\
                           \
                           If the request is approved and implemented, states will be
                           able to submit vehicle records for all plate values issued
                           to the temporary authority vehicles by providing SAFER the
                           common phrases to be used in T0022 transaction.\"\
                           \
                           \[2004-05-24\] Presented and discussed at the 5/20/04 ACCB
                           meeting.\
                           Volpe proposed a solution that would involve SAFER
                           creating a unique key for vehicle records received with
                           non-unique license plate values. Sharon Holland (UT)
                           suggested that states should assign a unique number -
                           e.g., TEMP + last 6 digits of VIN - so that such vehicles
                           can be tracked. Bill Guiffre (CSI) was uncomfortable with
                           SAFER altering records. This CR will be posted on the
                           CVISN System Architects list serv and discussed at the
                           June ACCB meeting.\
                           \
                           \[2004-06-03\] During the recent meeting regarding
                           PRISM/CVISN/SAFER programs, APL suggested that the data
                           consistency between SAFER and CVIEW local database needs
                           to be considered when evaluating the options.\
                           \
                           \[2004-06-21\] Presented at the 6/17/04 ACCB meeting.\
                           The CR will be posted to the list serv for states to
                           review.\
                           \
                           \[2004-07-19\]\
                           Four states responded to the posting on the list serv. All
                           endorsed the counter-proposal that states generate their
                           own unique identifier rather than having SAFER create a
                           unique identifier.\
                           \
                           Presented and discussed at the 7/15/04 ACCB meeting. The
                           CR was disapproved. It will be up to the states to ensure
                           that plates are unique.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/16/2004 12:31:45 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          5/24/2004 8:21:40 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           7/19/2004 11:53:18 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2637

  **External               SAFER CR 109; Terri Ungerman (LA)
  Reference:**             

  **Category:**            SAFER XML

  **Component:**           SAFER/PRISM/CVIEW

  **Synopsis:**            SAFER XML doesn\'t contain new elements of updated MCS150
                           form.

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2005-07-25\] Closed - subsumed by CR 3115.

  **Description:**         \[2004-05-19\] from Terri Ungerman\
                           \"I am working with Louisiana to implement PRISM using
                           CVIEW and SAFER. In a conference call yesterday we noted
                           that the latest SAFER XML ICD doesn\'t contain the
                           additional data elements that were added to the latest
                           version of the MCS150 form, such as cell phone #,
                           additional information on equipment, revoked USDOT, and
                           company representatives. I was wondering if there was a
                           plan to incorporate these data elements in the XML
                           transaction sets going to CVIEW in the near future.\
                           \
                           We are trying to make a decision tomorrow if we will use
                           the SAFER transaction sets for the MCS150 form data or if
                           we should use the PRISM MCS150 file. What we do depends on
                           if/when SAFER will incorporate these additional data
                           elements. If you could help us out, it would help us
                           greatly in moving forward in our decision making
                           process.\"\
                           \
                           \[2004-05-27\] Presented and discussed at 5/20/04 ACCB
                           meeting.\
                           This CR is related to the issue of different data elements
                           in CVISN and PRISM, which will be discussed in the June 3
                           CVISN/PRISM meeting.\
                           \
                           \[2004-06-17\] Presented at the 6/17/ACCB meeting.\
                           This CR was posted to the list serv last month; only one
                           comment was received. The states were asked if there is
                           interest in this CR; North Carolina and Nebraska indicated
                           that they are interested. The requirements do not include
                           the list of data elements yet, so this CR will need
                           further analysis. It was noted that a new version of MCS
                           150 has been proposed; its adoption could impact this CR.
                           More analysis is needed.\
                           \
                           \[2004-06-28\] Feedback from Gary DeRusha (VOLPE-PRISM)
                           6/25/04\
                           During the last meeting, Nebraska asked if the new
                           elements of the Updated MCS150 form that were added to the
                           XML Carrier Census transaction set would that allow them
                           to use it instead of the PRISM MCS150 File to satisfy a
                           PRISM requirement. I said that a reconciliation of the
                           required fields would be necessary, but the intent would
                           be that they could use the enhanced XML transaction set
                           instead of downloading the PRISM file. I forgot to mention
                           that in order to do so, states will have to make sure that
                           they can access the latest MCS150_Update_Date field, which
                           is not a field on the MCS150 form. My comment would be
                           that the carrier\'s MCS150_Update_Date field should also
                           be added to the transaction set if it is not already
                           there.\
                           \
                           \[2004-06-29\] At the 6/23/05 ACCB meeting, Terri Ungerman
                           (OK) to look into the data elements on the MCS150 form
                           that don\'t appear to be in the T0031. The hope is that
                           any missing items could be added to the T0031 when it is
                           revised. The results are listed below.\
                           \
                           1. Field 14 on the MCS150 form (Principal Contact Cellular
                           Phone Number). This may be referred to by the LU User ID
                           in the T0031, but it wasn\'t clear to me that it is
                           referencing the same data.\
                           \
                           2. Field 21 on the MCS150 form includes options to circle
                           E.Intrastate Shipper and F. Vehicle Registration Only. In
                           the T0031 it appears that there is a field for Intrastate
                           Shipper - HM, and a field for Hazmat status but I\'m not
                           sure how these correspond with item E on the MCS 150.
                           There doesn\'t appear to be any field in the T0031 to
                           accommodate F. Vehicle Registration Only.\
                           \
                           3. Field 26 of the MCS150 is a table of values. In the
                           T0031 it appears the totals for some of the columns are
                           provided for, but not the individual table entries.\
                           \
                           4. Field 27 of the MCS150 is also a table where the T0031
                           appears to provide the column totals but not individual
                           values.\
                           \
                           5. There doesn\'t appear to be places in the T0031 where
                           the officer names are provided as shown on the MCS 150
                           form field 29.\
                           \
                           \[2005-07-25\] This CR has been subsumed by Architecture
                           CR3115 SAFER CR 174). Closed as duplicate.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       7/25/2005 1:17:09 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          5/19/2004 3:15:21 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           7/25/2005 1:17:09 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2578

  **External               Volpe CR 29
  Reference:**             

  **Category:**            SAFER XML_in, SAFER ICD, SAFER SCIP

  **Component:**           SAFER/PRISM

  **Synopsis:**            Develop an XML input transaction for PRISM states to
                           submit vehicle registration information to SAFER.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2006-03-21\] Closed - disapproved.

  **Description:**         The PRISM team is exploring adding the capability of
                           having the PRISM States with CVIEW or equivalent
                           capabilities submit an XML vehicle registration input
                           transaction to SAFER for all their vehicle records to help
                           satisfy IRP requirement 12 in the PRISM Program
                           Implementation Guide. That requirement mandates that PRISM
                           States submit a full set of vehicle IRP records associated
                           with carriers in the MCSIP program to SAFER. This
                           information is combined with similar data from other
                           States to support the generation of the PRISM Local Target
                           File that is made available to PRISM States every day.\
                           \
                           Since CVIEW transfers are transactional in nature, that
                           requirement can be met if information for every vehicle
                           with IRP maintenance activity from the State is sent to
                           SAFER. Vehicle IRP data only needs to be transferred to
                           SAFER when a change is made to it. This would ensure that
                           current vehicle data is available so if a carrier becomes
                           targeted in MCSIP at a later date, then all associated
                           vehicle data is already there in the database and those
                           vehicles will become appropriately targeted.\
                           \
                           The proposed transaction set would be named T0022P, PRISM
                           IRP Registration (Cab Card) Input Transaction where P in
                           the transaction number stands for PRISM. The T0022P
                           transaction is identical in format to the current T0022
                           transaction, the difference being that certain fields that
                           are optional in the T0022 transaction are mandatory in the
                           T0022P transaction and all IRP Cab Card Input transactions
                           need to be submitted due to the way PRISM and SAFER
                           process the data.\
                           \
                           The rationale for requesting a new transaction set is that
                           some States using CVIEW or equivalent capabilities to
                           input IRP vehicle data to SAFER may not want to
                           participate in the PRISM program and thus be forced to
                           comply with the PRISM business rules. Therefore, the
                           creation of a separate T0022P Transaction Set is being
                           requested instead of proposing changes to the existing
                           T0022. Since the use of only one IRP Cab Card Input
                           Transaction Set will be allowed, if States choose to use
                           the new T0022P transaction, it must satisfy all the PRISM
                           and non-PRISM requirements that the State may have.\
                           \
                           The proposal for a new T0022P transaction was the result
                           of an internal SAFER/PRISM meeting held earlier this year
                           at the Volpe Center. At this meeting it was agreed that
                           the new transaction T0022P would contain the same vehicle
                           information contained in the PRISM Vehicle File submitted
                           by PRISM Pilot Architecture States. It would use the same
                           field sizes that SAFER uses now since SAFER uses larger
                           size fields than PRISM does for the same data. The XML tag
                           names would remain unchanged and would be mapped to
                           specific field names referenced in the PRISM system
                           specifications. PRISM program business rules mandate that
                           all of the PRISM fields are required to contain data, the
                           data be maintained to remain current and the selection set
                           of records submitted must include all of the State\'s
                           current IRP vehicles. By requesting a new T0022P
                           transaction set, these business rules would only apply to
                           PRISM States certified to use this method of transmitting
                           targeted vehicle data to SAFER.\
                           \
                           The following would be the mandatory fields in transaction
                           T0022P. The rest of the optional fields in T0022 are not
                           listed here but would be included in T0022P.\
                           \
                           FIELD NAME SIZE TYPE PRESENCE RULE\
                           \
                           Safety Carrier Number 12 string Mandatory Right justified
                           blank space pad\
                           VIN 30 string Mandatory Left justified\
                           Plate Number 12 string Mandatory\
                           Registration Jurisdiction 2 string Mandatory\
                           Registration Date Effective yyyymmdd date Mandatory the
                           date on the current registration\
                           Registration Date Expiration yyyymmdd date Mandatory the
                           date on the current registration\
                           Make 10 string Mandatory Left justified\
                           Model Year yyyy date Mandatory\
                           Base Country 2 string Mandatory\
                           \
                           Analysis by Volpe SAFER team (20040112):\
                           The new transaction T0022P would impact XML states
                           participating in both CVISN and PRISM programs. The SAFER
                           XML certification testing procedure would be modified to
                           include PRISM requirements into the certification process
                           for PRISM states or CVISN states planning to be compliant
                           with PRISM as well. The SAFER ICD would be modified to
                           introduce the new T0022P interface for states in PRISM
                           program. Upon approval, the XML schema definition file and
                           a sample transaction file for T0022P would be published in
                           the next version of the SAFER ICD.\
                           \
                           The labor and cost analysis for this task is pending
                           approval from FMCSA.\
                           \
                           \
                           Analysis by Volpe PRISM team (20040112):\
                           Issue #1: FMCSA will need to publish to XML states that
                           intend on using the IRP cab card input transaction T0022P
                           which vehicles need to be included in those transactions.
                           At a minimum, all targeted vehicles must be.\
                           \
                           Analysis by Volpe PRISM team (20040126):\
                           It will require that CVIEW States that intend on using the
                           T0022P, PRISM IRP Cab Card Input Transaction follow the
                           rules of the PRISM program. To comply, they will be asked
                           to submit ALL IRP transactions and keep them current.
                           Fields that PRISM specifies as not being blank will be
                           required and the PRISM Technical Support group will be
                           involved in the certification process. Non-CVIEW States
                           will be able to use the existing T0022 Input transaction
                           set and a new variant; T0022P will be documented in the
                           ICD for PRISM CVIEW States to use. If an existing CVIEW
                           State decides to participate in the PRISM program later
                           on, they would have to be re-certified prior to coming on
                           board.\
                           \
                           \[2004-04-16\] Discussed at the 4/15/04 ACCB meeting.\
                           Volpe is investigating the possibility of creating XML
                           transactions for PRISM states. There are many
                           ramifications to both PRISM and CVISN states that are
                           being considered.\
                           \
                           \[2004-06-17\] Presented at the 6/17/04 ACCB meeting.\
                           This CR was also discussed during the CVISN/PRISM meeting
                           and is undergoing analysis. The progress of this CR will
                           be reviewed at the next ACCB meeting.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/21/2006 11:22:59 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          4/7/2004 8:21:04 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           3/21/2006 11:22:59 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2577

  **External               SAFER CR 31
  Reference:**             

  **Category:**            PRISM XML_out, SAFER ICD

  **Component:**           SAFER/PRISM

  **Synopsis:**            Develop an XML output transaction for the vehicle
                           component of the PRISM Local Target File.

  **Status:**              Closed Approved

  **Disposition:**         \[2004-08-23\] Approved by FMCSA PRISM Program

  **Description:**         The PRISM team at the Volpe Center is interested in having
                           the capability to output the equivalent of the PRISM Local
                           Target file for PRISM States with CVIEW or equivalent
                           capabilities. PRISM State IRP and Enforcement groups need
                           access to this data to comply with various PRISM program
                           requirements; however, an XML approach to receiving this
                           data does not currently exist.\
                           \
                           The proposal is to create a new XML transaction set that
                           explicitly contains only PRISM targeted vehicles as
                           identified by the PRISM Central Site every evening. The
                           data would come from the same source used to create the
                           existing PRISM Local Target flat file used by PRISM pilot
                           architecture States and would be regenerated fresh each
                           day. State IRP and Enforcement groups could be assured
                           that by accessing this new transaction set they are
                           getting the latest information available from the PRISM
                           program on the status of targeted vehicles.\
                           \
                           The PRISM Local Target file consists of both carrier and
                           vehicle record types within the same file and duplicating
                           this feature within an XML transaction set would not be
                           necessary. Upon Volpe analysis, it was noted that only two
                           fields had to be included from the carrier record of the
                           PRISM Local Target file to satisfy PRISM requirements.
                           Those fields where the MCSIP Step of the Carrier
                           responsible for safety and the run date of the last MCMIS
                           Carrier Census update to SAFER. By adding this information
                           to each vehicle record of the new output transaction set,
                           the result would simplify the XML processing. This
                           proposed transaction set would be identified as T0028P
                           (see later note - it will be T0041P), PRISM Targeted IRP
                           Registration (Cab Card) Output Transaction.\
                           \
                           As a result of the SAFER/PRISM meeting held at the Volpe
                           Center earlier this year, it was decided that the new
                           transaction T0041P would contain the same vehicle
                           information included in the PRISM Local Target File. It
                           would be formatted similar to the existing T0028
                           Transaction Set but would be comprised of only one type of
                           transaction. Some elements of the IRP VIN and IRP
                           Registration sections of the existing T0028 Transaction
                           Set would be used but there would be no elements from the
                           existing IRP Proration section. Also, new tag names would
                           be created for the MCSIP Step and Census Update Date
                           fields not included in T0028.\
                           \
                           T0041P would use the same field sizes that SAFER uses now
                           since SAFER uses larger field size than PRISM does for the
                           same data. The XML tag names would remain unchanged and
                           would be mapped to specific field names. The new output
                           transaction T0028P would contain the following data
                           elements:\
                           \
                           FIELD NAME SIZE TYPE\
                           \
                           VIN 30 string\
                           Safety Carrier Number 12 string\
                           MCSIP Step 2 string\
                           Plate Number 12 string\
                           Registration Jurisdiction 2 string\
                           Registration Date Effective yyyymmdd date\
                           Registration Date Expiration yyyymmdd date\
                           Make 10 string\
                           Model Year yyyy date\
                           Last Census Update Date yyyymmdd date\
                           Vehicle Last Update Date yyyymmdd date\
                           \
                           If approved and implemented, the SAFER ICD would be
                           modified to include the new T0041P interface for States in
                           the PRISM program. The XML schema definition file and a
                           sample transaction file for T0041P would be published in
                           the next version of the SAFER ICD.\
                           \
                           The labor and cost analysis for this task is pending for
                           approval from FMCSA.\
                           \
                           \
                           \[2004-04-15\] Discussed at the 4/15/04 ACCB meeting.\
                           Volpe is investigating the possibility of creating XML
                           transactions for PRISM states. There are many
                           ramifications to both PRISM and CVISN states that are
                           being considered.\
                           \
                           \[2004-06-21\] Presented at the 6/17/04 ACCB meeting.\
                           A CVISN/PRISM meeting was conducted on June 3, 2004 to
                           coordinate issues in combining PRISM and CVISN systems. CR
                           2577 was discussed and a set of actions was established to
                           resolve the issue. A follow-up meeting is scheduled for
                           the end of June. In addition, Volpe is analyzing the CR.
                           The progress of this CR will be reviewed at the next ACCB
                           meeting.\
                           \
                           \[2004-08-23\] Presented at the 8/19/04 ACCB meeting.\
                           Volpe has developed XML transaction T0041P for XML PRISM
                           output from SAFER. T0041P contains only PRISM targeted
                           vehicles as identified by the PRISM Central Site every
                           evening. The data would come from the same source used to
                           create the existing PRISM Local Target flat file used by
                           PRISM pilot architecture States and would be regenerated
                           fresh each day. This is not a replacement for T0028.
                           T0041P was tested with Nebraska which has a CVIEW
                           equivalent that stores the PRISM data in a separate table
                           from the CVISN registration data. This does not
                           demonstrate the impact on CVIEWs that are designed based
                           on the SAFER database schema, which would not have the
                           separate PRISM table to store the data.\
                           \
                           The T0041P transaction has been approved by FMCSA and will
                           be made available to states that are configured to use it,
                           but with the caution that states with conventional CVIEWs
                           cannot use it without making modifications to their
                           CVIEWs. This information will be posted to the CVISN
                           System Architects list serv.\
                           \
                           Impact on architecture:\
                           None - this relates to PRISM architecture\
                           \
                           Impact on documentation:\
                           None\
                           \
                           Impact on States:\
                           No impact to CVISN states that are not PRISM states.\
                           PRISM states may change from flat file to this format.
                           This is no impact if they chose not to use this XML
                           transaction.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       8/23/2004 1:11:19 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          4/7/2004 8:19:29 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           8/23/2004 11:44:59 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2572

  **External               UT Sharon Holland (801) 944-5778; SAFER CR 107
  Reference:**             

  **Category:**            Database and XML schemas

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Add account balance information to the CARRIER_IFTA and
                           CARRIER_IRP tables in the current CVIEW database.\
                           \
                           Summary: Utah proposed a change to XML transactions T0019
                           and T0020 to add fields of interest only to Utah for data
                           exchange among systems within the state. The discussion at
                           the ACCB meeting led to the more general question of
                           providing the capability in XML transactions to carry
                           state-specific data. States indicated interest in this
                           capability, as long as they don\'t have to change their
                           processing if they are not using the feature.\
                           \
                           Proposal: Volpe will pursue the idea of adding a section
                           to an XML schema to allow state custom data to be
                           optionally carried in an XML transaction; this section
                           would be ignored by SAFER and not passed on to other
                           States.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2004-07-19\] CR withdrawn - closed.

  **Description:**         Submitted by Sharon Holland for UT:\
                           \
                           The Utah Ports of Entry collect delinquent IFTA and IRP
                           balances from Utah-based carriers. To do this, they need
                           information about the amounts owed. They access the CVIEW
                           database for information about credential status. The
                           CARRIER_IFTA and CARRIER_IRP tables in the current CVIEW
                           database contain IFTA and IRP status codes and dates, but
                           no account balance information.\
                           \
                           To facilitate sharing account balance information through
                           CVIEW, Utah would like to add account balance fields, as
                           follows:-+\
                           \*\* CARRIER_IFTA table: Add IFTA_ACCOUNT_BALANCE\
                           \*\* T0019 IFTA XML transaction: Add IFTA_ACCOUNT_BALANCE\
                           \*\* CARRIER_IRP table: Add IRP_ACCOUNT_BALANCE\
                           \*\* T0020 IRP Account XML transaction: Add
                           IRP_ACCOUNT_BALANCE\
                           \
                           Account balance information does not need to be stored in
                           SAFER and shared with other states, because other states
                           would never collect a delinquent balance from a Utah-based
                           carrier. But having the ability to transmit this
                           information to the local CVIEW database through T0019 and
                           T0020 transactions, and store it in the CARRIER_IFTA and
                           CARRIER_IRP tables would be very helpful to Utah, and any
                           other state that needs to share account balance
                           information between state agencies.\
                           \
                           Since Utah wants to keep their CVIEW database schema
                           consistent with SAFER, the alternative to including
                           account balances in the CARRIER_IFTA and CARRIER_IRP
                           tables would be to build web services that allow CVIEW
                           query windows to access IFTA_ACCOUNT_BALANCE and
                           IRP_ACCOUNT_BALANCE in the local IFTA and IRP databases.
                           This alternative is more complex, and more costly to
                           implement, than the one requested above.\
                           \
                           \[4-16-04\] Discussed at the 4/15/04 ACCB meeting.\
                           While Utah proposed a change to T0019 and T0020 to add
                           fields of interest only to Utah for data exchange among
                           systems within the state, the discussion led to the more
                           general question of providing the capability in XML
                           transactions to carry state-specific data. States
                           indicated interest in this capability, as long as they
                           don\'t have to change their processing if they are not
                           using the feature. Volpe will pursue the idea of adding a
                           section to an XML schema to allow state custom data to be
                           optionally carried in an XML transaction; this section
                           would be ignored by SAFER and not passed on to other
                           States.\
                           \
                           \[2004-07-19\]\
                           The posting to the list serv generated the following: 2
                           states disagreed with the request to provide the
                           capability for state-specific data in XML transactions.
                           The requestor, Utah, has withdrawn the CR.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       7/19/2004 12:35:32 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          4/1/2004 10:55:11 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           7/19/2004 12:35:32 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- -----------------------------------------------------------------------------------
  **CR Number:**           2563

  **External               Volpe CR 51
  Reference:**             

  **Category:**            SAFER XML interface

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Add capability to delete a record\
                           \
                           Summary: This CR requests that an XML Delete transaction be implemented. Currently,
                           the state must call Volpe and ask them to manually delete a record.\
                           \
                           Proposal: The XML delete transaction will be implemented in accordance with the
                           requirements expressed in this CR.

  **Status:**              Closed Approved

  **Disposition:**         \[2005-07-07\] Closed - deployed SAFER 4.6

  **Description:**         At the 1/15/04 ACCB meeting the ability to delete a record was requested. The
                           purpose of the delete transaction is to correct errors in certain attributes of
                           XML-sourced T0022 data sent by a state.\
                           \
                           In the event that a record is sent to SAFER and the key value is discovered by the
                           state to be in error (e.g. VIN has one character incorrect), there is no way for
                           the state to delete the record. If a correct record is sent, it will not overwrite
                           the original record, because the keys are different. The current solution is
                           calling Volpe and asking them to manually delete the record.\
                           \
                           Volpe will perform analysis of the scope and required functionalities of the
                           proposed transaction.\
                           \
                           2004-04-16\] Discussed at the 4/15/04 ACCB meeting.\
                           Volpe is still analyzing the proposed delete transaction.\
                           \
                           \[2004-06-16\] See attached overview.\
                           \
                           Proposed Requirements\
                           \
                           - The system shall ensure that a user can only modify data owned by that user. For
                           IRP data, it is proposed that the IRP base state be considered the owner of the
                           data, and that it be required for a user to be authenticated as that owner in order
                           to delete records.\
                           - Each delete operation shall archive the deleted data, and output it in a
                           corresponding SAFER IRP Cab Card Delete Output transaction to notify CVISN
                           participants of the deletion.\
                           - A restore operation shall be created for use by Volpe should it become necessary
                           to restore data that was removed in a delete operation.\
                           \
                           \[2004-06-21\] Presented and discussed at 6/17/04 ACCB meeting.\
                           Since this CR was discussed in April, Volpe has provided a set of requirements.
                           This CR will be posted on the CVISN Systems Architects list serv for review. This
                           CR does not address the issue that states can add data where the state is not the
                           authoritative source (Maryland is an example).\
                           \
                           Discussed the issue of data submitted on behalf of a state by another state or
                           organization that is not the authoritative source. Maryland will create
                           registration data for a vehicle that enrolls in screening that is from another
                           state and there is no registration data available from that state. The current
                           process for validating the registration data is to contact the IRP office. A
                           separate notice is not provided from Maryland to SAFER in these cases; it is
                           submitted with regular updates. We need to know if the registration was submitted
                           by the base state or another state. Nebraska indicated that this is a concern.
                           Another field is needed to indicate the source. Gary DeRusha noted that PRISM
                           business rules do not allow this to happen. An architecture CR will be written by
                           APL to address this issue.\
                           \
                           \[2004-07-19\]\
                           The posting to the list serv generated responses from 4 states. All agreed with
                           providing the capability to delete a record. One state suggested that an archive
                           capability not be implemented.\
                           \
                           Presented and discussed at the 7/15/04 ACCB meeting. The CR was recommended for
                           approval. This recommendation initially applies only to T0022.\
                           \
                           Volpe will post the following question to the list serv: Do states wish to increase
                           the scope of CR 2563 to include transactions other than T0022?\
                           \
                           \[2004-09-03\] Update from Jingfei Wu\
                           Volpe presented the technical analysis at the June\'s ACCB meeting. This CR does
                           not address the issue that states can add data where the state is not the
                           authoritative source.\
                           \
                           This CR has been approved by the ACCB and FMCSA for implementation in the next
                           SAFER release.\
                           The deletion capability will be first available for T0022. Expansion of deletion
                           function to other input transactions will be addressed in CR 130 and will be
                           implemented at a later stage.\
                           \
                           Until the authoritative source rules allowing other states to modify other state\'s
                           data, the current implementation of the deletion transaction only allows deletions
                           for the state whose state code matches the IRP_BASE_STATE.\
                           \
                           The proposed required fields in T0022 deletion transaction will be VIN, License
                           Plate Number and IRP Base State.\
                           \
                           \[2005-07-07\] Closed - deployed in SAFER 4.6\
                           \
                           ================================================================================\
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD\
                           \
                           Impact on States:\
                           There is not impact if states chose not to use this capability.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CR2563 (SAFER CR 51) summary.doc

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       7/7/2005 10:03:56 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/25/2004 10:39:26 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           7/7/2005 10:03:56 AM
  --------------------- -- -----------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           2562

  **External               SAFER CR 50
  Reference:**             

  **Category:**            XML, EDI, ICD

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Request to review SAFER business rule regarding multiple VINs

  **Status:**              Closed Approved

  **Disposition:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.

  **Description:**         \[2007-09-21\] Closed. Implemented in SAFER 7.3.\
                           \
                           \[2007-07-26\] sbs SCR 50 has been updated by Volpe and has been approved for SAFER 5.3\
                           \
                           Based on a series of discussions among the stakeholders about the current SAFER business rule implementation and the CVISN/PRISM business
                           needs, this SCR 50 has been updated to reflect the following requirements for the vehicle registration business process. The summary document
                           of the proposed rules and applicable business scenarios is attached to this SCR.\
                           \
                           1. SAFER shall allow one vehicle to have multiple registrations in the same jurisdiction if the license plate and/or carrier will be
                           different. Please note that this is different than the current business rule #1 that states that one vehicle shall only have one plate in the
                           same jurisdiction at any given time. This new rule requires SAFER to support the following scenario.\
                           - SAFER shall update the existing registration record when the same vehicle is getting a new plate or a new carrier.\
                           - SAFER shall create a new registration record when the same vehicle is sold to a new carrier with a new license plate. Please note SAFER
                           currently does an \"update\" in this scenario and this needs to be corrected.\
                           - SAFER shall create a new registration record when the same vehicle is registered in more than one state. Please note that SAFER currently
                           supports this scenario.\
                           \
                           2. SAFER shall only allow one license plate assigned to one vehicle at given time in the same jurisdiction. This rule stays the same as the
                           current business rule #2. However, SAFER will need to be modified to support the following scenario.\
                           - SAFER shall update the existing registration record when an existing license plate is used by another vehicle regardless if the carrier is
                           changed. SAFER will need to be modified to support it as the current logic would create a new record when the VIN is different.\
                           - SAFER shall create a new registration record when the same plate number is used by vehicles registered in different states and or with
                           different carriers. SAFER currently supports this scenario.\
                           \
                           Please note the CVISN/PRISM stakeholders recommend that states shall be responsible to maintain the data quality of the IRP_STATUS_CODE
                           changes in CVIEW and submit to SAFER in the update files in a timely fashion. This data rule has no impact on SAFER processing.\
                           \
                           HISTORY\
                           \
                           \[2007-07-25\] Volpe analysis of SCR 50 attached - \"Include in CR 50 analysis.doc\"\
                           \
                           \[2007-05-17\] Discussed at 2007-05-17 CVISN ACCB meeting. The analysis in SCR 50 needs to be updated to reflect discussion at the 2007-05-08
                           PRISM/CVISN Business Rules telecon. Scheduled for SAFER 7.3.\
                           \
                           \[2007-01-23\] Approved by J. Secrist. Scheduled for SAFER 5.2.\
                           \
                           \[2007-01-18\] Recommended for FMCSA Approval.\
                           \
                           \[2006-11-21\] Discussed at the 11/16/06 ACCB meeting.\
                           The CVISN/PRISM subcommittee of the ACCB recommends that this CR be approved to allow more than one registration record per VIN within the
                           same jurisdiction. Recent changes to the SAFER database structure would accommodate this change. Volpe also noted that there should be a CR
                           written to implement a capability for a state to select to receive the most recent record or all records via the subscription process. This
                           would support SAFER CRs 50 and 1386.\
                           \
                           \[2005-03-01\] Presented and discussed at the 2/17/05 ACCB meeting.\
                           Comments from several states generally supported the idea that the proposed change would reflect business practices in their states. On the
                           other hand, there were several states that currently follow the same business rules that SAFER has in place and opposed the idea. It was
                           inconclusive at this point whether it was necessary or desirable (or neither) to modify the SAFER rules. Discussion was deferred until the
                           March ACCB meeting. More input is needed from States.\
                           \
                           \[2005-02-08\] Discussed at 2005-01-20 ACCB meeting (as Volpe CR 50)\
                           Volpe updates 2005-02-03 to CR 50:\
                           \"At the request of the stakeholder, this CR is reopened since CR 50 was created primarily for a transitional data issue. There are other
                           business scenarios where non-transitional data in the state IRP system need to be uploaded to SAFER but are currently rejected by SAFER due to
                           the business rule violation. The data sent by the states may contain both active and inactive records for the same vehicle as states desire to
                           have inactive statuses sent to SAFER in order to ensure that the most accurate data are kept there and sent to other jurisdictions. This would
                           require SAFER to modify the business logic to allow one vehicle to have more than one record accepted during data input processing.
                           Additionally, states may have business practices where multiple license plates need to exist for one vehicle within the jurisdiction and this
                           is not allowed by the existing SAFER business rule.\
                           \
                           The current SAFER system implements the following business rules for vehicle registration transaction:\
                           RULE 1: A VIN can only have one PLATE/STATE within a state at any given time.\
                           RULE 2: A PLATE/STATE can only be assigned to one VIN within a state at any given time\
                           \
                           Since modification of the business rules has great impact on the data exchanged between CVISN and SAFER, and potentially between CVISN/PRISM
                           and SAFER, Volpe would like to re-evaluate the validity of the current business rules whether or not they support the current business
                           practices and the future business requirements. Volpe would also like to solicit comments and feedback from the states whether there is
                           sufficient interest in implementing the changes.\"\
                           End Volpe 2005-02-03 updates.\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           \
                           \[2004-08-23\] Discussed at 2004-08-19 ACCB meeting.\
                           This CR, related to the problem of multiple VINs, was submitted by Nebraska in December, 2003. Nebraska has developed a workaround (handling
                           the situation via edit, so that duplicate records are not sent to SAFER). This CR will be closed. However, Volpe will consider this issue as
                           it relates to PRISM and potential future merging of data requirements and business rules of the CVISN and PRISM programs.\
                           \
                           \[2004-03-11\] Discussed at 2004-01-15 ACCB meeting.\
                           It was recommended that states not send a vehicle registration to SAFER when it is in a transitional state.\
                           \
                           It is recommended that Volpe review this business rule as documented in the SAFER v4.2 ICD and as implemented in SAFER.\
                           \
                           \[2003-12-16\] Submitted on Dec 16th, 2003\
                           Nebraska is requesting that the following SAFER business rule be reviewed.\
                           \
                           The second business rule we would like reviewed is the requirement that the SAFER extract file does not allow more than one VIN entry within
                           the same jurisdiction. It is my understanding that the file may contain duplicate VIN entries across jurisdictions but not within a
                           jurisdiction. The same scenario that would create the situation where a vehicle appears in two jurisdictions could also happen, and does with
                           some regularity, within a jurisdiction.\
                           \
                           Vehicle A is registered under Carrier ABC Co. at the beginning of the registration year. Six months into the registration year, Vehicle A
                           breaks lease with carrier ABC Co. and leases onto Carrier XYZ, Co. Carrier ABC Co. waits several weeks to file the appropriate paper work to
                           transfer registration fees from Vehicle A to newly added vehicle B. During the interim, vehicle A is technically active in both carrier ABC
                           Co. and XYZ Co. Carrier ABC Co. paid registration fees for vehicle A and until such time that they direct the Department to either refund or
                           transfer those fees, the vehicle remains active in their fleet. Carrier XYZ Co. has also paid registration fees for the same vehicle, so the
                           vehicle is also active (albeit with a different plate number) in that fleet. I understand that from an enforcement perspective this may seem
                           confusing, but today, if a check by VIN, were conducted on the Nebraska system under the example above, both vehicles would appear active
                           until specific carrier initiated action would require us to inactivate one.\
                           \
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           IMPACT on architecture:\
                           No impact on documentation (other than SAFER ICD)

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    Include in CR 50 analysis.doc

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/21/2007 8:06:24 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          3/23/2004 11:13:12 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/21/2007 8:06:24 AM
  --------------------- -- ----------------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2561

  **External               Volpe CR 49
  Reference:**             

  **Category:**            SAFER XML service

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Review business rule for T0019 input transaction

  **Status:**              Closed Approved

  **Disposition:**         Closed with release of SAFER 4.4

  **Description:**         The SAFER/CVIEW interface as currently implemented does
                           not allow one USDOT number to be associated with more than
                           one IFTA license numbers if the records are in separate
                           input transaction files. One USDOT number can be
                           associated with multiple IFTA license numbers if the
                           records are in the same input transaction file. For
                           non-existing USDOT number, it allows for records in the
                           same input file as well as in separate input files.\
                           \
                           MMA, Inc. is requesting that the business rule be reviewed
                           and the SAFER XML service be corrected to allow one USDOT
                           number to exist with multiple IFTA license numbers for the
                           same jurisdiction. The same business rule shall be
                           implemented to the records in the same transaction file as
                           well as in separate transaction files.\
                           \
                           The fix for this CR will be available in SAFER version 4.4
                           in April.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       4/6/2004 8:27:06 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/23/2004 8:50:02 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           4/6/2004 8:27:06 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2555

  **External               WA Bill Goforth GofortB@wsdot.wa.gov - SAFER CR 108, CR
  Reference:**             4640

  **Category:**            Change the file size limit

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The maximum transaction size should be reduced from 5000
                           records to 2000 records for the T0028 IRP Registration
                           (Cab Card) Output Transaction and the T0031 MCMIS Safety
                           and Census Output Transaction.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2006-05-26\]Closed - disapproved.

  **Description:**         The maximum transaction size should be reduced from 5,000
                           records to 2,000 records for the T0028 IRP Registration
                           (Cab Card) Output Transaction and the T0031 MCMIS Safety
                           and Census Output Transaction. Allowing the higher limit
                           may result in files with size 50Mb or larger, which are
                           difficult to manage and process.\
                           \
                           \[2004-05-07\] Volpe will address in June 2004 release of
                           SAFER.\
                           \
                           \[2006-03-27\]Presented at the 2006-03-23 ACCB meeting.\
                           This CR, originally requested by WA, was recommended for
                           FMCSA approval in March, 2004, but not scheduled for
                           implementation. The states were asked if this change was
                           still desired. Volpe said that a benefit of having a
                           smaller file size would be faster aggregate processing
                           time. WA suggested limiting the .zip file size to a
                           megabyte. NE said they would prefer to receive fewer,
                           larger files. Further discussion is needed, linked to the
                           general issue of data volume (CR4640)\
                           \
                           \[2006-05-26\] Discussed at 5/18/06 ACCB meeting.\
                           The ACCB decided that this CR could be accomplished
                           through CR4640 and recommended closing this CR.\
                           \
                           Impact:\
                           Update SAFER ICD to reflect this business rule.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    NE\'s T0028 files \-- Maybe we need IRP Weight Groups.doc

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       5/31/2006 9:07:54 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/19/2004 12:44:28 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/26/2006 9:51:36 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2539

  **External               Volpe CR \# 26
  Reference:**             

  **Category:**            XML, EDI, ICD

  **Component:**           SAFER

  **Synopsis:**            Request to review SAFER business rule regarding USDOT \#
                           and IRP account \#

  **Status:**              Closed Approved

  **Disposition:**         Closed with release of SAFER 4.4

  **Description:**         Submitted on Dec 16th, 2003\
                           Nebraska is requesting that the following SAFER business
                           rule be reviewed.\
                           \
                           It is my understanding that the SAFER extract file
                           requires that US DOT number be unique to a carrier. In the
                           Nebraska system, it is possible to tie a US DOT number to
                           more than one carrier provided they are under one Master
                           account (i.e. They are using the same TIN.)\
                           One example in our system is tied to US DOT number 154318.
                           On the SAFER web site, a search by this DOT number shows a
                           legal name of: Ready Mix Concrete Co Central Sand & Gravel
                           Company and a DBA name of: Lyman-Richey Sand & Gravel
                           Company. In the Nebraska system, DOT number 154318 is tied
                           to 3 separate carriers:\
                           \
                           Lyman-Richey Corporation DBA Lyman-Richey Sand & Gravel
                           Company\
                           Lyman-Richey Corporation DBA Ready Mix Concrete Co\
                           Lyman-Richey Corporation DBA Central Sand & Gravel
                           Company\
                           \
                           These carriers have unique NE assigned IRP carrier numbers
                           and are located at different addresses.\
                           \
                           We are continuing to analyze our data while we proceed
                           with our SAFER extract implementation and hope that other
                           duplicate DOT number scenarios can be straightened out in
                           our system. However, this example above needs to be
                           addressed. Clearly the manner in which this carrier is
                           displayed on the SAFER site is confusing. The parent
                           company of all three carriers is Lyman-Richey Corporation
                           and they have chosen to establish three separate yet
                           related DBA entities. Nebraska hopes that this business
                           rule can be reviewed and that perhaps rather than
                           requiring a unique DOT number for each carrier, the
                           requirement would be to have a unique DOT number for each
                           corresponding TIN. (This would also conform to PRISM rules
                           that tie a DOT number to a TIN.)\
                           \
                           \[3-11-04\] Discussed at 1/15/04 ACCB meeting.\
                           Business rule regarding USDOT \# and IRP account \#\
                           According to the SAFER v4.2 Interface Control Document
                           (ICD), the SAFER-CVIEW XML interface allows one US DOT
                           number to be associated with multiple IRP account
                           numbers.\
                           \
                           However, the SAFER-CVIEW XML interface as currently
                           implemented does not allow one US DOT number to be
                           associated with multiple IRP accounts numbers if the
                           transactions are in separate input files. It does allow
                           one US DOT number to be associated with multiple IRP
                           account numbers if the transactions are in the same input
                           file and the US DOT number does not already exist in the
                           IRP account database.\
                           \
                           States are requesting that the business rules be reviewed
                           and that the SAFER-CVIEW XML interface be corrected to
                           support the following:\
                           1. Allow the same US DOT number to exist in multiple IRP
                           records for a jurisdiction.\
                           2. Make sure records within the same transaction file have
                           the same business rules applied to them as transactions in
                           different input files.\
                           \
                           \
                           It is recommended that Volpe review this business rule as
                           documented in the SAFER v4.2 ICD and as implemented in
                           SAFER.\
                           \
                           IMPACT on architecture:\
                           No impact on documentation (other than SAFER ICD)

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       4/6/2004 8:43:21 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/11/2004 8:45:52 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           4/6/2004 8:43:21 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2538

  **External               Volpe CR #10
  Reference:**             

  **Category:**            SAFER XML in, SAFER XML out service, ICD

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Anticipate need for XML subscription capability

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2004-05-19\] Closed - duplicate of 2412.

  **Description:**         Submitted by WI on 10/16/2003. SAFER 4.2 XML support does
                           not include a subscription capability as was implemented
                           for EDI transactions. States cannot request XML snapshots
                           for data from specific states or other criteria as is
                           available for EDI transactions. There is a concern that
                           this may become a problem due to the volume of data that
                           is being transmitted and that needs to be processed. Do
                           not yet have experienced base to tell whether this will be
                           a problem.\
                           \
                           During a TELECON on 12/17/03, WI indicated this to be
                           their third highest priority for WI-submitted CR\'s 9, 10,
                           21. They also indicated they are doing some filtering on
                           downloaded transactions but have concerns with the size of
                           the transaction files and their associated transmissions
                           costs (WI CVIEW is billed back at a per transaction
                           rate).\
                           \
                           \
                           Analysis (01202004):\
                           While performing technical analysis on options to
                           implement XML subscription capability, we received a
                           proposal from MMA, which has the similar idea as one of
                           the approaches we are considering but which is more
                           convenient for the state users. Further discussion of the
                           approach in particular between the Volpe Center and MMA
                           suggests it is a valid and feasible option. The major
                           benefit of it would be less data volume for states to
                           download from SAFER and thus would help to eliminate the
                           XML overhead and processing problem states might have.\
                           \
                           To implement this approach, SAFER will divide each output
                           transaction file into files specific for each state and
                           rename the files accordingly. In the T0025 output
                           directory one might see the following files:\
                           T0025_ID_20040102\...\_ud.zip\
                           T0025_MT_20040102\...\_ud.zip\
                           T0025_UT_20040102\...\_ud.zip\
                           T0025_NE_20040102\...\_ud.zip\
                           T0025_MD_20040102\...\_ud.zip\
                           In the T0025_ID_20040102\...\_ud.zip file one would find
                           IFTA information about carriers based only in Idaho. In
                           the T0025_UT_20040102\...\_ud.zip file one would find IFTA
                           information about carriers based only in Utah. File
                           T0025_20040102\...\_ud.zip containing IFTA information
                           about all carriers will be generated as usual.\
                           \
                           The same methodology could be applied to all transaction
                           sets except the T0031 transaction set and possibly the
                           T0032 transaction set, which we do not envision changing.\
                           \
                           Whether the subscription capability should be available
                           for baseline file generation is pending for discussion.\
                           \
                           During the interim, a new FTP directory will be created
                           for each transaction, such as T0025sub for transaction
                           T0025. The new directory T0025sub will be used to store
                           the output subscription files for T0025; example file
                           names:\
                           T0025_WI_2004010101_ud.zip\
                           T0025_NE_2004020202_ud.zip\
                           T0025_NE_2004030303_ud.zip\
                           \
                           Two options will be supported by SAFER to the CVISN states
                           to either download all the files for the specific
                           transaction, or download subscription outputs from the
                           subscription directory. States desiring to receive
                           subscriptions will need to make source code changes in the
                           CVIEW application to identify the state-specific files in
                           the subscription directories. No change is required for
                           the states not using subscriptions.\
                           \
                           Please note this particular suggestion only provides the
                           \"Regional\" function of the subscription. Other
                           subscription capabilities will be implemented at later
                           time.\
                           \
                           \[2004-03-11\] Presented at the 2/26/04 ACCB meeting.\
                           The suggested approach is essentially a self-subscribing
                           process. States clarified their requirement for XML
                           subscriptions: the output transaction file for State X
                           should contain the data for vehicles/carriers authorized
                           to operate in State X. Also, the issue of handling the
                           data from PRISM states (targeted vehicles) was addressed.
                           The file sent from PRISM states to SAFER does not contain
                           the jurisdiction/weights data. It was suggested that all
                           of the PRISM targeted vehicle information be written to
                           one separate transaction file. Volpe took an action item
                           to further analyze the proposed solution for the XML
                           subscription capability.\
                           \
                           \[2004-05-19 ncm\] This is a duplicate of CR 2412. All
                           info herein has been moved to 2412.\
                           \
                           \
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       5/19/2004 12:25:55 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/11/2004 8:37:27 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/19/2004 12:25:55 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2537

  **External               Volpe CR #9
  Reference:**             

  **Category:**            SAFER XML_in service, ICD

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Need for XML inspection report transaction

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2004-05-19\] Closed - duplicate of 2132

  **Description:**         Submitted by WI on 10/16/2003. Non-ASPEN states that will
                           be using the XML capabilities of SAFER 4.2 would like to
                           be able to send inspection reports from CVIEW to SAFER via
                           XML. The application file format (AFF) used by ASPEN
                           states could also be used by non-ASPEN states if
                           documentation were provided. During a TELCON on
                           12/17/2003, WI indicated this to be their second highest
                           priority for WI-submitted CR\'s #9, #10 and #21.\
                           \
                           \[2002-01-19\] Volpe Analysis:\
                           A new input transaction T0018 will be created to support
                           states uploading inspection reports in XML. The Volpe
                           Center will jointly work with FMCSA FST at Colorado to
                           define the XML schema file for the transaction T0018. The
                           proposed XML schema file will be used by SAFER, CVIEW,
                           SAFETYNET2000, ASPEN or equivalent systems and possibly
                           MCMIS.\
                           \
                           The data items in T0018, both required and optional, shall
                           at least be consistent with those in the Inspection Report
                           uploaded in AFF format. The framework of the current XML
                           input transactions will be used when implementing T0018.\
                           \
                           Once implemented, the CVISN states will be able to use
                           T0018 to upload the inspection reports from CVIEW to SAFER
                           in XML format. These inspection reports will subsequently
                           be processed by the SAFER XML_in service.\
                           \
                           For roadside inspectors, the inspection reports will be
                           uploaded in XML from ASPEN or an equivalent system through
                           HTTP protocol and processed subsequently by SAFER web
                           service.\
                           \
                           The SAFER web service will be an enhancement to the SAFER
                           system to support real time query and uploads. The details
                           of this enhancement are documented in SAFER CR#21, which
                           has been approved by FMCSA.\
                           \
                           \[2004-03-11\] presented at the 2/26/04 ACCB meeting.\
                           Recommended for FMCSA approval. If approved, this change
                           will be targeted for the July, 2004 release of SAFER. It
                           will be implemented via the existing FTP method.\
                           \
                           Regarding the statement \"For roadside inspectors, the
                           inspection reports will be uploaded in XML from ASPEN or
                           an equivalent system through HTTP protocol and processed
                           subsequently by SAFER web service\", this would be a
                           future capability; there is no current plan.\
                           \
                           \[2004-04-16\] presented at the 4/15/04 ACCB meeting.\
                           The solution to the XML inspection report transaction will
                           be implemented as a web service. Iowa will test the
                           transaction. This feature will be available in a special
                           release in May. This change will also be implemented via
                           the FTP method; that capability will be available in the
                           July quarterly release of SAFER.\
                           \
                           Impact on architecture:\
                           ASPEN - SAFER XML\
                           \
                           \[2004-05-19 ncm\] This is a duplicate of CR 2132. All
                           info herein has been moved to 2132.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       5/19/2004 12:27:24 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/11/2004 8:34:19 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/19/2004 12:27:24 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2535

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Add equipment package descriptions to CVISN Architecture
                           document

  **Status:**              Closed Approved

  **Disposition:**         Closed following publication of document

  **Description:**         Baseline V1.0 of the CVISN Architecture document does not
                           include descriptions of the equipment packages shown on
                           the CVISN Architecture Flow Diagram. To make the
                           architecture document more complete, descriptions should
                           be added.\
                           \
                           \[2004-03-19\] Presented at the 3/18/04 ACCB meeting. This
                           CR has already been approved by FMCSA. Open pending
                           publication of the document.\
                           \
                           IMPACT SUMMARY:\
                           ACCB Items:\
                           1. CVISN Architecture document

  **Fix:**                 Extracted the definitions from the National ITS
                           Architecture and included as Table 4 of the document.\
                           ACCB Items:\
                           1. CVISN Architecture document\
                           \
                           CVISN Architecture: published and delivered via PL-04-0133
                           (POR-02-7364), 1 April 2004.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       4/5/2004 3:44:57 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/4/2004 1:53:58 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           4/5/2004 3:44:39 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2446

  **External               
  Reference:**             

  **Category:**            Communication of Changes

  **Component:**           CVIEW

  **Synopsis:**            Notification of User Authorization System changes
                           indicated need for improvement in communicating changes to
                           affected users.

  **Status:**              Closed Fixed

  **Disposition:**         Closed per ACCB meeting 2004-01-15.

  **Description:**         Maryland\'s CVIEW system administrator was surprised in
                           January 2004 to receive an email referring to changes
                           pending since October 2003 regarding FMCSA\'s change to
                           user authorization methods. It isn\'t clear who in
                           Maryland may have been notified of the impending changes
                           in October 2003. Neither the MD system architect (me) nor
                           the MD CVISN program manager (then Joe Foster) were on the
                           notification list. An effort should be undertaken to
                           review and update notification lists for impending changes
                           to SAFER and related systems that may affect the
                           interfaced systems. Because personnel changes are common,
                           a process for maintaining the contact list should be
                           implemented, probably including state CVISN program
                           managers\
                           \
                           The documentation intended to support users through the
                           change-over to UAS seems to be inconsistent with emails
                           and telephone advice provided. Specifically, the \"UAS
                           User Guide\" says \"There are currently no plans to
                           implement UAS for system-to-system connections (i.e.,
                           CVIEW-to-SAFER or PRISM-to-SAFER).\" But the Maryland
                           CVIEW-SAFER connection was disabled, and subsequent
                           dialogue indicated some uncertainty as to what connections
                           were or should have been affected.\
                           \
                           \[2004-01-16 sbs\] Discussed at 1/15/04 ACCB meeting.
                           Volpe explained that turning on UAS was not supposed to
                           affect SAFER-CVIEW connections, which was why the CVISN
                           distribution was not notified. An unexpected problem with
                           the firewall rules occurred during the transition. Volpe
                           maintains a technical support list and those users were
                           notified of the change. Any CVISN users are welcome to be
                           added to that list, but only about 10% of the messages are
                           related to CVISN. Users may also view announcements at the
                           FMCSA Technical Support website http://fmcsa-ts.dot.gov/
                           (userid and password required).\
                           \
                           Whenever a change is planned that affects the CVIEW-SAFER
                           interface, the ACCB System Architect / CVISN Program
                           Manager email list will be sent a message.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Waddell Richard L

  **Modified Time:**       3/11/2004 11:45:17 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          1/12/2004 12:43:29 PM

  **Entered By:**          Waddell Richard L

  **Severity:**            Medium

  **Priority:**            Yes

  **Type:**                Defect

  **Closed On:**           1/16/2004 11:24:24 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2444

  **External               SAFER CR 21; Wisconsin
  Reference:**             

  **Category:**            Need query capability for carrier snapshot to support XML
                           CVIEWS

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            States using XML CVIEWS do not have the query capability
                           that is available for EDI users.

  **Status:**              Closed Approved

  **Disposition:**         Closed with release of SAFER 4.4

  **Description:**         The roadside inspectors need to be able to retrieve
                           carrier snapshots from SAFER when the requested carrier
                           information does not exist in the state\'s CVIEW database.
                           The Carrier snapshot queries shall be performed by
                           connecting to SAFER via CVIEW.\
                           \
                           SAFER CR 21 was discussed at the 2003-12-18 ACCB meeting.
                           Volpe will investigate the options to providing the
                           capability to states implementing XML CVIEW systems.\
                           \
                           Volpe Analysis:(01222004)\
                           Another Change Request (CR 10) we are analyzing recommends
                           the implementation of date \"subscriptions\" similar to
                           the EDI functionality, primarily to reduce the amount of
                           data downloaded and stored locally at the CVIEW sites.
                           This CR supports that concept, as it will allow sites to
                           obtain query results from SAFER in near real-time when the
                           data is not found locally.\
                           A feasibility test was performed locally and demonstrated
                           that web services is a feasible approach to meet the
                           user\'s requirements. We recommend using existing XML
                           output transaction source code to deliver the data through
                           web services. Therefore, there is no need to develop new
                           transactions in the XML format.\
                           \
                           We recommend the web services functionality be developed
                           using existing standards WSDL and SOAP. Oracle JDeveloper
                           can be used as the development environment to automate the
                           creation of WSDL and SOAP. We also recommend providing an
                           example SAFER web services Client to a select number of
                           states to do alpha testing to ensure it suffices for their
                           functional requirements, and that the state is able to
                           incorporate the Client into their CVIEW systems.\
                           \
                           The proposed framework would allow us to easily provide
                           all current XML output transactions through web services
                           in near real-time. Any new SAFER specific transactions to
                           be developed in the future would require no additional
                           work to use the web services. Note that this change does
                           not purport to duplicate the query capabilities of other
                           FMCSA systems, Query Central (QC) in particular. For
                           transactions not inherent to SAFER (Past inspections from
                           the SAFER data mailbox for example - see CR22), we
                           recommend the CVIEW sites utilize other mechanisms.\
                           \
                           \[2004-03-09 ncm\] SAFER CR 21 was discussed at the
                           2004-02-26 ACCB meeting.\
                           Volpe explained the web services approach to implementing
                           the query capability. Three transactions (T0028, T0030,
                           and T0031) will be tested; this capability is targeted for
                           the April, 2004 release of SAFER. Eventually, other
                           transactions are expected to be implemented via web
                           services. Volpe noted that the query capability will only
                           provide data in SAFER; it will not provide the more
                           detailed or up-to-date data that may be available from
                           Query Central. There was general agreement among the
                           states to this approach; the CR has already been approved
                           by FMCSA.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       4/6/2004 8:25:36 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/18/2003 5:09:03 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           4/6/2004 8:25:36 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2443

  **External               SAFER CR 11 and CR 12
  Reference:**             

  **Category:**            Changes to SAFER-CVIEW interface to handle REVIEW_TYPE

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Two new values for CARRIER_REVIEW_TYPE are in the carrier
                           data received by SAFER from MCMIS.\
                           \
                           Summary: Since the FMCSA-sponsored CVIEW will not accept
                           the new values, Volpe has implemented a workaround to
                           change the values or not send records that would be
                           rejected.\
                           \
                           Proposal:\
                           The CVISN states change their CVIEW to accept the new
                           review type values so that the data in their CVIEW
                           databases will be consistent with the data displayed on
                           the SAFER web site. A schema change will be required; the
                           transaction T0031 will be versioned.

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2005-06-17\] Closed - incorporated into CR 3115

  **Description:**         MCMIS uses new Review Type data which has the following
                           values:\
                           \
                           G combined Compliance Review and Cargo Tank Review\
                           F Cargo Tank only review\
                           \
                           The current SAFER system failed to process records with
                           the new\
                           Review_Type data from MCMIS due to a check constraint on
                           the Review_Type\
                           column \-- REVIEW_TYPE in (\'C\',\'E\',\'H\',\'N\',\'S\')\
                           \
                           Changing the value of the REVIEW_TYPE will require changes
                           to the SAFER\
                           ICD and to CVIEW applications.\
                           \
                           SAFER CRs 11 and 12 were discussed at the ACCB meeting
                           2003-12-18.\
                           More information will be provided by Volpe.\
                           \
                           See Solution-Work Around for how this will be handled by
                           Volpe to support the SAFER/CVIEW interface.\
                           \
                           \[2004-05-07\] Closed, pending request for data from
                           states.\
                           \
                           \[2004-07-12\] Volpe has requested that this CR be
                           reopened. Volpe recommends that the CVISN states change
                           their CVIEW to accept the new review type values so that
                           the data in their CVIEW databases will be consistent with
                           those displayed on the SAFER web site. Volpe will develop
                           revised schema files.\
                           \
                           If states accept this CR, the implementation timeframe
                           needs to be discussed. Volpe proposes that they would
                           continue to support the work around until the end of
                           September. Volpe would provide technical assistance to the
                           states in making this change.\
                           \
                           \[2004-07-19\] Presented and discussed at the 2004-07-15
                           ACCB meeting.\
                           This CR was reopened at Volpe\'s request and will be
                           posted to the CVISN Systems Architects list serv for
                           review. Volpe will provide information on the changes that
                           were made to SAFER so states can better judge the
                           monetary/time impact. It is targeted for inclusion in
                           SAFER 4.6 due to be released in September. States
                           attending the meeting had no concerns over implementing
                           this CR. A test case will be sent to APLINT to determine
                           whether there is an impact on the EDI interface.\
                           \
                           \[2004-08-23\] Presented and discussed at the 2004-08-19
                           ACCB meeting.\
                           States agreed to the proposal that \"the CVISN states
                           change their CVIEW to accept the new review type values so
                           that the data in their CVIEW databases will be consistent
                           with those displayed on the SAFER web site.\" Wisconsin
                           and Utah volunteered to beta-test T0031V2. This CR is
                           recommended for FMCSA approval and implementation in the
                           next release of SAFER, 2004-09-30. However, because the
                           impact of this change on the State CVIEWs is not clear,
                           the date for turning off T0031V1 has been extended to
                           2005-01-01. See related CR 2933.\
                           \
                           \[2004-09-27\] Discussed at the 2004-09-23 ACCB meeting.\
                           Because additional values are going to be supplied by
                           MCMIS, beta-testing has been postponed until October, and
                           the CR will not be implemented until the January SAFER
                           release.\
                           \
                           \
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD\
                           \
                           Impact on States:\
                           XML states would have to use the versioned schema. If they
                           have a database constraint on the REVIEW_TYPE field, or if
                           they do any processing based on the value of that field,
                           that processing may need to change.\
                           Utah noted that changes could probably be done in one
                           day.\
                           There seems to be no impact on EDI states, as any unknown
                           value of REVIEW_TYPE is mapped to \"Other\".\
                           \
                           \[2005-06-17\] Closed - incorporated into CR 3115

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       6/17/2005 7:37:17 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/18/2003 4:49:16 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           6/17/2005 7:37:17 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2417

  **External               Volpe CR #2
  Reference:**             

  **Category:**            Addition of fields to XML inspection summary transaction

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Change to SAFER to process and send Level 6 Radiological
                           data in inspection reports.\
                           \
                           The current version of SAFER, v 4.2.3.10, does not accept
                           input files from ASPEN which have radiological records.

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2004-05-12\] Closed, incorporated into CR 2132.

  **Description:**         The following code change to SAFER has been made in v
                           4.2.3.10 in order for SAFER to accept the inspection
                           reports in question:\
                           - Changed the 284 record processing code to read and
                           ignore the new radiological data fields.\
                           \
                           However, SAFER will eventually be changed to send the
                           radiological data in output transactions. This will impact
                           states\' CVIEW systems.\
                           \
                           Analysis is pending on what the new fields are and when
                           the change will be made. Note that the affected XML
                           transactions will be versioned, so that states may still
                           use the XML transactions that are in place now and will
                           not have to change their code immediately.\
                           \
                           \[2003-11-21:sbs\] Update from Volpe 2003-11-20\
                           No change will be made to SAFER to accept or to send
                           radiological data to states until CR 2132, Need for XML
                           input transaction, is implemented.\
                           \
                           Presented at ACCB meeting 2003-11-20.\
                           \
                           \[20040507\] Closed, incorporated into CR 2132.

  **Fix:**                 Close this CR and update CR 2132 to incorporate this
                           potential change.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       5/12/2004 10:19:45 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          11/13/2003 10:52:26 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/12/2004 10:19:45 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2416

  **External               Volpe CR #1
  Reference:**             

  **Category:**            Change to field sizes in XML inspection summary
                           transaction

  **Component:**           SAFER/CVIEW

  **Synopsis:**            Change to SAFER to support extended field sizes used by
                           SAFETYNET 2000 and ASPEN.\
                           \
                           The new ASPEN and SAFETYNET releases are sending
                           inspection reports with extended field sizes for a number
                           of fields.

  **Status:**              Closed Fixed

  **Disposition:**         \[2004-05-07\] Closed. Implemented in SAFER 4.3.

  **Description:**         The SAFER ELQ Service version 4.2.3.10 has been deployed
                           with changes to support the new releases of SAFETYNET and
                           ASPEN. The changes are completely transparent as far as
                           end users are concerned. However, SAFER will eventually be
                           changed to send the extended fields in output transactions
                           without truncating them. This will impact states\' CVIEW
                           systems.\
                           \
                           Analysis is pending on what fields are affected and when
                           the change will be made. Note that the affected XML
                           transactions will be versioned, so that states may still
                           use the XML transactions that are in place now and will
                           not have to change their code immediately.\
                           \
                           \[2003-11-21 sbs\] Volpe update 2003-11-20\
                           This CR affects XML transactions T0022, T0028.\
                           \
                           The following fields have changed sizes:\
                           \
                           Inspection Report Fields\
                           Carrier Name changes from 55 characters to 120\
                           Carrier Street from 30 to 50\
                           Shipper Name from 55 to 120\
                           \
                           Vehicle Fields\
                           Owner Name from 55 to 120\
                           Operator Name from 55 to 120\
                           \
                           Discussed at ACCB meeting 2003-11-20. Volpe would use
                           version identification for the new transactions. States
                           would be able to use the older version until ready to
                           process the longer length records. States will need to
                           implement a means to identify the transaction versions.
                           Bill Guiffre asked for a schema and example transactions
                           and Volpe accepted an action item to send that information
                           out in the next week.\
                           \
                           \[2003-11-25\] Volpe provided a schema and example
                           transactions demonstrating the changes in XML transactions
                           T0022 and T0028 and the use of versioning.\
                           \
                           \[2004-05-07\] T0028 v2 was implemented in SAFER 4.3
                           released January, 2004.\
                           \
                           \[2004-05-07 clarification Jingfei Wu\] The changes in
                           SAFER CR#1 (CR 2416) are in T0028v2. Primarily field size
                           changes.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       5/18/2004 9:08:13 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          11/13/2003 10:46:08 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/7/2004 4:17:02 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- -----------------------------------------------------------
  **CR Number:**           2412

  **External               Tania Rossouw, Wisconsin; SAFER CR 10
  Reference:**             

  **Category:**            SAFER XML in, SAFER XML out service, ICD

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Implement SAFER XML subscription capability.

  **Status:**              Closed Approved

  **Disposition:**         \[2006-09-18\] Closed; incorporated into SAFER Release 5.1.

  **Description:**         SAFER 4.2 XML support does not include an XML subscription
                           capability, as was implemented for EDI transactions.
                           Submitted by WI on 10/16/2003.\
                           \
                           States cannot request XML snapshots for data from specific
                           states or other criteria, as is available for EDI
                           transactions. There is a concern that this may become a
                           problem, due to the volume of data that is being
                           transmitted and that needs to be processed.\
                           \
                           \[2003-10-17 ncm\] Discussed at ACCB meeting 2003-10-16.
                           Volpe has started to look into this problem.\
                           \
                           During a TELECON on 12/17/03, WI indicated this to be their
                           third highest priority for WI-submitted SAFER CR\'s 9, 10,
                           21. They also indicated they are doing some filtering on
                           downloaded transactions but have concerns with the size of
                           the transaction files and their associated transmissions
                           costs (WI CVIEW is billed back at a per transaction rate).\
                           \
                           \[20040120\] Volpe Analysis and proposed solutions:\
                           While performing technical analysis on options to implement
                           XML subscription capability, Volpe received a proposal from
                           MMA, which is similar to one of the approaches being
                           considered but which is more convenient for the state
                           users. Further discussion of the approach in particular
                           between the Volpe Center and MMA suggests it is a valid and
                           feasible option. The major benefit of it would be less data
                           volume for states to download from SAFER and thus would
                           help to eliminate the XML overhead and processing problem
                           states might have.\
                           \
                           To implement this approach, SAFER would divide each output
                           transaction file into files specific for each state and
                           rename the files accordingly. In the T0025 output directory
                           one might see the following files:\
                           T0025_ID_20040102\...\_ud.zip\
                           T0025_MT_20040102\...\_ud.zip\
                           T0025_UT_20040102\...\_ud.zip\
                           T0025_NE_20040102\...\_ud.zip\
                           T0025_MD_20040102\...\_ud.zip\
                           In the T0025_ID_20040102\...\_ud.zip file one would find
                           IFTA information about carriers based only in Idaho. In the
                           T0025_UT_20040102\...\_ud.zip file one would find IFTA
                           information about carriers based only in Utah. File
                           T0025_20040102\...\_ud.zip containing IFTA information
                           about all carriers will be generated as usual.\
                           \
                           The same methodology could be applied to all transaction
                           sets except the T0031 transaction set and possibly the
                           T0032 transaction set, which Volpe does not envision
                           changing.\
                           \
                           Whether the subscription capability should be available for
                           baseline file generation is pending for discussion.\
                           \
                           During the interim, a new FTP directory could be created
                           for each transaction, such as T0025sub for transaction
                           T0025. The new directory T0025sub would be used to store
                           the output subscription files for T0025; example file
                           names:\
                           T0025_WI_2004010101_ud.zip\
                           T0025_NE_2004020202_ud.zip\
                           T0025_NE_2004030303_ud.zip\
                           \
                           Two options could be supported by SAFER to the CVISN states
                           to either download all the files for the specific
                           transaction, or download subscription outputs from the
                           subscription directory. States desiring to receive
                           subscriptions would need to make source code changes in the
                           CVIEW application to identify the state-specific files in
                           the subscription directories. No change is required for the
                           states not using subscriptions.\
                           \
                           Please note this particular suggestion only provides the
                           \"Regional\" function of the subscription. Other
                           subscription capabilities will be implemented at later
                           time.\
                           \
                           \[2004-03-11\] Presented at the 2/26/04 ACCB meeting.\
                           The suggested approach is essentially a self-subscribing
                           process. States clarified their requirement for XML
                           subscriptions: the output transaction file for State X
                           should contain the data for vehicles/carriers authorized to
                           operate in State X. Also, the issue of handling the data
                           from PRISM states (targeted vehicles) was addressed. The
                           file sent from PRISM states to SAFER does not contain the
                           jurisdiction/weights data. It was suggested that all of the
                           PRISM targeted vehicle information be written to one
                           separate transaction file. Volpe took an action item to
                           further analyze the proposed solution for the XML
                           subscription capability.\
                           \
                           \[2004-06-16\] See attached overview.\
                           \
                           Proposed Requirements\
                           \
                           - The subscription function shall support both baseline and
                           update files. The time interval of the subscription output
                           depends on the time interval that is configured for SAFER
                           system and the availability of the update data.\
                           \
                           - States shall define or modify their subscriptions using a
                           web interface through SAFER web site.\
                           \
                           - Access to the subscription link shall be limited to the
                           privileged state users.\
                           \
                           - After completion of the subscription request, an email
                           shall be sent to the subscriber confirming the requested
                           data sets or notifying of any subscription failure.\
                           \
                           - The SAFER Subscription Service shall fulfill states\'
                           subscriptions based on the requests pre-defined by the
                           states in the previous step. For each output transaction,
                           SAFER shall generate the subscription data list by states,
                           as well as a full set of snapshots as it currently does.\
                           \
                           - Each subscribed state shall have a subscription folder
                           created under each output transaction directory where the
                           subscription output shall be stored. For example, for
                           transaction T0025, the subscription folder for Wisconsin
                           will be \"SUBU_WI\", where U stands for update. Other
                           values for the 4th character in the folder name include: B
                           for baseline, P for PRISM subscription.\
                           \
                           Notes:\
                           - The XML subscription function will be first available
                           though the FTP interface, and will be extended to use the
                           SAFER web service in the future.\
                           \
                           \[2004-06-21\] Presented and discussed at the 6/17/04 ACCB
                           meeting.\
                           Since this CR was discussed in April, Volpe has provided
                           analysis and requirements. Volpe will provide an estimate
                           of cost and schedule to Janet Curtis. The states indicated
                           that this CR is only of value if there is the capability of
                           selecting the vehicles that operate in the state (versus
                           only vehicles with base registration for the state). Volpe
                           will add this as a requirement (output for vehicles that
                           operate in state \"x\"). With this addition, Nebraska,
                           Idaho, and Wisconsin agree that this CR should be
                           implemented. The CR will be posted on the CVISN Systems
                           Architects list serv for review.\
                           \
                           \[2004-07-19\]\
                           One state responded to the list serv posting and agreed
                           with the request for an XML subscription capability.\
                           \
                           Presented at the 7/15/04 ACCB meeting. This CR was
                           recommended for FMCSA approval.\
                           \
                           \[2004-07-26\] Clarification from Andrew Wilson 7/23/04\
                           I would like to submit for discussion a clarification of
                           the Requirement concerning filtering for the proposed XML
                           subscription capability:\
                           \
                           For the SAFER XML subscription service, the \"Primary
                           Filtering\" shall filter records pertaining to vehicles or
                           carriers and only include those records that are authorized
                           to operate in the subscribing state.\
                           \
                           Proposed algorithm for Primary Filtering for SAFER XML
                           subscriptions. For vehicle records, the filtering will be
                           based on whether there exists an IRP jurisdiction record
                           for the vehicle and the state subscriber.\
                           \
                           Based on the set of vehicles authorized to operate in the
                           subscribing state, the XML subscription service shall
                           compute a list of carriers that operate in the subscribing
                           state.\
                           \
                           For records that are indexed by DOT number, the filtering
                           will be based on the computed list of carriers that operate
                           in the subscribing state.\
                           \
                           \[2005-10-05\] Implemented in SAFER v4.8 - closed.\
                           \
                           \[2006-03-29\] Presented at the 2006-03-23 ACCB meeting.\
                           This was partially implemented (T0028 only) in October,
                           2005. It will be extended to T0031 and possibly other
                           transactions. States should let Volpe know which other
                           transactions are of interest. Both the architecture and
                           SAFER versions will be reopened to include additional
                           transactions. This is a candidate for SAFER Release 5.1 in
                           August.\
                           \
                           \[2006-09-18\] Closed; incorporated into SAFER Release
                           5.1.\
                           \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\
                           \
                           Impact on architecture:\
                           Change to CVIEW - SAFER XML interface at detailed level\
                           \
                           Impact on documentation:\
                           SAFER ICD

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CR2412 (SAFER CR 10) summary.doc

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       1/23/2007 12:44:41 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          10/14/2003 11:53:58 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Enhancement

  **Closed On:**           9/18/2006 6:57:50 AM
  --------------------- -- -----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2410

  **External               
  Reference:**             

  **Category:**            SAFER now stores Inspection Reports for 90 days

  **Component:**           SAFER

  **Synopsis:**            SAFER has been changed to store inspection reports (IRs)
                           for 90 days rather than 60 days. It will eventually be
                           changed to store IRs for 120 days. Documents under
                           configuration control need to be changed to indicate this.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         SAFER has been changed to store inspection reports (IRs)
                           for 90 days rather than 60 days. It will eventually be
                           changed to store IRs for 120 days. Documents under
                           configuration control need to be changed to indicate
                           this.\
                           \
                           \
                           ACCB Documents Affected:\
                           COACH Part 1 - no longer maintained\
                           COACH Part 3\
                           COACH Part 5 - no longer maintained\
                           Other Documents Affected:\
                           CVISN Guide to Safety Information Exchange - no longer
                           maintained\
                           SCOPE Workshop - Session 5 - no longer maintained\
                           \
                           \[20031017sbs\] Presented at ACCB meeting 2003-10-16.

  **Fix:**                 COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.\
                           COACH Part 1 will not be updated at this time.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       5/7/2004 2:32:48 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          10/10/2003 11:31:58 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/7/2004 2:32:48 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------
  **CR Number:**           2390

  **External               
  Reference:**             

  **Category:**            CVISN - National ITS Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Update CVISN Architecture to keep pace with changes to the National ITS Architecture
                           (Version 5)

  **Status:**              Closed Approved

  **Disposition:**         Closed following publication of document

  **Description:**         The National Intelligent Transportation Systems (ITS) Architecture is about to release
                           version 5.0. The most significant Version 5.0 enhancement is the improvement of the
                           coverage of transportation security in the National ITS Architecture
                           \<http://itsarch.iteris.com/itsarch/version5.0beta/html/security/securityhome.htm\>.
                           These improvements include updates to the physical architecture, market packages,
                           logical architecture, and supporting documentation. Using ITS to Enhance
                           Transportation Security is addressed in the following areas: Transit, Rail, Freight
                           and Commercial Vehicle, HAZMAT, Wide Area Alerts, Transportation Infrastructure, and
                           Disaster Response and Evacuation. In addition, guidance is now offered on ways in
                           which ITS can be made more secure. A new security document was created to define and
                           present aspects to ITS-related surface transportation security and their applicability
                           to the National ITS Architecture. It provides context and guidance for using the
                           security-related parts of the National ITS Architecture when developing regional and
                           project ITS architectures.\
                           \
                           The CVISN Architecture is represented by a diagram that depicts subsystems, equipment
                           packages, architecture flows, and terminators represents the CVISN Architecture \[see
                           CVISN Web site: http://www.jhuapl.edu/cvisn/ \> Documents \> CVISN Architecture and
                           Standards\]. Tables provide additional information about each item shown on the
                           diagram. The diagram and tables in the CVISN architecture should be updated to include
                           National ITS Architecture changes as summarized in the attachment.\
                           \
                           \[2003-10-10 ncm per VBB email Fri 6/13/2003 9:25 AM\]\
                           In the upcoming Version 5.0 of the National ITS Architecture, the definition for
                           architecture flow \"Information on Violators\" will be revised as follows:
                           \"Information on violators provided by a law enforcement agency. May include
                           information about commercial vehicle violations or other kinds of violations
                           associated with the particular entity. The information may be provided as a response
                           to a real-time query or proactively by the source. The query flow is not explicitly
                           shown.\"\
                           \
                           \[2003-10-17 ncm\] Presented at 10/16/03 ACCB meeting.\
                           \
                           \[2003-10-27 ncm\] Addtions to attachment - in the course of updating the document,
                           there were some additional architecture flows, subsystems and terminators that need to
                           be added, are new or have updated definitions. The document was updated to reflect
                           this..\
                           Alerting and Advisory Systems, EVS, ADMS, EM, RS, TCS, alerts and advisories, CVO
                           driver initialization, CVO pass/pull-in message, emergency notification, information
                           on violators, road network conditions, trip log information, vehicle location.\
                           \
                           \[2003-10-28 ncm\] The document should be updated to reflect the NITSA V5.0 definition
                           for the Fixed Point Communications architecture interconnect.\
                           \
                           IMPACT SUMMARY:\
                           ACCB Items:\
                           1. CVISN Architecture Flow diagram\
                           2. CVISN Architecture document\
                           \
                           Note: other CVISN documents containing the flow diagram are not being maintained.

  **Fix:**                 ACCB Items:\
                           1. CVISN Architecture Flow diagram\
                           2. CVISN Architecture document\
                           \
                           CVISN Architecture: published and delivered via PL-04-0133 (POR-02-7364), 1 April
                           2004.

  **Comment:**             

  **Attachment names:**    Natl ITS Arch V5 Impacts on CVISN Arch R1.doc

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       4/5/2004 3:43:47 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/17/2003 2:02:59 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           4/5/2004 3:43:47 PM
  --------------------- -- --------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2178

  **External               
  Reference:**             

  **Category:**            COACH Part 4

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            COACH 4 - cleanup

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         Various changes were made to update the COACH Part 4 for
                           publication including:\
                           \*\*Expand acronyms\
                           \*\*References updated\
                           \*\*Section 2 - split the interface function diagram into
                           4; dispensed with separate Interface Standards diagram(s)\
                           \*\*Remove version number from SAFETYNET\
                           \*\*Added CR section at back explaining impacts\
                           \
                           \[2003-10-17 ncm\] Presented at 10/16/03 ACCB meeting.\
                           \
                           ACCB Impact:\
                           1. COACH, Part 4

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/11/2004 3:36:34 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          7/9/2003 2:29:29 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:13:43 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2156

  **External               
  Reference:**             

  **Category:**            COACH Part 4

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            COACH 4 - add Query Central interface info

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         Added CIA interfaces to the COACH 4 Table 2-1 (Standard
                           Interface Identification Table) in accordance with the
                           attached Query Central document.\
                           \
                           \[2003-10-16 ncm\] Presented at 10/16/03 ACCB meeting.\
                           \
                           ACCB Impact:\
                           COACH Part 4

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.

  **Comment:**             

  **Attachment names:**    Brenda Lantz Query Central Jan03.ppt

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/11/2004 3:36:21 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/27/2003 3:26:44 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:13:13 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2155

  **External               
  Reference:**             

  **Category:**            COACH Part 4

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            COACH 4 - correct safety system interfaces

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         In Table 2-1(Standard Interface Identification Table),
                           many interfaces between safety systems (ASPEN, CVIEW,
                           SAFER, SAFETYNET, MCMIS) indicate the use of the
                           SAFER/CVIEW Data Mailbox. We brought these into accordance
                           with the SAFER ICDs and comments received during review of
                           the SAFE current systems document.\
                           \
                           The interface diagrams will also be updated to reflect the
                           revised table.\
                           \
                           \[2003-10-17 ncm\] Presented at 10/16/03 ACCB meeting.\
                           \
                           ACCB Impact:\
                           COACH Part 4

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/11/2004 3:36:10 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/27/2003 3:25:54 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:12:50 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2147

  **External               
  Reference:**             

  **Category:**            COACH Part 4

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            COACH 4 - replace EDI-A, etc, with AA, etc.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         To simplify both the Level 1 drawings and the Standard
                           Interface Identification Table (table 2-1), replace the
                           identification labels EDI-A, etc, with AA, etc. Add to the
                           \"Std\" column \"XML\", \"HTML\", and \"CIA\" as
                           appropriate.\
                           \
                           General rules:\
                           \*\* Wherever EDI is available for a carrier to state
                           interface, add XML and HTML\
                           \*\* Wherever EDI is available for an interface within the
                           state, add XML and CIA\
                           \*\* Wherever EDI is available for a state to core
                           infrastructure interface, add XML and possibly HTML\
                           \
                           Remove/renumber INT rows of the table since most are now
                           covered by the AA, etc, rows.\
                           \*\* Int A in AA\
                           \*\* Int B in HH\
                           \*\* Int C in UU\
                           \*\* Int D becomes Int A\
                           \*\* Int E deleted\
                           \*\* Int F in LL\
                           \*\* Int G in RR\
                           \
                           AFF-A removed - no evidence it was true\
                           AFF-F removed - no evidence it was true\
                           AFF-H removed because it is covered in AFF-E without any
                           SDM involvement\
                           \
                           CIA-C removed - no evidence that this is so\
                           Old CIA-R removed - covered by CIA-E\
                           \
                           If an XML standard exists, reference it in the table.\
                           \
                           \[2003-10-17 ncm\] Presented at 10/16/03 ACCB meeting.\
                           \
                           ACCB Impact:\
                           COACH Part 4

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/11/2004 3:36:04 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/25/2003 9:26:52 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:12:13 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2137

  **External               
  Reference:**             

  **Category:**            COACH 3

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            COACH 3 - cleanup

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         Various changes were made to update the COACH Part 3 for
                           publication including:\
                           \*\* Update References format\
                           \*\* Expand acronyms\
                           \*\* XML as a current (as opposed to future) capability\
                           \*\* Adopt the COACH Part 1 L1/E/C requirement level in
                           the appendices\' tables\
                           \*\* Use \"X\" as the requirement level for design
                           components not considered essential to achieve CVISN Core
                           (Level 1) functionality in the appendices\' tables\
                           \
                           \[2003-09-19 ncm\] Presented at ACCB meeting 9/18/2003.\
                           \
                           \
                           ACCB Impact:\
                           COACH 3

  **Fix:**                 COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/11/2004 3:35:18 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/23/2003 9:10:14 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/23/2003 7:16:42 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2132

  **External               Tania Rossouw, Wisconsin - Volpe CR 9
  Reference:**             

  **Category:**            Need for XML inspection report transaction

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The XML inspection summary transaction in SAFER 4.2 is an
                           output transaction from SAFER to the states. There is no
                           XML inspection report transaction from the state to SAFER.
                           Wisconsin, a non-ASPEN state, would like an input XML
                           inspection report transaction.

  **Status:**              Closed Approved

  **Disposition:**         \[2004-07-19\] Closed - implemented in SAFER 4.5.

  **Description:**         The application file format (AFF) used by ASPEN to send
                           inspection reports to SAFER has not been documented for
                           use by systems other than SCAPI. Non-ASPEN states that
                           will be using the XML capabilities of SAFER 4.2 would like
                           to be able to send inspection reports to SAFER via XML as
                           well.\
                           \
                           This CR was created in response to action item assigned at
                           ACCB meeting June 19, 2003.\
                           \
                           \[2003-10-17 ncm\] Discussed at ACCB meeting 2003-10-16.
                           Tania Roussouw said that ASPEN has defined/implemented an
                           XML interface for inspection reports. What is needed now
                           is for SAFER to be able to read it. This is one example of
                           the larger problem of capability gaps in the XML version
                           of SAFER.\
                           \
                           \[2003-11-21 sbs\] CR 2417, Addition of fields to XML
                           inspection summary transaction, has been closed and
                           incorporated into this CR. When this CR is addressed, it
                           will be decided what radiological data will be included in
                           input and output transactions between SAFER and CVIEW.\
                           \
                           \[2002-01-19\] Volpe Analysis:\
                           A new input transaction T0018 will be created to support
                           states uploading inspection reports in XML. The Volpe
                           Center will jointly work with FMCSA FST at Colorado to
                           define the XML schema file for the transaction T0018. The
                           proposed XML schema file will be used by SAFER, CVIEW,
                           SAFETYNET2000, ASPEN or equivalent systems and possibly
                           MCMIS.\
                           \
                           The data items in T0018, both required and optional, shall
                           at least be consistent with those in the Inspection Report
                           uploaded in AFF format. The framework of the current XML
                           input transactions will be used when implementing T0018.\
                           \
                           Once implemented, the CVISN states will be able to use
                           T0018 to upload the inspection reports from CVIEW to SAFER
                           in XML format. These inspection reports will subsequently
                           be processed by the SAFER XML_in service.\
                           \
                           For roadside inspectors, the inspection reports will be
                           uploaded in XML from ASPEN or an equivalent system through
                           HTTP protocol and processed subsequently by SAFER web
                           service.\
                           \
                           The SAFER web service will be an enhancement to the SAFER
                           system to support real time query and uploads. The details
                           of this enhancement are documented in SAFER CR#21, which
                           has been approved by FMCSA.\
                           \
                           \[2004-03-11\] presented at the 2/26/04 ACCB meeting.\
                           Recommended for FMCSA approval. If approved, this change
                           will be targeted for the July, 2004 release of SAFER. It
                           will be implemented via the existing FTP method.\
                           \
                           Regarding the statement \"For roadside inspectors, the
                           inspection reports will be uploaded in XML from ASPEN or
                           an equivalent system through HTTP protocol and processed
                           subsequently by SAFER web service\", this would be a
                           future capability; there is no current plan.\
                           \
                           \[2004-04-16\] presented at the 4/15/04 ACCB meeting.\
                           The solution to the XML inspection report transaction will
                           be implemented as a web service. Iowa will test the
                           transaction. This feature will be available in a special
                           release in May. This change will also be implemented via
                           the FTP method; that capability will be available in the
                           July quarterly release of SAFER.\
                           \
                           \[2004-05-07\] clarification by Jingfei Wu\] Changes in
                           SAFER CR#2 (CR 2132) are not related to T0028 v2 at all.
                           These are inspection data. We only made changes in SAFER
                           to accept the radiological data from ASPEN and SAFETYNET.
                           SAFER is not sending the data to CVIEW. So no impact right
                           now. If the CVISN users are interested in getting
                           radiological data, then we will include the data in
                           T0030.\
                           \
                           \[2004-07-12\] From SAFER CR 9: The implementation of this
                           CR has been divided into two phases. (1) Inspection
                           uploads using SAFER web service will be implemented in
                           version 4.5 scheduled on July 19th.\
                           (2) The IR uploads using SAFER XML service through FTP
                           protocol will be available in version 4.6 in September.\
                           \
                           \[2004-07-19\] Presented as the 7/15/04 ACCB meeting.\
                           This CR has been implemented in the new version of SAFER
                           (version 4.5) - CR is closed.\
                           \
                           \
                           Impact on architecture:\
                           ASPEN - SAFER XML

  **Fix:**                 Workaround: A state could implement SCAPI to create the
                           AFF format that is used by ASPEN to send the inspection
                           report to SAFER.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       7/19/2004 12:04:09 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/19/2003 4:50:18 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           7/19/2004 12:04:09 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2110

  **External               
  Reference:**             

  **Category:**            National ITS Architecture V5

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Natl Arch V5 - updated definition for \"Information on
                           Violators\"

  **Status:**              Closed Is Duplicate

  **Disposition:**         Closed - incorporated into CR 2390

  **Description:**         In the upcoming Version 5.0 of the National ITS
                           Architecture, the definition for architecture flow
                           \"Information on Violators\" will be revised as follows:\
                           \
                           \"\"Information on violators provided by a law enforcement
                           agency. May include information about commercial vehicle
                           violations or other kinds of violations associated with
                           the particular entity. The information may be provided as
                           a response to a real-time query or proactively by the
                           source. The query flow is not explicitly shown.\"\
                           \
                           per VBB email Fri 6/13/2003 9:25 AM\
                           \
                           \[2003-10-10 ncm - moved this CR into CR 2390\]

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 6:53:17 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/13/2003 9:35:17 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Low

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 8:38:47 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           2045

  **External               
  Reference:**             

  **Category:**            E-Screening Enrollment

  **Component:**           CVISN Architecture

  **Synopsis:**            what escreening jurisdictions can a carrier enroll in ??

  **Status:**              Closed Fixed

  **Disposition:**         Closed.

  **Description:**         in SAFER v4.2, a carrier may request to participate in
                           escreening in one or more jurisdictions via a T0023 XML
                           transaction or EDI snapshot.\
                           \
                           What choice of jurisdictions should be available to the
                           carrier?\
                           \
                           For instance, if a state does NOT have an escreening
                           program, should the carrier be allowed to enroll in that
                           jurisdiction anyway ? Shouldn\'t he be informed that this
                           request has been denied ?\
                           \
                           SAFER maintains a list of escreening jurisdictions that a
                           carrier may enroll in. if that list contains ONLY
                           jurisdictions that have escreening programs or have
                           otherwise agreed to participate in escreening, if a
                           carrier attempts to enroll in a jurisdiction that is NOT
                           in the list, SAFER will return an error message to the
                           carrier in the transaction log file. If the list contains
                           all possible jurisdictions, regardless of whether the
                           state has a program or wishes to participate, the carrier
                           won\'t know and transponder information could be generated
                           for that state anyway.\
                           \
                           Which states should be include in SAFER\'s list of
                           escreening jurisdictions ? ALL ? only those that policy
                           states should be included (whatever that policy might be
                           ?)\
                           \
                           This question needs to be resolved in order to ensure that
                           the deployed SAFER v4.2 works as expected by the CVISN
                           states and FMCSA.\
                           \
                           \[sbs for rkc\] 20030610 SAFER should include all
                           jurisdictions. Since there is no easy way to add
                           jurisdictions to the list now, any other solution would
                           cause maintenance problems.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/21/2003 2:55:09 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          5/23/2003 10:52:18 AM

  **Entered By:**          Goldfarb Robert H

  **Severity:**            High

  **Priority:**            Yes

  **Type:**                Defect

  **Closed On:**           6/10/2003 5:31:30 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           1992

  **External               
  Reference:**             

  **Category:**            COACH Part 1

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            CVISN \"Level 1\" changed to CVISN \"Core\"

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         As part of the CVISN program, FMCSA defined an initial set
                           of capabilities that could be deployed incrementally by a
                           state and its motor carriers. The capabilities focus on
                           electronically exchanging safety and credentialing
                           information, electronically processing interstate
                           registration and fuel tax credentials, and implementing
                           roadside electronic screening at one fixed or mobile site.
                           These capabilities were originally referred to as \"CVISN
                           Level 1\" capabilities, but are now called \"Core\" CVISN
                           capabilities.\
                           \
                           ACCB Checklist:\
                           1. COACH Part 1 - add paragraph above to 2nd page, and
                           update words in Appendix B\
                           2. COACH Part 3 - add paragraph above to 2nd page\
                           3. COACH Part 4 - add paragraph above to 2nd page

  **Fix:**                 1\. ncm 2003-05-14\
                           2. ncm 2003-05-14\
                           3. ncm 2003-05-14\
                           \
                           COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.\
                           COACH Part 4 V1.0: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 6:53:35 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          5/15/2003 6:41:20 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:11:41 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           899

  **External               
  Reference:**             

  **Category:**            E-Screening Enrollment

  **Component:**           CVISN Architecture

  **Synopsis:**            what should SAFER do if vehicle is not registered?

  **Status:**              Closed Fixed

  **Disposition:**         Closed per Robert Goldfarb \[2003-09-24\]

  **Description:**         When SAFER receives a vehicle escreen enrollment request
                           (via EDI or XML) it normally associates the TRANSPONDER ID
                           in the request to a vehicle (VIN) in SAFER \'s db.\
                           \
                           What should SAFER do if :\
                           \
                           a) there is no vehicle (VIN) record for the vehicle in the
                           db (i.e., the vehicle was never registered - SAFER has
                           never received a vehicle IRP registration edi snapshot
                           update or XML transaction) ?\
                           \
                           or\
                           \
                           b) there is a vehicle (VIN) record in the data base but it
                           is associated with ONLY an expired registration ?\
                           \
                           or\
                           \
                           c) there is a vehicle (VIN) record in the data base but it
                           is NOT associated with ANY registration. (This can happen
                           if a the plate on a vehicle (VIN record) were switched to
                           another vehicle (VIN record) - leaving the original
                           vehicle (VIN record) without a legitimate registration.
                           SAFER does not delete the VIN record in this case -
                           perhaps it should - but it doesnt.)\
                           \
                           We require requirements guidance on this issue in order to
                           proceed with SAFER v4.2 XML & EDI development.\
                           \
                           \
                           \[2003-03-20 ncm\] Presented at ACCB meeting 3/20/2003.

  **Fix:**                 \[sbs 2003-0314\]\
                           There has to be a VIN record in the database and it has to
                           be associated with a registration.\
                           \
                           In the cases described, the escreening enrollment request
                           would be accepted in case (b), but in cases (a) and (c),
                           the escreening enrollment request would be rejected.\
                           \
                           \[2003-09-24\] Implemented in SAFER v4.2 (per rhg)

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Goldfarb Robert H

  **Modified Time:**       11/24/2003 6:54:12 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          2/20/2003 1:50:56 PM

  **Entered By:**          Goldfarb Robert H

  **Severity:**            High

  **Priority:**            Yes

  **Type:**                Defect

  **Closed On:**           9/24/2003 7:30:57 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           895

  **External               
  Reference:**             

  **Category:**            CVISN Core Infrastructure

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Query Central needs to be added to the list of CVISN Core
                           Infrastructure systems.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         Query Central (QC) is an information retrieval system
                           designed to dramatically increase access to motor carrier
                           safety information for State and Federal law enforcement
                           personnel using the power of web-based technology. QC is
                           hosted at Volpe and connects directly to MCMIS, SAFER, and
                           L&I. The current user base is made up of FMCSA and State
                           Motor Carrier enforcement personnel.\
                           \
                           Query Central was added to diagrams as a CVISN Core
                           Infrastructure system.\
                           \
                           Interfaces were added to diagrams between Query Central
                           and the following systems:\
                           SAFER\
                           L&I\
                           CDLIS\
                           MCMIS\
                           Firewalls\
                           Roadside Inspections\
                           \
                           Impact Summary:\
                           ACCB Items:\
                           CVISN System Design Document\
                           COACH Part 3\
                           COACH Part 4\
                           \
                           Frequently Used Slides: (see attachments - proposed may
                           show effects of other CRs)\
                           Generic State Design Template.ppt\
                           CVISN System Design Description (ACCB)\
                           COACH Part 3 (ACCB)\
                           CVISN Guides: (no longer maintained)\
                           Top Level Design\
                           Safety Information Exchange\
                           Electronic Screening\
                           Credentials Administration\
                           Scope (no longer maintained)\
                           Generic Network Template.ppt\
                           CVISN System Design Description (ACCB)\
                           CVISN Guide to Top Level Design - no longer maintained\
                           Scope - no longer maintained\
                           CVISN Design-Stakeholder View.ppt\
                           CVISN System Design Description (ACCB)\
                           CVISN Web Page\
                           Introductory Guide to CVISN - no longer maintained\
                           Safety Information Exchange.ppt\
                           CVISN System Design Description (ACCB)\
                           CVISN Guide to Safety Information Exchange - no longer
                           maintained\
                           Scope 5 - no longer maintained\
                           Generic CVISN Configuration.ppt\
                           CVISN System Design Description (ACCB)\
                           Scope - no longer maintained\
                           CVISN System Design Legacy - Planned View.ppt\
                           CVISN System Design Description (ACCB)\
                           \
                           Other:\
                           CVISN Web Page\
                           \
                           \
                           \[2003-03-20 ncm\] Presented at ACCB meeting 3/20/2003.

  **Fix:**                 CVISN Web Page - tgn working on it\
                           \
                           Frequently Used Slides:\
                           Generic State Design Template.ppt - ncm updated 3/3/03\
                           Generic Network Template.ppt - ncm updated 3/30/03\
                           CVISN Design-Stakeholder View.ppt - ncm updated 3/30/03\
                           Safety Information Exchange.ppt - ncm updated 3/30/03\
                           Generic CVISN Configuration.ppt - ncm updated 3/30/03\
                           CVISN System Design Legacy - Planned View.ppt - ncm
                           updated 3/30/03\
                           \
                           Documents:\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.\
                           COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.

  **Comment:**             

  **Attachment names:**    CR 895 proposed.ppt\
                           CR 895 current.ppt

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       3/9/2006 11:13:21 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          2/10/2003 3:31:01 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           3/9/2006 11:13:21 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           877

  **External               
  Reference:**             

  **Category:**            New MCMIS replaces MCMIS

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            MCMIS replaced by New MCMIS

  **Status:**              Closed Fixed

  **Disposition:**         Closed.

  **Description:**         New MCMIS became operational about 3 September 2002. \"Old
                           MCMIS\" functionality needs to be replaced by \"New
                           MCMIS\" functionality in the following documents as they
                           are updated. Note that the system will be referred to as
                           \"MCMIS\", not \"New MCMIS\".\
                           \
                           Impact Summary:\
                           ACCB Items:\
                           CVISN System Design Description\
                           \
                           Frequently Used Slides (see attachment): (the documents
                           each affects are listed in the individual FUS files)\
                           CVISN Design-Stakeholder View.ppt\
                           CVISN System Design Legacy-Planned View.ppt\
                           Generic Network Template.ppt\
                           Safety Information Exchange.ppt\
                           (Note that the \"new\" slides in the attachment may
                           include changes from other CRs)\
                           \
                           \
                           Other documents not scheduled for update - listed for
                           completeness only.\
                           Introductory Guide to CVISN\
                           CVISN Guide to Top Level Design\
                           CVISN Guide to Safety Information Exchange\
                           CVISN Planning Workshop\
                           Scope\
                           \
                           \
                           \[2003-03-20 ncm\] Presented at ACCB meeting 3/20/2003.

  **Fix:**                 ACCB Items:\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           \
                           Frequently Used Slides (see attachment): (the documents
                           each affects are listed in the individual FUS files)\
                           CVISN Design-Stakeholder View.ppt\
                           CVISN System Design Legacy-Planned View.ppt\
                           Generic Network Template.ppt\
                           Safety Information Exchange.ppt\
                           (Note that the \"new\" slides in the attachment may
                           include changes from other CRs)

  **Comment:**             

  **Attachment names:**    CR0877_MCMIS CR FUS.ppt

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/23/2003 7:05:25 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          1/20/2003 7:01:04 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/23/2003 7:05:25 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           861

  **External               
  Reference:**             

  **Category:**            System Design Description

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            System Design Description document \"clean-up\"

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Various types of \"cleaning up\" need to be done to the
                           System Design Description during the current update
                           process. Some of these revisions are as follows:\
                           \* Expanding acronyms at first use\
                           \* Reorganizing to increase clarity\
                           \* Adding section 6 (Change Requests) to allow change
                           management tracking\
                           \* Modifying slide titles for consistency\
                           \* Updating references\
                           \* Section headings added to page footer\
                           \* XML was added as an option for many transactions that
                           used to be solely EDI\
                           \* Double arrows between SAFER and MCMIS were replaced by
                           a single arrow from New MCMIS to SAFER\
                           \* Information was updated to bring it in line with the
                           most recent CVISN guides and the SAFER ICD\
                           \* CAPRI updated to L1\
                           \* Add paragraph on 2nd page explaining that in the future
                           \"CVISN Level 1\" will be referred to as \"CVISN Core\"\
                           \
                           etc.\
                           \
                           \[2003-03-20 ncm\] Presented at ACCB meeting 3/20/2003.\
                           \
                           Impacted Summary:\
                           ACCB Items:\
                           System Design Description

  **Fix:**                 CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 6:54:38 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          1/7/2003 10:18:44 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/23/2003 3:06:43 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           833

  **External               
  Reference:**             

  **Category:**            E-Screening Enrollment - New Business Rules

  **Component:**           CVISN Architecture

  **Synopsis:**            Beginning with SAFER v4.2, SAFER\'s processing of
                           Electronic Screening enrollment requests will change for
                           both Carrier E-Screening and Vehicle E-Screening requests.
                           The impacts to the CVISN states desiring to participate in
                           E-Screen enrollment via EDI or XML are described below.

  **Status:**              Closed Approved

  **Disposition:**         Closed per Robert Goldfarb \[2003-09-24\]

  **Description:**         1\) Carrier E-Screen Enrollment - Carrier E-Screening
                           enrollment requests, which identify jurisdictions that a
                           carrier (identified by a DOT Number in the request) grants
                           permission to receive Transponder Numbers for his vehicles
                           participating in E-Screening enrollment, will no longer
                           need to be approved by each jurisdiction specified by the
                           carrier; only by the carrier\'s base jurisdiction, which
                           has implicitly approved it by virtue of its forwarding the
                           request to SAFER.\
                           \
                           2) Transponder Number Exchange - The Vehicle E-Screening
                           request EDI or XML transaction will be the only mechanism
                           by which a vehicle\'s Transponder Number can be entered in
                           SAFER\'s database. Starting with SAFER v4.1, a vehicle\'s
                           Transponder Number will no longer be accepted by SAFER if
                           it is included in an IRP Registration (Cab Card) EDI
                           transaction.\
                           \
                           The Vehicle E-Screening EDI or XML transaction will be the
                           mechanism by which a vehicle\'s Transponder Number will be
                           forwarded by SAFER to other CVISN states (if authorized by
                           the vehicle\'s E-Screen carrier), and only if SAFER has
                           previously received an IRP Registration (Cab Card) EDI or
                           XML transaction for that vehicle.\
                           \
                           3) Identifying an E-Screen Carrier\'s E-Screen Vehicles -
                           Vehicle E-Screening requests will no longer be used to
                           specify which of a carrier\'s vehicles are participating
                           in E-Screening. Instead, all vehicles assigned to a
                           carrier for Safety plus all vehicles for which the carrier
                           is the Registrant will be considered to be the E-Screen
                           vehicles for that carrier. The association of an E-Screen
                           carrier to his E-Screen vehicles is made via the
                           specification of the E-Screen carrier (DOT number) as
                           either the Safety carrier (CVIS_DEFAULT_CARRIER) or
                           Registrant in the vehicle\'s EDI or XML IRP Registration
                           (Cab Card) transaction sent to SAFER.\
                           \
                           Therefore, unless the vehicle\'s E-Screen carrier is
                           identified in the Cab Card transaction, it will not be
                           possible to determine if that vehicle participates in
                           E-Screening and its Transponder Number will not be
                           forwarded by SAFER to any jurisdiction - even those
                           granted permission to receive it by the vehicle\'s
                           E-Screen carrier.\
                           \
                           \[20021219 ncm\] Presented at ACCB meeting 12/19/2002.

  **Fix:**                 None needed - purpose was to document SAFER 4.2 escreening
                           logic (per rhg)

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:54:54 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/4/2002 11:01:01 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/24/2003 7:29:44 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           807

  **External               
  Reference:**             

  **Category:**            IRP Processing

  **Component:**           SAFER

  **Synopsis:**            SAFER\'s data model for vehicle registration information
                           supports a combination of IRP and PRISM requirements.\
                           \
                           The bottom line is that multiple registrations for the
                           same vehicle must be supported in the SAFER database at
                           the same time. Example 2 portrays a situation that may
                           occur. The SAFER project requires guidance as to what the
                           vehicle data should look like to ensure that the vehicle
                           registration information best reflects the \"real world\".

  **Status:**              Closed Fixed

  **Disposition:**         Closed upon SAFER 4.2 releas.

  **Description:**         SAFER Vehicle Data Model Background Information\
                           \
                           SAFER\'s vehicle data model is comprised of a Vehicle_Vin
                           database table that contains information about the vehicle
                           (VIN, Model, Model Year, Numer of Axles, Color, Title
                           Number, Title jurisdiction, etc.) from the incoming
                           registration. A Vehicle_Registration table contains the
                           information associated with the registration (License
                           Plate Number, state of registration, Safety carrier,
                           registration dates, IRP_Check_Flag, etc.). It also
                           includes a pointer to the Vehicle_Vin record for that
                           vehicle. In this way, a single Vehicle_Vin record
                           (vehicle) can be associated with many Vehicle_Registration
                           (registration) records.\
                           \
                           Example 1:\
                           \
                           MD sends in the following IRP registration information:\
                           \
                           VIN - 123\
                           Make - Ford\
                           Year - 1999\
                           Color - Blue\
                           Title No - 1234\
                           Title Jurisdiction - MD\
                           Number of Axles - 4\
                           Plate - 1234\
                           License_Plate_State - MD\
                           Registration Start Date - 20020112\
                           Registration End Date - 20021231\
                           \
                           If not already existing, a Vehicle_Vin record containing
                           the first 7 items is created and a Vehicle_Registration
                           record containing the last 4 is created.\
                           \
                           In early March, VA sends in the following IRP registration
                           information:\
                           \
                           VIN - 123\
                           Make - Ford\
                           Year - 1999\
                           Color - Blue\
                           Title No - 1234\
                           Title Jurisdiction - MD\
                           Number of Axles - 4\
                           Plate - 5678\
                           License_Plate_State - VA\
                           Registration Start Date - 20020301\
                           Registration End Date - 20020630\
                           \
                           A Vehicle_Registration record containing the last 4 items
                           is created. It points to the already existing Vehicle_Vin
                           record for VIN 123.\
                           \
                           There is no problem with this scenario. However, assume
                           that instead of the above IRP registration information
                           from VA, the following information is received:\
                           \
                           Example 2:\
                           \
                           VIN - 123\
                           Make - Dodge\
                           Year - 2002\
                           Color - Red\
                           Title No - 5678\
                           Title Jurisdiction - PA\
                           Number of Axles - 2\
                           Plate - 5678\
                           License_Plate_State - VA\
                           Registration Start Date - 20020301\
                           Registration End Date - 20020630\
                           \
                           How should SAFER handle this?\
                           \
                           Currently, the information associated with the VIN (Make,
                           color, year, title, etc.) REPLACES the previous
                           information from MD. What used to be a 4axle Blue Ford
                           titled in MD is now a 2 axle Red Dodge Titled in PA. This
                           is done, even though the registration information from VA
                           will expire before that from MD.\
                           \
                           When subscriptions are generated following processing the
                           MD registration information, the recipients will receive
                           information for a 4 axle Blue Ford. When subscriptions are
                           generated following processing of the VA registration
                           information, the recipients will receive information for a
                           2 axle Red Dodge. Both registrations designating the same
                           VIN.\
                           \
                           It is certainly possible that the vehicle was painted
                           between the time it was registered in MD and VA. It is
                           also possible that the vehicle was retitled as well. What
                           is not likely is that the 4 axle FORD is now a 2 axle
                           DODGE.\
                           \
                           When registration information is sent out in response to
                           queries or when included in the PRISM Local Target file
                           (if the vehicle were targeted), there will be 2
                           registration records - one from MD and one from VA for a 2
                           axle Red Dodge (with the same VIN).\
                           \
                           There are several alternatives to handling this
                           situation:\
                           \
                           1 - Continue doing what SAFER does now (as described
                           above).\
                           \
                           2 - Process the VA registration but don\'t update the
                           vehicle information (Make, Year, axles, etc.) in the
                           Vehicle_Vin table if it is not consistent. Report the
                           inconsistency for manual resolution. Note that since the
                           registration information comes in with many alternative
                           spellings for the same data element (e.g., \"FOR\" and
                           \"FORD\"), there would be many \"errors\" detected due to
                           spelling inconsistencies.\
                           \
                           3 - Use one of the Registration (or other?) dates to
                           determine whether to update the Vehicle_Vin information.
                           For instance, if the Registration End Date is later than
                           any already received, then update the Vehicle_Vin
                           information - even if it conflicts. This will ensure that
                           the vehicle information is consistent for all
                           registrations associated with the designated VIN.\
                           \
                           4 - Move all vehicle attribute information from the
                           Vehicle_Vin table into the Vehicle_Registration table.
                           This would ensure that all of the vehicle information
                           provided in each registration would remain consistent with
                           itself. If this were done, registration information was
                           sent out in response to queries or when included in the
                           PRISM Local Target file (if the vehicle were targeted),
                           there would be 2 registration records - one from MD for a
                           4 axle Blue Ford titled in MD and one from VA for a 2 axle
                           Red Dodge titled in PA - both having the same VIN. This
                           would rightfully be confusing to consumers.\
                           \
                           5 - Ignore Make and Model Year of the vehicle included in
                           the registration where there could be spelling or other
                           inconsistencies and use a VIN decoding algorithm to
                           determine these values. (This won\'t resolve conflicts in
                           axles, fuel, weight, etc.). Store along with the vehicle
                           color, title, axles, fuel, and weight and other
                           information from the incoming registration (with or
                           without comparing information in the database with that in
                           the incoming registration).\
                           \
                           Please advise whether the current SAFER processing
                           approach, as described above, is adequate or provide
                           alternative processing requirements.\
                           \
                           \[20021122 ncm\] Presented and discussed at ACCB meeting
                           11/21/2002.\
                           \
                           States agreed that there should be VIN decoding. Option 5
                           was agreed upon; options 2-4 should be discarded. Option 1
                           will continue to be in effect for now. The implementation
                           of a VIN algorithm will be explored and its impact on the
                           SAFER 4.2 schedule determined. Sources for two such
                           algorithms were provided by participating states and were
                           added as an attachment to the CR.\
                           \
                           In addition, Robert Goldfarb will look into the effects of
                           replacing existing data with incoming blank data fields.
                           Currently all data are replaced; whether or not existing
                           data for title number and title jurisdiction should be
                           blanked out is at issue.\
                           \
                           \[20021216 rhg\] While the response from the ACCB members
                           was positive and the VIN parsing tools look promising,
                           changes of this magnitude will definitely be beyond that
                           which can be accomplished in SAFER v4.2. After SAFER is
                           transitioned to Volpe would be a more appropriate time to
                           consider this enhancement.\
                           \
                           SAFER v4.2 will only support \"REPLACE\" operations.
                           Therefore, incomplete XML input records will result in any
                           existing data in a record being replaced by NULL data.\
                           \
                           \[20021219 ncm\] Presented at ACCB meeting 12/19/2002.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CR 807 Comments.doc\
                           CR 807 VIN algorithm sources.doc

  **Responsibility:**      Goldfarb Robert H

  **Modified Time:**       5/7/2004 1:54:03 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          11/4/2002 3:48:42 PM

  **Entered By:**          Goldfarb Robert H

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/7/2004 1:54:03 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           785

  **External               
  Reference:**             

  **Category:**            Changes to SAFER to State trans. for Veh.Inspection in
                           SAFER 4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The XML/FTP interface for SAFER shall send vehicle
                           inspection report summary data to States.\
                           \
                           The Inspection Report Summary transaction shall contain
                           information derived only from inspection reports that were
                           sent to SAFER. SAFER may not receive all inspection
                           reports pertaining to a particular vehicle, so the summary
                           only applies to a subset of the inspection reports that
                           may exist.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         CVISN Architecture documentation should be updated to
                           include support of XML/FTP interface for SAFER to send
                           vehicle inspection summary data to States. Refer to the
                           SAFER 4.2 Interface Control Document (ICD) to be released
                           in September 2002 for details.\
                           \
                           \[2002-10-18 ncm\] Presented and discussed at ACCB meeting
                           10/17/02\
                           \
                           \[2003-02-06 ncm\] The text in the synopsis was updated
                           per RHG.\
                           \
                           \[2003-02-25 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:55:11 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          10/10/2002 12:50:51 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:09:59 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           782

  **External               
  Reference:**             

  **Category:**            sendlist subscription process

  **Component:**           SAFER

  **Synopsis:**            A convention needs to be established for the values of
                           \"sender\" and \"receiver\" in the EDI transactions from
                           SAFER.

  **Status:**              Closed Fixed

  **Disposition:**         Closed per Robert Goldfarb \[2003-09-24\]

  **Description:**         The Sendlist process for filling subscriptions involves
                           creating the subscription output for one user and copying
                           it for all other subscribers, rather than repeating the
                           process of creating the bundled snapshot for each
                           subscriber to that subscription. This results in
                           inaccurate destination Trading partner IDs in the EDI
                           transaction. If the receiver of the snapshot is expecting
                           the \"receiver\" field to be their own Trading Partner ID,
                           and if they have designed a system that uses this field
                           for some purpose such as data routing or security, they
                           would have a problem with the receiver values supplied by
                           the Sendlist replication process. It is important that the
                           users of the SAFER snapshots understand that the
                           \"receiver\" field does not identify their Trading Partner
                           ID. (see SAFER CR 699)\
                           \
                           One solution that removes the presence of inaccurate
                           \"receiver\" values, is to hard code a generic destination
                           TPID such that every snapshot from SAFER would have
                           \"SAFER\" as the sender and \"subscriber\" as the
                           recipient. These values would be present in the ISA, GS
                           and NM1 segments of the EDI message. If there is consensus
                           on this approach, the convention should be documented in
                           the SAFER requirements, design description and interface
                           documents.\
                           \
                           \[2002-10-18 ncm\] Presented and discussed at ACCB meeting
                           10/17/2002. States agreed that the proposed solution will
                           work.\
                           \
                           Impact summary:\
                           1. SAFER requirements documents\
                           2. CVIEW 3.3 CD documentation \"CVIEW Utility
                           Instructions\" and \"CVIEW Release Notes\"\
                           3. SAFER design documents\
                           \
                           \[2003-09-24 ncm per rhg\] Changes implemented in SAFER &
                           CVIEW v3.3.

  **Fix:**                 RHG 10/18/02:\
                           \
                           changed sendlist 3.3 to use generic \"SUBSCRIBER\"
                           recipient trading partner and use application\'s MY_TP_ID
                           registry key as the sender TP.\
                           \
                           still need to change carrier & vehicle sendlist version
                           4.x\
                           \
                           Impacted documents:\
                           1.\
                           2.\
                           3.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Stuart Mary W

  **Modified Time:**       11/24/2003 6:55:27 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          10/8/2002 3:14:54 PM

  **Entered By:**          Stuart Mary W

  **Severity:**            Medium

  **Priority:**            Yes

  **Type:**                Suggestion

  **Closed On:**           9/24/2003 7:28:36 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           771

  **External               
  Reference:**             

  **Category:**            Views and View Versions

  **Component:**           SAFER and CVIEW

  **Synopsis:**            See SAFER CRs 660 and 661 and the attached spreadsheet for
                           background.\
                           \
                           Changes to SAFER/CVIEW views and versions were suggested
                           in CRs 660 and 661. I contacted the users. The following
                           changes are recommended:\
                           \
                           DELETE Full Carrier Q105 View version 2;\
                           KEEP Full Carrier view version 3 and 4.\
                           \
                           DELETE Carrier MCMIS Q102 view version 2.\
                           \
                           DELETE ROC Vehicle Q301 and all view versions;\
                           KEEP Full Vehicle Q303, View version 3 only.\
                           \
                           DELETE Q304 IRP with tag, all view versions;\
                           KEEP Q306 IRP no tag view version 3 only.

  **Status:**              Closed Fixed

  **Disposition:**         Closed per Robert Goldfarb \[2003-09-24\]

  **Description:**         \[2002-10-18 ncm\] Presented and discussed at ACCB meeting
                           10/17/02.\
                           \
                           Impacted Documents:\
                           1. Snapshot reports (Ron Glaser generates) after views
                           deleted\
                           2. Opcon Documentation (user manual? release notes?\_\
                           3. ROC documentation?\
                           \
                           \[2003-09-24 ncm per rhg\] Changes were implemented in
                           SAFER 4.1 and 4.2

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    SUbscriptionRegistrations.xls

  **Responsibility:**      Stuart Mary W

  **Modified Time:**       11/24/2003 6:55:41 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          10/2/2002 3:51:40 PM

  **Entered By:**          Stuart Mary W

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/24/2003 7:27:29 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           768

  **External               
  Reference:**             

  **Category:**            View for updating Transponder ID

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            SAFER v3.3 will support Transponder_ID updates from
                           Escreen View (Q305) only.\
                           \
                           The purpose of this CR is to document the following
                           behavior of SAFER v3.3 (and later versions).\
                           \
                           When SAFER v3.3 goes into production during October 2002,
                           vehicle Transponder IDs in SAFER will only be updated via
                           the Vehicle Escreen Enrollment update transaction (view
                           Q305).\
                           \
                           The Vehicle IRP Registration view (Q304) will no longer
                           include Transponder ID. If a Transponder ID is included in
                           a vehicle IRP registration update sent from CVIEW to SAFER
                           v3.3 (or later), SAFER will not update the value of
                           Transponder ID currently in its DB for that vehicle.\
                           \
                           Transponder IDs will only be included in subscriptions in
                           the vehicle Escreen view (Q305) and only for states
                           authorized to receive the Transponder ID for that vehicle.

  **Status:**              Closed Approved

  **Disposition:**         Closed per Robert Goldfarb. \[2003-09-24\]

  **Description:**         \[2002-10-18 ncm\] Presented and discussed at ACCB meeting
                           10/17/02. Because CR 1771 was approved, the last line of
                           the 4th paragraph and the 1st line of the 5th needed to be
                           removed in the synopsis. Robert Goldfarb took an action
                           item to send out a list of deleted views and the effective
                           dates via the general distribution list.\
                           \
                           \
                           Impacted Documents:\
                           1. Snapshot reports (Ron Glaser generates) after views
                           deleted\
                           2. Opcon Documentation (user manual? release notes?\_\
                           3. ROC documentation?

  **Fix:**                 no change required - purpose was to document use of Q305
                           view - per rhg

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Goldfarb Robert H

  **Modified Time:**       11/24/2003 6:56:00 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          10/2/2002 1:51:24 PM

  **Entered By:**          Goldfarb Robert H

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           9/24/2003 7:25:57 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           744

  **External               
  Reference:**             

  **Category:**            Delete SAFER snapshot field

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Delete HM_PASSENGER_SCORE from SAFER snapshot.\
                           The HM_PASSENGER_SCORE value is no longer calculated in
                           (New) MCMIS (per Mark Swope). It should be deleted from
                           SAFER snapshots since the current values in SAFERhave not
                           been updated since Sept 01 and are obsolete.

  **Status:**              Closed Fixed

  **Disposition:**         Closed per Robert Goldfarb. \[2003-09-24\]

  **Description:**         \[2002-10-18 ncm\] Presented and discussed at ACCB meeting
                           10/17/02.\
                           \
                           Impact Summary:\
                           \
                           1.SAFER View Summary Report (view_sum_report.doc)\
                           2.SAFER Snapshot Definition Report for Carrier Data\
                           (carrier_snapshot_def_report.doc)\
                           3.SAFER Snapshot Definition Report for Vehicle Data\
                           (vehicle_snapshot_def_report.doc)\
                           4.SAFER View Definition Report for Carrier Data\
                           (view_matrix_DOT30_car.doc)\
                           5.SAFER View Definition Report for Vehicle Data\
                           (view_matrix_DOT30_veh.doc)

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Goldfarb Robert H

  **Modified Time:**       11/24/2003 6:56:14 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/23/2002 3:31:16 PM

  **Entered By:**          Goldfarb Robert H

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           9/24/2003 7:24:35 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           732

  **External               VOLPE CR 15
  Reference:**             

  **Category:**            Requirement for OOS information for escreening

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Is there a requirement for carrier Out of Service
                           information at the roadside when screening vehicles ? If
                           so, which roadside applications require it, what frequency
                           should be provided, and in what form.

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2005-09-22 obr\] Closed out and incorporated into ARCH
                           CR 3115

  **Description:**         \[2002-10-18 ncm\] Presented and discussed at ACCB meeting
                           10/17/02. States agreed that carrier-level OOS data would
                           be useful at the roadside for screening and should be
                           included in SAFER snapshots. This feature will not be
                           included in SAFER 4.2, but will be added to the list for
                           future SAFER updates.\
                           \
                           \[2005-09-22 obr\] Closed out and incorporated into ARCH
                           CR 3115

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Goldfarb Robert H

  **Modified Time:**       9/23/2005 2:32:56 PM

  **Modified By:**         Roberts Onna Beth

  **Entered On:**          9/18/2002 8:29:29 AM

  **Entered By:**          Goldfarb Robert H

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           9/23/2005 2:32:56 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           731

  **External               
  Reference:**             

  **Category:**            Delete L&I snapshot view

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            It appears that Licensing and Insurance serves no role in
                           support of roadside screening. Consequently, the storage
                           of L&I data in the CVIEWs seems to be unnecessary. The
                           SAFER project requests termination of L&I CVIEW
                           subscriptions unless there is a business reason for this
                           information to be sent to the CVIEWs (could it possibly be
                           used by PRISM for carrier registration of vehicles ?) If
                           retention of L&I subscriptions is required, please provide
                           details of the business case for it.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2002-10-18 ncm\] Disapproved and closed.

  **Description:**         \[2002-10-18 ncm\] Presented and discussed at ACCB meeting
                           10/17/02. States agreed that L&I data is useful at the
                           roadside for screening, and the capability should be
                           retained in SAFER snapshots.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Goldfarb Robert H

  **Modified Time:**       10/21/2002 11:37:49 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          9/18/2002 8:26:32 AM

  **Entered By:**          Goldfarb Robert H

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           10/21/2002 11:37:49 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           708

  **External               
  Reference:**             

  **Category:**            MCMIS quarterly updates

  **Component:**           SAFER

  **Synopsis:**            We need a better mechanism for transfering the data from a
                           MCMIS quarterly update to the states. The SAFER data
                           mailbox system was not designed to handle this kind of
                           volume of data and the CVIEWs have a hard time keeping up
                           with the processing as well. One option would be to
                           provide the data as an Oracle dump via an ftp site at
                           Volpe. Other options include providing an AFF, or (later)
                           an XML file on the ftp site.

  **Status:**              Closed Approved

  **Disposition:**         \[2003-02-06\] Closed - no longer applicable.

  **Description:**         \[NCM 2002-09-24\] Presented and discussed at ACCB meeting
                           9/19/2002. One of the changes in new MCMIS is the move to
                           more frequent SAFESTAT updates. After October 2002,
                           updates may occur monthly. As noted in the CR synopsis,
                           even the quarterly updates present processing problems for
                           SAFER and for States\' CVIEWs. Field Systems is
                           investigating a solution in which only \"significant\"
                           changes will cause update records to be generated. An
                           example of a \"significant\" change is a carrier moving
                           into category A or B.\
                           \
                           \[NCM 2003-02-06\] Closed - no longer applicable.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Stuart Mary W

  **Modified Time:**       8/23/2004 12:00:29 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          9/6/2002 5:21:59 PM

  **Entered By:**          Stuart Mary W

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           2/6/2003 2:06:51 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           704

  **External               http://www.jhuapl.edu/cvisn/ Documents, White papers
  Reference:**             

  **Category:**            Update to Primary Identifiers White Paper

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The Recommendations for Primary Identifiers White Paper
                           should be updated to incorporate the following changes:\
                           \
                           1) Clarify that the Transponder Serial Number and the
                           Manufacturer Identifier are hexadecimal values.\
                           \
                           2) Update the Primary Carrier ID to delete the ID Type.
                           The ID Type applies to the EDI interface and does not
                           apply to the XML interface and so is not really part of
                           the identifier itself.\
                           \
                           3) Update the Primary Carrier ID to delete the terminal
                           ID, because States do not use it; it will not be in the
                           XML interface (CR 87)\
                           \
                           4) Update the Primary Carrier ID to delete the State
                           Code.\
                           \
                           5) Update the section on International Carriers to state
                           that each Mexican carrier that operates in the US is
                           required to have a USDOT #.\
                           \
                           6) Update the Recommended Implementation Approach section
                           to state that SAFER/CVIEW do not support the State
                           Specific Carrier ID.\
                           \
                           7) Update the section on International Vehicles to reflect
                           that Ontario is a member of IRP.\
                           \
                           8) Add note to section on Impact on Information Systems
                           for vehicle identifiers regarding future modification to
                           SAFER to link IFTA accounts to vehicles through the VIN.\
                           \
                           9) Add note to section on Transponder Identifiers
                           regarding potential future use of transponders for
                           container security.\
                           \
                           10) Update section on Impact on Information Systems for
                           Shipment Identifiers to state that \"motor carriers that
                           transport hazardous material must incorporate the Shipment
                           Unique ID and data structures for HazMat shipments into
                           their legacy systems.\
                           \
                           11) Various editing changes to improve readability in
                           tables.\
                           \
                           12) Update frequently used slide Figure A Primary
                           Identifiers - CVISN Level 1\
                           \
                           13) Incorporate recommendations of SAFE Data Architecture.
                           Specifically, add CVO Company Type to the Primary Carrier
                           ID.\
                           \
                           14) Update Driver Identifier to include the potential for
                           biometric identification.\
                           \
                           15) Update the information in the Vehicle Identifier
                           section regarding Mexico and the IRP.\
                           \
                           16) Update the information in the Trip Identifier section
                           regarding ITDS and ACE.\
                           \
                           17) Change \"MCMIS\" to \"New MCMIS\".

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         This CR incorporates CR 87.\
                           \
                           CVISN Architecture documentation should be updated to
                           include the impact of changing the identifers white paper\
                           \
                           \[NCM 2002-09-24\]: Presented and discussed at ACCB
                           meeting 9/19/2002. Item number 4 will be corrected to
                           indicate that the State code is not part of the Primary
                           Carrier ID. There was clarification on item number 6. The
                           State Specific Carrier ID is not a key field by which the
                           carrier can be searched/selected. It is not populated by
                           SAFER, but it could be by a State\'s CVIEW.\
                           \
                           \[SBS 2002-1022\]: Additional changes made (items 12-
                           17).\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description\
                           Primary Identifiers White Paper\
                           SCOPE Part 3\
                           Primary Identifiers FUS

  **Fix:**                 Published (or finalized):\
                           Primary Identifiers White Paper - published and delivered
                           via PL-02-0471, 2002-11-14\
                           FUS - Primary Identifiers - updated in FUS directory
                           2002-11-15\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           Changes pending in following documents:\
                           SCOPE Part 3 - not being maintained\
                           \
                           \
                           Corrections made in following documents:

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:56:53 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          9/5/2002 1:11:54 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:09:36 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           688

  **External               
  Reference:**             

  **Category:**            Changes to EDI State-SAFER interface in SAFER 4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The following changes will occur to the EDI interface for
                           exchanging data between States and SAFER, as a result of
                           deploying SAFER 4.2.\
                           \
                           1. IFTA\
                           - The CVIEW 3.3 IFTA view requires an IFTA account to be
                           associated with a carrier by providing a USDOT Number.
                           Only one such association can be maintained. SAFER 4.2
                           does not require such an association, and, more than one
                           IFTA account may be associated with a particular carrier.
                           SAFER v4.2 will send, in the CVIEW 3.3 format, one and
                           only one IFTA license record (where one exists) in each
                           carrier snapshot.\
                           \
                           2. IRP\
                           - The CVIEW 3.3 IRP account view requires an IRP account
                           to be associated with a carrier by providing a USDOT
                           Number. Only one such association can be maintained. SAFER
                           4.2 does not require such an association, and, more than
                           one IRP account may be associated with a particular
                           carrier. SAFER v4.2 will send, in the CVIEW 3.3 format,
                           one and only one IRP account record (where one exists) in
                           each carrier snapshot.\
                           \
                           - The IRP account \"check flag\" is obsolete and shall be
                           replaced by a more comprehensive IRP status. The IRP
                           vehicle \"check flag\" is obsolete and shall be replaced
                           by a more comprehensive IRP vehicle status.\
                           \
                           3. Electronic Screening\
                           \
                           - While CVIEW 3.3 transactions recording each individual
                           jurisdiction\'s acceptance of a carrier or vehicle will
                           still be accepted by SAFER 4.2, only the base state\'s
                           acceptance at the carrier level shall be recorded.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         CVISN Architecture documentation should be updated to
                           include the impact of SAFER 4.2 changes on EDI
                           transactions.\
                           \
                           \[NCM 2002-09-24\] Presented at ACCB meeting 9/19/2002. No
                           discussion.\
                           \
                           \[NCM 2003-02-10\] Description text modified per RHG.\
                           \
                           \[2003-02-25 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:57:03 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2002 10:41:35 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:09:05 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           687

  **External               
  Reference:**             

  **Category:**            Changes to SAFER to State trans. for E-Screening in SAFER
                           4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The following requirements apply to the XML/FTP interface
                           for SAFER to send escreening data to States in SAFER 4.2:\
                           \
                           4. Electronic Screening Transactions\
                           \
                           - The Transponder Id Transaction is supported. Refer to CR
                           683.\
                           - The transponder id is sensitive information. It shall
                           only be sent to jurisdictions authorized by the carrier to
                           receive it.\
                           - A carrier authorizes a jurisdiction to receive his
                           vehicle\'s transponder ids through the Carrier
                           Authorization transaction. - The transponder id may be
                           sent to a jurisdiction if it has been authorized by any of
                           a vehicle\'s registrant or safety carriers.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         CVISN Architecture documentation should be updated to
                           include support of XML/FTP interface for SAFER to send
                           carrier and vehicle data to States. Refer to the SAFER 4.2
                           Interface Control Document (ICD) to be released in
                           September 2002 for details.\
                           \
                           \[NCM 2002-09-24\] Presented at ACCB meeting 9/19/2002. No
                           discussion.\
                           \
                           \[2003-02-20 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:57:12 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2002 10:35:57 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:08:37 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           686

  **External               
  Reference:**             

  **Category:**            Changes to SAFER to State trans. for IRP in SAFER 4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The following requirements apply to the XML/FTP interface
                           for SAFER to send IRP data to States in SAFER 4.2:\
                           \
                           3. IRP Transactions\
                           \
                           These are the same as the input IRP Transactions, with the
                           additional notes below. See CR 682.\
                           \
                           The IRP Registration transaction shall consist of VIN,
                           registration, and proration information structured within
                           a file as follows:\
                           \
                           Interface Header + IRP-Reg Transaction Header + {
                           IRP-VIN + IRP-Reg + {IRP-Proration} }\
                           \
                           - Since a vehicle can be registered simultaneously in more
                           than one jurisdiction, several records with the same VIN
                           and different license plates may exist in any particular
                           file. However, only one license plate from any one
                           jurisdiction may exist at a single time.\
                           - It is recommended that the client\'s data store allow
                           multiple IRP-Reg records to be stored per vehicle. If the
                           license plate from a particular state already exists for a
                           particular vehicle, the IRP-Reg and IRP-Proration
                           information should be considered to be an update to that
                           information and should not affect registrations from other
                           states. If a license plate does not exist for the state,
                           the IRP-Reg and IRP-Proration information should be
                           inserted into the data store without affecting any other
                           registrations for the same vehicle.\
                           \
                           IRP REG\
                           - This transaction can hold either interstate or
                           intrastate information. The information in this
                           transaction is designed for use with IRP, that is
                           interstate, registrations. If used for intrastate
                           registrations, the intrastate information used should be
                           equivalent to the IRP information, but no checks or
                           validations will be performed to ensure that this is the
                           case. It is recommended that client systems do not retain
                           intrastate vehicles from other jurisdictions in their data
                           store.\
                           - The base jurisdiction licensed gross vehicle weight and
                           expiration date is redundant with the proration
                           information. If this information exists in the record,
                           then one of the associated proration records will have the
                           same values for the base jurisdiction.\
                           \
                           IRP PRORATION\
                           - In the associated proration records, at least one
                           proration, for the base state, shall be provided. In the
                           case of an intrastate vehicle, one and only one proration,
                           for the base state, shall be provided.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         CVISN Architecture documentation should be updated to
                           include support of XML/FTP interface for States to send
                           IRP data to SAFER. Refer to the SAFER 4.2 Interface
                           Control Document (ICD) to be released in September 2002
                           for details.\
                           \
                           \[NCM 2002-09-24\] Presented and discussed at ACCB meeting
                           on 9/19/2002. It was clarified that the USDOT number will
                           be optional for IRP and IFTA transactions using the XML
                           interface.\
                           \
                           \[SBS 2002-10-09\] The capability for handling multiple
                           names and multiple addresses has been included in the
                           SAFER 4.2 ICD.\
                           \
                           \[NCM 2003-01-20\] CR 79 closed out because it is
                           incorporated within this CR.\
                           \
                           \[2003-02-25 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:57:22 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2002 10:33:15 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:08:19 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           685

  **External               
  Reference:**             

  **Category:**            Changes to SAFER to State trans. for IFTA in SAFER 4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The following requirements apply to the XML/FTP interface
                           for SAFER to send IFTA vehicle data to States in SAFER
                           4.2:\
                           \
                           2. IFTA Transaction\
                           \
                           This is the same as the input IFTA Transaction. See CR
                           681.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         CVISN Architecture documentation should be updated to
                           include support of XML/FTP interface for SAFER to send
                           carrier and vehicle data to States. Refer to the SAFER 4.2
                           Interface Control Document (ICD) to be released in
                           September 2002 for details.\
                           \
                           \[NCM 2002-09-24\] Presented at ACCB meeting 9/19/2002. No
                           discussion.\
                           \
                           \[SBS 2002-10-09\] The capability for handling multiple
                           names and multiple addresses has been included in the
                           SAFER 4.2 ICD.\
                           \
                           \[2003-02-25 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:57:32 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2002 10:29:11 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:07:55 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           684

  **External               
  Reference:**             

  **Category:**            Changes to SAFER to State trans. for MCMIS and L&I in
                           SAFER 4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The following requirements apply to the XML/FTP interface
                           for SAFER to send carrier and vehicle data to States in
                           SAFER 4.2:\
                           \
                           There will not be a concept of \"full carrier\" or \"full
                           vehicle\" snapshot for XML transactions. Instead, there
                           will be multiple transactions. These are:\
                           \
                           Carrier Safety and Credential Transactions\
                           IFTA Transaction\
                           IRP Transactions\
                           Electronic Screening Transactions\
                           \
                           1. Carrier Safety and Credential Transactions\
                           This category consists of two transaction types.\
                           - The MCMIS Census and Safety transaction shall consist of
                           the information defined in interface I-011, SAFER-MCMIS
                           Update, of POR-99-7129, V1.0, Safety and Fitness
                           Electronic Records (SAFER) System Interface Control
                           Document, dated May 2001. Several minor changes, including
                           the MCS 150 date, requested by FMCSA since the interface
                           was defined will be incorporated.\
                           \
                           - The Licensing and Insurance (L&I) transaction shall
                           consist of the information defined in interface I-012,
                           SAFER-L&I Update, of the SAFER System Interface Control
                           Document, POR-99-7129, Baseline V1.0, June 2001. Several
                           minor changes requested by FMCSA since the interface was
                           defined (principally to support NAFTA) will be
                           incorporated.\
                           \
                           CRs 685-687 will address IFTA, IRP, and escreening SAFER
                           to State transactions.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         CVISN Architecture documentation should be updated to
                           include support of XML/FTP interface for SAFER to send
                           carrier and vehicle data to States. Refer to the SAFER 4.2
                           Interface Control Document (ICD) to be released in
                           September 2002 for details.\
                           \
                           \[NCM 2002-09-24\] Presented and discussed at ACCB meeting
                           9/19/2002. It was clarified that inspection reports
                           transactions will not be implemented in the XML interface
                           for SAFER 4.2. If States would like this as a future
                           capability, please submit a CR. A CR will be submitted by
                           Wisconsin for a future version of SAFER to handle permit
                           transactions in the XML interface. Prototype fields exist
                           in the EDI interface, but it has never been used.\
                           \
                           \[SBS 2002-10-10\] Vehicle inspection report summaries
                           will be available as Output XML transactions in SAFER 4.2.
                           Refer to CR 785\
                           \
                           \[2003-02-25 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:57:44 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2002 10:27:51 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:07:28 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           683

  **External               
  Reference:**             

  **Category:**            Changes to E-Screening transactions in SAFER 4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The following requirements apply to the XML/FTP interface
                           for States to exchange E-Screening data with SAFER 4.2:\
                           \
                           The system shall support two transactions related to
                           electronic screening (e-screening) enrollment, one that
                           establishes the jurisdictions which are authorized by the
                           carrier to receive transponder ids, and one to establish
                           the transponder id for a particular vehicle.\
                           \
                           1. Carrier Authorization\
                           - The carrier designated by the USDOT Number is the
                           \"e-screening\" carrier. The e-screening carrier
                           authorizes SAFER to send his vehicle\'s transponder ids to
                           the given jurisdiction. A vehicle\'s transponder id may be
                           sent to the given jurisdiction if its registrant or safety
                           carrier is the e-screening carrier.\
                           - The authorizations in the transaction shall completely
                           replace any existing authorizations previously established
                           for that carrier.\
                           - The jurisdiction sending the transaction shall be
                           considered the \"base jurisdiction\" for e-screening
                           authorization. The base jurisdiction\'s authorization
                           shall include the jurisdiction action and jurisdiction
                           action date. In all other records the actions and dates
                           shall be left NULL. At least one authorization, that for
                           the \"base jurisdiction,\" shall be provided.\
                           - The base jurisdiction should only send authorizations to
                           SAFER when and if it approves of the carrier\'s
                           participation in its e-screening program. If it does not
                           approve it should not enroll the carrier.\
                           \
                           2. Transponder ID\
                           - SAFER shall store no more than one transponder id for a
                           particular vehicle.\
                           - The transponder id will replace any previously
                           established transponder id for a given VIN.\
                           - The VIN is mandatory\
                           - The Transponder Id may be NULL to indicate that a
                           transponder is no longer associated with a particular
                           vehicle.\
                           - The transponder id is sensitive information. It shall
                           only be sent to jurisdictions authorized by the carrier to
                           receive it.\
                           - A carrier authorizes a jurisdiction to receive his
                           vehicle\'s transponder ids through the Carrier
                           Authorization transaction. - The transponder id may be
                           sent to a jurisdiction if it has been authorized by any of
                           a vehicle\'s registrant or safety carriers.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         This CR incorporates CR 213.\
                           \
                           CVISN Architecture documentation should be updated to
                           include support of XML/FTP interface for States to send
                           electronic screening enrollment data to SAFER. Refer to
                           the SAFER 4.2 Interface Control Document (ICD) to be
                           released in September 2002 for details.\
                           \
                           \[NCM 2002-09-24\] Presented and discussed at ACCB meeting
                           9/19/2002. In discussion about supporting only one
                           transponder ID, it was noted that because PrePass doesn\'t
                           provide account numbers to SAFER at this time there is no
                           need for more than one transponder ID in SAFER 4.2. States
                           may submit CRs for future SAFER 4.3.\
                           \
                           \[2003-02-25 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:57:53 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2002 10:03:15 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:07:11 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           682

  **External               
  Reference:**             

  **Category:**            Changes to IRP transactions in SAFER 4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The following requirements apply to the XML/FTP interface
                           for States to exchange IRP data with SAFER 4.2:\
                           \
                           SAFER shall support three types of transactions (snapshot
                           views) related to IRP: IRP Account, IRP Fleet and IRP
                           Registration.\
                           \
                           1. IRP Account\
                           - A particular Jurisdiction (State / Province) may
                           associate no more than one carrier (USDOT Number) to an
                           IRP account. Since it is possible that two or more
                           separate jurisdictions may be maintaining separate IRP
                           accounts for the same carrier, the same USDOT Number may
                           exist for more than one IRP account.\
                           - SAFER shall store no more than two names for a
                           particular IRP account. The name in the transaction shall
                           completely replace any existing name previously
                           established for a given account.\
                           - SAFER shall store no more than two addresses for each
                           name. The address in the transaction shall completely
                           replace any existing address previously established for
                           the name.\
                           - The IRP Account transaction may be combined with the IRP
                           Fleet transaction\
                           \
                           2. IRP Fleet\
                           - Many fleets may exist for a particular IRP account
                           number. Only one account may exist for a particular
                           fleet.\
                           - SAFER shall store no more than two names for a
                           particular IRP Fleet. The name in the transaction shall
                           completely replace any exiting name previously established
                           for a given fleet.\
                           - SAFER shall store no more than two addresses for each
                           name. The address in the transaction shall completely
                           replace any existing address previously established for
                           the name.\
                           \
                           3. IRP Registration\
                           - In the transaction, there must be one and only one
                           registration per VIN (i.e. per vehicle), but in SAFER
                           there may be more than one registration per VIN since a
                           vehicle can be registered simultaneously in more than one
                           jurisdiction.\
                           - The vehicle\'s transponder id shall not appear in this
                           transaction. The transponder id shall only be available
                           through the electronic screening enrollment transaction.\
                           - This transaction can hold either interstate or
                           intrastate information; there will be a field that
                           indicates interstate or intrastate. The information in
                           this transaction is primarily designed for use with IRP,
                           that is, interstate registrations. If used for intrastate
                           registrations, the intrastate information used must be
                           analogous to the IRP information. In the case of
                           intrastate vehicles, one and only one proration record,
                           for the base jurisdiction, will exist.\
                           - The base jurisdiction licensed gross vehicle weight and
                           expiration date is redundant with the proration
                           information. If this information exists, then one of the
                           associated proration records will have the same values for
                           the base jurisdiction.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         CVISN Architecture documentation should be updated to
                           include support of XML/FTP interface for States to send
                           IRP data to SAFER. Refer to the SAFER 4.2 Interface
                           Control Document (ICD) to be released in September 2002
                           for details.\
                           \
                           \[NCM 2002-09-24\] Presented and discussed at ACCB meeting
                           9/19/2002. It is still being considered whether multiple
                           names and addresses for IFTA accounts will be implemented
                           in SAFER 4.2. This capability will only be implemented if
                           it does not impact the schedule.\
                           \
                           \[SBS 2002-10-09\] The capability for handling multiple
                           names and multiple addresses has been included in the
                           SAFER 4.2 ICD.\
                           \
                           \[NCM 2003-02-06\] The text in the synopsis was updated
                           per RHG.\
                           \
                           \[2003-02-25 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:58:02 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2002 9:42:10 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:06:49 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           681

  **External               
  Reference:**             

  **Category:**            Changes to IFTA transactions in SAFER 4.2

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The following requirements apply to the XML/FTP interface
                           for States to exchange IFTA data with SAFER 4.2:\
                           - A particular Jurisdiction (State / Province) may
                           establish no more than one carrier (USDOT Number) for an
                           IFTA account. Since it is possible that two or more
                           separate jurisdictions may be maintaining separate IFTA
                           accounts for the same carrier, the same USDOT Number may
                           exist for more than one IFTA account.\
                           - SAFER shall store no more than two names for a
                           particular IFTA account. The name in the transaction shall
                           completely replace any existing name previously
                           established for a given account.\
                           - SAFER shall store no more than two addresses for each
                           name. The address in the transaction shall completely
                           replace any existing address previously established for a
                           given name.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         CVISN Architecture documentation should be updated to
                           include support of XML/FTP interface for States to send
                           IFTA data to SAFER. Refer to the SAFER 4.2 Interface
                           Control Document (ICD) to be released in September 2002
                           for details.\
                           \
                           \[NCM 2002-09-24\] Presented and discussed at ACCB meeting
                           9/19/2002. No changes to CR, but it was noted that some
                           States track IFTA accounts by FEIN and may have to change
                           their business process to link to the USDOT number. It is
                           still being considered whether multiple names and
                           addresses for IFTA accounts will be implemented in SAFER
                           4.2. This capability will only be implemented if it does
                           not impact the schedule.\
                           \
                           \[SBS 2002-10-09\] The capability for handling multiple
                           names and multiple addresses has been included in the
                           SAFER 4.2 ICD.\
                           \
                           \[NCM 2003-02-06\] The text in the synopsis was updated
                           per RHG.\
                           \
                           \[2003-02-25 ncm\] Presented at ACCB meeting 2/20/2003.\
                           \
                           Documents affected:\
                           \
                           COACH Part 4\
                           CVISN System Design Description

  **Fix:**                 COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:58:11 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          8/23/2002 9:38:49 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:06:24 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           654

  **External               Mike Miller
  Reference:**             

  **Category:**            

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            National ITS Architecture 4.0 shows no standard for \"tax
                           filing\"

  **Status:**              Closed Approved

  **Disposition:**         Closed following publication of document

  **Description:**         In the National ITS Architecture Version 4.0, the
                           architecture flow named \"tax filing\" is not mapped to
                           any standard. EDI TS 813, Electronic Filing of Tax Return
                           Data is available to carry fuel tax return information and
                           should be shown.\
                           \
                           We are using this mechanism to track this discrepancy. We
                           will discuss the issue with our technical contact on the
                           National ITS Architecture team (Mike Miller (703-367-5015
                           or michael.e.miller@lmco.com).\
                           \
                           This CR should remain open until a resolution has been
                           implemented either in the CVISN Architecture or in the
                           National ITS Architecture.\
                           \
                           \[2002-10-18 ncm\] Presented at ACCB meeting 10/17/02.\
                           \
                           \[2002-10-22 ncm\] Below is from a 10/22/02 e-mail from
                           Mike Miller (see Attachments\]\
                           Val and Nancy,\
                           Here\'s the latest. We requested that JPL put this
                           standard on their list so we could map it to the
                           architecture. As of now, JPL doesn\'t plan on adding it
                           because it\'s not one of the ITS standards being funded by
                           the JPO (I guess that is the criteria for inclusion). I
                           explained the situation to the Architecture team\'s
                           standards people and they recognize it would be beneficial
                           to include this standard. They fear that if they map one
                           standard not tracked by JPL, do they open up pandora\'s
                           box regarding other stakeholder areas wanting their
                           standards mapped to the architecture.\
                           \
                           The architecture team may develop criteria for including
                           standards not tracked by JPL. This would give us some
                           latitude to include additional standards, like EDI TS-813.
                           I\'ll let you know when this issue has been resolved.\
                           Michael E. Miller\
                           \
                           \[2003-10-17 ncm\] Presented at 10/16/03 ACCB meeting.\
                           \
                           \[2003-03-04\] Updated explanation included in document:\
                           National ITS Architecture 4.0 showed no standard for \"tax
                           filing\"\
                           In the National ITS Architecture Version 4.0, the
                           architecture flow named \"tax filing\" was not mapped to
                           any standard. EDI TS 813, Electronic Filing of Tax Return
                           Data, is available to carry fuel tax return information
                           and should be shown. In Version 5.0 of the National ITS
                           Architecture, \"tax filing\" is mapped to EDI TS 813, so
                           Table 1 in the CVISN Architecture has been updated.\
                           \
                           \
                           IMPACT SUMMARY \--\
                           ACCB Items\
                           1. CVISN Architecture Flow Diagram\
                           2. CVISN Architecture document

  **Fix:**                 CVISN Architecture: published and delivered via PL-04-0133
                           (POR-02-7364), 1 April 2004.

  **Comment:**             

  **Attachment names:**    Mike Miller 2002-10-22.txt

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       4/5/2004 3:42:55 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          7/25/2002 2:35:34 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            Low

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           4/5/2004 3:42:55 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           607

  **External               
  Reference:**             

  **Category:**            Remove WWW, EDI, DSRC interfaces diagram; improve CVIEW
                           descript

  **Component:**           CVISN System Design Description

  **Synopsis:**            Remove the diagram showing the WWW, EDI, and DSRC
                           standards interfaces between CVISN Architecture subsystems
                           from the CVISN System Design Description. Add a more
                           complete description of the functions of a state CVIEW.

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Description:\
                           The following changes are proposed for the CVISN System
                           Design Description:\
                           \
                           1) Remove the diagram showing the WWW, EDI, and DSRC
                           standards interfaces in the CVISN Architecture (slide 1 in
                           the attachment). These three standards types are only a
                           subset of those in use, and standards continue to change
                           more quickly than the document is updated.\
                           \
                           2) Add a description of CVIEW to complement the diagram
                           shown in slide 2 of the attachment (\"The State CVIEW
                           handles the exchange of safety and credentials information
                           within the state, and with other jurisdictions via SAFER).
                           The proposed text is shown in slide 3 of the attachment.\
                           \
                           \
                           \[2003-01-17 ncm\] Presented at ACCB meeting 1/16/2003.

  **Fix:**                 CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    CR 607 example slides.ppt

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 6:58:22 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/20/2002 2:18:28 PM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           5/23/2003 3:01:57 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           604

  **External               CR 0312
  Reference:**             

  **Category:**            Add Clearinghouse Connections to SAFER

  **Component:**           Interfaces

  **Synopsis:**            In the generic state CVISN System Design, the IRP and IFTA
                           Clearinghouses connect only to the state IRP and IFTA
                           products. Snapshot segments related to IRP and IFTA data
                           are made by the state CVIEW based on inputs from the state
                           IRP and IFTA products (or some other product, such as the
                           Credentialing Interface).\
                           \
                           We expect that some states will join the Clearinghouses
                           before they implement other aspects of CVISN Level 1. The
                           IRP and IFTA information needed for the snapshot segment
                           updates is already part of the dataset that the
                           Clearinghouses receive from the member states. So that the
                           IRP and IFTA segments of snapshots from Clearinghouse
                           member states without a CVIEW can be made available as
                           quickly as possible, the proposed change establishes a
                           connection between the IRP Clearinghouse and SAFER, and
                           between the IFTA Clearinghouse and SAFER. The current
                           scenarios for states with a CVIEW remain in effect; that
                           is, states with a CVIEW may choose to provide IRP and IFTA
                           snapshot segment updates to SAFER from their IRP and IFTA
                           products through CVIEW. (VBB 10/6/1998)

  **Status:**              Closed Disapproved

  **Disposition:**         Closed - disapproved. 11/27/2000 No states are currently
                           supporting or requesting this approach. APL will update
                           documents to remove the proposed links. The CRF will
                           remain open until the documents have been updated.

  **Description:**         The proposed change impacts the IRP Clearinghouse, IFTA
                           Clearinghouse, and SAFER. At the request of a state, the
                           clearinghouse will send TS 285 segments to SAFER
                           comparable to the segments that state would normally
                           submit. SAFER will respond with 997 and 824. The
                           clearinghouse will acknowledge the 824 with a 997. The
                           attached figures illustrate the flow.\
                           \
                           Impacts:\
                           ACCB configuration identification - CVISN System Design
                           Description, COACH\
                           \
                           SAFER configuration items - ??\
                           \
                           Clearinghouse configuration items - ??\
                           \
                           Other: Training materials for Introduction to ITS/CVO and
                           Understanding ITS/CVO Technology Applications courses;
                           Guides; Workshop materials; Introduction to CVISN; other
                           places where the affected slides are used\
                           \
                           Note: States will choose one method for updating IRP
                           snapshot segments, and one method for updating IFTA
                           snapshot segments. The snapshot segments can either be
                           provided by CVIEW to SAFER, or by the appropriate
                           Clearinghouse to SAFER.\
                           \
                           Estimated Cost:\
                           ACCB changes are within existing budgets.\
                           SAFER changes are scheduled and budgeted ??\
                           Some funding exists for making these IRP Clearinghouse
                           changes.\
                           IFTA Clearinghouse changes are not planned; the concept is
                           being evaluated.

  **Fix:**                 No states are currently supporting or requesting this
                           approach. APL will update documents to remove the proposed
                           links. The CRF will remain open until the documents have
                           been updated.\
                           \
                           COACH Parts 1, 3, 4, System Design Description, Guide to
                           Credentials Administration have been updated. COACH Part 5
                           has been updated(MWS July 2001).\
                           \
                           Documents updated:\
                           Guide to Safety Information Exchange: published and
                           delivered via PL-02-0088 (POR-99-7191), 13 Jun 2002\
                           System Design Description: published and delivered via
                           PL-03-0123 (POR-97-6998), 20 May 2003.\
                           Guide to Credentials Administration (changes made;
                           publication pending)\
                           COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           COACH Part 5: published and delivered via PL-01-0444
                           (POR-98-7126), 21 Sep 2001

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:58:43 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          6/18/2002 2:11:19 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:04:55 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           439

  **External               http://itsarch.iteris.com/itsarch/
  Reference:**             

  **Category:**            

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Discrepancy between CVISN and V4 Nat\'l ITS Architectures

  **Status:**              Closed Approved

  **Disposition:**         Closed following publication of document.

  **Description:**         The National ITS Architecture recently released Version 4.
                           The interfaces between subsystems have been redefined
                           (e.g., Wireline, DSRC, Wide Area Wireless). In most cases,
                           these changes were judged to have no effect on the intent
                           of the CVISN Architecture and were implemented into CVISN
                           documents.\
                           \
                           There are 3 request/response pairs that do not fall into
                           this category. In each of these pairs, the possibility of
                           a DSRC connection between FMS and CVS Aggregate was
                           dropped by the National ITS Architecture. The DSRC
                           connections will be retained in the CVISN Architecture,
                           but it is advisable to discuss the problem with the
                           National ITS Architecture team.\
                           \
                           The 3 data flow pairs are:\
                           on-board safety request/on-board safety data\
                           trip log request/trip log\
                           on-board vehicle request/on-board vehicle data\
                           \
                           \[2003-10-17 ncm\] Presented at 10/16/03 ACCB meeting.\
                           \
                           \[2004-03-04\] Updated explanation per VBB:\
                           Discrepancy between CVISN and V4 National ITS
                           Architecture\
                           In the following request/response pairs, the National ITS
                           Architecture dropped the possibility of a DSRC connection
                           between FMS and CVSAg in ITS Architecture Version 4.0. In
                           Baseline V1.0 of the CVISN Architecture document, the DSRC
                           connection option was retained. This was shown as \"X?\"
                           in the Std column of Table 1 for these flows:\
                           -+ on-board safety request/on-board safety data\
                           -+ trip log request/trip log\
                           -+ on-board vehicle request/on-board vehicle data\
                           In Version 5.0 of the National ITS Architecture, the
                           discrepancy was eliminated. Allowance was made for future
                           standardization of the \"trip log request\", \"trip log\",
                           \"on-board vehicle request\", and \"on-board vehicle
                           data\" flows. The flow \"trip identification number\" was
                           also added to the set that may be transmitted via either
                           DSRC or wide area wireless, with an option for future
                           standardization. Figure 2-1 and Table 1 of the CVISN
                           Architecture Baseline Version 2.0 document have been
                           updated to align with Version 5.0 of the National ITS
                           Architecture.\
                           \
                           \
                           ACCB Impact:\
                           1. CVISN Architecture Flow Diagram\
                           2. CVISN Architecture document

  **Fix:**                 CVISN Architecture: published and delivered via PL-04-0133
                           (POR-02-7364), 1 April 2004.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       4/5/2004 3:42:16 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          4/19/2002 9:54:29 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           4/5/2004 3:42:16 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           358

  **External               http://itsarch.iteris.com/itsarch/
  Reference:**             

  **Category:**            Update documentation reflecting V4 of Nat\'l ITS
                           Architecture

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The National ITS Architecture team is releasing Version 4.
                           There have been some changes to definitions and diagrams
                           that are not related to our alignment efforts and have no
                           effect on the intent of our documents.\
                           \
                           The types of changes involved include:\
                           \* Definition wording\
                           \* Redefinition of line connectors\
                           \* Applicable standards\
                           \
                           To stay current, these changes will be implemented in
                           CVISN documents during the regular publication process.

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         IMPACT SUMMARY \--\
                           ACCB Items \--\
                           CVISN Architecture Flow Diagram\
                           CVISN System Design Description\
                           CVISN Architecture document\
                           \
                           Other Items \--\
                           Scope part 3\
                           \
                           Frequently Used Slides \--\
                           Natl ITS Arch Sausage w CVO highlights.ppt\
                           CVISN architecture connects subsystems.ppt\
                           CVISN architecture - equipment packages.ppt

  **Fix:**                 IMPACT SUMMARY \--\
                           ACCB Items \--\
                           CVISN Architecture Flow Diagram - done 20020618 ncm\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           CVISN Architecture document - published and delivered via
                           PL-02-0307 (POR-02-7364), 22 Aug 2002\
                           \
                           Other Items \--\
                           Scope, part 3 - required changes noted in README, not
                           maintained \[20020618 ncm\]\
                           \
                           Frequently Used Slides \--\
                           Natl ITS Arch Sausage w CVO highlights.ppt - updated
                           3/15/02 NCM - done\
                           CVISN architecture connects subsystems.ppt\
                           CVISN architecture - equipment packages.ppt - updated
                           20020618 ncm - done

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/23/2003 7:31:36 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          3/15/2002 9:39:11 AM

  **Entered By:**          Magnusson Nancy C

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           9/23/2003 7:31:36 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           291

  **External               
  Reference:**             

  **Category:**            What is States\' Preferred Data Format for SAFER
                           interface?

  **Component:**           CVISN Architecture

  **Synopsis:**            The CVISN architecture should reflect the States\'
                           preferred data exchange format for the State - SAFER
                           carrier and vehicle snapshot data interface, whether that
                           be flat file or XML.

  **Status:**              Closed Approved

  **Disposition:**         FMCSA approved - closed

  **Description:**         While both flat file and XML State - SAFER interfaces will
                           be specified in the SAFER Interface Control Document
                           (ICD), which will be available in September, 2002, only
                           one interface type can be implemented in the timeframe
                           needed to support states deploying CVISN Level 1 by
                           September 30, 2003. It is important that all States,
                           particularly those committed to achieving CVISN Level 1 by
                           September 30, 2003, weigh in on which data format they
                           would prefer (or whether they intend to use EDI). FMCSA
                           will then decide which format shall be implemented to
                           support deployment by 9/30/03.\
                           \
                           Some notes from stakeholders:\
                           \
                           The CSI CVIEW currently supports EDI. Both CA and MN will
                           use EDI. WI has purchased the CSI source code and is
                           modifying it. CSI is currently in discussion with a number
                           of other States. CSI is committed to supporting whichever
                           interface SAFER implements. CSI has also been approached
                           by WA to provide support for States using xCVIEW and by
                           APL to provide support to States using the FMCSA CVIEW.\
                           \
                           ID and SD have signed agreements with WA to for xCVIEW. UT
                           and AZ are currently using data from WA. A number of other
                           states, including LA, NM, OK, and OR have expressed
                           interest in xCVIEW. WA prefers an XML interface with
                           SAFER.\
                           \
                           MT and other states may use PreView. The ACS proposal to
                           MT states that \"Although ASCII and XML are the preferred
                           data interchange formats, VISTA/CA - PreView can also
                           accept and send data in ANSI X.12 transaction set
                           formats.\"\
                           \
                           NCM 2002-04-05: Presented at ACCB 4/4/2002\
                           NCM 2002-04-05: Recommended for FMCSA approval by ACCB
                           4/4/2002\
                           NCM 2003-02-06: FMCSA approved - closed

  **Fix:**                 SBS 2002-03-29: As of 3/29/2002, States have voted 17-3
                           XML vs. flat file, with 6 states indicating preference to
                           use EDI for 9/2003 deployment.\
                           \
                           This information will be passed to the SAFER development
                           team so that the XML interface from State systems to SAFER
                           will be given priority over the flat file interface.

  **Comment:**             

  **Attachment names:**    Level1Matrix_VotesonDataFormat.xls\
                           States Comments on Question.doc

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       2/6/2003 2:21:37 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          2/21/2002 6:03:24 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           2/6/2003 2:21:37 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           215

  **External               
  Reference:**             

  **Category:**            SAFER

  **Component:**           CVISN Architecture

  **Synopsis:**            Allow All States to Have All Transponder ID\'s

  **Status:**              Closed Disapproved

  **Disposition:**         \[20020821\] Disapproved and closed.

  **Description:**         In order to simplify SAFER processing, it is desired to
                           create one and only one subscription file per view, which
                           will be accessible by any authorized user via FTP. Since
                           the CVISN architecture allows carriers to designate a
                           specific list of jurisdictions to which transponder id\'s
                           may be sent and does not allow them to be sent to any
                           other jurisdiction, such access cannot be granted for a
                           file that contains all the currently registered
                           transponder id\'s.\
                           \
                           We would like to change this policy so that a carrier may
                           choose to send transponder id\'s to the central location,
                           but not to designate individual recipients after doing so.
                           In this way a SINGLE file containing transponder id\'s can
                           be created, rather than multiple custom-tailored files for
                           each recipient.\
                           \
                           SAFER will provide only a single file over the FTP server
                           for all users of a particular subscription, rather than a
                           seperate file created for each recipient specifically.
                           Such a file would either have to contain all of the
                           transponder id\'s avaiable or none. Putting them all in
                           would mean violating the current CVISN transponder id
                           privacy model, so transponder ids would not be put into
                           the file at all. While this privacy model is in effect,
                           the states that will exercise the \"SAFER Option,\" which
                           will be using the file, won\'t be able to obtain
                           transponder ids from SAFER. A state that wants transponder
                           ids would have to use the current SMTP / POP3 approach,
                           since it currently supports the privacy model.\
                           \
                           SBS 2002-02-21: As FMCSA stated in the CVISN Level 1
                           Checklist: \"The CVISN architecture does not address
                           issues involving business interoperability.\" The SAFER
                           software should not force any particular business model
                           \"to simplify SAFER processing\".

  **Fix:**                 \[20020821\] This is not in the SAFER 4.2 requirements.
                           Disapproved and closed.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       8/23/2004 11:45:42 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          2/4/2002 2:15:48 PM

  **Entered By:**          Mick Alan A.

  **Severity:**            High

  **Priority:**            Yes

  **Type:**                Suggestion

  **Closed On:**           8/21/2002 11:18:36 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           213

  **External               Safer Options Working Group
  Reference:**             

  **Category:**            Transponder Registration

  **Component:**           SAFER

  **Synopsis:**            Allow Multiple Transponder ID\'s per Vehicle

  **Status:**              Closed Disapproved

  **Disposition:**         Closed - FMCSA disapproved.

  **Description:**         As a practical matter, the SOWG would like to be able to
                           associate more than one transponder id to a vehicle, since
                           this is actually the way trucks are operated today.
                           However, the SAFER database only allows one transponder id
                           per vehicle. This is consistent with the CVISN
                           architecture, since standards to allow one transponder to
                           perform multiple functions are being promulgated by it.\
                           \
                           The question of multiple transponders per vehicle in the
                           SAFER database should be discussed by the CVISN
                           architecture group and a recommendation made.\
                           \
                           NCM 2002-04-05: Presented and discussed at ACCB meeting
                           4/4/2002. This CR addresses the possibility of two CVO
                           transponders in a truck; toll transponder data would not
                           be passed in SAFER snapshots. PrePass is not enrolling
                           their transponders in CVISN. The meeting participants
                           could not think of a scenario in which a carrier would be
                           enrolling two escreening transponders for the same truck.
                           However, such a situation may be known to other States who
                           did not participate in this call, so an action item was
                           taken to send an email to the ACCB membership. States will
                           be requested to respond by April 19, 2002 as to whether
                           they see the need for multiple transponder ids in the
                           SAFER database and snapshots and, if they do see the need,
                           to describe the scenario.\
                           \
                           \[2003-02-06 ncm\] FMCSA disapproved.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    States Responses to CR 213.doc\
                           State response summary.xls

  **Responsibility:**      Mick Alan A.

  **Modified Time:**       2/6/2003 2:05:26 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          2/1/2002 11:26:55 AM

  **Entered By:**          Mick Alan A.

  **Severity:**            Medium

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           2/6/2003 2:05:26 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           182

  **External               
  Reference:**             

  **Category:**            Update documentation to reflect CVISN Level 1 Checklist

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            On August 8, 2001, at a working meeting with FMCSA and
                           APL, FMCSA proposed changes to COACH Part 1 that resulted
                           in nine ACCB Change Requests. One CR addresses various
                           document-formatting concerns. The other eight CRs address
                           changes to the State System Checklists in Chapter 4 of
                           COACH Part 1. The new CVISN Level 1 Checklist incorporates
                           all eight of the technical CRs, as well as many of the
                           formatting changes addressed in the ninth CR.\
                           \
                           This CR requests that COACH Part 1 and other CVISN
                           documents be updated to reflect the CVISN Level 1
                           Checklist. The original set of nine CRs will be closed
                           with references to the new CR.

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         The CRs that are incorporated into this CR are (old system
                           number in parentheses): 84 (1786), 90 (1832), 91 (1833),
                           92 (1834), 93 (1835), 94 (1836), 95 (1837), 96 (1838), and
                           97 (1839).\
                           \
                           \[2003-02-06 ncm per sbs\] The Level 1 Checklist will be
                           added as an Appendix to the COACH Part 1.\
                           \
                           ACCB Documents Affected:\
                           COACH, Part1, Chapter 4 State System Checklists\
                           CVISN System Design Description\
                           COACH Part 3\
                           COACH Part 4\
                           Other Documents Affected:\
                           Scope Workshop - not maintained

  **Fix:**                 ACCB Documents Affected:\
                           COACH, Part1, Chapter 4 State System Checklists -
                           published and delivered via PL-03-0143, (POR-97-7067), 8
                           August 2003.\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.\
                           COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 6:59:07 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          1/21/2002 2:35:05 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:03:55 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           158

  **External               KY Wray Williams
  Reference:**             

  **Category:**            \"Baseline\" SAFER snapshot

  **Component:**           SAFER

  **Synopsis:**            KY would like a capability to obtain SAFER snapshot data
                           for a specific time interval or for the entire SAFER
                           database.For example, KY would like the capability to
                           obtain all of the Motor Carrier insurance data from the
                           SAFER data base to bring the KY CVIEW up to date. A
                           request might be a set up as a special selection of SAFER
                           data that would result in creating the same type of
                           transactions a subscription would create. This request
                           might be used to bring a CVIEW up to date as well as to
                           recreate a set of subscription transactions for a time
                           period where there might have been a local CVIEW problem.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2003-10-17\] Disapproved

  **Description:**         Salazar: Suggest that this be added to SAFER version 4
                           requirements.\
                           \
                           Two options are requested:\
                           \
                           1. The ability to go \"back in time\" and catch up (assume
                           this\
                           would be based on a time stamp).\
                           2. The ability to deliver an update to a customer. If, for
                           example, a state\
                           had system problems last period, the state could request a
                           \"two period\"\
                           update. The state should still be able to get that via
                           e-mail. But another media (FTP, etc.)\
                           would be an acceptable option.\
                           \
                           The attachments to this CR contain more detailed
                           suggestions from MI, MN, and APL on options for addressing
                           this requirement.\
                           \
                           \[2003-10-17 ncm\] Discussed at ACCB meeting 2003-10-16.
                           The affected (EDI) states will implement work-arounds for
                           baseline snapshots. The three EDI states and six of the
                           seven XML states that responded to the email query
                           indicated that time-interval snapshots were not needed.

  **Fix:**                 Responses were requested by January 31, 2002. Michigan and
                           CSI, representing several states including MN, replied
                           that this capability is required.

  **Comment:**             

  **Attachment names:**    ACCB CR 158 - Baseline SAFER Snapshot.htm\
                           RE ACCB CR 158 - Baseline SAFER Snapshot.htm\
                           RE ACCB CR 158 - Baseline SAFER Snapshot_Giuffre.txt\
                           RE ACCB CR 158 - Baseline SAFER Snapshot_Giuffre_01.txt\
                           RE ACCB CR 158 - Baseline SAFER Snapshot_Walton.txt

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       10/17/2003 11:18:31 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          1/9/2002 3:21:15 PM

  **Entered By:**          Salazar Sandra B

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           10/17/2003 11:18:31 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           103

  **External               CR 2031
  Reference:**             

  **Category:**            Align with National ITS Arch Maintenance & Construction
                           Ops

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Version 4.0 of the National ITS Architecture will support
                           a new Maintenance and Construction Operations (MCO) User
                           Service. As a result of the analysis associated with
                           adding the new service, two changes to the segments of the
                           architecture that are aligned with the CVISN architecture
                           are recommended:\
                           \
                           1. Add a new Architecture Flow that makes \"asset
                           restriction\" information available to the Commercial
                           Vehicle Administration Subsystem:\
                           \
                           (new) Maintenance and Construction Management Subsystem
                           =\> current asset restrictions =\> (existing) Commercial
                           Vehicle Administration Subsystem\
                           \
                           Proposed flow definition for \"current asset
                           restrictions\" - Restrictions levied on transportation
                           asset usage based on infrastructure design, surveys,
                           tests, or analyses. This includes standard facility design
                           height, width, and weight restrictions, special
                           restrictions such as spring weight restrictions, and
                           temporary facility restrictions that are imposed during
                           maintenance and construction.\
                           \
                           2. Replace an Architecture Flow to make a richer set of
                           information available to the fleet and freight management
                           subsystem including road weather information and work zone
                           information:\
                           Before: Information Service Provider (ISP) =\> traffic
                           advisories =\> Fleet and Freight Management Subsystem
                           (FMS)\
                           After: ISP =\> road network conditions =\> FMS\
                           \
                           Definition for \"road network conditions\" - Current and
                           forecasted traffic information, road and weather
                           conditions, incident information, road restrictions, and
                           pricing data. Either raw data, processed data, or some
                           combination of both may be provided by this architecture
                           flow.\
                           \
                           Note: \"road network conditions\" is an existing
                           architecture flow that is used on several different
                           interfaces in the draft V4.0 architecture (e.g., Traffic
                           Management Subsystem=\>road network conditions=\>ISP).
                           This flow includes a broad set of highway-travel related
                           information, which is very close to what we want to make
                           available to FMS. It might be even better to choose a
                           different flow name to reflect the fact that the ISP might
                           do some processing/tailoring on the information that it
                           makes available to the FMS (e.g., \"traveler information
                           for fleet management\" or similar. Send your suggestions.\
                           \
                           Submitted by Val Barnes 11/21/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         The proposed changes are recommended for approval. The new
                           MCMS-to-CVAS current asset restrictions architecture flow
                           will provide for improved support of permitting operations
                           based on current roadway restrictions. The replacement
                           architecture flow, road network conditions, from
                           ISP-to-FMS is a richer set of data reflecting the sort of
                           information that FMS users need. Even if the data are
                           tailored for FMS use, the proposed road network conditions
                           flow should be sufficient.\
                           \
                           During the discussions about these proposed changes, we
                           also raised the question of additional connections to the
                           Commercial Vehicle Check Subsystem (CVCS) to account for
                           changes in traffic management due to maintenance and
                           construction activities. The National ITS Architecture
                           team prefers to address that question in a subsequent
                           update, since the discussion should involve a broader
                           audience and the deadline for freezing changes for V4.0 is
                           drawing near.\
                           \
                           Impact Summary:\
                           ACCB Items \--\
                           CVISN Architecture Flow Diagram\
                           CVISN Architecture document\
                           (memo dated December 2001)\
                           CVISN System Design Description\
                           \
                           Other Items \--\
                           SCOPE workshop\
                           \
                           Frequently Used Slides \--\
                           CVISN Arch Flow.ppt\
                           CVISN Architecture - equipment packages.ppt\
                           CVISN Architecture connects subsystems.ppt\
                           Natl ITS Arch Sausage w CVO highlights.ppt\
                           \
                           Recommended for FMCSA approval, November 29, 2001.\
                           Approved by FMCSA 12/20/2001

  **Fix:**                 Impact Summary:\
                           ACCB Items \--\
                           CVISN Architecture Flow Diagram - published and delivered
                           via PL-02-0307 (POR-02-7364), 2002-0822\
                           CVISN Architecture document - published and delivered via
                           PL-02-0307 (POR-02-7364), 2002-0822\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           Other Items \--\
                           SCOPE workshop - pending\
                           Frequently Used Slides \--\
                           CVISN Arch Flow.ppt - done \[20020618 ncm\]\
                           CVISN Architecture - equipment packages.ppt - updated
                           20020618 ncm\
                           CVISN Architecture connects subsystems.ppt (see CR 607 -
                           20030108 ncm)\
                           Natl ITS Arch Sausage w CVO highlights.ppt - updated
                           3/15/02 NCM

  **Comment:**             

  **Attachment names:**    Maintenance and Construction and CVISNIBC.htm

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       9/23/2003 7:33:22 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:26:30 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           9/23/2003 7:33:22 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           102

  **External               CR 2014
  Reference:**             

  **Category:**            Are periodic subscriptions a required capability for
                           SAFER/CVISN

  **Component:**           SAFER

  **Synopsis:**            SAFER and CVIEW incorporate the capability to generate
                           subscriptions on a periodic basis (WEEKLY, MONTHLY,
                           QUARTERLY, YEARLY, etc.) This capability is not currently
                           used in either SAFER or in any FMCSA CVIEW.\
                           \
                           Are periodic subscriptions a required capability for SAFER
                           & CVIEW ?\
                           \
                           Submitted by: Robert Goldfarb 11/9/2001

  **Status:**              Closed Disapproved

  **Disposition:**         The CR is thereby disapproved and closed on February 1,
                           2002.

  **Description:**         Goldfarb 11/29/01 -\
                           \
                           Background:\
                           \
                           In Safer v3, subscription data is generated and sent to
                           the subscriber by safer/cview either:\
                           \
                           1 - at the time the system\'s db is updated (Update Time).
                           This is called an \"Immediate\" subscription. This is the
                           manner used for all Vehicle subscriptions.\
                           \
                           2 - at a 24 hour interval - but only if the system\'s db
                           had been updated within the last 24 hours. This is the
                           current mechanism used for carrier data. Currently,
                           carrier data is received and processed only once a week
                           (ie., from mcmis). Thus, all carrier subscription data is
                           generated at that interval (even though the software
                           checks every 24 hours to see if subscription data is
                           available ).\
                           \
                           The SAFER/CVIEW design allows for subscriptions to be
                           GENERATED at longer intervals so that users would not have
                           to connect and download their subscriptions as frequently
                           as the system\'s data base was being updated. Thus, for a
                           MONTHLY subscription, all data processed within the prior
                           month (regardless of the interval of the updates) would be
                           sent to the subscriber once a month in a single file. For
                           mcmis carrier data (for example) the user would download
                           one file each month - containing a full months worth of
                           data - rather than 4 files - each containing a week\'s
                           work of mcmis carrier data.\
                           \
                           As seen from the example, the PERIODIC subscription is not
                           necessary. It just simplifies the download process for
                           user\'s not wishing to connect at as frequent an interval.
                           For these users, timeliness is not critical. They might be
                           insurers or others interested in doing periodic research,
                           etc. Instead of having to download 4 files each month -
                           each having a week\'s carrier data (for example) - a
                           subscriber requesting a MONTHLY subscription would connect
                           once and download a single (larger) file containing the
                           entire months data.\
                           \
                           Analysis:\
                           \
                           CVIEW: Periodic subscriptions have not been tested and at
                           this time there are no plans for this capability to be in
                           \"production\" in FMCSA Cview v3.3\
                           \
                           SAFER: this capability could be incorporated at version 4
                           or later\
                           \
                           Presented at ACCB 11/29/2001\
                           Salazar sent email to states on 12/17/2001; mentioned on
                           state teleconferences 12/18/2001. Responses due 1/11/2002.

  **Fix:**                 States were asked to reply by January 11, 2002. MD, KY,
                           SC, SD, NV, and KS responded that they did not require
                           this capability. No states replied that they did need it.\
                           \
                           The CR is thereby disapproved and closed on February 1,
                           2002.

  **Comment:**             

  **Attachment names:**    CR 2014 email.doc\
                           Kansas RE Periodic Subscriptions.txt\
                           MD RE Periodic Subscriptions in SAFERCVIEW.txt\
                           Periodic Subscriptions in SAFERCVIEW.htm\
                           KY RE Periodic Subscriptions in SAFERCVIEW.txt

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       2/1/2002 2:21:07 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          12/17/2001 3:25:09 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           2/1/2002 2:21:07 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           101

  **External               CR 2000
  Reference:**             

  **Category:**            Update documents regarding TS 284 not supported in Fed
                           systems

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Related to CR 1849 which was disapproved on 10/25/01.
                           Instead of removing the TS 284 from the CVISN
                           architecture, keep it in the documentation but add a note
                           saying it is not supported by Federal Safety systems such
                           as SAFER and Safetynet. This CR calls for the update of
                           all the CVISN documents that contain references to TS
                           284.\
                           \
                           Submitted by Stuart 10/25/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         CVISN documents affected:\
                           \
                           CVISN Guide to Top Level Design\
                           CVISN System Design Description\
                           Introductory Guide to CVISN\
                           CVISN Guide to Safety Information Exchange\
                           Workshop materials\
                           Snapshot White Paper\
                           Test Suite Part 3\
                           COACH Part 4\
                           CVISN, National ITS Architecture, IBC Architecture
                           Alignment document\
                           (Look for others)\
                           \
                           Recommended for FMCSA approval, November 29, 2001.\
                           Approved by FMCSA 12/20/2001

  **Fix:**                 1-CVISN System Design Descrip: published and delivered via
                           PL-03-0123 (POR-97-6998), 20 May 2003.\
                           2-Snapshot White Paper: 12/01 - this document is not going
                           to be maintained.\
                           3-Architecture Alignment Document: published and delivered
                           via PL-01-0650 (POR-02-7349), 25 March 2002 (20020108
                           ncm)\
                           4-Guide to Safety Information Exchange: published and
                           delivered via PL-02-0088 (POR-99-7191), 13 June 2002
                           (20020617 ncm)\
                           5-COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           Other docs no longer maintained.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 6:59:35 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:23:58 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 1:03:01 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           100

  **External               CR 1984
  Reference:**             

  **Category:**            IBC/CVISN/National ITS Architecture alignment

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            In June 2001, The CVISN Architecture, the IBC architecture
                           and the National Architecture teams agreed to align the
                           three architectures. The alignment involved making the
                           terminators, subsystems and architecture flows
                           consistent.\
                           \
                           Submitted by: Clyde 10/18/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         Members of all three architecture teams have worked
                           together on the alignment process. A synopsis of the
                           changes proposed for the CVISN architecture follows:\
                           \
                           1. Added the Trade Regulatory agencies terminator.\
                           \
                           2. Added the Intermodel freight/shipper terminator.\
                           \
                           3. Revised definitions for Fleet and freight management
                           Subsystem and Other CVAS Terminator.\
                           \
                           4. Deleted the following flows:\
                           \
                           a. Customs & Immigr Info Request flow.\
                           \
                           b. Deleted Lock Message Set Flow\
                           \
                           c. Deleted CV Border Clearance Message Set Flow\
                           \
                           d. Deleted International Border crossing data\
                           \
                           5. Added the following flows:\
                           a. border agency clearance results\
                           b. border clearance status\
                           c. border clearance data\
                           d. border clearance data request\
                           e. border clearance event\
                           f. declaration information\
                           g. domestic transportation information\
                           h. electronic lock data\
                           i. electronic lock data request\
                           j. transportation border clearance assessment\
                           k. trip declaration identifiers\
                           l. trip identification number\
                           \
                           6. Modified the definition for safety status information\
                           \
                           \
                           The CVISN Architecture Flow diagram is a configuration
                           item under the ACCB. The arch alignment document produced
                           as part of CRF 1760 will be updated with the revised
                           information.\
                           \
                           Impact Summary:\
                           ACCB Items \--\
                           CVISN Architecture Flow Diagram\
                           The arch alignment document produced as part of CRF 1760
                           will be updated with the revised\
                           information.\
                           CVISN System Design Description\
                           \
                           Other Items \--\
                           SCOPE workshop\
                           \
                           Frequently Used Slides Affected:\
                           CVISN Arch Flow.ppt\
                           CVISN Architecture - equipment packages.ppt\
                           CVISN Architecture connects subsystems.ppt\
                           \
                           Recommended by ACCB 11/29/2001\
                           Approved by FMCSA 12/20/2001.

  **Fix:**                 Comments received during the review cycle were
                           incorporated into the document. The final document is
                           PL-01-0650/POR-02-7349.\
                           \
                           IMPACTED ITEMS:\
                           CVISN Architecture Flow Diagram - published and delivered
                           via PL-01-0650 (POR-02-7349),\
                           25 March 2002\
                           \"CVISN, IBC and National ITS Architecture Alignment\" -
                           published via PL-01-0650\
                           (POR-02-7349), 25 March 2002\
                           CVISN Arch Flow.ppt - updated\
                           CVISN Architecture - equipment packages.ppt - updated
                           3/14/02 ncm\
                           CVISN Architecture connects subsystems.ppt - updated
                           3/14/02 ncm\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           \
                           SCOPE workshop - no longer maintained

  **Comment:**             

  **Attachment names:**    CVISN Arch Flow R1.ppt

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 6:59:48 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:22:41 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 12:55:54 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------
  **CR Number:**           99

  **External               CR 1983
  Reference:**             

  **Category:**            Remove View Versions no longer used for SAFER/CVIEW/ROC

  **Component:**           Database

  **Synopsis:**            After talking with Ron Glaser and sending out a few emails, I would like to propose that we remove/delete the
                           following views/view versions from the database:\
                           Q103, view version 2, Carrier SAFEVUE\
                           Q103, view version 3, Carrier SAFEVUE\
                           Q103, view version 4, Carrier SAFEVUE\
                           Q105, view version 1, Full Carrier\
                           Q108, view version 2, Carrier ROC\
                           Q108, view version 3, Carrier ROC\
                           Q108, view version 4, Carrier ROC\
                           Q110, view version 4, Carrier ISS\
                           Q301, view version 2, Vehicle ROC\
                           Q301, view version 4, Vehicle ROC\
                           \
                           submitted by: Jim Polaha 10/18/2001

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         From DJ Waddell, Sent on Wed 10/31/2001 3:14 PM:\
                           After the proposed deletions, would ROC and CVIEW still be able to get the data they need in the formats they
                           expect? Would LSIs and CVIEW still be able to update snapshots appropriately?\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           Jim Polaha, Nov. 5, 2001:\
                           - All the views mentioned are OUTPUT only views, they are NOT Input or Update views.\
                           - Eric King verified that the views in question are not being used (no one has subscriptions for them) on VOLPE
                           SAFER.\
                           \
                           Q103, view version 2, Carrier SAFEVUE\
                           Q103, view version 3, Carrier SAFEVUE\
                           Q103, view version 4, Carrier SAFEVUE\
                           These are not used, and there are no SAFEVUEs in existence.\
                           \
                           Q105, view version 1, Full Carrier\
                           This view is not longer used/needed.\
                           \
                           Q108, view version 2, Carrier ROC\
                           Q108, view version 3, Carrier ROC\
                           Q108, view version 4, Carrier ROC\
                           The ROC does not use this view, it uses FULL CARRIER views.\
                           \
                           Q110, view version 4, Carrier ISS\
                           This view is no longer used/needed.\
                           \
                           Q301, view version 2, Vehicle ROC\
                           Q301, view version 4, Vehicle ROC\
                           These are not used by ROC Version 4 in the field.\
                           \
                           ROC Version 4 (4, 4.0, 4.1, whatever it will be called) does/will work with the views that will remain. ROC Version
                           4 does not need/use the views that are going to be deleted. I spoke with Eric and Wendy about this and they both
                           agreed.\
                           \
                           The remaining views that are \"ROC\" related are:\
                           Q105, View Version 2, Full Carrier - O\
                           Q105, View Version 3, Full Carrier - O\
                           Q105, View Version 4, Full Carrier - O\
                           Q301, View Version 3, Vehicle ROC - O\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           From an email from Eric to Sandy, Sent on Wed 11/7/2001 10:15 AM:\
                           OpCon:\
                           OpCon looks into the database to determine which views & versions are available for use. Deleting them from the
                           database will automatically remove them from OpCon.\
                           The OpCon.oce file, which contains the available \"event fields\", must be modified by removing the Carrier ROC
                           selection. This can be incorporated into the OpCon v3 release. Note that there is no SafeVUE selection - there never
                           was.\
                           \
                           SCAPI32:\
                           The code must be modified to disallow Carrier ROC transactions (such as queries) and Carrier SafeVUE transactions.\
                           The SCAPI32 documentation must be modified.\
                           \
                           In summary, relatively minor modifications must be made as indicated above. About 1 day of effort.\
                           \-\-\-\--\
                           From Eric King, 30 Nov 2001:\
                           The following should also be accomplished in concert with the aforementioned database data modifications:\
                           \
                           The SAFERViews.txt file should be similarly modified (by removing the SAFEVue references):\
                           : Q103 MC 2 SAFEVue view\
                           : Q103 MC 3 SAFEVue view\
                           etc.\
                           \
                           ACCB Documents Affected:\
                           Snapshot White Paper (SAFER View Summary Report)\
                           \
                           Recommended for FMCSA approval, November 29, 2001.\
                           Approved by FMCSA 12/20/2001

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 6:59:59 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:21:17 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           8/21/2002 10:47:10 AM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           98

  **External               CR 1842
  Reference:**             

  **Category:**            Update the State diagram in the CVISN System Design
                           Description

  **Component:**           CVISN System Design Description

  **Synopsis:**            Update the Interfaces Within the State diagram in the
                           CVISN System Design Description.\
                           \
                           Submitted by: Salazar 8/14/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         On the diagram in section 4 of the CVISN System Design
                           Description, \"In CVISN Level 1, Interfaces Within the
                           State support enhanced exchange of safety and IRP & IFTA
                           credentials information.\", add dashed lines indicating
                           custom interface agreements wherever there are EDI
                           interfaces. This is because states are not restricted to
                           using EDI for interfaces between systems within the state.
                           This change also affects workshop material.\
                           \
                           Impact Summary \[2003-02-03 ncm\]\
                           ACCB Items:\
                           System Design Description\
                           COACH 4\
                           \
                           Other Items:\
                           Workshop materials (no longer being maintained)\
                           \
                           Frequently Used Slides:\
                           Core Capabilities - within State.ppt

  **Fix:**                 CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           \
                           COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           Core Capabilities - within State.ppt - done

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 7:00:10 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:19:58 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 12:56:15 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           97

  **External               CR 1839
  Reference:**             

  **Category:**            Add use of credentials and safety data to e-screening
                           reqts.

  **Component:**           COACH Part 1, V2

  **Synopsis:**            The L1 requirements related to e-screening do not
                           explicitly include using credentials and safety data. It
                           is generally understood that e-screening should be based
                           on an evaluation of credentials and safety data, but the
                           criteria are not explicitly stated.\
                           \
                           Submitted by Jeff Secrist 8/8/2001.

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Update COACH Part 1, table 4.4-2, State Electronic
                           Screening Systems Design Requirements Checklist, item
                           4.4.4 by adding 2 new L1 sub-items:\
                           - Use safety data from snapshots and other sources\
                           - Use credentials data from snapshots and other sources\
                           \
                           ACCB Impacts:\
                           COACH Parts 1, 3

  **Fix:**                 COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:00:22 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:18:57 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/23/2003 7:12:19 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           96

  **External               CR 1838
  Reference:**             

  **Category:**            Remove item 4.4.3 re interoperability policies from table
                           4.4-2

  **Component:**           COACH Part 1, V2

  **Synopsis:**            COACH Part 1, table 4.4-2 State Electronic Screening
                           System Design Requirements, item 4.4.3 says to implement
                           interoperability policies as they are developed by a wide
                           variety of groups. Is this a necessary item in the table?\
                           \
                           Submitted by: Jeff Loftus 8/8/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         The referenced item was intended to remind states to keep
                           up with e-screening interoperability policies as they
                           evolve. Now the interoperability guiding principles
                           (included in chapter 2 of the COACH Part 1) capture most
                           of the agreed-to policy ideas. This item is no longer
                           useful in chapter 4 of the COACH Part 1 and should be
                           deleted.\
                           \
                           ACCB Impacts:\
                           COACH Parts 1, 3

  **Fix:**                 COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:00:31 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:18:00 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/23/2003 7:11:44 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           95

  **External               CR 1837
  Reference:**             

  **Category:**            Update DSRC \"sandwich\" spec guidance

  **Component:**           COACH Part 1, V2

  **Synopsis:**            The rulemaking for the DSRC \"sandwich\" specification is
                           taking longer than expected.\
                           \
                           Submitted by Val Barnes 8/8/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         The technical documents should be updated to reflect that
                           the sandwich specification is planned for future use as of
                           an unspecified date, and that current guidance for DSRC is
                           to use the existing technology.\
                           \
                           Documents affected:\
                           - COACH Part 1 - In section 4.4, the requirements related
                           to the DSRC equipment were updated to reflect the
                           uncertainty of action on the rulemaking for the sandwich
                           specification. The language was simplified and clarified.\
                           - COACH Part 3

  **Fix:**                 COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:00:46 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:17:01 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/23/2003 7:10:57 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           94

  **External               CR 1836
  Reference:**             

  **Category:**            Eliminate confusing \"L1;E\" Req Level in COACH Part 1

  **Component:**           COACH Part 1, V2

  **Synopsis:**            Showing L1 and E for some items in the COACH Part 1,
                           Chapter 4, State Systems Checklists, is confusing. Clarify
                           what is really a Level 1 item and what is an Enhanced
                           item.\
                           \
                           Submitted by Elyse Turkeltaub 8/8/2001.

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         The \"L1;E\" items are those related to credentialing
                           interfaces - Web-based (person-to-computer) or
                           computer-to-computer. The FMCSA policy states that States
                           should implement either a Web-based OR a
                           computer-to-computer interface as part of their Level 1
                           activities, and do the other implementation as an Enhanced
                           activity. The introductory paragraphs should explain that,
                           and the tables should show all such requirements as L1.\
                           \
                           ACCB Impacts:\
                           COACH Part 1\
                           COACH Part 3

  **Fix:**                 COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:00:55 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:15:59 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/23/2003 7:09:21 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           93

  **External               CR 1835
  Reference:**             

  **Category:**            Clarify COACH Part 1

  **Component:**           COACH Part 1, V2

  **Synopsis:**            Many items in the COACH Part 1 are not clear to new
                           readers and should be clarified.\
                           \
                           Submitted by: Elyse Turkeltaub 8/8/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Changes to the structure and wording are recommended to
                           simplify the text and increase readability.\
                           - Acronyms were expanded at first use;\
                           - Table titles are shown on each page of the table;\
                           - References to tables were made consistent\
                           - Appendices A and B were created for change management
                           tracking;\
                           - References to CRs applied to previous versions of this
                           document were removed from the text and tables;\
                           - Any comments in the Comments column of the tables were
                           moved into the Compatibility Criteria column; the Comments
                           column is now reserved for state use.\
                           \
                           ACCB Impacts:\
                           COACH Part 1\
                           COACH Part 3

  **Fix:**                 COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:01:02 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:14:57 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/23/2003 7:08:46 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           92

  **External               CR 1834
  Reference:**             

  **Category:**            Replace date columns in COACH Part 1 Ch 4 with
                           Verification col.

  **Component:**           COACH Part 1, V2

  **Synopsis:**            Op Test Date, IOC Date, and FOC Date columns in the COACH
                           Part 1, Chapter 4, State Systems Checklists are not used
                           and take up space. Replace with one column that explains
                           how each of the requirements in those checklists is
                           verified - through interoperability testing, less-formal
                           demonstration, or inspection.\
                           \
                           Submitted by: Elyse Turkeltaub 8/8/2001

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         The three date columns in chapter 4 of the COACH Part 1
                           were intended to be used for planning and tracking by the
                           owner of a particular copy of the COACH Part 1. In
                           practice, they are not used. Therefore, it would be more
                           useful to replace those columns with guidance about how
                           each design requirement should be verified.

  **Fix:**                 COACH, Part1 published and delivered via SSD/PL-003-0143
                           (POR-97-7067), 8 August 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:01:10 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:13:55 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 1:00:05 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           91

  **External               CR 1833
  Reference:**             

  **Category:**            Intrastate data exchange within state is Level 1

  **Component:**           COACH Part 1, V2

  **Synopsis:**            The definition of CVISN Level 1 is inconsistent about
                           whether intrastate data exchange within the state is part
                           of Level 1 or not. Intrastate data exchange within the
                           state should be part of CVISN Level 1.\
                           \
                           Submitted by Jeff Loftus 8/8/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Update the COACH Part 1, table 4.1-2, General State
                           Systems Design Requirements Checklist, item 4.1.5,
                           sub-items 3 and 4 from E to L1:\
                           4.1.5 Exchange safety and credentials data electronically
                           within the state to support credentialing, safety, and
                           other roadside functions. Where useful, exchange
                           snapshots.\
                           3 Data for intrastate carriers L1\
                           4 Data for intrastate vehicles L1\
                           \
                           Other ACCB impacts:\
                           Coach Part 3

  **Fix:**                 COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:01:19 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:12:51 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/23/2003 7:08:01 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           90

  **External               CR 1832
  Reference:**             

  **Category:**            Clarify Level 1 summary slide

  **Component:**           COACH Part 1, V2

  **Synopsis:**            The one-page viewgraph summary definition of CVISN Level 1
                           should be clarified to answer many frequently-asked
                           questions.\
                           \
                           Submitted by: Stuart 8/8/2001

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         The CVISN Level 1 summary viewgraph as well as the summary
                           table used in the CVISN documents should be clarified to
                           indicate ASPEN to SAFER data flow via direct and indirect
                           paths;use of SAFER option as alternative to CVIEW; use of
                           Web-based credential solutions; updating SAFER and CVIEW
                           with credential data; and use of snapshots in the
                           e-screening process.\
                           \
                           \
                           ACCB Documents Affected:\
                           COACH, Part1, Chapter 4 State System Checklists\
                           CVISN System Design Description\
                           Other Documents Affected:\
                           Scope Workshop\
                           E-screening Guide \[2003-01-08 ncm\]\
                           Frequently Used Slides:\
                           DSRC in Electronic Screening \[2003-01-08 ncm\]

  **Fix:**                 The new top level slide is found in
                           \\\\ssdapps2\\pvo\\Reference Communications\\Freq Used
                           Slides\\\_CONTROLLED Slides, filename \"Definition of
                           CVISN Level 1 Deployment.ppt\".\
                           The attachment to this CR contains both the original and
                           proposed new slide. The changes are highlighted in bold,
                           red, italic font in the proposed slide.\
                           \
                           ACCB Documents Affected:\
                           COACH, Part1, Chapter 4 State System Checklists -
                           published and delivered via SSD/PL-003-0143 (POR-97-7067),
                           8 August 2003.\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.\
                           \
                           Other Documents Affected:\
                           Scope Workshop - not maintained\
                           E-screening Guide - not maintained\
                           Frequently Used Slides:\
                           DSRC in Electronic Screening - done 2003-01-08

  **Comment:**             

  **Attachment names:**    Definition of CVISN Level 1 Deployment.ppt

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:01:28 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:11:34 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 12:58:52 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           89

  **External               CR 1829
  Reference:**             

  **Category:**            Make SNET 2K View \"Private\"

  **Component:**           SAFER

  **Synopsis:**            The definition of the carrier SNET view (Q101) is
                           currently included in CVISN documentation. This view is
                           used only by SAFER in communicating to SAFETYNET 2000. By
                           including it in the CVISN architecture definitions of
                           views, programs other than SAFETYNET 2000 might utilize
                           it. If so, when SAFETYNET requirements change, those
                           programs other than SNET 2K utilizing the view might
                           experience difficulties. For this reason, the view should
                           be removed from the generally available list or be clearly
                           marked \"for use by SNET 2K only.\"\
                           \
                           Submitted by: Mick 8/8/2001

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         Documentation on views will clearly state which views are
                           proprietary and who owns the view. In particular, the
                           SAFER View Summary Report (successor to the Snapshot White
                           Paper) will clearly indicate that Q101 is a proprietary
                           view owned by SAFETYNET 2000.\
                           \
                           If the view_description for Q101 is changed to \"Carrier
                           SNET (SNET Proprietary)\", it will appear in both OPCON
                           and the \"SAFER View Summary Report\".\
                           \
                           Documents affected:\
                           SAFER View Summary Report.\
                           \
                           Recommended by ACCB: 9/20/2001\
                           Approved by FMCSA 12/20/2001

  **Fix:**                 rcg - star date 20020123\
                           Added\" (SNet Proprietary)\" to view_description field for
                           the Q101 views.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:01:41 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:10:01 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           8/21/2002 10:45:00 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           88

  **External               CR 1828
  Reference:**             

  **Category:**            Miscellaneous View Changes to Correct Minor Problems

  **Component:**           SAFER

  **Synopsis:**            Field 62 (SHIPPER_INTERSTATE) was added to the Carrier
                           Snet view Q101 (v3 and v4) in the DOT30 database. See CRF
                           1815.\
                           \
                           Field 0 (VIN) has been made not updateable in the Vehicle
                           Insp view Q302 (v3 only). See CRF 1684.\
                           \
                           CRF 1821 requests adding field 17 (LICENSE_PLATE_STATE) to
                           the Vehicle Insp view Q302 (v2 and 3). These view versions
                           were created when the search key was
                           LICENSE_PLATE_NUMBER+IRP_BASE_STATE. The search key is now
                           LICENSE_PLATE_NUMBER+LICENSE_PLATE_STATE so the missing
                           field should be added.\
                           \
                           submitted by: Mick 8/8/2001

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         Shipper Interstate was added to correct a problem with the
                           field called \"Shipper Interstate HazMat.\" MCMIS is
                           populating Shipper Interstate, but not Shipper Interstate
                           HazMat.\
                           \
                           The VIN has been made \"not updatable\" to prevent the VIN
                           numbers in SAFER 2.0 from becoming corrupted by errant
                           inspection report data. Inspection report data generally
                           does not contain a full 17 character VIN. If the field is
                           updatable a vehicle established through an IRP update,
                           with a full 17 character VIN, will have the VIN set to an
                           incorrect value if the vehicle is inspected and the
                           inspector does not use the full 17 characters.\
                           \
                           The \"License Plate State\" is an artificial field created
                           to provide functionality requested by MD. It is not really
                           a field in the snapshot. It has to be included in the
                           internal definition of the snapshot to make sure the
                           functionality works correctly, but does not affect the
                           \"official\" definition of the snapshot, which does not
                           (and cannot) contain this field.\
                           \
                           Documents affected:\
                           SAFER View Summary Report.\
                           \
                           Recommended by ACCB: 9/20/2001\
                           Approved by FMCSA 12/20/2001

  **Fix:**                 These changes were accomplished under the CRF\'s indicated
                           in the request. Alan Mick 12/7/2001

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:01:52 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:08:54 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           8/21/2002 10:44:38 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           87

  **External               CR 1824
  Reference:**             

  **Category:**            Primary Carrier ID recommendation needs to be reviewed

  **Component:**           Documentation

  **Synopsis:**            The CVISN recommendation for Primary Carrier ID needs to
                           be reviewed and perhaps revised.\
                           \
                           Submitted by Salazar 8/2/2001

  **Status:**              Closed Is Duplicate

  **Disposition:**         Closed - This CR has been incorporated into CR 704. While
                           some States are using state specific carrier identifiers,
                           only one State has voiced a need at this time to have
                           SAFER support. States should be kept aware that if they do
                           have a need for SAFER to support state-specific carrier
                           identifiers, they must express this to FMCSA and the ACCB.
                           In future updates of architecture documentation, it should
                           be noted that this capability is not supported by SAFER.

  **Description:**         Several States were consulted regarding some of the
                           primary identifier issues, which include the need to carry
                           both USDOT number and state-specific identifier, need for
                           terminal ID component, need for issuing authority
                           component.\
                           \
                           An email message was sent to all CVISN deployment States
                           explaining the issues and requesting comments.\
                           \
                           During discussion of this CR at the ACCB meeting of August
                           9, 2001, several participating states expressed the need
                           for the capability to update and retrieve data from SAFER
                           by jurisdiction-specific Carrier ID. CR 1851 has been
                           submitted. During subsequent discussion at the ACCB
                           meeting of September 20, 2001 and the CVISN Program
                           Manager-s meeting on October 5, 2001, a few States voiced
                           a need for state-specific carrier ID within the state and
                           supported by the State-s CVIEW, but only one expressed a
                           need for SAFER support.\
                           \
                           At this time, no changes will be made to the Primary
                           Carrier ID recommendation. States will be informed at the
                           Workshops that if they do have a need for SAFER to support
                           state-specific carrier identifiers, they must express this
                           to FMCSA and the ACCB. In future updates of architecture
                           documentation, it should be noted that this capability is
                           not supported by SAFER.\
                           \
                           Documents affected:\
                           CVISN Recommendations for Primary Identifiers White Paper\
                           Snapshot White Paper\
                           COACH\
                           Workshop Materials\
                           \
                           Discussed at ACCB 9/20/2001

  **Fix:**                 This CR has been incorporated into CR 704.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:02:52 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 3:01:20 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/15/2002 3:16:23 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           86

  **External               CR 1809
  Reference:**             

  **Category:**            NAFTA Additions to SAFER Snapshot

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            FMCSA is identifying fields that need to be added to
                           MCMIS, SAFETYNET, SAFER website to support NAFTA. Need to
                           determine whether these changes impact CVISN architecture,
                           specifically the SAFER snapshots.

  **Status:**              Closed Fixed

  **Disposition:**         Closed by ACCB 4/4/2002.

  **Description:**         FYI - In our NAFTA discussions so far, we\'ve determined
                           that there are several\
                           pieces of information that will need to be added to our
                           Census:\
                           \
                           1. OP-1(MX) - Mexican carriers operating anywhere in U.S.\
                           versus\
                           OP-2 - Mexican carriers operating only in the U.S.
                           commercial zone\
                           \
                           2. MC or MX (for type of ICC number issued)\
                           \
                           3. Revocation Indicator and Date\
                           \
                           4. Tracking Number (for coordination between L&I and MCMIS
                           databases)\
                           \
                           (Phyllis/Vera - If you\'ve come up with a specs for these
                           new fields, would you\
                           respond to everyone on this message with those? Also, let
                           me know if I\'ve\
                           omitted anything.)\
                           \
                           We will need to coordinate on getting these new fields
                           into all the\
                           appropriate systems, which will likely include SAFETYNET,
                           SAFER snapshot, etc.\
                           I\'ll try to set up a meeting next week.\
                           \
                           Further Information from Pat, Sent 8/10/2001:\
                           \
                           Just a heads- up\...We\'ve finally narrowed down the list
                           of data items that\
                           will need to be added to the SAFER web site. In order to
                           make this as\
                           painless as possible to you, we\'ve decided to have the
                           data transfer come from\
                           the L&I database. We would just add the new items to the
                           existing records\
                           that L&I passes to you.\
                           \
                           Here\'s our initial list of items:\
                           \
                           Mexican carrier RFC identification number\
                           Canadian carrier identification number\
                           Revocation/ Suspension Indicator\
                           Revocation/Suspension Date\
                           \
                           We don\'t have the specifics on the lengths of these
                           fields, the values, etc.\
                           I\'ll get those to you as soon as they\'re defined.\
                           \
                           Submitted by Pat Savage 7/12/2001.\
                           \
                           This request has been placed in the NAFTA requirements
                           document and scheduled for implementation. Alan Mick: The
                           change has resulted in several SAFER CRF\'s, a
                           requirements document and has been scheduled. 12/10/01\
                           \
                           Analysis needs to be completed with final list of new
                           fields.\
                           \
                           Documents affected:\
                           SAFER View Summary Report\
                           \
                           Presented to ACCB\
                           \
                           NCM 2002-04-05: The changes have no impact on any of the
                           snapshot views. Modifications, however, were made to the
                           SAFER database. As a result, new fields will show up in
                           the SAFER/CVIEW 3.3 database and data dictionary.\
                           \
                           Closed by ACCB 4/4/2002.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       6/4/2002 2:35:40 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          12/17/2001 3:00:05 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           4/8/2002 6:28:46 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           85

  **External               CR 1794
  Reference:**             

  **Category:**            Add fields to vehicle inspection view.

  **Component:**           SAFER

  **Synopsis:**            Several states would like to have CVSA Expiration date and
                           state carrier ID in the vehicle inspection view. We
                           recommend that those two fields be added to the views in a
                           future version of SAFER. This corresponds to ACCB CR
                           1554.\
                           \
                           Submitted by Salazar to CVOSS CCB 6/21/2001

  **Status:**              Closed Disapproved

  **Disposition:**         This is actually the SAFER CR that is the equivalent of
                           ACCB CR 1554. Disapproved and closed by ACCB 4/4/2002.

  **Description:**         Due to requests from additional CVISN states for the CVSA
                           expiration date, we would like the priority to be changed
                           to \"H\" and would like this change to be considered for
                           SAFER 4.\
                           \
                           Information from Ron:\
                           \
                           The CVSA_EXPIRE_DATE and STATE_CARRIER_ID fields are NOT
                           in the vehicle_inspection table. Both of these fields are
                           in the vehicle_registration table. I think we talked about
                           moving the CVSA_EXPIRE_DATE(calculated field) to the
                           vehicle_inspection table but we never discussed moving the
                           STATE_CARRIER_ID. The DB3.0 design would not support a
                           view based on fields from two possibly unrelated tables
                           (vehicle_inspection and vehicle_registration). We would
                           have to add or move STATE_CARRIER_ID to
                           vehicle_inspection. How would we populate this field ?\
                           \
                           Information from Alan:\
                           \
                           We do not have a direct source for \"CVSA Expiration
                           date.\"\
                           In the inspection report, keyed by VIN / LICENSE PLATE /
                           STATE we have:\
                           \
                           CVSA_DECAL CHAR(1) (True/False)\
                           DECAL_NUMBER VARCHAR2(8)\
                           \
                           If the decal field is only filled in when the decal is
                           ISSUED, the expiration date can be ASSUMED to be the date
                           of the inspection report + 60 days. If this field is
                           filled in at any other time, this assumption does not
                           hold.\
                           \
                           The inspection view is a summary of all inspections for
                           vehicles with a particular license plate. Over time, more
                           than one vehicle can have the same license plate, and the
                           same vehicle can have different license plates. But the
                           decal is stuck to the truck. For this reason, the cert
                           flag and expiration date may not relate to the truck with
                           the license plate.\
                           \
                           According to Paul, SAFER can not further consider these
                           changes until further requirements analysis is done by the
                           CVISN Architecture CCB to clarify the source and means of
                           calculating the CVSA expiration date.\
                           \
                           State Carrier ID:\
                           \
                           The SAFER inspection view / table contains information
                           about the last OOS inspection received, the last
                           inspection received, OOS or not, and statistics about
                           inspections received. The fields for these two inspection
                           reports are:\
                           \
                           DATETIME\
                           LOCATION\
                           RPTNUM\
                           VIN\
                           \
                           The inspection report contains a single field for carrier
                           id and state carrier id, and multiple vehicles. An
                           INSPECTION_STATE_CARRIER_ID and an OOS_STATE_CARRIER_ID
                           could be added to the vehicle inspection table and set
                           using the STATE CARRIER ID for each vehicle contained in
                           the report. These two fields could then be put into the
                           inspection view.\
                           \
                           Since access to the vehicle inspection view is through the
                           registration information provided to SAFER, the USDOT
                           numbers and state id numbers recorded in the vehicle
                           inspection table may be different from the carrier ids
                           recorded in the registration for the license plate of the
                           vehicle.\
                           \
                           Before further consideration can be given to this request,
                           the ACCB should verify that these considerations are
                           acceptable to the states, or provide details to whatever
                           alternative they would like to consider.\
                           \
                           Analysis: 12/10/2001\
                           \
                           NCM 2002-04-08: It was agreed at the 4/4/2002 ACCB meeting
                           that vehicle.CVSA_EXPIRE_DATE and vehicle.CARRIER_STATE_ID
                           will not be requested for the Inspection View Q302. CR
                           disapproved and closed.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       1/8/2007 11:19:54 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          12/17/2001 2:58:53 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           1/8/2007 11:19:54 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           84

  **External               CR 1786
  Reference:**             

  **Category:**            Address CVIEW in COACH Part 1

  **Component:**           COACH Part 1

  **Synopsis:**            CVIEW should be mentioned in the appropriate operational
                           concepts and system requirements tables of COACH Part 1.\
                           \
                           Requested by Jeff Loftus 6/15/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Recommend adding a new item 4.2.9 to table 4.2-2 State
                           Safety Information Exchange and Safety Assurance Systems
                           Design Requirements Checklist in COACH Part 1 to address
                           the CVIEW requirement:\
                           Implement the CVIEW (or equivalent) system for exchange of
                           intrastate and interstate data within state and connection
                           to SAFER for exchange of interstate data through
                           snapshots - OR - utilize the SAFER option for exchange of
                           inter- and intrastate data through snapshots.\
                           \
                           ACCB Documents Affected:\
                           - COACH, Part 1\
                           - COACH, Part 3

  **Fix:**                 COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:03:12 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:57:38 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           10/23/2003 7:06:27 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           83

  **External               CR 1784
  Reference:**             

  **Category:**            Updates to snapshot whitepaper for SAFER/CVIEW version 2

  **Component:**           Snapshots

  **Synopsis:**            This CR documents updates to be included in the snapshot
                           whitepaper for SAFER/CVIEW version 2.\
                           \
                           Submitted by Clyde 6/14/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Combine all of the spreadsheets in appendices A & B into
                           whitepaper as word table\
                           Remove shading and multiple fonts\
                           Repeated key fields for some supporting tables\
                           For Appendix A:\
                           Rename column B from -SAFER Database Element- to -Database
                           Field Name-\
                           Rename column D from \"Added/Changed under CRF Number\" to
                           \"Applicable CR No.\"\
                           Delete column E (\"SAFER Support Revision\")\
                           Delete column F (\"Supported in EDI IG\") and\
                           Added column to show field type and length for SAFER
                           database\
                           For Appendix B:\
                           Rename column B from -SAFER Database Element- to -Database
                           Field Name-\
                           Rename \"Data Sources\" to \"Authoritative Sources\"\
                           Rename column K from \"Common Source\" to \"Source\"\
                           Rename column L from \"Common Source Availability\" to
                           \"Source Availability\" - use a \"C\" for current or a
                           \"F\" for future\
                           Rename column N from \"Common Source\" to \"Source\"\
                           Rename column O from \"Common Source Availability\" to
                           \"Source Availability\" - use a \"C\" for current or a
                           \"F\" for future\
                           Rename column S from \"Common Source\" to \"Source\"\
                           Rename column U from \"Common Source Availability\" to
                           \"Source Availability\" - use a \"C\" for current or a
                           \"F\" for future\
                           Delete column M (\"Data Source Issues\")\
                           Delete column P (\"Data Source Issues\")\
                           Delete column U (\"Data Source Issues\")\
                           Rename \"Maryland State\" to \"Maryland State (example)\"\
                           General changes\
                           Add words in white paper about SSN change in CRF 1059
                           (Appendix A Comment)\
                           Add L & I Fields from CRF 626 to white paper (appendix A &
                           B)\
                           Add fields from CRF 693 to white paper (Appendix A & B)\
                           Add words on not change and replace in safer(Text In
                           Whitepaper)\
                           Add words about keys for views (Text in Whitepaper)\
                           Updated appendix D to be consistent with paper itself\
                           Clear definition for IRP Check Flag (appendix A Comment)\
                           Define snapshot update views for credentials at carrier
                           level (Text in whitepaper and Appendix B)\
                           Add MCS 150 Mileage and Year to snapshot.(appendix A & B)\
                           Add L&I summary fields to carrier snapshot (Appendix A &
                           B)\
                           Rename IRP Check Flag (Appendix A )\
                           Added paragraphs on interface alternatives to EDI (Text in
                           Whitepaper)\
                           Added paragraphs about SOWG (text in whitepaper)\
                           Appendix A added comments on CVIS default carrier and ties
                           to PRISM (appendix A)\
                           Added updates to Comments on ISS2 values. (Appendix A)\
                           Added Inspection report retention being 60 days. (text in
                           whitepaper)\
                           \
                           Analysis: Clyde 6/14/2001\
                           Recommended by ACCB 6/21/2001

  **Fix:**                 Snapshot White Paper published and delivered via
                           PL-01-0258, 6 Aug 2001

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 7:03:23 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:56:04 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           12/19/2001 12:27:54 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           82

  **External               CR 1760
  Reference:**             

  **Category:**            Align CVISN and National ITS Architecture flows

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            In June 2000, the CVISN Architecture and National ITS
                           Architecture teams were directed to align the two
                           architectures. Equipment Packages and Subsystems were
                           already aligned, but the flows were not.\
                           \
                           Submited by Barnes 5/30/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         Members of the National ITS and CVISN Architecture teams
                           have worked together on the alignment process. A synopsis
                           of the changes proposed for the CVISN architecture
                           follows:\
                           \
                           1.The National ITS Architecture naming conventions were
                           adopted by CVISN for aligned flows (flow name initial caps
                           were changed to lower case). Flows that have not yet been
                           aligned, e.g., IBC flows, are shown as all caps to
                           differentiate them.\
                           \
                           2.The Cargo terminator was eliminated as part of the CVISN
                           architecture.\
                           \
                           3.The proposed CVISN Architecture Flow diagram (2001
                           Version) shows the Vehicle Subsystem aggregated with the
                           Commercial Vehicle Subsystem; this aggregation was not
                           explicitly shown in the original. Architecture flows that
                           were not unique to CVO were not represented in the
                           original CVISN architecture. For the alignment process,
                           basic vehicle functions were incorporated into the CV
                           realm.\
                           \
                           4.Many of the two-way flows (Message Sets and DSRC
                           request/response pairs) were eliminated and explicitly
                           split into their component unidirectional functions.\
                           \
                           5.The snapshot data flow \"CV Safety & Cred Info Exch\"
                           was split into separate safety and credential flows.\
                           \
                           6.Direct flows from a center to a human interface without
                           an intervening system at the driver-s location were
                           eliminated.\
                           \
                           7.The terminator label \"Law Enforcement Agency\" was
                           replaced by \"Enforcement Agency.\"\
                           \
                           8.When necessary for clarification and/or alignment, flow
                           names and definitions were modified.\
                           \
                           9.A few flows were added for alignment or because they
                           were missing from the original CVISN architecture.\
                           \
                           10.Some flows between humans and subsystems remain in the
                           National ITS Architecture but are not shown in the CVISN
                           Architecture because the human operator is considered to
                           be part of the subsystem in CVISN. This is an area where
                           we agreed to disagree.\
                           \
                           The attachment \-- CR_1760 \_Arch_Flow_Diagrams.ppt \--
                           includes the proposed and original CVISN architecture flow
                           diagrams. An additional file \-- ssdapps2\\pvo\\Config
                           Mgmt\\CRF Database\\CRFs\\Attachments\\CR_1760
                           \\CR_1760_Arch Alignment.doc \-- contains tables that
                           correlate new and old flow names. All flow names are
                           defined; explanations for flow deletions and additions are
                           also included. The CVISN Architecture Flow Diagram is a
                           configuration item under ACCB.\
                           \
                           ACCB Documents Affected:\
                           CVISN Architecture Flow Diagram\
                           CVISN System Design Description\
                           \
                           Other Documents Affected:\
                           SCOPE Workshop\
                           \
                           Frequently Used Slides Affected:\
                           CVISN Arch Flow.ppt\
                           CVISN Architecture - equipment packages.ppt\
                           CVISN Architecture connects subsystems.ppt\
                           \
                           Analysis: Barnes 5/30/2001\
                           Recommended by ACCB 6/21/2001\
                           Approved by FMCSA 7/3/2001

  **Fix:**                 Scope Workshop - published\
                           CVISN Architecture Flow Diagram - published and delivered
                           via PL-01-0358, 3 Aug 2001\
                           CVISN Arch Flow.ppt - updated\
                           CVISN Architecture - equipment packages.ppt - updated\
                           CVISN Architecture connects subsystems.ppt - updated\
                           CVISN System Design Description: published and delivered
                           via PL-03-0123 (POR-97-6998), 20 May 2003.

  **Comment:**             

  **Attachment names:**    CR_1760_Arch_Alignment.doc\
                           CR_1760_Arch_Flow_Diagrams.ppt

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:03:37 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:54:46 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           5/23/2003 2:55:26 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           81

  **External               CR 1743
  Reference:**             

  **Category:**            Remove Last Update Date from inspection view

  **Component:**           Snapshots

  **Synopsis:**            Remove Last Update Date from inspection view\
                           \
                           Submitted by Clyde 5/17/2001

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         This CRF replaces 1403. 1403 introduced the problem of
                           continuing to use last update date in certain
                           circumstances starting with SAFER/CVIEW version 3.0. To
                           support storage of data for PRISM, underlying changes to
                           the database structure have been made. These changes
                           result in the situation where last update date can\'t be
                           utilized by some authoritative sources. Since this is the
                           case, we recommend just removing it from the view so that
                           last_update_date can\'t be misinterpreted. It is not
                           essential for performing screening or an inspection.\
                           \
                           Documents affected:\
                           \"SAFER View Summary Report\"\
                           \
                           Analysis:\
                           Recommended by ACCB 5/17/2001\
                           Approved by FMCSA 12/20/2001

  **Fix:**                 rcg - 20020123\
                           Removed LAST_UPDATE_DATE from Q302 v4 (Vehicle
                           Inspection).

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:03:50 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:52:51 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           8/21/2002 10:45:16 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           80

  **External               CR 1738
  Reference:**             

  **Category:**            Non-populated data elements in the SAFER database

  **Component:**           SAFER

  **Synopsis:**            Alan Mick: 5/14/2001\
                           \
                           Non-populated data elements in the SAFER database should
                           be removed from the \"White Paper,\" the \"CVO
                           Vocabulary,\" and the SAFER database.

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         Discussed at ACCB meeting 5/17/2001

  **Fix:**                 Carrier non populated data fields have been eliminated
                           from the SAFER DB. No additional database cleanup is
                           planned.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:04:03 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:51:38 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 12:48:58 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           79

  **External               CR 1731
  Reference:**             

  **Category:**            Need fields to support intrastate registration

  **Component:**           CVIEW

  **Synopsis:**            There is a need for CVIEW to support intrastate
                           registration. Fields needed include:\
                           License Plate Number\
                           License Plate State\
                           License Plate Country\
                           \
                           Submitted by Salazar 5/9/2001\
                           \
                           A field called -LICENSE_PLATE_STATE- already exists in the
                           SAFER/CVIEW database, but it has other business rules
                           associated with it.\
                           \
                           There may also be a need to have a status flag associated
                           with intrastate registration.\
                           There may also be a need to have an -interstate or
                           intrastate- flag.

  **Status:**              Closed Is Duplicate

  **Disposition:**         \[2003-01-20 ncm\] Closed - covered by CR 686

  **Description:**         Related to SOWG requirements. See SAFER 4.2 requirements.\
                           \
                           \[2003-01-20 ncm\] Intrastate registration is covered by
                           CR 686.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       1/20/2003 8:57:02 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:50:40 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           1/20/2003 8:57:02 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           78

  **External               CR 1717
  Reference:**             

  **Category:**            Add OOS and Inspection VIN to Vehicle Inspection View

  **Component:**           Snapshots

  **Synopsis:**            Add OOS VIN and Inspection VIN to Inspection view for
                           release 3. Add to Q302 and Q303 for view version 4.\
                           \
                           Submitted by Mick 5/2/2001

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         From the minutes of the Deployment state teleconferences
                           on May 22, 2001: During the calls, Gary Steinmetz (MO)
                           said he felt a partial VIN field would not be useful, and
                           could be confusing. CT, MD, NV and NY felt the VIN
                           captured during inspection would be useful information.
                           This CR is associated with the CVOSS CR 1793.\
                           \
                           Documentation affected:\
                           \
                           SAFER View Summary Report\
                           \
                           Analysis:\
                           Recommended by ACCB: 6/21/2001\
                           Approved by FMCSA 12/20/2001

  **Fix:**                 rcg - 20011130\
                           Added the INSPECTION_VIN and OOS_VIN fields to Q302,v4
                           (Vehicle INSP) and Q303,v4 (Full Vehicle) views.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:04:15 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:49:35 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           8/21/2002 10:45:31 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           77

  **External               CR 1662
  Reference:**             

  **Category:**            SAFER now stores IRs for 60 days

  **Component:**           SAFER

  **Synopsis:**            SAFER has been changed to store inspection reports for 60
                           days rather than 45 days. Documents under configuration
                           control need to be changed to indicate this.\
                           \
                           Submitted by Salazar 4/6/2001.

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         ACCB Documents Affected:\
                           Snapshot White Paper\
                           COACH Part 1\
                           COACH Part 3\
                           COACH Part 5\
                           Other Documents Affected:\
                           CVISN Guide to Safety Information Exchange\
                           SCOPE Workshop - Session 5\
                           \
                           8/15/01 - removed System Design Description from affected
                           documents - the note that referenced this change was
                           removed. Ncm\
                           \
                           Recommended by ACCB 4/19/2001\
                           Approved by FMCSA 7/3/2001

  **Fix:**                 COACH Part 5 updated July 2001 (MWS). Published and
                           delivered via PL-01-0444 (POR-98-7126), 21 Sep 2001\
                           Snapshot White Paper - published and delivered via
                           PL-01-0258, 6 Aug 2001\
                           Scope Workshop - published Oct 2001\
                           CVISN Guide to Safety Information Exchange - published and
                           delivered via PL-02-0088 (POR-99-7191), 13 Jun 2002\
                           COACH Part 1 V3.0: published and delivered via PL-03-0143
                           (POR-97-7067), 8 August 2003.\
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 7:04:25 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:48:14 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/23/2003 7:03:50 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           76

  **External               CR 1590
  Reference:**             

  **Category:**            Increase field lengths for Unit Number and Address

  **Component:**           CVIEW

  **Synopsis:**            Increase the data length allowed for vehicle Unit Number
                           and street address fields so that snapshots are not
                           rejected by CVIEW/SAFER. KY IRP sends 6 digit vehicle Unit
                           Numbers and street address fields of 40 characters. These
                           snapshots are rejected by CVIEW which only allows 5 digits
                           for Unit Number and 30 for street address. Data fields
                           should not be so restrictive.\
                           \
                           Submitted: Stuart 3/13/2001

  **Status:**              Closed Fixed

  **Disposition:**         Closed

  **Description:**         Unit number: This is a motor carrier assigned ID number.
                           KY allows 8 characters to provide room for fleet
                           designations. MD allows 9 characters because VISTA allows
                           9 in the IRP registration process. I have seen example cab
                           cards from MD with 6 characters. WA also allows 9
                           characters. WA says the transponder administrators use the
                           unit number to ID the vehicle and that\'s why it should
                           still be included in the snapshot. Since motor carriers
                           are allowed up to 9 characters in the VISTA system and so
                           many states use VISTA, SAFER/CVIEW should increase the
                           field length to 9. At the present time SAFER/CVIEW allows
                           only 5 characters and this is not enough. Even non-VISTA
                           states are allowing fleet designators in the IDs which can
                           make them fairly long. See SAFER CRFs 1748 and 1749.\
                           \
                           Analysis: Stuart 6/14/2001\
                           Discussed at ACCB 6/21/2001\
                           Disposition: Open until corresponding SAFER CRs 1748 and
                           1749 closed; analysis will need to include updates to
                           documents affected. Paul North has contacted FMCSA
                           regarding the impact the change of the unit number length
                           would have on release of SAFER/CVIEW 3 (about 1 week). The
                           address length problem will most likely be addressed in
                           the context of the SAFER Option Working Group
                           requirements.\
                           \
                           sbs 2002-04-01: SAFER CR 128 (formerly 1748) has been
                           fixed. SAFER CR 129 (formerly 1749) will be included in
                           SAFER version 4.

  **Fix:**                 Field lengths have been corrected in XML transactions in
                           SAFER 4.2.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:19:54 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:46:49 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 1:02:01 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           75

  **External               CR 1555
  Reference:**             

  **Category:**            Impact of EDI standard version on data elements carried in
                           snaps

  **Component:**           SAFER

  **Synopsis:**            The SAFER software is remaining at EDI standard 4010. (CRF
                           1196) This has the following impact:\
                           - Fuel Type not available.\
                           - SAFER User ID, which would be helpful for update
                           security, will not be available. Must continue to use
                           -mutual agreement- code in 4010.\
                           - The Implementation Guides are Version 4030. Earlier
                           versions are not maintained.\
                           - 4010 does not include the increased VIN length (from 25
                           to 30) requested by PRISM.\
                           - 4010 does not include country code in license plate.\
                           - 4010 does not include the additional N2 segment to
                           accommodate the longer name lengths requested for license
                           and insurance data.\
                           - FMCSA code directory in the 4010 version of the standard
                           does not include 3 codes added since then. These codes,
                           T23, T24, and T27, refer to the code tables for Cargo,
                           Hazmat Cargo, and Compliance Reviews. Therefore none of
                           the codes in these 3 tables are referenced by Version
                           4010. If states use 4020 or later versions, SAFER will
                           ignore the transaction. If they use 4010, they will have
                           to edit their version of the standard to include the 3
                           codes that SAFER uses that are not part of the 4010
                           standard.\
                           QUESTION: If SAFER is never going to migrate to the new
                           standard should these effected data fields still be part
                           of the snapshot view definitions? We are saying one thing
                           (in the IG) and doing another.\
                           \
                           Submitted by Stuart 2/22/2001

  **Status:**              Closed Disapproved

  **Disposition:**         Discussed with FMCSA 12/20/2001

  **Description:**         We talked to Chris Conway of MN, Jim Ramsey & Wray
                           Williams of KY, DJ Waddell of MD, Gary Nishite of CA. They
                           all indicated that there was no need within their
                           respective states to have the fields in 4040 that are not
                           in 4010. CA does not need the increased VIN length; they
                           will handle it. There is an issue of what it means for
                           four states to not be in conformance with the standard
                           identifiers, by not using the country code for license
                           plate. Otherwise, we propose that FMCSA does not implement
                           changes in SAFER to support 4040.\
                           \
                           Disaspproved by ACCB 6/15/2001, but needs to be discussed
                           with FMCSA.\
                           Submitted to FMCSA 12/2001.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    CRF 1555 Attachment.doc

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       12/21/2001 5:12:13 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          12/17/2001 2:45:30 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           12/21/2001 5:12:13 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           74

  **External               CR 1554
  Reference:**             

  **Category:**            No new vehicle views after CVIEW 3.x

  **Component:**           CVIEW

  **Synopsis:**            The latest SAFER SOW says: Update views will have specific business rules tied to them. For instance, IRP updates will behave differently from E-Screening and Inspection Report updates. Since these rules constitute
                           view-specific code, vehicle update views can no longer be created simply by adding new views to the database. New vehicle update views must be accompanied by new code and a new release of SAFER/CVIEW to accommodate
                           them. This means that after CVIEW 3.x there will be no support for new vehicle update views from the state\'s point of view, and no way to add additional credential data to the snapshots, such as OS/OW, intrastate
                           regstration, titling etc. How does this work with CVISN statements that the electronic credentialing (and data flow to CVIEWs) is expected to expand beyond IRP and IFTA ?\
                           \
                           Submitted: Stuart 2/22/2001

  **Status:**              Closed Disapproved

  **Disposition:**         Disapproved and closed by the ACCB 4/4/2002.

  **Description:**         The S/C V2 and S/C V3 vehicle data elements are essentially the same, with the exception of special tables created for vehicle history for PRISM. The relationships between these elements have been revised.\
                           \
                           An examination of the snapshot white paper has shown that ALL vehicle data elements are covered in the three update views (E-Screen, IRP, Inspection) with the following exceptions:\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           License Plate State is not in any view. IRP Base State is the data element that establishes this value. The update rules for License Plate State are as follows:\
                           \
                           \* If there is a license plate number in the update information, Licence Plate State is set to the value of IRP Base State.\
                           \* If there is no license plate number in the update information, both License Plate State and License Plate Number are set to NULL.\
                           \
                           This allows MD to send in IRP registrations prior to a license plate being issued.\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           No NMVTIS Check Flag or Update Date view.\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           No view for CVSA Expiration date, although the CVSA decal issued does exist in the inspection view. No inspection state assigned carrier census number in inspection view.\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           No view for Permit fields in S/C V2, however this view has been added to S/C V3.\
                           \
                           Recommendations:\
                           \
                           \* Add NMVTIS view.\
                           \
                           \* Add CVSA Expiration date and \"inspection state assigned carrier census number\" to inspection view.\
                           \
                           \* Clarify License Plate State in white paper.\
                           \
                           \
                           Salazar:\
                           Email sent to states on May 11 and discussed with states in monthly teleconferences on May 22, 2001.\
                           Only one state expressed interest in the NMVTIS view.\
                           Several states would like to have CVSA Expiration date and state carrier ID in the vehicle inspection view. We recommend that those two fields be added to the views in a future version of SAFER. We do not recommend
                           that an NMVTIS view be defined. Architecture documentation would be impacted. This corresponds to CVOSS CR 1794.\
                           \
                           Recommended by ACCB 8/9/2001.\
                           \
                           Reopened after CVOSS CCB meeting 12/10/2001.\
                           \
                           Information from Ron Glaser and Alan Mick (refer to CR 1794 for more details):\
                           \
                           The vehicle.CVSA_EXPIRE_DATE is not available from the inspection report. It would have to be derived.\
                           \
                           The inspection report contains a single field for carrier id and state carrier id. It is stored as the database field vehicle.CARRIER_ID_NUMBER.\
                           \
                           We propose that since vehicle.CVSA_EXPIRE_DATE and vehicle.CARRIER_STATE_ID are not available from the inspection report, they should not be included in the Inspection View Q302.\
                           \
                           NCM 2002-04-05: Presented to the ACCB on 4/4/2002. It was agreed that vehicle.CVSA_EXPIRE_DATE and vehicle.CARRIER_STATE_ID will not be requested for the Inspection View Q302.\
                           \
                           NCM 2002-04-05: Disapproved and closed by the ACCB 4/4/2002.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       1/8/2007 11:20:03 AM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          12/17/2001 2:43:55 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           1/8/2007 11:20:03 AM
  --------------------- -- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           73

  **External               CR 1552
  Reference:**             

  **Category:**            Maintain vehicle query capability

  **Component:**           CVIEW

  **Synopsis:**            The CVISN architecture shows CVIEW sending carrier and
                           vehicle queries to SAFER. According to the latest SAFER
                           statement of work, CVIEW version 3.x will not provide
                           vehicle queries from CVIEW to SAFER. There will be carrier
                           queries only, and these will be via remote procedure call,
                           not EDI. SAFER/CVIEW should maintain vehicle queries from
                           CVIEW to SAFER.\
                           \
                           submitted by Mary Stuart 2/22/2001

  **Status:**              Closed Disapproved

  **Disposition:**         \[2003-02-06 ncm\] Closed out CR

  **Description:**         Not scheduled for SAFER/CVIEW version 3. Estimate to
                           implement in SAFER is 4-6 weeks. Candidate for inclusion
                           in future version of SAFER, not in version 3.\
                           \
                           Analysis: North reported to ACCB 5/17/2001.\
                           \
                           \[2003-02-06 ncm per rhg\] SAFER will continue to support
                           EDI vehicle queries sent to it directly via e-mail as long
                           as EDI is supported. There are no plans to enable vehicle
                           queries sent to a CVIEW to be forwarded to SAFER. CR is
                           closed out.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       2/6/2003 1:45:21 PM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:42:40 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           2/6/2003 1:45:21 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           72

  **External               CR 1551
  Reference:**             

  **Category:**            No EDI queries from APL developed CVIEW to SAFER

  **Component:**           CVIEW

  **Synopsis:**            No EDI queries from APL developed CVIEW to SAFER; SAFER
                           accepts EDI and RPC\
                           \
                           The CVISN architecture shows CVIEW sending EDI queries for
                           vehicle and carrier snapshots to SAFER. CVIEW as developed
                           does not support EDI queries to SAFER. Queries are
                           accomplished via remote procedure call only. CVISN
                           documentation should reflect CVIEW-SAFER as EDI or RPC,
                           and point out that SAFER can acept and respond to either.\
                           \
                           Submitted by: Stuart 2/22/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         Some documents need to be clarified by explaining the RPC
                           vs. EDI situation that exists today between CVIEW and
                           SAFER for snapshot queries, while discouraging new
                           developers from planning to use the RPC mechanism
                           long-term. In some cases this can be addressed by adding a
                           paragraph. The proposed paragraph follows:\
                           \
                           \"SAFER was initially built to provide snapshot data to
                           CVIEW using EDI. That is the mechanism by which the APL
                           CVIEW currently receives subscription data from SAFER.
                           SAFER also responds to EDI queries for snapshots. In the
                           APL version of CVIEW, however, snapshot queries (carrier
                           only) are sent to SAFER via remote procedure call (RPC),
                           not EDI. The RPC capability was implemented in both SAFER
                           and CVIEW to improve performance for the near-term, but
                           its long-term support is uncertain and continued
                           availability is not guaranteed. EDI is the current
                           official interface. States can enhance the APL CVIEW by
                           implementing EDI snapshot queries;however, in the future,
                           the snapshot interface is expected to be Web-based, using
                           XML and HTTP; new developers should concentrate on that
                           approach.\"\
                           \
                           Other modifications may also be required to explain the
                           availability of RPC vs. EDI vs. Web-based solutions, e.g.,
                           diagrams and tables.\
                           \
                           ACCB Documents Affected:\
                           CVISN System Design Description\
                           COACH Part 4\
                           Other Documents Affected:\
                           CVISN Guide to Safety Information Exchange\
                           SCOPE Workshop Session 5\
                           Training - Technology Application Course (possibly)\
                           \
                           \
                           Analysis: Magnusson 6/8/2001\
                           Recommended by ACCB: 5/15/2001\
                           Approved by FMCSA: 7/3/2001

  **Fix:**                 Corrections made to following documents:\
                           \*\*SCOPE Workshop Session 5 - published Oct 2001\
                           \*\*CVISN Guide to Safety Information Exchange - published
                           and delivered via PL-02-0088 (POR-99-7191), 13 June 2002\
                           \*\*System Design Description: published and delivered via
                           PL-03-0123 (POR-97-6998), 20 May 2003.\
                           \*\*COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 7:20:15 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:41:38 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 12:55:07 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           71

  **External               CR 1508
  Reference:**             

  **Category:**            CVIEW Version 3 will not store inspection reports locally

  **Component:**           CVIEW

  **Synopsis:**            Requirements Clarification:\
                           \
                           CVIEW 3.0 will have the capability to support ASPEN 2.X
                           (32-bit). The following constraints on this functionality
                           are being implemented:\
                           \
                           1) CVIEW 3.0 will not store inspection reports locally.
                           They will automatically be sent on to SAFER. Queries sent
                           to CVIEW (PIQ) will be passed to SAFER via RPC, since no
                           inspection reports will be resident on CVIEW.\
                           \
                           submitted by: Mick 2/5/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         COACH Part 3 and the SCOPE Workshop (section 5) require
                           slight modifications for clarification purposes. The
                           Snapshot White Paper (soon to be published) was already
                           clarified. The published version of COACH Part 5 is
                           incorrect, but the latest update (which is now being
                           reviewed) is correct.\
                           \
                           ACCB items affected: COACH Part 3 and Part 5, Snapshot
                           White Paper\
                           Other documents affected: SCOPE Workshop\
                           \
                           Analysis: Magnusson 3/30/2001\
                           Recommended by ACCB: 5/15/2001\
                           Approved by FMCSA 7/3/2001

  **Fix:**                 COACH Part 5 updated July 2001 (MWS)\
                           \
                           Interoperability Test Suite Package Part 2 updated July
                           2001 (MWS)\
                           \
                           Snapshot White Paper published Aug 2001\
                           \
                           Scope workshop published Oct 2001\
                           \
                           COACH Part 3 V2.0: published and delivered via PL-03-0472
                           (POR-97-7067), 22 October 2003.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 7:20:30 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:40:19 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           12/18/2001 4:26:05 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           70

  **External               CR 1501
  Reference:**             

  **Category:**            PIQ results from SAFER and CVIEW via RPC Mechanism

  **Component:**           SAFER

  **Synopsis:**            This CR is not being submitted to request a change, just a
                           requirements clarification:\
                           \
                           PIQ from CVIEW to SAFER via RPC\
                           \
                           When a CVIEW gets a past inspection query (PIQ) it will
                           check its local database for matches and return the
                           results, if any, to the client. If, and only if, there are
                           no local results, it will issue an RPC query to the SAFER
                           RPC service and return the results, if any, to the client.
                           If no matches are found in either database the standard
                           \"data not on server\" message is returned.\
                           \
                           Note that if any matching inspection reports exist in
                           CVIEW, the SAFER service will not be queried, and any
                           matching inspection reports on SAFER would not be
                           returned.\
                           \
                           submitted by Mick 2/1/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Allows storage of IR\'s in CVIEW without negative affect
                           on PIQ.\
                           \
                           This CR describes the ASPEN-CVIEW interface; no action
                           required other than updating the Guide to Safety
                           Information Exchange.\
                           \
                           ACCB documents affected: Guide to Safety Information
                           Exchange\
                           \
                           Analysis: Mick\
                           discussed at ACCB:

  **Fix:**                 2002-06-17 ncm: Guide to Safety Information Exchange
                           published 6/13/02

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:20:40 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:38:49 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           6/18/2002 12:42:53 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           69

  **External               CR 1463
  Reference:**             

  **Category:**            IFTA Tax Scenario Changes

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The IFTA Tax scenarios, thread diagrams and interface
                           specifications need to be corrected and updated. The
                           changes need to be reviewed by stakeholders and
                           incorporated into all applicable CVISN documentation.\
                           \
                           Background: Some of the interface specifications for IFTA
                           tax-related exchanges were found to be incorrectly
                           described in the CVISN Guide to Credentials. Also, an
                           additional tax-related business need was brought to our
                           attention that requires the addition of an EDI interface
                           between the State and carrier for sending notice of tax
                           adjustments to the carrier. Revised scenarios and
                           interface specifications were reviewed by the ANSI X-12
                           Government Subcommittee, Tax Information Interchange Task
                           Group(X12/TG2) at their December 2000 meeting, and their
                           comments and recommendations were incorporated in to the
                           scenarios included in the attachment.\
                           \
                           The proposed corrections are as follows:\
                           1. There is no electronic notification of tax filing due.
                           TG2 pointed out that this would have legal implications
                           concerning whether or not the carrier received
                           notification. Most jurisdictions would not rely on an
                           electronic notice either via email or EDI, and there is no
                           EDI equivalent transaction to accomplish this. Thus, the
                           use of TS 813 is inappropriate for notification of tax
                           filing due, and should be removed from the scenarios.\
                           2. Tax credits are sent to the carrier via the TS 826. The
                           TS 813 is uni-directional and always goes from the tax
                           filer to the tax authority, and is not appropriate for
                           this exchange.\
                           3. The TS 150 is appropriate to request and receive tax
                           rates from the state, however the TG2 group pointed out
                           that it is more likely that states will post their rates
                           on a web site. This is now noted on the scenarios.\
                           4. The final change is the addition of an EDI transaction
                           set to satisfy a business need that was not included in
                           the original CVISN interface specifications. The
                           transaction set is used when a state needs to send the
                           carrier a correction to the tax filing that includes a
                           recalculation of taxes due. According to the TG2 group,
                           the appropriate EDI transaction set for this exchange is
                           the TS 149, Notice of Tax Adjustment or Assessment.\
                           \
                           Submitted by: Stuart 1/16/2001

  **Status:**              Closed Approved

  **Disposition:**         Closed

  **Description:**         Impact of changes: The proposed changes will require
                           corresponding changes to ACCB items such as the CVISN
                           Guides and the COACH documents (a complete list can be
                           added to this CR upon further analysis), as well as
                           updates and corrections to the CVISN workshop and training
                           materials to reflect the correct interface specifications.
                           Any existing or planned carrier system designs that serve
                           these business needs should be examined to verify correct
                           use of the transaction sets. On the State side, the
                           systems responsible for creating EDI responses to the
                           carrier, whether a legacy system interface for the IFTA
                           tax system or a credentialing interface (CI), should be
                           examined to verify appropriate use of the EDI transaction
                           sets. There should be no impact for the IFTA
                           clearinghouse.\
                           \
                           Note that CVISN Level 1 capability does not require
                           inclusion of the TS 150 (tax rate exchange) in State CVISN
                           designs at this stage, and by extension, the use of the TS
                           826 for tax credits which are sent along with the tax
                           rates to the carrier, would not be considered part of
                           Level 1. The additional specification for the TS 149 for
                           notice of tax adjustment is also outside the scope of the
                           CVISN Level 1 capability. Therefore, the implications of
                           these changes for a State implementing only the Level 1
                           capability should be minimal.\
                           \
                           To summarize, these changes may have an impact on EDI
                           development plans in the IFTA tax area for those states
                           that are already designing/implementing capabilities
                           beyond CVISN Level 1. Note that this is only applicable to
                           your design if you are implementing an EDI interface from
                           the carrier to your state, such as with a CAT-CI
                           interface. MWS update 4/01: I have been in touch with KY,
                           MN, WA, MD and none of these states have a problem with
                           this change. MWS update 6/14/01: Email to states was sent
                           out in February and again in May. There were no responses
                           that indicated any problems with the proposed corrections.
                           The few responses we did get indicated a Web solution for
                           IFTA so it didn\'t impact them. The ACCB documents
                           impacted are the CVISN Guides (TLD and Credentials), and
                           COACH Part 5(taken care of with CR 1377). Other documents
                           impacted are the CVISN Workshop materials(Scope), Training
                           materials and the Interoperability Test Suite Package
                           Parts 1,2 and 4. Also impacts System Design Description.\
                           \
                           Analysis: Stuart 1/17/2001\
                           Recommended by ACCB 5/17/2001\
                           Approved by FMCSA 7/3/2001

  **Fix:**                 COACH Part 5 updated July 2001 (MWS)\
                           Interoperability Test Suite Package Part 2 updated July
                           2001 (MWS).\
                           System Design Description: published and delivered via
                           PL-03-0123 (POR-97-6998), 20 May 2003.\
                           COACH Part 4: published and delivered via PL-03-00568
                           (POR-97-7067), 5 Nov 2003.\
                           \
                           \
                           No longer maintained:\
                           Scope 6\
                           Guide to Credentials Administration

  **Comment:**             

  **Attachment names:**    CR_1463_IFTAtax.ppt

  **Responsibility:**      Magnusson Nancy C

  **Modified Time:**       11/24/2003 7:20:49 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:37:28 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           11/5/2003 12:53:36 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  **CR Number:**           68

  **External               CR 1308
  Reference:**             

  **Category:**            Add a Carrier Snapshot IRP Update View to SAFER and CVIEW

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            We need to have a Carrier Snapshot IRP Update View.\
                           \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\
                           E-Mail from Alan Mick on Tuesday 10/10/2000 9:38 AM:\
                           Jim,\
                           The only CARRIER snapshot information we send to CVIEW is the MCMIS view, and it would be inappropriate for IDT to send that information in.\
                           My suspicion is that they would send the IRP view, which for a carrier is pretty simple:\
                           \
                           DOT Number\
                           IRP Account Number\
                           IRP Check Flag\
                           IRP Check Flag Date\
                           \
                           Please verify with Robert/Karen the contents of the CARRIER IRP view, and then suggest that to Wray as the view/fields to be updated.\
                           This might involve more work than Carolyn should be handling for KY. We might have to get help from some of the EDI folks.\
                           \
                           Submitted by Polaha 10/13/2000

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         Two IRP update views exist in CVIEW 2.4. These views are being documented in the current version of the whitepaper. Additional fields required in the IRP carrier update will
                           need to be requested via the SAFER option working group and a new CRF.\
                           \
                           Analysis Clyde 11/2000\
                           Recommended by ACCB 11/27/2000\
                           Approved by FMCSA 7/3/2001

  **Fix:**                 Snapshot White Paper published Aug 2001

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 7:21:00 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:34:04 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           12/18/2001 4:09:39 PM
  --------------------- -- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           67

  **External               CR 1227
  Reference:**             

  **Category:**            Make Vehicle Registration Data Repeating Fields

  **Component:**           Snapshots

  **Synopsis:**            Multiple registrations per vehicle must be supported. It
                           is unusual but unavoidable that one vehicle can have
                           registrations and license plates from more than one state,
                           including IRP and/or intrastate registrations/plates.
                           Several previous CRs addressed aspects of this problem:
                           607 on IRP/Intrastate check flags; 1117, 1118 and 1119 on
                           EDI, snapshots and code directory updates for registration
                           flags/dates. Those CRs are absorbed into this new CR
                           (1227). Analysis is required to determine which data
                           fields are linked to vehicle registration data for each
                           jurisdiction (eg. different owners allowed? Different
                           registered weights?) Update logic must be designed (e.g.,
                           two intrastate plates from one state allowed?) Proposed
                           answers will have to be reviewed by a group of state
                           vehicle registration experts.\
                           \
                           Submitted: Waddell 9/6/2000

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         See \"Multiple Vehicle Registrations.doc\" in
                           \\\\SSDAPPS2\\PVO\\Config Mgmt\\CRF
                           Database\\CRFs\\Attachments\\CRF_1227\
                           \
                           Analysis: Waddell 11/3/2000\
                           Recommended by ACCB: 11/27/2000\
                           Approved by FMCSA: 7/3/2001

  **Fix:**                 Implemented in SAFER/CVIEW 3.3

  **Comment:**             

  **Attachment names:**    Multiple Vehicle Registrations.doc

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:21:11 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:32:38 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 12:47:02 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           66

  **External               CR 1082
  Reference:**             

  **Category:**            Diesel Emissions Data in Inspection Reports and Snapshots

  **Component:**           Snapshots

  **Synopsis:**            A group of states is seeking to include diesel emissions
                           data in inspection reports and flags in snapshots for
                           interstate enforcement of environmental regulations.
                           Corresponding CRs should be issued for changes to ASPEN
                           and/or other inspection support systems.

  **Status:**              Closed Disapproved

  **Disposition:**         \[2006-11-21\]Closed - disapproved

  **Description:**         \[2000-06-09\] DJ Waddell\
                           A group of states is seeking to include diesel emissions
                           data in inspection reports and flags in snapshots for
                           interstate enforcement of environmental regulations.
                           Corresponding CRs should be issued for changes to ASPEN
                           and/or other inspection support systems. The original
                           emails from Massachusetts and New Jersey are attached.
                           Also attached are two presentations made originally at the
                           Eastern States CVISN Design Workshop that spell out the
                           proposal.\
                           \
                           \[2000-10-27\] DJ Waddell\
                           Analysis is provided in the attached file Diesel
                           Emissions.doc\
                           \
                           \[2006-03-29\] Presented again at the 2006-03-23 ACCB
                           meeting.\
                           This CR was originally proposed by MD in June, 2000. MD
                           said that sharing this data is important for the
                           northeastern states, subject to Department of the
                           Environment regulations. It would be very helpful if ASPEN
                           supported diesel emissions data. APL will contact east
                           coast states to see if they are still interested. WA will
                           check with state patrols.\
                           \
                           \[2006-05-26\] Discussed at the 5/18/06 ACCB meeting.\
                           APL will transfer CR 66 (Diesel Emissions Data in
                           Inspection Reports and Snapshots) to the I-95 Corridor
                           Coalition for further investigation.\
                           \
                           \[2006-07-26\] Discussed at the 7/20/06 ACCB meeting.\
                           Mary Stuart contacted Marygrace Parker from the I-95
                           Corridor Coalition. Marygrace recalled that analysis was
                           conducted a few years ago by I-95 and thought that an
                           ASPEN CR had been submitted. She will look for the
                           documentation. Mary Stuart noted that requirements are
                           needed and suggested keeping the CR open until further
                           analysis is done.\
                           \
                           \[2006-11-21\] Discussed at the 11/16/06 ACCB meeting.\
                           No states have expressed an interest recently in pursuing
                           the addition of diesel emissions data in inspection
                           reports and/or snapshots. It has been suggested that this
                           CR be closed.

  **Fix:**                 

  **Comment:**             

  **Attachment names:**    Diesel Emissions I-95 Project.DOC\
                           Diesel Emissions WG.DOC\
                           Diesel Emissions.doc\
                           Joe Civaler Email.doc\
                           Multi-State Diesel Emissions.PPT\
                           NJ Diesel Emissions.PPT\
                           Original Message.doc

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       1/23/2007 12:42:32 PM

  **Modified By:**         Salazar Sandra B

  **Entered On:**          12/17/2001 2:30:27 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Suggestion

  **Closed On:**           12/11/2006 7:32:56 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           65

  **External               CR 1059
  Reference:**             

  **Category:**            Stopped Sending the complete SSN and only send the four
                           digit SS

  **Component:**           Snapshots

  **Synopsis:**            FMCSA has stopped sending SAFER the full social security
                           number of motor carriers. Only the last four digits are
                           being provided. In the carrier snapshots a tax id type of
                           \"S\" will have a tax id number of at most four digits.
                           Duplicates will be possible. Employeer id numbers, with a
                           type of \"E\" are unaffected.\
                           \
                           Submitted by Mick 5/24/2000

  **Status:**              Closed Approved

  **Disposition:**         \[2003-01-20 ncm\] Closed - IFTA portion covered by CR 681

  **Description:**         Include information in the Snapshot White Paper to explain
                           what data will appear in the SSN field. When the impact
                           has been described, the CRF should be promulgated to the
                           snapshot stakeholders so that they are aware of what has
                           happened.\
                           \
                           The whitepaper has been updated to reflect this change in
                           census data. However, this is a question of being able to
                           supply tax id\'s with IFTA updates. The only place tax ID
                           occurs is in census data and MCMIS is the authoritative
                           source for this. There probably needs to be a tax ID
                           number added to the IFTA credential data. This was left
                           open and was to be discussed further. We also need to look
                           at whether there is an issue with IFTA being able to
                           supply US DOT numbers for update. The original plan was
                           for them to use tax id number to link to existing
                           snapshots but this is not an option in SAFER.\
                           \
                           (Salazar 6/14/01) Spoke with Tom Melville and Jim Poe of
                           Indiana, Rick Taylor of Kentucky, and Sandy Axley of
                           California. It seems that this is still an open issue;
                           there is a move toward using USDOT but it hasn-t happened
                           yet. IFTA, Inc. needs to address this; it is an agenda
                           item for the IFTA, Inc. Managers- Workshop in October.\
                           \
                           \[ncm 2003-01-20\] The IFTA part is covered by CR 681.

  **Fix:**                 Snapshot White Paper published Aug 2001\
                           Check SAFER 4.2 reqs. for association of US DOT number
                           with IFTA account. \[ncm 2003-01-20 - the IFTA portion is
                           covered by CR 681\]

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       1/20/2003 10:38:31 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:28:58 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           1/20/2003 10:38:31 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           64

  **External               CR 1046
  Reference:**             

  **Category:**            Definition of IRP Check Flag in Snapshot White Paper is
                           unclear

  **Component:**           Snapshots

  **Synopsis:**            Definition of the IRP Check Flag in the snapshot white
                           paper is unclear and does not meet users\' needs.\
                           \
                           Submitted by Salazar 5/13/2000

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         Appendix A. Detailed Snapshot Contents.\
                           \
                           Carrier Snapshot Row 174 Column A Data Description\
                           Change \"IRP Check Flag\" to \"IRP Status Flag\".\
                           \
                           Carrier Snapshot Row 174 Column C EDI IG Data Item\
                           Change \"IRP Check Flag\" to \"IRP Status Flag\".\
                           \
                           Carrier Snapshot Row 174 Column G Comments Carrier\'s IRP
                           Status (Active or Inactive). A value of \"Check\" means
                           the carrier\'s status is inactive. Consult authoritative
                           source for additional information.\
                           \
                           Change to: Set by the authoritative source to indicate
                           whether the carrier\'s IRP Status is Active or Inactive.
                           The three states and their interpretations are: Null (not
                           set) - No information provided by authoritative source.
                           Check - Set by the authoritative source to indicate that
                           the carrier\'s IRP status is inactive. The snapshot user
                           should query the authoritative source for up-to-date
                           status information and the necessary specifics. Okay - Set
                           by the authoritative source to indicate that the
                           carrier\'s IRP status is active. Note that the IRP Status
                           Flag is associated with the IRP Account Number; a single
                           carrier (USDOT number) may have more than one IRP
                           account.\
                           \
                           Vehicle Snapshot Row 42 Column G Comments\
                           Indicates the registration has been suspended or has a
                           stop placed on it (invalid). A value of \"Check\" means no
                           valid registration. Consult authoritative for additional
                           information.\
                           \
                           Change to: Set by the authoritative source to indicate
                           whether the vehicle credentials are legal. The three
                           states and their interpretations are: Null (not set) - No
                           information provided by authoritative source. Check - Set
                           by the authoritative source to indicate that the vehicle
                           credential is suspended or revoked. The snapshot user
                           should query the authoritative source for up-to-date
                           status information and the necessary specifics. Okay - Set
                           by the authoritative source to indicate that the vehicle
                           credentials are legal. Note that the IRP Check Flag is
                           associated with the IRP Account Number; a single carrier
                           (USDOT number) may have more than one IRP account.\
                           \
                           Analysis Salazar 6/1/2000\
                           Recommended by ACCB 8/11/2000\
                           Approved by FMCSA 7/3/2001

  **Fix:**                 Snapshot White Paper published Aug 2001

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 7:21:27 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:26:46 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           12/18/2001 3:49:24 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           63

  **External               CR 0940
  Reference:**             

  **Category:**            Potential Changes to Vehicle Snapshot resulting from
                           SAFER-PRISM

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            Potential changes to vehicle snapshot resulting from
                           design of combined SAFER-PRISM central site database will
                           dramtically change structure of vehicle database and
                           relationships of data in the vehicle snapshot.
                           Specifically, there will be N to N relationships between
                           VIN and state plate and between state plate and
                           registration information. Previous vehicle snapshot
                           queries will not work in the same manner. Previous IRP
                           updates will not work. The 285 EDI representation of the
                           vehicle snapshot may also be affected.\
                           \
                           There needs to be a review of the impacts of these changes
                           on other CVISN programs and stakeholders.\
                           \
                           Submitted by Goldfarb 2/25/2000

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         This CRF identifies the need to modify the SAFER database
                           to support the Performance and Registration Information
                           Systems Management (PRISM) program. The proposed changes
                           create a many-to-many relationship between license plates
                           and Vehicle Identification Numbers (VINs), where, before,
                           there was a one-to-one relationship. The proposed changes
                           should correct errors in the original design. Vehicle data
                           will be divided into several tables as illustrated in
                           database table design information provided in \\Config
                           Mgmt\\CRF Database\\CRFs\\Attachments\\Crf_940\\for CRF
                           940 PRISM_Vehicle_V3.ppt Under the new design, an
                           inspection report will not establish the state/plate
                           relationship to a VIN. Instead, there are now separate
                           fields for the VIN and state/plate recorded during an
                           inspection.\
                           \
                           Under the new design, a query on either VIN or state/plate
                           may result in a return of zero or many matches. As part of
                           the PRISM effort, the SAFER database team worked with Ruth
                           Skluzacek of the Iowa Department of Transportation to
                           create and review a truth table that describes valid,
                           suspicious, and erroneous data combinations. This is
                           provided in \\Config Mgmt\\CRF
                           Database\\CRFs\\Attachments\\Crf_940\\IRP_matrix.xls.
                           Another table was developed to demonstrate in more detail
                           what the choices are when a new record is received and one
                           or more of the key fields is the same as those fields in a
                           record already existing in the database. The second table
                           gives an example of what could happen when a carrier wants
                           to switch plates on two vehicles. The example is based on
                           these two \"business rules\":\
                           \
                           RULE 1: - A VIN can only have one PLATE/STATE within a
                           state at any given time.\
                           This rule would prevent the following condition:\
                           VIN STATE PLATE\
                           10 MD 777\
                           10 MD 888\
                           \
                           RULE 2: - A PLATE/STATE can only be associated with one
                           VIN within a state at any given time.\
                           This rule would prevent the following condition:\
                           VIN STATE PLATE\
                           10 MD 777\
                           20 MD 777\
                           \
                           In March 2000, the table board agreed that other vehicle
                           registration experts should review the truth table. After
                           review of the proposal via email by IRP experts from MD,
                           KY, MN, VA, and IRP, Inc., a teleconference was held on
                           July 7, 2000, to obtain closure. The proposal was
                           unanimously declared acceptable.\
                           \
                           \
                           Impact Summary:\
                           ACCB Items - Snapshot White Paper\
                           Vehicle queries by VIN will return multiple snapshots -
                           rather than one - if there are multiple license plates
                           registered for the VIN.\
                           285 EDI vehicle representation changes will be minimal -
                           or non-existent.\
                           285 EDI carrier snapshot will potentially need to change
                           (for IRP account data). This change will be implemented in
                           SAFER 3.0.\
                           \
                           Analysis Salazar 8/11/2000\
                           Recommended by ACCB 8/11/2000\
                           Approved by FMCSA 7/3/2001

  **Fix:**                 20020821 Robert Goldfarb This change has been implemented
                           in SAFER/CVIEW v3.3.\
                           \
                           The 2 IRP business rules described in the CR are valid for
                           SAFER/CVIEW IRP processing but are not limitations in the
                           SAFER/CVIEW v3.3 db. In fact, the SAFER v3.3 db at VOLPE
                           could have vehicles that violate the 2 business rules due
                           to PRISM processing.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 7:21:36 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:25:14 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           8/21/2002 11:59:07 AM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           62

  **External               CR 0827
  Reference:**             

  **Category:**            Snapshot Update Views and Control

  **Component:**           Snapshots

  **Synopsis:**            Questions on Snapshot update views need to be resolved.
                           Snapshot update views need to be defined for IFTA (and
                           perhaps other credentials) at the carrier level. Currently
                           there is a vehicle snapshot update view for IRP only. Who
                           decides what data items are needed for updates of the
                           database? Who decides who should be able to update the
                           database? If Kentucky wants a view for their CI to send
                           full Carrier snapshot updates to their CVIEW that include
                           IRP and IFTA information, can they do that? And if they
                           do, does that mean every state can define any view for any
                           combination of credentials? If SAFER will only take one
                           type of credential update at a time (like IRP or IFTA) do
                           we have to have a separate view defined for each
                           credential? Which ones are to be at the carrier level and
                           which ones at the vehicle level? Does the state decide?
                           How is this information provided to the state CI EDI
                           developers? If the sender thinks they are sending a
                           snapshot update (like a Q105, full carrier) that is not
                           actually allowed by SAFER or CVIEW as an update, some
                           information is ignored, and the fields are not changed.
                           How is the sender notified of this? The IG says the sender
                           can specify a change, replace, add or delete for the TS
                           285 update, (see CR 269) but CVIEW treats them all as
                           replace which requires every data field filled in or it
                           will be replaced with a null value.\
                           \
                           Submitted by Stuart 12/14/99

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         See Attached file for advice on handling inputs from
                           multiple sources. Should add a carrier IRP view.\
                           \
                           Brenda Clyde (11/21/00) A file containing the definition
                           of proposed views for IFTA and IRP can be found on the
                           server at PVO\\Arch Concepts\\snapshots\\Proposed Level 1
                           Views 112100.xls. This file still has a few questions
                           which are being worked. Additions will need to be made for
                           HazMat, OS/OW and Diesel emissions.\
                           \
                           Configuration items affected include SAFER, state
                           developed CVIEW, EDI IG 285 and snaphot whitepaper.\
                           \
                           Several Carrier and Vehicle views were added to CVIEW
                           version 2.4. All new views added are being documented in
                           the MAY 2001 version of the whitepaper Additional views
                           are being added to CVIEW 3.0. These views allow for the
                           updating of the fields in the snapshot. Any new views
                           required by a state/user to perform updates of snapshots
                           will need to be requested via the SAFER Option Working
                           Group or via a new CRF.\
                           \
                           Analysis Barnes 6/15/2000\
                           Recommended by ACCB 6/15/2000\
                           Approved by FMCSA 7/3/2001

  **Fix:**                 Incorporated in System Design Document - 2000.\
                           Incorporated in COACH Parts 1 and 3 - 2000.\
                           Snapshot White Paper updated and published Aug 2001.

  **Comment:**             

  **Attachment names:**    Data Mult Sys 2000-06-19JJP.ppt

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 7:21:47 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:22:20 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           12/18/2001 3:41:02 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           61

  **External               CR 0714
  Reference:**             

  **Category:**            Multiple IRP Account Numbers per Carrier

  **Component:**           SAFER

  **Synopsis:**            The IRP allows several accounts to be established per
                           carrier. The SAFER database has only one account / check
                           flag per carrier. SAFER has a change request to allow
                           multiple accounts / check flags per carrier. I think that
                           VA stated that they did not want multiple IRP check flags
                           but one over-all IRP check flag. I am unsure whether or
                           not this issue was considered by the Architecture CCB
                           board and I did not want to approve the SAFER request
                           untill it has been.\
                           \
                           Related CRF: 484, 832, 1227\
                           \
                           Submitted by Alan Mick 9/7/1999

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         CRs 484 and 832 are hereby closed and absorbed into this
                           CR. The decision of the ACCB is to support multiple IRP
                           accounts per motor carrier. Each account is to have its
                           own IRP Check Flag and associated date. A state that
                           wishes to may logically \"or\" all such IRP Check Flags
                           within ROC or similar systems to create their own \"Master
                           IRP Check Flag.\" Related CR 1227 calls for analysis of
                           multiple IRP and/or Intrastate registration in vehicle
                           snapshots.\
                           \
                           Analysis: Waddell 9/6/2000.\
                           Recommended by ACCB 9/6/2000.\
                           Approved by FMCSA 7/3/2001.

  **Fix:**                 Multiple IRP accounts per motor carrier are handled in XML
                           transactions in SAFER 4.2.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:21:57 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:18:30 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 12:47:57 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           60

  **External               CR 0693
  Reference:**             

  **Category:**            Add MCS 150 Mileage and Year to SAFER Snapshot

  **Component:**           Snapshots

  **Synopsis:**            FHWA (Pat Savage) has requested that the MCMIS database
                           values MCS_150_MILEAGE and MCS_150_MILEAGE_YEAR added to
                           the SAFER web page. In order to do this, these values have
                           been added to the SAFER database. While there are no SAFER
                           clients that require this information, it may be useful
                           and maybe should be added to the snapshot.\
                           \
                           submitted by Alan Mick 8/2/1999

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         Implemented in SAFER 2.x\
                           Change will be incorporated in next revision of the
                           Snapshot White Paper.\
                           \
                           Recommended by ACCB 8/11/2000.\
                           Approved by FMCSA 7/3/2001.

  **Fix:**                 Snapshot White Paper updated and published Aug 2001.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Greenwald Beverly E

  **Modified Time:**       11/24/2003 7:22:06 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 2:16:02 PM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           12/18/2001 2:10:00 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           59

  **External               CR 0550
  Reference:**             

  **Category:**            Vehicle Cargo Type Length

  **Component:**           DSRC Standards

  **Synopsis:**            In draft 0.1.3b of IEEE P1455, Vehicle-CargoType is
                           specified as 6 characters for HazMat Code. There are
                           several systems and interfaces that use coded values for
                           HazMat, and in none of them are 6 characters required.\
                           \
                           Ron/Ray: you should review the options and make a
                           recommendation on which to use for this field.\
                           \
                           Requested by Barnes 3/18/1999

  **Status:**              Closed Approved

  **Disposition:**         Closed - approved

  **Description:**         In draft 0.1.4 of IEEE P1455, Vehicle-CargoType is
                           specified as 6 characters for HazMat Code. This is based
                           upon CFR 49 part 172 which defines a 2 alpha + 4 numeric
                           designator for a large number of hazmat types (and is
                           normally used on manifests). It was assumed that other
                           cargo types would use fewer than 6 characters and
                           therefore, would be able to fit within this field.\
                           \
                           There are a couple of approaches to reducing the number of
                           characters allocated to hazmat. One would be to adopt some
                           of the other codes used by FHWA to identify hazmat. These
                           codes are based on CFR 49 part 172, but do not provide the
                           level of detail. For example, we could adopt the codes
                           used on form MCS-150 (which is filled in to obtain a DOT
                           number) section 25. The instructions say \"The HM types
                           correspond to the classes and divisions found in 49 CFR
                           173.2.\" These classes and divisions broadly define the
                           hazmat but are not specific. Since the purpose of
                           including a hazmat field on the transponder was to permit
                           emergency response agencies with the ability to determine
                           what hazmat is on a vehicle, this information MAY not be
                           sufficient to meet their requirements.\
                           \
                           Another approach is to code the alpha part of the CFR 49
                           part 172 hazmat code differently while keeping the numeric
                           portion coded as (one byte) characters. Since the alpha
                           portion only takes on values of \"UN\" for international
                           and domestic shipments or \"NA\" used only for shipments
                           within North America (between the US and Canada), it would
                           be possible to employ only one alpha. Specifically, the
                           \"UN\" would be converted to a \"U\" and the \"NA\" would
                           be converted to an \"N\". Other bit oriented coding
                           schemes would be even more efficient.\
                           \
                           Recommend eliminating the second alpha character.\
                           \
                           Impact Summary:\
                           \
                           DSRC Items: IEEE P1455 standard should be modified to
                           reflect 5 character designator and to reference CFR 49
                           part 172 and the specific CVISN modification.\
                           \
                           ACCB Items - none\
                           \
                           EDI Items: none. (The EDI X12 TS 286, 285, and 284 IGs use
                           HazMat codes that should be considered for adoption in
                           IEEE P1455 ).\
                           \
                           Interoperability Test Items: Existing tests should be
                           evaluated. This change may affect test data sets.\
                           \
                           Other CCBs- Items: none (The SAFER database also stores
                           HazMat codes that should be considered for adoption in
                           IEEE P1455.)\
                           \
                           Yuan 3/31/1999

  **Fix:**                 Yuan 5/14/1999

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 7:22:22 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 11:18:35 AM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           12/18/2001 2:01:44 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           58

  **External               CR 0549
  Reference:**             

  **Category:**            Add Transponder ID to List of Standard Identifiers

  **Component:**           CVISN Architecture and Standards

  **Synopsis:**            The list of standard identifiers does not contain
                           Transponder ID. Since the Transponder is a key entity, it
                           should be added to the list. Unfortunately, the issue is
                           not simple, since today-s transponders have one de facto
                           format, and the transponder IDs proposed in IEEE P1455
                           will have a different format.\
                           \
                           The proposed definition for Transponder ID consists of:\
                           - Identifier Name = Transponder ID\
                           - Identifier Segments\
                           1. Transponder ID Definition Flag (1 bit; 0=current;
                           1=P1455)\
                           \
                           If Transponder ID Definition Flag = current, then the
                           other segment is:\
                           2. Transponder Serial Number (32-bit hexadecimal value)\
                           \
                           If Transponder ID Definition Flag = P1455, then the other
                           segments are:\
                           3. Manufacturer Identifier (16 bits; hexadecimal value)\
                           4. Transponder Serial Number (20 bits; hexadecimal value)\
                           \
                           The Transponder ID must be one of the ways used in
                           exchanging information about transponders among agencies
                           and jurisdictions.\
                           \
                           Submitted by Val Barnes 3/23/1999

  **Status:**              Closed Approved

  **Disposition:**         Closed - Approved by FMCSA 7/3/2001

  **Description:**         The Transponder ID is built in to the transponder. All the
                           major electronic screening programs use the Transponder
                           ID. States in some electronic screening programs are
                           implementing a \"screening enrollment\" process to share
                           Transponder IDs and enrollment wishes/decisions through
                           snapshots. To make the connection between the
                           transponder-equipped transponder and the snapshots,
                           standardizing the format of the Transponder ID in
                           interface definitions is prudent. The recommended format
                           is the native Transponder ID stored on the transponder
                           itself and used in the vehicle-roadside communications.
                           Systems implementing the standard Transponder ID should
                           make accommodations for both the current and future ID
                           formats.\
                           \
                           Impact Summary:\
                           ACCB Items - COACH Part 4, CVISN System Design
                           Description, Table05\
                           \
                           EDI Items: The EDI X12 TS 286, 285, and 284 IGs should be
                           reviewed and updated as needed.\
                           \
                           DSRC Items: none?\
                           \
                           Interoperability Test Items: Existing tests should be
                           evaluated. This change may affect test data sets.\
                           \
                           Other CCBs- Items: All products should be evaluated by
                           each CCB. This change may affect databases, user
                           interfaces, and code. The SAFER/CVIEW database should be
                           evaluated.\
                           \
                           Analysis by Val Barnes 3/23/1999\
                           Approved by ACCB 5/1/1999

  **Fix:**                 Most of the problems discussed is this CRF have been
                           previously resolved. One unresolved problem with the
                           transponder ID is the fact that Norpass stores transponder
                           ID numbers as hexadecimal numbers while Prepass and others
                           use decimal transponder ID numbers in their database. The
                           transponder ID is normally identified in hexadecimal on
                           the transponder case. The ID may also be displayed in
                           decimal as well as hexadecimal, however, this is not
                           always the case. The 8-digit hexadecimal character based
                           format would appear to lead to less problems when stored
                           in the SAFER/CVIEW databases due to the one-to-one
                           relationship between the character and the position of the
                           corresponding bits in the integer. Additionally, a
                           hexadecimal ID would not require additional field length
                           while the 10-digit decimal format would require additional
                           field length. Based on a review of the appropriate
                           implementation guides and discussions with individuals
                           familiar with these guides, there does not appear to be a
                           specification as to whether these numbers should be
                           specified in hex or decimal format. Transponder ID format
                           should be specified to be in hexadecimal, vice decimal.
                           This format change should be implemented as soon as
                           possible. The longer this goes on the greater the number
                           of transponder IDs that will have to be changed.\
                           \
                           CVISN System Design Description updated and published.\
                           COACH 4 updated and published.\
                           Snapshot White Paper updated and published Aug 2001.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 7:22:31 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 11:13:38 AM

  **Entered By:**          Greenwald Beverly E

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           12/18/2001 1:40:15 PM
  --------------------- -- ----------------------------------------------------------

  --------------------- -- ----------------------------------------------------------
  **CR Number:**           57

  **External               CR 0393
  Reference:**             

  **Category:**            Add Last Update Date for Views vice Snapshots

  **Component:**           Snapshots

  **Synopsis:**            Date of last update applies to the full snapshot, not to
                           any one view in it. When one view is updated and the date
                           is changed, it may give the false impression that other
                           data is also up to that date. There should be an update
                           date specific for each view.

  **Status:**              Closed Fixed

  **Disposition:**         Closed - Approved by FMCSA 12/20/2001

  **Description:**         It is suggested that in the SAFER/CVIEW database a table
                           be created that contains two fields: the name of the input
                           view and the date last posted for that input view. It is
                           suggested that whenever a snapshot is generated for output
                           it contain one or more dates last posted corresponding to
                           the data being sent.\
                           \
                           Since a view sent out (output view) may contain data items
                           from several input views (updates from authoritative
                           sources), the output view could be defined to include the
                           date last posted for each input view in it.\
                           \
                           The snapshot definition (table 5) could be organized by
                           input views (authoritative sources) with each of these
                           sections showing a date of last update for it. The
                           SAFER/CVIEW database would not necessarily be organized
                           this way, however.\
                           \
                           Brenda Clyde (11/21/00) Configuration items affected
                           include: SAFER, State developed CVIEW, EDI IG 285, and
                           snapshot white paper.\
                           \
                           Alan Mick (2001-09-17): The requested change is not
                           included in the requirements for CVIEW version 3, which
                           will be the last update to the CVIEW software. Given the
                           fact that this has a LOW priority and cannot be included
                           in CVIEW, I suggest that it not be implemented in SAFER.\
                           \
                           Alan Mick (2001-11-29): Examination of the SAFER Option
                           Working Group requirements and the desire to advance to
                           the use of FTP has increased the value of this feature
                           from the point of view of data integrity. Since each input
                           view may be updated by different sources at different
                           times, the last update date would be used to reject
                           updates that would \"regress\" the snapshot because they
                           arrived later than an update from another authoritative
                           source. I recommend this change be added to the SAFER
                           version 4 requirements, and I have reopened the SAFER CCB
                           CRF. However, I do not believe it will be possible, or
                           necessary, to alter CVIEW version 3.3 plans or provide
                           this information in EDI. Instead, I recommend that it
                           appear in the flat file and XML interface to SAFER.\
                           \
                           Recommended for FMCSA approval and implementation in SAFER
                           version 4, November 29, 2001.\
                           Approved by FMCSA 12/20/2001

  **Fix:**                 Discuss with SAFER team.\
                           \
                           SAFER Team has been notified, previously deferred CRF has
                           been changed to Reconsider. Mick 12/7/2001\
                           \
                           In EDI, IRP view will contain the last update date, if
                           provided in the snapshot (SAFER/CVIEW v3.3). The last
                           update date is included in XML transactions in SAFER 4.2.

  **Comment:**             

  **Attachment names:**    

  **Responsibility:**      Salazar Sandra B

  **Modified Time:**       11/24/2003 7:22:40 AM

  **Modified By:**         Magnusson Nancy C

  **Entered On:**          12/17/2001 11:00:28 AM

  **Entered By:**          Salazar Sandra B

  **Severity:**            High

  **Priority:**            No

  **Type:**                Defect

  **Closed On:**           10/10/2003 12:46:50 PM
  --------------------- -- ----------------------------------------------------------

**Total:** 158