Home Products

The LogIQ VDA5050 Analyzer logo beside the claim “Every message, against every rule”, the standards it covers — VDA5050 1.1, 2.0.0, 2.1.0 and 3.0, VDMA M2X, VDMA LIF — and four of the application's own screens overlapping: the dashboard with its latest runs, the LIF layout graph, the replay view and the findings table, with a seal reading “PASS — report signed” on top.
A LogistiXpert product

Independent. Secure. Verifiable.

A conformance checker for VDA5050, M2X and VDMA LIF — for log files and for live traffic. The standard describes messages; it does not prove that two systems read them the same way. This does.

The situation

The interface is in the standard. Real life is not.

The vehicle and the fleet controller come from different vendors. The specification describes the messages — it does not prove that both sides read them the same way. When they do not, three questions cost real time.

01

"Who is right?"

When something breaks, it is one vendor's claim against another's. Without evidence, the argument takes days.

02

"What was checked?"

A green tick without a scope is worthless. An acceptance test has to state which rules ran, which did not apply and why.

03

"What happened there?"

The fault appears once, on a Friday evening. Without a recording that keeps its context, all that is left is to reproduce it — and hope.

The answer

One tool, three specifications

186checks

VDA5050

1.1, 2.0.0, 2.1.0 and 3.0

Schema, protocol header, order and state structure, node, edge and action lifecycles, order-state correlation, battery and safety.

12checks

M2X

0.9.0 · preview

Peripheral interfaces: load handling, doors, lifts, signal lights, charging devices and transport orders — against the official schemas.

13checks

VDMA LIF

1.0.0

Layout files: schema, node and edge integrity, reachability across the graph, station references.

M2X is not final yet. Its results are marked as a preview and make no claim to certification — VDA5050 and LIF are unaffected.

Sources

Three different sources — whichever you have

01

Import a log file

.log, .txt, .json or .ndjson. The importer detects the message type, reports lines it could not read and keeps the field order of the source.

Several files at once are read and listed first; you then decide whether they stay apart or merge into one log — ordered by the timestamp the messages carry, an overlap between two files kept once, and a repetition inside one file left alone, because that is a finding.

02

Record live

A capture profile connects to the broker, records in the background and analyses every message as it arrives — several profiles at once.

03

Sit in between

The same profile can mirror the traffic onto a second broker, running as a transparent proxy between vehicles and controller without disturbing live operation.

Depth

What is actually checked

Not one pass over the text — four layers, each building on the last. And a second number saying how much of all that a recording actually reached.

  1. Schema first

    Every message against the official JSON schema of the target version — 1.1, 2.0.0, 2.1.0 and 3.0 separately, because each of them renamed fields the others still carry.

    Layer 1
  2. Then structure

    Required fields, types, ISO-8601 timestamps, semantic version, arrays where arrays belong.

    Layer 2
  3. Then sequence

    headerId gaps and regressions, timestamp regressions, node and edge sequences, action lifecycles.

    Layer 3
  4. Then coherence

    Is an order acknowledged? Does the reported progress match the order that was issued? Both per vehicle.

    Layer 4
The two verdict cards of a report side by side: the VDA5050 compliance verdict with its score, and the standard coverage verdict with its figures and the seven gates a certification-grade run has to pass.

Two numbers, because one of them can lie

A score says how much of what was tested passed. It says nothing about how much there was to test — and a flawless score over a third of the rules proves very little. Every run therefore carries a second figure: coverage, how much of the standard the recording actually put to the test.

It is measured against what this vehicle is supposed to be able to do — everything the target version describes, minus what the vehicle's own factsheet says it has no hardware for. Three questions make it up: did the rules find anything to judge, did the vehicles fill the fields the standard defines, and did the run ever show the situations that only occur when something is done. With several vehicles the figure is the lowest of them, not the average.

Seven things have to have happened at least once before a run is certification-grade — an order carried to completion, one updated while it ran, one cancelled and acknowledged, an error that began and ended, and so on. The report names the ones still open, and what to record to close them. Neither number ever moves the other.

Declaration against reality

Can the vehicle do what it is asked to?

Every vehicle declares in its factsheet what it can do. 22 of the checks measure the traffic against that declaration and they answer a different question from the rest: not “does this message follow the standard” but “can this vehicle handle it”.

01

What the fleet manager asks for

An action that is not in the vehicle's catalogue. An optional parameter it never claimed to support. An order beyond the declared length, array and timing limits.

02

What the vehicle actually does

More states reported than promised, state messages faster or slower than its declared interval, loads outside its own specification.

03

Whose fault was it?

Every finding names the side that caused it. So the most common commissioning argument ends with an answer instead of two assertions. The factsheet itself is checked on import and can be viewed in the tool, properly formatted.

