Scheduled Remote Tachograph DDD Downloads: Before Automation
A timer is not an operating contract. Before a team automates remote tachograph DDD downloads, it should define the fleet scope, tachograph environment, cadence owner, file boundary, handoff destination and evidence that makes one run count.
On this page
- Scheduled DDD retrieval is a chain of scope, authentication, trigger, file and receiving decisions; a cron-like timer only covers one small part.
- Vehicle-unit and driver-card files, cadence policy, signed-file naming and handoff ownership should be explicit before a request is automated.
- Unknown scope or missing evidence is a stop condition. It is not permission to infer compatibility, a complete download or a successful destination receipt.
Why scheduled downloads need a written operating contract
A scheduled remote tachograph DDD download is a chain: vehicle or card scope, tachograph route, company-card authentication, trigger, download window, signed file and receiving handoff. If one input is implicit, a timer can run without agreement about the file it should retrieve.
The official FMS Standard Digital Tachograph User Guide Remote Download v3.01 describes remote company-card authentication and downloading, with an on-board unit and back office involved. This confirms the technical boundary, not a LEXUNYU product capability.
This operating-contract recommendation is for project planning, not legal advice. It does not establish a supplier, platform or route.
Define fleet, vehicle and tachograph scope
Begin with the smallest fleet slice that can be named and tested. “The fleet” may contain different vehicles, tachograph generations and access routes, so a schedule needs an identity for every member.
| Scope input | Define before automation | Owner or evidence |
|---|---|---|
| Fleet scope | Named list, depot or operating group; state how additions happen. | Fleet owner and dated record. |
| Vehicle scope | Make/model/year or an unambiguous asset alias. | Asset register or controlled record. |
| Tachograph scope | Tachograph make/model/generation; flag variants. | Technical owner and source record. |
| Connection route | FMS/RDD, direct tachograph or service-cloud path. | Integration owner and route record. |
| Authentication boundary | Company-card authentication holder and response observer. | Session evidence; see the company-card guide. |
Do not fill an unknown scope cell with “supports CAN” or “supports remote download.” Unknown tachograph make, model or generation keeps that schedule outside automation until an owner closes it.
Name the cadence, trigger and policy owner
Download cadence is a policy choice. Record whether it is periodic, event-led or signal-led, plus timezone, trigger, download window, deferral and the policy owner who may change the rule. Do not invent a universal interval.
Make the trigger observable and define when a run is late or skipped. Failure and retry are later deep topics; this page only requires their boundary to remain visible.
| Contract line | Question to answer | Stop if unknown |
|---|---|---|
| Cadence | What recurring or event-led policy applies? | No unagreed frequency. |
| Timezone | Which clock controls schedule evidence? | No mixed “on time” claims. |
| Trigger | What observable event creates the request? | No trigger, no count. |
| Download window | When may it run, and when is it late? | Do not widen it silently. |
| Policy owner | Who approves changes and exceptions? | No owner, no automation. |
| Scope change | How are vehicles, cards or generations rechecked? | No inherited proof. |
Separate vehicle and driver-card file scope
Vehicle-unit files and driver-card files are separate scope questions. Record the file class, vehicle or card identity, covered period, generation context and destination. If only one class is needed, say so.
Keep the period and trigger together: the request record should state the intended period before a response arrives. Use a signed-file naming contract with a stable alias, period, needed route context, revision and receipt state. Detailed file/API delivery is a later integration topic; the handoff boundary still belongs in this schedule.
Define signed-file naming and handoff
“Downloaded” should identify an artifact, not merely bytes leaving a vehicle path. The FMS Standard guide describes signatures appended to downloaded data so authenticity and integrity can be checked. Preserve the signed DDD file and the request context.
Name the handoff destination, receiving owner and retained evidence. An intermediate receipt is not necessarily final acceptance, and an acknowledgement without the file context may not prove what was delivered. Keep API credentials and private card data out of a public brief.
A handoff record should contain scope alias, timestamp and timezone, requested period, file class, signed-file name, receipt state and unresolved items. Open detailed file/API mapping as a separate workstream. For the post-download receiving-system checklist, see the DDD file-delivery handoff article.
Make success and failure visible
Use human-readable states such as scheduled, triggered, request sent, response observed, signed file received, handoff acknowledged, late, failed and unknown. A green scheduler tick alone cannot explain a missing or mismatched file.
Define success visibility: request record, vehicle response, signed-file location and destination acknowledgement. Define failure visibility: owner, timeout record and held scope. If monitoring is disconnected, record that the state cannot be established; retry policy stays outside this article.
Accept the first pilot by evidence
A pilot should prove one defined slice, with expected schedule and both successful and unsuccessful attempts retained. It should answer whether the selected route, scope and handoff are observable under agreed conditions.
| Check | Evidence to retain | Acceptance state |
|---|---|---|
| Scope | Fleet/vehicle alias, tachograph make/model/generation and route. | Pass, fail or unknown for this configuration. |
| Policy | Cadence, timezone, trigger, download window and policy owner. | Comparable with the agreed rule. |
| Authentication | Company-card owner, request context and response. | Only the shown boundary is evidenced. |
| File scope | Vehicle-card or driver-card class, period and signed-file name. | Requested class and period identifiable. |
| Receipt | Signed file, completeness check and destination acknowledgement. | Pass, fail or unknown; preserve intermediates. |
| Exception | Late, timeout, missing response or unknown cause with owner. | Held for review; do not erase with a new run. |
| Decision | Reviewer, date, evidence pointers and open unknowns. | Accepted, held or rejected with next action. |
This is an evidence contract, not a delivery claim. Coverage, file/API behavior, hard-wired installation and failure/retry still need records from a scoped pilot.
Keep fuel and AdBlue on a separate data path
Fuel, AdBlue, engine and mileage values belong to an FMS/J1939/CAN data path. Scheduled DDD retrieval is a tachograph file path with authentication, signed data and handoff.
The fuel and AdBlue validation guide treats vehicle data as a separate evidence chain. A CAN field does not prove tachograph access, and a scheduled file does not prove a fuel or AdBlue field.
Use the DDD project guide and CAN versus DDD explanation for adjacent boundaries.
Unknowns are stop conditions
Stop the affected scope when tachograph generation, authentication owner, trigger, file class, signed-file destination or evidence path is unresolved. Record the unknown, owner and next information needed. Do not broaden a pilot, turn a vendor statement into a compatibility list or turn an unverified schedule into a production promise.
The FMS Standard guide describes remote company-card authentication, remote downloading, vehicle-unit generations and back-office/vehicle-side roles. A written schedule, file and evidence contract should precede automation. Selected-fleet coverage, destination implementation and project result remain open until direct evidence exists.
Questions to close before automation
What does scheduled remote DDD automation actually automate?
A defined request window and handoff, not the missing scope and evidence decisions.
Which fleet information should be fixed first?
Fleet, vehicle make/model/year or alias, tachograph make/model/generation, route and scope owner.
Who owns the download cadence?
A named policy owner who can set cadence, timezone, trigger and download window.
Should vehicle-unit and driver-card files share one schedule?
Not by default; define vehicle-card and driver-card file scope separately.
What is a signed-file naming contract?
A stable alias, period, context, revision and receipt state that identifies the artifact.
Where should the downloaded file go?
Name the receiving platform, archive or handoff destination and its owner; API design is separate.
What counts as a successful scheduled run?
Observable request, response, signed file, completeness check and receiving acknowledgement.
What should happen when a scheduled run is unknown?
Keep it unknown, stop the scope, preserve evidence and assign an owner.
Does fuel or AdBlue CAN data prove DDD automation?
No. FMS/J1939/CAN data and tachograph file retrieval are separate paths.
What should a buyer send for a project review?
Vehicle/tachograph environment, cadence, file scope, destination and responsibility boundaries.
References and scope
The 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 the technical concepts and boundaries, not LEXUNYU capability, supplier coverage or a legal conclusion.
For authentication, read the company-card article; for FMS/J1939 fields, read the fuel and AdBlue article. Vehicle coverage, destination implementation and project results still need direct testing.