conveyance or yard moves segments even after they occur. Knight
believed the most common error made with ELDs is that drivers forget to
change duty status. Therefore, FMCSA should allow drivers to make duty
status change designations as edits at any time. Such an allowance will
better serve drivers and alleviate concerns about an ELD intruding upon
an individual's privacy.
    TCA wrote that employers should be allowed to make minor edits to
correct driver ELD records, limited to instances that do not pertain to
compliance with driving or on-duty time.
    ATA stated that the proposed rule on edits will complicate
compliance and enforcement, and could raise the potential for fraud.
ATA identified several problems it perceived as the result of requiring
driver acceptance of edits. The commenter wrote that FMCSA must
consider what an employer should do if a driver refuses to accept the
changes. Similarly, ATA asked what happens if the erroneous record is
identified during an internal review weeks or months after the fact and
the driver cannot be contacted for approval because he has since left
the company? For these reasons, and because the carrier is ultimately
responsible for maintaining accurate records, ATA stated that FMCSA
should permit carriers to make edits. At a minimum, the Agency should
allow changes that would not disguise driving time violations or
otherwise make such violations possible. ATA indicated that minor
recordkeeping errors that do not reflect driving time violations
comprise the vast majority of HOS violations. ATA recommended that
FMCSA allow carriers to correct them, unhindered by the need to seek
driver approval, would more efficiently help both carriers and
authorized safety officials focus on those comparatively few
discrepancies that reflect material fraud (i.e., false logs) and
driving time violations.
    J.B. Hunt wrote that the final rule should clearly say that
corrective action taken by a carrier against a driver for false entries
is not harassment.
    BigRoad Inc. (BigRoad) stated that, although section <IP_ADDRESS>.2 (2)
allows for the correction of errors related to team driver switching,
it does not allow for the correction of errors commonly found in slip-
seat operations, where drivers do not always drive the same truck each
day. In such operations, drivers occasionally forget to sign out when
their shift in the truck ends or forget to sign in when their shift
begins. This can cause drive time to be incorrectly assigned to the
driver who was last signed in instead of the current driver of the
truck, essentially the same type of error experienced by team drivers
who are signed-in incorrectly. ABA stated that there was some confusion
with respect to the SNPRM requirement that only drivers are able to
``edit'' their HOS records. While ABA agreed that drivers should have
the ability to revise a duty status designation, it asked whether the
SNPRM meant to allow drivers to revise records that do not reflect a
change in duty status. ABA contended that the driver should be allowed
to revise only the duty status designation and that the final rule
should reflect that determination.
    Schneider National supported the proposal that the driver must
approve edits made by the motor carrier to ensure accuracy. However,
since any edit made on a record from more than the preceding 8 days
will not impact the current duty cycle, the requirement for driver
approval should be removed. Schneider listed several operational
reasons why an edit would be made on a record that is more than 8 days
old.
    Roehl Transport stated that the proposed process will complicate
compliance and enforcement. Allowing the company to edit a driver's ELD
record would, they argued, facilitate its ability to correct a
potential falsification. Roehl Transport wrote that the motor carrier
is ultimately responsible for maintaining accurate RODS and FMCSA
should permit motor carriers to make edits to drivers' RODS.
    Verigo commented that the proposal to allow editing of ODND records
does

not indicate any time limit, or address edits that trigger a violation
on subsequent records that have already been certified. Verigo believed
that the proposal indicated that, when edits, additions, or annotations
are necessary, the driver must use the ELD. Commenter believed the rule
should allow editing and recertification of records outside of the ELD
provided all other proposed protocols are followed.
    The IBT supported allowing a driver to edit, enter missing
information, or annotate their ELD record when the vehicle is stopped.
It was concerned with the motor carrier's ability to propose changes
directly to the driver's record within the electronic interface because
it would create an opportunity for driver coercion and harassment. It
supported the inclusion of edit notes as detailed in the appendix to
subpart B of part 395, section 4: Functional requirements. The IBT
proposed that, if a driver record is changed, the source of the change
be documented.
    The IME indicated that any change of a driver's records made by a
motor carrier should require the driver's approval.
    The OTA stated that some provision needs to be made to allow the
carrier to correct RODS without the driver's approval. Given the high
turnover in the industry, it is common for a driver to have moved to
another carrier and no longer be responsive to the carrier attempting
to correct the record. Commenter wrote that even a clear, obvious error
could remain unchanged if the driver simply refuses to respond to the
carrier's request, resulting in a false log charge against the company.
    Although PeopleNet thought that carriers are better suited to
provide comments concerning the handling of ``unassigned driver
events'' and making corrections to ELD records, it recommended that the
final rule provide some additional guidance on how to manage carrier-
initiated corrections that the driver opts to reject. Zonar recommended
adding a section addressing the certification of records for law
enforcement. Commenter believed that the driver should be required to
certify the records prior to giving them to law enforcement. In
addition, law enforcement should allow the driver sufficient time to
certify his or her ELD records before a citation is given for not
having them available.
2. FMCSA Response
    While FMCSA appreciates carrier management concerns about requiring
driver re-certification of any edits made subsequent to the driver's
initial certification, today's rule retains this concept. The ELD
reflects the driver's RODS, although integrity of the records is both a
driver and carrier responsibility. The driver certification is
intended, in part, to protect drivers from unilateral changes--a factor
that drivers identified as contributing to harassment. In fact, the
rule prohibits a carrier from coercing a driver into making a false
certification. See Sec.  395.30(e) of today's rule.
    Edits are permitted of a driver's electronic record except as
limited by the rule's technical specifications. See <IP_ADDRESS>.2 of the
technical specifications. Each edit must be accompanied by an
annotation. See Sec.  395.30(b)(2) of today's rule. However, if the
driver was unavailable or unwilling to recertify the record, the
proposed edit and annotation made by a carrier would remain as part of
the record. The Agency would expect that a carrier and driver would
ordinarily resolve any disputes in this regard. Changes initiated after
the period during which records were accessible through the ELD (i.e.,
minimum of 8 days) would likely be initiated by a carrier; however,
driver re-certification would still be required. See Sec.  395.30(b)(4)
of today's rule. FMCSA recognizes that the need for edits will
sometimes arise at a time when the driver's record will no longer be
accessible through the ELD. The process to edit records at this point
will vary depending on the ELD system used. However, any edit and
annotation will still require recertification of that record by the
driver.
    Today's rule does not specifically address the ``slip-seat''
scenario raised by BigRoad. However, FMCSA expects the motor carrier to
resolve the issue by proposing edits that would adequately attribute
the driving time and provide an annotation describing the
circumstances. In terms of roadside inspections, the rule would not
modify current practice where a driver normally certifies her or his
record at the close of the day. See Sec.  395.30(b)(2) of today's rule.

H. Harassment Complaints

1. Comments to the 2014 SNPRM
    In the SNPRM, FMCSA proposed a new complaint process under which a
driver who felt that she or he was subject to harassment, as defined in
the SNPRM, could file a complaint with the FMCSA Division Administrator
for the State where the incident is occurring or had occurred. Provided
the complaint was not deemed frivolous, an investigation would result.
FMCSA's finding of a harassment violation could result in a notice of
violation under 49 CFR 386.11(b) or a notice of claim under 49 CFR
386.11(c).
    OOIDA noted that proposed Sec.  390.36 requires that harassment
complaints be based upon violations of Sec.  392.3 or part 395. It
wrote that the statutory provision on harassment is not so limited and
the SNPRM does not explain or defend this limitation. In its view, the
approach of tying harassment problems to driver violations of part 395
or Sec.  392.3 is flawed. Requiring that driver harassment complaints
be based upon regulatory violations creates a giant loophole through
which acts of harassment will pass with impunity. It also stated that
FMCSA has assigned itself a passive role with no duty to investigate or
take any action on its own and criticized the Agency's reference to
alternative remedies. Although OOIDA noted that the reference to
``productivity'' was eliminated in MAP-21, it nevertheless criticized
the Agency's failure to follow the Seventh Circuit's direction that the
Agency define how ELDs may be used to monitor driver productivity. It
also argued that the statutory requirement to address harassment under
49 U.S.C. 31137(a)(2) applies to any electronic logging device and is
distinct from the ELD mandate under section 31137(a)(2). OOIDA further
suggested that the Agency defined ELD in a manner so as to minimize the
requirement that the Agency ensure that ELDs do not result in
harassment.
    ABA stated that Sec.  386.12, regarding complaints of substantial
violations, requires that a complaint against a carrier for a
``violation may be filed with the FMCSA Division Administrator for the
State where the incident . . . occurred.'' It questioned whether the
complaint may be transferred to the FMCSA Division Administrator for
the State where the motor carrier is domiciled. For the small business
bus operator, ABA commented that the costs associated with defending
any complaint can be substantial. The defense would be significantly
more costly if the carrier is required to hire an out-of-State attorney
and bear the costs of the proceeding in a State that could be thousands
of miles away from home.
2. FMCSA Response
    In mandating the use of ELDs for CMV drivers required to keep RODS,
Congress embraced ELDs as a tool to enhance compliance with the HOS
rules. The statute restricts FMCSA's use of ELD-generated data for
purposes unrelated to motor carrier safety enforcement. Thus, in
today's rule the Agency tied the definition of ``harassment'' to
violations of the HOS

rules set forth in part 395 and a related regulation, Sec.  392.3,
prohibiting carriers from requiring drivers to drive when their ability
or alertness is impaired due to fatigue, illness or other causes that
compromise safety.
    FMCSA believes the effective enforcement of the harassment
prohibition requires that harassment be defined by objective criteria.
Linking the definition of harassment to underlying violations of
specified FMCSRs will enhance the Agency's ability, through its
Division Administrators located throughout the country, to respond to
driver harassment complaints filed under Sec.  390.36(c) in a
consistent manner and within a reasonable period of time. However, the
Agency simply lacks the resources necessary to investigate every
possible circumstance that a driver might consider as harassment.
    OOIDA's suggestion that the Agency defined the term ``ELD'' to
include only recording functions in order to minimize its obligation to
address harassment is without merit. The Agency's requirements for an
ELD of limited functionality, which are consistent with MAP-21's
definition, were developed in order to minimize the cost of required
technology. Furthermore, today's rule addresses ELD-related
functionality, other than recording, to require that ELDs have a mute
function available during sleeper berth periods. This technical
specification was adopted directly in response to concerns raised by
commenters.
    In addition, FMCSA notes that Sec.  390.36 is not the sole remedy
available to drivers who believe they have been subjected to
harassment. Drivers may alternatively seek relief by filing a coercion
complaints with FMCSA under Sec.  386.12(c), a process adopted in the
recent coercion rulemaking (80 FR 74695, November 30, 2015), or by
filing complaints with the Department of Labor pursuant to 49 U.S.C.
31105, depending on the underlying facts. The Agency notes that certain
examples of harassment offered by commenters fall squarely within the
realm of labor-management relations rather than the application of the
HOS rules and are therefore outside the scope of this rulemaking.
    The Agency does not address the distinction between productivity
and harassment, because, as part of the MAP-21 legislation, Congress
eliminated the statutory provision expressly permitting carriers to use
ELDs to monitor the productivity of drivers. In light of that revision,
we do not infer congressional intent that the Agency establish
guidelines in this rule for the appropriate use of ELDs to improve
productivity. FMCSA simply makes clear that, for the protection of
drivers, productivity measures undertaken by carriers cannot be used to
harass drivers, as that term is defined in the regulations.
    The procedures governing the filing of a complaint, including with
whom the complaint must be filed, and the procedures addressing the
Agency's handling of a harassment complaint have been modified from
those proposed in the SNPRM in order to track the procedures governing
complaints alleging coercion in a recent FMCSA rulemaking (80 FR 74695,
November 30, 2015). Similarly, the complaint process for substantial
violations is modified to track, in part, procedures under the coercion
rule. Complaints alleging a substantial violation can be filed by any
person through the National Consumer Complaint Database or with any
FMCSA Division Administrator; the Agency will then refer the complaint
to the Division Administrator it believes is best able to handle the
complaint.
    As further indication of the seriousness with which FMCSA's viewed
drivers' harassment concerns, the Agency conducted a survey of drivers
and motor carriers concerning their attitudes and experiences related
to harassment and its relationship to ELDs. FMCSA placed the harassment
survey report in the public docket with a request for comment, to which
OOIDA subsequently responded. The survey and related comments, which
are part of the record of this rulemaking, are discussed in Section
XII, L, of this preamble.

I. Matters Outside FMCSA's Authority

    Several commenters submitted recommendations that would require new
