ECAD / MCAD Collaboration - prostep.org

ECAD/MCAD Collaboration 

RECOMMENDATION 

ECAD/MCAD Collaboration; PSI 5 

Version 2.0

ABSTRACT ProSTEP iViP Recommendation 

Abstract 

The integration of mechanical and electrical components in mechatronic integrated products is becoming increasingly important. 

Development takes place in separate domains using different CAD tools (ECAD and MCAD). Although powerful software tools 

are available on the market for the respective disciplines, support for existing processes and systems is reaching its functional limits 

with regard to collaboration between these systems. With increasing product complexity and the demand for shorter development 

cycles, there is a growing need for feasible solutions for sustainable collaboration on the basis the existing ECAD and 

MCAD systems. 

This ProSTEP iViP Recommendation serves to manage the exchange of ECAD and MCAD entities within a mechatronic design 

process by collaborating information between the domains involved. The exchange of collaboration data is not restricted to a 

certain phase of the product life cycle. 

This ProSTEP iViP Recommendation deals with collaboration between developers in the business processes. It does not deal with 

change management or detailed product data management processes. These subjects go beyond the scope of this recommendation 

and should be applied and handled as appropriate in the particular product development environments. 

This ProSTEP iViP Recommendation covers the results elaborated by the ProSTEP iViP Project Group ECAD/MCAD-Collaboration. 

II 

PSI 5 (ECAD/MCAD) / V.2.0 / May 2010

ProSTEP iViP Recommendation DISCLAIMER · COPYRIGHT · ACKNOWLEDGMENT 

Disclaimer 

ProSTEP iViP Recommendations (PSI Recommendations) are recommendations that are available for anyone to use. Anyone using 

these recommendations is responsible for ensuring that they are used correctly. 

This PSI Recommendation gives due consideration to the prevailing state-of-the-art at the time of publication. Anyone using PSI 

Recommendations must assume responsibility for his or her actions and acts at their own risk. The ProSTEP iViP Association and 

the parties involved in drawing up the PSI Recommendation assume no liability whatsoever. 

We request that anyone encountering an error or the possibility of an incorrect interpretation when using the PSI Recommendation 

contact the ProSTEP iViP Association (psi-issues@prostep.com) immediately so that any errors can be rectified. 

Copyright 

I. All rights on this ProSTEP iViP Recommendation, in particular the copyright rights of use and sale such as the right to 

duplicate, distribute or publish the recommendation remain exclusively with the ProSTEP iViP Association and its members. 

II. The recommendation may be duplicated and distributed unchanged, for instance for use in the context of creating software 

or services. 

III. It is not permitted to change or edit this recommendation. 

IV. A suitable notice indicating the copyright owner and the restrictions on use must always appear. 

Acknowledgment 

Our thanks go to all the companies and their staff who were actively involved in drafting this recommendation and for the 

many constructive suggestions received. The following companies and research institutes were involved: 

Cenit, Continental, Delphi, :em engineering methods, Fern Universität Hagen, Fraunhofer IPK, Mentor Graphics, Parametric 

Technology, PDTec, PROSTEP, Siemens PLM Software, Universität Karlsruhe, xPLM Solution. 

PSI 5 (ECAD/MCAD) / V.2.0 / May 2010 

III

TABLE OF CONTENTS ProSTEP iViP Recommendation 

Table of Contents 

1 Introduction 1 

1.1 Preface 1 

1.2 Objectives of ECAD/MCAD collaboration 1 

1.3 Scope of the EDMD Schema 2 

1.4 Structure of the recommendation 3 

2 General requirements 4 

2.1 Shortening the iteration cycles between ECAD and MCAD development processes 4 

2.2 Working in the native system 4 

2.3 Separate collaboration environment 5 

2.4 Asynchronous and synchronous collaboration 6 

2.5 Means of communication parallel to collaboration 7 

2.6 Support for different forms of representation 7 

2.7 Cardinality of collaboration 7 

2.8 Initiating collaboration 8 

3 Use cases 9 

3.1 Standardized use case description 9 

3.2 Actors within the use cases 10 

3.3 Defining a board baseline 11 

3.4 Placement under mechanical constraints 13 

3.5 Placement under electrical constraints 15 

3.6 Change of board components 16 

3.7 Change of placement locations 17 

3.8 Replacement of components 18 

3.9 Panelization design review 20 

4 System and Process Integration 22 

4.1 The role of a PDM system within collaboration 23 

4.1.1 Online Collaboration 24 

4.1.2 Offline Collaboration 25 

4.2 Use Cases for System and Process Integration 26 

4.2.1 Create Collaboration-Session-Object (CSO) for a collaboration session 26 

4.2.2 Identify and attach PDM system objects to the CSO 27 

4.2.3 Identify responsible persons based on the PDM system information 28 

4.2.4 Invite responsible persons to the collaboration 29 

4.2.5 Select and start collaboration session 29 

4.2.6 Checkout data from the PDM system to the ECAD/MCAD system 30 

4.2.7 Store back modifications into the PDM-system 30 

4.3 PDM/TDM system supported collaboration 31 

4.4 PDM system supported cooperation 34 

4.4.1 Represent additional user roles which are necessary within a collaboration 35 

4.4.2 Management of a collaboration session object within the PDM system 35 

4.4.3 CSO Metadata management 35 

4.4.4 CSO Document management 35 

4.4.5 CSO Search management 35 

4.4.6 CSO Link management 35 

4.4.7 Collaboration session preparation support 35 

4.4.8 Collaboration session initiation support 36 

4.4.9 Collaboration session data management 36 

IV 


ProSTEP iViP Recommendation TABLE OF CONTENTS 

4.4.10 Closing the collaboration session 36 

4.4.11 Managemet of the Collaboration sandbox 37 

4.4.12 Handling of ECO/ECR within a collaboration process 37 

5 Standardized Library Components 38 

5.1 Use Cases for Standardized Library Components 38 

5.1.1 Using library information within collaboration 38 

5.1.2 Cross domain library to library data exchange 39 

5.1.3 Provision of library data from supplier 39 

5.2 Parameterized Library Components 40 

5.2.1 3D Master Model "Type A" 42 

5.2.2 3D Master Model "Type B" 50 

5.2.3 General Implementation Issues 51 

6 EDMD data model 52 

6.1 Overview 52 

6.2 Packages in the user-driven data model 53 

6.2.1 Package 1: item definition and product structure 53 

6.2.2 Package 2: item classification and grouping 54 

6.2.3 Package 3: person and organization information 55 

6.2.4 Package 4: ECAD shape information 56 

6.2.5 Package 5: constraint definition 58 

6.2.6 Package 6: property and material definition 59 

6.2.7 Package 7: 2d geometry model 60 

6.2.8 Package 8: shape dependant information 60 


6.3 Objects 62 

6.3.1 annotation 62 

6.3.2 assembly_component 62 

6.3.3 assembly_component_relationship 62 

6.3.4 assembly_definition 63 

6.3.5 assembly_group_component 63 

6.3.6 b_rep_model 63 

6.3.7 b_spline_curve 63 

6.3.8 cartesian_coordinate_space 63 

6.3.9 cartesian_coordinate_space_2d 64 

6.3.10 cartesian_coordinate_space_3d 64 

6.3.11 cartesian_point 64 

6.3.12 centre_of_mass 64 

6.3.13 circle 64 

6.3.14 classification_association 65 

6.3.15 classification_attribute 65 

6.3.16 collaboration_definition 65 

6.3.17 component_termination_passage 66 

6.3.18 component_termination_passage_template_interface_terminal 66 

6.3.19 component_termination_passage_template_join_terminal 66 

6.3.20 component_termination_passage_template_terminal 66 

6.3.21 composite_curve 66 

6.3.22 constraint 66 

6.3.23 curve 67 

6.3.24 curve_on_surface 67 

6.3.25 curve_set_2d 67 


V


VI 

6.3.26 cutout 67 

6.3.27 Cutout_edge_segment 67 

6.3.28 data_environment 68 

6.3.29 definition_based_product_occurrence 68 

6.3.30 design_discipline_item_definition 68 

6.3.31 design_layer_stratum 68 

6.3.32 design_layer_technology 68 

6.3.33 detailed_geometric_model_element 69 

6.3.34 digital_file 69 

6.3.35 documentation_layer_stratum 69 

6.3.36 documentation_layer_technology 69 

6.3.37 ellipse 69 

6.3.38 external_geometric_model 70 

6.3.39 external_geometric_model_with_parameters 70 

6.3.40 external_model 70 

6.3.41 feature_parameter 71 

6.3.42 filled_via 71 

6.3.43 general_classification 71 

6.3.44 general_parameter 71 

6.3.45 general_property 72 

6.3.46 general_shape_dependent_property 72 

6.3.47 geometric_model 72 

6.3.48 geometric_model_relationship_with_transformation 73 

6.3.49 hybrid_geometric_model_3D 73 

6.3.50 hyperbola 73 

6.3.51 instance_placement 73 

6.3.52 inter_stratum_feature 73 

6.3.53 interconnect_module_constraint_region 74 

6.3.54 item 74 

6.3.55 item_contraint 75 

6.3.56 item_definition_instance_relationship 75 

6.3.57 item_instance 75 

6.3.58 item_property_association 75 

6.3.59 item_shape 75 

6.3.60 item_version 76 

6.3.61 laminate_component 76 

6.3.62 line 76 

6.3.63 material 76 

6.3.64 material_property 77 

6.3.65 material_property_association 77 

6.3.66 material_property_value_representation 77 

6.3.67 moments_of_inertia 77 

6.3.68 next_higher_assembly 78 

6.3.69 numerical_value 78 

6.3.70 offset_curve 78 

6.3.71 organization 78 

6.3.72 parabola 79 

6.3.73 part_feature 79 

6.3.74 part_mounting_feature 79 

6.3.75 partially_plated_cutout 79 


ProSTEP iViP Recommendation TABLE OF CONTENTS 

6.3.76 person 79 

6.3.77 person_in_organization 80 

6.3.78 person_organization_assignment 80 

6.3.79 physical_connectivity_interrupting_cutout 81 

6.3.80 plated_cutout 81 

6.3.81 plated_cutout_edge_segment 81 

6.3.82 plated_inter_stratum_feature 81 

6.3.83 plated_passage 81 

6.3.84 point 81 

6.3.85 point_on_curve 81 

6.3.86 point_on_surface 82 

6.3.87 polyline 82 

6.3.88 printed_part_template_terminal 82 

6.3.89 printed_part_cross_section_template_terminal 82 

6.3.90 printed_part_template_interface_terminal 82 

6.3.91 printed_part_template_join_terminal 83 

6.3.92 printed_part_template_terminal 83 

6.3.93 property 83 

6.3.94 property_value 83 

6.3.95 property_value_association 83 

6.3.96 property_value_representation 83 

6.3.97 property_constraint 84 

6.3.98 shape_dependent_property 84 

6.3.99 shape_description 84 

6.3.100 shape_element 85 

6.3.101 shape_feature 85 

6.3.102 single_instance 85 

6.3.103 stratum 85 

6.3.104 stratum_feature_template_component 85 

6.3.105 stratum_technology 86 

6.3.106 structured_printed_part_template_terminal 86 

6.3.107 thermal_component 86 

6.3.108 transformation 86 

6.3.109 transformation_2d 86 

6.3.110 transformation_3d 86 

6.3.111 trimmed_curve 86 

6.3.112 unit 87 

6.3.113 unsupported_passage 87 

6.3.114 value_limit 87 

6.3.115 value_range 88 

6.3.116 value_with_unit 88 

6.3.117 via 88 

6.3.118 wireframe_model_2d 88 

6.4 Implementation steps and functional scope 89 

6.5 Mapping logic 90 

6.5.1 Package 1: item definition and product structure 90 

6.5.2 Package 2: item classification and grouping 91 

6.5.3 Package 3: person and organization information 92 

6.5.4 Package 4: ECAD shape information 92 

6.5.5 Package 5: constraint definition 93 

PSI 5 (ECAD/MCAD) / V.2.0 / May 2010 VII


6.5.6 Package 6: property and material definition 94 


6.5.8 Package 8: shape dependant information 96 


6.6 Implementation-driven data model (EDMDSchema) 96 

6.6.1 Concept of the “item” 97 

6.6.2 Concept of the designator within the context of the system 99 

6.6.3 Limitations on properties, user-defined properties 101 

6.6.4 The geometry model, shape of an item 103 

6.6.5 Roles 104 

6.6.6 General information 105 

6.6.7 Package EDMDSchema.foundation 106 

6.6.8 Package EDMDSchema.property 108 

6.6.9 Package EDMDSchema.administration 110 

6.6.10 Package EDMDSchema.pdm 110 

6.6.11 Package EDMDSchema.material 113 

6.6.12 Package EDMDSchema.d2 113 

6.6.13 Package EDMDSchema.external 114 

6.6.14 Package EDMDSchema.grouping 114 

6.6.15 Package EDMDSchema.annotation 115 

6.6.16 Package EDMDSchema.text 115 

6.6.17 Package EDMDSchema.computational 116 

6.6.18 Package EDMDSchema.3d_master_parts 116 

7 EDMD protocol 119 

7.1 General information 119 

7.2 Messages 120 


7.2.2 SendInformation message 120 

7.2.3 SendChanges message 120 

7.2.4 RequestForInformation message 121 

7.2.5 ServiceResult class 121 

7.3 Protocol 122 


7.3.2 Self contained Messages 123 

7.4 Processing rules 123 


7.4.2 SendInformation 124 

7.4.3 SendChanges 128 

Annex A: Packages EDMDSchema 133 

Annex B: EDMDSchema 134 

Annex C: 3D Master Models 135 

Annex D: Conformance Guidelines 136 

Annex E: Implementation Guidelines 137 

VIII 


ProSTEP iViP Recommendation FIGURES 

Figures 

Figure 1: Collaboration model embedded in native ECAD/MCAD systems 2 

Figure 2: Support scenarios for EDMD based collaboration 2 

Figure 3: Options for integrating the collaboration modules 5 

Figure 4: Collaboration module and communication with the native system using ECAD as an example 6 

Figure 5: Configuration of collaboration control 8 

Figure 6: Dependencies between the use cases 9 

Figure 7: Roles and actors within ECAD/MCAD collaboration 10 

Figure 8: EDMD collaboration scope 22 

Figure 9: PDM system stores not the collaboration models 23 

Figure 10: Steps of an online collaboration process 24 

Figure 11: Steps of an offline collaboration process 25 

Figure 12: PDM/TDM supported Collaboration Step by Step 1/4 31 




Figure 16: PDM system's collaboration session support 34 

Figure 17: Main characteristics of Master Model Types 40 

Figure 18: Hierarchical structure of the parameters of 3D master models 41 

Figure 19: Pin type "L" 46 

Figure 20: Pin type "I" 46 

Figure 21: Pin type "Z" 46 

Figure 22: Pin type "C" 46 

Figure 23: Offset additional body 47 

Figure 24: Numbering and naming of Pins 47 

Figure 25: Offset for pin rows 48 

Figure 26: Copper area definition 48 

Figure 27: Pins through Basic Body 49 

Figure 28: Overview of the application-driven data model 52 

Figure 29: Overview of the "item definition and product structure" Package 53 

Figure 30: Overview of the "item classification and grouping" Package 54 

Figure 31: Overview of the "person and organization information" Package 55 

Figure 32: Overview of the "ECAD shape information" Package 56 

Figure 33: Overview of the "constraint definition" Package 58 

Figure 34: Overview of the "property and material definition" Package 59 

Figure 35: Overview of the "2d geometry model" Package 60 

Figure 36: Overview of the "shape dependant information" Package 61 

Figure 37: Overview of the "3d geometry model" Package 62 

Figure 38: Implementation steps 89 

Figure 39: Mapping in Package 1 90 

Figure 40: Mapping classification and grouping mechanisms 91 

Figure 41: Mapping the organizational units and roles 92 

Figure 42: Mapping the shape information 92 

Figure 43: Mapping the constraints 93 




Figure 47: Item model 97 

Figure 48: Item data 98 

PSI 5 (ECAD/MCAD) / V.2.0 / May 2010 IX

FIGURES ProSTEP iViP Recommendation 

Figure 49: Designator model 99 

Figure 50: Designator data 100 

Figure 51: UserProperties model 101 

Figure 52: Shape model 103 

Figure 53: CurveSet2d 104 

Figure 54: Roles 105 

Figure 55: Overview of foundation Package 107 

Figure 56: Over view of property Package 108 

Figure 57: Overview of administration Package 110 

Figure 58: Overview of pdm Package 111 

Figure 59: Overview of material Package 113 

Figure 60: Overview of external Package 114 

Figure 61: Overview of grouping Package 114 

Figure 62: Overview of annotation Package 115 

Figure 63: Overview of text Package 115 

Figure 64: Over view of computational Package 116 

Figure 65: Overview of 3d_master_parts Package 117 

Figure 66: Color and length property used to describe properties of 3D master part 117 

Figure 67: properties of pad property set 118 

Figure 68: Types of communication 119 

Figure 69: SendInformation message 120 

Figure 70: SendChanges message 120 

Figure 71: RequestInformation message 121 

Figure 72: ServiceResult class 121 

Figure 73: SendChanges 122 

Figure 74: RequestForInformation 123 

Figure 75: Processing SendInformation (1 of 2) 126 

Figure 76: Processing SendInformation (2 of 2) 127 

Figure 77: Processing SendChanges (1 of 3) 130 



X 


ProSTEP iViP Recommendation 1 INTRODUCTION 

1 Introduction 

1.1 Preface 

Existing processes and applications in the area of ECAD/MCAD collaboration are currently reaching their limitations. At the 

same time, the demands being made on the quality and scope of collaborative efforts are increasing. With increasing product 

complexity and the demand for shorter development cycles and improved quality, the need for ways of implementing ECAD/MCAD 

collaboration is steadily growing. 

Currently available methods based on data exchange formats do not permit collaboration. The IDF format, for example, is not 

suitable for adequate collaboration due in particular to its limitations when changing the position of components, inadequate 

functionality when defining data ownerships and the lack of an option for performing incremental data exchange. There are 

also no data management functions for implementing satisfactory change and versioning processes. The handling of constraints 

as well as their exchange and administration also remains an unresolved task within the framework of ECAD/MCAD 

collaboration. 

The key questions for collaboration between the domains electric and mechanics are: 

Which information are divided by the two domains? 

When and/or at which time during the product development process? 

Which solutions exist for a better collaboration between the domains? 

These picked up by the ProSTEP iViP Project Group ECAD/MCAD-Collaboration and which specified a data model based on the 

entities of ISO10303 AP 210 and AP 214 and a related XML schema for implementation. Furthermore services were defined which 

enable the exchange of information between that ECAD and the MCAD system on basis of the defined data model. 

Efficient collaboration between ECAD and MCAD developers provides a new method for communicating and exchanging 

information between both domains electric and mechanics. 

. 

1.2 Objectives of ECAD/MCAD collaboration 

The current limitation of promising options for collaboration between ECAD and MCAD domains give rise to a demand for appropriate 

solutions. Therefore, the objective of this ECAD/MCAD Recommendation is to specify the data models and protocols 

required to enable collaboration between the domains ECAD and MCAD - process oriented and based on existing standards. 

The essence of this approach is to facilitate collaboration between the ECAD and MCAD domains in such a way that the users 

in one domain have access to all relevant information in the other domain. The improved flow of information means that iteration 

loops can be avoided, and thus the product development can be accelerated. Scope is to support an interactive procedure 

that is characterized by informal collaboration processes. 

The interoperability in terms of a collaboration process on selected ECAD and MCAD objects that might be originally created 

either in the one or the other CAD environment is an essential requirement. The collaboration process must embed both the 

creation of a baseline and the common collaborative work on the collaboration model proposing changes where the baseline 

has been created earlier in the design process. To exploit the most benefit it must be possible that not only the whole data 

model but also selective parts of it are exclusively usable. 

The data model specified to enable mandatory collaboration between ECAD and MCAD domains is based on terminologies 

derived from STEP AP 214 (Core Data for Automotive Mechanical Design Processes) with enrichments using STEP AP 210 

(Electronic Assembly, Interconnection and Packaging Design). To facilitate implementation, the data model specified in the Unified 

Modeling Language (UML) has been made available as an XML schema. 

The data model for collaboration has been established to allow interaction between ECAD and MCAD systems on common 

defined collaboration objects. The collaboration model and the corresponding communication protocol, which enable exchange 

of the necessary information between both domains, are shown in relation to the native CAD systems in Figure 1. 

PSI 5 (ECAD/MCAD) / V.2.0 / May 2010 1

1 INTRODUCTION ProSTEP iViP Recommendation 

Figure 1: Collaboration model embedded in native ECAD/MCAD systems 

The collaboration model represents an extension of the particular MCAD and ECAD data models but not the disclosure of the 

native data models. The collaboration enhancement of the respective ECAD and MCAD systems has to be implemented by the 

system vendors. 

1.3 Scope of the EDMD Schema 

With version 2.0 of the recommendation the scope was enhanced. The recommendation describes collaboration process with 

