The workflow supports automotive network engineers in specifying and optimizing communication traffic for in-car networks. Engineers must map logical communication specifications (signals between electronic control units) onto a physical network (ECUs connected by bus systems) and actively change this mapping in response to change requests while respecting cost and capacity constraints. The workflow combines a matrix-based overview of logical communication with topology views and signal path tracing in coordinated multiple views.
The input consists of three related network specifications loaded from the NetDB company database: (a) the physical network describing how ~100 ECUs are connected by ~10–15 bus systems (an undirected hypergraph), (b) the logical network specifying ~10,000 signal communications between ECUs as {send, signal, recv} triples (a directed multigraph), and (c) the signalpath network mapping logical signals onto physical paths as {src, signal, bus, dest} 4-tuples. Additionally, the engineer receives a change request specifying required modifications (e.g., connecting an ECU to a different bus, rerouting signals, adding/removing ECUs). The logical multigraph is aggregated into a logicalcount network — a weighted simple graph where each edge carries the count of signals between a pair of ECUs — to enable scalable overview visualization.
The system generates four coordinated views. The Topology View arranges ECUs in a node-link layout mimicking familiar manually-drawn topology maps, with ECUs grouped in vertical stacks by bus connectivity. The Matrix View arranges ECUs along rows and columns (optionally sorted by bus) with communication-boxes at intersections sized by signal count, providing an overview of the logicalcount network. The SignalPath View shows filtered signal paths as a node-link diagram for a selected signal. List Views provide text-based browsing of ECUs and signals with search and filter capabilities.
The engineer explores the current network state through coordinated interactions: hovering/selecting elements triggers crossbeam highlighting in the matrix, linked highlighting in the topology view, and filtered signal lists. Through this exploration, the engineer identifies traffic patterns relevant to the change request — communication hotspots (heavily-trafficked edges), local vs. global communicator ECUs, introvert vs. extrovert bus systems, and well-directed vs. wide-spread signals. Based on these patterns and implicit knowledge of costs and constraints (bandwidth limits, delay requirements, load balancing goals, financial costs), the engineer assesses whether the current routing is adequate or whether changes are needed. If changes are needed, they formulate a modification proposal (rerouting signals, reassigning ECUs to buses, consolidating ECUs) and inspect its effects through the views. This exploration–assessment–modification cycle repeats — the engineer may discover cascading effects requiring further changes — until the engineer is satisfied that all constraints are respected and traffic is optimized.
Once the engineer judges the proposed changes satisfactory, they validate the final configuration by inspecting critical paths and verifying that no capacity constraints are violated and that load is balanced across buses. The validated change specification is then released as the new version of the network specification.