Without a factsheet this group reports “no data” — never “passed”. A report claiming conformance against a reference nobody supplied would be exactly the false confidence this tool exists to prevent. A fleet has more than one type of vehicle, so a run takes one factsheet per type, each matched to the vehicle it names — and the report says, vehicle by vehicle, which ones were measured against a declaration and which were not. A vehicle passed over must not look like one that passed.

Your rules

Your site has rules the standard has never heard of

No fleet fails commissioning on VDA5050 alone. Every integration guide has a sentence like this one: “pickFromBin requires a binId of the form BIN-0000”. A custom ruleset carries it into the same machinery that evaluates the standard.

01

Data, never code

The file is declarative JSON against a published schema, interpreted by seven fixed rule types — a field value, an embedded JSON Schema, a count, message spacing, monotonicity, a forbidden value, an allowed-transition table. Nothing in it is ever executed.

02

Two verdicts, side by side

A custom rule never moves the VDA5050 verdict. The report shows both: the standard alone, and the standard plus your rules — and the first is settled before the first custom finding exists.

03

Frozen with the report

A copy of the rulesets used is written next to the report files, and the audit block carries the name, version and SHA-256 of each. Replacing the upload later never changes what an existing report was measured with.

Selected on the Analyze page and on capture profiles like any built-in check, marked CR on every finding. Included from the Team plan (five rulesets), without limit on Unlimited and on-premises; up to 200 checks and 2 MB per file. Uploading is reserved for superusers, because a ruleset changes what every member's runs are judged with.

In use

From a finding to the message in one click

The findings of a report: severity, the family each rule comes from, the vehicle, the field path, and the clause of the version being judged — with the disposition recorded beside it.

The finding, with the evidence for it

Each finding shows the message that triggered it, with the offending field path highlighted — not just a line number. Beside it, the previous, current and next message scroll as one, so you read a deviation in context.

Filter by severity and by vehicle, grouped by check or by message — depending on whether you are after a pattern or a single incident.

And because acceptance ends with a list, the report records it: each finding carries a disposition — accepted deviation, false positive, to fix — with a mandatory justification and its author. Standing waivers cover deviations that recur in every recording, re-runs inherit past decisions, and two runs can be compared check by check. None of it moves a verdict, and all of it travels in the signed package.

The Analyze page: the versions a capture holds and the message types it holds, each ticked and each with its count, and below them the checks of the version whose tab is open.

You choose what is judged, and against which document

The page reads the file first and then offers what is actually in it: every VDA5050 version the traffic carries, and every message type with its count. Untick a version and it leaves the run; untick a type and those messages never reach the checks at all.

Each version gets its own tab and its own selection, showing only the rules that version knows — a corridor rule is not a choice under 1.1, and a rule the judged version never had is not counted as passed either. Every check names the clause it comes from, in the document you are being measured against.

The track layout of a LIF file drawn from its real coordinates: nodes, stations and edges, with names that step aside where they would overlap instead of disappearing.

The layout, read as a map

A LIF file is checked as a document — schema, duplicate ids, dangling edges, isolated nodes — and drawn as what it describes: every node at its real position, stations and actions marked, elements with findings in red.

Zoom and pan; names appear as you zoom in. Where two would sit on top of each other one steps aside rather than vanishing, because a name that is not drawn is a node you cannot find.

A finished capture replayed on the imported LIF layout: the route of the active order highlighted on the track, with the vehicle table and the transport controls below it.

Watch the system at work — or replay what already happened

Every vehicle on the LIF layout in its own colour, the last order issued against the last position reported. When the map and the vehicle disagree, the tool names the contradiction — that is the point. Findings appear as they happen.

The same view replays any finished capture or imported log, forwards or backwards, step by step and up to 20×, true to the real message intervals and showing only what was known at each point.

A report you can pass on

A report exports as one signed package: the report, the file that was analysed, the cleaned messages and every reference, with a manifest carrying the SHA-256 of each file and an Ed25519 signature over it. Whoever receives it checks it against our public key and knows it came from us and is unaltered.

Auditable verdicts

Every rule is Active, No data or Switched off — never a silent pass. Each run records what it was made from: the project, the log file, the LIF layout and factsheets, the messages by type and every vehicle by name — with the target version, the schema revisions, an input checksum and the time.

The order on the real track

The order path is drawn on the imported LIF layout and compared node by node and edge by edge — the most common reason a vehicle rejects an order. On a mismatch, every missing node is named.

Fleet-ready

headerIds are counted per topic; the topic carries manufacturer and serial. Every sequence, lifecycle and correlation is evaluated per vehicle, so ten vehicles are not one vehicle's findings times ten.

Unattended monitoring

Record for days. A digest arrives on a schedule or once a threshold is crossed, broken down by severity, vehicle and check. A restart resumes where it stopped — nothing counted twice.

Operating figures