and without the control of a PDM or TDM system. The following figure gives an overview of the scenarios which are supported 

by the EDMD schema. 

Figure 2: Support scenarios for EDMD based collaboration 

2 


ProSTEP iViP Recommendation 1 INTRODUCTION 

In principle the EDMD schema supports the following four constellations: 

Oflline Collaboration with PDM/TDM system 

Online Collaboration with PDM/TDM system 

Oflline Collaboration without PDM/TDM system 

Online Collaboration without PDM/TDM system 

1.4 Structure of the recommendation 

This ProSTEP iViP Recommendation first of all includes a section describing the requirements regarding mandatory collaboration 

between ECAD and MCAD domains. This is followed by an introduction to collaboration use cases, the integration into systems 

and processes and the description of simpliefied 3D master models for library management. These chapters in turn are followed 

by both the data model and protocol for collaboration. The EDMD implementation schema is provided in the Annex. EDMD ist 

a abbreviation for Electrical Design Mechanical Design. 


2 GENERAL REQUIREMENTS ProSTEP iViP Recommendation 

2 General requirements 

This section provides a definition of the requirements relating to systems that provide support for ECAD/MCAD collaboration. 

These requirements are based on discussions that took place at the workshops conducted within the framework of the ECAD/MCAD 

Collaboration project group in 2006 and 2007. 

2.1 Shortening the iteration cycles between ECAD and MCAD development processes 

The main requirement of any product or project manager is shortening product development cycles. This objective is even 

more difficult to achieve in the area of mechatronic product development since more than one discipline is directly affected by 

a change cycle. 

Any change - regardless of whether it occurs in the mechanical or the electrical domain - has a direct impact on the other 

domain. 

4 

Example: If the mechanical designer changes the housing type, thus reducing the height, this could mean that the 

electrical layouter will have to change his layout or allow for components with a different housing type. If, as a result 

of a change in requirements regarding the electrical wiring, the electrical layouter needs alternative components 

with larger dimensions, this could lead to a change in the board outline. Any change to board outline, however, 

will have a direct impact on the housing type with regard to possible mountings, etc. 

It is this interdisciplinary impact that slows down the product development process considerably since different systems are always 

involved in validating a change, and at the moment these systems have no direct means of communication. 

Example: A mechanical collision can only be checked in the exact 3D geometry model in the CAD system. 

In summary, it can be said that a change in one domain may have a considerable impact on the other domain. This impact 

can, however, only be validated and assessed in the authoring tool of the respective domain. 

This gives rise to the first core requirement for a system aimed at providing support for ECAD/MCAD collaboration. 

Requirement 1: 

Shortening the iteration cycles between mechanical and electrical product development processes when a change occurs 

by providing an efficient communication platform for the ECAD and MCAD systems involved. 

2.2 Working in the native system 

There are a number of different ways in which the communication platform between ECAD and MCAD can be implemented 

(cp. Figure 3): 

a) Integration of the collaboration module in the ECAD system, in which case communication takes place directly with the MCAD 

system. 

b) Integration of the collaboration module in the MCAD system, in which case communication takes place directly with the ECAD 

system. 

c) Separate collaboration module which controls only the collaboration and which is provided with the respective data from 

the authoring tools. 

d) Integration of a collaboration module in both the ECAD and the MCAD system. Communication then takes place between 

the two collaboration modules. 


ProSTEP iViP Recommendation 2 GENERAL REQUIREMENTS 

Figure 3: Options for integrating the collaboration modules 

For the reasons presented, the project group favored solution d). As far as the product developer is concerned, it is necessary 

that the collaboration modules must be integrated seamlessly in the native systems and that no information is lost due to additional 

interfaces. 

Furthermore, this type of system architecture allows rules that can only be defined in the native systems to be checked. This gives 

rise to the following requirement: 


It must be possible to call the collaboration modules directly in the native systems. Communication then takes place between 

the collaboration modules integrated in each system. 

2.3 Separate collaboration environment 

During the course of collaboration, a variety of product development data can be created that also has a significant impact on 

the respective native data. It may also be the case that the user does not wish to make all of the data from his native model available 

within the framework of the collaboration. 

It is therefore necessary that a collaboration model is created in the native system in parallel to the current native model. In this 

case, the interface between the native systems and the collaboration module regulates the mapping between the two models, 

see Figure 4. 



Figure 4: Collaboration module and communication with the native system using ECAD as an example 

It must remain possible for the user to decide which results he ultimately wants to transfer to the native model once colla boration 

has been brought to a close. 

This gives rise to the following requirement: 


Collaboration is initially performed on dedicated collaboration models derived from the native model by the user. The user 

is free to decide which elements he wants to make available within the framework of the collaboration and which changes 

he wants to transfer to his native model once the collaboration is over. 

2.4 Asynchronous and synchronous collaboration 

The globally distributed development of mechatronic products also requires support for collaboration scenarios that give due 

consideration to time differences. It is impossible to ensure that all the parties participating in a collaboration can be involved 

at a desired point in time during collaboration. In these cases, synchronous collaboration cannot take place. 

Control mechanisms must be defined which, in the case of asynchronous collaboration, allow the collaboration information to 

be stored persistently and transferred to the collaboration module. 



The collaboration module must support both a synchronous and an asynchronous form of communication. 

6 


ProSTEP iViP Recommendation 2 GENERAL REQUIREMENTS 

2.5 Means of communication parallel to collaboration 

Communication during a collaborative session does not necessarily have to be controlled directly via the collaboration modules. 

The collaboration modules should provide simple means of communicating a message to the collaboration partner. 

Additional means of communication can be used parallel to the collaboration. This gives rise to the following requirement: 


The collaboration module must provide simple means of communicating messages during collaboration. Enhanced forms of 

communication should be provided by external systems. 

2.6 Support for different forms of representation 

The representation of a product in MCAD systems is fundamentally different to the representation of a product in ECAD systems. 

In MCAD, focus is placed on representation of the precise, three-dimensional geometry. In ECAD, on the other hand, representation 

in a 2D or 2.5D (footprint plus height information) model is also often sufficient. 

Collaborative scenarios must take these different forms of representation into consideration, and the collaboration modules must 

provide appropriate mapping rules. 

Example: If the mechanical designer changes the outline of the PCB, he will do so directly in the 3D model. However, 

in the ECAD system, the board outline only exists as a 2D boundary line. This means that during collaboration the 

collaboration modules must give due consideration to the options provided by the other system. In the case in hand, 

it would only be possible to change the geometry on the 2D plane, and it would not be possible to map an additional 

change in the third dimension in the collaboration scenario – although the MCAD system is able to do so 

from a purely technical point of view. 

This gives rise to the following requirement regarding the collaboration platform: 


The collaboration modules must be able to map different forms of representation onto each other and assign them to the native 

model in the respective domain. 

2.7 Cardinality of collaboration 

The first step in implementing collaboration support involves 1:1 peer-to-peer communication of the ECAD and MCAD systems 

involved. Control of the collaboration can be assumed by either side during collaboration. At the start of the collaboration, the 

initiator of the collaboration is automatically the master, who has control. 

In a common product development environment with numerous development engineers it may be necessary to clarify changes 

within a collaboration scenario involving several involved parties. This means that in the second step, the collaboration module 

must allow more than one engineer to participate in a synchronous collaboration (cp. Figure 5). 

In this context, it is however important that there is ever only one master – from either the mechanical or electrical domain – responsible 

for controlling the collaboration. The other parties participating in the collaboration have only “read” access to the 

collaboration process. They have no way of actively making a change. 



Figure 5: Configuration of collaboration control 



As a matter of principle, the collaboration module must provide support for scenarios that involve several parties participating 

in the collaboration. It must however be clearly defined who from either the mechanical or electrical domain is in control 

of the collaboration. The other participants have only read access to the collaboration. It must be possible for another 

participant to take over control at any time during the collaboration. In the initial configuration, 1:1 peer-to-peer collabora tion 

will be supported. This configuration will be extended to n:m in the subsequent stages of implementation. 

2.8 Initiating collaboration 

Appropriate mechanisms for initiating the collaboration must be made available. These mechanisms allow the collaboration partner 

to be informed of a desire for collaboration. To do this, a means of clearly identifying the partner must be introduced. This 

identification allows the current collaboration session to be initiated. 


Appropriate identification mechanisms for initiating the collaboration must be made available. These mechanisms allow the 

collaboration partner to be informed of a desire for collaboration. 

8 


ProSTEP iViP Recommendation 3 USE CASE 

3 Use cases 

Collaboration between ECAD and MCAD domains can be required at numerous points within a mechatronic development process. 

Depending on the point of time in the process being considered, different use cases can be defined which must be supported 

by any future ECAD/MCAD collaboration solution. 

It was decided within the project group to focus initially on seven modular use cases, which are described in detail below. 

3.1 Standardized use case description 

The use cases are described according to the following schema: 

Aim A brief description (short sentence) of the use case and its aim 

Actors Main human and machine entities and their roles 

Preconditions A description of what if anything is assumed to have happened before the activities described in the use case 

description 

Description A narrative description of the use case or usage scenario 

Alternatives Possible (important) variants of the description 

Postconditions Description of the final state 

Diagram Simple illustration of the use case as sequence or activity diagram 

Benefits Documentation of main benefits concerning the application of this use case for the actors 

Notes Documentation of important decisions and, if existing, open issues 

The use cases have mutual dependencies. The relationships between the use cases are shown in Figure 6. 

Figure 6: Dependencies between the use cases 


3 USE CASES ProSTEP iViP Recommendation 

3.2 Actors within the use cases 

In the descriptions of the use cases, mention is made of “actors”. In this context, actors can be either human users of a system, 

a machine, software or any system. Anything that interacts with the system within the context of a use case is referred to as an 

actor. An initial general description of the various actors is provided in Figure 7. 

Figure 7: Roles and actors within ECAD/MCAD collaboration 

Project manager: Responsible for the overall project. Defines the mechanical and electrical product structure, requirements 

and tasks. Controls results. 

Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system. Fulfills the requirements of the 

project manager. Defines requirements for PCB development. 

Mechanical digital mock-up: Performs 3D interference checks in a mechanical 3D CAD system. Checks whether the current 

design fits with the surrounding geometry. Uses the 3D representation of the mechanical and electrical design. 

Electrical designer: Designs the schematics of the PCB. His output is the netlist as input for the layout of the PCB, which is done 

by the ECAD layouter. Fulfills the requirements of the project manager and designers. 

Electrical layouter: Designs the layout of the PCB in the ECAD system based on the netlist of the Electrical designer. Fulfills 

the requirements of the project manager, ECAD designers and MCAD designers. 

Thermal: Performs thermal analysis based on the PCB layout. Checks whether heating, cooling, security and other thermal 

requirements are fulfilled by the current PCB design. 

EMI/EMC: Analyzes whether the current PCB design fulfills the requirements concerning the electromagnetic compatibility 

(EMC), which require that the system is able to tolerate a specified degree of electromagnetic interference (EMI) and does 

not generate more than a specified amount of interference. 

ECAD system: The components are placed on the PCB in the ECAD system. In this recommendation, the ECAD system is viewed 

only as an ECAD layout system. This system receives its input from the schematics design. 

MCAD system: The 3D geometry of the product is designed in the MCAD system and the 2D/3D information of the elec trical 

components is processed. 

10 


ProSTEP iViP Recommendation 3 USE CASES 

3.3 Defining a board baseline 

Aim Transfer of the initial printed circuit board layout from the ECAD domain to the MCAD domain or vice 

versa. Both information about the electrical components and the board outline must be transferred. This use 

case can be initiated from either the MCAD or ECAD domain. 

Actors Electrical layouter: Designs the PCB layout in the ECAD layout system. Defines electrical requirements concerning 

the board outline and the component placement. 

ECAD system: The electrical components are placed on the PCB in the ECAD layout system. 

Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system and defines the 

requirements concerning the board outline. Places electrical components that have an impact on the 

mechanical design. 

MCAD system: In the MCAD system, both the 3D geometry of the product is defined and the 2D/3D in formation 

relating to the electrical components is processed. 

Preconditions From an electrical point of view, the schematic design must be concluded before the components can be 

placed. The result of the schematic is the netlist, which describes how the electrical components are 

con nected. PCB layout is started on the basis of this netlist. 

The mechanical definition of the surrounding geometry is required, on the one hand, to define the board 

outline. On the other hand, restrictions regarding the height and size of electrical components and their 

placement depend on the housing type and must be defined as a precondition for this use case. 

Description There are basically two different ways of defining the board baseline depending on who assumes 

development leadership in the process (for Case 2, see section “Alternatives” in this use case description). 

Case 1: MCAD assumes leadership, i.e. the mechanical designer creates the board outline and places 

several PCB components from a mechanical point of view. These can include connectors, LEDs or 

potentiometers which have a direct impact on the mechanical geometry. 

This predefined layout is then transferred to the electrical layouter as the board baseline. If necessary, existing 

3D information from the mechanical 3D CAD system must be transferred to the ECAD system in a format that 

can be processed by the ECAD system, e.g. 2D or 2.5D information. In addition, a mapping between the 

designators in the mechanical design (e.g. feature or part IDs) and the designators in the electrical design 

(reference designators) must be performed. 

Alternatives Case 2: ECAD assumes leadership, i.e. the electrical layouter starts placing the electrical components on the 

basis of the schematic information. This includes placing components that may affect the mechanical design. 

Once he has finished, the layout is transferred to the mechanical designer as the board baseline. 2D or 2.5D 

information is normally used in the electrical domain, i.e. a footprint and height information for the components 

is transferred. In addition, a mapping between the designators in the electrical design (reference designators) 

and the designators in the mechanical design (e.g. feature or part IDs) must be performed. 

Postconditions An initial baseline for the PCB has been transferred, and the initial mapping of the IDs for the PCB 

components within collaboration between the two domains has been defined. 



Diagram 

Benefits The use of ECAD/MCAD collaboration simplifies the initial transfer of a board baseline considerably since 

no time-consuming transfers via interfaces such as, for example, IDF are required. The common data model 

means that both domains can access identical information. The initial transfer of the baseline for the PCB is 

the starting point for all subsequent collaboration scenarios described in the following use cases. 

Notes No additional notes 

12 



3.4 Placement under mechanical constraints 

Aim Placing electrical components on the PCB under mechanical constraints, e.g. housing type or mechanical 

connections. This use case is initiated from the MCAD domain. 

Actors Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system and defines the 

requirements concerning the board outline. Places electrical components that have an impact on the mechanical 

design. 

MCAD system: In the MCAD system, both the 3D geometry of the product is defined and the 2D/3D information 


Electrical layouter: Designs the PCB layout in the ECAD layout system. 

ECAD layout system: The electrical components are placed on the PCB in the ECAD system. In the use case 

described, the ECAD system also checks components placed under mechanical constraints with regard 

to their placement from an electrical point of view. 

Preconditions The mechanical definition of the surrounding geometry is first of all required to define the board outline, which 

from a mechanical point of view is mainly determined by the housing geometry. Mounting holes on the PCB 

must also be coordinated with the housing geometry. In addition, restrictions regarding the height and size of 

electrical components and their placement depend on the housing type. Ideally, it should be possible for the 

mechanical designer to access the 3D geometry. To do this, a 3D component library needs to be set up. 

Only with precise 3D information can correct placement be performed while utilizing the design space as 

best as possible. The diagram below illustrates why precise 3D geometry is important for optimum utilization 

of design space and why 2.5D information is not sufficient. In addition, the availability of the exact 3D geometry 

allows additional components to be placed which could not otherwise be placed with 2.5D. 

An additional precondition is that the initial board baseline has been transferred and is available in both 

domains in a synchronized status. 



Description Based on the initial board baseline, the mechanical designer starts the collaboration process in order to transfer 

placement of the mechanical components to the electrical layouter. 

14 

The mechanical designer creates the board outline and places several PCB components from a mechanical 

point of view. These can include connectors, LEDs or potentiometers which have a direct impact on the mechanical 

geometry. This mechanically predefined layout is then transferred to the electrical layouter, who then 

places other electrical components depending on the schematic and the electrical constraints. Once this has 

been completed, iteration between MCAD and ECAD begins if the components placed by the mechanical 

designer have to be moved due to electrical constraints or electrical components collide with the mechanical 

housing (see also, for example, use case: Change of placement locations). In the iterative process, the electrical 

designer can check whether the placed components violate electrical constraints. Agreement can be 

achieved very quickly and efficiently within the framework of ECAD/MCAD collaboration since both users 

can compare the impact with the design rules of their native systems. 

Alternatives See use case: Placement under electrical constraints 

Postconditions The mechanical components have been placed on the PCB and the layout has been harmonized with the 

electrical designer within the framework of collaboration. 

Diagram 

Benefits The use of an ECAD/MCAD collaboration can significantly reduce the time needed for the iterative process. 

The common data model allows for a common language in both system environments. This means that changes 

in one environment can be transferred in a standardized manner to the other environment and interpreted 

there. 




3.5 Placement under electrical constraints 

Aim Placing electrical components on the PCB subject to electrical constraints stipulated by the schematic. This use 

case is initiated from the ECAD domain. 

Actors Electrical layouter: Designs the PCB layout in the ECAD layout system. 

ECAD layout system: The components are placed on the PCB in the ECAD system. 

Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system and defines 

requirements concerning the board outline. 



Preconditions From an electrical point of view, the schematic design must be concluded before the components can be 

placed. The result of the schematic is the netlist, which describes how the electrical components are connected. 

PCB layout is started on the basis of this netlist, i.e. placement of the components based on the electrical 

constraints. 

An additional precondition is that the initial board baseline has been transferred and is available in both 

domains in a synchronized status. 

Description Based on the initial board baseline, the electrical layouter starts the collaboration process in order to transfer 

the placement of the electrical components to the mechanical designer. 

The electrical layouter has created his components based on the schematic. Once this has been completed, 

iteration between MCAD and ECAD begins if the components placed by the electrical layouter have to be 

moved due to mechanical constraints because, for example, the electrical components collide with the 

housing. In the iterative process, the mechanical designer can check whether the placed components violate 

mechanical constraints. 

Agreement can be achieved very quickly and efficiently within the framework of ECAD/MCAD collabora tion 

since both users can compare the impact with the rules of their native systems. 

Alternatives See use case: Placement under mechanical constraints 

Postconditions The electrical components have been placed on the PCB and the layout has been harmonized with the 

mechanical designer within the framework of collaboration. 

Diagram 




The common data model allows for a common language in both system environments. This means that changes 

in one environment can be transferred in a standardized manner to the other environment and interpreted 

there. 


3.6 Change of board components 

Aim Components which have already been placed and harmonized within the collaboration framework are to be 

deleted or new components added. This use case can be initiated from either the MCAD domain or the ECAD 

domain. 


16 



requirements concerning the board outline 



Preconditions The board baseline has already been transferred and initial harmonization of the components has already 

been performed. 

Description Based on the initial board baseline, the electrical layouter or the mechanical designer starts the collabo ration 

process because changes relating to the components on the PCB have arisen. For example, the mechanical 

designer has realized that a component is no longer required since the design has been changed. Or 

the electrical layouter has realized that – due to an updating of the schematic – an additional electrical component 

which has not yet been placed on the PCB is required. 

Alternatives Non 

Once the collaboration has been initiated, the person who started the collaboration must transfer the information 

about the deleted or added components. Subsequently either the existing ID mapping is deleted (if a component 

has been deleted) or a new ID mapping is generated (if a new component has been added). 

Within the collaboration, both the mechanical designer and the electrical layouter now check together what 

impact the deleted or new component has on the existing PCB layout. 

Agreement can be achieved very quickly and efficiently within the framework of ECAD/MCAD collabo ration 


Postconditions After collaboration, the components have been either deleted or added and the impact of this change has 

been checked using both native systems. 



Diagram 



3.7 Change of placement locations 


moved to a different location as a result of new constraints. This use case can be initiated from either the 

MCAD domain or the ECAD domain. 









Description Based on the initial board baseline, the electrical layouter or the mechanical designer starts the collaboration 

process because changes relating to the placement of the components on the PCB have arisen. For example, 

the mechanical designer has detected collisions with the housing or the electrical layouter has realized 

that a certain wiring of the components does not fulfill the requirements. 

Once the collaboration has been initiated, the person who started the collaboration must transfer the information 

about the component to be moved. This involves transferring information about both the current position 

of the component and the desired new position. 

Within the collaboration, both the mechanical designer and the electrical layouter now check together what 

impact the new placement of the component has on the existing PCB layout. 

Agreement can be achieved very quickly and efficiently within the framework of ECAD/MCAD collabo ration 




Alternatives Non 

Postconditions After collaboration, the components have placed in a new position and the impact of this change has been 

checked using both native systems. 

Diagram 

Benefits The use of an ECAD/MCAD collaboration can significantly reduce the time needed for the iterative 

process. 


3.8 Replacement of components 


replaced as a result of new constraints. The replaced component provides the same functionality in the same 

way. This use case can be initiated from either the MCAD domain or the ECAD domain. 


18 




MCAD system: In the MCAD system, both the 3D geometry of the product is defined and the 2D/3D - 

