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

ProSTEP iViP Recommendation

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 ([email protected]) 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

ProSTEP iViP Recommendation

Table of Contents 1 Introduction 1.1 Preface 1.2 Objectives of ECAD/MCAD collaboration 1.3 Structure of the Recommendation 2 General Requirements 2.1 Shortening the iteration cycles between ECAD and MCAD development processes 2.2 Working in the native system 2.3 Separate collaboration environment 2.4 Asynchronous and synchronous collaboration 2.5 Means of communication parallel to collaboration 2.6 Support for different forms of representation 2.7 Cardinality of collaboration 2.8 Initiating collaboration 3 Use cases 3.1 Standardized use case description 3.2 Actors within the use cases 3.3 Defining a board baseline 3.4 Placement under mechanical constraints 3.5 Placement under electrical constraints 3.6 Change of board components 3.7 Change of placement locations 3.8 Replacement of components 3.9 Panelization design review 4 EDMD data model 4.1 Overview 4.2 Packages in the user-driven data model 4.2.1 Package 1: item definition and product structure 4.2.2 Package 2: item classification and grouping 4.2.3 Package 3: person and organization information 4.2.4 Package 4: ECAD shape information 4.2.5 Package 5: constraint definition 4.2.6 Package 6: property and material definition 4.2.7 Package 7: 2d geometry model 4.2.8 Package 8: shape dependant information 4.2.9 Package 9: 3d geometry model 4.3 Objects 4.3.1 annotation 4.3.2 assembly_component 4.3.3 assembly_component_relationship 4.3.4 assembly_definition 4.3.5 assembly_group_component 4.3.6 b_rep_model 4.3.7 b_spline_curve 4.3.8 cartesian_coordinate_space 4.3.9 cartesian_coordinate_space_2d 4.3.10 cartesian_coordinate_space_3d 4.3.11 cartesian_point 4.3.12 centre_of_mass

IV

10 10 10 11 12 12 12 14 15 15 15 16 17 18 18 19 20 21 23 25 26 28 30 32 32 35 35 38 39 40 43 43 46 49 52 53 53 53 53 53 53 54 54 54 54 54 54 55

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

ProSTEP iViP Recommendation

4.3.13 4.3.14 4.3.15 4.3.16 4.3.17 4.3.18 4.3.19 4.3.20 4.3.21 4.3.22 4.3.23 4.3.24 4.3.25 4.3.26 4.3.27 4.3.28 4.3.29 4.3.30 4.3.31 4.3.32 4.3.33 4.3.34 4.3.35 4.3.36 4.3.37 4.3.38 4.3.39 4.3.40 4.3.41 4.3.42 4.3.43 4.3.44 4.3.45 4.3.46 4.3.47 4.3.48 4.3.49 4.3.50 4.3.51 4.3.52 4.3.53 4.3.54 4.3.55 4.3.56 4.3.57 4.3.58 4.3.59 4.3.60 4.3.61 4.3.62

circle classification_association classification_attribute collaboration_definition component_termination_passage component_termination_passage_template_interface_terminal component_termination_passage_template_join_terminal component_termination_passage_template_terminal composite_curve constraint curve curve_on_surface curve_set_2d cutout Cutout_edge_segment data_environment definition_based_product_occurrence design_discipline_item_definition design_layer_stratum design_layer_technology detailed_geometric_model_element digital_file documentation_layer_stratum documentation_layer_technology ellipse external_geometric_model external_geometric_model_with_parameters external_model feature_parameter filled_via general_classification general_parameter general_property general_shape_dependent_property geometric_model geometric_model_relationship_with_transformation hybrid_geometric_model_3D hyperbola instance_placement inter_stratum_feature interconnect_module_constraint_region item item_contraint item_definition_instance_relationship item_instance item_property_association item_shape item_version laminate_component line

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

TABLE OF CONTENTS

55 55 56 56 56 56 56 57 57 57 57 58 58 58 58 58 59 59 59 59 59 60 60 60 60 60 61 61 61 61 62 62 62 63 63 63 64 64 64 64 65 65 66 66 66 66 67 67 67 67

V

TABLE OF CONTENTS

