For support and field teams at robot makers
Is the fault data complete before your engineer opens it?
A customer sends logs after a robot fault. A file is missing, or the recording stops before the event, and nobody notices until an engineer opens it. We want to check each fault package against your own support checklist before analysis starts. Right now we are finding out whether that is worth doing.
Tell us about your last three cases See an example result
Status: early. We have not run this for a customer yet, and there is no product. We want to hear about real fault cases first.
What gets checked
Five things, in this order. The rules come from your checklist, not from us.
The file is there
Every file or data stream your checklist requires.
The file can be read
It opens and parses. A truncated or corrupt file is reported as such.
The fields are there
The fields your engineers need exist in the data.
The time range covers the event
The data spans the period you require before and after the event time you gave us.
It matches the case
Device ID and software, firmware and configuration versions agree with the ticket.
How a first check would work
- 01
You give us your checklist
We write it down as a rule set with a version number. You approve it before anything is checked.
- 02
You share past fault packages
Share only the ones you are allowed to. We ask who owns the data first.
- 03
We check each package
Each one is checked against the approved rules. The original files are not changed.
- 04
You get a report
It comes with a draft follow-up request for the customer. Your engineer reviews it and decides whether to send it.
The report
- The rule version you approved.
- A list of the files received, with size and hash.
- A result for each rule, and where in the data it comes from.
- What is missing and what still needs your confirmation.
- A draft follow-up request for your engineer to review.
- What was checked, what was not, and the limits.
Each result is one of four: met, not met, unknown, or not applicable. We use “unknown” when the data cannot settle it, for example when a device clock cannot be mapped to UTC.
| Rule | Result | Why |
|---|---|---|
| System log present | Not met | system_log.jsonl is not in the package |
| Motion data covers the event | Met | data spans 10 min before to 5 min after |
| Firmware matches the ticket | Not met | ticket says 4.2.1, device file says 4.1.9 |
| Device clock maps to UTC | Unknown | no time sync record in the package |
What it does not do
- It does not find the cause of the fault.
- It does not say a robot is safe or can go back into service.
- It does not contact your customers. Your team sends any follow-up.
- It does not decide warranty, liability or SLA questions.
“Complete” means the package meets the version of the checklist you approved. It does not mean the data is enough to find the cause.
Your data
- Before you send anything, we put in writing who owns the data, what you are allowed to share, who and what may process it, and how long we may keep it.
- We do not use your data for training, and we do not mix it with data from other companies.
- We treat every package as untrusted input. We do not run scripts or install anything it contains.
Questions
What is a fault data completeness check?
A check of whether the logs and files a customer sent after a robot fault contain what your support checklist requires: the files, readable contents, the required fields, a time range that covers the event, and device and version details that match the ticket. It does not look for the cause of the fault.
Could we do this with our own script?
Possibly. If a short script already catches everything on your checklist, you do not need us. We would rather find that out early, by comparing both on the same package.
Is there a product I can install?
No. We have not checked a real fault package yet. If the problem is real for your team, a first step would be a fixed-scope check of a few past packages against your rules.
Do you diagnose faults?
No. We only check whether the data your engineers asked for has arrived in a usable state.
Who decides what a complete package is?
You do. We do not guess what a robot should log. The rule set is yours and carries a version number.
What are you asking for right now?
A short reply by email about your last three fault cases: how the data reached you, what was missing the first time, and how many times you had to ask again. A description is enough.
Contact
For pricing, write to us. Please do not attach fault data to a first email.