What the fleet did with its time

The same file, a second question: not whether the messages are right, but what the installation did with the time. Every imported log and every finished capture carries a performance review — no extra instrumentation, no second recording.

The performance review of one shift: a row per vehicle with availability, error periods, and the shares of manual, fault, active and idle time, followed by the error periods themselves with their start and end.
One shift, five vehicles: the shares of the recorded span per vehicle, and under the table every error period of the fleet in one list, ordered by when it began and filterable to a single vehicle.

Five states, exactly one at a time

Manual, fault, active, idle and — where it occurs — other. Because exactly one holds at every moment, the shares add up to the recorded span and can be read against each other: the tug above spent 12.4 % of the shift in fault, and one of the AMRs 6.6 % under manual control.

A warning is not an outage

A vehicle reporting an uncertain pose and carrying on is available; only an error above warning level counts against it. That is why the fork-lift above lists two error periods and only one of them is in its 7.5 %: the warning it worked through is in the list, not in the figure.

Active means it is working

Not that it is driving. A vehicle standing at the station with a pick running is neither travelling nor waiting for work — driving would have called it idle. Active is an order still to finish.

Any timeframe

A shift, an hour, the half hour before the standstill. The window is cut before counting rather than filtered afterwards, so the percentages are shares of the period you asked about — one click resets to the whole log.

Every fault with its own line

Under the table, each error period: level, type, description, the state message that first reported it and the one that no longer did — with the minute it began and the message it sits in, one click away.

Who it is for

Where it pays off

AGV and robot manufacturers

Prove that your own vehicles conform before shipping — and show, when a complaint arrives, that the messages matched the standard.

Fleet controller vendors

Test orders and instantActions against several vehicle types before the customer does. Spot regressions between releases with the same scope on a new build.

Integrators and operators

Accept third-party systems without taking the vendor's word for it. A weekend-long run, a report on Monday.

Test houses and consultancies

A documented, repeatable scope instead of home-grown scripts — multi-tenant across enterprises and projects.

Operations and security

Runs where the data has to stay

Recordings from a live installation rarely leave the network. The analyzer runs where they are.

  • On your own premises

    Docker Compose — one file, one command. Your hardware, your network or a hosted instance.

  • Encrypted connection

    MQTT over TLS, with your own CA certificate where the site uses one. Broker passwords are stored encrypted, never in plain text.

  • A licence that does not call home

    On your own network the installation carries a signed licence file, checked locally. Grace on expiry, then read-only — nothing you recorded is ever locked away.

  • Reports under your own name

    Test houses can put their own name and mark on the report, the export and the digests. The name of the tool stays underneath.

  • Links that cannot be guessed

    Reports and runs sit behind unguessable ids, with an ownership check on every access.

  • Roles with limits

    Member, superuser, administrator — who may delete what is defined and enforced in one place.

  • Teams and projects

    Colleagues share one enterprise; logs, layouts and reports are filed under a project and can be filtered by it. What a plan limits is scope — people, projects and profiles — not how much traffic you analyse.

  • Quality on record

    More than 1,700 automated tests run before every release.

FAQ

Common questions about the Analyzer

What is the LogIQ VDA5050 Analyzer?

An independent conformance checker for AGV and AMR fleet communication. It reads VDA5050, VDMA M2X and VDMA LIF messages — from a log file or live over MQTT — and shows whether a vehicle and its fleet controller interpret the standard the same way, backed by an auditable report.

Which standards does it check, and how many checks are there?

VDA5050, VDMA M2X and VDMA LIF, with 211 checks: 186 for VDA5050 in its four versions, 12 for M2X and 13 for LIF layouts.

Does it work on recorded logs or on live traffic?

Both. Point it at a log file, or connect it to live MQTT for a real-time fleet view, session replay and unattended monitoring.

Can I run it on-premise?

Yes. It ships as Docker and runs hosted by LogistiXpert or entirely on-premise, so protocol data never has to leave your network.

Are the reports auditable and verifiable?

Every run states which checks ran, which did not apply and why. Reports from the instances we operate are cryptographically signed, and anyone can verify one against the public key at logistixpert.de/verify.

Is it tied to a particular vehicle or fleet-controller vendor?

No. LogistiXpert is independent, with no vendor ties and no stake in the outcome — the point is neutral evidence both sides can trust.

The next step

Three ways to start

01

Demonstration

A walk-through of the demo package that ships with the product — one clean and one faulty data set with a matching layout.

02

Pilot on your data

One recording from your installation, analysed and discussed together.

03

Operation

Hosted at logiq-vda5050.com or in your own network with Docker.

The LogIQ VDA5050 Analyzer provides diagnostic guidance. It issues no certification and no release approval. VDA5050, M2X and LIF are trademarks of their respective bodies; this is an independent tool and is not endorsed by them.