4.3.63 material 4.3.64 material_property 4.3.65 material_property_association 4.3.66 material_property_value_representation 4.3.67 moments_of_inertia 4.3.68 next_higher_assembly 4.3.69 non_features_shape_element 4.3.70 numerical_value 4.3.71 offset_curve 4.3.72 organization 4.3.73 parabola 4.3.74 part_feature 4.3.75 part_mounting_feature 4.3.76 partially_plated_cutout 4.3.77 person 4.3.78 person_in_organization 4.3.79 person_organization_assignment 4.3.80 physical_connectivity_interrupting_cutout 4.3.81 plated_cutout 4.3.82 plated_cutout_edge_segment 4.3.83 plated_inter_stratum_feature 4.3.84 plated_passage 4.3.85 point 4.3.86 point_on_curve 4.3.87 point_on_surface 4.3.88 polyline 4.3.89 printed_part_template_terminal 4.3.90 printed_part_cross_section_template_terminal 4.3.91 printed_part_template_interface_terminal 4.3.92 printed_part_template_join_terminal 4.3.93 printed_part_template_terminal 4.3.94 property 4.3.95 property_value 4.3.96 property_value_association 4.3.97 property_value_representation 4.3.98 property_constraint 4.3.99 shape_dependent_property 4.3.100 shape_description 4.3.101 shape_element 4.3.102 shape_feature 4.3.103 single_instance 4.3.104 stratum 4.3.105 stratum_feature_template_component 4.3.106 stratum_technology 4.3.107 structured_printed_part_template_terminal 4.3.108 thermal_component 4.3.109 transformation 4.3.110 transformation_2d 4.3.111 transformation_3d 4.3.112 trimmed_curve 4.3.113 unit

VI

ProSTEP iViP Recommendation

68 68 68 68 68 69 69 69 69 70 70 70 70 70 71 71 71 72 72 72 72 72 73 73 73 73 74 74 74 74 74 74 75 75 75 76 76 76 76 76 77 77 77 77 78 78 78 78 78 78 79

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

ProSTEP iViP Recommendation

4.3.114 unsupported_passage 4.3.115 value_limit 4.3.116 value_range 4.3.117 value_with_unit 4.3.118 via 4.3.119 wireframe_model_2d 4.4 Implementation steps and functional scope 4.5 Mapping logic 4.5.1 Package 1: item definition and product structure 4.5.2 Package 2: item classification and grouping 4.5.3 Package 3: person and organization information 4.5.4 Package 4: ECAD shape information 4.5.5 Package 5: constraint definition 4.5.6 Package 6: property and material definition 4.5.7 Package 7: 2d geometry model 4.5.8 Package 8: shape dependant information 4.5.9 Package 9: 3d geometry model 4.6 Implementation-driven data model (EDMDSchema) 4.6.1 Concept of the “item” 4.6.2 Concept of the designator within the context of the system 4.6.3 Limitations on properties, user-defined properties 4.6.4 The geometry model, shape of an item 4.6.5 Roles 4.6.6 General information 4.6.7 Package EDMDSchema.foundation 4.6.8 Package EDMDSchema.property 4.6.9 Package EDMDSchema.administration 4.6.10 Package EDMDSchema.pdm 4.6.11 Package EDMDSchema.material 4.6.12 Package EDMDSchema.d2 4.6.13 Package EDMDSchema.external 4.6.14 Package EDMDSchema.grouping 4.6.15 Package EDMDSchema.annotation 4.6.16 Package EDMDSchema.text 4.6.17 Package EDMDSchema.computational 5 EDMD protocol 5.1 General information 5.2 Messages 5.2.1 General information 5.2.2 SendInformation message 5.2.3 SendChanges message 5.2.4 RequestForInformation message 5.2.5 ServiceResult class 5.3 Protocol 5.3.1 General information 5.4 Processing rules 5.4.1 General information 5.4.2 SendInformation 5.4.3 SendChanges Annex A: Packages EDMDSchema Annex B: EDMDSchema

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

TABLE OF CONTENTS

79 79 80 80 80 80 81 82 82 85 86 87 90 90 93 93 93 96 96 98 100 101 105 106 107 110 113 113 116 116 116 117 118 119 120 123 123 124 124 124 125 125 126 127 127 129 129 129 133 137 137