statutory authorities for FMCSA before action could be taken to address
the issue. For example, commenters suggested changes in methods by
which drivers are paid, admissibility of ELD data in litigation, and
further protections of ELD data beyond current law. The Agency will not
consider taking actions beyond its current authority and will not
commit to seeking such authority.

X. Discussion of Comments Related to the Technical Specifications

A. Performance and Design Specifications

    The detailed performance and design requirements for ELDs included
in today's rule ensure that providers are able to develop compliant
devices and systems, and that motor carriers are able to make informed
decisions before purchasing them. The requirements ensure that drivers
have effective recordkeeping systems, which provide them control over
access to their records. The technical specifications also address, in
part, statutory requirements pertaining to prevention of harassment,
protection of driver privacy, compliance certification procedures, and
resistance to tampering. Furthermore, they establish methods for
providing authorized safety officials with drivers' ELD data when
required.
1. Comments to the 2011 NPRM
    The 2011 NPRM relied entirely upon the now-vacated 2010 rule.
Though comments were submitted to the 2011 NPRM concerning the
technical specifications, they were out of the scope of the 2011
proposal, as those specifications had already been finalized in the
April 2010 rule and subsequent amendments to address petitions for
reconsideration of the rule.
2. Comments to the 2014 SNPRM
    FMCSA proposed new technical specifications in the SNPRM, which
included detailed design and performance standards for ELDs that
address statutory requirements. FMCSA proposed specific standard data
formats and outputs that ELD providers would need to use to transfer,
initialize, or upload data between systems or to authorized safety
officials. These proposed technical specifications are intended to be
performance-based, in order to accommodate evolving technology and
standards, and to afford ELD providers the flexibility to offer
compliant products that meet the needs of both drivers and motor
carriers. In the SNPRM, FMCSA asked the following questions
specifically about interoperability.
    1. Should FMCSA require that every ELD have the capability to
import data produced by other makes and brands of ELDs?
    2. To what extent would these additional required capabilities for
full interoperability increase the cost of the ELDs and the support
systems?
    3. While full interoperability could lower the cost of switching
between ELDs for some motor carriers, are there a large number of motor
carriers who operate or plan to operate with ELDs from more than one
vendor? How would full interoperability compare to the proposed level
of standardized output? If carriers wanted to operate ELDs from more
than one vendor, would this be a barrier? Would this issue be impacted

by the market-share of the ELD manufacturer?
    4. Would motor carriers and individual drivers have broad-based use
or need for such capability? Is there a better way to structure
standardized output to lower cost or encourage flexibility without
requiring full interoperability?
    Providers raised questions about many of the technical
specifications and suggested changes. NTSB asked FMCSA to consider
adding crash survivability for ELD and ELD data.
    EROAD Inc. (EROAD) stated that the easiest and fairest way for
FMCSA to provide standards that guarantee high performance is to use
general hardware and software technical and security standards. It
recommended a requirement for ELD providers to meet appropriate FIPS,
Common Criteria, or other equivalent standards.
    BigRoad stated that codifying the technical specifications, as part
of the regulatory requirements, is undesirable because the regulatory
process would impede the development of the technical specifications.
Instead, FMCSA should remove technical specifications from the
regulatory requirements and create a technical standards open working
group consisting of industry and government representatives that is
able to work collaboratively through the interoperability issues.
BigRoad was concerned that the complexity of the ELD specifications,
particularly in support of roadside inspection information transfer,
would result in ELD systems that are more expensive and less reliable
than necessary to meet the requirements of MAP-21. Interoperability
issues between ELD providers and roadside inspection systems could
result in an unintended bias toward drivers producing printed paper
logs during an inspection. Providing simpler roadside data transfer
options, with specific requirements for both ELD providers and
authorized safety officials, would allow technology providers to deploy
the necessary systems more quickly.
    Continental stated that the ELD regulation and associated standards
should include a clear security specification, using standard IT
industry processes and endorsed by the National Institute of Standards
and Technology (NIST) and standardized interfaces. This would assist
with the identification of drivers, the transmission of drivers' data
from one vehicle to another and easy access to and downloading of data
by enforcement personnel and vehicle operators.
    PeopleNet requested clarification on how to manage data for those