in formation relating to the electrical components is processed. 





Description Based on the initial board baseline, the electrical layouter or the mechanical designer starts the collaboration 

process because a component is to be replaced by a different component offering the same functionality. 

Alternatives --- 

This can be the case, for example, if suppliers discontinue certain components, which means that they can 

no longer be included on the PCB. In this case, alternative components offering the same functionality must 

replace the existing components. 

Once the collaboration has been initiated, the person who started the collaboration must transfer information 

about the component to be replaced. Changes to the connectors in particular can lead to an additional 

need for collaboration since wiring may have to be moved. 

Within the collaboration, both the mechanical designer and the electrical layouter now check together 

what impact the replaced component has on the existing PCB layout. 

Agreement can be achieved very quickly and efficiently within the framework of ECAD/MCAD collaboration 


Postconditions After collaboration, the components in both domains can be replaced by the updated components since 

the impact of this change has been checked during collaboration using both native systems. 

Diagram 

Benefits The use of an ECAD/MCAD collaboration can significantly reduce the time needed for the iterative 

process. 




3.9 Panelization design review 

Aim The aim of the collaboration is to determine the optimal producibility of a PCB from a carrier material (panel). 

To save material costs and thus reduce raw material loss, the PCB layout and PCB design need to be reviewed 

for PWB (printed wiring board) panelization. At the end of the collaboration, the PCB layout that best 

meets manufacturing constraints will have been defined. 

20 

The diagram below represents an example result of the panelization process. 




Manufacturing or process engineer: Is responsible for the manufacturing line and is familiar with the constraints 

imposed by the available manufacturing machines 

Panelization simulation system: System which is able to simulate the PCB panelization process. 




Preconditions The PCB layout has been defined (board outline and component placement) and an initial PWB profile has 

been created. 

Description The electrical layouter, mechanical designer, manufacturing or process engineer and, if necessary, other persons 

must be involved in the design review since not only technical constraints but also commercial constraints 

have to be taken into consideration. 

Once the initial PWB profile for manufacturing the PCB has been created, the above-mentioned persons should 

come to an agreement in order to find the best solution – and not only from an electrical point of view. In the 

collaboration, answers can be found to questions such as, for example, where can symmetries be utilized or 

what tolerances have to be observed in the manufacturing process? 

From a manufacturing point of view, the best outcome is not always to make the panel as small as possible. 

Constraints such as utilization of the manufacturing lines or tool changes on the machines might mean that a 

larger panel can be manufactured more efficiently. 

In the collaboration, the current PWB profile is assessed by all those involved and, if necessary, any changes 

to be made are checked in the native systems. 



Alternatives --- 

Postconditions After the collaboration, the PCB layout which best meet manufacturing constraints and the matching PWB profile 

have been created. 

Diagram 

Benefits The use of an ECAD/MCAD collaboration can significantly reduce the time needed to reach agreement up 

to and including the manufacturing processes. 



4 SYSTEM AND PROCESS INTEGRATION ProSTEP iViP Recommendation 

4 System and Process Integration 

In order to integrate the ECAD/MCAD Collaboration process into the existing PDM/TDM environments an extension of the 

scope is necessary. The following figure shows the system architecture with a PDM-system participating within the collaboration 

process based on the EDMD Schema definition. Additionally it is important that an online and offline collaboration process 

will be supported by the EDMD schema. 

Figure 8: EDMD collaboration scope 

The PDM system is responsible to store and provide the data which is necessary within the collaboration. The PDM system is 

not responsible to steere the collaboration process. The collaboration process takes place between the ECAD and MCAD system 

and their collaboration moduls. An important role within the collaboration process plays the management of the collaboration 

sandbox. 

In the collaboration sandbox the data used within the collaboration is stored. Each system participating in the collaborations 

needs provide data in the collaboration sandbox. The physical representation of the collaboration syndbox differs if the collaboration 

is an online or offline collaboration. 

In an online collaboration the collaboration sandbox is a central “file system” in which the PDM-system checks out the native data 

which is used in the collaboration. It is a snapshot of the data in the collaboration space. After the collaboration the data stored 

in the sandbox is deleted. The PDM/TDM system takes care of the collaboration sandbox management within an online 


Within an offline collaboration the collaboration sandbox exists locally in each location. No centralized managed storage is 

available because the EDMD schema data is submitted with an offline medium such as email etc. The management of the collaboration 

sandbox is done by the user himself or by the participating collaboration systems. 

22 


ProSTEP iViP Recommendation 4 SYSTEM AND PROCESS INTEGRATION 

4.1 The role of a PDM system within collaboration 

The TDM system of the ECAD world only knows the electrical structure of the product. It has no informationen about the mechanical 

world. The TDM system of the MCAD world only knows the mechanical structure of the product. It has no informationen 

about the electrical world. Only the PDM system has - with the information about the partnumbers and a mapping table 

- the information about the mechanical and electrical structure of the product. For this reason the PDM system is responsible 

to provide th overall structure information used within a collaboration either to the TDM systems or directly to the participating 

ECAD or MCAD systems. 

It is not in the scope of the PDM/TDM system to provide storage mechanisms for the reduced models generated in the native 

systems for the purpose of the collaboration. The following figure shows that the PDM system is only responsible for the 

native data and the provision of this data to the ECAD or MCAD system or to the appropriate TDM systems. If the ECAD or 

MCAD system generates a derived model in order to support the collaboration this model is only valid within this specific 

collaboration. This models are stored in the collaboration sandbox. Only the changes to the original model after the collaboration 

will be stored backed into the PDM/TDM systems. 

Figure 9: PDM system stores not the collaboration models 

In order to define the role and the tasks of a PDM/TDM system within an ECAD/MCAD collaboration process it is necessary 

to analyze in a first step the collaboration set-up and closure process. 

It is important to distinguish between an online and offline collaboration process. Each process has different requirements concerning 

a PDM/TDM support. Furthermore it should be possible to switch the mode between online- and offline collaboration. 

Example: A collaboration process has started in an offline mode. During the collaboration a difficult problem was encountered 

and a decision was made to switch to an online collaboration. This use case should be supported by the participating systems. 

The principle workflows of online and offline collaboration will be described in the following chapters. 



4.1.1 Online Collaboration 

The following figure shows in principle an online collaboration process from the very first initialization up to the closure of the 

collaboration session. Additionally typical tasks which are necessary in each step are described. 

Figure 10: Steps of a collaboration process 

The inner collaboration in step four and five takes place between the ECAD and MCAD system without any PDM system 

participation. The use cases for the PDM system within the other steps of the collaboration process are described in the next 

chapter. 

24 



4.1.2 Offline Collaboration 

The following figure shows in principle an offline collaboration process from the very first initialization up to the closure of the 

collaboration session. All communication within the process is done with an offline communication medium such as email 

transfer. Additionally typical tasks which are necessary in each step are described in the figure. 

Figure 11: Steps of an offline collaboration process 



4.2 Use Cases for System and Process Integration 

In this chapter the use cases based on the standardized use case description (see chapter 3) are documented. 

4.2.1 Create Collaboration-Session-Object (CSO) for a collaboration session 

This Use Case is relevant in collaboration step 1 “Preparation of the collaboration” in online and offline collaboration. 

Aim The aim is the creation of a collaboration session object in the PDM system in order to represent the 

information of a collaboration session. All information generated during the collaboration session should 

be attached to this object in the PDM system. 

Actors In which system the CSO will be physically created? 

26 

a) Only in the requesting TDM system 

b) In both TDM systems 

c) Only in the PDM system 

d) In the PDM and TDM system 

PDM system 

Project manager: Responsible for the overall project. Defines the mechanical and electrical product structure, 

requirements and tasks. Controls results 

Preconditions Objects which should be used in the collaboration session are available in the PDM system. 

Description The project manager creates a collaboration session object for the collaboration session within the PDM 

system. The PDM system stores all relevant metadata such as version, creation data, creator etc. 

Alternatives None 

In an offline and online Collaboration this use case is done in the locally available PDM system. 

Post conditions A new collaboration session object (CSO) with all relevant metadata is created. 

Diagram None 

Benefits All information generated during the collaboration session is attached to one single object. This objects 

allows to exactly rebuild the collaboration session in future. 




4.2.2 Identify and attach PDM system objects to the CSO 


Aim The aim is to attach all object which are relevant within the collaboration to the collaboration session object. 

Actors Only the PDM system knows both worlds based on the meta data information and the BoM. The real data is 

stored in the different TDM systems. 

PDM system 



Preconditions A collaboration session object exists in the PDM system. 

Description The project manager identifies all PDM system objects (layouts, elements, parts, assemblies etc.) which should 

go into the collaboration session as collaboration objects. The project manager links these objects to the generated 

collaboration session object. The PDM system stores the selected version information for this objects 

together with the collaboration session object. 



Post conditions All relevant mechanical and electrical data is attached to the generated collaboration session object. 

Diagram None 

Benefits All data used during the collaboration session is attached to the collaboration session object. This objects 

allows to exactly rebuild the data used in collaboration session in future. 




4.2.3 Identify responsible persons based on the PDM system information 


Aim The aim is to identify all relevant persons which are responsible for the objects in a collaboration. 

Actors The identification must be done in the PDM system because not all user are administrated in the TDM system. 

28 

PDM system 



Preconditions A collaboration session object with attached data objects exists in the PDM system. 

A mapping of relevant persons to the collaboration objects exists in the PDM system. 

Description Based on the objects the project manager is able to identify the responsible persons and their roles for this 

objects based on a PDM system information. Minimum one person attached to the object should have an additional 

information which identifies the person as responsible for a collaboration. 



Post conditions A list of all persons which are relevant for the collaboration session is available. The rights within the collaboration 

session are defined based on the PDM system information. 

Diagram None 

In this example: 

Bob: Read/Write Access to MechanicalPart “Housing” and sub assembly 

Read Access to all other information 

Alice: Read/Write Access to MechanicalPart “Lower Part” 


Joe: Read/Write Access to ElectricalPart “Control PCB” and all components 


Benefits The project manager has a direct link to the responsible persons. This prevents time consuming searches of 

responsible persons. 




4.2.4 Invite responsible persons to the collaboration 

This Use Case is relevant in collaboration step 2 in an online collaboration and step 3 in offline collaboration “Initiation of the 

collaboration session”. 

Aim The aim is to automatically invite all relevant persons to a collaboration session. 

Actors Must be done via the PDM system. 

PDM system 



Preconditions A list of relevant persons which should participate the collaboration. 

Description Based on the list of participants the project manager is able to sent an invitation to the persons directly from 

the PDM system. The invitation could be for an online or offline collaboration session. 


In an offline collaboration the invitation is done via email or other offline media. In an online collaboration 

the invitation is done via an online service. 

The PDM system manages the responses and defines the time for the collaboration session. It informs the 

participants about the data which is relevant for the collaboration. 

Post conditions The invited persons know that there is a collaboration session scheduled. The starting time for the 

collaboration session is defined. 

Diagram None 

Benefits Every participant of the collaboration knows exactly the time an the content of the collaboration session. 


4.2.5 Select and start collaboration session 

This Use Case is relevant in collaboration step 2 in an online collaboration and step 3 in an offline collaboration “Initiation of 

the collaboration session”. 

Aim The aim is to automatically start the collaboration session with the invited persons and the necessary data. 

Actors Must be done via the PDM system. The PDM system must sent a message to the TDM system to start their 

collboration modules. 

PDM system 



Preconditions Collaboration Session Object, List of participants who have accepted the collaboration 

Description The project manager is able to start the collaboration session based in the Collaboration Session Object in 

the PDM system. 


In an offline collaboration the start of the collaboration session generates an email template with automatically 

filled in “Recipient “and “Subject”. The Recipient is derived from Use Case 3. In an online collaboration the 

collaboration session is started directly from the PDM/TDM system. The user gets an online message that a 

collaboration has started. (like Sametime) 



Post conditions The invited persons get a message that the collaboration starts. The persons can accept the start of the 


Diagram None 

Benefits No additional efforts to search relevant persons for the manager of a collaboration. 


4.2.6 Checkout data from the PDM system to the ECAD/MCAD system 

This Use Case is relevant in collaboration step 3 in an online collaboration and step 4 in offline collaboration “Provision of the 

data for a collaboration session”. 

Aim The aim is to automatically provide the necessary data to the participants of the collaboration. 

Actors The data is stored in the different TDM systems. The initiation of a check out process must be done from the 

PDM system based on the CSO information. 

30 

PDM system 

Preconditions Collaboration Session Object, List of participants who have accepted the collaboration 

Accepted collaboration from the participants. 

Description The PDM system provides the participants the current data necessary for the collaboration. It is also possible 

that the PDM system automatically starts the corresponding application. 


In offline collaboration the data is directly attached to the email or available in the file system of the receiver. 

In an online collaboration the data is checked out directly to a “central” collaboration space. 

Post conditions The data is loaded in the application participating the collaboration. The user has now the possibility to perform 

the collaboration session based on this data. 

Diagram None 

Benefits The user has no additional efforts in order to load the data to the application. The PDM system ensures that 

the correct versions are loaded. 


4.2.7 Store back modifications into the PDM-system 

This Use Case is relevant in collaboration step 6 in an online collaboration and step 8 in offline collaboration “Documentation 

of the collaboration session”. 

Aim The aim is to store the modifications which are the result of a collaboration back into the PDM system. 

Actors The information about meta data changes must be stored back to the PDM system together with the sandbox 

data. The modified data must be stored back via the standard TDM system interface to the TDM system. 

PDM system 

Preconditions Finished collaboration session. 



Description After the collaboration has finished the PDM system automatically stores the metadata information generated 

within the collaboration back to the CSO, e.g. protocol of collaboration, participating persons, objects 

modified etc.. After the collaboration the CSO gets a PDM status “frozen” which does not allow to modify this 

version of the object in the future. 


Furthermore each participant has the choice to store the modified native information back to the PDM system with 

the following possibilities: 

1. Overwrite existing data 

2. Create new version of data 

3. Create new data 

In an offline collaboration this could be only done with a manual import of the data to the local PDM systems. In 

an online collaboration the data from the collaboration space could be checked in directly to the PDM system. 

Post conditions The collaboration is documented with the frozen CSO and the modified data is stored back in the PDM system. 

Diagram None 

Benefits No information gets lost. The collaboration is exactly documented and comprehensible in the future. 


4.3 PDM/TDM system supported collaboration 

The following chapter describes the principle collaboration process in the case that a PDM and a TDM system exist in the 

company. 

Figure 12: PDM/TDM supported Collaboration Step by Step 1/4 





32 






4.4 PDM system supported cooperation 

Based on the described use cases the PDM system must fulfill additional requirements The following picture gives a rough overview 

of the necessary PDM system’s collaboration session support: The roles and objects as well as the resulting requirements 

will be described in the following sub chapters. 

Figure 16: PDM system’s collaboration session support 

34 



4.4.1 Represent additional user roles which are necessary within a collaboration 

The PDM system should represent additional user roles which are necessary for a collaboration. These role are: 

Collaboration manager: Person who has the right to manage a CSO by means of creating links to other objects, starting 

the collaboration, inviting persons, managing and versioning the CSO etc. 

Collaboration part responsible: Person who is responsible for a PDM system part within a collaboration session. Each part 

in the PDM system should have exactly one person who is responsible for the part in the collaboration context. This person 

participates in a collaboration session. It must be ensured that all necessary software is installed for a person which has this 

role. It must be defined which application this person will use within a collaboration. The Collaboration part responsible 

can change release levels of the data according to the collaboration, e.g. a part of the PDM system could have the status 

“released for collaboration”. 

Collaboration leader: Person who has the lead within a collaboration. This person could be different from the 

collaboration manager or the same person. A Collaboration leader has the right to initiate a collaboration. He is not 

allowed to generate links between the CSO and other PDM system’s objects. The role Collaboration leader could be 

granted by a Collaboration manager. The Collaboration leader defines the access rights and privileges of a person/role 

related to a specific collaboration item (e.g. view, update, create of object data and structures). The PDM system provides 

a collaboration management support for the collaboration leader. 

4.4.2 Management of a collaboration session object within the PDM system 

The PDM system data model must be able to define a collaboration session object (CSO). The CSO must be versioned and 

must be able to have links to other objects stored in the PDM system. The CSO has an own version management within the PDM 

system. After a collaboration a new version of the CSO will be created automatically and the old version will be checked in 

and frozen. The CSO should only be created with a specific PDM system’s role called Collaboration manager. 

4.4.3 CSO Metadata management 

It should be possible to attach additional metadata to the CSO, such as creator, creation date, collaboration history etc. 

4.4.4 CSO Document management 

It should be possible to attach additional documents to the CSO, e.g. the protocol of a collaboration after the collaboration has 

finished. 

4.4.5 CSO Search management 

The PDM system’s search and retrieve mechanisms should allow to search upon specific attributes of the CSO. 

4.4.6 CSO Link management 

It is important that a CSO could be linked with other objects of the PDM-system. Especially the linkage between the CSO and 

the data which should be used in the collaboration is a prerequisite for the start of a collaboration based on the CSO. 

4.4.7 Collaboration session preparation support 

Appropriate mechanisms for initiating the collaboration must be made available. These mechanisms allow the collaboration partner 

to be informed of a desire for collaboration. To do this, a means of clearly identifying the partner must be introduced. The 

data which should be used within a collaboration is called the collaboration scope. This data will be linked a collaboration manager 

to the collaboration session object, The PDM system should automatically identify all persons which have the role 

“Collaboration part responsible” for the parts of the collaboration scope. These persons are the basis for the invitation management 

of the collaboration. 



This identification allows the current collaboration session to be initiated. The PDM system invites responsible persons based on 

the CSO for a collaboration and support of the two principle collaboration types: 

Synchronous (online) Collaboration: All users which should attend the collaboration are logged in the PDM system (online). 

The PDM system should use an internal notification mechanism and invite the responsible persons. The PDM system should 

provide possibilities to reject, accept or rearrange a collaboration invitation. 

Asynchronous (offline) Collaboration: Users which should attend the collaboration are offline. The PDM system should 

inform the inviting user that only a offline collaboration is possible. It should start the collaboration. 

4.4.8 Collaboration session initiation support 

The PDM system must provide mechanisms to start the collaboration based on a CSO. The PDM system must furthermore check 

if all necessary information for the collaboration is linked to the CSO: 

1. Data for the collaboration session (collaboration scope) 

2. Responsible persons (Collaboration part responsible) 

3. Data and time of the collaboration session 

The right to start a collaboration should be attached to a specific role within the PDM system, e.g. a collaboration manager 

role. The role could be attached also to a mechanical or electrical designer if they should be able to start a collaboration process. 

4.4.9 Collaboration session data management 

The PDM system should automatically check out all relevant data for a collaboration session. Based on the information of the 

CSO the PDM system should retrieve the “Collaboration part responsible” persons. Each person has associated a collaboration 

application. The PDM system could automatically start the defined application and with its collaboration session management 

module. The Collaboration part responsible has the task to define the data which should be shared within the collaboration 

session in the collaboration “sandbox”. After the collaboration session the Collaboration part responsible has the option 

which modification from the collaboration influence the native data. The native data is stored back to the PDM system. The PDM 

system provides the following possibilities: 

1. Overwrite existing data in the PDM system 

2. Create new version of the existing data in the PDM system 

3. Create new data with now version history 

Remark: the collaboration data itself (sandbox data) gets lost after the collaboration. 

4.4.10 Closing the collaboration session 

After closing the collaboration session by the Collaboration leader the PDM system should store back the metadata and 

session information to the CSO. This could be for example: 

Participating persons 

Collaboration session log file 

After the collaboration it should not be possible to modify the content or the link information of a CSO. The PDM system must 

ensure that this information is frozen within the PDM system. 

36 



4.4.11 Managemet of the Collaboration sandbox 

The management of a data check out process is done within the PDM system. From a PDM system’s point of view it is not 

relevant if the checkout is done for the reason of working with the data or collaborating with the data. 

The ‘simplified’ data used within collaboration is stored locally in the so called sandbox. After the collaboration the changes are 

submitted back to the native data. 

For an online collaboration the sandbox data will be deleted after the closure of the collaboration process. Within an online 

collaboration the PDM system takes care on this step. The results of the collaboration are only available in the native ECAD or 

MCAD system. 

Within an offline collaboration the sandbox exists locally in each location. Therefore the user himself must take care about the 

further management of the sandbox data. In an offline collaboration this is no requirement for a PDM or TDM system. 

4.4.12 Handling of ECO/ECR within a collaboration process 

The asumption is, that the handling of an Engineering Change Request and an Engineering Change Order is availbale in the 

standard installation of the PDM system in a company. The handling is synchronized with the versioning mechanisms of the PDM 

system. If an ECO is succesful a new version of the data is created. 

Form the collaboration point of view the versioning is used to 

1. Perform a versioning of the Collaboration session object: Which each initiation of the same collaboration a new version 

of the CSO is created. The previous results of a collaboration are still available in the previous version of the CSO. 

2. Perform a versioning of the part modified during the collaboration session. After the collaboration is closed the user has 

