ECAD/MCAD Collaboration ECAD/MCAD ... - ProSTEP iViP

ECAD/MCAD Collaboration 

RECOMMENDATION 

ECAD/MCAD Collaboration; PSI 5 

Version 1.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 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 1.0 / April 2008


DISCLAIMER · COPYRIGHT 

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. 

. 

PSI 5 (ECAD/MCAD) / V 1.0 / April 2008 

III

TABLE OF CONTENTS 


Table of Contents 

1 Introduction 10 

1.1 Preface 10 

1.2 Objectives of ECAD/MCAD collaboration 10 

1.3 Structure of the Recommendation 11 

2 General Requirements 12 

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

2.2 Working in the native system 12 

2.3 Separate collaboration environment 14 

2.4 Asynchronous and synchronous collaboration 15 

2.5 Means of communication parallel to collaboration 15 

2.6 Support for different forms of representation 15 

2.7 Cardinality of collaboration 16 

2.8 Initiating collaboration 17 

3 Use cases 18 

3.1 Standardized use case description 18 

3.2 Actors within the use cases 19 

3.3 Defining a board baseline 20 

3.4 Placement under mechanical constraints 21 

3.5 Placement under electrical constraints 23 

3.6 Change of board components 25 

3.7 Change of placement locations 26 

3.8 Replacement of components 28 

3.9 Panelization design review 30 

4 EDMD data model 32 

4.1 Overview 32 

4.2 Packages in the user-driven data model 35 

4.2.1 Package 1: item definition and product structure 35 

4.2.2 Package 2: item classification and grouping 38 

4.2.3 Package 3: person and organization information 39 

4.2.4 Package 4: ECAD shape information 40 

4.2.5 Package 5: constraint definition 43 

4.2.6 Package 6: property and material definition 43 

4.2.7 Package 7: 2d geometry model 46 

4.2.8 Package 8: shape dependant information 49 


4.3 Objects 53 

4.3.1 annotation 53 

4.3.2 assembly_component 53 

4.3.3 assembly_component_relationship 53 

4.3.4 assembly_definition 53 

4.3.5 assembly_group_component 53 

4.3.6 b_rep_model 54 

4.3.7 b_spline_curve 54 

4.3.8 cartesian_coordinate_space 54 

4.3.9 cartesian_coordinate_space_2d 54 

4.3.10 cartesian_coordinate_space_3d 54 

4.3.11 cartesian_point 54 

4.3.12 centre_of_mass 55 

IV PSI 5 (ECAD/MCAD) / V 1.0 / April 2008 III



4.3.13 circle 55 

4.3.14 classification_association 55 

4.3.15 classification_attribute 56 

4.3.16 collaboration_definition 56 

4.3.17 component_termination_passage 56 

4.3.18 component_termination_passage_template_interface_terminal 56 

4.3.19 component_termination_passage_template_join_terminal 56 

4.3.20 component_termination_passage_template_terminal 57 

4.3.21 composite_curve 57 

4.3.22 constraint 57 

4.3.23 curve 57 

4.3.24 curve_on_surface 58 

4.3.25 curve_set_2d 58 

4.3.26 cutout 58 

4.3.27 Cutout_edge_segment 58 

4.3.28 data_environment 58 

4.3.29 definition_based_product_occurrence 59 

4.3.30 design_discipline_item_definition 59 

4.3.31 design_layer_stratum 59 

4.3.32 design_layer_technology 59 

4.3.33 detailed_geometric_model_element 59 

4.3.34 digital_file 60 

4.3.35 documentation_layer_stratum 60 

4.3.36 documentation_layer_technology 60 

4.3.37 ellipse 60 

4.3.38 external_geometric_model 60 

4.3.39 external_geometric_model_with_parameters 61 

4.3.40 external_model 61 

4.3.41 feature_parameter 61 

4.3.42 filled_via 61 

4.3.43 general_classification 62 

4.3.44 general_parameter 62 