VII

FIGURES

ProSTEP iViP Recommendation

Figures Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

VIII

1: Collaboration model embedded in native ECAD/MCAD systems 2: Options for integrating the collaboration modules 3: Collaboration module and communication with the native system using ECAD as an example 4: Configuration of collaboration control 5: Dependencies between the use cases 6: Roles and actors within ECAD/MCAD collaboration 7: Overview of the application-driven data model 8: Overview of the “item definition and product structure” Package 9: Overview of the “item classification and grouping” Package 10: Overview of the “person and organization information” Package 11: Overview of the “ECAD shape information” Package 12: Overview of the “constraint definition” Package 13: Overview of the “property and material definition” Package 14: Overview of the “2d geometry model” Package 15: Overview of the “shape dependant information” Package 16: Overview of the “3d geometry model” Package 17: Implementation steps 18: Mapping in Package 1 19: Mapping classification and grouping mechanisms 20: Mapping the organizational units and roles 21: Mapping the shape information 22: Mapping the constraints 23: Mapping in Package 6 24: Mapping in Package 7 25: Mapping in Package 8 26: Item model 27: Item data 28: Designator model 29: Designator data 30: UserProperties model 31: Shape model 32: CurveSet2d 33: Roles 34: Overview of foundation Package 35: Over view of property Package 36: Overview of administration Package 37: Overview of pdm Package 38: Overview of material Package 39: Overview of external Package 40: Overview of grouping Package 41: Overview of annotation Package 42: Overview of text Package 43: Over view of computational Package 44: Types of communication 45: SendInformation message 46: SendChanges message 47: RequestInformation message 48: ServiceResult class

11 13 14 16 18 19 33 36 38 39 41 43 44 47 50 52 81 83 85 86 88 90 91 93 94 96 97 98 99 100 101 103 105 108 111 113 114 116 116 117 118 119 121 123 124 125 125 126

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

ProSTEP iViP Recommendation

Figure Figure Figure Figure Figure Figure Figure

49: 50: 51: 52: 53: 54: 55:

SendChanges RequestForInformation Processing SendInformation (1 of 2) Processing SendInformation (2 of 2) Processing SendChanges (1 of 3) Processing SendChanges (2 of 3) Processing SendChanges (3 of 3)

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

FIGURES

127 128 131 132 135 136 137

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

ProSTEP iViP Recommendation

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.

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

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.

12

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

ProSTEP iViP Recommendation

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:

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

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

13

2 GENERAL REQUIREMENTS

ProSTEP iViP Recommendation

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:

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

14

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

ProSTEP iViP Recommendation

2 GENERAL REQUIREMENTS

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. This gives rise to the following requirement:

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

Requirement 5: 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:

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

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

15

2 GENERAL REQUIREMENTS

ProSTEP iViP Recommendation

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

This gives rise to the following requirement:

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

16

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

ProSTEP iViP Recommendation

2 GENERAL REQUIREMENTS

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.

Requirement 8: 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.

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

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 Aim Actors Preconditions

described according to the following schema: A brief description (short sentence) of the use case and its aim Main human and machine entities and their roles 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

18

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

ProSTEP iViP Recommendation

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.

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

19

3 USE CASES

ProSTEP iViP Recommendation

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.

20

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

ProSTEP iViP Recommendation

3 USE CASES

Diagram

Benefits

The use of ECAD/MCAD collaboration simplifies the initial transfer of a board baseline considerably since no time-consuming transfers via interfaces such as, for example, IDF are required. The common data model means that both domains can access identical information. The initial transfer of the baseline for the PCB is the starting point for all subsequent collaboration scenarios described in the following use cases.

Notes

No additional notes

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.

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

21

3 USE CASES

Preconditions

ProSTEP iViP Recommendation

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.

22

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

ProSTEP iViP Recommendation

3 USE CASES

Diagram

Benefits

The use of an ECAD/MCAD collaboration can significantly reduce the time needed for the iterative process. The common data model allows for a common language in both system environments. This means that changes in one environment can be transferred in a standardized manner to the other environment and interpreted there.

