Remote Tachograph DDD File Delivery: What the Receiving System Must Confirm
A remote tachograph DDD file can be successfully downloaded and still be absent from the system that must use it. This checklist defines the handoff: preserve the original signed file, identify its scope, name the target system and API responsibility, then retain receipt and audit evidence.
On this page
- Download success is a source-side event. It does not prove that a named receiving system received, validated or accepted the file.
- The original signed file, its identity and the minimum metadata should travel together. Parsing or renaming must not erase the source artifact.
- Delivery ownership, receipt evidence, duplicate handling and status unknown belong in a reusable handoff matrix; retention remains a project/legal-policy decision.
Download success is not delivery
There are two distinct events in a remote tachograph workflow. A download path obtains a DDD artifact; a receiving system must identify, preserve and confirm what it accepted. The first event can be green while the second is missing.
The FMS Standard Remote Download User Guide v3.01 describes remote company-card authentication and downloading across the vehicle-side and back-office boundary. The rFMS tachograph files API v1.0.1 describes an HTTPS API contract with timestamps and file-related response fields. Neither turns a scheduler event into destination receipt.
This page covers the post-download handoff. Cadence, authentication depth, failure/retry, installation and end-to-end pilot acceptance remain separate topics.
Preserve the original signed file and its identity
Start with the source artifact. Keep the original signed DDD file as a byte-preserving record with the request or download context. A preview or parsed copy is derived and must link back to the original.
“Signed” is an identity and integrity boundary, not permission to rewrite. Do not change encoding, remove a signature, merge periods or replace the original with parser output. If the project uses a digest, record its method as project evidence, not as a universal legal requirement.
The source record should identify the vehicle or card route, tachograph context, covered period, source timestamp and location of the unchanged bytes. An unlabelled attachment is not a delivery contract.
Minimum metadata for a receiving system
Metadata lets a receiving system decide what it has without guessing. Use controlled aliases where needed and keep unnecessary personal details out of a public brief.
| Metadata group | Minimum question | Evidence or owner |
|---|---|---|
| File identity | What stable file name, source reference or digest identifies the original signed file? | Source record; preserve bytes unchanged. |
| Vehicle identity | Which vehicle or controlled asset alias does this file represent? | Fleet or asset owner; do not infer from a filename alone. |
| Tachograph identity | Which tachograph context and generation are in scope? | Technical owner; confirm the generation directly for the selected vehicle. |
| File type and period | Is it a vehicle-unit/mass-memory or driver-card file, and what period does it cover? | Request context and file metadata. |
| Timestamp | When was it requested, received and handed off, and in which timezone? | Use an explicit timezone; the rFMS reference uses UTC ISO 8601 timestamps. |
| Route and target | Which path, endpoint or receiving system is responsible for the next state? | Named integration owner and destination identifier. |
| Receipt state | Was it received, validated, acknowledged, duplicated or left status unknown? | Response, acknowledgement or an assigned unresolved owner. |
The rFMS specification lists filename, receivedDateTime, VIN, tachoGen and optional file content in its defined response. These inform a checklist; they do not prove a selected route.
Assign the target system and API responsibility
Write the destination as an accountable system, not just “the cloud.” Name its endpoint owner, credential owner, response observer and acceptance owner.
API responsibility includes transport, authentication, schema or media version, headers, encoding, timestamp convention, response identifier, duplicate key and escalation path. The rFMS document describes HTTPS, bearer authorization and JSON-oriented responses; vehicle-to-OEM download is outside that API and OEM-specific.
Boundary to keep explicit: API/route is an integration boundary, not evidence that LEXUNYU owns a platform. A route in a brief is a question for the receiving-system owner, not a product capability claim.
One sample response does not prove universal compatibility. Confirm the selected vehicle, generation, route, schema and live credentials within the project.
Use an acceptance matrix for the handoff
A matrix prevents “downloaded,” “delivered,” “validated” and “accepted” from becoming interchangeable. Give each state one owner and one evidence pointer.
| Handoff state | Receiving-system question | Minimum evidence | Owner / boundary |
|---|---|---|---|
| Downloaded | Did the source route produce an original signed file? | Source request, file reference and unchanged artifact. | Download-side owner; not destination receipt. |
| Sent | Was the identified artifact handed to the agreed route? | Transfer time, route identifier and content reference. | Sending integration owner. |
| Received | Did the target system store or expose the artifact? | Target response, received timestamp or receipt ID. | Receiving-system owner. |
| Validated | Can the target read the expected file type and period? | Validation result linked to the original file. | Technical or workflow owner. |
| Acknowledged | Has an accountable system confirmed the handoff? | Machine or human acknowledgement with scope. | Named accepting owner. |
| Unknown | Can the next state not yet be classified? | Last observed event, missing evidence and owner. | Hold; do not infer success. |
This operational recommendation is for project planning, not a regulation. It preserves the distinction between source and destination events.
Confirm receipt with audit evidence
Receipt should be reproducible. Keep a handoff identifier, source and file identity, vehicle identity, request and received timestamps, route, response or acknowledgement, validation result and unresolved items. Link these records to the unchanged original.
An acknowledgement may precede storage or validation. Name the state it proves; if it has no file context, mark that relationship unresolved.
- Source evidence: scope, signed DDD file, file type, period and source timestamp.
- Transfer evidence: route, destination identifier, sent time and response or receipt.
- Acceptance evidence: target record, received time, validation outcome, actor and open questions.
A scheduler tick, attachment, HTTP connection or plausible filename is not delivery proof.
Record duplicates and status unknown without guessing
A duplicate delivery may be the same artifact twice, a corrected revision or a filename collision. Define a project duplicate key, compare with the preserved original and record the decision. Never silently overwrite the first receipt.
Status unknown means the records cannot show whether the target stored, rejected or completed the handoff. Hold the item, preserve evidence, assign an owner and state what would close the gap. It is neither success nor failure.
This page does not prescribe retry logic. Keep duplicate and unknown records visible; a later run must not erase them.
Keep retention with the project or legal-policy owner
Retention is not a universal number. Decide who owns access, retention, deletion, legal hold and jurisdiction-specific policy. The project/legal-policy owner must define the period and controls before the workflow is operational.
Keep the delivery record and original signed file within that boundary; limit access and document the decision.
This is not legal advice. A receipt record shows what a system observed; it does not establish compliance or a retention outcome.
Keep DDD files separate from CAN telemetry
A signed DDD file is not CAN telemetry. Tachograph access, company-card authentication, file retrieval and signed-file handoff are a separate evidence path from FMS/J1939/CAN values such as fuel, AdBlue, rpm or mileage.
The fuel and AdBlue validation guide covers vehicle data field checks. A CAN value does not prove a DDD file was retrieved or delivered, and a received DDD file does not prove that a CAN field is available. Keep the two acceptance records separate.
For the broader route context, use the remote tachograph DDD project guide and the scheduled-download definition article. Each answers a different handoff question.
Questions before choosing a delivery route
Does a successful remote DDD download mean the receiving system has the file?
No. Download success is a source-side state. The receiving system still needs an identified file, agreed metadata, a delivery path and receipt evidence.
What should be preserved when a signed DDD file is handed off?
Preserve the original signed bytes and request context. Keep previews and parsed copies as derived records linked back to the original.
Which metadata does a receiving system need first?
File identity, vehicle identity, tachograph identity, file type, period, timestamp and timezone, route, destination, receipt state and owner.
Who owns an API or file-delivery route?
Name the receiving-system owner and route owner. API/route is an integration boundary, not proof of platform ownership or universal compatibility.
What counts as receipt evidence?
Keep a handoff identifier, source and file identity, timestamps, content reference, target response or acknowledgement, validation result and unresolved item.
How should a duplicate delivery be handled?
Compare it with the preserved source using a stable project key, then record same file, revision or unknown. Do not silently overwrite the first record.
What does status unknown mean?
The available evidence cannot classify the next state. Hold the item, preserve evidence and assign an owner rather than guessing.
Who defines DDD file retention?
The project or legal-policy owner must define retention, access and deletion rules for the intended use and jurisdiction. This checklist is not legal advice.
References and scope
Primary references are the FMS Standard Remote Download User Guide v3.01 and FMS Standard API for rFMS tachograph files v1.0.1. They explain remote authentication, file responses, timestamps and API boundaries; they do not prove a selected route or LEXUNYU capability. For the authentication boundary, see the company-card guide. Vehicle or tachograph compatibility, live credentials, endpoint behavior, customer-system acceptance, retention and legal responsibility still need project-level confirmation.