A technical domain summary for developers building graph, validation, and analysis tools around automotive wiring systems. This page is conceptual and uses fake/sample data only; it is not a description of any proprietary OEM process or dataset.
1. Wiring Systems as Engineered Networks
An automotive wiring system is the physical and logical network that distributes power, ground, and signals through the vehicle. It connects batteries, alternators, power distribution boxes, fuses, relays, electronic control units, sensors, actuators, switches, displays, lighting, pumps, motors, antennas, and chassis ground points. The system is both electrical and mechanical: it must carry current correctly, preserve signal integrity, survive vibration and temperature, fit through package space, support assembly, and remain serviceable.
From a software perspective, the most useful abstraction is a network of endpoints and connections. A connector cavity, splice leg, device pin, inline connector pin, ground lug, or fuse terminal can be treated as a node. A wire, internal component bridge, splice relationship, terminal interface, or logical continuity relationship can be treated as an edge. This lets engineering software answer practical questions: what can reach this node, what path exists between source and load, where does a branch occur, which circuits share a splice, and which portions of the system fail basic continuity checks.
Real wiring systems carry many kinds of information beyond connectivity. A production harness model may track wire size, insulation, color, material, length, bundle membership, terminal part numbers, seal information, connector housing part numbers, clip locations, grommets, coverings, takeouts, harness variants, platform options, market configurations, and manufacturing rules. A graph prototype should start with connectivity because it is the foundation, but a useful engineering tool eventually has to preserve these attributes rather than flattening them away.
2. OEM Workflow Context
An OEM electrical workflow usually starts from feature and architecture intent. Vehicle functions define required loads, sensors, control modules, networks, power modes, fusing strategies, grounding strategies, diagnostic behavior, and packaging constraints. Electrical architects and system engineers decide what modules own which functions, where power distribution happens, which communication networks are used, and how safety or regulatory requirements affect wiring.
Schematic design is the logical stage. Engineers define circuits, connector pins, splices, fuses, grounds, inline connectors, and device interfaces. The schematic shows electrical intent: source-to-load relationships, switching, protection, and signal routing. It is not primarily a manufacturing artifact. It often abstracts away physical routing, exact bundle length, clip placement, and harness build sequence.
Harness engineering turns logical intent into buildable wiring assemblies. This includes partitioning circuits into harnesses, choosing connector systems, assigning terminals and seals, determining wire specifications, routing through vehicle package space, defining branch points and takeouts, applying coverings, and checking assembly constraints. Manufacturing engineering then needs flattened formboard or 2D harness drawings, cut lists, wire lists, terminal applicator information, splice process details, continuity test definitions, and plant-specific build instructions.
The data must move between many tools and teams: electrical architecture, schematic capture, harness CAD, mechanical packaging, simulation, sourcing, manufacturing, service, and validation. That is why exchange formats and stable identifiers matter. A connector pin in a schematic must remain traceable when it becomes a routed segment in 3D, a wire on a 2D drawing, a terminal in a bill of material, and a test point in manufacturing.
3. KBL and VEC in the Domain
KBL and VEC are harness-related data exchange formats used in automotive engineering ecosystems. At a high level, they exist because wiring data is too rich and interconnected for simple spreadsheets. A harness model needs to describe electrical connectivity, physical harness structure, parts, variants, module interfaces, connector cavities, terminals, wires, coverings, splices, and other relationships in a way that tools can exchange.
KBL is historically associated with harness description and exchange in vehicle electrical system toolchains. VEC, the Vehicle Electric Container, is a more modern standardization effort intended to represent vehicle electrical system data with broader semantics. In practice, real files can be large, detailed, tool-specific, and governed by customer or supplier agreements. They are not appropriate inputs for this prototype.
For developers, the important lesson is not the exact schema. The lesson is the shape of the problem: domain data is relational, typed, and layered. A wire is not only a line between two labels. It may reference terminals, connector cavities, wire specifications, colors, cross sections, lengths, harness segments, variants, and assemblies. A connector pin may be part of a component interface, a harness connector, an inline connector, or an internal bridge. A robust importer should preserve identity and relationships even if the first prototype only extracts endpoint connectivity.
This workbench deliberately uses a simplified XML dialect. That keeps the graph work visible: parse fake XML into a raw harness model, resolve endpoint references, normalize node IDs, add typed edges, traverse, validate, visualize. If a real KBL/VEC integration is built later, it should be a separate adapter layer that maps real domain objects into the same internal graph model without exposing proprietary data in samples or tests.
4. Topology: The Connectivity Layer
Topology is the electrical shape of the system. It answers what is connected to what, regardless of where the parts are physically located. A topology view can represent power distribution, branch points, grounds, inline connectors, and device pins as a graph. It does not need to know whether a wire runs along the left rocker, through the instrument panel, or across a rear bumper harness to answer reachability questions.
Topology is especially useful because many engineering checks are graph checks. Source reachability, ground reachability, duplicate continuity, disconnected branches, missing internal bridges, unexpected alternate paths, and cyclic structures can all be found by graph traversal. Even before current, length, or resistance are known, topology can reveal whether the intended electrical path exists.
Topology should not be confused with schematic layout or physical layout. A schematic page may draw a circuit in a readable electrical order. A physical harness route may snake through vehicle packaging. A formboard drawing may flatten the harness for manufacturing. The same underlying topology can appear differently in each view. Good tooling keeps the identity of nodes and edges consistent across these views.
In this prototype, a topology node is a normalized connector:pin string, and topology edges are typed as wire, internal, splice, or unknown. That is intentionally modest, but it is enough to demonstrate path tracing, shortest path, reachability, validation, exports, and visual highlighting.
5. Schematic to 3D to 2D to Manufacturing
A typical data flow starts with schematic intent. The schematic identifies the electrical connection between components: power source, protection, switching, loads, sensors, modules, network pins, and grounds. It defines what should be connected and often includes circuit names, wire names, connector pin assignments, fuse identities, splice references, and signal names.
The 3D harness stage places this intent into vehicle packaging. Engineers route bundles through space, define branch points, clips, grommets, coverings, bend constraints, and takeouts. Wires that are simple logical connections become physical paths with approximate or exact lengths. This stage must respect mechanical constraints, serviceability, thermal zones, water paths, moving parts, crash zones, and assembly sequence.
The 2D harness stage flattens the routed design into a manufacturing-friendly representation. It may show bundle branches, connector orientations, dimensions, coverings, clips, labels, splice locations, and build notes. The 2D view is not just a drawing; it is often a bridge to downstream manufacturing data such as wire cutting, stripping, crimping, splice processing, taping, testing, and inspection.
Manufacturing needs precise, actionable outputs. That can include wire cut lists, terminal and seal assignments, applicator settings, splice definitions, connector loading instructions, bill of material, continuity test tables, formboard dimensions, label placement, and change tracking. A graph model can support manufacturing checks by making continuity explicit, but manufacturing also needs process and part metadata that go beyond topology.
The key implementation idea is traceability. A logical schematic connection should be traceable into routed segments, flattened harness branches, BOM items, and test definitions. If identifiers are unstable or relationships are lost during translation, downstream validation becomes fragile. A graph prototype can help by making identity and connectivity visible early.
6. Schematic Meaning vs Physical Meaning
Developers often underestimate how many meanings a line can have in wiring data. In a schematic, a line may mean logical continuity, a named circuit, a net, a signal, or a design intent connection. In a harness model, that same intent may be realized by multiple wire segments, intermediate connectors, splices, terminals, and internal component links. In manufacturing, the relevant objects may be individual cut wires, crimped terminals, splice sleeves, coverings, and connector loading operations.
This is why an endpoint graph should be explicit about edge kind. A wire edge is different from an internal connection edge. A splice-like fan-out is different from a direct point-to-point wire. A fuse or relay may be physically connected but electrically state-dependent. In early prototypes it is acceptable to treat all edges as bidirectional continuity, but production analysis must eventually model direction, state, protection, and component behavior.
The safest design pattern is to keep the simple graph as a derived view rather than the only source of truth. The graph is excellent for traversal and visualization. The richer domain model should still remember where each edge came from and what it means.
7. Voltage Drop Domain Meaning
Voltage drop is the loss of electrical potential along a path when current flows through resistance. In vehicle wiring, voltage drop matters because loads and electronic modules require adequate voltage under operating conditions. A lamp may dim, a motor may run weakly, a sensor reading may become unreliable, or an ECU may reset if the supply or ground path drops too much voltage.
Topology alone cannot compute voltage drop. It can identify candidate paths, but electrical calculation needs additional data: current draw, wire length, conductor material, cross-sectional area, temperature assumptions, connector contact resistance, splice resistance, fuse or relay resistance, ground interface resistance, and operating state. The same topology can have different voltage drop results depending on which loads are active and what current is flowing.
Domain engineers usually care about both supply-side and ground-side drop. A load may receive low voltage because the positive feed drops too much, because the ground return rises above chassis reference, or because both sides contribute. For analysis, the path from source to load and the path from load to ground may both need to be traced and evaluated.
A future tool could use this graph workbench as the first layer of voltage drop analysis. The workflow would be: find paths, select the relevant operating path, attach resistance and current metadata, sum edge voltage drops, and report voltage at each node. The UI could then color edges by contribution and flag the worst connectors, splices, or wire segments. That future layer depends on the topology being correct first.
8. Validation and Change Control
Validation in wiring systems is broader than syntax checking. It includes checking that every intended source can feed its loads, every ground path exists, every connector pin assignment is valid, every splice has the expected branches, every option combination is buildable, every wire has required manufacturing attributes, and every change preserves downstream consistency.
Graph validation is a useful early subset. It can catch missing endpoints, duplicate edges, unreachable branches, unknown configured source or ground points, and isolated nodes. These are not the only possible errors, but they are high-value because they affect basic continuity.
In OEM and supplier workflows, changes are frequent: feature changes, connector changes, packaging changes, cost reductions, manufacturing feedback, service fixes, and issue resolution. The data model must support comparison between revisions. For a graph tool, that means being able to diff nodes, edges, edge metadata, path results, and validation issues across versions. Even a simple prototype benefits from stable node and edge identifiers because they make change review easier.
9. Why a Graph Workbench Helps
A graph workbench gives developers and engineers a neutral inspection surface. It strips the problem down to nodes, edges, traversal, and validation while keeping enough metadata to remain useful. That makes it a good place to prototype import logic, endpoint normalization, path algorithms, visualization, and JSON export contracts before integrating with a real enterprise toolchain.
The main limitation is intentional simplification. Real EDS work includes variants, signal semantics, physical routing, component behavior, assembly constraints, and proprietary data. A small graph workbench should not pretend to solve all of that. Its value is in creating a clear, testable core: if the connectivity graph is wrong, every downstream analysis will be wrong too.