EDS for Developers

This page explains the engineering model behind this prototype. It uses simplified, fake XML only. It is not a KBL/VEC implementation and should not be treated as a source of truth for proprietary harness data.

1. What is EDS?

EDS means Electrical Distribution System. In an automotive context, it is the wiring, connectors, terminals, splices, grounds, fuses, relays, electronic modules, sensors, loads, and related electrical connection information that lets power and signals move through a vehicle.

At a practical engineering level, an EDS answers questions such as:

• How does battery power reach a lamp, pump, ECU, sensor, or switch?
• Which connector and pin is used at each interface?
• Where does a circuit branch, splice, pass through a fuse, or terminate at ground?
• Which nodes are electrically connected, directly or indirectly?
• Which parts of the network are dangling, disconnected, duplicated, or impossible to validate?

This prototype focuses only on connectivity. It intentionally ignores real harness complexity such as wire gauge, insulation, color, terminal part numbers, option codes, variants, packaging, geometry, and manufacturing process data.

2. What are KBL/VEC?

KBL and VEC are automotive harness data exchange formats used in industry workflows. They can describe electrical harness structure, connectors, wires, cavities, terminals, parts, variants, and related engineering data. Real KBL/VEC files are complex and often proprietary.

This workbench does not parse real KBL or VEC. Instead, it uses a deliberately tiny XML shape that borrows the idea of connectors, pins, wires, component references, splices, and internal connector pin connections:

<Harness>
  <Wires>
    <Wire id="W1" fromConnector="C_BATTERY" fromPin="1"
          toConnector="C_FUSEBOX" toPin="1"/>
  </Wires>
  <InternalConnections>
    <Connection from="C_FUSEBOX:1" to="C_FUSEBOX:2"/>
  </InternalConnections>
</Harness>

The purpose is to prototype graph ingestion, traversal, visualization, and validation without depending on real customer, OEM, supplier, or proprietary data.

3. Importer pipeline

The XML parser does not directly become the graph anymore. It first builds a normalized raw import model, then a resolver turns references into graph edges:

XML
  -> RawHarness
  -> Resolver
  -> ParseResult edges/issues
  -> Graph
  -> paths/validation/API/UI

This split matters because real KBL/VEC-style data is reference-heavy. A wire may point at connector and pin objects, a component may point at connector references, and a splice may collect several endpoint references. Direct field extraction is too fragile once XML starts using lookup tables and object identity.

The resolver isolates domain mapping from graph algorithms. It validates connector and pin references, keeps syntactically valid unresolved endpoints with warnings, skips malformed endpoints, expands splice fan-out, and emits typed graph edges. DFS, BFS, reachability, validation, and visualization then operate on the normalized graph without caring how the XML represented the source objects.

4. What is topology?

Topology is the shape of the electrical network: what is connected to what. It is different from physical layout. Two connectors may be far apart in the vehicle, but topology only cares that a wire or internal connection links their pins.

In this workbench, topology is represented as nodes and edges:

• A node is a connector pin endpoint, such as C_FUSEBOX:2.
• An edge is a connection between two endpoints, such as a wire or an internal pin connection.

The SVG topology view is intentionally simple. It does not attempt to draw a real harness layout. Its job is to show graph structure, branches, and highlighted paths clearly enough for engineering inspection.

5. How connector:pin becomes a graph node

The parser normalizes every endpoint into a stable text key:

connector + ":" + pin

For example, this XML wire:

<Wire id="W1" fromConnector="C_BATTERY" fromPin="1"
      toConnector="C_FUSEBOX" toPin="1"/>

becomes two graph nodes:

• C_BATTERY:1
• C_FUSEBOX:1

and one edge:

{"from":"C_BATTERY:1","to":"C_FUSEBOX:1","kind":"wire","id":"W1"}

Whitespace is trimmed. Missing connector names, missing pin values, or malformed internal connection endpoints are skipped and reported as validation issues instead of crashing the server. If a connector or pin reference is syntactically valid but not declared in the fake lookup tables, the resolver keeps the endpoint and returns a warning so the graph remains inspectable.

6. What path tracing means

Path tracing means finding a sequence of connected graph nodes between a start endpoint and a target endpoint. In an EDS graph, this can answer questions like, "How can battery positive reach ground through this simplified circuit?" or "Which intermediate connector pins are involved between the source and load?"

A path contains both the visited nodes and the edge metadata between them. A simplified path might look like:

C_BATTERY:1 -> C_FUSEBOX:1 -> C_FUSEBOX:2 -> C_SWITCH:1

The corresponding edges explain whether each step came from a wire, an internal connector connection, a splice-like branch, or an unknown connection type.

7. DFS vs BFS

DFS, or depth-first search, walks down one branch as far as it can before backtracking to try another branch. This is useful for enumerating all possible simple paths, but it must track visited nodes and cap the number of returned paths to avoid exploding on large or cyclic graphs.

BFS, or breadth-first search, explores the graph in layers from the starting node. Because it expands all one-step neighbors before two-step neighbors, it is a natural fit for finding a shortest path in an unweighted graph.

In this prototype:

• /paths uses DFS with maxPaths.
• /shortest uses BFS.
• /reachable uses graph traversal to list everything connected to the start node.

8. How validation works

Validation combines parser issues, graph construction issues, and graph-level checks. The output is structured so the UI can label severity and highlight related nodes.

Each issue has this shape:

{
  "severity": "warning",
  "code": "unknown_ground",
  "message": "configured ground not found in graph: KL31:1",
  "node": "KL31:1"
}

The current checks include:

• Bad wire endpoints, such as missing fromPin or toPin.
• Bad internal connection endpoints, such as blank or malformed connector:pin values.
• Importer warnings for unknown connectors, unknown pins, duplicate connector/pin/component declarations, invalid component connector references, and one-endpoint splices.
• Duplicate edges, reported as informational issues rather than fatal errors.
• Unknown configured sources or grounds, reported as warnings.
• Nodes that cannot reach any configured ground, reported as errors when at least one configured ground exists in the graph.
• Isolated nodes if graph data ever creates a node with no neighbors.

Validation does not prove that a real vehicle circuit is correct. It only checks consistency and reachability in this simplified connectivity graph.

9. Where voltage drop fits later

Voltage drop belongs after basic topology is reliable. To estimate voltage drop, the graph needs more than connectivity: it needs electrical attributes such as wire length, gauge, material, resistance, connector/contact resistance, current draw, fuse and relay behavior, splice behavior, and operating state.

A future version could layer voltage-drop analysis on top of traced paths:

1. Find candidate source-to-load or source-to-ground paths.
2. Attach resistance/current metadata to each edge or component.
3. Sum resistance along the selected path.
4. Apply Ohm's law for the relevant current case.
5. Report expected voltage at each endpoint and flag excessive drop.

That is intentionally out of scope for this prototype. The current goal is to make endpoint extraction, graph creation, traversal, visualization, and validation easy to inspect before adding electrical calculations.