4.3.45 general_property 62 

4.3.46 general_shape_dependent_property 63 

4.3.47 geometric_model 63 

4.3.48 geometric_model_relationship_with_transformation 63 

4.3.49 hybrid_geometric_model_3D 64 

4.3.50 hyperbola 64 

4.3.51 instance_placement 64 

4.3.52 inter_stratum_feature 64 

4.3.53 interconnect_module_constraint_region 65 

4.3.54 item 65 

4.3.55 item_contraint 66 

4.3.56 item_definition_instance_relationship 66 

4.3.57 item_instance 66 

4.3.58 item_property_association 66 

4.3.59 item_shape 67 

4.3.60 item_version 67 

4.3.61 laminate_component 67 

4.3.62 line 67 

IV PSI 5 (ECAD/MCAD) / V 1.0 / April 2008 

V



4.3.63 material 68 

4.3.64 material_property 68 

4.3.65 material_property_association 68 

4.3.66 material_property_value_representation 68 

4.3.67 moments_of_inertia 68 

4.3.68 next_higher_assembly 69 

4.3.69 non_features_shape_element 69 

4.3.70 numerical_value 69 

4.3.71 offset_curve 69 

4.3.72 organization 70 

4.3.73 parabola 70 

4.3.74 part_feature 70 

4.3.75 part_mounting_feature 70 

4.3.76 partially_plated_cutout 70 

4.3.77 person 71 

4.3.78 person_in_organization 71 

4.3.79 person_organization_assignment 71 

4.3.80 physical_connectivity_interrupting_cutout 72 

4.3.81 plated_cutout 72 

4.3.82 plated_cutout_edge_segment 72 

4.3.83 plated_inter_stratum_feature 72 

4.3.84 plated_passage 72 

4.3.85 point 73 

4.3.86 point_on_curve 73 

4.3.87 point_on_surface 73 

4.3.88 polyline 73 

4.3.89 printed_part_template_terminal 74 

4.3.90 printed_part_cross_section_template_terminal 74 

4.3.91 printed_part_template_interface_terminal 74 

4.3.92 printed_part_template_join_terminal 74 

4.3.93 printed_part_template_terminal 74 

4.3.94 property 74 

4.3.95 property_value 75 

4.3.96 property_value_association 75 

4.3.97 property_value_representation 75 

4.3.98 property_constraint 76 

4.3.99 shape_dependent_property 76 

4.3.100 shape_description 76 

4.3.101 shape_element 76 

4.3.102 shape_feature 76 

4.3.103 single_instance 77 

4.3.104 stratum 77 

4.3.105 stratum_feature_template_component 77 

4.3.106 stratum_technology 77 

4.3.107 structured_printed_part_template_terminal 78 

4.3.108 thermal_component 78 

4.3.109 transformation 78 

4.3.110 transformation_2d 78 

4.3.111 transformation_3d 78 

4.3.112 trimmed_curve 78 

4.3.113 unit 79 

VI PSI 5 (ECAD/MCAD) / V 1.0 / April 2008



4.3.114 unsupported_passage 79 

4.3.115 value_limit 79 

4.3.116 value_range 80 

4.3.117 value_with_unit 80 

4.3.118 via 80 

4.3.119 wireframe_model_2d 80 

4.4 Implementation steps and functional scope 81 

4.5 Mapping logic 82 

4.5.1 Package 1: item definition and product structure 82 

4.5.2 Package 2: item classification and grouping 85 

4.5.3 Package 3: person and organization information 86 

4.5.4 Package 4: ECAD shape information 87 

4.5.5 Package 5: constraint definition 90 

4.5.6 Package 6: property and material definition 90 


4.5.8 Package 8: shape dependant information 93 


4.6 Implementation-driven data model (EDMDSchema) 96 

4.6.1 Concept of the “item” 96 

4.6.2 Concept of the designator within the context of the system 98 

4.6.3 Limitations on properties, user-defined properties 100 

