EXCEL-to-EDB Converter

The Excel file should consist of a single table that describes all relevant data. We assume that the first row of this table contains the table headers, which are evaluated by the conversion tool. In general, every (other) row of the table corresponds to one wire of the harness.

The description of a wire encompasses five parts:

1. The actual wire information like wire ID, wire name, wire type (like power, ground, bus etc.), and an arbitrary number of attributes of the wire.
2. Multicore information (whether the wire is twisted or shielded together with other wires), and attributes of the multicore. We also support nested multicores where, e.g., bundles of wires are twisted and then shielded together.
3. The first connection point of the wire, i.e., cavity, connector, and component to which one end of the wire is connected. The headers of all columns that belong to this group all start with the prefix “A-”.
4. The same information for the second connection point. The headers of all columns that belong to this group start with the prefix “B-”.
5. Module information specifies to which signal, harness, bus, or function a wire, component, connector, or cavity belongs.

No-wire entries: There is an exception to the rule that each line creates one wire. For instance, if the system contains components with cavities that are not connected to a wire or nested multicores that do not directly contain wires, but only other multicores. In this case, the wire information is left empty and only the relevant part is filled with data. The described objects are created but without connection to a wire. These no-wire entries have an empty Wire ID and also the other wire fields like WireType and wire attributes must be empty.

Case sensitive: The reserved column headers are case insensitive (so writing “Wire”, “wire” or “WIRE” is equivalent). In contrast, attribute names and the contents of the data cells are case sensitive.

A missing column has the same meaning as if all its fields were empty. The Name columns are an exception to this rule as described below.

Comment Columns

All columns with either an empty header or a header that starts with the character “#” are considered comment columns and ignored by the conversion tool.

Object Identifiers

Every object that should be created needs an object identifier. The IDs are used to refer to objects, e.g., at an inliner component to specify which connectors are attached to each other. We require that all object IDs are unique within their container. Here are examples for IDs:

Object Names

Apart from an ID, each object can have a name that can be displayed in EEvision. The name can either be identical to the ID, or a separate name (which does not need to be unique) can be specified. The name of an object is obtained as follows:

• If the table contains a column “Name”, then the entry in this column specifies the displayed name of the wire (it can also be the empty string when the table cell is empty; in this case, no name will be displayed). If there is no column “Name”, then the Wire ID is used as the wire name.
• Similar: A-CompName, B-CompName (for components), A-ConnName, B-ConnName (for connectors), A-CavName, B-CavName (for cavities), MCName (for multicores), SignalName (for the signal module), HarnessName (for the harness module), and BusName (for the bus module).

Object Attributes

