Altair EEvision™

Validator Plugin

Introduction

The purpose of the EDB Validator is to assist users who create EDB files in finding inconsistencies in the data. Such inconsistencies can lead to erroneous or at least unexpected behavior of EEvision. Typically these issues result from implicit assumptions that cannot be checked (cheaply) in the EDB Creator API. While the EDB guarantees consistency of the technical data structures, this document describes rules that define a meaningful semantic, which meets the expectations of EEvision. This meaningful semantic refers to a so-called 100% design, that describes a harness wiring that exists in reality. However, so-called 150% designs, that can be stored in the EDB and are subject to be configured before displayed, can be checked too (with reduced accuracy).

Semantic of Connectivity

The table below illustrates the rules for the relations Component ⇒ Connector ⇒ Cavity ⇒ Wire. It shows the rules for the required number and types of Connectors per Component, and the required number and types of Cavities per Connector & Component, and the required number of connecting Wires.

The abbreviation MFI stands for “MALE, FEMALE, INVISIBLE” and the abbreviation MF stands for “MALE, FEMALE” and the abbreviation HS stands for “HALFDOT, SPLICED” and the abbreviation INO stands for “IN, OUT, IO”. The Validator reports violations as information, warning or error. These semantic restrictions apply to 100% designs.

(*) However, for 150% designs, the cnt columns in the SPLICE and EYELET rows are not checked, because the configuration may reduce or extend them in ways that are unpredictable by this Validator.

Partner Relations:

Partner relations Connector ⇔ Connector are only allowed between Connectors of the same INLINER, and partner relations Cavity ⇔ Cavity are only allowed at partnered Connectors (of an INLINER). Those partner relations are defined by Creator API's EdbPartnerConnector() and EdbPartnerCavity(). The Validator reports any violations of these partner rules as an error message. Connector partner relations between two MALE or two FEMALE are reported as a warning message.

Semantic of Modules

Modules form a collection of objects in an EDB. They serve different purposes: Configuration modules are used to adapt an EDB to a given configuration (from the 150% model to a 100% model of a vehicle). Function, Harness, Signal and Bus modules are used to display groups of objects that belong together because they are part of a function, harness, signal or bus in the vehicle. The member objects are added to a Module by the Creator API's AddObject2Module(). The table below illustrates the rules for the members of those Modules by type.

The abbreviation CCCMW stands for “Component, Connector, Cavity, Multicore, Wire”. The ✔ in the “disjoint” column means, that all Modules of that type must be disjoint in respect of their members. For example, the member Wires of a Signal must not be members of another Signal (however, can be members of another Harness or Bus, for example). The “disjoint” rule can only be checked in 100% designs. The Validator reports violations as information, warning or error.

(*) At HARNESS Modules, the disjoint rule only refers to its Wire members, not necessarily to its other members.

(*) The UNDEF Module members may include sub-modules of almost any type. The abbreviation SBHFU stands for “SIGNAL, BUS, HARNESS, FUNCTION, UNDEF”. Those sub-modules are not required to have a Name; they should form a tree and must not include cycles. All leaves of this tree commonly define the contents of the root Module.

(*) The CONFIG and ALWAYS Module members may include sub-modules of the types CONFIG or ALWAYS. Those sub-modules are not required to have a Name; they should form a tree and must not include cycles. But any sub-module with a type other than CONFIG or ALWAYS is considered as a leaf in this tree, and will be processed as an object by itself and not descending into it. All leaves of this tree, including the non-CONFIG/ALWAYS Modules, commonly define the contents of the root Module (and will commonly control the configuration process). The CONFIG and ALWAYS Modules may include dynamic pair or attr definitions as created by AddObjectPair2Module() or AddObjectAttr2Module(). The CONFIG and ALWAYS Modules are NOT available in 100% designs.

List of Checks and Reported Messages

The following table contains a list of all issues that are currently reported by the EDB validator. The first column shows the Message ID that is also output by the validator. The second column contains details about the issue and its causes.