Collapse All Expand All

Version: 10.2.1c and 10.2.1c SP3

Resource Center Home

To set your circuit source feature classes as sources in ArcCatalog, you must first create the circuit source object class. Then create a relationship class between the feature class you've designated as a source and the CircuitSource object class.

The CircuitSource table is a key object class. It stores information about the source of a circuit and is how Feeder Manager 2.0 begins its search for connected features. You must create a separate relationship class for each feature class in the network that may possibly contain features acting as circuit sources. Feeder Manager 2.0 will only trace circuits that have a matched pair of one CircuitSource object and one junction feature. Substation circuit breakers and reclosers most commonly serve as circuit sources. The relationship cardinality does not require that each circuit source object have a related feature, but each circuit source object that does have a related feature can have no more than one.

Create CircuitSource Object Class

Add this table to your geodatabase. Add each of the required fields listed below. You can change the names of the fields, but the field model names assigned later must have the EXACT spelling. There are no required domains for this feature class. Your table may include additional fields.

 

 

Convert the CircuitSource Object Class to an ArcFM Object

Use the ArcFM Solution Object Converter to convert the objects to ArcFM objects. If you do not convert, you will not have the autoupdater you need in an upcoming step.

1. In ArcCatalog, right-click the CircuitSource object class you just created.
2. Select ArcFM Solution Object Converter.
3. Select the Convert to user ArcFM objects option and click OK.
4. Click Yes at the warning.

 

Assign Object Class and Field Model Names

Assign the following model names to the CircuitSource object class, which you just created. Note that the field names shown are from the Minerville data model. Your field names may be different but model names must be exact.

Object Model Name: CIRCUITSOURCE

Field Model Names:

*When populating the CircuitSource table, remember that each value in the FeederID field must be unique. This field should have a NOT NULL constraint applied as well. Further, we strongly recommend that you set a unique constraint on the field (in both the CircuitSource table and the CircuitSourceID table). Oracle and SqlServer both have the ability to set a unique constraint. If you set the constraint, uses cannot make the mistake of assigning duplicate FeederIDs to different feeders, which is not supported.

 

Assign Autoupdaters

Assign the ArcFM Internal FeederID Update autoupdater to the On Feature Update event of this table. You can do so via the Object Info tab in the ArcFM Properties Manager.

 

Create Circuit Source Relationships

Feeder Manager 2.0 requires a separate relationship class for each feature class in the network that may possibly contain features serving in the role of a circuit source (i.e., a source of power for the electric distribution network and a starting point for Feeder Manager’s tracing actions).

Feeder Manager 2.0 will only trace circuits that are represented by a matched pair consisting of one CircuitSource object and one junction feature. Many utilities use Circuit Breakers exclusively as the source of a circuit but some also use Reclosers as the source point for a circuit. Also, Circuit Breakers may exist in a distribution system and not be the source of a circuit. For these reasons, having an object that is related to the appropriate feature classes provides the flexibility necessary to model all the possible conditions. Feeder Manager 2.0 builds the list of Feeders by starting with the records in the Circuit Source object and determining the attributes of the feeders. It then traverses all defined relationships to associated features to establish starting points for tracing the network.

The relationship cardinality does not require each circuit source object to have a related feature, but each circuit source object that does have a related feature can have no more than one.

Feeder Manager 2.0 traverses the relationships defined for the Circuit Source object class to acquire the starting location on the geometric network for circuit tracing. You can define relationships between Circuit Source and multiple classes (including ones that don't represent the start of a circuit). Feeder Manager 2.0 checks the following three conditions before traversing the relationship:

If all three conditions are satisfied, then Feeder Manager 2.0 treats the associated feature class as a starting feature for a circuit trace.

Things that ensure correct behavior:

Notes on Relationship Keys

Feeder Manager 2.0 builds the list of Feeders by starting with the records in the Circuit Source object and determining the attributes of the feeders. It then traverses all defined relationships to associated features to establish starting points for tracing the network.

If only one feature class will be related to the CircuitSource class, then add to the CircuitSource object class a foreign key field to hold ObjectID values from the origin feature class (ObjectID is always the primary key field for a feature class).

In this example, the Tagged Values for the relationship between the DynamicProtectiveDevice and the CircuitSource would designate the OriginForeignKey as DynamicProtectiveDevObjectID. The OriginPrimaryKey would be the ObjectID of the DynamicProtectiveDevice.

If you have defined subtypes for these feature classes, you can specify the relationship rules between them to include minimum and maximum cardinality for the source and destination. In this case, you would define the relationship between the subtypes representing the Circuit Breaker and those for the Circuit Source as a 0..1-to-0..1. This would allow any of the three subtypes for CircuitSource to have up to one DynamicProtectiveDevice associated with it.

To relate more than one feature class to the CircuitSource object class, then you have two choices. You may add to the CircuitSource class a separate foreign key field for each related feature class to hold the feature class ObjectID. This choice entails leaving N-1 of the foreign key fields unused for each CircuitSource object, where N is the number of related feature classes, since each CircuitSource object is allowed to relate to at most one feature. Alternatively you may add to each related feature class a single foreign key field to hold a CircuitSource ObjectID. This choice leaves an unused foreign key field only for those features that have no related CircuitSource object.

 

Test the Relationship

Faulty CircuitSource relationships are a leading cause of failure in configuring data for use with Feeder Manager 2.0. You can easily test the validity of a CircuitSource relationship by following these steps:

1. Start ArcMap.
2. Add a layer for the destination feature class of the relationship (or else open a map document that already has that feature class as a layer).
3. Select either List by Drawing Order, List by Source, or List by Visibility in the Table of Contents. Right-click on that layer in the Table Of Contents (either the List By Drawing Order or List By Source) and from the context menu choose Joins and Relates > Join.
4. Select "Join data based on a pre-defined relationship class" in answer to the question, "What do you want to join to this layer?"
5. Select the name of the relationship class that you wish to test from the dropdown list where it says "Choose the relationship class to base the join on."
6. Under Join Options, select Keep All Records.Click OK.
7. Back in the legend, right click on the layer again and from the context menu choose Open Attribute Table.
8. In the table that appears, look for the column named after the field that received the FEEDERID model name in the CircuitSource class in this step of the configuration. If that field name happens to be the same as the name of a field in the feature class, then the column name will include a class name prefix on one or the other so they may be distinguished. You want to be sure to get the FeederID column that comes from the CircuitSource class, and not from the feature class.
9. Any empty rows of the table for which the FeederID column was identified in the previous step represent features that do not have a related CircuitSource object (or else they are related to a CircuitSource object that has a null or blank FeederID value).
10. Repeat 2 - 8 for each feature class that is supposed to be related to the CircuitSource class.
11. Repeat 2 - 9 again from the point of view of the CircuitSource class as the starting point of the Join. That is, add the CircuitSource class as a layer in the map, and from it establish a join based on the existing relationship, etc., and try to determine, from the joined table view, whether all of the CircuitSource objects that you expect to have a related feature do in fact have one.

 

 

---

Send Comment to ArcFMdocumentation@schneider-electric.com