In order to generate isometrics from AutoPLANT using the new AP2EC conversion process the AutoPLANT component classes need to be properly mapped to the most suitable component classes available in the OpenPLANT 3D schema, along with other information like the class properties, relationships, value maps, etc. The AutoPLANT AP2EC conversion process generates a set of ECXML files for the component assembly which includes detailed information about the component type, component relationships, component ports and connectivity information, and other necessary information pertaining to component location, properties. These ECXML files are then used by the OpenPLANT Isometric Manager to generate isometric drawings for those components/assemblies.
The mappings are done using the Class Editor software, which allows supplementing the AutoPLANT supplemental schema on to the OpenPLANT 3D schema. However, in an AutoPLANT installation, only the merged schema would be available, which is basically both the OpenPLANT 3D and AutoPLANT supplemental schema blended together.
The following few steps detail the class mapping procedure.
In order to export necessary information to write to the ECXML for consumption by OPIM, several AP class properties need to be mapped to existing properties in the OpenPLANT schema. For example, the COMP_LEN property in AutoPLANT, which defines the total length of the several components from one end to the other, has been property mapped to END_TO_END_LENGTH for every applicable class. Thus, the value stored in the COMP_LEN field in AutoPLANT component would then be recognized by the conversion process as END_TO_END_LENGTH, and would be consumed by OPIM accordingly.
Several property maps have already been defined in the classes higher up in the hierarchy, from which the classes at the bottom of the hierarchy derive their properties, with some specialized addition properties of their own. The PIPING_COMPONENT class in the OpenPLANT schema houses several properties used by the piping components under it, however there are several properties that are only to be added for special components, and should not affect other classes in the PIPING_COMPONENT hierarchy. The class hierarchy in the OP schema helps in organizing the classes under appropriate generic parent classes.
As before, the procedure to define a property map involves adding the ‘AutoPLANT_PDW_Property_Map’ from the custom attributes addition dialog. Once that is done, an empty section for the AutoPLANT_PDW_Property_Map should appear. Write down the AP property in the PropertyName section for the new custom attribute, as shown in the image on the right.
Value maps are required to map values like component end conditions in AP to the ones defined in the OP schema. For example, the end Threaded Female end condition defined in AP is SCF, whereas the Threaded Female end condition defined in the OP schema is FT. Even though you may property map the END_COND_1 to END_PREPARATION in OP, the value map would still have to be defined because both have a different way of representing something which basically means the same. Unlike numerical values like those in the COMP_LEN field or the PIPE_OD_M field, the end conditions contain strings which are different for both the AP and the OP system. Similarly, the RATING field in the AP system would have a different way of representing valve/flange ratings, whereas the OP schema would have a different rating value representation.
The procedure for defining the value map starts by first defining the correct property map, as has been detailed in the Property Mapping section above. The additional work required for defining a value map is to set IsValueToBeMapped to True, and to specify the ValueMapName which points to a sub-class under the VALUE_MAP class in the schema.
Consider the rating value map, for example. The image below shows how the IsValueToBeMapped and ValueMapName have been defined in the AutoPLANT_PDW_Property_Map custom attribute for the PIPING_COMPONENT class.
Notice that IsValueToBeMapped has been set to True, and the relevant VALUE_MAP sub-class has been specified for ValueMapName. Now, using Ctrl + F, search for the already defined RATING_VALUE_MAP to see what it looks like, and it leads us to the class shown in the image below:
It is important that the ValueMapName should match this new class defined under the parent VALUE_MAP class. Clicking on the Properties tab for the RATING_VALUE_MAP shows us all the value maps pertaining to this class. Clicking on CL150, for example, would show that it has been mapped to 150LB using the ‘AutoPLANT_PDW_Catalog_Value_Map’ custom attribute.
So, when an export is done using these value maps, the RATING or CONTACT_RATING property in the ECXML generated would have the corresponding values defined in the OP schema. For example, if the user runs the AP2EC conversion process on a flange with a 150LB rating defined in AP, the ECXML would have RATING specified as CL150, in the following XML format:
There can always be multiple values coming from AP that can be value mapped to a particular OP value. For example, multiple types of butt-welds coming from AP have been mapped to the BUTT_WELD class in the OP schema, as shown in the image below.
Relationships between various entities in the ECXML’s have to be defined in order to ‘connect’ the entire assembly of entities/components together. A relationship can be something like Joint has Port, or Valve has Valve Operating Device, or Device has a Support. The relationship connects to OP class entities together in its definition in the schema, and is eventually printed in the ECXML’s for consumption by OPIM.
Let us take the Device_Has_Support relationship as an example. This relationship has been defined to define a connection between an entity under the DEVICE class, and an entity under the SUPPORT class in the OP schema.
The Device_Has_Support class residing under Relationship Classes has a AutoPLANT_PDW_Class_Map custom attribute defined. The class defined here is used internally by the AP2EC conversion process to map to the proper relationship, so obviously it is not to be tampered with for pre-defined relationships.
The constraints tab specifies the Cardinality. A pipe can have multiple supports, so the cardinality would be (0, 1) to (0, N).
Notice how the Source section has Device class defined in the box, whereas the Target class section has the Support class defined. The statement ‘pipe has a support’ is logical, rather than saying that ‘support has a pipe’, since a pipe can have multiple supports on it.
If we look at the Constraints for the Valve_Has_Valve_Operating_Device relationship, it would be observed that the Cardinality is (0,1) to (0,1), since one valve will always have just one topwork/regulator on it.
If the Class Editor software is not available to modify your merge schema, you can always use any popular text editor software like Notepad++ to manually make amends/additions to your ecxml.xml file residing in the Config > OpenPLANT > Schemas folder location of your project root. For example, adding a new AP class mapping to an existing OP class would simply require the addition of the following lines under the AutoPLANT_PDW_Class_Map custom attribute:
<ClassNames> <string>YOUR_AP_CLASS</string> </ClassNames> <ModuleNames> <string>YOUR_AP_CLASS_MODULE</string> </ModuleNames>
Below is a snapshot of the AP class mappings of the JACKETED_CONNECTOR class. Notice that multiple classes have been mapped to this EC class.
The isometric supplemental schema can be supplemented onto the OP 3D schema or the merge schema in the same way as has been described for the AutoPLANT Supplemental Schema. Note that it also needs to be supplemented on the merge schema, because the merged schema is only a blend of the OP 3D schema and the AP supplemental schema. In an AutoPLANT installation, this schema would be present in the same location as the merge schema in the project folder Config > OpenPLANT > Schemas.
The isometric supplemental schema gives control over the final isometric that would be generated a few custom attributes of importance are:
All of them are not necessarily defined for each and every class, but their employment depends upon special requirements for that particular component class. But generally, the Isometric Component custom attribute is defined for all components so that they are correctly output to the final isometrics.
Here’s a snapshot of the Isometric Component custom attribute of the PIPE_ELBOW class. All isometric component custom attributes can be seen alongside the AP custom attributes once the isometric schema is supplemented.
The Item Code concatenates several properties together and stores that in the isometric component as IE_CODE. The isometric generation process would throw an error if any of these properties is not mapped correctly. The Class Name is also stored in the isometric component as IE_TYPE.
The Scaler and the Symbol are instrumental in defining the structure of the isometric component’s symbol and the graphics of the symbol itself, respectively. However, other changes/additions need to be made if an entirely new symbol is to be defined.
First we need to create the symbol representation.
Now let’s return to the isometric supplemental schema. Search for the PIPE_TEE class and scroll to the isometric Component custom attribute on the right. Assuming that your new tee class is mapped to PIPE_TEE or a child class residing under PIPE_TEE, notice that the Scaler and the Symbol have already been defined. The Scaler has been defined as follows:
IIf(IM.GetPort("3","ECX_END_PREP") = "FL","TEE_16,90","TEE_8,90")
This means that if the third port end condition is FL, then use the TEE_16 scaler defined in the symbolsizes.def file, otherwise use TEE_8.
Such conditions are used at various places in the isometric supplemental schema. For example, following is the Scaler written in the Isometric Component custom attribute of the PIPE_ELBOW class.
IIf(IM.GetPort("1","ECX_END_PREP") = "FL", "ELBOW_16,90","ELBOW_8,90")
This also means that if the end prep of the first port is FL, then use the ELBOW_16 scaler, otherwise use ELBOW_8.
Coming back to the PIPE_TEE class, the Symbol has been written as follows in the Isometric Component custom attribute:
"TEE" & IM.EndPrepMap()
This concatenates “TEE” and all the end conditions of the component together to create a symbol name. For example, if all the ports of the tee are SW (socket weld female), then IM.EndPrepMap() would give SW, and the final symbol name would be TEESW. If this symbol exists in your .cel library then the component would have this symbol drawn in the final isometric. Now let’s assume that the main and run ports of the tee are SW, but the branch is FT (female threaded). So the final symbol would become TEESW_SW_FT. If all the end conditions on the three ports are different – for example the first port is FL, second is SW, and branch is FT – then the final symbol would become TEEFL_SW_FT. Notice how the sequence of end conditions is maintained in the symbol name. Care should be exercised during assigning port numbers to all the end conditions in your symbol graphic in OPIM; they should be assigned in the correct order so as to create a valid connection representation in the final isometric.
The Symbol definition in the isometric custom attribute for the PIPE_FLANGE class has also been structured with an IIF condition, which says that if the end condition of the second port is FL, then get the end condition of the first port to concatenate with FLG, otherwise get the end condition of the second port to concatenate with FLG.
The isometric components custom attributes also allows the specification of an Extra Direction, which is of particular use in the SUPPORTS class.
Using statements like these one can specify conditions in which a particular symbol should be used and when it should not be used. However, these conditions/statements should be kept as simple as possible, and existing symbols and scalers should be used to avoid complexity, unless there is no viable option available.
Another important isometric supplemental schema custom attribute is Isometric Mappings. It provides various control options to specify the structure of the isometric component, whether it is an add-on type of component, whether it needs to be displayed or not, etc. Consider the Isometric Mappings custom attribute for the BOLT class as an example, shown in the image below.
It tells the isometric generation process that this particular component is an add-on component, and that it should not be skipped. There are some cases where particular AutoPLANT entities/components have to be skipped, i.e., they are not represented anywhere in the isometric. For example, the AT_GLAND class in the Ductile module. It is part of a complicated mechanical joint assembly which has several fasteners, and most of them have been incorporated in isometric component definitions in IsoExtractor. So, since mapping could not be ignored because that would give missing mapping errors, this component was mapped to the GLAND class which has Is Skip set as True in its Isometrics Mappings custom attribute. This would allow the AP2EC ECXML generation process to push this component through, but the isometric supplemental schema would disallow this component to be displayed on the final isometric.
Also notice how the Has Intersection Point in the Isometric Mappings custom attribute for the PIPE_ELBOW class has been set to True, since this two port component has an intersection which connects to the two ports with two segments.
Bentley's Product Advantage Group requests that you please confine any comments you have on this Wiki entry to this "Comments or Corrections?" section. THANK YOU!