Notes

No additional notes

3.5 Placement under electrical constraints Aim

Placing electrical components on the PCB subject to electrical constraints stipulated by the schematic. This use case is initiated from the ECAD domain.

Actors

Electrical layouter: Designs the PCB layout in the ECAD layout system. ECAD layout system: The components are placed on the PCB in the ECAD system. Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system and defines requirements concerning the board outline. 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.

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

23

3 USE CASES

Preconditions

ProSTEP iViP Recommendation

From an electrical point of view, the schematic design must be concluded before the components can be placed. The result of the schematic is the netlist, which describes how the electrical components are connected. PCB layout is started on the basis of this netlist, i.e. placement of the components based on the electrical constraints. An additional precondition is that the initial board baseline has been transferred and is available in both domains in a synchronized status.

Description

Based on the initial board baseline, the electrical layouter starts the collaboration process in order to transfer the placement of the electrical components to the mechanical designer. The electrical layouter has created his components based on the schematic. Once this has been completed, iteration between MCAD and ECAD begins if the components placed by the electrical layouter have to be moved due to mechanical constraints because, for example, the electrical components collide with the housing. In the iterative process, the mechanical designer can check whether the placed components violate mechanical constraints. Agreement can be achieved very quickly and efficiently within the framework of ECAD/MCAD collaboration 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

24

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

ProSTEP iViP Recommendation

3 USE CASES

Benefits

The use of an ECAD/MCAD collaboration can significantly reduce the time needed for the iterative process. The common data model allows for a common language in both system environments. This means that changes in one environment can be transferred in a standardized manner to the other environment and interpreted there.

Notes

No additional notes

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

Electrical layouter: Designs the PCB layout in the ECAD layout system. ECAD layout system: The components are placed on the PCB in the ECAD system. Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system and defines requirements concerning the board outline 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

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

Description

Based on the initial board baseline, the electrical layouter or the mechanical designer starts the 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. Agreement can be achieved very quickly and efficiently within the framework of ECAD/MCAD collaboration since both users can compare the impact with the rules of their native systems.

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.

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

25

3 USE CASES

ProSTEP iViP Recommendation

Diagram

Benefits

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

Notes

No additional notes

3.7 Change of placement locations Aim

Components which have already been placed and harmonized within the collaboration framework are to 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

Electrical layouter: Designs the PCB layout in the ECAD layout system. ECAD layout system: The components are placed on the PCB in the ECAD system. Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system and defines requirements concerning the board outline. 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

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

Description

Based on the initial board baseline, the electrical layouter or the mechanical designer starts the collaboration process because changes relating to the placement of the components on the PCB have arisen. For example, the mechanical designer has detected collisions with the housing or the electrical layouter has realized that a certain wiring of the components does not fulfill the requirements.

26

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

ProSTEP iViP Recommendation

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. Within the collaboration, both the mechanical designer and the electrical layouter now check together what impact the new placement of the component has on the existing PCB layout. Agreement can be achieved very quickly and efficiently within the framework of ECAD/MCAD collaboration since both users can compare the impact with the rules of their native systems. 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

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

Notes

No additional notes

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

27

3 USE CASES

ProSTEP iViP Recommendation

3.8 Replacement of components Aim

Components which have already been placed and harmonized within the collaboration framework are to 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

Electrical layouter: Designs the PCB layout in the ECAD layout system. ECAD layout system: The components are placed on the PCB in the ECAD system. Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system and defines requirements concerning the board outline 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

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

Description

Based on the initial board baseline, the electrical layouter or the mechanical designer starts the collaboration 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. Within the collaboration, both the mechanical designer and the electrical layouter now check together what impact the replaced component has on the existing PCB layout. Agreement can be achieved very quickly and efficiently within the framework of ECAD/MCAD collaboration since both users can compare the impact with the rules of their native systems.

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.

28

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

ProSTEP iViP Recommendation

3 USE CASES

Diagram

Benefits

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

Notes

No additional notes

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

29

3 USE CASES

ProSTEP iViP Recommendation

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

