Legal/Disclaimer

Legal notice, privacy information and terms for LogIQ VDA5050 Analyzer.

Trademarks and Independence

VDA 5050 is a specification published by the Verband der Automobilindustrie e. V. (VDA). LIF and M2X are specifications of the VDMA e. V., the German mechanical engineering association. These designations are used descriptively throughout this application, and in the name of this product, to say which specifications the tool reads. Any rights in them remain with the bodies that publish them.

This is an independent tool. Neither the operator named above nor the LogIQ VDA5050 Analyzer is affiliated with, authorised by, endorsed by, accredited by or otherwise connected to the VDA or the VDMA. Nothing this tool produces – no verdict, no score, no report and no exported package – is a statement by either body, and neither has reviewed the checks it applies. Where the analyzer and the body that publishes a specification read that specification differently, the body's reading is the one that counts; the places where this tool knowingly departs from a published schema are listed at schema deviations, each with the passage behind it.

Other company, product and brand names that appear in this application are the property of their respective owners and are named only to say what a thing is. Their mention implies no endorsement, partnership or business relationship.

Disclaimer

LogIQ VDA5050 Analyzer is a technical analysis tool for VDA5050 message streams. It helps users inspect state, order and mixed captures, identify potential issues and prepare engineering reviews.

  • The service does not provide official VDA5050 certification, safety certification, product approval, legal advice or operational release approval.
  • Analysis results are generated automatically and may be incomplete, inaccurate or dependent on the uploaded data quality and selected checks.
  • Users remain responsible for validating vehicle behavior, safety functions, integration correctness, operational procedures and customer-specific requirements.
  • No guarantee is given that all defects, protocol violations, safety risks, integration risks or operational risks will be detected.
  • Reports must be reviewed by qualified engineering, safety and compliance personnel before any operational decision is made.
  • M2X checks are based on a pre-release specification. They are marked as a preview in the affected reports, may change with the standard and must not be used as the basis of a formal conformance statement.
  • LIF checks follow the VDMA LIF 1.0.0 guideline and assess the layout file itself; they say nothing about the physical site it describes.
  • Live MQTT capture analyzes traffic as it is recorded. Messages lost in transport cannot be assessed, and results depend on the topics subscribed and the checks enabled for the profile.
  • Automated capture reports sent by email summarise findings since the previous report. They are a monitoring aid and do not replace review of the full report.
  • Custom rulesets carry rules that are not part of VDA5050. The service evaluates such a file as data and executes nothing from it, but makes no assessment of whether its rules are correct, complete or applicable to a given installation – that remains with whoever wrote the file and whoever selected it for a run. The VDA5050 verdict of a report is computed before any custom rule is applied and is not affected by one.
  • Finding dispositions and standing waivers – the statuses and justifications users record about individual findings or about a check on a vehicle – are statements by those users, not assessments by the service. They never alter a report's verdicts, scores or severity counts and the exported package marks them as such.
  • The signature on an exported report package states that the package was produced by the operator named in it and has not been altered since. It is not a statement that the verdict is correct for a given fleet, that the recording behind it is complete or truthful, or that the person passing the package on is entitled to do so.
  • Where a plan carries the Testbench feature, the service can act as a fleet controller and actively drive a vehicle – sending VDA5050 order and instant-action messages to a real vehicle over a broker the user configures, or to the built-in virtual vehicle. This is not passive analysis: a live run causes physical movement, and the service relies on the user's own confirmation that the plant is in test mode and that they are authorised to move the vehicles addressed. It does not and cannot verify either fact.
  • Certification runs, remote control runs, dry runs and benchmarks are testing aids. A certification run records what a vehicle demonstrated; it is not an operational release approval, not a safety certification, and no guarantee that a vehicle will behave identically outside the testbench. The word "certification" in the product names what the run is evidence for, and never a certificate issued by this service or by any body.
  • Standing a virtual fleet on a broker for interop testing publishes and answers VDA5050 traffic under manufacturer and serial number identities the user chooses. The service does not check those identities against real equipment that may be reachable on the same broker.

Privacy Policy

Controller

The controller responsible for the processing of personal data in this application is Matthias Merz, freelance consultant, at the address stated in the Legal Notice. Contact: support@logiq-vda5050.com.