the choice if the modified results are stored back from the sandbox to the native data and afterwards back to the PDM 

system. In this case a new version of the data will be generated. 

The ECDA/MCAD collaboration has no additional special requirements to the handling of these processes. The mechanism 

could be applied to the collaboration process as well. 


5 STANDARDIZED LIBRARY COMPONENTS ProSTEP iViP Recommendation 

5 Standardized Library Components 

To create ECAD representations and 3D representations of electrical and electromechanical components is an enormous 

workload. The goal is to provide within the EDMDSchema a standardized component library specification of components. 

5.1 Use Cases for Standardized Library Components 

In this chapter the use cases for an EDMDSchema supported library management are documented. The documentation is based 

on the standardized use case description (see chapter 3). 

The following three use cases were defined and will be detailed in the next chapters: 

UC1: Using library information within collaboration 

UC2: Cross domain library to library data exchange 

UC3: Provision of library data from supplier 

5.1.1 Using library information within collaboration 

Aim Within the collaboration process the usage of library information should be enabled. 

Actors ECAD, MCAD, ECAD-Library, MCAD-Library. 

Preconditions Established collaboration session. The two standard library elements are available in each library of the 

participating systems. Functionality for instantiation based on parameters exists within the libraries. 

Description The standardized library information is used in order to minimize necessary data exchange within 

collaboration. For library elements only the element type and the standardized parameterization needs to be 

exchanged. An explicit exchange of the component geometry is not necessary. 

Alternatives No alternatives. 

Post conditions Library elements are available as explicit collaboration object with all necessary information. The instantiation 

was done by each system based on the provided parameterization of the library components. 

Diagram 

Benefits Minimization of data exchange. Individual Library element description possible (e.g. 3D for MCAD, 2D for 

ECAD etc.). Standardized data exchange. 

Notes After first instantiation the library components may be modified or enriched by librarian information, e.g. 

pure ECAD information has to be added to ECAD library components. 

38 


ProSTEP iViP Recommendation 5 STANDARDIZED LIBRARY COMPONENTS 

5.1.2 Cross domain library to library data exchange 

Aim Exchange of library information between different ECAD- and MCAD-libraries. 

Actors ECAD-Library, MCAD-Library. 

Preconditions The two standard library elements are available in each library of the participating systems. Functionality for 

instantiation based on parameters exists within the library. 

Description The standardized library information is used in order to synchronize the information between different existing 

libraries. The standardized library information could also be used for building new library content. Each 

library has its own mechanism for generating the components. The parameterization of the components which 

is submitted via the EDMDSchema must contain all necessary information. 

Alternatives Without the EDMDSchema support an exchange between library information is only possible with a manual 

process. 

Post conditions After the synchronization the library elements are instantiated within the participating libraries based on the 

submitted parameterization. 

Diagram 

Benefits Minimization of manual data exchange work. Transfer between different library types (2D/3D) possible 

based on an individual parameterization. 



5.1.3 Provision of library data from supplier 

Aim Exchange of component information between component supplier and customer based on the EDMD-Schema. 

Actors Supplier, ECAD-Library, MCAD-Library. 

Preconditions 2 Standard library elements are available in the customer target library. Functionality for instantiation based 

on parameters exists within the library. 

Description The standardized library information is used in order to submit component information from a supplier to its 

customer. The information could be used to fill either a mechanical or an electrical component library. The 

standardized library information is used in order to build up new library content based on the supplier's specification. 

Alternatives Exchange of the component information based on “common” data exchange ways such as email, fax etc. 

and manual entering of the information into the library. 

Post conditions After the data transfer the supplier component is available as a component within the customer library. The 

component was instantiated automatically based on the submitted parameterization. It could be directly used 

within the ECAD- or MCAD-application. 



Diagram 

Benefits Error free component information data exchange. Minimization of manual work. Digital process without 

paper based information. 



5.2 Parameterized Library Components 

The EDMD library schema is based on two standard electrical component types (cp. Figure 17). Each type is parameterized 

within a library-dependent native format. The data exchange of a component instance takes place based on the component type 

and the parameter information. The parameterization information is standardized within the EDMDSchema definition. The 

EDMDSchema is not a format for the library definition, meaning each library could have additional, tool dependent component 

information such as tool dependent wiring and insertion information etc. 

Figure 17: Main characteristics of Master Model Types 

40 



Basic principle for the standardized library components is the definition of parametric 3D master models.These master models 

are categorized into two types, which differ in their main geometric appearance. In Scope is the rough geometry with exact 

dimensions and additional necessary information for both MCAD and ECAD. Technology information is out of scope. The 

instantiation itself will be triggered by the corresponding XML-File, which contains the parameters to feed the 3D master models. 

Afterwards, the instantiated models may be modified or enriched by librarian information. 

The specification of the 3D master parts is independent from any specific CAD system. As a result users and respectively 

vendors could implement the master model parts in their own ECAD or MCAD system 

environment. 

The master models are specified by both geometrical parameters and non-geometrical parameters. The parameters are 

categorized into element classes. The hierarchical structure is illustrated in Figure 18: 

Figure 18: Hierarchical structure of the parameters of 3D master models 

The parameters describing the master models and driving the respective component instantiations are stored in an XML file with 

the identical hierarchical structure. The structure of the XML file has to be conform with the part of the EDMDSchema specifying 

the master model (cp. 6.6.18). 



5.2.1 3D Master Model "Type A" 

In the following table the geometrical parameters of the master model "Type A" are listed: 

Element Class Parameter short name Parameter full name 

(in illustration) (in EDMDSchema) 

Electrical Insertion Point X_Offset ACS_X_Offset 

42 

Y_Offset ACS_Y_Offset 

Z_Offset ACS_Z_Offset 

Angle ACS_Angle 

Body Width Body_Width 

Length Body_Length 

Height Body_Height 

Bottom_Height Body_Bottom_Height 

Chamfer_LB Body_Chamfer_LB 

Chamfer_RB Body_Chamfer_RB 

Chamfer_LA Body_Chamfer_LA 

Chamfer_RA Body_Chamfer_RA 

Additional Body Add_Length Body_Add_Length 

Add_Width Body_Add_Width 

Add_Radius Body_Add_Radius 

Add_Bottom_Height Body_Add_Bottom_Height 

Add_Height Body_Add_Height 

Add_Offset_X Body_Add_Offset_X 

Add_Offset_Y Body_Add_Offset_Y 

Opt Hole_X Opt_Hole_X 

Hole_Y Opt_Hole_Y 

Hole_Diameter Opt_Hole_Diameter 

Hole_Z1 Opt_Hole_Z1 

Hole_Z2 Opt_Hole_Z2 

Cut_X1 Opt_Cut_X1 

Cut_Y1 Opt_Cut_Y1 

Cut_X2 Opt_Cut_X2 

Cut_Y2 Opt_Cut_Y2 

Cut_Z1 Opt_Cut_Z1 

Cut_Z2 Opt_Cut_Z2 





Pin 

Width_R 

Width_L 

Width_B 

Width_A 

Pitch_R 

Pitch_L 

Pitch_B 

Pitch_A 

Thickness_R 

Thickness_L 

Thickness_B 

Thickness_A 

Radius_R 

Radius_L 

Radius_B 

Radius_A 

Fixation_Height_R 

Fixation_Height_L 

Fixation_Height_B 

Fixation_Height_A 

Fixation_Height_1_R 

Fixation_Height_1_L 

Fixation_Height_1_B 

Fixation_Height_1_A 

Length_R 

Length_L 

Length_B 

Length_A 

Length_1_R 

Length_1_L 

Length_1_B 

Length_1_A 

Offset_R 

Offset_L 

Offset_B 

Offset_A 

Pin_Width_R 

Pin_Width_L 

Pin_Width_B 

Pin_Width_A 

Pin_Pitch_R 

Pin_Pitch_L 

Pin_Pitch_B 

Pin_Pitch_A 

Pin_Thickness_R 

Pin_Thickness_L 

Pin_Thickness_B 

Pin_Thickness_A 

Pin_Radius_R 

Pin_Radius_L 

Pin_Radius_B 

Pin_Radius_A 

Pin_Fixation_Height_R 

Pin_Fixation_Height_L 

Pin_Fixation_Height_B 

Pin_Fixation_Height_A 

Pin_Fixation_Height_1_R 

Pin_Fixation_Height_1_L 

Pin_Fixation_Height_1_B 

Pin_Fixation_Height_1_A 

Pin_Length_R 

Pin_Length_L 

Pin_Length_B 

Pin_Length_A 

Pin_Length_1_R 

Pin_Length_1_L 

Pin_Length_1_B 

Pin_Length_1_A 

Pin_Offset_R 

Pin_Offset_L 

Pin_Offset_B 

Pin_Offset_A 





Pad 

In the following table the non-geometrical parameters of the master model "Type A" are listed: 

44 

Length 

Width 

Offset_R 

Offset_L 

Offset_A 

Offset_B 

Pad_Length 

Pad_Width 

Pad_Offset_R 

Pad_Offset_L 

Pad_Offset_A 

Pad_Offset_B 


(in EDMDSchema) 

Body 

Additional Body 

Pad 

Opt 

Pin 

Color 

Add_Count 

Color 

Name 

Count_R 

Count_L 

Count_A 

Count_B 

Hole_Count 

Cut_Count 

Identifier 

Digit 

Number_R 

Number_L 

Number_B 

Number_A 

Type_R 

Type_L 

Type_B 

Type_A 

Body_Color 

Body_Add_Count 

Body_Add_Color 

Pad_Name 

Pad_Count_R 

Pad_Count_L 

Pad_Count_A 

Pad_Count_B 

Opt_Hole_Count 

Opt_Cut_Count 

Pin_Identifier 

Pin_Digit 

Pin_Number_R 

Pin_Number_L 

Pin_Number_B 

Pin_Number_A 

Pin_Type_R 

Pin_Type_L 

Pin_Type_B 

Pin_Type_A 





Color_R 

Color_L 

Color_B 

Color_A 

Index_R 

Index_L 

Index_B 

Index_A 

Increment_R 

Increment_L 

Increment_B 

Increment_A 

Count_R 

Count_L 

Count_A 

Count_B 

Pin_Color_R 

Pin_Color_L 

Pin_Color_B 

Pin_Color_A 

Pin_Index_R 

Pin_Index_L 

Pin_Index_B 

Pin_Index_A 

Pin_Increment_R 

Pin_Increment_L 

Pin_Increment_B 

Pin_Increment_A 

Pin_Count_R 

Pin_Count_L 

Pin_Count_A 

Pin_Count_B 

The geometrical parameters of the 3D master model "Type A" are described within the extra document PSI5_Mastermodel_Type_A.pdf, 

which is also part of the recommendation but not part of this printable piece of the recommendation. Within this 3D PDF 

document the dimensioning concept is illustrated. The dimensions of the respective parameters are stored on different views. 

Through show and hide mechanism of selective parameters or even entire views, it is very comfortable to understand the 

definitions of the parameters. As basis orientation a clockwise cartesian coordinate system is used (x-axis red arrow, y-axis green 

arrow, z-axis blue arrow). 

For purposes of clarity not all definitions are described in the 3D PDF document. The following definitions are described by 

separate illustrations: 

Pin Types 'L", "I", "Z" and "C" 

Offset of Additional Body 

Definition of numbering and naming of Pins 

Additional Pin rows 

Offset for pin rows 

Definition of Copper Area 



The position of the pins is represented in the 3D PDF master model description. The definition of the pin types "L", "I", "Z" and "C" 

are described by the following drawings: 

Figure 19: Pin type "L" 

46 

Figure 20: Pin type "I" 

Figure 21: Pin type "Z" Figure 22: Pin type "C" 



The offset of the additional body is illustrated by Figure 23: 

Figure 23: Offset additional body 

Each Pin row has an Index for numbering, and a counting Increment. In addition each Pin has a number (Pin_Digit) and a 

name (Pin_Identifier). The numbering and naming of the pins is described in Figure 24: 

Figure 24: Numbering and naming of Pins 

Example: Pin_Index_A = 1 and Pin_Increment_A = 2, then the pins in row A have the numbers 1, 3, 5, and 7 

Additional pin rows are allowed for each side [0…n]. The pin rows are defined by the following parameters 

Type 

Pitch 

Offset 

Width 

Number 



The pin rows could have an offset (cp. Figure 25): 

Figure 25: Offset for pin rows 

Positive values for offset in positive x-/y-axis; negative values for offsets in negative x-/y-axis (e.g. Pin_Offset_A in above 

figure). Equivalent definition for Pin_Offset_L and Pin_Offset_R. 

The definition of the simplified copper area is illustrated in Figure 26: 

Figure 26: Copper area definition 

Multiple copper area pads are allowed [0..n]. The pad is defined by the length, width and an offset. The pad is always 

centered to longitudinal direction and is located on the x-y plane (z=0). Each pin row refers to one pad type. 

48 



5.2.1.1 Implementation Constraints 

For the implementation of the 3D master model "Type A" in a CAD system the following implementation 

constraints have to be observed: 

Default Orientation 

- The longer side of the basic body extends along the x-axis 

Body 

- Origin in the middle of the Body 

Optional Chamfers of Basic Body 

- 45° Chamfers 

- If value = "0" or "" then no Chamfer 

Optional Additional Body 

- All 4 radiuses are identical 

- Multiple Additional Bodies allowed: Add_Count [0..n] 

Cut (Optional through Body or Contacts) 

- Multiple Cuts allowed: Cut_Count [0..n] 

Hole (optional through Body or Contacts) 

- If Diameter = 0 or "" then no Hole 

- Multiple Holes allowed: Hole_Count [0..n] 

Pin (the asterisk symbol * represents the for sides A, B, L and R) 

- "Pin 1" is the pin along the positive x- and y-axis (first max. x-direction, then max. ydirection) 

- Pin definition for each side is independent (different Pins on sides right (R), left (L), ahead (A) and behind (B) possible) 

- Positioning of pins: evenly distributed on each row [number of Pins and pitch] 

- Definition of 'Pin_Length' and 'Pin_Length_1' depends on the 'Section Type' 

- Multiple Pin(rows) allowed: Pin_Count_* [0..n] 

- Pin_Identifier and Pin_Digit refers to Pin_Index_* and Pin_Increment_* 

- Identical Pin_Radius for each edge of the pin 

- If both the Pin_Width and the Pin_Thickness are twice the Pin_Radius, the pins are round. 

- Pin_Length_2 could be negative, then the Pins will go through the Basic Body (cp. Figure 27): 

Figure 27: Pins through Basic Body 



5.2.2 3D Master Model "Type B" 

In the following table the geometrical parameters of the master model "Type B" are listed: 



Electrical Insertion Point 

Body 

Pin 

Pin optional 

In the following table the non-geometrical parameters of the master model "Type B" are listed: 



Body 

Pin 

The geometrical parameters of the 3D master model "Type B" are described within the extra document PSI5_Mastermodel_Type_B.pdf, 

which is also part of the recommendation but not part of this printable piece of the recommendation. Within this 3D PDF 

document the dimensioning concept is illustrated. The dimensions of the respective parameters are stored on different views. 

Through show and hide mechanism of selective parameters or even entire views, it is very comfortable to understand the 

definitions of the parameters. As basis orientation a clockwise cartesian coordinate system is used (x-axis red arrow, y-axis green 

arrow, z-axis blue arrow). 

50 

X_Offset 

Y_Offset 

Z_Offset 

Angle 

Diameter 

Length 

Diameter 

Length 

Width 

Diameter 

Length 

Width 

Color 

Color 

ACS_X_Offset 

ACS_Y_Offset 

ACS_Z_Offset 

ACS_Angle 

Body_Diameter 

Body_Length 

Pin_Diameter 

Pin_Length 

Pin_Width 

Pin_opt_Diameter 

Pin_opt_Offset 

Pin_opt_Width 

Body_Color 

Pin_Color 



5.2.2.1 Implementation Constraints 

For the implementation of the 3D master model "Type B" in a CAD system the following implementation constraints have to be 

observed: 

"Pin 1" is the pin along the positive x-axis 

Model is mirror-symmetrical 

- Cylinder is in the middle of the pins 

- Both pins are identical 

Special type with "ring" as contact without standard L-Pins 

- Inner Diameter of ring equals Body Diameter 

- Standard L-Pins values: 

· Pin_Diameter = 0 

· Pin_Length = 0 

· Pin_Width = 0 

Special type with upright body position is out of scope 

5.2.3 General Implementation Issues 

The following implementation constraints are valid for both Types A and B: 

Tolerances 

- Tolerances must be applied to all geometric parameters 

· Nominal Value 

· algebraic sign + Tolerance for Maximum Material Model 

· algebraic sign + Tolerance for Minimum Material Model 

Color 

- Each feature (Basic Body, Add. Body, Pin row) has an attribute for the color 

· 9-digit rgb-code (e.g. 255255255 for white) 

Electrical Insertion Point 

- ACS Electrical Insertion Point represents the placement constraint. The origin coordinate system is just for defining the ACS. 


6 EDMD DATA MODEL ProSTEP iViP Recommendation 

6 EDMD data model 

6.1 Overview 

An application-driven data model based on user requirements was first of all defined within the project group. The applicationdriven 

data model is intended to describe the requirements relating to ECAD/MCAD collaboration from the view of the user. In 

addition, it should also be able to support the functionality required by the user within the framework of an ECAD/MCAD 


The application-driven data model is divided into different functional areas, which are referred to as “packages”. Figure 28 

provides an overview of the developed data model with the nine currently defined packages. 

Figure 28: Overview of the application-driven data model 

The contents of the packages are described in detail in section 6.2 below. A detailed description of the objects in the packages 

can be found in section 6.3. 

In the next step, the application-driven data model was mapped to an implementation-driven data model within the project group, 

together with the implementors. This data model serves to satisfy the boundary conditions for efficient implementation. 

To do this, the implementation-driven data model can, for example, group together objects, convert objects into attributes, 

simplify relationships, etc. These changes ensure efficient implementation with the consideration of boundary conditions such as 

uniqueness, stability and performance of the software solution. The implementation-driven data model is described in detail in 

section 6.5.1. 

52 


ProSTEP iViP Recommendation 6 EDMD DATA MODEL 

6.2 Packages in the user-driven data model 

6.2.1 Package 1: item definition and product structure 

The central package in the application-driven data model is the Package "item definition and product structure" (cp. Figure 29). 

The entire structure between the objects involved in the collaboration is described in this package. Additional information such 

as the properties and geometry of these collaboration objects can be defined using the objects in the other packages. In addition, 

the versioning of collaboration objects (item_version) and the multiple utilization of objects (item_instance) are defined in 

this package. 

Figure 29: Overview of the “item definition and product structure” Package 

Application example: 

20 LED displays of the same type (item) and with an identical version status (item_version) are placed on a PCB (Printed Circuit 

Board). Each LED display is then defined as an item_instance. Since the LED displays have different positions on the PCB, the 

positioning of the item_instance objects are defined using a transformation (in this case transformation_2D). 

The following objects are defined in this package: 

item, item_version, design_discipline_item_definition, collaboration_definition, instance_placement, single_instance, item_instance, 

assembly_definition, interconnect_module, pcb, item_definition_instance_realtionship, assembly_component_relationship, 

next_higher_assembly, geometric_model_relationship_with_transformation, transformation, transformation_2d, transformation_3d 



6.2.2 Package 2: item classification and grouping 

In addition to Package 1, the Package "item classification and grouping" allows the classification and grouping of collaboration 

objects and their versions (cp. Figure 30). 

Figure 30: Overview of the “item classification and grouping” Package 


All the LED displays (represented by item objects) on a PCB can be grouped together by means of a classification 

(general_classification). 


classification_association, general_classification, classification_attribute 

54 



6.2.3 Package 3: person and organization information 

Person and organization-specific data is defined in the Package "person and organization information" (cp. Figure 31). The 

package allows a person with a specific role to be assigned to each collaboration object. 

Figure 31: Overview of the “person and organization information” Package 


A capacitor on the PCB (represented by an item object) can be assigned the person Miller in his role as “electrical layouter” 

(using the object person_and_organization_assignment). This allows clear identification during collaboration of which persons 

are, for example, allowed to make changes to the components. 


organization, person_organization_assignment, person, person_in_organization 



6.2.4 Package 4: ECAD shape information 

The "ECAD shape information" Package describes component-related geometric information about how the electrical components 

are, for example, stored in a component library (cp. Figure 32). The package allows electrical semantics to be defined 

for an explicit 2D or 3D geometry (defined in Package 7 or Package 8). 

Figure 32: Overview of the “ECAD shape information” Package 


non_feature_shape_element, interconnect_module_constraint_region, shape_feature, 

component_termination_passage_template_terminal, component_termination_passage_template_join_terminal, 

component_termination_passage_template_interface_terminal, printed_part_template_terminal, 

printed_part_cross_section_template_terminal, printed_part_template_interface_terminal, printed_part_template_terminal, 

printed_part_template_join_terminal, part_feature_ part_mounting_feature, assembly_component, 

definition_based_product_occurence, thermal_component, assembly_group_component, laminate_component, 