Electrical layouter: Designs the PCB layout in the ECAD layout system. Mechanical designer: Designs the surrounding geometry in the mechanical 3D CAD system and defines requirements concerning the board outline. 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. ECAD layout system: The components are placed on the PCB in the ECAD system. 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

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

Description

The electrical layouter, mechanical designer, manufacturing or process engineer and, if necessary, other persons must be involved in the design review since not only technical constraints but also commercial constraints have to be taken into consideration. Once the initial PWB profile for manufacturing the PCB has been created, the above-mentioned persons should come to an agreement in order to find the best solution – and not only from an electrical point of view. In the collaboration, answers can be found to questions such as, for example, where can symmetries be utilized or what tolerances have to be observed in the manufacturing process?

30

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

ProSTEP iViP Recommendation

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

The use of an ECAD/MCAD collaboration can significantly reduce the time needed to reach agreement up to and including the manufacturing processes.

Notes

No additional notes

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

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.

32

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 7: Overview of the application-driven data model

33

34

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

35

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

36

37

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

Application example: All the LED displays (represented by item objects) on a PCB can be grouped together by means of a classification (general_classification). The following objects are defined in this package: classification_association, general_classification, classification_attribute

38

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

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

Application example: 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. The following objects are defined in this package: organization, person_organization_assignment, person, person_in_organization

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

39

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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). The following objects are defined in this package: non_feature_shape_element, interconnect_module_constraint_region, shape_feature, component_termination_passage_template_terminal, component_termination_passage_template_join_terminal, component_termination_passage_template_interface_terminal, printed_part_template_terminal, printed_part_cross_section_template_terminal, printed_part_template_interface_terminal, printed_part_template_terminal, printed_part_template_join_terminal, part_feature_ part_mounting_feature, assembly_component, definition_based_product_occurence, thermal_component, assembly_group_component, laminate_component, 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

40

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

41

42

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

Application example: 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. The following objects are defined in this package: 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.

Application example: 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.". The following objects are defined in this package: 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

43

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

44

45

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

Application example: 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. The following objects are defined in this package: 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

46

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

47

48

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. The following objects are defined in this package: 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

49

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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

50

51

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.2.9 Package 9: 3d geometry model 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

The following objects are defined in this package: b_rep_model, hybrid_geometric_model_3d

52

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. This object type has no attributes. 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. This object type has no attributes. 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

Description

id

The id specifies the identifier of the design_discipline_item_definition.

name

The name specifies the name of the design_discipline_item_definition.

assembly_type

The assembly_type specifies the kind of the assembly_definition. Note: "functional assembly" or "design assembly" are examples of an assembly_type.

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. This object type has no attributes.

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

53

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. This object type has no attributes. 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: Attribute name

Description

name

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. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes.

54

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

name

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

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: Attribute name

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: Attribute name

Description

name

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

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: Attribute name

Description

role

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

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

55

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

id

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

name

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

description

The description specifies additional information about the classification_attribute.

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: Attribute name

Description

id

The id specifies the identifier of the design_discipline_item_definition.

name

The name specifies a name of the design_discipline_item_definition.

description

The collaboration_type specifies the kind of collaboration. The collaboration_type could be for example "moving of a mounting hole" or "placement under mechanical constraints".

4.3.17 component_termination_passage A component_termination_passage is a type of plated_passage through which a component_terminal may pass. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes.

56

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.3.20 component_termination_passage_template_terminal A component_termination_passage_template_terminal is a type of Shape_feature. This object type has no attributes. 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: Attribute name

Description

name

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

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: Attribute name

Description

id

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

name

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

constraint_type

The following values are recommended to use for the constraint_type: relating (e.g. to move parts together), placement (e.g. for clearance), or rotation (for rotation of elements).

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: Attribute name

Description

name

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

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

57

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

name

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

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. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes. 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: Attribute name

Description

description

The description specifies additional information about the data_environment.

environment_name

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

58

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. This object type has no attributes. 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: Attribute name

Description

id

The id specifies the identifier of the design_discipline_item_definition.

name

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. This object type has no attributes. 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. This object type has no attributes. 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: Attribute name

Description

name

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

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

