Robot Diagnostics: Retain Severity and Device Identity
Retain DiagnosticStatus severity, component identity and supporting values so robot health displays remain traceable beyond a single coloured indicator. This guide concerns robot integration and delivery review. The proposed observations are editorial assessment guidance, grounded in the linked original documentation and subject to the deployed version. They do not describe an on-site test of a particular machine or establish whole-system acceptance from a single interface response.
Identify the reported component
The definition concerns an individual component. Retain name, hardware_id and deployment context so the record identifies the device or check it describes. Repeated names across robots need additional identity. A recently healthy component report should not automatically become a statement that every function of the complete robot installation is operating correctly.
For this review, identify the delivered device, software and configuration revisions first. Record unsupported, disabled and untested capabilities separately. Evidence from another model is useful context, but cannot establish what the delivered combination actually provides. Keep the original input beside the settings used to interpret it.
Preserve the four severity meanings
The definition lists OK, WARN, ERROR and STALE. Preserve those meanings rather than converting stale data automatically into a device error or retaining old OK indefinitely because no new ERROR arrived. Keep original levels and presentation rules, identifying how the project assesses update age and missing diagnostic observations alongside the supplied component state.
Retain the original input and the reason for the decision, rather than a successful screenshot alone. Change only the variables agreed for the comparison, and keep the before-and-after configuration. List conditions that were not exercised explicitly; they should not silently become part of the accepted operating range.
Retain messages and supporting values
Keep the status message and associated key-value entries instead of storing only the severity number. Review key names, units and observation source, especially after schema changes. Separate a display colour from the supporting evidence so maintenance staff can identify the relevant component and original observation rather than receiving an unexplained overall warning.
Use the three illustrated observations as starting questions, rather than as diagnoses of an installation that has not been inspected. Check record completeness, units and identity before selecting the next observation. An unresolved result is more informative than a confident explanation assembled from missing fields or unrelated test runs.
Review aggregation and missing components
For combined health displays, retain coverage, precedence and components with no report instead of selecting the newest or healthiest record. The message does not define every project health policy. In isolated review, include normal, warning, error and missing observations, checking that presentation retains identity and explanation rather than reducing distinct conditions to one generic fault message.
Let the site owner choose an approved isolated way to exercise relevant exceptions. Record normal operation, the exceptional condition and recovery separately. The purpose is to establish how the application recognises and explains untrustworthy input, without requiring production equipment to act on deliberately invalid results.
Deliver component-traceable health rules
Deliver severity mapping, component inventory, key definitions, aggregation and update-age rules, identifying uncovered functions. Recheck consumers after publisher changes. An overall healthy indication needs an explicit coverage boundary and a path to component evidence; one green indicator cannot establish comprehensive functional verification of the complete robot and every operating mode.
Deliver the configuration, representative samples, result table and unresolved questions together. Agree who reviews subsequent changes. The receiving team should be able to select one conclusion and trace it back to its input and decision path without relying on the original author to reconstruct the missing steps.
Original documentation and further reading
Continue with related articles in this section, or use selection guides to prepare the next review. Apply the device-specific documentation and agreed operating conditions when implementing a test.