4.6.4 The geometry model, shape of an item 101 

4.6.5 Roles 105 

4.6.6 General information 106 

4.6.7 Package EDMDSchema.foundation 107 

4.6.8 Package EDMDSchema.property 110 

4.6.9 Package EDMDSchema.administration 113 

4.6.10 Package EDMDSchema.pdm 113 

4.6.11 Package EDMDSchema.material 116 

4.6.12 Package EDMDSchema.d2 116 

4.6.13 Package EDMDSchema.external 116 

4.6.14 Package EDMDSchema.grouping 117 

4.6.15 Package EDMDSchema.annotation 118 

4.6.16 Package EDMDSchema.text 119 

4.6.17 Package EDMDSchema.computational 120 

5 EDMD protocol 123 

5.1 General information 123 

5.2 Messages 124 


5.2.2 SendInformation message 124 

5.2.3 SendChanges message 125 

5.2.4 RequestForInformation message 125 

5.2.5 ServiceResult class 126 

5.3 Protocol 127 


5.4 Processing rules 129 


5.4.2 SendInformation 129 

5.4.3 SendChanges 133 

Annex A: Packages EDMDSchema 137 

Annex B: EDMDSchema 137 


VII

FIGURES 


Figures 

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

Figure 2: Options for integrating the collaboration modules 13 

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

Figure 4: Configuration of collaboration control 16 

Figure 5: Dependencies between the use cases 18 

Figure 6: Roles and actors within ECAD/MCAD collaboration 19 

Figure 7: Overview of the application-driven data model 33 

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

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

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

Figure 11: Overview of the “ECAD shape information” Package 41 

Figure 12: Overview of the “constraint definition” Package 43 

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

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

Figure 15: Overview of the “shape dependant information” Package 50 

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

Figure 17: Implementation steps 81 

Figure 18: Mapping in Package 1 83 

Figure 19: Mapping classification and grouping mechanisms 85 

Figure 20: Mapping the organizational units and roles 86 

Figure 21: Mapping the shape information 88 

Figure 22: Mapping the constraints 90 




Figure 26: Item model 96 

Figure 27: Item data 97 

Figure 28: Designator model 98 

Figure 29: Designator data 99 

Figure 30: UserProperties model 100 

Figure 31: Shape model 101 

Figure 32: CurveSet2d 103 

Figure 33: Roles 105 

Figure 34: Overview of foundation Package 108 

Figure 35: Over view of property Package 111 

Figure 36: Overview of administration Package 113 

Figure 37: Overview of pdm Package 114 

Figure 38: Overview of material Package 116 

Figure 39: Overview of external Package 116 

Figure 40: Overview of grouping Package 117 

Figure 41: Overview of annotation Package 118 

Figure 42: Overview of text Package 119 

Figure 43: Over view of computational Package 121 

Figure 44: Types of communication 123 

Figure 45: SendInformation message 124 

Figure 46: SendChanges message 125 

Figure 47: RequestInformation message 125 

Figure 48: ServiceResult class 126 

VIII PSI 5 (ECAD/MCAD) / V 1.0 / April 2008


FIGURES 

Figure 49: SendChanges 127 

Figure 50: RequestForInformation 128 

Figure 51: Processing SendInformation (1 of 2) 131 

Figure 52: Processing SendInformation (2 of 2) 132 

Figure 53: Processing SendChanges (1 of 3) 135 




IX

1 INTRODUCTION ProSTEP iViP Recommendation 

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 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. 

10 PSI 5 (ECAD/MCAD) / V 1.0 / April 2008


1 INTRODUCTION 

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. 

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 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, which in turn is followed 

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

a abbreviation for Electrical Design Mechanical Design. 


11

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. 

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 2): 

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. 



2 GENERAL REQUIREMENTS 

Figure 2: 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. 


13


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 3. 

Figure 3: 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 collaboration 

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. 

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. 


15


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 4). 

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 4: 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 collaboration 

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. 


17