drivers that transition between a compliant AOBRD device and a
compliant ELD. Eclipse Software Systems stated that it would be useful
for any driver to have access to non-authenticated driving time so they
are aware of it, since it will be displayed to roadside inspectors. It
asked for a clarification that displaying co-driver names (perhaps
automatically from other driver's data on the ELD) is allowed.
3. FMCSA Response
    The Agency is not requiring crash survivability standards for ELDs
because of the costs involved. Crash survivability is a complicated and
expensive requirement, and would mean that the ELD has to withstand
high impact or crash forces and be water resistant and withstand
exposure to open flames for some period of time. FMCSA does not believe
this is necessary.
    FMCSA agrees that some level of standardization is necessary.
Whenever possible, FMCSA used NIST, or other commonly available
technical standards, including those incorporated by reference in
today's rule in Sec.  395.38, Incorporation by Reference.
    FMCSA has elected to codify the technical specification standards
in the appendix to part 395 in today's rule rather than establish a new
working group. Though FMCSA acknowledges that including the technical
requirements in the regulations makes changing them more difficult,
FMCSA believes this is the best way to provide transparency and ensure
that all interested parties are aware of the requirements and any
proposed changes to the standards. FMCSA notes that adopting technical
specifications by regulation is the only way to make them binding.
Additionally, though the Agency did not create a workgroup, the MCSAC
subcommittee, which included members from the ELD technical community,
gave a recommendation to FMCSA on task 11-04, which the Agency
considered in lieu of a workgroup's recommendations.
    Today's rule requires standardized output and standardized data
sets. FMCSA has decided not to require full interoperability between
all ELDs. Although full interoperability would have some benefits, it
would also be complicated and costly. FMCSA believes that requiring
standardized data output and requiring that drivers have access to
their own records will achieve some of the goals of the commenters
advocating for full interoperability.
    The motor carrier and the driver are responsible for ensuring that
all the RODS information required by the HOS rules is available for
review by authorized safety officials at the roadside. If the driver
works for multiple employers with multiple ELD or AOBRD systems that
are not compatible (e.g., the data file from one system cannot be
uploaded into the other system), the driver must either manually enter
the missing duty status information or provide a printout from the
other system so that an accurate accounting of the duty status for the
current and previous 7 days is available for authorized safety
officials.

B. Specific Performance Requirements

1. Comments to the SNPRM
    Commenters had comments or questions on specific design elements in
the proposed appendix to part 395.
Comments Requesting New Requirements
    FedEx stated that ELDs should be programmed to acknowledge that a
driver is using the 100-air-mile exception. While taking the exception,
the driver should only need to enter start time and end time into the
ELD. Omnitracs, LLC (Omnitracs) asked for a definition of minimum duty
status duration. Paper logs are to a granularity of 15 minutes, but
there is no specification for RODS recorded by the ELD. Omnitracs
believed the customer should be able to configure the duration.
    CVSA and the United Motorcoach Association (UMA) stated that the
ELD should alert a driver when he or she is approaching the HOS limits.
Number of Required Features
    The IFDA recommended eliminating the requirement for a single-step
interface and graphic display or printout. The commenter wrote that
there is not a sufficient safety benefit to justify the 60-minute
requirement for recording the location, communications methods, and
indications of sensor failure, which it wrote are not currently
standard technology.
    XRS stated that FMCSA needs to clarify why the engine hours are a
requirement. FMCSA should identify what other methods would accurately
acquire engine hours without an ECM available.
    ATA raised concerns about the requirement to synchronize devices to
Coordinated Universal Time (UCT) periodically and to ensure that a
device's deviation from UCT not exceed 10 minutes at any point in time.
To ensure such synchronization will

require cell or satellite service (depending on the device) and such
service is not always available. ATA also questioned if ELDs would be
able to produce the volume of data that FMCSA proposes (e.g., last 6
months' records, all drivers who previously used the device). ATA
believed that such requirements will cause devices to need large memory
capacity that will add to cost, reduce design flexibility, and
ultimately impact the ability of some existing hardware to be upgraded
to meet new specifications. ATA recommended limiting the requirement to
the same level of detail that drivers currently must provide during
roadside inspections.
    With the requirement for ELD records to resolve latitude and
longitude to a place name, as well as the distance and direction to the
place name, Verigo stated that it is questionable why locations need to
be resolved to an accuracy of two decimal places. This level of
granularity does not appear to provide a higher level of safety and is
inconsistent with the accuracy in use today. The 10-mile accuracy of
single decimal coordinates is consistent with the distance that could
reasonably be traveled within the 15-minute interval in use.
    Eclipse Software Systems stated that the transaction numbering
system, along with the odometer capture (vehicle miles) provides very
strong security that makes tampering extremely difficult. Adding engine
hours, ignition on/off and VIN detection add very little additional
security. Another issue Eclipse asked FMCSA to consider is that the
serial and CAN buses of ECMs broadcast the odometer and wheel speed
without intervention from an ELD. The ELD can sit in ``listen mode''
and obtain this information. Conversely, to get engine hours and VIN,
the ELD must transmit on the ECM bus, and send requests for this
information. Eclipse commented that it was aware of some EOBRs
improperly transmitting on vehicle buses, causing erratic behavior on
the electrical bus. Given that an ELD mandate is likely to draw lots of
new providers to this market (who may be inexperienced with ECM
interfacing), it seems safer that ELD providers operate in ``listen
only'' mode, where they are less likely to interfere with vehicle
operation by broadcasting on the engine bus.
2. FMCSA Response
    FMCSA is aware that there is no current device on the market that
meets every standard in today's rule. However, the intent of this rule
is to set a standard that the Agency believes is secure, useful, and
can be met at a reasonable cost. FMCSA has been careful to consider the
cost of developing new components of an ELD, and has purposefully set
standards that can be met by re-programming many existing devices with
little cost to the providers.
Requesting New Requirements
    FMCSA does not require ELDs to accommodate any statuses other than
those that are currently required to complete paper RODS, including
excepted and exempted statuses. However, section <IP_ADDRESS>.2. (c) states
that an exemption must be proactively configured for an applicable
driver account by the motor carrier. The ELD must prompt the motor
carrier to annotate the record and provide an explanation for the
configuration of the exemption.
    FMCSA does not require a minimum duty status duration. The ELD will
capture all duty statuses entered; there is no minimum amount of time
these statuses must be engaged. While longstanding industry and
enforcement practices may have relied upon minimum intervals of 15
minutes in the handwritten RODS, the ELD provides for a more accurate
accounting of drivers' time. This should not be construed to be an
indicator that the activities that are electronically recorded as less
than 15 minutes are suspect, only that the time actually required to
complete the task may be less that what had been traditionally noted in
the paper RODS.
    FMCSA allows, but does not require, any notification of the driver
when they are nearing their HOS limits. While an ELD will automatically
record on-duty driving time, a driver is still responsible to record
other duty statuses based on the driver's actual work time.
Number of Required Features
    FMCSA agrees that data transmission is complex, and roadside
enforcement and review will likely play a large role, especially in the
transition phase of the implementation of today's rule. For this
reason, FMCSA has standardized the information on the printout and the
display screen to contain the same data set. FMCSA believes that the
modifications made from the SNPRM in today's rule to require a
standardized backup of a display or printout will increase the ease of
users.
    FMCSA acknowledges the commenter's concerns about 60-minute
location but the Agency believes ELD devices can easily be programmed
to record at 60 minute intervals.
    FMCSA believes it is necessary to record engine hours, as a check
with the other data contained on the ELD. A record of engine hours,
when compared with the ECM odometer readings, verifies the accuracy of
periods other than drive time. Because today's rule is not applicable
to vehicles older than model year 2000, and ELD providers can work-
around vehicles using OBD-II, which might not capture engine hours, the
concern about engines without ECMs should be eliminated. However,
should a driver of a CMV with a non-ECM engine wish to install an ELD,
Appendix B sections 4.2(b) and <IP_ADDRESS>(b) provide specifications for an
ELD when there is no ECM or ECM connectivity.
    With current technology, it should be rare for an ELD's time to
drift more than 10 minutes. In addition, the technical specifications
require the ELD to (1) periodically cross-check its compliance with the
requirement specified in section <IP_ADDRESS> of the Appendix with respect
to an accurate external UTC source and (2) record a timing compliance
malfunction when it can no longer meet the underlying compliance
requirement.
    FMCSA clarifies that the ELD in the CMV only needs to retain the
data for the current 24 hour period and the previous 7 consecutive
days. Carrier (or private driver) record keeping systems could retain
more data for the purposes of historical data storage. FMCSA does not
prohibit any ELD from retaining more data than 8 days, but it is not
required. The carrier is required to keep data for 6 months in case of
an FMCSA inspection. This information can be kept on the device itself
or in the carrier's office. These electronic files are not large. FMCSA
estimates that 6 months of data, for one ELD, would not require more
than 10 MB of storage. Therefore, in this rule, FMCSA does not reduce
the data set that needs to be retained.
    FMCSA needs to capture latitude and longitude because it is more
reliable for computers to process than place names. However, FMCSA also
needs place names to allow drivers to verify that the location is
correct and safety officials to recognize the location quickly. Data
collected in addition to odometer, such as engine hours, are necessary
as a cross check to verify that data has not been manipulated. Location
resolved to an accuracy of two decimal places when drivers are on-duty
driving provides a clear history of where the driver and vehicle have
been. In today's rule, FMCSA does not require an ELD to be able to
communicate with the motor carrier. FMCSA disagrees that the location
information does not have a safety reason; location information will
make falsification of HOS records more

difficult. Additionally, FMCSA believes this level of specificity can
provide accurate time information, and that this is not a difficult
level of location information to meet.
    In response to concerns about improper transmittal, the industry
will be driven by customer requirements to provide safe and non-
interfering connectivity of the ELDs to the engine ECM or ECM
connectivity. Additionally, the use of industry standards in the
regulation, and the requirement that ELD providers register and certify
their ELDs on FMCSA's Web site, should reduce the potential for this
type of issue.

C. Security

1. Comments to the 2014 SNPRM
    The SNPRM proposed incorporating by reference several industry
standards for privacy and encryption including NIST standards.
    Continental stated that ELDs should be tested and certified to
comply with security standards by independent laboratories that follow
processes endorsed by NIST. In the absence of a precise requirement for
a specific tamper resistance level, FMCSA should at least ensure that
ELD software cannot be accessed and modified by end users. As drafted,
Continental stated the rule may lead to the proliferation of hacked or
cloned apps for smartphones and tablets that exactly mimic the displays
of compliant systems. As a minimum security requirement, FMCSA should
only allow ELDs that prohibit user access to the software environment
on the device. The provider of the ELD should demonstrate during the
certification process that the software environment on the device
cannot be easily accessed and modified by the end user. While the
industry has shown an interest in using smart devices for operational
management, the current market penetration of smart device-based ELDs
is very low. Therefore, there will be only a minimal financial impact
to the industry by prohibiting open-software devices. As the number and
sophistication of tampering attempts will grow with time, the overall
tamper resistance level could be significantly enhanced by requiring
that the data delivered by ELDs be digitally signed. Continental noted
that FMCSA proposes to require that ELDs provide data in the format of
an electronic file. Lacking enforceable security requirements, however,
it will be extremely easy to perform undetectable modifications on
those files.
    XRS stated that many suppliers of AOBRD portable devices or
handheld devices that are AOBRD compliant and moving to an ELD have
been employing security measures through the use of Mobile Device
Management software, which provides for security of the device.
    BigRoad stated that the series of checksums that are required on
event logs, output file lines, and the entire output file itself are
calculated in a manner that would be trivial to recalculate should any
data be altered. However, in proposed sections 7.1.20, 7.1.26, and
7.1.31 (7.21, 7.27, and 7.32 in this rule), these values have the
stated purpose to identify cases where an ELD file or event record may
have been inappropriately modified after its original creation. BigRoad
stated that, for security against purposeful tampering, only a
cryptographically robust signature of the data in question is effective
in practice.
    Omnitracs also questioned the value of these and stated that as
proposed they provide no security. PeopleNet recommended the use of a
proven industry standard, MD5 Hash.
2. FMCSA Response
    FMCSA follows all DOT Security guidelines which includes NIST
standards for access to any FMCSA system or network. In this rule,
FMCSA has expressly prohibited any modification at the user level.
FMCSA believes that the security standards of ELDs have appropriately
balanced industry standards, privacy, the need for accurate HOS
monitoring, and the cost of security measures. FMCSA notes that it has
only established minimally compliant standards in this rule, and there
could be a market for more security features on an ELD. ELD providers
are not prohibited from using additional security measures, so long as
the data can still be transferred to authorized safety officials as
required by the today's rule.
    In addition, the commenter's concern about mobile devices is
misplaced. Security on mobile devices is well-understood. Banks,
governments, and retailers all provide apps which require security.
There is no reason to believe that consumer mobile devices cannot be an
adequate platform for ELDs. FMCSA believes the specifications and
privacy standards and protocols are sufficient to respond to reasonable
concerns about hackers.
    FMCSA does not prohibit the use of Mobile Device Management
software, but believes it is too costly to include as a minimum ELD
specification.
    The intent of the checksums is to provide a simple method of
detecting data manipulation to help prevent a novice user or rogue
script programmer from easily modifying the data and gaming the system.
The checksum algorithms are sufficiently robust to prevent a novice
user from simple data manipulation. Although MD5 is a well-known and
more robust checksum algorithm, in this instance it is no better than
the simple scheme provided in this rule. Someone changing the data
could simply apply the MD5 checksum to each line as there is no
independent source to verify its accuracy. The MD5 checksum has the
additional disadvantage of adding significantly more data to each line,
thus increasing the size of the overall file.

D. External Operating Factors and Failure Rate of ELDs

1. Comments to the 2014 SNPRM
    The SNPRM did not address the effect of external operating factors,
such as dirt or vibration, on the failure rate of ELDs.
    The National Ground Water Association stated that FMCSA should
ensure that providers understood that ELDs had to perform when
subjected to vibration from heavy equipment. The Association of General
Contractors stated that the off-road conditions construction vehicles
operate under may be problematic for ELDs. Its members indicate at
least a 10 percent failure rate.
2. FMCSA Response
    In today's rule, FMCSA continues to allow the marketplace to
address developing roadworthy ELDs. As with other electronic device
manufacturers (mobile phones and laptop computers for example), the
market should drive ELD providers to respond to CMV operating
situations where a high level of durability is required. CMVs that
operate only on the highway may not need the robustness of design that
the construction and utility industries require.

E. Automatic Duty Status

1. Comments to the 2014 SNPRM
    If the driver's duty status is Driving, an ELD would only have
allowed the driver who is operating the CMV to change the driver's duty
status to another duty status. A stopped vehicle would have to maintain
zero (0) miles per hour speed to be considered stationary for purposes
of information entry into an ELD. Additionally, an ELD would have to
switch to driving mode automatically once the vehicle is moving at up
to a set speed threshold of 5 miles per hour.

    XRS stated that FMCSA should indicate whether the drive time should
be set back to the beginning of the on duty period when 5 minutes has
expired. Zonar stated that the safety, effectiveness, efficiency, and
reliability of the ELD and FMS will be significantly limited by not
allowing automatic duty-status changes when the system finds specific
criteria for an event have been met. Zonar commented that automatic
changes include providing the driver the ability to change the event;
if the driver does not respond, then the automatic duty status occurs.
Automatic duty status records must include an annotation to describe
the system action taken, so the original record is retained.
    XRS stated that FMCSA should reconsider ``Other Automatic Duty-
Status Setting Actions Prohibited'' since the driver will have the
ability to edit and annotate other changes. Section 395.2 (definition
of ``on-duty time'') allows a co-driver to be off duty for up to 2
hours in the passenger seat of a moving vehicle before or after at
least 8 hours in the sleeper berth and then the co-driver must revert
to on duty. Allowing an automatic duty status change from off to on
duty when the 2 hours expires, would make ELD records more accurate and
avoid additional transactions by the driver without compromising
safety.
2. FMCSA Response
    FMCSA purposefully did not require drive time to set back
automatically. FMCSA believes that the driver of a CMV has a
responsibility to ensure the accuracy of his or her own HOS records.
FMCSA considers that, in most cases, status changes should be directly
linked to an action taken by a driver.
    An ELD must prompt the driver to input information into the ELD
only when the CMV is stationary and the driver's duty status is not on-
duty driving, except for the automatic setting of duty status to ODND.
The driver still has the option to edit and switch that time after it
has elapsed, as long as it is not driving time. Limited editing rights,
coupled with the ability of the driver and motor carrier to annotate,
should ensure that records are accurate. FMCSA does not believe this
will result in an unreasonable number of edits or complicated data for
enforcement.

F. CMV Position

1. Comments to the 2014 SNPRM
    The SNPRM provided that an ELD must have the capability to
automatically determine the position of the CMV in standard latitude/
longitude (proposed section <IP_ADDRESS>. of the SNPRM). The ELD must obtain
and record this information without any external input or interference
from a motor carrier, driver, or any other person. CMV position
measurement must be accurate to 0.5 mile of absolute
position of the CMV when an ELD measures a valid latitude/longitude
coordinate value.
    FMCSA proposed that position information be obtained in or
converted into standard signed latitude and longitude values and must
be expressed as decimal degrees to hundreds of a degree precision
(i.e., a decimal point and two decimal places).
    XRS stated that FMCSA needs to clarify the accuracy of the GPS as
to rounding up or truncating on the 1-decimal and 2-decimal accuracy.
Eclipse Software Systems stated that FMCSA is requiring that the ELD
determine date, time, and location ``[w]ithout allowing external input
or interference.'' Given that this data comes from GPS, and GPS can be
interfered with (by obscuring the GPS antenna, for example), the
wording should be changed to reflect that the carrier, driver, or other
individuals are not allowed to set the date, time, and location
manually. Eclipse commented that other parts of the SNPRM already make
it clear that interfering with GPS is a violation, but the
responsibility lies with the individual, not the ELD provider.
    Zonar asked for guidance on the maximum characteristics to be
displayed. A customer may choose to have more precise information than
3 to 6 or 3 to 7 characters. As an FMS has reports and tools that are
supported by the precise GPS location of the vehicle, this will have a
major impact on the system.
2. FMCSA Response
    Geo-location rounding to a 1-decimal (approximately within a 10
mile radius) will provide sufficient granularity to the data without
providing an excessive amount of specificity; this granularity remains
of limited specificity when reduced to 2-decimal accuracy. Because the
date, time, and location will be determined by the ELD without
modification by the driver, motor carrier, or any other individual, any
alterations to these records would be considered tampering with an ELD
under Sec.  395.8(e)(2).
    The output values for GPS location for the purpose of enforcement
and compliance to the ELD rule may be 3 to 6 characters. If a carrier
has more character requirements for its FMS there is no prohibition on
having more precise information.

G. Special Driving Categories

1. Comments to the 2014 SNPRM
    The SNPRM proposed to add a requirement for the ELD to provide the
capability for a driver to indicate the beginning and end of two
specific categories, namely, personal use of a CMV and yard moves, as
allowed by the motor carrier. In these cases, the CMV may be in motion
but a driver is not necessarily in a ``driving'' duty status. This
would record the necessary information in a consistent manner for the
use of drivers, motor carriers, and authorized safety officials.
    In the data structures as defined in the SNPRM, XRS saw no
allowance for identification for items such as adverse conditions, or
16-hour short haul exemption and requested guidance on how these should
be identified or indicated in the files. Zonar asked for clarification
on the special driving categories: How does FMCSA expect this to be
displayed in ``Off-Duty'' and ``On-Duty Not Driving'' or is there no
requirement?
    While Omnitracs agreed with resetting the special driving situation
to ``none'' if the ELD or CMV's engine goes through a power off cycle,
it suggested that the same confirmation be allowed during yard driving
that is allowed for authorized personal use of the CMV. This would
enable the driver to turn off the engine when connecting or
disconnecting a trailer when operating within a company's facility
without the requirement to re-enter the annotation of yard driving each
time the engine goes through a power cycle.
2. FMCSA Response
    FMCSA does not require special identification to be built into an
ELD for specific exceptions or adverse condition status. FMCSA expects
drivers and motor carriers to use the annotation ability on the ELD to
record these statuses.
    Today's rule permits the driver to indicate the beginning and end
of yard moves and personal conveyance, as allowed by the motor carrier.
All other special driving categories, such as adverse driving
conditions (Sec.  395.1(b)) or oilfield operations (Sec.  395.1(d)),
would be annotated by the driver, similar to the way they are now.
    The Agency feels that the allowance of multiple power off cycles
would not provide a substantive reduction in inputs required by the
driver during yard moves. In addition, this may create a potential for
misuse of the off duty yard-move status.

H. Data Automatically Recorded

1. Comments to the 2014 SNPRM
    The SNPRM proposed that the ELD would automatically record the
following data elements: (1) Date; (2) time; (3) CMV geographic
location information; (4) engine hours; (5) vehicle miles; (6) driver
or authenticated user identification data; (7) vehicle identification
data; and (8) motor carrier identification data.
    Eclipse Software Systems stated that it had concerns that items (6)
driver, and (8) motor carrier information cannot truly be
``automatically recorded.'' The ELD can make note of the current driver
and carrier, but these values have been manually entered or selected by
a human at some point. Unlike items 1 through 5, and 7, they are not
provided by external sensors.
    Inthinc Technology Solutions, Inc. (inthinc) stated that a driver
may log out and then turn off the engine. It asked if engine shutdown
should be recorded on the ELD record even though the driver is logged
out.
    Schneider requested confirmation that in Sec.  395.32(a), where the
words ``as soon as the vehicle is in motion'' occur, that the
definition of `motion' is the one found in the appendix, in section
<IP_ADDRESS>.
2. FMCSA Response
    Today's rule provides that driver and motor carrier information
will be the responsibility of the motor carrier, as reflected in Sec.
395.22. After a driver's unique login to the ELD, this information will
be available to the ELD and will be recorded by the ELD, with all the
other data elements, at each change of duty status and at intermediate
recording times.
    With regard to comments about the engine status, FMCSA notes the
ELD will automatically capture the engine on and engine off activities,
including the date, time, and location of these activities. FMCSA
expects the driver to enter a new duty status before turning the
vehicle off. For example, if the driver intends to remain on duty, then
the driver would enter that information and then turn the vehicle off.
If the driver plans to switch from driving time to a sleeper-berth
period, the new duty status would be entered before the vehicle is shut
down. The precision of the data collected by an ELD is not intended to
override the practical sequence of events needed to reduce to the
greatest extent possible annotations and corrections.
    The ELD will indicate the vehicle is in motion once the vehicle
begins moving at a set speed threshold of up to 5 miles per hour.

I. Driver's Annotation/Edits of Records

1. Comments to the 2014 SNPRM
    The SNPRM proposed that a driver may edit and a motor carrier may
request edits to electronic RODS. All edits would have to be annotated
to document the reason for the change. The SNPRM did not allow any
driving time to be edited into non-driving time.
    BigRoad noted that the annotation requires a 4-character minimum.
Its database of logs includes hundreds of thousands of 3-letter notes
that are meaningful. It stated that the restriction should be removed.
Omnitracs stated that the term ``source data streams'' is too vague and
should be changed to ``recorded data.'' Omnitracs recommended the
process outlined in sections <IP_ADDRESS>.1 and in <IP_ADDRESS> be amended to
track only the original and the driver-approved final edit since they
comprise the final record set. It also stated that the requirements
regarding edits to driver ELD records do not sufficiently detail that
only the original and final edits are to be maintained and are too
restrictive regarding automatically recorded drive time edits.
PeopleNet stated that the specifications in section <IP_ADDRESS> mean that
if the driver is in Driving, gets to the destination, and turns off the
ignition, he will remain in Driving, which is incorrect, but the ELD
cannot reduce drive time.
2. FMCSA Response
    The term ``source data streams'' has a broader meaning than
``recorded data.'' It includes all the information, recorded or not,
that the ELD receives. FMCSA does not find that there is a reason to
include 3-letter notes as acceptable annotations, and continues to
require 4-character minimum codes. The Agency thinks that a code with a
minimum of four characters will provide better quality information and
specificity.
    When the duty status is set to driving, and the CMV has not been
in-motion for 5 consecutive minutes, the ELD must prompt the driver to
confirm continued driving status or enter the proper duty status. If
the driver does not respond to the ELD prompt within one-minute, the
ELD must automatically switch the duty status to ODND. The time
thresholds for purposes of this section must not be configurable.
Accordingly, the driver status will most likely change to ODND under
the PeopleNet scenario.
    FMCSA declines to limit the record to only the original record and
driver-approved edits. While an edit by a motor carrier normally
requires recertification of the record by the driver, the Agency
acknowledges that there will be instances where a driver is no longer
available at the time of an edit. Although the edit and annotation
would lack the required certification, retaining the carrier edits may
provide a more complete picture of what occurred.

J. Driver's Data Transfer Initiation Input

1. Comments to the 2014 SNPRM
    The rule indicates that a screen icon must be clearly marked and
visible when the vehicle is stopped. Verigo asked for clarification
regarding the required visibility of this icon at all times when the
vehicle is stopped.
2. FMCSA Response
    The icon is a function that allows the driver to easily transfer
data at roadside. The supported single-step data transfer initiation
mechanism (such as a switch or an icon on a touch-screen display) must
be clearly marked and visible to the driver when the vehicle is stopped
and data transfer is required. We expect that the ELD makers will meet
the regulation requirements by incorporating user friendly and useful
features to maintain market share.

K. ELD Data File

1. Comments to the 2014 SNPRM
    In the SNPRM, FMCSA provided that an ELD must have the capability
to generate an electronic file output, compliant with the format
described in section 4.8.2, to facilitate the transfer, processing and
standardized display of ELD data sets on the authorized safety
officials' computing environments. FMCSA required that all output files
be standardized on ELDs according to American Standard Code for
Information Interchange (ASCII), which the Agency proposed
incorporating by reference.
    Zonar asked where the output file comment should be stored--within
the driver records on the ELD, just in the support system, or both? If
stored on the ELD only, when the ELD records are purged after the 7 or
8 days they are required to be retained, should it then be stored
within the support system?
    Omnitracs recommended replacing the word ``ELD'' in section 4.8.2
with the phrase, ``ELD or a support system used in conjunction with
ELDs,'' the same language used in section 4.9.2. The commenter believed
that use of the additional term would allow for closer alignment within
the rules. Omnitracs also stated that there is nothing in the output
file standard that specifies how to handle non-ASCII character sets
such

as special characters that may be used either by Canadian cities/
provinces or even in driver names.
    In section <IP_ADDRESS> of the appendix to part 395, the SNPRM proposed
that the ELD must produce a standard ELD data output file for transfer
purposes, regardless of the particular database architecture used for
recording the ELD events in electronic format. This ELD data output
file must be generated according to the standard specified in section
<IP_ADDRESS>.
    Omnitracs stated that all of the ``supporting'' elements (e.g.
annotations, certifications, malfunctions, etc.) reference the event
sequence ID number as the only means to associate to the actual driver
duty change event (refer to <IP_ADDRESS>.5, which contains the format for
Event annotations or comments). If a driver's duty cycle consists of
data recorded from multiple ELDs, these sequence IDs may overlap and
may not be unique on the current ELD. It recommended that a secondary
reference to the original duty status, which could include an ELD
unique identifier, or even a date/time reference, be used. Omnitracs
requested that there be further clarification on how to handle event
sequence IDs when data on the ELD are a mix of data that have been
recorded from different ELDs. The current language has no provision on
how to handle data from different ELDs when there could be a sequence
conflict.
    Inthinc recommended that UTF-8 be used for output rather than
ASCII. It also asked for examples of how output code should be parsed.
    BigRoad stated that the comma-separated format described in the
SNPRM is not based on any contemporary standard for structured data and
already fails to accommodate some data requirements fully (see Table 6,
Event Type 4). BigRoad wrote the format also fails to account for field
values that might include inline commas or  characters. The
commenter also noted that a file format based on standards like
extensible markup language (XML) would allow for more flexibility for
future changes and could be paired with any character set encoding,
including Unicode, to allow any character data to be captured correctly
without loss of precision. BigRoad wrote that to restrict future
flexibility of the data format to support a minority of devices seems
shortsighted.
    Since ELD data that are transmitted to FMCSA Web services are
formatted as XML, BigRoad believed that XML should be used as the
format for all transmission options. BigRoad wrote that using XML along
with a formal XSD schema is beneficial when trying to ensure
interoperability between disparate systems and would reduce the number
of file format incompatibility issues when transferring data between
systems.
    BigRoad stated that the ELD data file specifications are not
explicit about how to display and transfer data from drivers that
produce records on multiple ELDs. The requirements to display multi-day
data imply that data must be aggregated across all ELDs the driver
uses. None of the ELD data files contains an identifier for the
specific ELD that created the record, so if the records from multiple
ELDs are aggregated the event sequence number ranges throughout the
file could be discontinuous. If the intention is to produce data files
containing ELD data aggregated across several ELDs, BigRoad believed
adding an ELD identifier would mean that each separate ELD could be
easily disambiguated.
2. FMCSA Response
    In today's rule, section 4.8.2 is largely the same as proposed.
Some changes have been made to accommodate comments and to clarify the
rule. In response to the comment asking how the output file comment
should be stored, it must be recorded in the output file and
transferred to roadside enforcement or inspectors. All captured
elements from the output file must be retained by the carrier for 6
months.
    FMCSA understands that some capabilities of an ELD may not be
located on the same physical device, or even in the CMV, but rather in
a support system. FMCSA has provided flexibility in this rule for all
provider types and their respective ELDs.
    FMCSA requires that all information in the output file be
standardized and only include ASCII characters. ASCII is a widely
available standard within the United States, and is appropriate for the
data required. Although ASCII does not provide for special characters,
FMCSA feels that identification of proper names and cities can be clear
without the insertion special characters.
    The ELD technology option for any data transfers will require that
the standard ELD CSV data file outlined in part 395 would be packaged
into XML format. FMCSA will provide and manage ELD XML schema and all
related instructions outlined in guidance, ``ELD Interface Control
Document (ICD),'' to be placed on its Third Party Development site
(3PDP). There is no prohibition on using an XML format internally.
However, ELD output files have a standardized format. The format method
accounts for the suggested needs, including that for Table 7, Event
Type 4. In the respective section, only Event code is necessary as
event type is implied by the section. Field values including inline
commas or  characters can be controlled for or pre-processed by the
ELD provider. FMCSA has updated section <IP_ADDRESS>. to accommodate a comma
or carriage return by adding: ``(3) Any field value that may contain
comma (``,'') or carriage return () must be replaced with a
semicolon (`;') before generating the compliant CSV output file.''
    The concern about HOS records from multiple ELDs is appropriate.
FMCSA added data and time stamp fields to annotations to allow an
improved method of disambiguation. There may still be rare situations
where one or more drivers could have data in multiple ELDs that get
combined into a single file having identical event IDs and slightly
unsynchronized time stamps. The probability of this occurring is low,
but not zero, and the consequences are minimal. An ELD Identifier data
element that BigRoad mentions is already defined in the rule.
    While today's rule does not include requirements concerning
compatibility of files between ELD systems or the ability to upload
drivers' duty status files from multiple systems, there is nothing in
the rule that prevents collaboration among the providers to produce
compatible products. In the absence of a compatibility standard, if a
driver's duty cycle consists of data recorded from multiple ELDs, then
the records will be in multiple files. If the ELD is set to combine
them, then a provider could opt to use an additional field as a
database element in order to keep them separated. In today's rule,
FMCSA has added a secondary reference to the original duty status to
include a date and time field. There are multiple methods to handle
combining data from more than one source and FMCSA has purposely left
this open for the innovation and flexibility of ELD providers.

L. Engine Power Up and Shut Down

1. Comments to the 2014 SNPRM
    The SNPRM proposed that an ignition power on cycle refers to the
engine power sequence changing from ``off to on and then off.'' This
refers to a continuous period when a CMV's engine is powered.
    Omnitracs asked if, since CMV ignition can be in the ``on''
position without the engine running, the ELD must capture when the
ignition is in the on position without the engine running. The same
commenter recommended

that the 1-minute time for power up be relaxed to 3 minutes to allow
for a cold boot situation. Zonar asked what constitutes ``Ignition
power on cycle'' when connected to a hybrid truck? A hybrid truck will
not produce a RPM of greater than 0 until driven.
2. FMCSA Response
    The technical specification included a capture for when the engine
goes from on to off, but the intended data capture was for when the
driver intended to drive the CMV. Though propulsion variations can be
defined, FMCSA wants the specification to capture when the CMV is put
into a state where it can be driven. Likewise, ignition on/engine on
for a hybrid vehicle will be the status of vehicle ready to drive--the
equivalent to ``engine on'' for an internal combustion engine. FMCSA
continues to require the capture of the engine on data.
    FMCSA does not accept the suggestion to relax the power up status
to 3 minutes because the Agency believes that 1 minute is sufficient.
Any cold boot event records that would be captured could be annotated,
or would be clear from the type of activity that occurred. A 3 minute
cold start would be a rare occasion, and would be captured as a
diagnostic event, not as a fault, and should not impact driving time.

M. Engine Synchronization Compliance Monitoring

1. Comments to the 2014 SNPRM
    The SNPRM proposed that an ELD monitor the data it receives from
the engine ECM or alternative sources to record history to identify
instances and durations of its non-compliance with the ELD engine
synchronization, and establish a link to the ECM, as well as set an
engine synchronization compliance malfunction if connectivity to any of
the required data sources is lost for more than 30 minutes during a 24-
hour period aggregated across all driver profiles, including the
unidentified driver profile.
    FMCSA also proposed that engine synchronization must be functional
for all but 30 minutes in a 24-hour period. If it is not, an engine
synchronization compliance malfunction must be logged.
    If the vehicle ECM becomes unresponsive, XRS asked what value
should be inserted into these fields to record the malfunction. There
are other cases of failure that could prevent significant data being
available to record (e.g., Driver interface unit failing. . . . ``Data
recording compliance'' malfunction). The ECM could recover at a later
point and the system will be fully functional.
    XRS wanted FMCSA to clarify the 30 minutes mentioned in this
section. This could easily exceed 30 minutes in a 24 -hour period
especially with many jurisdictions around the country prohibiting CMV
drivers from idling their engines. There is the possibility that a
vehicle bus under particular stress may not respond for more than 5
seconds. Clarification on the 24-hour period as well as the aggregate
of the 30 minutes against all profiles may be difficult or give false
errors.
    Verigo noted that, given the wide variety of computer processor
speeds and other sequencing events that may be encountered, the 5-
second limit may introduce a significantly higher level of error
reporting than necessary to promote safe operation. There have been
several instances where the OBD-II interface does not become active
when the ignition is switched on, but only after the vehicle is
started. Without additional conditions to be checked, it seems likely
that there will be invalid logs of engine sync failure for these
vehicles (i.e. driver turns on ignition and listens to the radio). It
would be useful if the Engine Sync Compliance Monitoring is not
required to log a failure until after engine ignition is detected and
motion is detected (via GPS) and vehicle data are not available.
    Eclipse Software Systems stated engine synchronization must be
functional for all but 30 minutes in a 24-hour period. If it is not, an
engine synchronization compliance fault must be logged. This is
problematic in that the engine bus is not always operational. When the
engine is not powered and a cab door is not open, there is usually no
activity on the engine bus. This is indistinguishable from the wires to
the engine bus being disconnected. One action is harmless, the other is
tampering.
2. FMCSA Response
    Table 4 of the appendix explains the malfunction codes that must be
listed for a variety of issues including engine synchronization
compliance malfunctions. If the ECM or ECM connectivity is unresponsive
for more than 5 seconds, or if the failure cannot be recorded until the
ELD is fully functional again, Table 4 in the appendix outlines how to
capture these malfunctions. These conditions are not expected to be
occurring frequently but FMCSA acknowledges that on occasion that a
malfunction or disconnection anomalies will occur, but still requires
the ELD to adhere to the standard of consistent connectivity expected
of the ELD product.
    In regards to the concern about the aggregate 30 minute period in a
24 hour period, FMCSA believes that this is a generous standard for HOS
compliance. If a driver is concerned about this malfunction, there are
several ways, including a simple pre-boot, to ensure that the ELD is
ready to receive data as soon as the ECM or ECM connection sends it.
Additionally, when an ELD displays a malfunction, the authorized safety
official should be able to see what the problem is and take that into
consideration. There would be enough data in this instance to see what
the issue was, and what the real driving time is. When the engine is
not powered, the ELD does not have to capture data. The 30 minutes
verifies that additional miles and movement has not taken place in the
24 hour period.
    FMCSA clarifies that the ECM data or ECM connectivity data must
only be captured when the engine is powered, but the ELD is not
prohibited from recording information, if desired, when the engine is
off. If the CMV is older than model year 2000, then the driver is not
required to use an ELD. However, if that driver is voluntarily using an
ELD in a vehicle older than model year 2000 with the connections
required in section 4 of the appendix, then the interface should become
active when the engine is on, not just when the switch is turned on.

N. Engine Miles

1. Comments to the 2014 SNPRM
    The SNPRM proposed that engine miles be retrieved from an ECM if
the CMV had an ECM. If a vehicle was older than model year 2000, and
did not have an ECM, then the vehicle miles would have to be derived.
    Zonar stated that there are multiple sources of engine miles.
Because of widespread variability among CMVs with respect to what data
can actually be readily extracted by ELD providers, Zonar believed
FMCSA should consider a version of ELD that substitutes GPS-derived
data (such as mileage) for data that cannot be readily obtained from a
vehicle ECU or a vehicle data bus. Modern GPS fleet tracking devices
can be wired securely and permanently into a vehicle, can be programmed
to uniquely identify individual vehicles, and can provide very accurate
mileage data and truck run time data to validate driver records.
2. FMCSA Response
    Because today's rule is only mandatory for motor carriers operating

CMVs that are model year 2000 or newer, all engine miles must be
derived from the ECM or ECM connection. Synchronization with a
satellite for the receipt of GPS-derived data is not the same as being
integrally synchronized with the engine of the CMV, as required in
today's rule. Engine synchronization for purposes of ELD compliance
means the monitoring of the vehicle's engine operation to automatically
capture data, including: the engine's power status, vehicle's motion
status, miles driven value, and engine hours value.

O. Records Logged Under the Unidentified Driver Profile

1. Comments to the 2014 SNPRM
    The SNPRM proposed that all records logged be recorded on the ELD.
If a driver did not respond to prompts to log in, that time became
unassigned driving time, and would be visible to any authorized safety
official viewing the ELD records.
    Omnitracs stated that it was unclear how to handle unclaimed,
unassigned driving time. It recommended that the persistence of
unclaimed unassigned driving time only be kept on an ELD for 8 days
(maximum duty cycle). After such time, the ELD may delete any recorded
yet unclaimed unassigned drive time. In addition, unassigned driving
time should be sent to any ELD support system (e.g., host system) for
future assignment if the driver does not claim unassigned driving time
on the ELD directly.
    Omnitracs recommended an exception to this requirement in the case
of unit maintenance where the ELD may be completely ``reset'' and all
data purged from the ELD. In this situation, the ELD is allowed to act
as a ``new'' ELD with no driver history. In addition, Omnitracs
recommended that any ELD support system not be required to maintain
this information and then ``push'' back to the ELD post maintenance.
2. FMCSA Response
    All data for the last 8 days, including unassigned driving time,
must be available at roadside. There is no requirement that unassigned
driving time be available at roadside after 8 days. All data older than
8 days can be purged from the ELD, but all data, including unassigned
driving time, must be available to inspectors at the motor carrier's
principal place of business for 6 months.

P. Power-On Status Time

1. Comments to the 2014 SNPRM
    The SNPRM stated that an ELD must be powered within 15 seconds of
the vehicle's engine receiving power and must remain powered for as
long as the vehicle's engine stays powered.
    XRS stated that FMCSA needs to clarify the definition of power on
the device within 15 seconds referencing Fig 1. XRS asked if this is
for internal processing or is this for all input and outputs? There are
portable devices commercially available that can take much longer than
15 seconds to be available; these are tablets, ruggedized handheld
computers, and smart phones that can meet all other ELD recording
requirements. Omnitracs raised the same issue. It stated that a better
solution would be for the system to read and retain data from the ECM;
a 180-second time frame would better accommodate existing hardware that
could have slower cold boot capabilities. Omnitracs and inthinc noted
that the rule does not indicate what ELD functionality is required.
2. FMCSA Response
    As part of the ELD User Guide or a driver Standard Operating
Procedure on proper use of the ELD, FMCSA will recommend that the
driver turn on the engine and then power on and start up the ELD,
before moving the vehicle. However, the requirement remains the same;
the device must receive power within 15 seconds, and the driver should
pre-boot the equipment prior to powering up the vehicle. Similarly, at
power off and shutdown, FMCSA will recommend driver certifications of
records, followed by ELD log off, followed by engine shutdown. By not
following these recommendations, malfunction codes and annotations will
be needed in order to explain unaccounted odometer changes and
suspicious driving activity.
    This 15 second start up time is not unreasonable, compared with
other start up times for similar technology. However, in response to
the concern from commenters, FMCSA extends the requirement to a period
of 1 minute for full functionality in today's rule. Additionally, any
reboots that take longer would already be logged as power diagnostic
events.

Q. Time

1. Comments to the 2014 SNPRM
    The SNPRM proposed that the ELD automatically record the time at
changes of duty status and certain intervals (Sec.  395.26(b)(2)). As
described in the proposed data elements dictionary (proposed section
7.1.39; section 7.40 in this rule), even though time must be captured
in UTC, event records must use time converted to the time zone in
effect at the driver's home terminal.
    Proposed section <IP_ADDRESS>, timing compliance monitoring, would have
required an ELD to periodically cross-check the automatically acquired
date and time with an accurate external UTC source.
    Zonar asked FMCSA to clarify all sections that reference time
format. Zonar commented that it can be very difficult to calculate a
true 24 hours and accurately record time unless there is a one
consistent format; multiple formats cause inconsistencies in data. If
one event needs to be recorded as HH:MM:SS then all clocks within an
ELD need to run on this format. If the HH:MM:SS clock needs to record
an HH:MM for a different event, the commenter asked how the ELD should
handle the seconds--does it round up or down. Zonar asked for specific
examples within guidance to this question and suggested an HH:MM clock
to eliminate the need to round the seconds.
    Eclipse Software Systems stated that it had seen many projects in
the past where storing time in the local format leads to problems,
particularly when at or near daylight savings changeovers. While it is
only 1 hour per year, when daylight savings occurs in the fall, there
are two periods from 1am to 2am. All events during those 2 hours are
ambiguous. It recommended that all times be stored and reported in UTC,
which is what is reported by GPS systems by default.
    Omnitracs stated a concern about recording a qualifying 34-hour
restart. With respect to timing compliance monitoring, Eclipse stated
that aside from GPS, it is difficult to obtain other reliable sources
of the precise time. It has seen cell towers (which are not accessible
from all proposed ELDs) have time stamps that are years off. The ELD
could watch for backdating, if a time stamp from GPS is ever before
another received timestamp from GPS, but other validation would be
quite difficult.
2. FMCSA Response
    In response to comments, FMCSA changes the time to be captured in
today's rule to include seconds. Today's rule requires an ELD to
convert and track date and time--captured in UTC standard--to the time
standard in effect at driver's home terminal, taking the daylight
savings time changes into account. An ELD must record the driver's RODS
using the time standard

in effect at the driver's home terminal for a 24-hour period beginning
with the time specified by the motor carrier for that driver's home
terminal.
    The data element ``Time Zone Offset from UTC'' must be included in
the ``Driver's Certification of Own Records'' events as specified in
section <IP_ADDRESS>. Time must be stored in UTC, and reported in carrier's
local time. If an ELD stored it in a different format that was
translated to UTC, this would be acceptable.
    In today's rule, FMCSA does not require the ELD to record State
time. FMCSA does not believe that it is necessary for the ELD to record
State time for HOS compliance. However, FMCSA does not prevent ELD
providers from including State time as part of a compliant ELD.
    In regard to the comment on timing compliance monitoring, this
section of the rule has been clarified per the requester's suggestion
and the rule no longer requires the ELD to cross check time if it uses
GPS.

R. User List

1. Comments to the 2014 SNPRM
    In section <IP_ADDRESS>.2, the SNPRM proposed that the ELD should
provide a ``user list.'' In chronological order, this user list shows
all drivers and co-drivers with driving time records on the most recent
CMV operated by the inspected driver or motor carrier's support
personnel who requested edits within the time period for which this
file is generated.
    If ELDs are swapped on a CMV, Omnitracs believed that the new ELD
should not be required to know the driver list for the CMV prior to the
ELD being installed in the CMV. XRS stated that FMCSA needs to describe
how this user list would be used at roadside and if there could be a
validation process for its use. Depending on the time of day, there may
be users who will not be in the CMV user list from the support system
due to last time the CMV communicated with the host.
2. FMCSA Response
    For a reset or replaced ELD, today's rule requires data or
documents showing the driver's RODS history in the vehicle. This data
would include the driver's past 7 days of RODS either loaded into the
``new'' ELD or in paper format to be provided at roadside. There is no
requirement that the ELD have a wireless connection.
    In the case of ELDs that include a wireless connection, a user list
must be available up to the date from the last time the CMV or ELD
communicated with the host or back office system.

S. ELD Vehicle Interfaces

1. Comments to the 2014 SNPRM
    In the SNPRM, section 4.2 of the technical specifications proposed
that an ELD must be integrally synchronized with the engine of the CMV.
Engine synchronization means monitoring the vehicle's engine operation
to automatically capture engine's power status, vehicle's motion
status, miles driven value, and engine hours value. An ELD used while
operating a 2000 or later model year CMV, as indicated by the tenth
character in the VIN, that has an engine ECM, must establish a link to
the engine ECM and receive this information automatically through the
serial or Control Area Network communication protocols supported by the
vehicle's engine ECM. The SNPRM proposed that if a CMV is older than
model year 2000 and does not have an ECM, an ELD may use alternative
sources to obtain or estimate these vehicle parameters with the listed
accuracy requirements under section 4.3.1.
    XRS asked FMCSA to clarify if a link to the ECM is the only method
for the ELD to receive information or could information be received
from specific ECUs in the vehicle; e.g., can the ELD interface with
other components on the bus including the instrument cluster and the
vehicle management system. Because there is not Fstandardization on the
OBD that is published with the Society for Automotive Engineers for
odometer and other elements that could be captured, XRS asked what
FMCSA would expect manufacturers to capture for light duty vehicles.
The same commenter wrote that FMCSA needs to coordinate with National
Highway Transportation Safety Administration concerning the
requirements of the capturing of ECM data. For light duty vehicles that
may be required to use an ELD, FMCSA should require providers of OBD-II
to supply proprietary or public information to satisfy the regulation
requirements for ECM data capture. XRS also believed that ECM data
capture of specific OBD-II data requirements may increase the overall
cost of ELD solutions.
2. FMCSA Response
    FMCSA agrees that mandatory transfer through the OBD-II could
require additional information transfer or equipment. In today's rule,
FMCSA does not require drivers of CMVs manufactured before model year
2000 to use ELDs. However, if a driver of one of those vehicles
voluntarily uses an ELD, they must do so in compliance with section 4.2
of the technical specifications in today's rule. As indicated in that
section, if an ELD is being used voluntarily in a vehicle older than
model year 2000, it may use alternative sources to obtain or estimate
the required vehicle parameters with the listed accuracy requirements
under section 4.3.1. However, any CMV manufactured beginning model year
2000 must use an ELD that connects to the ECM.
    FMCSA believes that the ECM or ECM connectivity is the best and
most cost-efficient source of data. However, FMCSA understands that
drivers with non-ECM engines might see benefits from the use of an ELD.
Today's rule requires a reasonable proxy for the data if the ECM or ECM
connectivity is not providing it. So although a connection to the ECM
or ECM connectivity is preferable, voluntary use of an ELD could be
used with any CMV, provided the accuracy specifications are met.

T. Vehicle Miles

1. Comments to the 2014 SNPRM
    Section <IP_ADDRESS> of the SNPRM proposed that an ELD must monitor
vehicle miles as accumulated by a CMV over the course of an ignition
power on cycle (accumulated vehicle miles) and over the course of CMV's
operation (total vehicle miles). If the ELD is required to have a link
to the vehicle's engine ECM (as specified in section 4.2), the ELD must
monitor the ECM's odometer message broadcast and use it to log total
vehicle miles information and determine accumulated vehicle miles since
engine's last power on instance. Otherwise, the accumulated vehicle
miles indication must be obtained or estimated from an accurate source
(within 10 percent of miles accumulated by the CMV over a
24-hour period, as indicated on the vehicle's odometer display).
    XRS suggested that FMCSA define specifics of odometer use that are
acceptable. XRS questioned if the odometer may be used from the
instrument cluster. XRS believed that the proposed method is
inconsistent.
    Zonar stated that heavy-duty vehicles may have more than one
controller on the data bus that provides odometer value in verifying
levels of precision. Zonar suggested pulling the mileage from the dash
as this is more accurate than the engine and is in-sync with what will
be on the dash.
    Eclipse Software Systems stated that it would avoid calculating and
storing the mileages for each on/off pair. It is simpler to record the
odometer at the required intervals (duty status changes and hourly).
The elapsed miles can be

calculated (perhaps by eRODS) for each driving segment (and hour) using
only that data.
2. FMCSA Response
    By definition, an ELD means a device or technology that
automatically records a driver's driving time and facilitates the
accurate recording of the driver's HOS, and that meets the requirements
of subpart B of this part. The data received from the ECM is more
accurate than the data that is displayed on the dash. However, when
there is no ECM or ECM connectivity in the CMV, and an ELD is being
used voluntarily, vehicle miles can be derived from either engine or
dash odometer, provided that method of transfer meets the accuracy
specification in section 4 of the technical specifications. If the
reading of the mileage meets the accuracy specification required in
section 4 of the appendix, although it could be slightly different in
the ECM than on the odometer, the reading ensures the vehicle mileage
data is of value. In the case of large anomalies between the two
readings, the authorized safety official will decide whether further
investigation would be required.

U. Vehicle Motion Status

1. Comments to the 2014 SNPRM
    In section <IP_ADDRESS>, the SNPRM proposed that an ELD must
automatically determine whether a CMV is in motion or stopped by
comparing the vehicle speed information to a set speed threshold. If an
ELD is linked to the ECM, vehicle speed information must be acquired
from the engine ECM. Otherwise, accurate vehicle speed information must
be acquired using an independent source--apart from the positioning
services described under section <IP_ADDRESS>.
    Omnitracs recommended a second distance threshold as an additional
means to automatically detect and transition into driving status. This
commenter believed that simply using a speed threshold could
potentially reduce accuracy in determining an actual driving event.
Ongoing verification of this accuracy would require an alternate source
of speed detection and is not feasible during normal operation. In
addition, Omnitracs believed this level of accuracy (+/-3 miles per
hour tolerance) should only be required at the bottom end of the speed
values used for motion detection and not be required at higher speed
readings (e.g. at 75 mph).
2. FMCSA Response
    FMCSA continues to believe that a speed threshold is the best way
to determine accurate motion. FMCSA declines to create an alternate
threshold that relies upon distance; the data files and the actual
location will show how far the CMV has moved. Any additional threshold
that captures vehicle motion before the speed threshold required by the
rule is met is acceptable. However, as soon as the required speed
threshold is met, the ELD must record, even if the alternate threshold
is not met.
    In today's rule, once the vehicle speed exceeds the set speed
threshold of no more than 5 miles per hour, it must be considered in
motion until its speed falls to 0 miles per hour and stays at 0 miles
per hour for 3 consecutive seconds, at which point it will be
considered stopped. FMCSA has established this requirement to determine
the initiation of vehicle motion, which is at a very low speed of no
greater than 5 miles per hour. The accuracy does not apply to highway
speed.

V. Wireless Electronic Transfer

1. Comments to the 2014 SNPRM
    Proposed section 4.10.1 provided that ELDs must transmit records
electronically in accordance with a specified file format and must be
capable of a one-way transfer of these records to authorized safety
officials upon request. Proposed section <IP_ADDRESS> described the
standards for transferring ELD data to FMCSA via Web services.
    BigRoad stated that section <IP_ADDRESS> describes how an ELD provider
must obtain a public/private key pair compliant with NIST SP 800 32.
Using a private key in this scenario is not ideal since it would have
to be stored on every ELD that might create the email and is therefore
exploitable via memory inspection or code disassembly.
2. FMCSA Response
    All required security measures for data transfer with the Agency,
public or private, will require strict adherence to NIST for all data
in transit or `handshakes' between Government and private systems. DOT
guidelines follow NIST 820. The exact Public Key Infrastructure (PKI)
for ELD data transfers will be distributed once ELD providers register
and certify ELDs.

W. Pre-2000 Model Year CMVs

1. Comments to the 2014 SNPRM
    FMCSA sought comments on issues related to installing and using an
ELD on CMVs manufactured prior to model year 2000. The SNPRM required
all drivers using RODS to use an ELD, regardless of the CMV the drivers
operate.
    The California Construction Trucking Association said that while it
is possible to retrofit an older truck, its research indicates that it
is costly, at about $1,000 per truck in California. In contrast,
Continental stated that it would cost between $100 and $300 per
vehicle.
    For vehicles that do not have a diagnostics port, but have an
electronic speedometer, Continental stated that the ELD can use the
analog speed signal to calculate the odometer and engine hours. This
functionality is already integrated in some existing AOBRDs at no
additional cost. For vehicles that do not have a diagnostics port and
that have a mechanical speedometer (mostly built before 1992),
Continental wrote that a speed sensor must be added to convert the
mechanical signal into an electronic pulse signal.
    XRS stated that the GPS solutions and related costs for black boxes
could have an incremental cost of $250 per vehicle.
    PeopleNet stated that obtaining speed from a source other than the
ECM or GPS will be very complex and cost-prohibitive. When a connection
to the ECM is not available, it recommended that GPS be used to
determine vehicle speed. The commenter wrote that non-GPS options to
determine vehicle speed include ranging laser, accelerometer,
revolution counter (tire); or camera. PeopleNet did not believe any of
these options could ensure accuracy within (plus or minus) 3 miles per
hour of the CMV's true ground speed.
    Zonar supported using GPS-based ELDs for older CMVs. It stated that
modern GPS fleet tracking devices can be wired into a vehicle, be
programmed to identify individual vehicles, and provide very accurate
mileage data and truck run-time data.
    The Truck and Engine Manufacturers Association raised questions
about whether FMCSA was referring to model years or calendar years. The
commenter believed that the additional requirement that the engine
actually have an ECM is crucial in the event that a mechanically
controlled engine was installed in a vehicle with a model year 2000 or
later.
    One carrier stated that OBD-II ports data could not be shared if
they are already dedicated for another purpose. Another problem is that
there are five different protocols used in OBD-II and the software is
proprietary to the vehicle manufacturer. This would require the vehicle
manufacturer to release their software to use the OBD-II to capture the
necessary data effectively.

2. FMCSA Response
    When FMCSA developed the technical specifications, the Agency
considered whether ELDs could be easily installed in the full range of
CMVs operated by drivers subject to the HOS requirements. The Agency
determined that the most practical and cost-effective means of
achieving compliance is the use of the ECM or ECM connectivity or OBD-
II ports. Generally, these options are available in all the vehicles
manufactured beginning with model year 2000 and on many pre-2000
vehicles. After reviewing the comments in response to the SNPRM, the
Agency believes that imposing a requirement for ELDs on pre-model year
2000 vehicles is not feasible in all cases and that trying to
distinguish when it is a viable option is too difficult in this
rulemaking and next to impossible at the roadside.
    Some private-sector publications, such as the IHS Inc.'s March 2014
publication ``Quarterly Commercial Vehicle Report,'' suggest that the
population of pre-2000 Class 3 through Class 8 CMVs (CMVs with a gross
vehicle weight rating greater than 10,000 pounds) is approximately 35
percent of the registered CMVs in operation (4,178,000 pre-2000 versus
7,723,000 2000-current). These vehicles will have been in operation
more than 17 years by the compliance date of this rule. Therefore, the
percentage of these vehicles operated by drivers who are required to
use ELDs is likely to be small.
    The Agency decided not to use alternate technology for vehicles
without ECMs, ECM connectivity or OBD-II ports. While FMCSA is aware
that there are technologies that would make this possible, it does not
mandate their use. In the RIA for today's rule, FMCSA estimates that
there will be approximately 209,000 pre-2000 model year vehicles in
2017. FMCSA has decided to exempt this relatively small population of
CMVs.
    Concerning the comment from XRS, part 395 does not require black
boxes nor is there anything in the SNPRM related to `black box'
modification. Each ELD provider supports proprietary communications via
satellite, code division multiple access or CDMA, Bluetooth, etc. The
market dictates these products and their communication needs.

X. Authenticated User and Account Management

1. Comments to the SNPRM
    Section 395.22(b)(2)(i) of the SNPRM would have required that the
motor carrier actively manage the ELD accounts. The motor carrier would
have to include certain identification data elements in the ELD user
account assigned to a driver (Sec.  395.22(c)). These data elements
include the driver's license number and the name of the State that
issued the license. Under the proposal, the motor carrier assigns the
ELD username during the creation of a new ELD account (Sec.
395.22(b)(2)(ii)). As proposed, the ELD username is any alphanumeric
combination, 4 to 60 characters long, but it cannot include either the
driver's license number or social security number. The SNPRM also
proposed adding unique authenticated-user profiles for all users of the
ELD and its support system, to increase transparency and responsibility
between a motor carrier and its drivers, as well as to prevent
fraudulent activities.
    Commenters expressed concern with the requirements for user names.
FedEx stated that it is too restrictive. Because current usernames are
sufficiently identifying drivers, FedEx suggested that FMCSA expand
this requirement to allow ELD users to set the format of their own
usernames. Concerns about the creation of multiple aliases for a single
driver could be addressed via DOT compliance reviews.
    FedEx stated that the requirement does not accommodate all motor
carrier structures. FedEx suggested that the user rights management
rule require that ELD accounts are managed appropriately and that the
motor carrier is responsible for any failures. With the carrier
ultimately responsible, the rule need not dictate who must manage the
account.
    ATA stated that FMCSA should consider alternatives that accomplish
the same objectives and include the same protections against fraud.
This alternative would prevent carriers and providers from having to
implement new systems to assign identifiers based on CDL numbers.
    Saucon Technologies stated that requiring drivers to enter their
entire CDL number and State presents some technical challenges. Many
existing ELD solutions do not provide the ability to enter alphabetical
characters, only numeric characters. Requiring the name of the State
and entire CDL number would necessitate new hardware and increase the
time required for drivers to sign on. Schneider asked for clarification
on what proper identification data are as they relate to logging into
an ELD.
    AGC stated that in its industry multiple drivers--including
temporary employees--may use a vehicle. FMCSA should establish a more
secure means to identify the driver operating the vehicle and tie the
resulting ELD records to that driver.
    Several commenters stated that the requirement that a person have a
single role (driver or support person) fails to accommodate smaller
carriers where there is no support staff and the driver/owner fills
both roles.
    BigRoad stated that proposed section 7.1.13 (7.13 in this rule)
indicates that a person who is both the driver and the support person
would need to maintain two separate accounts in the system, since each
account can only be given a single role in the ELD account type field.
That person would have to switch between accounts to perform different
functions on the same system, creating an unnecessary administrative
burden. XRS, Omnitracs, inthinc, and Zonar also raised this issue. XRS
asked if account creation can be performed on the host and if the
credentials can be stored on the host.
    Zonar asked how a driver can certify his or her records at the end
of a 24-hour period if the driver has gone off duty for multiple days.
It suggested allowing the driver to confirm the records on the driver's
return to duty.
    Section 395.32(c) describes the carrier's responsibility to review
unidentified driving records; however, it does not establish an
expectation for when the motor carrier must complete the review.
Schneider recommended that the rule specifically state the number of
days a carrier is allowed to research and assign the unidentified
driving segments or annotate the record explaining why the time is
unassigned. Because the carrier has to make contact with the driver or
research if the tractor was moved by maintenance, one commenter
believed that 8 days is a reasonable time frame to allow for this
research to be done.
2. FMCSA Response
    FMCSA acknowledges commenters' concerns, but emphasizes that the
rulemaking does not impose the types of restrictions on usernames and
passwords that the commenters described. Section 4.1.2 of the appendix
to part 395 covers account creation with the explanation that each
driver account must require the entry of the driver's license number
and the State of jurisdiction that issued the driver's license into the
ELD during the account creation process. The driver's license
information is only required to set up the user account and verify the
identity of the driver; it is not used as part of the daily process for
entering duty status information.

    There may only be one user account per driver's license number and
the carrier would be responsible for establishing requirements for
unique user identifications and passwords. Therefore, the burden that
commenters believed would be imposed by the rule was not intended and
indeed is not a requirement in this rule.
    This rule does not differentiate between temporary and permanent
employees, nor does it affect how many drivers may use a CMV. Each
motor carrier that assigns a driver to operate a CMV under its DOT
number must establish and manage an ELD user account for that driver.
    Each driver should have one account that allows him or her to login
and perform driver-related functions specific to the driver. All other
administrative functions should be based on the discretion of each
company or its provider. This means a driver who is also the owner of
the company would have a single account authorizing entries as a
driver, and a separate account for administrative functions. Accounts
can be created on the ELD or the ELD support system.
    In response to Zonar's comments, FMCSA emphasizes that a driver
only needs to certify his or her records for each 24 hour duty status
period he or she is on duty. This is the case under the HOS rule and
the ELD rulemaking does not alter the duty status requirements under
the HOS rule. The ELD would allow the record to be confirmed as off-
duty when the driver returns to duty. There is no prohibition on a
driver certifying multiple days off on a single RODS. And, in the case
where the driver has Web-based access to review the records and make
certain edits or entries, the rule does not prohibit the driver from
logging into the system to provide updates on the duty status when
there are multiple days away from the CMV. This is also a means for
drivers employed by more than one motor carrier to update records
between carriers.
    Regarding the issue of providing carriers enough time to audit
electronic RODS and make corrections, FMCSA does not place limits on
when an annotation or correction may be made. The motor carrier must
maintain the original record so that authorized safety officials can
compare the chronology with the annotations and corrections, and
supporting documents.

Y. ODND Time

1. Comments to the 2014 SNPRM
    The existing HOS rules require a driver to record in his or her
RODS any ODND time, even if it is not in the truck (see Sec.  395.2,
On-duty time). The SNPRM did not propose any changes to this underlying
HOS requirement.
    Saucon Technologies, XRS, Zonar, and PeopleNet suggested that FMCSA
clarify how ODND time is to be managed when the driver is not at the
truck. PeopleNet stated that many customers use payroll integrations to
put their drivers on duty (i.e., when the driver swipes the time clock,
it puts the driver on duty via the AOBRD). Payroll integrations also
allow administrators to put a group of drivers on duty to account for
time spent at a safety meeting.
2. FMCSA Response
    FMCSA emphasizes that today's ELD rule does not change the
underlying HOS requirements. The ELD automatically captures the date,
time and location when the vehicle is turned on and turned off, when
someone starts to drive the vehicle, and when the individual stops
driving. The system also captures automatically the date, time and
location when manual entries are made so that the driver's location and
time are captured when manual entries (such as on-duty, not driving, or
sleeper berth) are entered. An ELD system relies upon the driver to
enter information about the duty status when the vehicle is stopped or
parked. The ELD captures the same duty status options that are
available to drivers currently relying upon paper RODS. The technical
specifications do not prevent supervisors from having administrative
rights to add ODND time onto drivers' ELD records.
    With regard to time a driver may spend working for another
employer, the time must be counted as on-duty time, either driving or
not driving. This is required by the current HOS rules, and the ELD
mandate does not change this fact. The ELD system mandated by this rule
provides drivers with the ability to update their RODS to account for
time the device is not capable of generating automatically.

Z. Data Transfer

1. Comments to the 2014 SNPRM
    The SNPRM used a menu-style approach, and several of the compliant
options would have required wireless connectivity. The SNPRM proposed
that all ELDs would need to use one of seven combinations of USB 2.0,
printouts of QR codes, TransferJet, wireless Web services, Web email,
and Bluetooth for the electronic transfer of data to authorized safety
officials. One alternative included a printout. The SNPRM also required
an ELD to be able to present a graph grid of the driver's daily duty
status changes either on a display unit or printout.
    Omnitracs stated that the SNPRM's technical requirements for data
transfer mechanisms, and the options provided, use technologies that
are not easily adaptable or readily available for enforcement to
deploy. The IME generally supported requirements to ensure that the ELD
would be able to communicate with officials at roadside.
    IFDA stated that the requirement that systems use a ``standardized
single-step driver interface for compilation of driver's ELD records
and initiation of the data transfer to authorized safety officials . .
.'' is unnecessary and overly prescriptive. Many devices currently in
use require the driver to perform more than a single step to display
the information. These systems do not pose a significant burden for
drivers or authorized safety officials and do not appear to compromise
safety in any way. IFDA opposed the requirement for a graphic display
or printout, and they felt that these unnecessary requirements would
add additional costs without any commensurate safety value.
    CVSA believed that the regulation should require a practical
standard interface for manual roadside inspections: ``A requirement for
a printout of the HOS graph grid showing the same information contained
in the paper logs is a proven, reliable, and cost-effective technical
solution that would significantly enhance the enforceability of the
regulation.''
    PeopleNet stated that providers should have to support only one
primary and one secondary method.
    Boyle Transportation recommended FMCSA require support systems for
ELDs, use Web services exclusively, allow display mode for inspections,
and limit electronic submissions.
    A rural transit provider stated that connectivity is not available
in many areas, so Internet and cellphone reception is not possible.
ELDs that rely on such connectivity are not viable.
2. FMCSA Response
    In consideration of the comments, FMCSA revised the data transfer
options, by establishing two options for electronic data transfer
(option one is a telematics-type ELD with a minimum capability of
electronically transferring data via wireless Web service, and email;
option two is a ``local connectivity'' type ELD with a minimum
capability of electronically transferring data via USB 2.0 and
Bluetooth). Additionally, both types of ELDs must be capable of
displaying a

standardized ELD data set in the format specified in this rule via
printout or display to an authorized safety official on demand. FMCSA's
changes address comments and concerns about the types of data transfer,
as well as provide flexibility for providers and motor carriers looking
for ELDs to suit different business needs and costs. These changes are
discussed in more detail in the next few sections.
    Although areas within the United States where data connectivity is
not available are shrinking, FMCSA understands that some areas of the
country do not have such access. Today's rule allows for alternative
methods of data transfer including Bluetooth and USB 2.0. Where data
transfer is not practical, the driver can still show enforcement
compliance via a printout or the ELD display. Due to potentially
hazardous conditions (i.e., weather, traffic, etc.) during roadside
inspections, authorized safety officials may ask drivers to hand them
their ELD outside of the CMV so that they may examine the ELD display
of data at a safe distance outside of the CMV. Absent a printout, an
ELD must be designed so that its display may be reasonably viewed by an
authorized safety officer without entering the CMV.

AA. USB 2.0

1. Comments to the 2014 SNPRM
    J.B. Hunt, Continental, and PeopleNet supported USB 2.0 as a method
to electronically transfer data due to its low cost, and ease of
deployment without complex IT infrastructure nor any monthly
communication and service fees. With appropriate security software on
the USB 2.0 device, J.B. Hunt wrote there could be safeguards to avoid
transmission of malware. Eclipse Software Systems recommended requiring
``at least one'' USB 2.0 port on ELDs.
    In contrast, the National School Transportation Association (NSTA),
BigRoad, Omnitracs, inthinc, and Drivewyze Inc. (Drivewyze) did not
fully support USB 2.0 as a required backup method for the electronic
transfer of data due to future hardware design constraints, security/
encryption concerns, lack of availability of connections on computers,
and probable obsolescence. J.J. Keller and Associates, Inc. (J.J.
Keller) noted that requiring a specific technology, such as USB 2.0,
constrains the hardware design to meet the specifications. This will
likely cause more frequent upgrades in hardware to adapt to more modern
USB 2.0 flash devices, increasing cost to industry. Inthinc recommended
that the rule state that USB transfer is specifically for a drive--not
for just a cable--and that the USB 2.0 port on the ELD can be an
accessory to the ELD.
2. FMCSA Response
    FMCSA believes that USB 2.0 is a cost-effective, technically viable
option for many authorized safety officials to obtain an electronic
data file from an ELD. The Agency acknowledges that some States have IT
security--related restrictions that would preclude their officers from
relying on USB 2.0 drivers or USB 2.0 connections to the ELD as a means
of retrieving the RODS information. This information was presented
during the MCSAC's session concerning ELD technical specifications. The
Agency continues to believe it should be included in the list of
options for making data files available to roadside inspectors. It is
not expected that this option would be used by every State, but
retaining a range of capabilities required on the driver side,
including USB 2.0 capability, will help to ensure flexibility for the
enforcement community. In the SNPRM, the USB 2.0 as a part of almost
every option for an ELD. In today's rule, the USB 2.0 is a requirement,
along with Bluetooth under only the ``local data transfer '' option,
meaning that it would be possible to have a compliant ELD that did not
have USB 2.0 if the telematics-type ELD is selected for use.
    In regard to USB standards becoming obsolete, that is the case with
any technical standards irrespective of whether the standards are
referenced in a rulemaking. The criticism of the USB 2.0 standard not
being widely used by authorized safety officials is no longer relevant,
given that authorized safety officials will have the option, under
today's rule, to utilize Bluetooth instead of USB 2.0 for electronic
data transfer.

BB. Wireless Data Transfer Through Web Services

1. Comments to the 2014 SNPRM
    PeopleNet recommended using a Web Service as a primary electronic
data transfer method, while Continental supported it as an option, but
not a mandate.
    BigRoad recommended eliminating wireless data transfer through Web
Services to simplify inspection requirements. Omnitracs stated there is
a need for clarification around the use of the public/private keys in
this section, including security provisions and the process for
refreshing the public/private keys as a part of security best
practices.
    Inthinc recommended Representational State Transfer (REST), noting
that Simple Object Access Protocol (SOAP) is much more difficult and
expensive to implement, and it is becoming archaic.
2. FMCSA Response
    FMCSA believes that Web Services will be a viable data transfer
option for telematic ELD providers. SOAP is a standards-based Web
services access protocol utilized for telematics data transfers.
Therefore, today's rule retains Web Services as a valid method of data
transfer, one of the two methods described in section 4.9.1(b) to
transfer data as part of the telematics option, along with wireless
email.
    FMCSA has clarified the public/private key in section <IP_ADDRESS>. of
the technical specifications of this rule.

CC. Wireless Services via E-Mail

1. Comments to the 2014 SNPRM
    J.B. Hunt and inthinc supported email as a viable, low cost option
for electronically transferring ELD data. Inthinc believes that ELDs
could have all inspection station email addresses pre-programmed or
ELDs could automatically send emails to these addresses upon entry to
inspection stations. Continental supported it as an option, but not a
mandate.
    Drivewyze said that this option is redundant with Web services and
could be cut. BigRoad recommended eliminating this option to simplify
inspection requirements.
    Omnitracs stated there is a need for clarification around the use
of the public/private keys, including security provisions and the
process for refreshing the public/private keys as a part of security
best practices.
2. FMCSA Response
    Today's rule allows the use of email as a part of the telematics
ELD specifications in section 4.9.1(b) of the appendix to part 395,
along with Web services. FMCSA does not believe it is redundant because
it provides a way for enforcement to access the data without using
FMCSA or other government systems. Authorized safety officials could
use either Web services or wireless email to verify ELD data from an
ELD with this telematics option.
    FMCSA agrees that inspection stations and other enforcement
Agencies could post or share a standardized email address but does not
require this. FMCSA believes a benefit of transferring ELD data to
authorized safety officials by email is a viable method to submit data
to the officer if necessary.

    FMCSA clarifies the public/private key requirements in
<IP_ADDRESS>(4)(b)(2) of the technical specifications.

DD. Bluetooth

1. Comments to the 2014 SNPRM
    Drivewyze recommended Bluetooth as a viable data transfer option.
Continental supported it as an option, but not a mandate.
    J.B. Hunt noted that Bluetooth transmissions are short-range, which
would limit the effectiveness of this technology. Eclipse was concerned
about Bluetooth personal area network in the roadside environment,
commenting that Bluetooth has a typical operating range of 30 feet.
Many officers use laptops mounted in their patrol vehicles, which sit
behind the truck and a 52-foot trailer, making reception from the
patrol car cab unlikely.
    Verigo and inthinc disagreed with including Bluetooth as a means of
electronic data transfer. Garmin Ltd. (Garmin) believed the description
of transferring ELD records using the Bluetooth transfer method in
section <IP_ADDRESS> should be further clarified.
    Once the connection is successfully established, this section
indicates that the ELD must connect to the official's technology via
wireless PAN and transmit the required data via Web Services as
described in section <IP_ADDRESS>. Garmin wanted FMCSA to consider the case
where the official's device cannot connect to the internet. In this
scenario, it will also be possible to transfer the ELD records directly
to the official's device over Bluetooth.
2. FMCSA Response
    FMCSA included Bluetooth as part of the local data transfer ELD
option specifications in section 4.9.1(b), along with USB 2.0
connectivity. FMCSA acknowledges that Bluetooth has its limitations as
all technologies do, but, it is a widely used, reliable, short range
non-telematic data transfer method.
    In today's rule, FMCSA changed the language in 4.10 to clarify the
fact that the Bluetooth transfer does not occur via telematics, as was
written in the SNPRM. If a driver is using a local data transfer method
and the officer cannot accept the data for some reason, the officer has
the ability to request the data in the form of a display on the ELD or
a printout, depending on the type of ELD.
    FMCSA does not agree with the commenter who stated that Bluetooth
is not designed for this type of transfer; the mechanism for data
transfer does not distinguish between the types of data being
transferred.

EE. QR Codes and Transfer Jet

1. Comments to the 2014 SNPRM
    Overall, none of the commenters supported QR codes or TransferJet
as feasible solutions for electronically transferring ELD data for the
purposes of roadside enforcement.
    Omnitracs, PeopleNet, XRS, inthinc, and Drivewyze did not believe
that QR Codes are a viable ELD data transfer option at roadside.
Omnitracs wrote that typical drivers would need to present between 6
and well over 30 QR codes that must be scanned by an authorized safety
official in the proper order, which does not seem to be realistic in
the field. Issues with screen size, screen resolution, the type of
scanner (camera versus laser), and the amount of data that needs to be
transferred adversely impact the ability of an authorized safety
official to successfully scan the QR codes. Drivewyze stated that on-
screen QR codes cannot be scanned, and printed QR codes are redundant
with printing grid graphs. As a result, QR codes were recommended to be
removed as an option.
    Drivewyz, BigRoad, PeopleNet, Continental, and J.B. Hunt questioned
the feasibility of TransferJet as a viable method of electronically
transferring ELD data to roadside officials. J.B. Hunt, XRS, and
Drivewyze noted that TransferJet is not a mainstream technology.
PeopleNet and XRS also stated that TransferJet is not widely used
except in smartphones; and that there are limited suppliers of products
to support current architectures. BigRoad noted TransferJet has no
encryption mechanism built into the link layer; for security, the
transmission should be encrypted. Continental pointed out that the
TransferJet technology is not used today in either automotive or
commercial vehicle applications and should be removed from the list of
options.
    PeopleNet stated that TransferJet requires the purchase of
additional hardware, which FMCSA did not take into consideration in the
cost analysis. In addition, commenters were concerned that many
suppliers would need to make modifications at the operating system
level to take advantage of the new hardware. Commenters contended this
solution would be prone to failure due to discrete hardware components,
and increase both carrier and supplier support costs due to this sole
source solution.
2. FMCSA Response
    FMCSA agrees with the commenters' technical and practical concerns
about both QR codes and TransferJet technology as not being viable
means of transferring electronic ELD data. Therefore, today's rule does
not include QR codes nor TransferJet technology as options for
electronically transferring ELD data to authorized safety officials.

FF. Other Communications and Technology Options

1. Comments to the 2014 SNPRM
    Garmin, J.B. Hunt, and Eclipse recommended use of Wi-Fi as an
additional primary transfer option. Similar to using Bluetooth, Garmin
wrote that Wi-Fi would enable the ELD to connect to the authorized
safety official's device via the local area network at the inspection
site. Alternatively, the Wi-Fi connection at the inspection site could
be used to transfer the ELD records via Web Services. Commenters
pointed out that Wi-Fi range is larger than the very short range within
which Bluetooth devices communicate, and it supports higher data
transfer speeds. Wi-Fi technology has the means to support the setup of
security-enabled networks where users can view available devices and
request a connection, or may receive an invitation to connect to
another device.
    Garmin recommended that an additional alternative method to
consider is the transfer of ELD records using a secure digital (SD)
card, that is via a microSD card and optional microSD to SD memory card
adaptor. The requirements for authenticating the driver, the ELD
system, and the official's hardware when using the USB 2.0 method can
continue to be realized and supported.
2. FMCSA Response
    FMCSA does not prohibit the use of a Wi-Fi device for intermediary
transfer, but the data transfer to an authorized safety official must
occur in accordance with the technical specifications. Data transfer to
an authorized safety official must occur through wireless email,
wireless Web services, USB 2.0, or Bluetooth. This is because
implementation of another option would necessitate hardware changes for
ELDs and would also increase the risks of conflicts between the
regulatory options and the IT security regulations policies that FMCSA
and its State partners must follow.

GG. Data Reporting During Roadside Inspections

1. Comments to the 2014 SNPRM
    CHP stated that a data exchange may present cross connectivity
issues when using a portable computer for ELD dataset exchange because
of the threat of

computer viruses and malware, issues associated with encryption
software, regional connectivity issues, operating systems
compatibility, and data transfer best practices. Therefore, enforcement
will continue to consist of an official physically observing the data
on a device's electronic display.
    Omnitracs stated that Option 1 presented in Table 5 has no backup
mechanism should the printer become disabled, and all other options
require two separate backup mechanisms. Inthinc recommended that the
regulation state that authorized safety officials are mandated to
accept whichever of the seven methods of data transfer that the ELD
provider has opted to support.
    EROAD recommended that FMCSA consider implementing a simple generic
report format as a transition to using eRODS software. FMCSA could
require the ELD solutions to generate and send enforcement data not
only in a raw data format, but also in a simple generic report format--
an enforcement view of the ELD data/records. This could be a secure PDF
file with a small number of relevant statistics. This option will be
easily implemented in the interim while States adopt eRODS software,
and such a report could be viewed on any device with ability to read
PDFs. Because ELDs will have the capability to send raw data, the
States will always be free to adopt eRODS software and develop or
procure additional software to display the information in their own
way.
    BigRoad stated that the only requirement is that ``an authorized
safety official will specify which transfer mechanism the official will
use,'' meaning that they can select any of the backup methods without
supporting the primary method themselves. In particular, this could
mean that although a device supports a primary mechanism such as
Bluetooth, the safety official might only ever choose the backup USB
2.0 mechanism. The SNPRM provides no guidance or requirements for data
transfer support on the devices used by authorized safety officials.
BigRoad also stated that inspections should require that the ELD
information be shown on the display of the ELD. Verigo stated that the
SNPRM provided too many options. The backup method of file transfer
from the ELD in CSV format should be limited to USB 2.0, QRC, or NFC.
Advocates cautioned against allowing the introduction of any
unnecessary intermediaries in the process of maintaining and
transferring HOS data. To prevent data corruption, the Agency must
require that the most recent 24 hours as well as the previous 7 days of
operation be stored in the ELD for immediate transfer to officers at
the roadside. Advocates acknowledged the check value calculations, but
did not believe that this limited security feature will thwart
determined efforts to evade compliance. Advocates recommended that the
Agency establish security features, which would be shared with
certified manufacturers and shielded from those subject to the HOS
requirements, namely drivers, carriers, and third parties servicing
those groups.
2. FMCSA Response
    FMCSA believes the SNPRM presented an appropriate number of options
for making the HOS data available to authorized safety officials. While
various commenters had substantive technical concerns about the
options, the Agency continues to believe that--with the exception of
TransferJet technology and QR codes--the proposed options remain viable
and cost-effective. However, FMCSA does believe that limiting the
combinations of data transfer types to two types, local and telematics,
and combined with a backup option, will make the data transfer to
authorized safety officials clearer. FMCSA believes that today's rule's
data transfer mechanism options suit the needs of many business
operations of motor carriers, the daily needs of drivers, and the needs
of authorized safety officials as well. Additionally, all ELDs are
required to have a backup method for the authorized safety official to
verify HOS compliance. FMCSA also believes that by not prescribing one
specific standard, cost is kept lower and providers can provide ELDs
that are able to meet the requirements of this rulemaking, including
the security standards.
    The Agency considered IT security concerns and the potential need
for additional hardware to implement the options. FMCSA does not
believe that there are concerns about cross-connectivity and security
concerns about portable devices. All ELDs will meet the same minimum
standards; there is no reduction in security for portable devices.

HH. Data Transfer Compliance Monitoring

1. Comments to the 2014 SNPRM
    Drivewyze requested clarification on the scope of a data transfer
test given that this test may occur without the presence of a receiving
roadside inspection system or that the receiving system may only
support a limited number of transfer mechanisms. Without a full suite
of connectivity tests that cover all transfer mechanisms, there can be
no confirmation of compliance beyond a test that only monitors the
ability to send data, not its successful receipt by third party
systems.
    BigRoad stated that data transfer mechanisms are only truly
verifiable when there are two endpoints to transfer between. It is
unclear how either the ELD or the driver could verify transfer
mechanisms without extra hardware components to act as one of the
endpoints in the pair. BigRoad commented that some clarification of the
extent and character of verification is needed.
    Omnitracs recommended removing the self-monitoring requirement on
the primary data transfer mechanism. To fully verify primary data
transfer mechanisms, the ELD would require (1) two Bluetooth radios to
test, transmit, and receive (in the case of Bluetooth); and (2) two USB
2.0 connections and an interconnect cable to test, transmit, and
receive over the USB 2.0 connections (in the case of USB 2.0). Since
there are both primary and backup transfer mechanisms, this added
hardware expense and complexity is not feasible.
2. FMCSA Response
    FMCSA believes the data transfer options provide a practical way to
provide RODS information to authorized safety officials. It is expected
that the ELD providers will be testing data transfer options before
certifying their devices with FMCSA. If the authorized safety official
is unable to receive or open the electronic file, this would not, in
and of itself suggest that the ELD system that transmitted the file was
non-compliant. The driver would then need to present the RODS
information to the authorized safety official at roadside, either on a
display screen or a printout. FMCSA does not remove the requirement to
self-monitor.
    FMCSA will use its Web site to accommodate ELD testing in support
of today's rule. This site will accommodate provider registration,
allow approved ELD providers to register their device with the Agency
and act as single source site for: ELD registration keys,
authentication keys, authentication files, data formatting and
configuration details and data testing (end to end) with approved third
parties. This site will also include an ELD Interface Control Document,
specifically written for ELD providers and service providers.
    FMCSA is currently in the development stage of modifying this site
in preparation for today's rule and plans to have a registration site
available and operational for ELD providers by rule's effective date.

II. Printing

1. Comments to the 2014 SNPRM