Data Processed

  • Account data: username, email address, password hash, email verification status, user role, enterprise membership, superuser flag, message quota and timestamps.
  • Enterprise and project data: enterprise names, membership, requests to join an enterprise including any message the requesting user writes, the designated fallback superuser, project names, descriptions, completion status and project membership – and, where configured, the report branding of an enterprise: the name, accent colour, closing line and uploaded logo that appear on its reports, exports and email digests.
  • Usage data: uploaded file metadata, import records, analysis records, selected settings, generated reports, message counts and timestamps – and finding dispositions and standing waivers, each with its status, justification text, author and time.
  • Uploaded technical data: VDA5050 logs, MQTT captures, LIF track layouts, vehicle factsheets, custom rulesets, cleaned messages and report data. These files may contain operational identifiers such as manufacturer, serial number, order ID, map ID, timestamps, route data, error information and site-specific information. A custom ruleset may in addition contain rules taken from a vehicle manufacturer's integration documentation.
  • Capture profile data: broker address, port, optional broker user name and password, subscribed topics, analysis settings and the address and credentials of a second broker if publishing is enabled. Broker passwords are stored encrypted (see Security Measures).
  • Connector data: the same connection details as a capture profile, held open permanently rather than for one session, plus the state of the connection and the time it last reconnected.
  • Derived operating history: quarter-hour summaries per vehicle - operating times, counted events, positions, speeds and braking points - computed from recorded state messages, together with the maintenance counters and service intervals a user enters against a vehicle.
  • Support data: when a user opens a support ticket from the application, the subject and description they write, their username and email address, the installation's version and instance name, and any report or diagnostic file they attach.
  • Capture run data: the recorded messages of a run, the findings derived from them, run start and stop times, message counts and per-vehicle attribution.
  • Reporting settings: the email addresses entered as recipients of automated capture reports, the chosen interval or threshold and the time of the last report sent.
  • Testbench data: certification runs (the segments and the finished order messages they will send, the target vehicle's manufacturer, serial number and vehicle type, and what each attempt at driving the run demonstrated), remote control scenarios and their runs, vehicle twin behaviour profiles entered or measured by the user, fleet groupings, and interop run records including the broker connection used and the virtual vehicle identities placed on it.
  • Sharing records: for a report shared with a partner enterprise, which item was shared, the receiving enterprise, the covering note, who sent it, when, and whether and by whom it was opened.
  • Technical access data: session cookie, IP address, request path, response status and server log entries generated by the application, reverse proxy, container runtime or hosting infrastructure.

Purposes of Processing

  • Provide user registration, login, email verification, account management, quota management, file import, MQTT capture, analysis and report downloads.
  • Operate enterprise accounts and projects, including shared visibility of uploaded and captured data within an enterprise, its restriction to the members of a project, and the handling of membership requests.
  • Send automated capture reports and alerts to the recipient addresses configured on a capture profile.
  • Where a plan carries the feature, operate the testbench: plan and drive certification runs and remote control orders against real or virtual vehicles, stand a virtual fleet on a broker for interop testing, and run benchmarks.
  • Where a plan carries the testbench feature, operate remote control: store broker connections with the credentials needed to reach them, author single orders and instant actions against a stored layout, send them to a chosen vehicle, and keep the resulting message log, its check and any report made from it.
  • Where a plan carries the feature, operate monitoring: hold connectors to customer brokers open permanently, compute the quarter-hour operating history behind the fleet wall and fleet health pages, and raise preventive maintenance due dates from it.
  • Receive and answer support tickets raised from within the application, and the diagnostic bundles attached to them.
  • Maintain security, prevent abuse, troubleshoot errors, improve reliability and operate the hosted service.
  • Communicate with users about account access, verification, support and service-related matters.

Legal Basis

Personal data is processed where necessary to provide the requested service, manage user accounts, protect the application against misuse, comply with applicable obligations and respond to support requests. Where consent is required for a specific processing activity, it will be requested separately.

Emails Sent by the Application

During registration, the application sends a verification email to the provided email address. Registration emails may include a blind copy to the operator for customer service, abuse prevention and registration monitoring purposes.

Capture profiles can send automated reports. These are delivered only to the recipient addresses entered on the profile and are not blind-copied to the operator, because they contain the user's own operational findings. Anyone who enters a third party's address as a recipient is responsible for that disclosure. Emails are sent as HTML and plain text and contain the product logo as an attached image; no tracking pixels or remote images are used.

Sharing a report with a partner enterprise sends an email to every superuser of the receiving enterprise's own address on file, naming what was shared and by whom.

Retention and Deletion

User accounts, uploads, cleaned messages, captured messages and reports are stored as long as the account exists or until they are deleted. Deletion rights follow the role model: users may delete their own data, superusers may additionally delete the data of members of their enterprise and administrators may delete any account including its stored imports, analyses, captures, reports and related data. Server logs and backups may be retained for a limited operational period.

Some actions hide data without deleting it, and this is intentional so that records of a conformance run are not lost by accident:

  • Marking a project as completed removes it and the work filed under it from the lists. The data is retained and reappears if the project is reopened.
  • Deleting an imported log keeps the reports generated from it; only the link between them is removed.
  • Dissolving an enterprise or removing a member does not delete any file; it only ends the shared visibility.
  • A report keeps its own copy of the custom rulesets it was judged with. Deleting or replacing the uploaded ruleset does not remove that copy, because a report has to remain readable as the record of the run it was.
  • Aging out recorded traffic under a profile's retention setting removes the messages, not the quarter-hour summaries derived from them. The operating history on the fleet health and maintenance pages therefore remains after the traffic behind it is gone. Deleting the profile or connector removes both.
  • Sharing a report makes a separate copy in the receiving enterprise's own account. Deleting either side's copy removes only that side's; the other party's copy, and the record that a share took place, is unaffected.

Free accounts are deleted automatically. An account on the free plan, and everything analyzed with it, is removed seven days after registration unless the account is moved to a paid plan or an administrator marks it to be kept. The application states the date in advance and warns before it arrives.

Users who want data erased rather than hidden should delete the individual items, or contact the operator using the address in the Contact section.

Closing an account. A user may close their own account in the account settings. For a user without an enterprise, the account and all associated uploads, layouts, analyses, reports and captured messages are deleted, including the stored files. For a member of an enterprise, the account, its credentials and its membership are deleted, while the material produced within the enterprise (uploads, layouts, analyses, reports, capture profiles and runs and the associated usage record) is transferred to the enterprise's fallback superuser and remains available to that enterprise. This is stated in the application before the deletion is confirmed. Administrators cannot close their own account.

User Rights

Depending on applicable law, users may have rights to access, rectification, deletion, restriction of processing, objection, data portability and withdrawal of consent. Requests can be sent to support@logiq-vda5050.com.

Shared Access and Projects

Users can be assigned to an enterprise. An enterprise is a grouping only and has no login of its own. It has a direct consequence for data visibility that users should be aware of before uploading:

  • Every member of an enterprise can see and use all logs, LIF layouts, capture profiles, capture runs, reports, certification runs, vehicle twins and fleet and interop runs of every other member of that enterprise, including their owner's user name – except material filed under a project they are not a member of.
  • Members may delete only their own data. Superusers of the same enterprise and administrators may also delete other members' data.
  • Superusers may remove members from their enterprise; deleting a user account is reserved for administrators and for the account holder themselves.
  • One superuser per enterprise may be designated as its fallback and receives the material of members who close their own account.
  • Superusers manage the membership of their enterprise and can add or remove users.
  • Membership is established either by a superuser or an administrator adding the account, or by the user requesting to join and a superuser approving that request.

Projects group the work of an enterprise, and each project has members chosen by a superuser; every member of the enterprise is a member of a new project unless the superuser decides otherwise. Material filed under a project is visible to that project's members, to the superusers of the enterprise and to administrators only; this applies to the uploader of the material as well. Material filed under no project remains visible to every member of the enterprise. A completed project hides its material from the lists but does not delete it.

Data uploaded before joining an enterprise also becomes visible to that enterprise once the account is a member. Users who do not want material shared should not upload it to an account that belongs to an enterprise.

MQTT Capture and Proxying

The application can connect to an MQTT broker as a client, subscribe to topics and record the messages it receives. Users configure these connections themselves, and doing so carries obligations that rest with the user, not the operator:

  • Users must be authorized to connect to the broker and to record the traffic on the topics they subscribe to. Recorded traffic may contain third-party operational data.
  • Recorded messages, the findings derived from them and the broker credentials entered are stored on the application server.
  • If publishing is enabled, the profile republishes every captured message onto a second broker configured by the user. Users are responsible for ensuring that this forwarding is permitted and that the target broker is under their control.
  • Automated capture reports are transmitted by email to the recipients configured by the user and leave the application server in doing so.
  • A connector records without end. Unlike a capture profile, which the user starts and stops, a connector holds one broker connection open indefinitely, returns by itself after an interruption and starts with the service. Users must be authorized to record that installation's traffic continuously, not only for a single session, and must ensure that authorization remains in place for as long as the connector runs.
  • Derived aggregates outlive the traffic they came from. While a recording runs, the application folds each state message into quarter-hour summaries per vehicle - operating times, counted events and positions - which feed the fleet health and preventive maintenance pages. These summaries are deliberately kept when the recorded traffic itself is aged out, so a short retention for raw messages does not delete the operating history derived from them. Deleting the profile or connector deletes both.
  • Where a broker service is configured, the application hands out an MQTT broker of its own per fleet on a publicly reachable address, and takes it down again a quarter of an hour after the last connection closes. Traffic on such a broker is reachable by anyone holding its address and credentials.

Driving Vehicles (Testbench)

Where a user's plan carries the Testbench feature, the application can act as a fleet controller itself: it sends VDA5050 order and instant-action messages over a broker the user configures, to a real vehicle or to the built-in virtual one. This is different from the capture and proxying described above, which only subscribes and records – driving a certification run or a remote control order causes a real vehicle to move.

  • Users must be authorised to command the vehicles they address, and the application asks for confirmation before every live run that the plant is in test mode and that they are authorised to move it. The service relies on that confirmation; it does not and cannot verify either fact.
  • A certification run, a fleet grouping, a vehicle twin and the messages of a run are stored on the application server, the same as an uploaded log.
  • A vehicle twin's behaviour profile – timing figures a user enters to stand a vehicle in for a real one in a dry run – is data the user supplies; it is not obtained from the vehicle and is not verified against it.
  • Standing a virtual fleet on a broker for interop testing – so that a third party's own fleet controller can drive it – publishes and answers traffic under manufacturer and serial number identities the user chooses. Users must ensure those identities do not collide with real equipment reachable on the same broker, and that they are authorised to occupy that broker at all.
  • A vehicle twin can be published to partner enterprises or to the whole installation, so that another party may drive a fleet against it. What is shared is the behaviour model and the maker and series it names, never the recording it was measured from.
  • Benchmarks and fleet dry runs drive virtual vehicles only and cause no physical movement, but their timing figures are not a promise about how a real vehicle of the same declared behaviour will perform in a plant.

Security Measures

  • Account passwords are stored as salted hashes and are never readable, not even by administrators.
  • Broker credentials of capture profiles cannot be hashed, because a capture has to reconnect on its own. They are stored encrypted at rest with a key derived from the server configuration. This protects them in database dumps and backups; it does not protect against an attacker holding both the database and the running server environment.
  • Records are addressed in URLs by random, unguessable identifiers, in addition to the ownership checks applied on every request.
  • Authentication uses a technically necessary session cookie with the SameSite attribute set.
  • Registration includes a verification step intended to prevent automated account creation.
  • An uploaded custom ruleset is data, not code. It is validated against a published schema and interpreted by a fixed set of rule types; nothing in such a file is executed. Uploading one is restricted to superusers, because a ruleset changes what every member's runs are judged with.
  • Report packages are signed with a private key held only on the instances operated by LogistiXpert. It is separate from the licence signing key, so an instance able to sign a report cannot issue licences. The corresponding public key is published at logistixpert.de/verify, and an installation without the key produces packages that state plainly that they are unsigned.

No security measure offers complete protection. Users should not upload credentials, private keys or access tokens and should not enter productive broker passwords where a dedicated, restricted account is sufficient.

Terms and Conditions

By creating an account or using LogIQ VDA5050 Analyzer, users agree to these Terms and Conditions. If a user does not agree, the service must not be used.

Service Description

LogIQ VDA5050 Analyzer provides hosted tools for importing VDA5050 log files, vehicle factsheets and LIF track layouts, capturing and optionally forwarding MQTT messages, running automated checks – those of the standard and, where the plan carries the feature, rules from a custom ruleset uploaded by the user – generating diagnostic reports, exporting them as a verifiable package and sending automated capture reports by email. Accounts can be grouped into enterprises with shared visibility and organised into projects. Where a plan carries the Testbench feature, the service additionally provides tools to plan and drive certification runs and single orders against real or virtual vehicles, to stand a virtual fleet on a broker for interop testing, and to benchmark vehicle behaviour. Where a plan carries the Monitoring feature, the service holds permanent connections to customer brokers, derives an operating history from the traffic and raises preventive maintenance due dates from it. A checked run may be judged against a layout ruleset and a check profile chosen by the user, and against requirements another enterprise has published. The service is intended to support engineering review and integration analysis.

The same software is offered as a hosted service operated by us and as a dedicated installation operated by the customer. These terms apply to both; where a clause names the operator, it means whoever runs the installation in question. On a dedicated installation, data is stored on the customer's own infrastructure and the sections on hosting and processors describe that infrastructure instead of ours.

User Accounts

  • Users must provide accurate registration information and keep account credentials confidential.
  • Users are responsible for all activity performed through their account.
  • The operator may suspend or delete accounts that misuse the service, violate these terms or create operational risk.

Permitted Use

  • Users may upload only files and message captures that they are authorized to process and analyze.
  • Users must not upload passwords, private keys, access tokens, unnecessary personal data, unlawful content or third-party confidential information without authorization. This includes custom rulesets: a file derived from a vehicle manufacturer's integration documentation may only be uploaded where the user is entitled to process that documentation.
  • Users must not attempt to disrupt the service, bypass quotas, probe security controls or access data belonging to another user or another enterprise.
  • Users must only connect capture profiles to brokers they are authorized to use, and must only enable publishing to a target broker under their control.
  • Users must only enter email addresses as report recipients where the recipient is entitled to receive the findings concerned.
  • Users must only share a report with a partner enterprise where the receiving party is entitled to receive its contents.
  • Users must only command, drive or otherwise move a vehicle through the testbench where they are authorized to do so, and must confirm before every live run that the plant is in test mode. Users must only stand a virtual fleet on a broker under identities that do not collide with real equipment reachable on it, and only where they are authorized to occupy that broker.
  • Users who join an enterprise accept that their uploads, captures, certification runs and reports become visible to the other members of that enterprise.

Analysis Results

  • Reports are generated automatically and are provided for diagnostic guidance only.
  • The service does not provide official certification, safety approval, legal advice or operational release approval.
  • Users remain responsible for validating reports before relying on them in engineering, compliance, safety or business decisions.
  • A report may be exported as a package holding the report, the analyzed file, the cleaned messages and the references used. Passing such a package to a third party discloses the underlying operational data, not only the verdict; the user decides who receives it.

Plans, Limits and Availability

  • A plan limits scope and term: the number of users, projects, MQTT profiles and custom rulesets and the period for which the plan runs. Message volume is limited on the free plan only.
  • The service may in addition apply file size limits, rate limits, user roles, administrative message quotas and other operational restrictions.
  • When a term ends, the account or installation becomes read-only. Recorded data, reports and exports remain reachable; new analyses do not start. A free account is deleted instead, as described under Retention and Deletion.
  • The operator may update, suspend, restrict or discontinue the service for maintenance, security, abuse prevention or operational reasons.
  • No uninterrupted availability or error-free operation is guaranteed.

Stored Data

Uploaded files, cleaned messages and reports may be stored on the application server until deleted by the user, an administrator or operational maintenance. Users should not upload data that they are not permitted to store on hosted infrastructure.

Liability

To the maximum extent permitted by applicable law, the operator is not liable for indirect damages, lost profits, production downtime, data loss or decisions made based on automated analysis results. Mandatory statutory liability remains unaffected.

Changes to Terms

The operator may update these Terms and Conditions when the service, legal requirements or operational needs change. Continued use of the service after publication of updated terms constitutes acceptance of the updated terms.

Cookie Notice

The application uses a technically necessary session cookie to keep users signed in and to protect authenticated areas. No advertising cookies or tracking cookies are intentionally used by the application. If analytics, marketing tools, embedded media or third-party tracking are added in the future, this notice will be updated and consent will be requested where required.

Hosting and Processors

The hosted production service runs on a Hetzner server in Falkenstein, Germany. Other instances operated by us - the customer portal and internal test instances - run on Hetzner servers in Helsinki, Finland; both are within the EU. Hetzner provides the server infrastructure and the backup storage used to operate the application. Email delivery is performed through the configured email provider for the domain logistixpert.de.

Support tickets leave the application. Opening a support ticket transmits the ticket text, the reporter's username and email address and any attached file to the operator's customer portal, which is a separate system operated by us. An administrator may also download a diagnostic bundle: it contains the installation's configuration, recent log entries and a list of the accounts on it, so it carries usernames and email addresses. Attaching it to a ticket transfers those to the operator. Both are voluntary acts by a user or administrator.

Uploaded files, captured messages and generated reports are stored on the application server unless deleted through application functions or administrative maintenance.

Where a user configures a capture profile, the application connects to the broker specified by that user, and, if publishing is enabled, to the second broker specified by that user. Where the broker service is enabled, the application additionally runs brokers of its own on the application server, reachable from the internet on the ports it hands out. These systems are chosen and operated by the user, not by the operator of this service.

Contact

For support, privacy requests, legal questions or abuse reports, contact:

support@logiq-vda5050.com