3 USE CASES ProSTEP iViP Recommendation 

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 5. 

Figure 5: Dependencies between the use cases 



3 USE CASES 

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 6. 

Figure 6: 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 electrical 

components is processed. 


19


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 information 

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 connected. 

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. 



3 USE CASES 

Diagram 

Benefits 

Notes 

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. 

No additional notes 

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 relating to the electrical components is processed. 

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. 


21


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. 

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. 



3 USE CASES 

Diagram 

Benefits 

Notes 

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 


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. 




23


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. 


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 



3 USE CASES 

Benefits 

Notes 

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.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. 

Actors 



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

concerning the board outline 



Preconditions 

Description 

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

been performed. 

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

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. 

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. 



Alternatives – 

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

been checked using both native systems. 


25


Diagram 

Benefits 

Notes 

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


3.7 Change of placement locations 

Aim 


be 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. 

Actors 







Preconditions 

Description 




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. 



3 USE CASES 

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. 


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



Alternatives – 

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 

Notes 




27


3.8 Replacement of components 

Aim 


be 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. 

Actors 




requirements concerning the board outline 

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

information relating to the electrical components is processed. 

Preconditions 

Description 




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

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. 


impact the replaced component has on the existing PCB layout. 



Alternatives --- 

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. 



3 USE CASES 

Diagram 

Benefits 

Notes 




29


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. 

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

Actors 




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 

Description 

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

been created. 

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? 



3 USE CASES 

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 

Notes 

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

to and including the manufacturing processes. 



31

4 EDMD DATA MODEL ProSTEP iViP Recommendation 

4 EDMD data model 

4.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 

collaboration. 

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

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

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

packages can be found in section 4.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 4.5.1. 


4 EDMD DATA MODEL 


Figure 7: Overview of the application-driven data model 

33 

34


4.2 Packages in the user-driven data model 

4.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 8). 

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. 

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 



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

36 

37


4.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 9). 

Figure 9: 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 




4.2.3 Package 3: person and organization information 

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

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

Figure 10: 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 


39


4.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 11). The package allows electrical semantics to be defined 

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


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, 

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 



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

41 

42


4.2.5 Package 5: constraint definition 

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

Figure 12: 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 

4.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 13). 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. 


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 




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

44 

45


4.2.7 Package 7: 2d geometry model 

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


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 



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

47 

48


4.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 15). 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. 

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 



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

50 

51



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

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 this 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 16: Overview of the “3d geometry model” Package 


b_rep_model, hybrid_geometric_model_3d 




4.3 Objects 

4.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. 

4.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. 


4.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. 


4.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 

id 

name 

assembly_type 

Description 

The id specifies the identifier of the design_discipline_item_definition. 

The name specifies the name of the design_discipline_item_definition. 

The assembly_type specifies the kind of the assembly_definition. 

Note: "functional assembly" or "design assembly" are examples of an 

assembly_type. 

4.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. 



53


4.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. 


4.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 

Description 

The name specifies the name by which the 

detailed_geometric_model_element is referred to. 

4.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. 


4.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. 


4.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. 





4.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 

Description 



4.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 

Description 

The description specifies additional information about the property_value. 

4.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 

Description 



4.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 

Description 

The role specifies the relationship between the 

general_classification and the associated object. 


55


4.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 

name 

description 

Description 

The id specifies the identifier of the classification_attribute that must be 

unique within the scope of the associated general_classification 

The name specifies the name by which the classification_attribute 

is referred to. 

The description specifies additional information about the 

classification_attribute. 

4.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 an 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: 


id 

name 

description 

Description 


The name specifies a name of the design_discipline_item_definition. 

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". 

4.3.17 component_termination_passage 

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


4.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. 


4.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. 





4.3.20 component_termination_passage_template_terminal 

A component_termination_passage_template_terminal is a type of Shape_feature. 


4.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: 


name 

Description 



4.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 

name 

constraint_type 

Description 

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

the collaboration. 

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

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). 