59

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.3.34 digital_file A digital_file contains computer interpretable data stored in a physical file within the filesystem. This object type has no attributes. 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 This object type has no attributes. 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. This object type has no attributes. 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: Attribute name

Description

name

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

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: Attribute name

Description

model_id

The model_id specifies the identifier of the external_model.

description

The description specifies additional information about the external_model.

60

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

model_id

The model_id specifies the identifier of the external_model.

description

The description specifies additional information about the 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: Attribute name

Description

model_id

The model_id specifies the identifier of the external_model.

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: Attribute name

Description

parameter_name

The parameter_name specifies the character, abbreviation, or word by which the feature_parameter is referred to. Note "a", "b1", or "r" are typical examples for the parameter_name.

4.3.42 filled_via A filled_via is a type of via. This object type has no attributes.

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

61

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

id

The id specifies the identifier of the general_classification.

description

The description specifies additional information about the general_classification.

version_id

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

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: Attribute name

Description

parameter_role

The parameter_role specifies the kind of parameter that is represented by the general_parameter. Note "width" or "diameter" are examples for the parameter_role.

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: Attribute name

Description

description

The description specifies additional information about the property.

id

The id specifies the identifier of the property.

version_id

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

property_type

The property_type specifies the kind of property the general_property defines.

62

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

description

The description specifies additional information about the property_value of the shape_dependent_property.

property_type

The property_type defines the type of characteristic that is specified for an object.

property_value

The property_value specifies the value that is given for a particular characteristic.

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). This object type has no attributes. 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. This object type has no attributes.

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

63

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. This object type has no attributes. 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: Attribute name

Description

name

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

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. This object type has no attributes. 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: Attribute name

Description

feature of size

Specifies whether or not the inter_stratum_feature interfaces with a feature of another product in an assembly context. A value of TRUE specifies that it interfaces. A value of FALSE specifies that it does not interface.

vertical_extent

64

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

keepout

Specifies if the meaning of the interconnect_module_constraint_region is to describe that items shall be in the interior of the element_shape or shall be on the exterior of the element_shape. The value of TRUE states that objects in the constrained_design_object_category are not to be within the element_shape. The value of FALSE states that objects in the constrained_design_object_category are to be only within the element_shape.

constrained_design_object_category

Specifies object categories for the interconnect_module_constraint_region. The names shall be interpreted as the identification of Application Object categories to be constrained.

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. The following table shows the attributes of an item: Attribute name

Description

id

The id specifies the identifier of the item. For the id, an owner must be specified by a person_organization_assignment with role "id owner". The id must be unique within the scope of the organization that is specified by the person_organization_assignment.

name

The name specifies the name of the item.

description

The description specifies additional information about the item.

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

65

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. The following table shows the attributes of an item: Attribute name

Description

id

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

name

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

constraint_type

The following values are recommended to use for the constraint_type: relating (e.g. to move parts together), placement (e.g. for clearance), or rotation (for rotation of elements).

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. This object type has no attributes. 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: Attribute name

Description

description

The description specifies additional information about the item_instance.

id

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. This object type has no attributes.

66

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

described_object

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: Attribute name

Description

id

The id specifies the identifier of the item_version. The id must be unique within the scope of the associated item. A particular object is identified by the id of the item_version.

description

The description specifies additional information about the item_version.

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. This object type has no attributes. 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: Attribute name

Description

name

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

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

67

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

material_name

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: Attribute name

Description

description

The description specifies additional information about the property.

id

The id specifies the identifier of the property.

version_id

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

property_name

The property_name specifies the kind of material_property. Note: 'EM1' is an example for a "property_name" that may be associated with a material_property that is described as 'elastic modulus'.

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. This object type has no attributes. 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. This object type has no attributes. 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: Attribute name

Description

description

The description specifies additional information about the property_value.

68

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. This object type has no attributes. 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. This object type has no attributes. 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: Attribute name

Description

value_name

The value_name specifies the name by which the property_value is referred to. Note: "l1" or "vol2" are examples for the value_name of a Property_value.

value_component

The value_component specifies the quantity of the numerical_value.

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: Attribute name

Description

name

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

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

69

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

organization_name

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

id

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: Attribute name

Description

name

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

