Skip to main content
Faults recorded against a vehicle or a component. Delivered daily. Update key: external_system_id

Columns

Rules

  • Every row needs at least one of vehicle_number / component_serial_number.
  • Every row needs at least one of subsystem / product_group_code.
  • vehicle_number and component_serial_number must resolve within the project, or the file is rejected.
  • slot_position only means something together with product_group_code — the pair identifies a slot on the vehicle’s type. The vehicle type comes from the vehicle; never send it.
  • location is free text and is never parsed. Send the position in slot_position if you want it recorded as a position; writing Bogie 1 in location does not resolve a slot, and neither field replaces the other.
product_group_code and slot_position are the only soft references in the entire import. If either cannot be resolved, the row is still imported with that field empty and a warning is logged rather than the file being rejected. Because it is only a warning, a systematically wrong code will import silently for months.One exception: a row whose product_group_code does not resolve and whose subsystem is empty has no classification left at all, and is rejected with a row number — such a row could not be stored anyway. Note that on a component-only row the code resolves through the mount-derived vehicle, so for this row shape a gap in the configuration history can be what triggers the rejection.
Unlike every other file, defects reports all of its error classes in one message rather than aborting at the first failing stage.

Resolution rules

The import resolves the fields the row names first, then fills those still empty from the configuration record covering defect_datetimemounted_at at or before it, and either still open or dismounted after it. Derivation reads whatever mount history is already loaded, so vehicle_configurations must be imported before defects.
  • Explicit values win. slot_position is matched against the slots defined on the resolved product group or any of its ancestors on the vehicle’s type; the nearest node wins. The search never descends — a code above the slot’s node does not resolve. Surrounding whitespace is trimmed before matching. A resolved position is never overridden by the mount history.
  • A component derives its vehicle and slot. A row with a component_serial_number takes its missing vehicle_number and slot from the covering mount, and through the derived vehicle resolves its product_group_code as well. A mount on a different vehicle than the row resolved leaves the slot empty; the warning names both vehicles.
  • A slot derives its component. A row with a resolved vehicle and slot but no serial takes the component mounted there at defect_datetime.
Overlapping mounts at defect_datetime derive nothing and warn; a missing covering mount derives nothing and is silent. Re-imports treat all four resolved links — vehicle, component, product group and slot — identically: a resolved value overwrites the stored one, an unresolved value keeps it. A warned row can therefore still carry a value from an earlier import, and an empty column never clears a link — corrections require re-sending a row that resolves.

Example

The first row pins the fault to bogie position 1. The second leaves slot_position empty — the traction inverter is not a slotted position on this type, and location carries what is known about where it sits.

Why a file gets rejected

N is the row number in the file, and the quoted values are echoed from that row. Warnings, which do not reject the file. There are six, one per situation, and each is emitted only when the field it names actually ends up empty (<ts> is the row’s defect_datetime):