Concept
The mapping data is grouped under the following categories (Kind):
- "Working model filter": (only for schematic P&ID model).
- "Pipes" (to be interpreted as "Ducts" for HVAC).
- "Parts": corresponds to the different components in an engineering model.
- For 3D piping: piping valve, piping tee, piping reducer, nozzles and other parts
that fit the network
- For 3D HVAC: HVAC Cap, HVAC Damper, HVAC Elbow, HVAC Instruments, and other
parts that fit the network.
- For schematic P&ID: valve, branch, instruments, and other parts that fit the
network.
- "Equipment"
For schematic P&ID models, you can select the working model, and also filter what
P&ID components to be included in the generated model. Note:
This selection and
filtering of a working model can be seen as an extra level in the mapping for schematic
P&ID models, the other mapping still applies. For more about the filtering rules,
see Schematic P&ID Filtering Rules.
Pipes/Ducts are for 3D piping and schematic P&ID always of the Piping
Rigid Pipe type, for 3D HVAC always of the HVAC Rigid
Duct type. Any other item can be either of Parts
type, or of Equipment type. However, an item in itself can have a
user-defined type, for example MyPumpType.
Notes:
- A pipe/duct is, except from simple cases, made of a succession of straight pipe
segments and piping elbows. The generation of the Modelica representation of the model
creates a single Modelica class, an "equivalent pipe". This class corresponds to the
succession of straight pipe and piping elbows of the pipe/duct.
- Tapping is supported. When there is a tapping, a Modelica element with 3 ports as a
"Tee" is added. This is handled by a "Tapping Management" class. Pipes not having the
same diameters are handled, as well as branch pipes not orthogonal to the main route.
Engineering model components of type Equipment or
Parts have a subtype as well.
The type, subtype, or reference of engineering model entities is mapped with a Modelica
class or a group of classes by a mapping table. Depending on the Modelica libraries that
are targeted for the simulation, that table can be modified to map engineering model types
with the Modelica classes that are of interest.
Note:
For an equipment or part with a maximum of two connections, you can select to ignore
the mapping with a Modelica class. Instead you can replace the equipment or part by a
Modelica connection. Some engineering model parts are ignored automatically according to
their piping type. You can define a mapping between a 3D piping model and the Modelica
classes by using, depending on how the engineering model types are saved, the
Init from selection command or the Init from data
setup command. When you do that, the Piping_Flange
and the Piping_Gasket piping types are ignored. For a 3D HVAC
model, the HVAC Flange and the HVAC Gasket
HVAC types are ignored.
If you map with a Modelica class, you also have an option to make the components of the
generated class replaceable. Note:
You can replace components that are not generated with
this option, but it is harder.
The mapping process also includes the mapping of the attributes. The program exposes
keywords associated with the piping/duct type. You are responsible for the matching
definition with input parameters for each of the chosen classes.
The types are located in the CATIAPiping library.
You use the command Engineering Generator Mapping Edition
to open an editor for
the mapping table. Note:
In the editor, you can use default mapping tables to start
working with the mapping. You have three default mapping tables:
- For 3D piping: MSLDefaultMapping
- For 3D HVAC: MSLDefaultMappingHVAC
- For schematic P&ID: MSLDefaultMappingLogPiping
Schematic P&ID Filtering Rules
For schematic P&ID models, you can select the working model, and also filter
what P&ID components that should be included in the generated model. This filtering
automatically creates a mapping, that can be refined using the mapping rules in the next
section.
For the selected working model, you can select to include all components in the generation,
but you can also apply filtering, you can:
- Include components in the generation.
- Remove components from the generation.
- By-pass components in the generation, that is, include the components in the
generation, but generate them as Modelica connections.
You can select to by-pass lines, that is, you can select a line with the command
Select Line, all components in that line are selected to be
by-passed. The selection of the line ends when a component with three or more connectors is
found. The line is generated as a Modelica connection between two ports - the by-passed line
only have two extremities.
If a by-passed component is connected to three or more objects in the generated model, the
component is generated. It is not by-passed. A warning appears.
If a by-passed component is connected only one time, it is an extremity of a "by-pass
line", this component is generated, together with a warning that this component should
normally be by-passed manually.
When you include a component in the generation, the corresponding object type is
automatically added as "Equipment and Parts" in the mapping, if not already present. Notes:
- If you remove a component from the generation, the corresponding type in "Equipment
and Parts" is not automatically removed, you must remove it manually, or use the
command Clean From Selection, see Manage Equipment and Parts.
- The resulting "Equipment and Parts" can be further refined, see next section.
There are some limitations when working with schematic P&ID models:
- Offsheet connectors (pure graphical connectors to identify that a line is continuing
in another view) are not supported. A pipe with an offsheet connector is generated as a
Modelica pipe only, nothing for the offsheet connector.
- If there is not full access to the logical data from the schematics, some data
structures may not be supported. Typically, if the components inserted in the schematics
are not in the same Logical Architecture tree as the schematic view, the corresponding Logical references are not loaded together
with the schematics. In that case, only the graphics are loaded, not the underlying data
model, and so the data cannot be accessed for generation of the Modelica model.
- If the topology of the schematics is not consistent with the topology of the
underlying Logical model, some data structures may not be supported. The generated model
may be incomplete.
- Icons generated from schematic symbols are not exactly a copy of the symbols:
- Black and white only.
- No selection of line thickness.
- Limited support for line styles.
- The logical branch mapping contains only one logical port. This means that no prefer
direction can be decided based on the logical model. If you want to have a specific
angle between connectors, you must create that manually, by, for example, using
replaceable components and replace them.
- You can use Logical electrical schematics to generate a Modelica model, but the
results are not guaranteed, as the preliminary target is piping schematic models.
Mapping Rules
The following mapping rules apply:
- Mapping can be defined for (from lower to higher priority when applying the mapping):
- a type of PLM entities
- a subtype, identified by the attribute Part SubType:
Vessel, Tee, Flange, Elbow...
- a PLM reference, identified by the attribute Name
- For each type/subtype/reference, one or several mappings to a Modelica class can be
defined. Each of those mappings has its own usage in the model generation process.
- If a mapping is defined for both a Reference and for the subtype of that reference,
the mapping for the reference is used (if it is valid).
- For each mapping, a single Modelica class is selected.
- The mapping has the following structure:
Each Type/subtype is mapped with a Modelica
class. This is the default mapping. When the mapping is
initialized with a physical model, each reference of a given Type/subtype can be
mapped with another Modelica class. If the reference is not mapped (undefined), the
default class is used, if any default class is found.
TypeA /subtypeA |
default Modelica class |
Reference1 |
Modelica Class 1 |
Reference2 |
(undefined) |
Reference3 |
Modelica Class 3 |
Notes:
- Removing, in the mapping table, a line with the keyword
default removes all lines in that group.
- The background color is used to indicate different groups in the mapping
table.
- If for a type/subtype, a Modelica class is not defined, and a default class
cannot be found, this is indicated by a red text
(undefined). Such a type/subtype is generated as an
undefined component.
- Port mapping can be applied. For mapping of port arrays, the following syntax applies:
- Attribute mapping:
- Attributes of the PLM entity (base PLM attributes, customer-defined PLM
attributes, or Knowledgeware parameters) can be mapped with the parameters of the
selected Modelica class.
- PLM attributes are identical with their internal ID (independent from NLS);
Knowledgeware parameters are identified by the name that you defined.
Note:
If new Knowledge parameters have been created in the Physical engineering model,
you can update the mapping by a command.
- For schematic P&ID models, with implement links from logical objects to physical
objects, you can select additional parameters of these physical objects to map as source
parameters for the logical object. Such parameters can be physical data parameters,
inherited parameters (like
V_PartType and
V_MaterialName ), customized parameters, and Knowledgeware parameters.
All these parameters have the prefix Physical_ in the source parameter
list.
Notes:
- If a physical parameter has been added or removed, you must initialize the model
again to retrieve the new parameters of the object.
- If a logical object is not linked to a physical object with an implement link,
no physical parameters can be retrieved for that logical object.
- If a logical pipe is implemented by a set of physical pipes, the parameters of
the physical pipes cannot be retrieved.
- No physical information can be retrieved from a branch.
- A typical example of linking is an implement link between a Logical Pipe and a
physical Piping Rigid Pipe. In that case, in the basic case, the following
physical parameters are available:
Physical Parameter |
Unit |
Description |
For EquivalentPipe CATIAPiping, to map typically with |
Physical_Diameter |
Length |
Inside diameter of the physical pipe |
diameter |
Physical_Radius |
Length |
Inside radius of the physical pipe |
|
Physical_BendRadius |
Length |
Bend radius of the physical pipe |
R_0 |
Physical_BendAngle |
Vector of Angles |
Bend angle of the physical pipe |
angles |
Physical_Length |
Vector of Lengths |
Length vector of straight pipes |
length |
Physical_Height |
Length |
Height difference between B and A |
height |
- Mapping numerical values: You can use the mapping to specify a numerical value in a
Modelica parameter.
- Additional Modelica classes are used generally in the generated Modelica model, not
directly related to any specific item in the source engineering model:
Inner High Level
|
The fluid model system where global parameters are
defined. Examples are Modelica.Fluid.System from Modelica Standard Library, or
ThermalSystems.SystemInformationManager from ThermalSystems library. |
Media
|
The classes that define the media used in the
model. |
For the media, the following attributes can be defined:
Component
|
The name of the media. |
Modelica Class
|
The Modelica class used in the redeclare statement.
|
Package
|
To specify if the medium redeclares a package (for
example, "Modelica Standard Language" components redeclare a medium package)
or not (for example, "Thermal Systems" components use the redeclared
component in the inner component "System Information Manager"). |
|