4.3.74 part_feature A part_feature is a type of shape_feature. The following table shows the attributes of a part_feature: Attribute name

Description

material_state_change

Specifies whether the material state change for the part_feature is due to addition of material or due to removal of material.

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. This object type has no attributes. 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. This object type has no attributes.

70

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

person_name

The person_name specifies the name used to refer to the Person. Note: The person_name includes the first, middle, and last names as well as titles, if applicable.

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: Attribute name

Description

role

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

location

The location specifies the relevant address of the person_in_organization.

id

The id specifies an identifier of the person. The identifier must be unique within the scope of the "associated_organization". Note: The id may be a staff number or a user id in a computer system.

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.

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

71

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

role

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. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes.

72

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

name

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

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: Attribute name

Description

name

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

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: Attribute name

Description

name

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

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: Attribute name

Description

name

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

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

73

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes. 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: Attribute name

Description

description

The description specifies additional information about the property.

id

The id specifies the identifier of the property.

version_id

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

74

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

value_name

The value_name specifies the name by which the property_value is referred to. Note: "l1" or "vol2" are examples for the value_name of a property_value.

4.3.96 property_value_association A property_value_association is a mechanism to assign a property_value_representation to an object. This object type has no attributes. 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: Attribute name

Description

value_determination

The value_determination specifies information on how the property_value_representation must be interpreted.

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

75

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

id

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

name

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

constraint_type

The 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: Attribute name

Description

description

The description specifies additional information about the shape_dependent_property.

4.3.100 shape_description A shape_description is either a geometric_model or a external_geometric_model. This object type has no attributes. 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. This object type has no attributes. 4.3.102 shape_feature A shape_feature is a type of shape_element. This object type has no attributes.

76

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

description

The description specifies additional information about the item_instance.

id

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. The following table shows the attributes of an single_instance: Attribute name

Description

id

The identifier that distinguishes the stratum.

of_technology

Specifies a role of the stratum_technology for the stratum.

stratum_surface_designation

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

4.3.105 stratum_feature_template_component A stratum_feature_template_component is a type of inter_stratum_feature. This object type has no attributes. 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. The following table shows the attributes of an single_instance: Attribute name

Description

name

The words by which the stratum_technology is known. Specifies the alphanumeric identifier of a stratum_technology.

layer_position

Specifies one of the layer_position_types of the stratum for the stratum_technology. Primary and secondary shall only be used if the member of stratum_technology is a design_layer_technology.

id

Unique identifier.

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

77

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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. This object type has no attributes. 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. This object type has no attributes. 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 This object type has no attributes. 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. This object type has no attributes. 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. This object type has no attributes. 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: Attribute name

Description

name

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

78

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

unit_name

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. This object type has no attributes. 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: Attribute name

Description

value_name

The value_name specifies the name by which the property_value is referred to.

limit

The limit specifies the value of the limit.

limit_qualifier

The limit_qualifier specifies the kind of limit. The following values must be used: "maximum": The specified limit is an upper limit; "minimum": The specified limit is a lower limit.

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

79

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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: Attribute name

Description

value_name

The value_name specifies the name by which the property_value is referred to.

upper_limit

The upper_limit specifies the maximum acceptable value that is constrained by the value_range.

lower_limit

The lower_limit specifies the minimum acceptable value that is constrained by the value_range.

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: Attribute name

Description

value_name

The value_name specifies the name by which the property_value is referred to.

4.3.118 via A via is a type of plated_passage. Via is defined in IEC 60050-541. This object type has no attributes. 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. This object type has no attributes.

80

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

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.

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

81

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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.

82

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 18: Mapping in Package 1

83

84

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.5.2 Package 2: item classification and grouping The mapping in Package 2 is shown in Figure 19 below.

Figure 19: Mapping classification and grouping mechanisms

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

85

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

4.5.3 Package 3: person and organization information The mapping in Package 3 is shown in Figure 20 below.

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.

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

86

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.5.4 Package 4: ECAD shape information The mapping in Package 1 is shown in Figure 21 below. 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.

87

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 21: Mapping the shape information

88

89

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.5.5 Package 5: constraint definition The mapping in Package 1 is shown in Figure 22 below.

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 The mapping in Package 6 is shown in Figure 23 below.

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.