56 



inter_stratum_feature, unsupported_passage, stratum_feature_template_component, cutout_edge_segment, 

plated_ cutout_edge_segment, plated_inter_stratum_feature, plated_passage, via, filled_via, component_termination_passage, 

stratum, documentation_layer_stratum, design_layer_stratum, stratum_technology, documentation_layer_technology, 

design_layer_technology, cutout, plated_cutout, partially_plated_cutout, physical_connectivity_interrupting_cutout 



6.2.5 Package 5: constraint definition 

The "constraint definition" Package can be used to define constraints between objects or properties (cp. Figure 33). 

Figure 33: Overview of the “constraint definition” Package 


A constraint of the type “relating” can be used to indicate the fact that two components must only ever be moved together during 

a collaboration session, i.e. the constraint places restrictions on the positioning of the items. 


constraint, item_constraint, property_constraint 

58 



6.2.6 Package 6: property and material definition 

The definition of arbitrary properties and materials relating to collaboration objects is a fundamental part of any collaboration. 

Therefore all this information has been grouped together in a separate package (cp. Figure 34). The package "property and 

material definition" allows properties, together with parameters and ranges of values, to be assigned to an entire class of collaboration 

objects (item) or their instances (item_instance). The defined properties are represented by values and units. It is also 

possible to assign materials. 

Figure 34: Overview of the “property and material definition” Package 


10 LED displays have been placed on a PCB. All the LED displays can be assigned the material “plastic”. To do this, the 

relationship directly to the item “LED” is used for property assignment. Each individual instance (item_instance) of the 10 LED 

displays can, for example, be assigned a different color using a "general_property" object with "property_type = color". The 

values of the color properties are defined using the "property_value" object with "value_name = red, green, blue etc.". 


item_property_association, property_value_association, property_value_representation, property, property_value, 

unit_ value_with_unit, numerical_value, value_limit, value_range, feature_parameter, material_property, general_property, 

general_parameter, material_property_value_representation, material_property_association, data_environment 



6.2.7 Package 7: 2d geometry model 

The "2d geometry model" Package allows the definition of two-dimensional geometry elements within collaboration (cp. Figure 35). 

Figure 35: Overview of the “2d geometry model” Package 


A change to the board outline is to be defined within a collaboration session. To do this, the collaboration object “PCB” (defined 

using an item) can be assigned the appropriate outline defined, for example, as a b-spline_curve. Changes to the individual 

points on the curve can then be made directly in the collaboration session and then transferred to both the MCAD and 

ECAD systems. 


wireframe_model_2d, curve_set_2d, curve, hyperbola, composite_curve, line, ellipse, plyline, curve_on_surface, trimmed_curve, 

circle, parabola, offset_curve, b_spline_curve, detailed_geometric_model_element, point, point_on_surface, point_on_curve, 

cartesian_point 

6.2.8 Package 8: shape dependant information 

The basic elements that allow geometric properties to be assigned to collaboration objects are contained in the Package "shape 

dependant information" (cp. Figure 36). A more detailed description of the geometry takes place in Package 7 or Package 

9. Furthermore, this package allows external geometric models, e.g. in an external file, to be assigned to an item. This package 

also allows annotations to be added during collaboration by means of the “annotation” object. The annotations can be represented 

either geometrically or as text. 

60 



Figure 36: Overview of the “shape dependant information” Package 

Application example (1): 

The exact geometry of an electrical component has been stored in a neutral 3D geometry format, e.g. STEP AP214 CC02. The 

object "external_model" can be used to assign the file containing this geometry to the “design_discipline_item_definition” of the 

electrical component (item). 

Application example (2): 

During a collaboration session a specific part of a PCB element is of special interest. Therefore the "annotation" object kann be 

used to assign a textual or graphical annotation to the "shape description" of this item. 


item_shape, shape_element, shape_description, annotation, geometric_model, shape_dependent_property, 

general_shape_dependent_property, moments_od_inertia, centre_of_mass, cartesian_coordinate_space, 

cartesian_coordinate_space_2d, cartesian_coordinate_space_3d, external_model, digital_file, external_geometric_model, 

external_geometric_model_with_parameters 




The "3d geometry model" Package allows three-dimensional geometry elements to be defined within collaboration (cp. Figure 

37). These can be stored either as a B-rep model or hybrid model. Package 9 thus allows three-dimensional geometric changes 

to be taken into consideration directly in a collaboration. 

Note: This is, however, only possible insofar as both the systems involved in the collaboration can work with three-dimensional 

geometric models. 

In the first version of the Recommendation, the collaboration is limited to 2D elements. Therefore although the 3D geometry 

package has been included in the structure, its contents have not yet been defined. 

Figure 37: Overview of the “3d geometry model” Package 


b_rep_model, hybrid_geometric_model_3d 

6.3 Objects 

6.3.1 annotation 

An annotation is used to annotate specific shape elements during a collaboration. The annotation could be a simple text or a 

complex 2D geometry used to define the area for which the annotation is applicable. 

This object type has no attributes. 

6.3.2 assembly_component 

An assembly_component represents a component in an assembly or in an interconnect. An assembly_component is a type of 

item_shape and of definition_based_product_occurrence. 


6.3.3 assembly_component_relationship 

An assembly_component_relationship is the relation between an assembly_definition and an item_instance representing a 

constituent of the assembly. 

Note: The constituent may also be an assembly. 

An assembly_component_relationship is a type of item_definition_instance_relationship. The association placement specifies the geometric_model_relationship_with_transformation 

that specifies the transformation information which is used to locate and orient the constituent 

in the coordinate space of the assembly_definition. If present, there must be exactly one object that defines the placement for 

an assembly_component_relationship. The association relating specifies the assembly_definition that has subordinate constituents. 


62 



6.3.4 assembly_definition 

An assembly_definition is a definition of an item_version that contains other subordinate objects. An assembly_definition is a 

type of design_discipline_item_definition. 

The following table shows the attributes of an assembly_definition: 

Attribute name Description 

id The id specifies the identifier of the design_discipline_item_definition. 

name The name specifies the name of the design_discipline_item_definition. 

assembly_type The assembly_type specifies the kind of the assembly_definition. Note: "functional 

assembly" or "design assembly" are examples of an assembly_type. 

6.3.5 assembly_group_component 

An assembly_group_component is a type of assembly_component. Each component that is part of a group is in the same 

design view as that group. 


6.3.6 b_rep_model 

A b_rep_model is a collection of b_rep objects.A b_rep-model is a type of geometric_model and is used fpr the representation 

of 3 dimensional geometry. 


6.3.7 b_spline_curve 

A b_spline_curve is a general polynomial or a rational parametric sculptured curve of various degrees and segments, defined 

in terms of control points, associated basic functions, weights, and nodes. 

Note: A polynomial uniform b_spline_curve is defined by a list of control points and by the associated basis functions. The node 

values can be derived and the weights are equal. A rational non-uniform b_spline_curve is defined by a list of control points, 

by the associated basis functions, by weights and by multiplicities of nodes. 

Note: A circular arc can be represented by a rational parametric curve. 

The following table shows the attributes of a b_spline_curve: 


name The name specifies the name by which the detailed_geometric_model_element is referred to. 

6.3.8 cartesian_coordinate_space 

A cartesian_coordinate_space is a coordinate space in which geometric and annotation elements may be defined. It is either 

two-dimensional or three-dimensional. An origin for coordinate values is implicitly defined. The units applicable to the coordinate 

values of elements defined in the cartesian_coordinate_space are specified. Each cartesian_coordinate_space is a cartesian_coordinate_space_3d 

or a cartesian_coordinate_space_2d. 




6.3.9 cartesian_coordinate_space_2d 

A cartesian_coordinate_space_2d is a two-dimensional coordinate space. Any two-dimensional geometric and annotation 

element must be defined in a cartesian_coordinate_space_2d. 

A cartesian_coordinate_space_2d is a type of cartesian_coordinate_space. 


6.3.10 cartesian_coordinate_space_3d 

A cartesian_coordinate_space_3d is a three-dimensional coordinate space. Any three-dimensional geometric data must be 

defined in a cartesian_coordinate_space_3d. 

A cartesian_coordinate_space_3d is a type of cartesian_coordinate_space. 


6.3.11 cartesian_point 

A cartesian_point is a point that is defined by its coordinates in a rectangular cartesian coordinate system. 

The following table shows the attributes of a cartesian_point: 


name The name specifies the name by which the detailed_geometric_model_element is referred 

to. 

6.3.12 centre_of_mass 

A centre_of_mass is the centre of the mass of a body. The relative position of the centre_of_mass within the body is an invariant 

datum relative to rotation and translation. The centre_of_mass is a characteristic of an item, not its shape. 

The following table shows the attributes of a centre_of_mass: 


description The description specifies additional information about the property_value. 

6.3.13 circle 

A circle is a planar unbounded curve where all points are equidistant from one point. 

The following table shows the attributes of a circle: 


name The name specifies the name by which the detailed_geometric_model_element is referred 

to. 

64 



6.3.14 classification_association 

A classification_association associates a general_classification with an object. The relation associated_classification specifies the general_classification 

object that provides classification information. The relation classified_element specifies the object that is classified. 

For the attribute role applicable the following values shall be used: 

* 'electromagnetic compatibility': The associated object is the classification that categorizes the classified element in respect of 

its ability to comply with requirements concerning electromagnetic interference; 

* 'environmental conditions': The associated object is the classification that categorizes the classified element with respect to 

its ability to comply with environmental impact requirements. 

The following table shows the requirements of a classification_association: 


role The role specifies the relationship between the general_classification and the associated 

object. 

6.3.15 classification_attribute 

A classification_attribute is a characteristic used to classify an object associated with the corresponding general_classification. 

The following table shows the attributes of a classification_attribute: 


id The id specifies the identifier of the classification_attribute that must be unique within the 

scope of the associated general_classification 

name The name specifies the name by which the classification_attribute is referred to. 

description The description specifies additional information about the classification_attribute. 

6.3.16 collaboration_definition 

A collaboration_definition is a definition of an item_version that is used within the collaboration between the mechanical and 

electrical domain. If a item of the PCB should be used within a collaboration a collaboration_definition should be instantiated 

for the item_version of this item. The relation associated_item_version is used to assign the collaboration_definition to the item. 

A collaboration_definition is a type of design_discipline_item_definition. 

The following table shows the attributes of a collaboration_definition: 



name The name specifies a name of the design_discipline_item_definition. 

description The collaboration_type specifies the kind of collaboration. The collaboration_type could 

be for example "moving of a mounting hole" or "placement under mechanical constraints". 



6.3.17 component_termination_passage 

A component_termination_passage is a type of plated_passage through which a component_terminal may pass 


6.3.18 component_termination_passage_template_interface_terminal 

A component_termination_passage_template_interface_terminal is a type of component_termination_passage_template_terminal, 

an occurrence of which provides an interface capability to the next level of assembly. 


6.3.19 component_termination_passage_template_join_terminal 

A component_termination_passage_template_join_terminal is a type of component_termination_passage_template_terminal, an 

occurrence of which provides a fabrication join capability, within an optionally constrained set of stratum 


6.3.20 component_termination_passage_template_terminal 

A Component_termination_passage_template_terminal is a type of Shape_feature 


6.3.21 composite_curve 

A composite_curve is a curve that is composed of a number of curves which join end to end. 

A composite curve is a type of curve. 

Note: A composite_curve may be closed and self-intersecting. 

The following table shows the attributes of a composite_curve: 



6.3.22 constraint 

A constraint defines constraining information between items or properties of the model. The constraint_type specifies detailed 

information about the constraint. 

The following table shows the attributes of a constraint: 


id The id specifies the identifier of the contraint that must be unique within the collaboration. 

name The name specifies the name by which the constraint is referred to. 

constraint_type The following values are recommended to use for the constraint_type: relating (e.g. to 

move parts together), placement (e.g. for clearance), or rotation (for rotation of elements). 

66 



6.3.23 curve 

A curve is a path of a point moving in a coordinate space. A curve is an abstract data model element. 

A curve is a type of detailed_geometric_model_element. 

The following table shows the attributes of a curve: 



6.3.24 curve_on_surface 

A curve_on_surface is a curve that lies on a parametric surface. This includes the cases of a 3D curve representation together 

with the basis surface, a 2D curve representation within the parameter space of the surface, and a combination of both. 

A curve_on_surface is a type of curve. 

The following table shows the attributes of a curve_on_surface: 



6.3.25 curve_set_2d 

A curve_set_2d is a collection of a two-dimensional curve or point objects that establish a wireframe_model_2d. 


6.3.26 cutout 

A cutout is a closed, internal shape in a substrate. A cutout may not extend completely through the substrate. The cutout is represented 

by a closed curve in two dimensional representations and by a manifold surface in three dimensional representations. A 

Cutout is a type of Inter_stratum_feature. 


6.3.27 Cutout_edge_segment 

A cutout_edge_segment defines an edge segment of a cutout. When the cutout_edge_segment participates in a cutout that is 

fully described by a collection of cutout_edge_segment, the end_vertex of the final segment shall be the start_vertex of the first 

segment. Pre-processors shall adhere to the requirement that the boundary this segment is contributing to shall be closed. A 

cutout_edge_segment is a type of inter_stratum_feature. 




6.3.28 data_environment 

A data_environment is the specification of the conditions under which a material_property_value_representation is valid. 

Note: A data_environment may have the name"'standard" and the description "20 degrees Celsius, 75% humidity". 

The following table shows the attributes of a data_environment: 


description The description specifies additional information about the data_environment. 

environment_name The environment_name specifies the name by which the data_environment is referred to. 

6.3.29 definition_based_product_occurrence 

A product_occurrence is the identification of an occurrence of an object in a product structure. It also specifies the design view 

of this occurrence. 

This object type has no attributes 

6.3.30 design_discipline_item_definition 

A design_discipline_item_definition is a view of an item_version. This view is relevant for the requirements of one or more life 

cycle stages and application domains and collects product data of the item_version. If the item_version is used within a collaboration 

session the suptype collaboration_definition should be instantiated. If the item_version represents an assembly of items 

the suptype assembly_definition should be instantiated. Each design_discipline_item_definition may be any combination of 

assembly_definition and collaboration_definition. 

The associated_item_version specifies the item_version for which the design_discipline_item_definition is a view. 

The following table shows the attributes of a design_discipline_item_definition: 



name The name specifies a name of the design_discipline_item_definition. 

6.3.31 design_layer_stratum 

A design_layer_stratum is a type of stratum for the purpose of realizing a physical network in one material. 


6.3.32 design_layer_technology 

A design_layer_technology is a type of stratum_technology. The design_layer_technology is a technology specification tailored 

for those materials intended to be used to implement the direct connectivity as described in a design. 


68 



6.3.33 detailed_geometric_model_element 

A detailed_geometric_model_element is the identification of a geometric element. 

Note: The detailed_geometric_model_element may be used to define the elements of a geometric_model. 

The following table shows the attributes of a detailed_geometric_model_element: 



6.3.34 digital_file 

A digital_file contains computer interpretable data stored in a physical file within the filesystem. 


6.3.35 documentation_layer_stratum 

A documentation_layer_stratum is a type of stratum used to describe patterns and other artwork information needed to manufacture 

a stratum from materials which are not independently implementing a generic_physical_network in the printed circuit 


6.3.36 documentation_layer_technology 

A documentation_layer_technology is a type of stratum_technology that may have patterns applied and whose purpose is not 

for directly implementing point to point connectivity as in the design_layer_technology. 


6.3.37 ellipse 

An ellipse is a conic section defined by the lengths of the semi-major and semi-minor diameters and by the position (center or 

mid-point of the line joining the foci) and orientation of the curve. 

An ellipse is a type of curve. 

The following table shows the attributes of an ellipse: 





6.3.38 external_geometric_model 

An external_geometric_model is the identification of a model that contains geometry in a 3D context only. 

An external_geometric_model is a type of external_model. Each external_geometric_model may be an 

external_geometric_model_with_parameters. 

The following table shows the attributes of an external_geometric_model: 


model_id The model_id specifies the identifier of the external_model. 

description The description specifies additional information about the external_model. 

6.3.39 external_geometric_model_with_parameters 

An external_geometric_model_with_parameters is the identification of a model that contains geometry in a 3D context, and 

where some characteristics of the model may be controlled or changed in a predefined way in each occurrence of the model. 

Note: A geometric model may have predefined aspect ratios of its overall dimensions, but a parameterized volume. In each 

occurrence of the external_geometric_model_with_parameters, the volume may be specified by the user and the dimensions of 

the model are set automatically while the predefined aspect ratio requirements are met. 

An external_geometric_model_with_parameters is a type of external_geometric_model. The association parameter_value specifies 

the general_parameter objects that may be varied in each occurrence. 

The following table shows the attributes of an external_geometric_model_with_parameters: 



description The description specifies additional information about the 

external_geometric_model_with_parameters. 

6.3.40 external_model 

An external_model is the identification of a model that is described in a digital_file and by the cartesian_coordinate_space that 

is needed to further process the externally described information. In the collaboration context each external_model is an 

external_geometric_model. 

The following table shows the attributes of an external_model: 



description The description specifies additional information about the external_model. 

70 



6.3.41 feature_parameter 

A feature_parameter is the representation of a characteristic of a feature_definition. In the ECAD/MCAD collaboration model the 

feature_parameter is used to define parameters of an external_geometric_model_with_parameters. The association parameter_value 

specifies the value of the feature_parameter. This includes information about units and possibly about limitations. 

The following table shows the attributes of a feature_parameter: 


parameter_name The parameter_name specifies the character, abbreviation, or word by which the 

feature_parameter is referred to. Note "a", "b1", or "r" are typical examples for the 

parameter_name. 

6.3.42 filled_via 

A filled_via is a type of via. 


6.3.43 general_classification 

A general_classification is a classification of an object which characterizes all objects of the same kind; such a classification is 

independent from the application of the classified object. 

Note: A resistor with subclasses, such as resistors with long or short connections, a bracket with subclasses, e.g., with 90 or 

100 degrees bending angle, or screws with subclasses such as metal screws or machine screws are examples for 

general_classification. 

The following table shows the attributes of a general_classification: 


id The id specifies the identifier of the general_classification. 

description The description specifies additional information about the general_classification. 

version_id The version_id specifies the identification of a particular version of the general_classification. 

6.3.44 general_parameter 

A general_parameter is the association of an external_geometric_model_with parameters and a feature_parameter. The association 

parameter_value specifies the feature_parameter that has the value and possibly a name of the general_parameter. 

The following table shows the attributes of a general_parameter: 


parameter_role The parameter_role specifies the kind of parameter that is represented by the general_parameter. 

Note "width" or "diameter" are examples for the parameter_role. 



6.3.45 general_property 

A general_property is the definition of a property that is specified by the attribute "property_type". 

Note: The noise emission of a fan on the PCB, maintenance intervals, and duration of parts, or electrical properties are examples 

for a general_property. 

A general_property is a type of property. 

The following table shows the attributes of a general_property: 


description The description specifies additional information about the property. 

id The id specifies the identifier of the property. 

version_id The version_id specifies the identification of a particular version of a property. 

property_type The property_type specifies the kind of property the general_property defines. 

6.3.46 general_shape_dependent_property 

A general_shape_dependent_property is a user-defined characteristic of an object. The 'property_value' specified by a 

general_shape_dependent_property is derived from geometry. 

Note: The general_shape_dependent_property may be used for the purpose of validation of geometric models. 

Note: If a geometry model is exchanged between two partners, the calculation of various properties of the bodies, such as centre 

of mass, overall surface, or overall volume, is performed by originator and recipient. When comparing these set of values, the 

existence of deficiencies in the received model can be easily detected. 

A general_shape_dependent_property is a type of shape_dependent_property. 

The following table shows the attributes of a general_shape_dependent_property: 


description The description specifies additional information about the property_value of the 

shape_dependent_property. 

property_type The property_type defines the type of characteristic that is specified for an object. 

property_value The property_value specifies the value that is given for a particular characteristic. 

6.3.47 geometric_model 

A geometric_model is a representation of geometry. In the ECAD/MCAD collaboration three different models must be used: 

wireframe_model_2d: Is used to represent 2D information, e.g. board outline. 

b_rep_model: Is used to represent 3D geometry with a boundary representation, e.g. 3D shape of a component (this model 

will be described in further versions of the recommendation) 

72 



hybrid_model: Is used to represent 3D geometry with history information, e.g. 3D shape of a component with feature structure 

of the 3D-CAD system (this model will be described in further versions of the recommendation) 


6.3.48 geometric_model_relationship_with_transformation 

A geometric_model_relationship_with_transformation is a relationship between two model objects with the additional information 

about a geometric transformation. This transformation defines the location and orientation of the related model relative to the 

relating model. The association model_placement specifies the geometric transformation that places and orients the related 

model relative to the relating model. 


6.3.49 hybrid_geometric_model_3D 

A hybrid_geometric_model_3d is a representation of geometry that consists of a set of detailed_geometric_model_element 

objects. 

The details of a hybrid_geometric_model_3d will be described in further versions of the recommendation 