4.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: 


name 

Description 




57


4.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: 


name 

Description 



4.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. 


4.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. 


4.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. 


4.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 

environment_name 

Description 


data_environment. 

The environment_name specifies the name by which the 

data_environment is referred to. 




4.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. 


4.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 subtype collaboration_definition should be instantiated. If the item_version represents an assembly of 

items the subtype 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: 


id 

name 

Description 


The name specifies a name of the design_discipline_item_definition. 

4.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. 


4.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. 


4.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: 


name 

Description 




59


4.3.34 digital_file 

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


4.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 


4.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. 


4.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: 


name 

Description 



4.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 

description 

Description 

The model_id specifies the identifier of the external_model. 

The description specifies additional information about the external_model. 




4.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: 


model_id 

description 

Description 



external_geometric_model_with_parameters. 

4.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: 


model_id 

description 

Description 


The description specifies additional information about the external_model. 

4.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 

Description 

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. 

4.3.42 filled_via 

A filled_via is a type of via. 



61


4.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 

description 

version_id 

Description 

The id specifies the identifier of the general_classification. 



The version_id specifies the identification of a particular version of the 


4.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 

Description 

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. 

4.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 

id 

version_id 

property_type 

Description 

The description specifies additional information about the property. 

The id specifies the identifier of the property. 

The version_id specifies the identification of a particular version of 

a property. 

The property_type specifies the kind of property the 

general_property defines. 




4.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 

property_type 

property_value 

Description 


property_value of the shape_dependent_property. 

The property_type defines the type of characteristic that is specified 

for an object. 

The property_value specifies the value that is given for a particular 

characteristic. 

4.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). 

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). 


4.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. 



63


4.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. 


4.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: 


name 

Description 



4.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. 


4.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 

Description 

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 




4.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 

constrained_design_object_category 

Description 

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. 

Specifies object categories for the interconnect_module_constraint_region. 

The names shall be interpreted as the identification of Application Object 

categories to be constrained. 

4.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 

name 

description 

Description 

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. 

The name specifies the name of the item. 

The description specifies additional information about the item. 


65


4.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. 



id 

name 


Description 




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). 

4.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. 


4.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) 

indepedent 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 

id 

Description 

The description specifies additional information about the item_instance. 

The id specifies the identifier of the item_instance. 

4.3.58 item_property_association 

An item_property_association is a mechanism to associate a property value with an object. 





4.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 

Description 

The described_object specifies the object whose shape the item_shape 

defines. 

4.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 

description 

Description 

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. 

The description specifies additional information about the item_version. 

4.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. 


4.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: 


name 

Description 




67


4.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 

Description 

The material_name specifies the name by which the material is referred to. 

4.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: 


description 

id 

version_id 

property_name 

Description 



The version_id specifies the identification of a particular version 

of a property. 

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'. 

4.3.65 material_property_association 

A material_property_association is an object that associates a material object with a material_property_value_representation 

object. 


4.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. 


4.3.67 moments_of_inertia 

A moments_of_inertia describes the matrix of inertia of a rigid body. The moments of inertia 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 

Description 

The description specifies additional information about the property_value. 




4.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. 


4.3.69 non_feature_shape_element 

A non_feature_shape_element is a type of Shape_element that is not on the physical boundary of a Part_view_definition. 


4.3.70 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 

value_component 

Description 

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. 

The value_component specifies the quantity of the numerical_value. 

4.3.71 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 

Description 




69


4.3.72 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 

id 

Description 

The organization_name specifies the name used to refer to the organization. 

The id specifies the identifier of the organization. 

4.3.73 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 

Description 



4.3.74 part_feature 

A part_feature is a type of shape_feature. 

The following table shows the attributes of a part_feature: 


material_state_change 

Description 

Specifies whether the material state change for the part_feature is due to 

addition of material or due to removal of material. 

4.3.75 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. 


4.3.76 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. 





4.3.77 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 

Description 

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. 