90

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 23: Mapping in Package 6

91

92

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.5.7 Package 7: 2d geometry model The mapping in Package 7 is shown in Figure 24 below.

Figure 24: Mapping in Package 7

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 The mapping in Package 8 is shown in Figure 25 below.

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). 4.5.9 Package 9: 3d geometry model Since there are only two mechanisms for describing item shape in EDMDSchema a special mapping of this package is not needed.

93

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 25: Mapping in Package 8

94

95

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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.

96

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

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

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

97

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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.

98

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

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

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

99

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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.

100

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

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

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

101

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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:

102

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 32: CurveSet2d

103

104

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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.

105

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

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.

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

106

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

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.

107

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 34: Overview of foundation Package

108

109

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.6.8 Package EDMDSchema.property This package (cp. Figure 35) describes the contents of the namespace: 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.

110

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 35: Over view of property Package

111

112

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.6.9 Package EDMDSchema.administration This package (cp. Figure 36) describes the contents of the namespace: 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 This package (cp. Figure 37) describes the contents of the namespace: 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 but released as a html document.

113

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

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

Figure 37: Overview of pdm Package

114

115

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.6.11 Package EDMDSchema.material This package (cp. Figure 38) describes the contents of the namespace: 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 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 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 This package (cp. Figure 39) describes the contents of the namespace: 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 Recommendation but released as a html document.

Figure 39: Overview of external Package

116

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

4.6.14 Package EDMDSchema.grouping This package (cp. Figure 40) describes the contents of the namespace: 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

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

117

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.6.15 Package EDMDSchema.annotation This package (cp. Figure 41) describes the contents of the namespace: 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

118

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

ProSTEP iViP Recommendation

4 EDMD DATA MODEL

4.6.16 Package EDMDSchema.text This package (cp. Figure 42) describes the contents of the namespace: 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 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 42: Overview of text Package

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

119

4 EDMD DATA MODEL

ProSTEP iViP Recommendation

4.6.17 Package EDMDSchema.computational This package (cp. Figure 43) describes the contents of the namespace: 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 but released as a html document.

120

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

4 EDMD DATA MODEL

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

123

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

ProSTEP iViP Recommendation

5 EDMD PROTOCOL

5.2 Messages 5.2.1 General information 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.

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

124

5 EDMD PROTOCOL

ProSTEP iViP Recommendation

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.

125

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

ProSTEP iViP Recommendation

5 EDMD PROTOCOL

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.

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

126

5 EDMD PROTOCOL

ProSTEP iViP Recommendation

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.

5.3.1 General information 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.

127

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

ProSTEP iViP Recommendation

5 EDMD PROTOCOL

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.

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

128

5 EDMD PROTOCOL

ProSTEP iViP Recommendation

5.4 Processing rules 5.4.1 General information 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.

129

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

ProSTEP iViP Recommendation

5 EDMD PROTOCOL

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.

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

130

5 EDMD PROTOCOL

ProSTEP iViP Recommendation

Figure 51: Processing SendInformation (1 of 2)

131

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

ProSTEP iViP Recommendation

5 EDMD PROTOCOL

Figure 52: Processing SendInformation (2 of 2)

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

132

5 EDMD PROTOCOL

ProSTEP iViP Recommendation

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.

133

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

ProSTEP iViP Recommendation

5 EDMD PROTOCOL

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

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

134

5 EDMD PROTOCOL

ProSTEP iViP Recommendation

Figure 53: Processing SendChanges (1 of 3)

135

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

ProSTEP iViP Recommendation

5 EDMD PROTOCOL

Figure 54: Processing SendChanges (2 of 3)

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

136

5 EDMD PROTOCOL

ProSTEP iViP Recommendation

Figure 55: Processing SendChanges (3 of 3)

137

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

ProSTEP iViP Recommendation

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

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

138

ProSTEP iViP Association Dolivostraße 11 64293 Darmstadt Germany Tel. +49-6151-9287-336 Fax +49-6151-9287-326 [email protected] www.prostep.org ISBN 978-3-9811864-7-5 Version 1.0, April 2008