6.3.50 hyperbola 

A hyperbola is one branch of an open conic section defined by its radius, imaginary radius, the centre point and the direction 

of the line joining the centre to the focus. 

A hyperbola is a type of curve. 

The following table shows the attributes of a hyperbola: 



6.3.51 instance_placement 

An instance_placement is the information pertaining to the placement of a single_instance, which is defined in the cartesian 

coordinate space of the product used within the collaboration. 

Note: An instance_placement is used to define the position of each occurence of e.g. a resistor component of the PCB. For 

each resistor an individual instance_placement has to be defined. 


6.3.52 inter_stratum_feature 

An inter_stratum_feature is a type of laminate_component. An inter_stratum_feature spans one or more stratum. 

The association inter_stratum_feature_stratum specifies stratum(s) which are related to the inter_stratum_feature. 

NOTE An inter_stratum_feature may be realized by removal of material by drilling, routing, punching, chemically etching, laser 

burning, or otherwise penetrating one or more sequential stratum; by the addition of material; or by combining both removal 

and addition of material in the fabrication process. 



The following table shows the attributes of a inter_stratum_feature: 


feature of size specifies whether or not the inter_stratum_feature interfaces with a feature of another 

product in an assembly context. A value of TRUE specifies that it interfaces. A value of 

FALSE specifies that it does not interface. 

vertical_extent 

6.3.53 interconnect_module_constraint_region 

An interconnect_module_constraint_region is a region within an interconnect_module in which a placement constraint 

on some category of design object is to be met by the design. An interconnect_module_constraint_region may overlap other 

interconnect_module_constraint_regions. 

The following table shows the attributes of an item: 


keepout specifies if the meaning of the interconnect_module_constraint_region is to describe 

that items shall be in the interior of the element_shape or shall be on the exterior of 

the element_shape. 

The value of TRUE states that objects in the constrained_design_object_category are 

not to be within the element_shape. The value of FALSE states that objects in the 

constrained_design_object_category are to be only within the element_shape 

constrained_design_object_category specifies object categories for the interconnect_module_constraint_region. 

The names shall be interpreted as the identification of Application Object categories 

to be constrained. 

6.3.54 item 

An item is a representation for any object used within the ECAD/MCAD collaboration. It collects the information that is 

common to all versions of the object. An item could be classified or grouped using the general_classification or the 

specific_item_classification objects within the data model. If the item is used in a collaboration session the collaboration_definition 

object should instantiated in order to detail the collaboration information of the item. Additionally, if an assembly_definition exists 

for at least one version of the item, the item must be classified as being an "assembly" using specific_item_classification. 

Note: An item may be either a single piece part or an assembly. 

Example: In the context of ECAD/MCAD collaboration an item may be the mechatronic product as a whole, the assembly of the 

PCB, the shape of the board outline or electrical/mechanical components such as resistors, capacitors, LED displays, plugs etc. 



id The id specifies the identifier of the item. For the id, an owner must be specified by a 

person_organization_assignment with role "id owner". The id must be unique within 

the scope of the organization that is specified by the person_organization_assignment 

name The name specifies the name of the item. 

description The description specifies additional information about the item. 

74 



6.3.55 item_contraint 

An item_constraint is used to constrain the relation between two or more items. The type of item_contraint needs to be specified 

with the constraint_type attribute. 

An item_constraint is a type of constraint. 





constraint_type The following values are recommended to use for the constraint_type: relating (e.g. to 

move parts together), placement (e.g. for clearance), or rotation (for rotation of elements). 

6.3.56 item_definition_instance_relationship 

An item_definition_instance_relationship is a relationship between a design_discipline_item_definition and an item_instance. Within a 

collaboration session the item_definition_instance_relationship is used to represent the assembly information of the product structure. 

Therefore the subtype assembly_component_relationship should be used. The association related specifies the item_instance that is part of 

the item_definition_instance_relationship. The association relating specifies the design_discipline_item_definition that is part of the assembly. 


6.3.57 item_instance 

An item_instance is the occurrence of an object in a product structure, e.g. a resistor is defined once within a PCB. Its 

design_discipline_item_definition carries all the information necessary to define the resistor (e.g., its shape and properties) 

in depedent of its usage. Additionally, there are five item_instance objects for this resistor since there are five equal resistors used 

in the PCB. Each of these instances may carry additional information such as placement or properties. 

The following table shows the attributes of an item_instance: 


description The description specifies additional information about the item_instance. 

id The id specifies the identifier of the item_instance. 

6.3.58 item_property_association 

An item_property_association is a mechanism to associate a property value with an object. 


6.3.59 item_shape 

An item_shape is the definition of the shape of a design_discipline_item_definition or an item_instance. 

The following table shows the attributes of an item_shape: 


described_object The described_object specifies the object whose shape the item_shape defines. 



6.3.60 item_version 

An item_version is a version of an item and serves as the collector of the data characterizing a physically realizable object in 

various application contexts. An item_version may be produced, consumed, used to produce other item_version objects, or 

offered to the market. The set of item_version objects of an item represents the history of the item within a particular life cycle 

stage or over its complete life cycle. The item_version_relationship is used to define the relationship between two different 

item_versions. Within the collaboration session an item_version is used to define different versions of collaboration objects. 

The following table shows the attributes of an item_version: 


id The id specifies the identifier of the item_version. The id must be unique within the scope 

of the associated item. A particular object is identified by the id of the item_version. 

description The description specifies additional information about the item_version. 

6.3.61 laminate_component 

A laminate_component is a type of assembly_component. All laminate_component types are realized as part of the manufacturing 

process that produces the interconnect. 


6.3.62 line 

A line is an unbounded curve that is defined by a point and a vector. The positive direction of the line is in the direction of the 

vector and the magnitude of the vector controls the parametrization. 

A line is a type of curve. 

The following table shows the attributes of a line: 



6.3.63 material 

A material is the substance out of which an item is or can be made.The association described_element specifies the objects the 

material information is provided for. 

The following table shows the attributes of a line: 


material_name The material_name specifies the name by which the material is referred to. 

76 



6.3.64 material_property 

A material_property is a characteristic that depends on material aspects. A material_property is a type of property. 

The following table shows the attributes of a material_property: 





property_name The property_name specifies the kind of material_property. Note: 'EM1' is an example for 

a "property_name" that may be associated with a material_property that is described as 

'elastic modulus'. 

6.3.65 material_property_association 

A material_property_association is an object that associates a material object with a material_property_value_representation 

object. 


6.3.66 material_property_value_representation 

A material_property_value_representation is the representation of a characteristic of a material. 

The association definition specifies the material_property that defines the material_property_value_representation. 

The association environment_condition specifies the environmental conditions in which the defined material_property_value_ 

representation is applicable. 


6.3.67 moments_of_inertia 

A moments_of_inertia describes the matrix of inertia of a rigid body. The moments of inertia I are described with the 9 inertia 

coefficients. 

A moments_of_inertia is a type of property_value. 

The following table shows the attributes of a moments_of_inertia: 


description The description specifies additional information about the property_value. 



6.3.68 next_higher_assembly 

A next_higher_assembly is a relationship where the association "related" specifies a constituent of an assembly and the association 

"relating" specifies the immediate parent assembly of the constituent. 

Note: A constituent may be a single part or an assembly. 

A next_higher_assembly is a type of assembly_component_relationship. 


A Non_feature_shape_element is a type of Shape_element that is not on the physical boundary of a Part_view_definition. 


6.3.69 numerical_value 

A numerical_value is a quantity expressed with a numerical value and a unit. 

A numerical_value is a type of value_with_unit. 

The following table shows the attributes of a numerical_value: 


value_name The value_name specifies the name by which the property_value is referred to. 

Note: "l1" or "vol2" are examples for the value_name of a Property_value. 

value_component The value_component specifies the quantity of the numerical_value. 

6.3.70 offset_curve 

An offset_curve is a curve in 2D or 3D space that is defined as a set of points for which there is at least one point on the basis 

curve that is at the offset distance of the considered point. At a given point of the basis curve, the distance is measured along 

a vector that is the normalized cross product of the tangent of the basis curve at this point, and of a reference direction vector. 

Note: The reference direction of the offset must be defined. An offset_curve must not self-intersect and may reference any type 

of curve except another offset_curve. 

An offset_curve is a type of curve. 

The following table shows the attributes of an offset_curve: 


Name The name specifies the name by which the detailed_geometric_model_element is referred to. 

6.3.71 organization 

An organization is a group of people involved in a particular business process. 

The following table shows the attributes of an organization: 


organization_name The organization_name specifies the name used to refer to the organization. 

Id The id specifies the identifier of the organization. 

78 



6.3.72 parabola 

A parabola is an open conic curve defined by its focal length, apex and the direction of the line joining the apex and focus. 

A parabola is a type of curve. 

The following table shows the attributes of a parabola: 


Name The name specifies the name by which the detailed_geometric_model_element is referred to. 

6.3.73 part_feature 

A part_feature is a type of shape_feature. 

The following table shows the attributes of a parabola: 


material_state_change specifies whether the material state change for the part_feature is due to addition of 

material or due to removal of material. 

6.3.74 part_mounting_feature 

A part_mounting_feature is a type of part_feature that is identified to facilitate tolerance specification when an occurrence of the 

associated part is used in an assembly. 


6.3.75 partially_plated_cutout 

A partially_plated_cutout is a type of cutout that is not a completely plated cutout for reason of manufacturing capabilities or 

design purposes. 


6.3.76 person 

A person within the collaboration is an individual human being who has some relationship to product data used within the 

collaboration. The person must always be identified in the context of one or more organizations. 

The following table shows the attributes of a person: 


person_name The person_name specifies the name used to refer to the Person. Note: The person_name 

includes the first, middle, and last names as well as titles, if applicable. 



6.3.77 person_in_organization 

A person_in_organization is the specification of a person in the context of an organization. The association associated_organization 

specifies the organization with which the person is associated. The association associated_person specifies the person. 

The following table shows the attributes of a person_in_organization: 


role The role specifies the relationship between the person and the organization. 

location The location specifies the relevant address of the person_in_organization. 

id The id specifies an identifier of the person. The identifier must be unique within the scope 

of the "associated_organization". Note: The id may be a staff number or a user id 

in a computer system. 

6.3.78 person_organization_assignment 

A person_organization_assignment is an object that associates an organization or a person_in_organization with the product 

data used in the collaboration. The role attribut of the person_organization_assignment must be used in a MCAD/ECAD collaboration 

with the following values: 

Project manager: A project manager is responsible for the overall project, defines the mechanical and electrical product 

structure, requirements, and tasks. The project manager controls the results. 

Mechanical designer: A mechanical designer designs the surrounding geometry in the mechanical 3D CAD system. A mechanical 

designer fulfills the requirements of the project manager and defines the requirements for the PCB development based on 

mechanical constraints. 

Mechanical digital mock-up: A person doing a digital-mock-up (DMU) performs 3D-interference checks in a mechanical 3D CAD 

system. This person checks whether the current design fits with the surrounding geometry. Within the DMU the 3D representa - 

tion of the mechanical and electrical design is used. 

Electrical designer: An electrical designer designs the schematics of the PCB. His output is the netlist as an input for the layout of the 

PCB, which is done by the ECAD layouter. The electrical designer fulfills the requirements of the project manager and MCAD designers. 

Electrical layouter: An electrical layouter designs the layout of the PCB in the ECAD system. The electrical layouter fulfills the 

requirements of the project manager, ECAD designers and MCAD designers. 

Thermal: The role thermal is used for a person who performs thermal analysis based on the PCB-Layout. This person checks 

whether heating, cooling, security and other thermal requirements are fulfilled by the current PCB design. 

EMI/EMC: The role EMI/EMC is used for a person who analyzes whether the current PCB design fulfills the requirements 

concerning the electromagnetic compatibility (EMC), which require that the system is able to tolerate a specified degree 

of electromagnetic interference (EMI) and does not generate more than a specified amount of interference. 

The following table shows the attributes of a person_organization_assignment: 


role The role specifies the responsibility of the assigned Person or organization with respect 

to the object that it is applied to. 

80 



6.3.79 physical_connectivity_interrupting_cutout 

A physical_connectivity_interrupting_cutout is a type of cutout that is included in the design of an interconnect_module for the 

purpose of interrupting one or more connectivity elements in an interconnect_module. 


6.3.80 plated_cutout 

A plated_cutout is an interior volume of the substrate, such as a void included for passage of a shaft, and may be plated for 

EMI shielding purposes. This object conveys the semantic that the interior referenced by the related shape is conductive. A 

plated_cutout is a type of plated_inter_stratum_feature and a type of cutout. 


6.3.81 plated_cutout_edge_segment 

The Plated_cutout_edge_segment is a feature with a specified shape that makes up part of the edge of a partially plated cutout. 

A plated_cutout_edge_segment is a type of plated_inter_stratum_feature and is a type of cutout_edge_segment. 


6.3.82 plated_inter_stratum_feature 

A plated_inter_stratum_feature is a inter_stratum_feature with deposited metal on its walls that makes an electrical connection 

between conductive patterns on internal design_layer_stratum, external design_layer_stratum, or both, of a printed circuit 

board. A plated_inter_stratum_feature is a type of inter_stratum_feature. 


6.3.83 plated_passage 

A plated_passage is a type of plated_inter_stratum_feature. A plated_passage may be either a component_termination_passage 

or a via. 


6.3.84 point 

A point is a location in a Cartesian coordinate space. 

A point is an abstract data model element. 

The following table shows the attributes of a point: 



6.3.85 point_on_curve 

A point_on_curve is a point that is defined by evaluating a given curve at a specified parameter value. 

Note: A point_on_curve implicitly represents the topological relation between a point and a curve. 

A point_on_curve is a type of point. 



The following table shows the attributes of a point_on_curve: 



6.3.86 point_on_surface 

A point_on_surface is a point that is defined in the domain of a surface. Its actual location in 3D geometric space is obtained 

by evaluating the parametric equation of the surface with a particular pair of parameter values. 

Note: The object implicitly represents the topological relation between a point and a surface. 

A point_on_surface is a type of point. 

The following table shows the attributes of a point_on_surface: 



6.3.87 polyline 

A polyline is a curve that is represented by n-1 linear segments, defined by a list of n points. A polyline may be closed and may 

self-intersect. 

A polyline is a type of curve. 

The following table shows the attributes of a polyline: 



6.3.88 printed_part_template_terminal 

A printed_part_template_terminal is a terminal of a printed_part_template. A Printed_part_template_terminal is a type of 

Shape_feature. 


6.3.89 printed_part_cross_section_template_terminal 

A pPrinted_part_cross_section_template_terminal is a type of printed_part_template_terminal that is the terminal of the 

printed_part_cross_section_template. 


6.3.90 printed_part_template_interface_terminal 

A printed_part_template_interface_terminal is a type of printed_part_template_terminal, an occurrence of which is an external 

access to the printed circuit board of which it is a component. 


82 



6.3.91 printed_part_template_join_terminal 

A printed_part_template_join_terminal is a type of printed_part_template_terminal an occurrence of which provides access to 

the functionality of the printed_part_template from within a printed circuit board. 


6.3.92 printed_part_template_terminal 

A printed_part_template_terminal is a terminal of a printed_part_template. A Printed_part_template_terminal is a type of 

Shape_feature. 


6.3.93 property 

A property is the definition of a particular quality. Within the collaboration each property is defined as a material_property or 

a general_property. 

Note: A property may reflect physics or arbitrary user defined measurements. 

The following table shows the attributes of a property: 





6.3.94 property_value 

A property_value is the numerical or textual value of a property_value_representation. Each property_value is a value_list, a 

string_value, or a value_with_unit. 

The following table shows the attributes of a property_value: 



Note: "l1" or "vol2" are examples for the value_name of a property_value. 

6.3.95 property_value_association 

A property_value_association is a mechanism to assign a property_value_representation to an object. 


6.3.96 property_value_representation 

A property_value_representation is the representation of property. 

The association definition specifies the property that the property_value_representation characterizes. 

The association specified_value specifies the property_value that qualifies the property_value_representation by a value_with_unit. 

For the value_determination the following values must be used: 



calculated: The value has been calculated; 

designed: The value represents a value intended by the design; 

estimated: The value has been estimated; 

measured: The value has been measured; 

required: The value represents a requirement; 

set point: The value is used as the initialization value. 

The following table shows the attributes of a property_value_representation: 


value_determination The value_determination specifies information on how the property_value_representation 

must be interpreted. 

6.3.97 property_constraint 

A property_constraint defines constraints between two or more properties. 

An property_constraint is used to constrain the relation between two or more properties. The type of property_constraint needs 

to be specified with the constraint_type attribute. 

A property_constraint is a type of constraint. 

The following table shows the attributes of a property_constraint: 




constraint_type The constraint_type specifies the dependencies between the constrained properties, e.g. 

"identical values", "derived" are are examples for the constraint_type of a property_constraint. 

6.3.98 shape_dependent_property 

A shape_dependent_property is a characteristic of the shape, or of a portion of the shape of an object. This object is either an 

item, an occurrence of an item in the product structure or the physical realization of an item. 

Note: A shape_dependent_property is independent of the representations of the shape. 

Each shape_dependent_property is a centre_of_mass, a moments_of_inertia, or a general_shape_dependent_property. 

The following table shows the attributes of a shape_dependent_property: 


description The description specifies additional information about the shape_dependent_property. 

6.3.99 shape_description 

A shape_description is either a geometric_model or a external_geometric_model. 


84 



6.3.100 shape_element 

A shape_element is a portion of shape that has to be identified explicitly to be associated with other information. 


6.3.101 shape_feature 

A shape_feature is a type of shape_element. 


6.3.102 single_instance 

A single_instance is one particular occurrence of an object that is defined as a design_discipline_item_definition. A single_instance 

may or may not be associated with placement information using an instance_placement. 

Note: In a PCB, a capacitor is used as a single_instance and its position is specified by a geometric transformation. 

A single_instance is a type of item_instance. 

The following table shows the attributes of an single_instance: 


description The description specifies additional information about the item_instance.. 

id The id specifies the identifier of the item_instance. 

6.3.103 stratum 

A stratum consists of a single material within an interconnect substrate. The vertical contours of either boundary surface may 

vary. Thus, the thickness of the stratum may vary throughout its range. The material used may be specific, such as 24K gold, or 

more general, such as etched copper. 

A stratum is a type of item_shape. The association Stratum_Stratum_technology qualifies the stratum_technology of this stratum. 



id the identifier that distinguishes the stratum 

of_technology specifies a role of the stratum_technology for the stratum 

stratum_surface_designation Kind of designation of the stratum, either average or primary or secondary 

6.3.104 stratum_feature_template_component 

A stratum_feature_template_component is a type of inter_stratum_feature. 




6.3.105 stratum_technology 

stratum_technology is a means to provide material properties, parametric data associated with the technology, and material 

identification. A stratum_technology maybe either a design_layer_technology or a documentation_layer_technology. 



name the words by which the stratum_technology is known. Specifies the alphanumeric 

identifier of a stratum_technology 

layer_position specifies one of the layer_position_types of the stratum for the stratum_technology. Primary 

and secondary shall only be used if the member of stratum_technology is a 

design_layer_technology 

ID unique identifier 

6.3.106 structured_printed_part_template_terminal 

A structured_printed_part_template_terminal is a terminal of a structured_printed_part_template. A Printed_part_template_terminal 

is a type of Shape_feature. 


6.3.107 thermal_component 

A thermal_component is a type of assembly_component that is included in the design in order to satisfy a heat flow requirement. 


6.3.108 transformation 

A transformation is a geometric transformation composed of translation and rotation. Scaling is not included. Each transformation 

is a transformation_3d or a transformation_2d 


6.3.109 transformation_2d 

A transformation_2d is the definition of a geometric transformation in 2D space. 

A transformation_2d is a type of transformation. 


6.3.110 transformation_3d 

A transformation_3d is the definition of a geometric transformation in 3D space. 

A transformation_3d is a type of transformation. 


6.3.111 trimmed_curve 

A trimmed_curve is a curve of finite length that is the result of trimming a curve between two points. The trimming points are the 

start and end points of the trimmed_curve. These points may be specified by cartesian points or by parameter values. 

86 



A trimmed_curve is a type of curve. 

The following table shows the attributes of a shape trimmed_curve: 



6.3.112 unit 

A unit is a quantity defined as a standard in terms of which other quantities may be expressed. The types of units should use SI 

unit standard in order to ensure a consistent interpretation of units within a collaboration. 

Within a collaboration, it should be possible to use different unit systems. Each system must be able to convert a foreign unit 

based on the standard SI unit system. 

The following table shows the attributes of a shape unit: 


unit_name The unit_name specifies the term representing the kind of unit. Note "gram", "litre", or 

"volt" are examples for the unit_name. 

6.3.113 unsupported_passage 

An unsupported_passage has no metallization in the realization of its walls. An unsupported_passage is a type of Inter_stratum_feature. 


6.3.114 value_limit 

A value_limit is a qualified numerical value representing either the lower limit or the upper limit of a particular physical characteristic. 

Note: "30.5 maximum" and "5 minimum" are examples for a value_limit. 

