Company Card Authentication inRemote Tachograph Downloads
A company card is the transport undertaking’s authentication credential for a remote tachograph download. Before a pilot, define who holds it, which back-office session uses it, how the vehicle request is observed and what evidence proves the signed file reached its intended destination.
On this page
- The company card identifies the transport undertaking and enables access to data locked by that undertaking; it does not name every owner in the wider delivery chain.
- Authentication evidence should be tied to the back-office reader, session, vehicle response, requested file and receiving handoff.
- A successful card session is one pilot checkpoint, not proof of a physical route, complete delivery, archive arrangement, legal compliance or current device capability.
What the company card proves — and what it does not prove
The company card is an authentication credential for the transport undertaking. The FMS Standard remote-download guide describes an initial remote company-card authentication step before downloading. The credential’s role is specific: it does not assign custody to a supplier or prove that a platform owns the wider process.
Before a pilot, record the card holder, permitted back-office location, reader or session, request initiator and party that can inspect the vehicle-unit response. A card without a visible session, authentication result or request trace is an input, not yet a reviewable evidence chain.
Authentication is narrower than the full project. It does not prove the physical route, a complete file, archive or API acceptance, legal compliance, or current LEXUNYU device support. This is educational project guidance, not legal advice.
Company-card authentication responsibility and evidence
| Step | Accountable owner | Evidence to retain | Failure to plan for |
|---|---|---|---|
| Card availability | Transport undertaking or named card holder | Valid company card, holder and permitted operating context | Card unavailable, expired or held by an unassigned party |
| Reader/session | Back-office operator or service owner | Reader identity, session record and authentication result | Reader access, credential custody or session boundary unclear |
| Vehicle communication | Route or integration owner | Request trace, vehicle-unit response and route-specific test record | Card authenticates but the vehicle path does not respond |
| File retrieval | Download workflow owner | Requested period, signed file receipt and completeness check | Partial, delayed or unreadable file with no visible owner |
| Retry and handoff | Platform or archive receiving owner | Timeout, retry, final receipt and archive/API handoff record | Failure repeats, or a received file has no destination evidence |
Keep the boundary explicit: the card holder may not own vehicle communication, and the party seeing a signed file may not own archive or platform handoff. A green authentication response is not a green end-to-end delivery.
Five decisions to make before the pilot
- Who holds and uses the card? Name the transport undertaking, holder, permitted reader and operating session; document any custody change.
- Which path is tested? Record the tachograph, vehicle and terminal combination and whether it is FMS/RDD, direct or a service route. Authentication does not create a physical path.
- Who watches the request? Define the schedule or trigger, visible response, timeout handling and retry decision.
- What file proves completion? Agree the signed artifact, request scope, receipt and completeness check; tie a sample to the intended route.
- Where does it finish? Name the archive, customer platform or API, receiving owner and handoff record.
Evidence pack for the first successful and failed attempts
Make the pack reconstructable: card and reader context, intended tachograph and vehicle combination, route description, request or schedule reference, authentication response, requested period and signed file receipt. Name the receiving system and the person who decides whether the attempt is complete.
Keep failure evidence beside the successful sample. Record unavailable card, reader error, missing vehicle response, incomplete file, timeout or rejected handoff; then note the symptom, owner, retry decision and preserved request. One success remains evidence for its tested scope, not universal compatibility.
Minimum review set: card and reader context; authentication response; vehicle-unit trace; signed DDD file; retry or timeout record; platform, API or archive receipt. Missing evidence means the corresponding capability remains unverified.
The FMS Standard guide is a primary reference for the authentication and downloading sequence. A supplier response should bind that sequence to the intended equipment and show a reviewable sample or test.
Keep authentication separate from the rest of the route
Authentication answers whether the transport undertaking’s credential was used in an observable session. It does not, by itself, prove the physical FMS/RDD or direct connection, complete signed-file delivery, archive or customer API handoff, legal compliance in a particular country, or current LEXUNYU device support.
For the wider project context, see the DDD project guide. For the wider responsibility chain, see the remote DDD ownership map. For connection-path questions, use the FMS/RDD versus direct route comparison. The boundary keeps authentication evidence useful without making it carry claims it cannot support.
Questions to close before a pilot
Does possession of a company card prove remote DDD support?
No. It proves an authentication credential is available; route, process, transfer and destination still need evidence.
Who is accountable for the card?
Name the transport undertaking or approved operator and the reader-session owner; do not infer custody from an interface label.
What should follow authentication?
Request the observable request and vehicle response, tied signed-file sample, retry visibility and platform or archive handoff.
Can authentication replace route testing?
No. A valid session does not establish the intended FMS/RDD, direct or service-cloud route for a selected combination.
What is retained when a download fails?
Keep request context, result, error or timeout, retry decision, owner and partial or rejected file evidence.
Is this legal compliance advice?
No. It is an educational responsibility and evidence checklist; use an appropriate qualified source for legal questions.
Technical references
Read the FMS Standard Digital Tachograph User Guide Remote Download v3.01 for the remote company-card authentication and downloading sequence. The EU tachograph regulation text is a legal source, not a substitute for project-specific advice. Neither source is proof of LEXUNYU capability or a particular supplier’s delivery.