Every object in the EDB can carry an arbitrary number of attributes. All columns whose names start with “Wire:” are turned into attributes of the wire (don't confuse “Wire” with “Wire:”). The field “Wire:xyz” defines the wire attribute “xyz”. The same applies to other objects' attributes, like “A-Comp:xyz” or “A-Conn:xyz” or “A-Cav:xyz” etc.

There is one reserved attribute name that is interpreted by the converter tool: The attribute “ color” (for wires specified in the column “Wire: color”, for components in “A-comp: color” – note the leading space in the attribute name!) contains color information. It is expected to be a space-separated list of color values. These can either be given in hexadecimal RGB notation (like “#FF0000” for red) or using the color keywords from the SVG standard like “red”, “green” etc. Color names and hexadecimal RGB values can be mixed. The value of “ color” attributes is case-insensitive.

Arbitrary Column Header: Additionally, all columns whose headers do not correspond to one of the reserved identifiers are also treated as wire attributes. This means “Wire:width” and “width” have identical meanings. If a wire attribute needs to be created whose name starts with “#”, then the form with prefix “Wire:” needs to be used; otherwise the column is treated as a comment column.

Overview on the Column Headers

Repeated Values: Object values do not need to be repeated. For instance, if several wires connect to the same component, the component appears in the table for each of these wires. In order to avoid redundancy, it suffices to specify the name, type and attribute value of the component once at its first occurrence; the remaining entries can be left empty. However, if a value is repeated, all occurrences must be consistent; otherwise a warning is printed. Which value is taken is implementation defined. Actually all fields except the Object IDs can be left empty at the repeated occurrences. The first occurrence (that must have all values defined) is the first from top, then within a row the leftmost one.

Empty Values: If an entry in an attribute column is empty, then this attribute is not defined for that object. This also means, there is no way to define empty-value attributes.

Example:

Wire Types: In the EDB data model, one can distinguish between different types of wires like power and ground wires. This information is specified in the “Type” column. Possible values for Type (case insensitive, empty string is allowed) are:

• POWER
• GROUND
• LOGICAL
• BUS
• HV
• ARC
• UNDEF (default, equivalent to the empty string)

Wire connections: By default, each wire connects to two cavities. However, also fewer and more connections are supported. If the wire connects only to zero (“unconnected wire”) or one cavity (“wire stub”), either the entries for the A-side or the B-side can remain empty or even both. If the wire connects to n > 2 cavities, the wire ID is repeated in (at least) [n/2] rows. Up to two connections per row can be specified.

Wires of type ARC play a special role. They do not represent physical wires, but instead model electrical connections within a component between its cavities. For instance, the electrical connection between the two pins of a fuse can be modeled using an ARC wire. Arc wires are not directly displayed in EEvision, but taken into account by the different analysis algorithms, e.g., when showing the electrically connected wires in “Net Mode”.

Example:

Components

Component Types: We need to distinguish between the different possible types of components. The type is specified in the column A-CompType. Possible values are (case insensitive):

• ECU
• INLINER
• SVG
• UNDEF (default, same as empty string)

ECU

INLINER

<comma-separated list of flags>:<partner connector Id>

Splices and Eyelets

Multicores

Example:

The twisting and shielding is defined as a tree, with multicores as the nodes and wires as the leaves. The “MCParent” column defines the nesting hierarchy by referring to other multicores by ID.

Multicore Types: The following values for “MCType” (case insensitive, empty string allowed) are supported:

• TWISTED
• SHIELDED
• TWSHIELDED
• UNDEF (default, equivalent to the empty string)

defining a twisting node, shielding node or both, twisting and shielding in one node. An empty value (or UNDEF) defines a logical grouping without any graphical indicators. The special value “SHIELD” just adds a shield connector wire to a SHIELDED or TWSHIELDED node.

Modules

Modules are used to group related database objects. For example, all wires carrying the same signal can be included in a module. EEvision supports different types of modules: Harness modules for grouping wires and their cavities as well as connectors into harnesses; signal modules for wires that carry a certain signal; bus modules for wires of the same bus; function modules to group wires by functions; and other modules that cannot be defined by this Excel data format.

Apart from columns describing module attributes, there can be up to three columns per module type: For instance, for harness modules, the column “Harness” contains the ID of the harness module, the column “HarnessName” specifies the name of the module if it is different from the ID. Finally, “HarnessMask” defines which objects of the current row (wire, multicore, component, connector, and cavity for both the first and second connection) should be contained in the module.

Replacing “Harness” by “Signal”, “Bus”, or “Func” yields signal, bus, or function modules.

We support two different notations for the contents of the “HarnessMask” column. The first one is a comma-separated list of tags, the other one a hexadecimal value, obtained as the sum of the tags' values. The available tags are:

If the mask column is missing or the table cell empty, a default value is used, which is supposed to cover the most common cases. For the different module types we use the following default values:

• Signal modules are expected to contain only wires. Therefore the default for “SignalMask” is “Wire” (= 0x0001).
• The same holds for bus modules. Therefore we also use “Wire” (0x0001) as the default value.
• Harness modules typically contain all elements of a cable harness, which are typically wires the cavities and the connectors they are connected to. This includes splices and eyelets, but not the components. Therefore the default value is “Wire,A-Conn,A-Cav,B-Conn,B-Cav” (= 0x0661).
• Function modules typically not only contain the harness elements, but also the components. Accordingly, we set the default to “Wire,A-Comp,A-Conn,A-Cav,B-Comp,B-Conn,B-Cav” (= 0x0771).

Example tapp1

Here is a Excel-based table (as Tapp1.csv and Tapp1.xlsx) that stores the same example design as created by the Tcl example program tapp1.tcl (or the Java example program Tapp1.java, or the Python example program Tapp1.py). The schematic diagram, as created by EEvision, looks as follows:

Example tapp3

Here is a Excel-based table (as Tapp3.csv and Tapp3.xlsx) that stores the same example design as created by the Tcl example program tapp3.tcl (or the Java example program Tapp3.java, or the Python example program Tapp3.py). The schematic diagram, as created by EEvision, looks as follows: