Attribute Push Priority

Designers push attributes from the Designer XI application back to the GIS when their design is complete. These attributes come from many sources including those generated by the application itself, stored with the CU, stored with the Macro CU, stored with the equipment specification (also known as a spec), and even those personally added by the designer. This begs the question, “What happens when there is an attribute conflict among the sources?” In other words, if the designer adds a manufacturer name that is different than the manufacturer name already stored in the CU, which name is pushed back to the GIS?

To answer the question, below is the hierarchy of push attributes. In case of a conflict, whichever is ranked higher “wins,” and that is the attribute ultimately pushed back to the GIS.

1. Attributes stored in the spec.

   IMPORTANT: You can update the attributes in the fields, but you cannot add new fields to a spec.

   

2. Attributes managed by the application (phase, operating voltage, and work function).

3. Attributes calculated by the application (load, low-side voltage).

4. Attributes personally entered by the designer using GIS Attributes.

   

5. Attributes stored in the Macro CU.

   

6. Attributes stored in the CU. There is an exception here, though. If attributes are applied at the unit level, the priority moves to 5th. Unit attributes are not overwritten by their Macro attributes.

   

As an example, the Manufacturer is outlined in the images above, and they are all different.

• In a conflict between the spec Manufacturer (General Cable Industries) and the CU Manufacturer (Schneider Electric), the spec Manufacturer “wins,” and “General Cable Industries” is pushed to the GIS (this assumes the spec is associated to the CU).

• If the designer uses the CU above (which has a Manufacturer of Schneider Electric) and types a Manufacturer of “Conductors Emporium” in the GIS Attributes, the designer “wins,” and “Conductors Emporium” is pushed to the GIS.

Recommendations

Given this hierarchy, consider where the data should be most accurate, and set the attributes at that level. In other words, keep the following in mind:

• Attributes managed and calculated by the application are at the top of the hierarchy, and thus, they always “win” in a conflict. So, do not add attributes at any lower level in the hierarchy that conflict with those managed and calculated by the application.

• If you want attributes to be largely driven at the company level, set the attributes at the spec level, and do not provide the same attribute fields to your designers. In this manner, the designers would not waste time entering values that are overwritten anyway.

  • This means more configuration work at the administrative level. You need to accommodate more attribute combinations, which means your CU and spec libraries are voluminous. But, it enhances data integrity, and the designers do not have to populate a lot of attributes.

• If you want attributes to be largely driven by the designers, leave the attributes null at the spec level, and provide the same attribute fields for your designers to populate in the application.

  • This means less configuration work at the administrative level and smaller CU and spec libraries. It gives designer more flexibility to edit their own attributes within their designs. But, it opens the door to more discrepancies and possibly errors populated by the designers.

  • A nice “middle ground” would be leave the attributes null at the spec level but then set many attributes at the CU and Macro level. In this manner, the designer is presented with attributes, but they can still override if necessary.