A value_limit is a type of value_with_unit. 

The following table shows the attributes of a value_limit: 



limit The limit specifies the value of the limit. 

limit_qualifier The limit_qualifier specifies the kind of limit. The following values must be used: "maximum": 

The specified limit is an upper limit;"minimum"': The specified limit is a lower limit. 



6.3.115 value_range 

A value_range is a pair of numerical values representing the range in which the value must lie. 

A value_range is a type of value_with_unit. 

The following table shows the attributes of a value_range: 


value_name The value_name specifies the name by which the Property_value is referred to. 

upper_limit The upper_limit specifies the maximum acceptable value that is constrained by the 

value_range. 

lower_limit The lower_limit specifies the minimum acceptable value that is constrained by the 

value_range. 

6.3.116 value_with_unit 

A value_with_unit is either a single numerical measure, or a range of numerical measures with upper, lower, or upper and 

lower bounds. 

A value_with_unit is a type of property_value. Each value_with_unit is a value_range, a numerical_value, or a value_limit. 

The following table shows the attributes of a value_with_unit: 


value_name The value_name specifies the name by which the Property_value is referred to. 

6.3.117 via 

A via is a type of plated_passage. Via is defined in IEC 60050-541. 


6.3.118 wireframe_model_2d 

A wireframe_model_2d is a collection of curve_set_2d objects, i.e., curve and point objects defined in two-dimensional space. 


88 



6.4 Implementation steps and functional scope 

The following in Figure 38 depicted three functional scopes have been defined to support the different steps: 

Figure 38: Implementation steps 

Step 1: Basic component-related collaboration = Package 1,2,3,6 

Step 1 allows ECAD/MCAD collaboration based on components, component properties and the geometric position of components. 

Example: The question of whether the position of an electrical component can be changed is to be clarified within a collaboration. 

Step 2: Advanced shape-related collaboration = Step 1 + Package 4, 7, 8, 9 

In addition to the functionality provided in step 1, step 2 allows collaboration based on geometry-dependent information. This 

means that simple geometric models need to be supported within the collaboration. 

Example: The new geometry of the PCB is to be harmonized within a collaboration. To do this, the board outline must be 

transferred between the collaborating systems. 

Step 3: Constraint-based ECAD/MCAD collaboration = Step 2 + Package 5 

An implementation in step 3 can also handle constraints within the collaboration. These constraints can be defined in both the 

ECAD and the MCAD environments. 

Example: Within a collaboration, an ECAD engineer specifies that three electrical components can only be moved together (due 

to electrical constraints). This constraint can then be transferred to the MCAD system within the framework of the collaboration 

so that any repositioning in the MCAD system will also involve all three components. 



6.5 Mapping logic 

6.5.1 Package 1: item definition and product structure 

The mapping in Package 1 is shown in Figure 39 below. 

Figure 39: Mapping in Package 1 

The mapping between the application-driven data model and the implementation-driven data model (EDMDSchema) is characterized 

in Package 1 by a high level of grouping of object structures and the relationships between objects. 

The reason behind the groupings of objects in EDMDSchema is the fact that only the collaboration view is available in EDMDSchema 

and, in this view, it is the assembly component relationships and the information on the position of the items which are of 

interest. However, the strict separation between the actual definition of an object (item) and the various instances of this object 

(item_instance) remains important. Since only one specific version can be viewed within the collaboration, additional version 

control mechanisms (item_version) are not required. 

For these reasons, the information about the item and the item_version is grouped together and mapped by the object EDMDItem. 

The instantiation of the EDMDItem object thus always contains the use of exactly one version of the object within the collaboration. 

The assembly placement and view information are mapped by the object EDMDItemInstance. The assembly placement 

(next_higher_assembly) in the EDMDSchema is realized by a relation between the EDMDItem and EDMDItemInstance object. 

Information on the position (transformation) is mapped within the assembly using EDMDTransformation and assigned directly to 

EDMDItemInstance. No explicit distinction is made between 2D and 3D transformation. EDMDTransformation is able to map 

both sets of information. 

90 



6.5.2 Package 2: item classification and grouping 


Figure 40: Mapping classification and grouping mechanisms 

EDMDSchema offers only one grouping mechanism, EDMDGroup. The classification mechanism EDMDGeneralClassification 

is derived from EDMDGroup. 



6.5.3 Package 3: person and organization information 


Figure 41: Mapping the organizational units and roles 

All the important object types for mapping the organizational units and roles were modeled in EDMDSchema. To facilitate 

processing, EDMDRoleOnItem and EDMDRoleInOrganisation were derived from EDMDRole. EDMDRole represents a general 

concept for mapping roles in the given context. EDMDRoleOnItem was extended in such a way that the context can also be an 

ItemInstance. 

6.5.4 Package 4: ECAD shape information 


Figure 42: Mapping the shape information 

92 



The shape information is always mapped using the same pattern. Because the MCAD system in particular is not able to interpret 

most of the information relating to the functions of a shape in the context of an electrical circuit, only the most important super 

types were modeled as real types. However, these types each contain a type that maps the original function of the shape. 

6.5.5 Package 5: constraint definition 


Figure 43: Mapping the constraints 

In EDMDSchema, the constraints are mapped using two different mechanisms. In the user-driven data model a general type of 

dependency is defined and then specialized, in the EDMDSchema, property definitions can already include limitations. These 

limitations are included directly in the property, which allows for easier processing. Dependencies between EDMDItems and 

EDMDItemInstances can be described using EDMDItemConstraint, a subtype of EDMDGroup. 



6.5.6 Package 6: property and material definition 



Mapping between the application-driven data model and the implementation-driven data model is characterized in Package 6 

by the consistent use of an object structure and inheritance in EDMDSchema. This means that only a small number of classes 

are needed in EDMDSchema to map the requirements planned for the application-driven data model. 

Therefore, the basic object for mapping properties (property) and assigning properties to an item (property_value_representation) 

are mapped by EDMDUserProperty. 

As a subclass of EDMDUserProperty, EDMDUserSimpleProperty also offers the option of mapping simple value/unit combinations 

and thus corresponds to the familiar value_with_unit concept. Limiting the value properties using the value_limit and value_range 

objects can also be done in EDMDSchema using an EDMDConstrainedProperty. 

In addition, the general_property in the application-driven data model satisfies the users’ desire to define any property and assign 

it to the item. The counterpart in EDMDSchema is the EDMDUserAnyProperty, which also allows any property to be assigned 

to the EDMDItem. Unlike the application-driven data model, these arbitrary properties can also be mapped using any XML 

representation. Therefore, EDMDUserAnyProperty can also be used to map the material_property and is thus significantly more 

powerful than the corresponding elements in the application-driven data model. 

94 






Mapping between the application-driven data model and the implementation-driven data model is done in Package 7 by defining 

a similar object model including curve set, curve and point and defining corresponding sub type for the elements defined 

in user driven data model. Since there is a definition for an upper bound and a lower bound at the EDMDCurveSet2d it is feasible 

to describe 3d shapes using this object type. 



6.5.8 Package 8: shape dependant information 



In Package 8 the mapping between user driven data model and implementation driven data model is done by defining a similar 

structure including item, item shape, shape element and shape description. Since there are global mechanisms to describe 

annotations and user defined properties (EDMDAnnotation and EDMDUserProperty) there are no special types for defining those 

at item shape. To describe a shape in EDMDScheme there are also two main function internal representations and external 

representations. Since the definition of external files is made by unified resource iterators the external representation of shapes 

can be done by one entity type (EDMDExternalGeometricModel). 


Since there are only two mechanisms for describing item shape in EDMDSchema a special mapping of this package is not 

needed. 

6.6 Implementation-driven data model (EDMDSchema) 

The actual interconnection of CAD systems is performed using a protocol which is based on the implementation-driven data model. 

This model was created as an XML schema and is shipped as an extra zip archive, which is also part of the recommendation 

but not part of this printable piece of the recommendation (see. 6.6.6). 

The basic concepts on which the data model is based are described below. 

96 



6.6.1 Concept of the “item” 

The item is the basic element for describing the product, see Figure 47: 

Figure 47: Item model 

The “item” is the basic element used to create the structure of the product description (product structure and geometry) relevant 

to the collaboration. Unlike STEP AP214, for example, the item not only represents a completed part (e.g. assembly or part) but 

can also be a single geometric element. This means that, for example, individual components (e.g. a PCB) can be represented 

as “assemblies” comprising individual elements (e.g. PCB comprising the “items”: board, mounting holes and several cutouts). 

An item always represents only one version of an object, version chains or sequences of changes on one and the same part 

can be represented implicitly by using the same number and version designator. Within the protocol, this correlation is represented 

by specifying the predecessor of an item. 

The item is the only object including an Identifier, for that it is the only object collaboration is available on, so by providing an 

item for some elements, IT systems show they are ready to collaborate on these elements. The item identifier is the only 

mechanism to establish cross references between EDMDSchema compliant xml documents. So the only addressable elements 

in collaboration space are item (by its identifier) and item instance (by the identifiers of the including item and the name of the 

item instance). 

Please note: 

Within the protocol, the predecessor-successor relationship is NOT established by evaluating similarities in the identifier 

but by specifying it explicitly in the message. 

Please note: 

EDMDItem describes a defined state of an element, not the element itself. The assignment of the element states to elements 

in the CAD system takes place in the CAD system via the CAD-system-specific designator (see EDMDDesignator) 

for the EDMDItem. 

As a rule, the complete description of an element is not transported in a message but rather the differences between 

two states of an element. 

As example an assembly comprising two occurences of the same part is shown in Figure 31: 



Figure 48: Item data 

98 



6.6.2 Concept of the designator within the context of the system 

The designator is linked with the object as an aggregation, see Figure 49: 

Figure 49: Designator model 

To be able to identify elements in different contexts (e.g. systems), designators (➞ EDMDDesignator) are always assigned to a 

context in which they are valid. Designators are names (➞ EDMDName) or identifiers (➞ EDMDIdentifier) where names must 

be unique within a list of elements and identifiers must be unique within the complete context. 

Elements can have different designators which are valid in different system. This means that the CAD systems involved in the collaboration 

can use different designators for shared objects. The example in Figure 50 contains instances of EDMDItem and 

EDMDItemInstance which have different designators in two CAD systems. In this example an ‘assembly’ contains two times the 

same ‘part’. While the assembly is identified as in the ECAD system called the assembly 

is identified as in the system called . Also the instances of ‘part’ in ‘assembly’ 

have different names, the name of the first instance is in and in 

. Second instance and the ‘part’ itself have also different name and identifier in the different system. 

Since this mechanism is very flexible it is also used to describe external references, e.g. filename, reference on library entry or 

identification on back end systems, e.g. pdm. In EDMDSchema there are some predefined types of EDMDSystems: 

Manufacturer 

o The EDMDSystem describes the product range of a manufacturer. 

PLM 

o The EDMDSystem is a product lifecycle management system (e.g. engineering data management or enterprise ressource 

planning) 

ECAD 

o The EDMDSystem is a computer-aided design system for electrical design. 

MCAD 

oThe EDMDSystem is a computer-aided design system for mechanical design. 



Proxy 

o The EDMDSystem is a proxy that maps its own numbers to internal numbers. 

Library 

o The EDMDSystem is a library where components can be found. 

CommonStandard 

o The EDMDSystem is a common standard (e.g. DIN 41429) 

FactoryStandard 

o The EDMDSystem is a factory standard 

As example objects with different designators from different systems are shown in Figure 50: 

Figure 50: Designator data 

Please note: 

Item in a collaboration session have to contain at least two identifiers, one for each collaborating system. 

100 



6.6.3 Limitations on properties, user-defined properties 

Classes for representing limited properties and user-defined properties are shown in Figure 51: 

Figure 51: UserProperties model 

The properties of objects are represented as properties in EDMDSchema. In additional to the actual value, limitations regarding the value or 

the unit involved can be specified. This allows unnecessary loops within the collaboration to be avoided. The corresponding function is implemented 

in the class EDMDConstrainedProperty from which all property types inherit. 

Every EDMDConstrainedProperty can also have an originator. In the case of a property, this indicates the user who specified the value for the 

property. In the case of a limitation, this indicates the user who defined the limit. If during collaboration one or more limitations are violated, it 

is easy to determine which user to consult. 

In addition to the predefined properties, user-defined properties can also be added to most elements in EDMDSchema. This function is defined 

101 



in the element EDMDExtensibleObject. All subtypes of this type can be extended by means of user-defined properties. 

XML data which corresponds to other XML schemas can also be included as user-defined properties with the help of 

EDMDUserAnyProperty. 

The example UserProperties.idx (shipped in the zip archive including the xml schema definition of EDMDSchema, available at 

www.prostep.org/en/downloads) illustrates the embedding of user-defined properties and the integration of other XML data as 

EDMDUserAnyProperty. 



6.6.4 The geometry model, shape of an item 

Basic elements for describing the shape of an item are shown in Figure 52: 

Figure 52: Shape model 

The geometric model provides two mechanisms for representing the shape of an item: 

Storing the geometry information in external files 

Representing the geometry information in the integrated geometry model 

The shape of an item is described by an ItemShape, which comprises a number of different parts. 

The element ‘inverted’ for ShapeElement indicates whether the element is added to the shape of the item (OR operator), in which 

case inverted is ‘false’ or empty, or whether the element is taken away from the other objects (NAND operator), in which case 

inverted is ‘true’. The shape is put together in the order in which the elements occur in the XML document. 

Instances of the abstract class EDMDShapeDescription are used to represent the geometric information. There are two concrete 

types, which inherit from EDMDShapeDescription. If the shape of the ShapeElement is stored in external files, this is done 

using an EDMDExternalGeometricModel which is linked with an EDMDExternalSource which describes the mechanism for 

downloading the external files. The class EDMDCurveSet2d is used to represent the shape in EDMDSchema. As the name 

indicates, the description of the lines, points and curves within such a set is two-dimensional. EDMDCurveSet2d nevertheless 

describes a three-dimensional shape since an upper and lower limit for the described partial shape can be specified based on 

the basic level (on which the 2D elements are located). 

103 



Please note: 

An EDMDCurve can – either on its own or together with other EDMDCurves – describe a closed curve and thus a surface. 

Or using an (optional) thickness, it can itself describe a surface. 

Elements for the internal description of the shape are shown in Figure 53: 

Figure 53: CurveSet2d 

6.6.5 Roles 

A distinction is made between different types of roles: 

Role which a user assumes with regard to a collaboration object (RoleOnItem, Owner or Listener) 

Role executing a change (Actor) 

Role as the originator of an element (Originator) 

The distinction between the roles owner, listener and actor are shown in Figure 37: 



Figure 54: Roles 

Owner 

Specification of an owner is informal. The user is the person who is responsible for an item in a higher-level process. 

Listener 

Specification of a listener is informal. The listener is the person who, because of their responsibilities in a higher-level process, 

wants to be notified about any change made to an item. With regard to notification, an owner must be treated like a listener 

and must also receive a message about changes made to an item. 

The roles owner and listener for an item are passed on to subordinate items and elements. The specification of the owner of an 

item or element overwrites the owner specified by the higher-level item. This owner is then downgraded to listener. 

Actor 

The actor is the person who sent a message (e.g. with a change) in the protocol. 

Originator 

Properties and property limits can have an optional originator. The originator is the person who specified the value or the limit 

for the value. Within the collaboration, this information can be used to contact the appropriate user. Systems can evaluate this 

information and send automatic notifications if these limitations are violated. 

6.6.6 General information 

In xml schema the type definitions are organized in packages called namespace. This mechanism can be used to allow the usage 

of object types from different namespaces in a single XML document. EDMDSchema defines the following namespaces: 

http://www.prostep.org/ecad-mcad/edmd/2.0/administration 

http://www.prostep.org/ecad-mcad/edmd/2.0/annotation 

http://www.prostep.org/ecad-mcad/edmd/2.0/computational 

http://www.prostep.org/ecad-mcad/edmd/2.0/external 

http://www.prostep.org/ecad-mcad/edmd/2.0/foundation 

http://www.prostep.org/ecad-mcad/edmd/2.0/geometry.d2 

http://www.prostep.org/ecad-mcad/edmd/2.0/grouping 

http://www.prostep.org/ecad-mcad/edmd/2.0/material 

http://www.prostep.org/ecad-mcad/edmd/2.0/pdm 

105 



http://www.prostep.org/ecad-mcad/edmd/2.0/property 

http://www.prostep.org/ecad-mcad/edmd/2.0/text 

The WSDL is described in the namespace: 

http://www.prostep.org/ecad-mcad/edmd/2.0/ws 

The EDMDSchema explicitly allows the use of other namespaces in documents. The UserProperties.idx example (shipped in the 

zip archive including the xml schema definition of EDMDSchema, available at www.prostep.org/en/downloads) shows the 

use of additional namespaces in an XML document according to EDMDSchema. The documents must be well formed and it 

must be possible to validate them, i.e. for validation purposes not only the EDMDSchema documents but also XML schemas must 

be available for the other namespaces used. EDMDSchema uses the IDREF mechanism for references within documents. The 

standard suffix for documents according to EDMDSchema is .idx, an acronym for Interdomain Design Exchange. 

EDMDSchema is supplied as set of XSD documents in a zip archive, which is part of this recommendation. 

This archive contains the xsd-schemas of the informational model: 

administration.xsd 

annotation.xsd 

external.xsd 

foundation.xsd 

geometry.d2.xsd 

grouping.xsd 

masterPart.d3.xsd 

material.xsd 

pdm.xsd 

property.xsd 

text.xsd 

The wsdl and schema of the computational model: 

EDMDService.wsdl 

computational.xsd 

Sample data 

sample/pattern.idx 

sample/UserProperties.idx 

sample/Systems.idx 

sample/vcard.xsd 

sample/xlink.xsd 

The documentation of EDMDSchema is part of the recommendation but shipped as a separate html document. The documentation 

is structured in packages. Each package covers on namespace. The following sub chapters describe the main purpose of 

each package. 

6.6.7 Package EDMDSchema.foundation 

This package (cp. Figure 55) describes the contents of the namespace: 

http://www.prostep.org/ecad-mcad/edmd/2.0/foundation 

It contains object types and relation types that serve as basic elements of the data schema. All Types within the EDMDSchema 

inherit from these types. For more details about the types of this package please refer the document Implementation driven data 

model (EDMDSchema), which is part of this recommendation but released as a html document. 



Figure 55: Overview of foundation Package 

107 



6.6.8 Package EDMDSchema.property 


http://www.prostep.org/ecad-mcad/edmd/2.0/property 

It contains object types and relation types for describing properties and user-defined properties. Types which describe properties 

in the EDMDSchema inherit from types which are described in this package. For more details about the types of this 

package please refer the document Implementation driven data model (EDMDSchema), which is part of this recommendation 

but released as a html document. 

Figure 56: Over view of property Package 

108 





6.6.9 Package EDMDSchema.administration 


http://www.prostep.org/ecad-mcad/edmd/2.0/administration 

It contains object types and relation types for describing administrative relationships and persons. For more details about the 

types of this package please refer the document Implementation driven data model (EDMDSchema), which is part of this recommendation 


Figure 57: Overview of administration Package 

6.6.10 Package EDMDSchema.pdm 


http://www.prostep.org/ecad-mcad/edmd/2.0/pdm 

It contains object types and relation types for describing the structure of items. For more details about the types of this package 

please refer the document Implementation driven data model (EDMDSchema), which is part of this recommendation but released 

as a html document. 

110 



Figure 58: Overview of pdm Package 

111 





6.6.11 Package EDMDSchema.material 


http://www.prostep.org/ecad-mcad/edmd/2.0/material 

It contains object types and relation types for describing materials. Future extensions are planned. For more details about the 



Figure 59: Overview of material Package 

6.6.12 Package EDMDSchema.d2 

This package describes the contents of the namespace: 

http://www.prostep.org/ecad-mcad/edmd/2.0/geometry.d2 

It contains object types and relation types for describing geometric information. . For more details about the types of this package 

please refer the document Implementation driven data model (EDMDSchema), which is part of this recommendation but released 

as a html document. 

113 



6.6.13 Package EDMDSchema.external 


http://www.prostep.org/ecad-mcad/edmd/2.0/external 

It contains object types and relation types for describing external documents and external data sources. For more details about 

the types of this package please refer the document Implementation driven data model (EDMDSchema), which is part of this 

recommendation but released as a html document. 

Figure 60: Overview of external Package 

6.6.14 Package EDMDSchema.grouping 


http://www.prostep.org/ecad-mcad/edmd/2.0/grouping 

It contains object types and relation types for describing groupings. Types which describe groups inherit from the types defined 

in this package. For more details about the types of this package please refer the document Implementation driven data model 

(EDMDSchema), which is part of this recommendation but released as a html document. 

Figure 61: Overview of grouping Package 



6.6.15 Package EDMDSchema.annotation 


http://www.prostep.org/ecad-mcad/edmd/2.0/annotation 

It contains object types and relation types for describing annotations which the user can add to collaboration objects. For more 