4.3.78 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 

location 

id 

Description 

The role specifies the relationship between the person and the organization. 

The location specifies the relevant address of the person_in_organization. 

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. 

4.3.79 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 representation 

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. 


71


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 

Description 

The role specifies the responsibility of the assigned Person or organization 

with respect to the object that it is applied to. 

4.3.80 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. 


4.3.81 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. 


4.3.82 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. 


4.3.83 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. 


4.3.84 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. 





4.3.85 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: 


name 

Description 



4.3.86 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: 


name 

Description 



4.3.87 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: 


name 

Description 



4.3.88 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: 


name 

Description 




73


4.3.89 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. 


4.3.90 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. 


4.3.91 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. 


4.3.92 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. 


4.3.93 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. 


4.3.94 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: 


description 

id 

version_id 

Description 



The version_id specifies the identification of a particular version 

of a property. 




4.3.95 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: 


value_name 

Description 

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. 

4.3.96 property_value_association 

A property_value_association is a mechanism to assign a property_value_representation to an object. 


4.3.97 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 

Description 

The value_determination specifies information on how the 

property_value_representation must be interpreted. 


75


4.3.98 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: 


id 

name 


Description 




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. 

4.3.99 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 

Description 


shape_dependent_property. 

4.3.100 shape_description 

A shape_description is either a geometric_model or a external_geometric_model. 


4.3.101 shape_element 

A shape_element is a portion of shape that has to be identified explicitly to be associated with other information. 


4.3.102 shape_feature 

A shape_feature is a type of shape_element. 





4.3.103 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 

id 

Description 

The description specifies additional information about the item_instance. 

The id specifies the identifier of the item_instance. 

4.3.104 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 

of_technology 

stratum_surface_designation 

Description 

The identifier that distinguishes the stratum. 

Specifies a role of the stratum_technology for the stratum. 

Kind of designation of the stratum, either average or primary or secondary. 

4.3.105 stratum_feature_template_component 

A stratum_feature_template_component is a type of inter_stratum_feature. 


4.3.106 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 

layer_position 

id 

Description 

The words by which the stratum_technology is known. 

Specifies the alphanumeric identifier of a stratum_technology. 

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. 

Unique identifier. 


77


4.3.107 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. 


4.3.108 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. 


4.3.109 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 


4.3.110 transformation_2d 

A transformation_2d is the definition of a geometric transformation in 2D space. 

A transformation_2d is a type of transformation. 


4.3.111 transformation_3d 

A transformation_3d is the definition of a geometric transformation in 3D space. 

A transformation_3d is a type of transformation. 


4.3.112 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. 

A trimmed_curve is a type of curve. 

The following table shows the attributes of a shape trimmed_curve: 


name 

Description 






4.3.113 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 

Description 

The unit_name specifies the term representing the kind of unit. 

Note: "gram", "litre", or "volt" are examples for the unit_name. 

4.3.114 unsupported_passage 

An unsupported_passage has no metallization in the realization of its walls. An unsupported_passage is a type of inter_stratum_feature. 


4.3.115 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: 


value_name 

limit 

limit_qualifier 

Description 



The limit specifies the value of the limit. 

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. 


79


4.3.116 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 

upper_limit 

lower_limit 

Description 



The upper_limit specifies the maximum acceptable value that is 

constrained by the value_range. 

The lower_limit specifies the minimum acceptable value that is constrained 

by the value_range. 

4.3.117 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 

Description 



4.3.118 via 

A via is a type of plated_passage. Via is defined in IEC 60050-541. 


4.3.119 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. 





4.4 Implementation steps and functional scope 

The following in Figure 17 depicted three functional scopes have been defined to support the different steps: 

Figure 17: 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. 


81


4.5 Mapping logic 

4.5.1 Package 1: item definition and product structure 

The mapping in Package 1 is shown in Figure 18 below. 

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 EDMD schema 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. 



Figure 18: Mapping in Package 1 

83 

