Service harness fault isolation and configuration restoration

ESV-S05-SOP-03   Serviceable satellite   Simulation procedure



Find and correct a planted service-harness routing error using a declared connector map. Preserve the upper and lower modules, then demonstrate that the bay can close with the intended configuration.

Use this procedure to author and assess a controlled simulation with the Serviceable satellite model, version 4. This is a concept-model training exercise. It does not authorise real hardware work or establish flight qualification.

Before the exercise

Use an unpowered concept-model exercise with a baseline harness map and separately supplied simulated diagnostic results. Define the intended endpoints, stow zones and door envelope before authoring. This is configuration reasoning, not live electrical troubleshooting.

Identity and provenance: ESV-S05-SOP-03 · S05 · model v4 · 25 October 2026

Explore the model and related procedures: https://eonspaceventures.com/models/#s05

1 Identify the diagnostic scope

Model labels: bus, bay.module1, bay.module3

Select the bus and the upper and lower service modules. Confirm that the middle module is outside this exercise scope.

Check: A correct scope record prevents unrelated module changes.

2 Load the baseline connections

Model labels: bay.module1.connectorleft, bay.module1.connectorright, bay.module3.connectorleft, bay.module3.connectorright

Read the author-defined endpoint map and label the four relevant connector positions. Save the expected pairing.

Check: Connector identity must come from the supplied map, not apparent proximity.

3 Establish isolation and access

Model labels: door, door.latchupper, door.latchmiddle, door.latchlower

Confirm the recorded unpowered state, release the latches and place the door in its reviewed access pose.

Check: The diagnostic sequence stays blocked without isolation and access confirmation.

4 Trace the left route

Model labels: bay.harnessleft, bay.jumper1, bay.module1.connectorleft

Follow the left harness and assigned jumper to the mapped upper-module endpoint. Record its current configuration.

Check: Preserve the observed route before changing it.

5 Trace the right route

Model labels: bay.harnessright, bay.jumper2, bay.module3.connectorright

Follow the right harness to the lower module and compare its jumper endpoint with the baseline map.

Check: Both routes must be compared before a fault is declared.

6 Resolve the crossed jumper finding

Model labels: bay.jumper1, bay.jumper2, bay.module1.connectorright

Plant a swapped endpoint in the scenario. Place a hold, select the conflicting jumper and explain the map mismatch.

Check: Do not correct both jumpers blindly or continue on an unresolved mapping conflict.

7 Protect the unaffected route

Model labels: bay.harnessleft, bay.module1.connectorleft, bay.wall.left

Mark the accepted route as unchanged and define a protected area while the affected jumper is moved.

Check: Any unintended change to the protected route records an assessment error.

8 Disconnect the affected jumper

Model labels: bay.jumper2, bay.module1.connectorright, bay.harnessright

Disconnect only the reviewed incorrect endpoint and move the affected jumper into its authored service pose.

Check: The chosen object and disconnection record must match the held fault.

9 Restore the intended endpoint

Model labels: bay.jumper2, bay.module3.connectorright, bay.wall.right

Move the jumper to its specified right-side route and reconnect it to the baseline lower-module endpoint.

Check: The correct endpoint and routed pose must both agree with the map.

10 Repeat the simulated diagnostic

Model labels: bay.jumper1, bay.jumper2, bay.module3

Request the scenario diagnostic card and compare its result with the intended configuration and action history.

Check: Use the supplied diagnostic result; do not infer continuity from the mesh.

11 Restore bay closure

Model labels: bay.harnessleft, bay.harnessright, door.inner, door

Check both routes against the authored door envelope, then return the door to its closed and latched state.

Check: A trapped route or open latch prevents completion.

12 Transfer the corrected configuration

Model labels: bay.module1, bay.module3, bay.jumper2, door

Submit baseline, observed fault, corrected map, simulated diagnostic result and final bay state for review.

Check: A second operator must be able to identify what changed and what stayed unchanged.

Assessment and completion

Score route identification 25, evidence-led diagnosis 25, controlled correction 20, restored closure 15 and handover 15. Unconfirmed isolation, changing an unrelated module or accepting the wrong endpoint is a critical stop. Diagnostic cards must retain their simulated provenance.

Authoring and headless handoff

Keep connector pairing and diagnostic state in explicit scenario records. Bind actual jumper and harness identifiers to authored transforms. No voltage, pin assignment or live test method is established by this model. Preserve the unchanged route and baseline revision in the event log.

Reuse the exact GLB and component identifiers above. Verify the supported Genesis import and binding path; the current Creator scene driver can generate a different model. This document and its JSON describe authoring intent, not completed interactions. Preserve one model revision and record actual lesson, job and review identifiers during execution.