details about the types of this package please refer the document Implementation driven data model (EDMDSchema), which is 

part of this recommendation but released as a html document. 

Figure 62: Overview of annotation Package 

6.6.16 Package EDMDSchema.text 


http://www.prostep.org/ecad-mcad/edmd/2.0/text 

It contains object types and relation types for describing simple texts that can be placed in Items. For more details about the 



Figure 63: Overview of text Package 

115 



6.6.17 Package EDMDSchema.computational 


http://www.prostep.org/ecad-mcad/edmd/2.0/computational 

It contains object types and relation types which are sent as parameters with EDMDMessages. For more details about the types 

of this package please refer the document Implementation driven data model (EDMDSchema), which is part of this recommendation 


Figure 64: Over view of computational Package 

6.6.18 Package EDMDSchema.3d_master_parts 


http://www.prostep.org/ecad-mcad/edmd/2.0/3d_master_parts 

Elements in this EDMD package are used to implement the 3D master part concept described in chapter 5.2. The abstract entity 

EDMD3dMasterModel is subclass of EDMDShapeDescription. Currently there are two master part models types described 

in EDMD recommendation: EDMD3dMasterModelTypeA and EDMD3dMasterModelTypB. The properties of these types are 

described by different kinds of property sets: 

Electrical insert property set 

Body property set 

Additional body property set (type A only) 

Pin property set 

Pad property set (type A only) 

Opt property set (type A only) 

Non geometry property set 

Except Electrical insert property set, these property sets are different for each 3D master part type. 

Therefore the EDMD schema defines type specific property sets (E.g. EDMDPinPropertyTypeA, EDMDPinPropertyTypeB). 



Figure 65: Overview of 3d_master_parts Package 

The properties of 3d master parts uses the property types EDMDLenghtProperty and EDMDColorProperty. Both entities are 

subclasses of EDMDConstrainedProperty. The EDMDConstrainedProperty allows to describe a tolerance range using the MinValue 

(deviation minus) and MaxValue (deviation plus) relation. The EDMDColorProperty describes the color by 9-digit rgb-code 

(red/green/blue). 

Figure 66: Color and length property used to describe properties of 3D master part 

Currently the property sets of the two 3d master model types contain over 100 properties. Figure 67 exemplary shows the properties 

for of EDMDPadPropertySetTypeA. For details see XSD schema of this package. 

117 



Figure 67: properties of pad property set 


7 EDMD PROTOCOL ProSTEP iViP Recommendation 

7 EDMD protocol 

The EDMD protocol is based on the implementation-driven data model (section 6.5.1) and serves to transfer change information 

between the systems involved. 

7.1 General information 

The messages in the EDMD protocol are defined in a general manner and can be exchanged between the systems involved 

using any technology (P2P approach). This means that the use cases involving synchronous and asynchronous collaboration can 

be represented in a 1:1 configuration or a 1:m configuration (cp. Figure 68). The subject of this recommendation is the 1:1 

configuration. 

Figure 68: Types of communication 

The representation of message exchange via Web services is part of this recommendation. The protocol interfaces are described 

in WSDL. WSDL is part of this recommendation and can be found in the zip archive including the xml schema definition 

of EDMDSchema. Alternatively, EDMD data can also be stored as XML documents, in which case the root element is always 

an EDMDDataSet. This can also include ProcessInstructions. The computational Package (➞ computational Package) contains 

definitions of ProcessInstruction subtypes which correspond to the messages. In this case, the message also refers to the EDMDDateSet 

itself. If several such ProcessInstructions exist, these are processed one after the other. 

In addition to describing the messages (➞ Messages), the protocol also specifies when the systems involved exchange which 

messages (➞ Protocol). 

The description of a CAD data set with the help of the implementation-driven data model can take place statically, i.e. a data 

set conforming to this schema can represent a complete version of design. During transferring changes, only the changed parts 

are transferred. If a message includes references to items which have not been included in messages it self, these items are represented 

in the message as item stub. These items only include at the very least an identifier and can be referenced within the 

document using IDREF. In the following, the item stub is taken to mean items which contain only identifiers that can be used to 

identify the item in the context of different systems. The section on processing rules describes how the information from these data 

sets has to be merged again. 

119 


ProSTEP iViP Recommendation 7 EDMD PROTOCOL 

7.2 Messages 


The messages are defined in such a way that they are easy to transfer to other technologies. In WSDL, they are defined as 

operations. They can however also be understood as function calls involving a shared library, as a call involving remote procedures, 

or as messages in a message queue. Therefore no mechanisms for receiver addressing have been defined in the 

schema since these would have to be made available by the underlying communication layer, e.g. by calling a remote procedure 

on precisely this remote system or by sending the message to this receiver in the message queue. It is also possible to 

embed the messages as ProcessInstructions in XML documents with an EDMDDataSet as the root element. The corresponding 

types are defined in the computational Package. 

This recommendation also defines a return value, which is returned as the result of a processing operation (➞ ServiceResult). If 

call interfaces are used, this value must be returned immediately. If queuing mechanisms are used, the underlying communication 

layer should allow a correlation between messages and results to be established. If queuing is used according to the “fire 

and forget” principle, this correlation must be ensured by the definition of additional solution-specific messages. 

7.2.2 SendInformation message 

In Figure 69 the message "SendInformation" is shown: 

Figure 69: SendInformation message 

This message is used to send information about the state of an item and the corresponding geometry. Therefore the message 

contains only one EDMDDateSet, which in turn contains information on the states of the items. 

7.2.3 SendChanges message 

In Figure 70 the message "SendChanges" is shown: 

Figure 70: SendChanges message 



This message is used to send changes made to parts. Only the item elements to which changes have been made are sent. Every 

changed item has a predecessor whose elements are transferred to the new item. The elements included in the message then 

overwrite the elements taken over from the predecessor. A more detailed description of how this is done is provided in the section 

on the processing rules (➞ Processing rules). Since the underlying transport mechanism does not necessarily allow a correlation 

to the sender to be established, the message also includes an IDREF indicating the originator of the message (actor). The 

originator must be formulated as an EDMDPerson in the EDMDDataSet included in the message. 

7.2.4 RequestForInformation message 

In Figure 71 the message "RequestForInformation " is shown: 

Figure 71: RequestInformation message 

This message can be used to request information on the states of items. Since the underlying transport mechanism does not necessarily 

allow a correlation to the sender to be established, the message also includes an IDREF indicating the originator of the 

message (actor). The actor must be formulated as an EDMDPerson in the EDMDDataSet included in the message. 

7.2.5 ServiceResult class 

In Figure 72 the class " 5.2.5 ServiceResult " is shown: 

Figure 72: ServiceResult class 

The ServiceResult class describes errors that can occur during the processing of messages. 

121 



7.3 Protocol 

The protocol specifies when, during the collaboration, which messages must be sent. 

Please note: 

In the case of Web service binding, every message sent is a client call. The reply expected by the protocol is not returned 

in the response. Only the EDMDResult including information about processing state of call are included in the response. 


All the systems involved manage assignments between the item identifiers used in their own systems and the identifiers used in 

other systems in an identifier repository. Since items can be identified only by an identifier (EDMDItemIdentifier) and the reference 

mechanism in EDMDSchema is IDREF, there is always an instance of EDMDItem including EDMDIdentifiers needed, which 

can be referenced by IDRef in an xml document. EDMDItems including only identifiers to facilititate references are hereinafter 

called item stub. Once a message containing new items is received, the receiver sends a mandatory message of the type 

SendInformation, which contains an item stub with at least two identifiers for all new items: the identifier of the original sender 

and the identifier of the receiver. This allows the sender to maintain his assignment table. 

An overview of the messages sent when transferring changes is shown in Figure 73: 

Figure 73: SendChanges 

Once the changes have been sent with message SendChange (see Figure above), the mandatory message containing the new 

identifiers is sent. Optionally, additional information can be requested with a message of the type RequestForInformation. The 

changes in the message may refer to items with which the receiver is not yet familiar. In this case, the message only contains the 

item stub. The receiver can request the other information using RequestForInformation. 

An overview of the messages sent when requesting information is shown in Figure 74: 



Figure 74: RequestForInformation 

A message of the type RequestForInformation can be used to request information about items; the items in the RequestForInformation 

message are only item stub. The response to such a request is always one or more messages of the type SendInformation. The 

items in these messages should contain all known identifiers. If new items are transferred, the mandatory adjustment of the identifiers 

is performed by means of a message of the type SendChange. 

7.3.2 Self contained Messages 

To allow a more convenient implementation of CAD system adapters the concept of a self contained message resp. document is introduced. 

A self contained document can contain several messages but has to include all informations about included items. This means, 

there is no external link to other document via item stubs. (External geometry can be included.) All optional information on an item 

that can be omitted in a normal SendInformation message is recommended. This means all known Identifiers and Attributs of an item 

has to be included in the same message. If message includes changes, it has to include all changes from the base line otherwise the 

NewItems of Changes might be not complete. For marking a document as self contained the IsSelfContained flag at EDMDHeader 

should be used. For indication that an IT system can process self contained messages only the flag NeedsSelfContainedMessages at 

EDMDSystem should be used. Marking an item as a base line can be done by the flag BaseLine at EDMDItem. 

7.4 Processing rules 


The processing rules describe how the internal representations of the elements, which are represented by an item, have to be 

changed when a message is received. The processing of a message must be executed as a transaction. If errors occur during 

the processing, all the changes transported in the message are discarded. 

The processing is performed individually for each item. The following elements belonging to an item are processed in blocks: 

Identifier (list) 

ItemType 

PackageName (list) 

ItemInstance (list) 

Shape 

ShapeTransformation 

Accept (list) 

Roles on item or included instance (list) 

123 



Elements resp. their internal representations can have the following states: 

set 

not set 

Where set means the element was already set at the internal representation of item and unset means the element was never set 

at the internal representation of item. In the case of lists, this state always applies to the whole list. 

7.4.2 SendInformation 

When processing a message of the type SendInformation, the items in the message are processed one after the other (cp. Figure 

75, Figure 76): 

1) Checking identifiers (list). 

a. If the item does not contain any identifiers, the message is errored and the processing transaction is aborted. 

b. If the item does not contain any known identifiers, the item is new. A representation according to the other information in 

the item is created. Processing is then concluded. 

c. If the item contains known identifiers, the representation of a known item must be adjusted. Processing continues with step 2. 

2) Adjustment of identifier repository 

a. If the identifiers contained in the item do not agree with the identifier repository, the message is errored and the processing 

transaction is aborted. 

b. If the identifiers contained in the item do not disagree with the identifier repository, new identifiers are stored in the repository, 

and processing continues with step 3. 

3) Adjustment of ItemType 

a. If the ItemType is not set in the existing representation of the item but is set in the message, the ItemType from the message 

is set in the representation. Processing continues with step 4. 

b. If the ItemType is set in the existing representation of the item but is not set in the message, processing continues with 

step 4. 

c. If the ItemType is set in the existing representation of the item and the same ItemType is set in the message, processing 

continues with step 4. 

d. If the ItemType is set in the existing representation of the item but a different ItemType is set in the message, the message 

is errored and the processing transaction is aborted. 

4) Adjustment of PackageName, for every PackageName in the list; processing continues with step 5 once all the PackageNames 

have been processed without error. 

a. If the PackageName is not set in this system context in the existing representation of the item but is set for this system context 

in the message, the PackageName from the message for this system context is set in the representation. Processing 

continues with the next PackageName. 

b. If the PackageName is set in this system context in the existing representation of the item but is not set for this system 

context in the message, processing continues with the next PackageName. 

c. If the PackageName is set in this system context in the existing representation of the item and the same PackageName is 

set in the message for this system context, processing continues with the next PackageName. 

d. If the PackageName is set in this system context in the existing representation of the item and a different PackageName 

is set in the message for this system context, the message is errored and the processing transaction is aborted. 

5) Adjustment ItemInstance (list) 

a. If the list of ItemInstances is not set in the existing representation of the item but is set in the message, the list of ItemInstances 

from the message is set in the representation. Processing continues with step 6. 

b. If the list of ItemInstances is set in the existing representation of the item but is not set in the message, processing continues 

with step 6. 

c. If the list of ItemInstances is set in the existing representation of the item and the same list of ItemInstances is set in the 

message, processing continues with step 6. 

d. If the list of ItemInstances is set in the existing representation of the item but a different list of ItemInstances is set in the 

message, the message is errored and the processing transaction is aborted. 



6) Adjustment Shape 

a. If the Shape is not set in the existing representation of the item but is set in the message, the Shape from the message is 

set in the representation. Processing continues with step 7. 

b. If the Shape is set in the existing representation of the item but is not set in the message, processing continues with step 7. 

c. If the Shape is set in the existing representation of the item and the same Shape is set in the message, processing continues 

with step 7. 

d. If the Shape is set in the existing representation of the item but a different Shape is set in the message, the message is 

errored and the processing transaction is aborted. 

7) Adjustment of Accept-Status, for every entry in the list; once all the entries in the list have been processed without error, the 

processing of the message has been completed successfully. 

a. If the originator has not set the Accept-Status in the existing representation of the item but has set it in the message, the 

Accept-Status from the message is set for this originator in the representation. Processing continues with the next entry. 

b. If the originator has set the Accept-Status in the existing representation of the item but has not set it in the message, 

processing continues with the next entry. 

c. If the originator has set the Accept-Status in the existing representation of the item and has set the same Accept-Status in 

the message, processing continues with the next entry. 

d. If the originator has set the Accept-Status in the existing representation of the item and has set a different Accept-Status in 

the message, the message is errored and the processing transaction is aborted. 

8) Adjustment of the roles in EDMDItems und EDMDItemInstances 

Note: 

EDMDItem describes the state of an element. This means that properties that have not yet been communicated can be 

added to an EDMDItem. It is not possible to make changes to properties which have already been communicated 

since this is always involves a new state of the underlying element. The roles and acceptance statuses constitute 

the only logical exceptions since they do not describe the state of an element itself but rather the relationship of individual 

actors to this state of the element. 

125 



Figure 75: Processing SendInformation (1 of 2) 



Figure 76: Processing SendInformation (2 of 2) 

127 



7.4.3 SendChanges 

The SendChanges message contains a number of changes which can be grouped into transactions. These transactions should not be 

confused with the transactions used to process the messages. The transactions in SendChanges messages are informal groups of 

changes which indicate to the user that his collaboration partner views these changes as a unit. This avoids unnecessary inquiries. 

Before starting processing of a message (or document) containing SendChanges messages all items that are not referenced by 

an change have to be processed like in a SendInformation message. 

When changes are processed, the following elements involved in the change are processed: 

NewItem is the identifier of the new item; the message contains the changes involved in the new item compared with the predecessor. 

PredecessorItem is the identifier of the predecessor item. 

DeletedInstanceName is the list of the names of the ItemInstances which the new item no longer includes. 

The changes are processed one after the other (cp. Figure 77, Figure 78, Figure 79). 

1) Checking identifiers of NewItem (list). 

a. If the identifier of NewItem already exists, the message is errored and the processing transaction is aborted. 

b. The identifier is not known, a representation of NewItem is created. 

2) Checking identifiers of PredecessorItem (list) 

a) If the identifier for PredecessorItem is not known, the item involved is a new item for which processing must first be requested, 

therefore this step is followed by step 3. 

b) If the identifier for PredecessorItem is known, the item involved is an item which has already been adjusted and whose 

representation can be used. 

3) Request representation of PredecessorItem 

4) Adjustment of ItemType 

a. If the ItemType is not set in the existing representation of the PredecessorItem but is set in the message, the ItemType from 

the message is set in the representation of NewItem. Processing continues with step 5. 

b. If the ItemType is set in the existing representation of the PredecessorItem but is not set in the message, the ItemType from 

the PredecessorItem is set in the representation of NewItem. Processing continues with step 5. 

c. If the ItemType is set in the existing representation of the PredecessorItem and in the message, the ItemType from the 

message is set in the representation of NewItem. Processing continues with step 5. 

5) Adjustment of PackageName, for every PackageName in the list; processing continues with step 5 once all the PackageNames 

have been processed without error. 

a. If the PackageName is not set in this system context in the existing representation of the PredecessorItem but is set for this 

system context in the message, the PackageName from the message for this system context is set in the representation of 

NewItem. Processing continues with the next PackageName. 

b. If the PackageName is set in this system context in the existing representation of the PredecessorItem but is not set in the 

message for this system context, the PackageName from the PredecessorItem for this system context is set in the representation 

of NewItem. Processing continues with the next PackageName. 

c. If the PackageName is set in this system context in the existing representation of the PredecessorItem and in the message 

for this system context, the PackageName from the message for this system context is set in the representation of NewItem. 

6) Checking ItemInstance names: 

a) The ItemInstance names are unique for every context. Processing continues with step 7. 

b) The ItemInstance names are not unique for every context. Processing of the transaction is aborted with an error. 

7) Create ItemInstance list for NewItem: The following is checked for each entry in the ItemInstance list in the representation of 

PredecessorItem using the InstanceName: 

a) Whether the list in the message contains an ItemInstance with the same name. If this is the case, this ItemInstance is 

copied from the message to the representation of NewItem. 

b) Or whether the name of the ItemInstance is included in the list of DeletedInstanceNames. In this case, this ItemInstance 

with the change is deleted, i.e. not copied to NewItem. 

c) If neither a) nor b) apply, the ItemInstance is copied from the representation of PredecessorItem to the representation of NewItem. 



8) Adjustment Shape 

a. If the Shape is not set in the existing representation of the PredecessorItem but is set in the message, the Shape from the 

message is set in the representation of NewItem. Processing continues with step 9. 

b. If the Shape is set in the existing representation of the PredecessorItem but is not set in the message, the Shape from the 

representation of PredecessorItem is copied to the representation of NewItem. Processing continues with step 9. 

c. If the Shape is set in the existing representation of PredecessorItem and in the message, the Shape from the message is 

set in the representation of NewItem. Processing continues with step 9. 

9) Adjustment of Accept-Status, only the Accept-Statuses from the message are used for the representation of NewItem: 

a. If the message contains Accept-Status for NewItem, these are copied to the representation of NewItem. Once this has 

been done, the processing of the change has been brought to a successful conclusion and the next change can be processed. 

b. If the message does not contain an Accept-Status for NewItem, the processing of the change has been brought to a successful 

conclusion and the next change can be processed 

10) Adjustment of roles for EDMDItem and EDMDItemInstance 

Note: 

EDMDItem reference as a NewItem in a change have to contain all changed sub elements. Only SendInformation 

messages allow split up the information on several messages. 

129 



Figure 77: Processing SendChanges (1 of 3) 




131 





ANNEX A: PACKAGES EDMDSCHEMA ProSTEP iViP Recommendation 

Annex A: Packages EDMDSchema 

The Implementation driven data model with documentation of EDMDSchema, including also UML is provided in html in the 

separated zip-archive PSI5_EDMD-Schema_2.0_HTML.zip (available at www.prostep.org/en/downloads). The page 

index.html is the entry point. 

133 


ProSTEP iViP Recommendation ANNEX B: EDMDSCHEMA 

Annex B: EDMDSchema 

EDMDSchema is supplied in the separated zip-archive PSI5_EDMD-Schema_2.0.zip (available at www.prostep.org/en/downloads). 

This archive contains the xsd-schemas of the informational model: 

administration.xsd 

annotation.xsd 

external.xsd 

foundation.xsd 

geometry.d2.xsd 

grouping.xsd 

masterPart.d3.xsd 

material.xsd 

pdm.xsd 

property.xsd 

text.xsd 

The wsdl and schema of the computational model: 

EDMDService.wsdl 

computational.xsd 

Sample data 

sample/pattern.idx 

sample/UserProperties.idx 

sample/Systems.idx 

sample/vcard.xsd 

sample/xlink.xsd 


ANNEX C: 3D MASTER MODELS ProSTEP iViP Recommendation 

Annex C: 3D Master Models 

The 3D Master Models (cp. 5) are provided as separated zip-archive PSI5_Mastermodels.zip (available at 

www.prostep.org/en/downloads). Both types are included: 

PSI5_Mastermodel_Type_A.pdf 

PSI5_Mastermodel_Type_B.pdf 

135 


ProSTEP iViP Recommendation ANNEX D: CONFORMANCE GUIDELINES 

Annex D: Conformance Guidelines 

The Conformance Guidelines are provided as separate document PSI5_Conformance_Guidelines_v2.0.pdf (available at 

www.prostep.org/en/downloads). 


ANNEX E: IMPLEMENTATION GUIDELINES ProSTEP iViP Recommendation 

Annex E: Implementation Guidelines 

The Implementation Guidelines are provided as separate document PSI5_Implemenation_Guidelines_v2.0.pdf (available at 

www.prostep.org/en/downloads). 

137 


ProSTEP iViP Association 

Dolivostraße 11 

64293 Darmstadt 

Germany 

Tel. +49-6151-9287336 

Fax +49-6151-9287326 

psev@prostep.com 

www.prostep.org 

ISBN 978-3-9812689-0-4 

Version 2.0, May 2010 

Price 109€

ECAD / MCAD Collaboration - prostep.org

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?