84


4.5.2 Package 2: item classification and grouping 


Figure 19: Mapping classification and grouping mechanisms 

EDMDSchema offers only one grouping mechanism, EDMDGroup. The classification mechanism EDMDGeneralClassification is derived 

from EDMDGroup. 




4.5.3 Package 3: person and organization information 


Figure 20: 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. 


86


4.5.4 Package 4: ECAD shape information 


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. 



Figure 21: Mapping the shape information 

88 

89


4.5.5 Package 5: constraint definition 


Figure 22: 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. 

4.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. 





91 

92





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. 

4.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. 





94 

95


4.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. 4.6.6). 

The basic concepts on which the data model is based are described below. 

4.6.1 Concept of the “item” 

The item is the basic element for describing the product, see Figure 26: 

Figure 26: 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 27: 

Figure 27: Item data 


97


4.6.2 Concept of the designator within the context of the system 

The designator is linked with the object as an aggregation, see Figure 28: 

Figure 28: 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 29 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 

o The 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 29: 

Figure 29: Designator data 

Please note: 

Item in a collaboration session have to contain at least two identifiers, one for each collaborating system. 


99


4.6.3 Limitations on properties, user-defined properties 

Classes for representing limited properties and user-defined properties are shown in Figure 30: 

Figure 30: 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 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. 




4.6.4 The geometry model, shape of an item 

Basic elements for describing the shape of an item are shown in Figure 31: 

Figure 31: 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). 


101


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 32: 



Figure 32: CurveSet2d 

103 

104


4.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 33: 

Figure 33: 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. 




4.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/edmd/1.0/administration 

• http://www.prostep.org/edmd/1.0/annotation 

• http://www.prostep.org/edmd/1.0/computational 

• http://www.prostep.org/edmd/1.0/external 

• http://www.prostep.org/edmd/1.0/foundation 

• http://www.prostep.org/edmd/1.0/geometry.d2 

• http://www.prostep.org/edmd/1.0/grouping 

• http://www.prostep.org/edmd/1.0/material 

• http://www.prostep.org/edmd/1.0/pdm 

• http://www.prostep.org/edmd/1.0/property 

• http://www.prostep.org/edmd/1.0/text 

The WSDL is described in the namespace: 

• http://www.prostep.org/edmd/0.1/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 xml schemas of the informational model, each with simple annotation as text or with annotations as embedded XHTML: 

• [html|plain]/administration.xsd 

• [html|plain]/annotation.xsd 

• [html|plain]/external.xsd 

• [html|plain]/foundation.xsd 

• [html|plain]/geometry.d2.xsd 

• [html|plain]/grouping.xsd 

• [html|plain]/material.xsd 

• [html|plain]/pdm.xsd 

• [html|plain]/property.xsd 

• [html|plain]/text.xsd 

The wsdl and schema of the computational model: 

• EDMDService.wsdl 

• [html|plain]/computational.xsd 

Sample data 

• sample/pattern.xml 

• 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. 


106


4.6.7 Package EDMDSchema.foundation 

This package (cp. Figure 34) describes the contents of the namespace: 

http://www.prostep.org/edmd/1.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 34: Overview of foundation Package 

108 

109


4.6.8 Package EDMDSchema.property 


http://www.prostep.org/edmd/1.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 35: Over view of property Package 

111 

112


4.6.9 Package EDMDSchema.administration 


http://www.prostep.org/edmd/1.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 but released as a html document. 

Figure 36: Overview of administration Package 

4.6.10 Package EDMDSchema.pdm 


http://www.prostep.org/edmd/1.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 





Figure 37: Overview of pdm Package 

114 

115


4.6.11 Package EDMDSchema.material 


http://www.prostep.org/edmd/1.0/material 

It contains object types and relation types for describing materials. Future extensions are planned. For more details about the 


Recommendation but released as a html document. 

Figure 38: Overview of material Package 

4.6.12 Package EDMDSchema.d2 

