This guide is intended for telematics service providers, tachograph workshops, and fleet managers.
The following describes the requirements that must be met to ensure smooth communication between the telematics unit and the VDO DTCO.
Access from telematics units to DTCO to data
For installed fleet management systems, the DTCO offers four types of messages/protocols that FMS can use:
1. Cyclic CAN messages: The DTCO sends cyclic CAN messages such as time/date or VDO counter messages that can be read by an FMS
2. Diagnostic data
3. D8 info interface
4. Remote download data
List of abbreviations
DSRC: Dedicated Short Range Communication
DTCO: Digital Tachograph
ECU: Electrical Control Unit
FMS: Fleet Management System
ITS: Intelligent Transportation Systems
UDS: Unified Diagnostic Services (according to ISO14229)
UN: United Nations
UTC: Coordinated universal time
In this guideline the term “telematics unit” and “fleet management system” are used interchangeably.
Introduction:
A digital or smart tachograph record driver activities as well as vehicle data. Data is stored on a driver card as well as in the mass memory of the tachograph. Local access to this data is possible through various interfaces, e.g. front interface, via Bluetooth (ITS interface) or CAN bus. However, data can also be accessed remotely in conjunction with a telematics unit which supports certain data protocols. In particular, remote download of driver card and mass memory is a very efficient procedure to archive data which is required from tachograph regulation point of view.
Data download from the individual driver card is required latest every 28 days (monthly) and the mass storage of the digital tachograph unit must be downloaded latest every 90 days (every quarter of a year).
Additionally, archived files must be held at the disposal of the authorities for a full year.
Moreover, fleet operators want to track vehicle data as well as driver activity data which is also feasible in conjunction with a FMS.
General overview
Overview on interfaces
Generally speaking, the DTCO provides wire bound as well as wireless interfaces in order to get access to vehicle and driver related data.

Data interfaces of a DTCO
CAN 1 is usually connected to the vehicle network, e.g. instrument cluster. CAN 2 is usually reserved for telematics units, but may also be used for tachograph related ECUs, like a CAN–DSRC module.
Moreover, the DTCO offers a (legacy) Info interface via pin 8 which provides a defined set ofparameters for FMS.
Data can be accessed wirelessly via Bluetooth ITS interface. This interface supports UDS as well as remote download (requires license).
Finally, UDS, local and remote download services are provided via the DTCO front interface.
Cybersecurity
Some vehicle manufacturers offer wire bound access to the DTCO only via a dedicated fleet management interface which is operated behind a security gateway. Avoid bypassing the security gateway as the Cybersecurity type approval of the vehicle may no longer be valid in this case.
Data interfaces
Security gateway in a vehicle architecture
Access to data
For installed FMS, the DTCO offers four types of messages /protocols FMS can make use of:
▪ Cyclic CAN messages: The DTCO sends out cyclic CAN messages like Time/Date or VDO counter messages which can be read by a FMS. Usually the number of parameters in cyclic messages is lower than data provided via UDS interface.
▪ Diagnostic data (UDS): The FMS has to actively request data and the DTCO responds to these requests. This is the preferred way to get access to detailed vehicle and driver related data.
▪ D8 Info interface: This is a legacy interface which will no longer be supported in future DTCO releases. The Info interface is a unidirectional interface, where the DTCO periodically broadcasts some fleet management related information (27 parameters in
total).
▪ Remote download data: Remote download is a peer to peer communication between a digital tachograph and a remote download terminal at the fleet company. The FMS acts
as a client and the DTCO as the server. In order to access remote download data, an authentication procedure in conjunction with the company card which is inserted in the remote download terminal is required.
Note that remote download provides a secured link between the DTCO and the remote download terminal. In order to secure the other data, encryption/signing has to be carried out
by the telematics unit prior to data transmission to the Internet.
Recommendations for robust system design
▪ Avoid any authentication process close to and after UTC lunch time (12.00) and midnight (24.00/00.00)
Why?
The DTCO needs to perform - defined by legislation – a lot of different checks, especially self and cross checks in its memory and controller system. So please avoid any remote authentication or remote download at least 10min. before and 10 minutes after.
▪ Avoid multiple remote downloads per hour. Instead, if you want to download driver card data, make sure that you do not start the remote download process more than once hour. This ensures that the DTCO has sufficient time to complete a potential interrupted
download from a previous session.
▪ Do not install more than one telematics unit in the vehicle.
Why?
Both devices may not interfere each other which may lead to permanent authentication procedures. In the worst case this leads to either ejected driver cards while driving or blocked card ejections.
▪ Check if the vehicle has a dedicated fleet management interface which can be used to connect the external telematics unit to the vehicle network.
▪ Some vehicle manufacturers do not allow a direct connection of a telematics unit with a tachograph due to the vehicle Cybersecurity architecture. In the worst case, the vehicle may lose its Cybersecurity type approval and must not be operated on public roads. The respective regulation is UN R155.
▪ We strictly expect that any remote authentication will be closed after a successful download of data. We need to take care, that the vehicle battery capacity in the truck will not be unduly discharged and the DTCO can go into sleep mode.
▪ For track and trace as well as driver activity monitoring, do not use remote download function. Instead, use UDS commands (e.g. read data by identifier) or evaluate cyclic messages that are transmitted on the CAN bus.
Why?
Remote download is intended for archiving purposes, i.e. archiving driver card data as well as tachograph mass memory. A remote download requires a stable internet connection usually for more than 10 minutes.
▪ If possible, avoid any driver card download when vehicle is moving.
Why?
When a DTCO driver card download is requested, the DTCO has to write and read the driver card. So, any side effect like vehicle vibration during drive or a longer disconnection, can influence the ongoing process and in the worst case result in an unforeseen card
ejection. Note: this does not have to be considered for any mass memory download.
▪ Train the drivers to keep the DTCO card slots clean and also avoid any dirt on the chip card contacts. Card cleaning kits can be found in the VDO web shop or at the VDO dealer.
▪ Avoid that a driver card is inserted for more than one week in a DTCO. Be sure that at
minimum once per week the card gets ejected in order to avoid any physical contact insulation.
▪ Make sure that data privacy is respected. Only if the (co-)driver has given his consent,data can be transmitted outside the cabin. DTCO provides parameters which contain the driver or co-driver consent information.
▪ No card can be ejected from the DTCO during a remote download. If a driver nevertheless requests his card, the tachograph responds with error code 34. This error code is only a user note and does not represent a device error.
Links:
FMS Standard Website: https://www.fms-standard.com/Truck/index.htm