This package describes the contents of the namespace: 

http://www.prostep.org/edmd/1.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. 

4.6.13 Package EDMDSchema.external 


http://www.prostep.org/edmd/1.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 


Figure 39: Overview of external Package 




4.6.14 Package EDMDSchema.grouping 


http://www.prostep.org/edmd/1.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 40: Overview of grouping Package 


117


4.6.15 Package EDMDSchema.annotation 


http://www.prostep.org/edmd/1.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 41: Overview of annotation Package 




4.6.16 Package EDMDSchema.text 


http://www.prostep.org/edmd/1.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 42: Overview of text Package 


119


4.6.17 Package EDMDSchema.computational 


http://www.prostep.org/edmd/1.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 43: Over view of computational Package 

121 

122

5 EDMD PROTOCOL ProSTEP iViP Recommendation 

5 EDMD protocol 

The EDMD protocol is based on the implementation-driven data model (section 4.5.1) and serves to transfer change information 

between the systems involved. 

5.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 44). The subject of this Recommendation is the 1:1 

configuration. 

Figure 44: 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. 



5 EDMD PROTOCOL 

5.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. 

5.2.2 SendInformation message 

In Figure 45 the message "SendInformation" is shown: 

Figure 45: 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. 


124


5.2.3 SendChanges message 

In Figure 46 the message "SendChanges" is shown: 

Figure 46: 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. 

5.2.4 RequestForInformation message 

In Figure 47 the message "RequestForInformation " is shown: 

Figure 47: 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. 




5.2.5 ServiceResult class 

In Figure 48 the class " 5.2.5 ServiceResult " is shown: 

Figure 48: ServiceResult class 

The ServiceResult class describes errors that can occur during the processing of messages. 


126


5.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 informations 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 49: 

Figure 49: 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 50: 

Figure 50: 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. 


128


5.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) 

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. 

5.4.2 SendInformation 

When processing a message of the type SendInformation, the items in the message are processed one after the other (cp. Figure 

51, Figure 52): 

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 

Please 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. 


130


Figure 51: Processing SendInformation (1 of 2) 




Figure 52: Processing SendInformation (2 of 2) 


132


5.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. 

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 53, Figure 54, Figure 55). 

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 


134


Figure 53: Processing SendChanges (1 of 3) 






136





6 ANNEX A · ANNEX B 

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 (PSI_PSI5_EDMD-Schema_1.0_HTML.zip, available at www.prostep.org/en/downloads). The page 

index.html is the entry point. 

Annex B: EDMDSchema 

EDMDSchema is supplied in the separated zip-archive (PSI_PSI5_EDMD-Schema_1.0.zip, available at www.prostep.org/en/ 

downloads). This archive contains the xsd-schemas of the informational model, each with simple annotation as text or with 

annotations as embedded XHTML: 

• [html|plain]/administration.xsd 

• [html|plain]/annotation.xsd 

• [html|plain]/external.xsd 

• [html|plain]/foundation.xsd 

• [html|plain]/geometry.d2.xsd 

• [html|plain]/grouping.xsd 

• [html|plain]/material.xsd 

• [html|plain]/pdm.xsd 

• [html|plain]/property.xsd 

• [html|plain]/text.xsd 

The wsdl and schema of the computational model: 

• EDMDService.wsdl 

• [html|plain]/computational.xsd 

Sample data 

• sample/pattern.xml 

• sample/pattern.idx 

• sample/UserProperties.idx 

• sample/Systems.idx 

• sample/vcard.xsd 

• sample/xlink.xsd 


138

ProSTEP iViP Association 

Dolivostraße 11 

64293 Darmstadt 

Germany 

Tel. +49-6151-9287-336 

Fax +49-6151-9287-326 

psev@prostep.com 

www.prostep.org 

ISBN 978-3-9811864-7-5 

Version 1.0, April 2008

ECAD/MCAD Collaboration ECAD/MCAD ... - ProSTEP iViP

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?