W H I T E P A P E R Z u k e n T h e P a r t n e r f o r S u c c e s s Electrical engineering data management A practical foundation for a true mechatronic data model d a t a m a n a g e m e n t z u k e n. c o m
Z u k e n T h e P a r t n e r f o r S u c c e s s Abstract The growing complexity of modern products, machines and systems calls for interdisciplinary collaboration during the early phases of the product development process (PDP). In the context of mechatronic engineering, established methods, such as managing mechanical, electrical and software development data in separate environments or repositories, and delaying their integration to a late phase of the PDP, are reaching their limitations. In order to reliably meet the objectives of today s product development programs, an efficient coordination of the work-inprogress of all involved disciplines is urgently required. Although an exchange of data and information between individual CAD-Toolsets enables a parameter exchange on a detailed design level, that alone is not sufficient from a process perspective. What is required is a comprehensive representation of all relevant information and status changes beginning from the early phases of a product development process, so that a comprehensive representation of the digital product is available at all times. With E 3.EDM, Zuken is the first vendor to supply an Engineering Data Management solution for electrotechnical and fluid engineering that provides the basis for an in-depth representation of the electrical product structure within a company-wide PLM backbone. The solution manages information in a hierarchical order within the framework of an object-oriented industry standard relational database. Mechatronic products a reality in today s engineering practice From connected vehicles to smart phones and household appliances, we are seeing rapid growth in the level of electronics and software in almost every sector. One of the most tangible results of this trend is that the mechanical components of a product increasingly tend to be looked upon as a commodity that can be easily reverse engineered and marketed as a competitive offering. In contrast, the shift of functionality into electronics and software offers much better protection of intellectual MCAD Functional Description E/E Software The complexity of modern products has led to a growing degree of specialization and fragmentation within the Product Development Process (PDP). property. It also provides the opportunity to differentiate from competitors through innovative solution approaches. The industry has adopted the term mechatronics for this new generation of highly integrated products. According to VDI, the Association of German Engineers, the term mechatronics means a synergistic interaction between the disciplines of mechanical engineering, electrical engineering and information technology for the design and manufacture of industrial products and the definition of related processes (VDI Standard 2206: Design methodology for mechatronic systems). The development of mechatronic products is exposing the industry to a number of risks and challenges that require the development and adoption of new processes and methods. In addition to the challenge of growing technical complexity, the ability to establish efficient coordination and collaboration of all involved disciplines mechanical engineering, electrical engineering and information technology is becoming crucial for success. To achieve this, an integrated product planning process is required that is capable of accommodating diverse discipline-specific methodologies, as well as continuously aligning the work-in-progress of these methodologies. 2 Optimal product development process: business and engineering processes are closely aligned
Does today s PDP meet the needs of tomorrow s mechatronic product development processes? In today s product development process, a functional description is typically specified at the outset of the lifecycle of a machine or other product. This specification is usually defined in close collaboration with the customer, and it comprehensively describes the desired functionality of a product. However, it does not necessarily specify implementation details or mappings of individual functionality to any given discipline. The required function can even be implemented in different disciplines, which in some areas will lead to a transfer of functionality from the mechanical domain into other disciplines. In a dialog between the engineering disciplines the high level specification will be broken down into different specific product structures in which individual functionality is mapped to a target item in an unambiguous way. This is where the generic functional view divides up into the specific perspectives of mechanical, electrical, fluid and automation engineering, with the results often being integrated as late as the prototype stage. To secure the success of a mechatronic product development program, it is essential to integrate all discipline-specific processes and methodologies as early as possible in the PDP. To this end the mechanical, electrical and controls sub-projects need to be continuously aligned and validated. This ensures that the mutual dependencies in change processes, as well as the derivation of options and variants, are considered in every involved discipline. To meet these objectives, two basic requirements have to be met: All development processes are conducted in a parallel within their respective disciplines. However, mutual dependencies need to be comprehensively represented. The work-in-progress baselines in the different disciplines need to be continuously aligned. Any solution approach is complicated by the fact that there are considerable differences in working practices and methodologies in the different disciplines: A mechanical design process shows fundamental differences from electrical engineering, and both are completely different from the principles adopted by agile software development methodologies, which are characterized by sprints (a set period of time during which specific work has to be completed and made ready for review). But not only do the development processes show profound differences, so do the engineering data, formats and structures generated within them. How to better control mutual dependencies Once we have identified the objectives, how can we achieve a practical implementation of a solution? The most obvious method is a point-to-point data exchange between the disciplines. One example is transferring a wire harness from electrical to mechanical engineering where additional information such as cable length is specified, before it is transferred back to electrical engineering. Although this method is widely used today, it lacks any kind of revision or change control. If the objective is a secure alignment across all involved disciplines, a more generic solution is required. One of the most obvious examples for this intertwining of product structures is an electric motor, which has both a mechanical and an electrical representation. It is part of an MCAD assembly and mechanical product structure, as well as being part of a schematic drawing in the ECAD system, and hence part of the electrical product structure. If a mechanical designer applies a change to the electric motor, this change also requires an update in the electrical drawing. However, the electrical engineer does not just need to understand which product is affected; he also needs to understand the implications and implement the required changes on a component level. Both structures point to the same part. Therefore both product structures the mechanical and electrical not only need to understand each other, they also need to be closely intertwined. In other words: the electrical bill of materials and the mechanical bill of materials must be associated in a bidirectional manner. This leads logically to the requirement for a deep integration between mechanical and electrical engineering. An electric motor is part of both the mechanical and electric product structure. We are convinced the capabilities offered by native management of our electrical and fluid design data will bring significant improvements in our change and variant management process, and in the re-use of existing designs. Roland Fuhrmann Head of IT at Faymonville d a t a m a n a g e m e n t z u k e n. c o m 3
Z u k e n T h e P a r t n e r f o r S u c c e s s Systems, data and processes employed in today s PEP The electrical BOM within the PLM backbone needs to be as associative as the mechanical BOM, and it needs to contain references to the schematic drawing and the devices used in it. The practical mechatronic data model: an unfulfilled promise? A solution to this requirement is the definition of a mechatronic data model that provides a full digital representation of the product, and which allows the mutual interdependencies to be controlled through intertwined mechanical and electrical bills of material. The need for such a data model is commonly agreed upon, however attempts at implementation have proved to be difficult within today s installed environments. For many engineering executives a mechatronic data model remains an unfulfilled promise to this day. So, why does the implementation of a mechatronic data model turn out to be so difficult, after all? If we take a look at the mechanical and the electrical BOMs, the reason becomes immediately apparent: a sensor that is deployed three times in one design is represented in the mechanical BOM as one item with the count three. For the electrical designer, however, every single sensor represents an individual function in the BOM that needs to be represented by a unique set of device properties. Consequently, mechanical and electrical BOMs represent different levels of detail that also need to be represented in the environments in which the respective bills of material are managed. The unique representation of the sensor used in our example therefore needs to be defined during the product development process to make sure the mechanical and electrical representations of the given component can be cross-referenced. 4 PLM: Identical level of granularity across MCAD and ECAD is a prerequisite But how deeply can we integrate between the different disciplines with a manageable degree of effort? The first question that has to be addressed is the level of detail with which the data generated by the different engineering disciplines needs to be connected, and how deep a realistic and practical integration for a mechatronic data model can be within a PLM system.
If we take the example of the electric motor, which represents both a mechanical and an electric component, we understand that mechanical and electrical engineering require a far-reaching degree of integration and interaction. The required associativity needs to be provided on a component level, so the full data model of a product in development needs to be represented within a single environment. According to common wisdom this ought to be in the PLM system. This system then would represent both the process, as well as the data generated within this process. In addition it would provide secure versioning and change mechanisms. If we take a look at the data models of today s PLM environments, it becomes evident that they have been designed to meet the requirements of mechanical engineering and the BOM structures used in that discipline. In other words, their data model does not support the depth of information that is required for a simultaneous representation of mechanical and electrical BOMs. Is PLM the ideal place to manage the digital product? Representing mechanical product structures within a PLM system is typically not a big challenge, since most PLM systems were developed from mechanical data management environments, and hence are deeply rooted in the world of mechanical engineering. Representing CAD formats, including all dependencies and variants with a structured bill of materials, is an everyday practice. The situation is quite different in the case of the electrical product structure: the data models used here are discipline-specific i.e. they typically access proprietary component libraries and can only be represented within PLM systems on a file level (we might also describe them as dumb files ). This means that a finished and approved project will be uploaded as a ZIP file containing all related library information. It can be accessed for documentation or sourcing purposes, but it will not be automatically updated if a change is made at some point in the PDP. The result is a serious fragmentation of the mechatronic data model: If the mechanic portion of the product is managed as a hierarchical structure, the required associativity on a component (i.e., mechanical) and a device (i.e., electrical) level is not supported. In other words, the electric motor used in our example will not be able to find and identify its electrical alter ego, because it is hidden in some sort of ZIP file. An export of an electrical BOM into the PLM system is also no solution to the problem, because once it has been exported, there is no reference back into the electrical product structure. If our ongoing electric motor example undergoes a modification, this change will find its way into the mechanical product structure in the PLM system. The electrical designs, however, will not be automatically updated, because it is locked up in a ZIP file and needs to be updated manually. If this is forgotten, it will become apparent only once the prototype is assembled, with well-known consequences for the project schedules, cost and product quality. Summing up: we can state that the electrical BOM needs to have the same level of associativity as the mechanical BOM, and it needs to contain a reference back to the schematic drawing and the devices used in it. This is the point where most attempts at defining a mechatronic data model have failed: the effort to represent the electrical logic in a PLM backbone turned out to be simply too great. Instead, the industry has resorted to a number of workarounds in the form of scripts and spreadsheets, which appear to be highly questionable from a data and process security perspective. Enabling the electrical product structure for PLM How can the electrical product structure be enabled for PLM? Product structures are We realized that to continue to serve our global markets with leading-edge products, we needed to take our mechanical, electrical and software engineering processes to the next level. By integrating domain-specific development processes into an end-to-end mechatronic engineering environment, we will be able to offer our customers cost-efficient and customized solutions that cut their engineering lead time and overheads. Theodor Determann, Managing Director at Windmöller & Hölscher d a t a m a n a g e m e n t z u k e n. c o m 5
Z u k e n T h e P a r t n e r f o r S u c c e s s A successful mechatronic data model enables control of multiple dependencies within the PDP overheads, it should be part of a standard engineering data management environment for electrical engineering (EDM). While the implementation of an electrical data model within a native EDM environment for electrical engineering lays the foundation for an integrated mechatronic data model, the question of how to link the BOMs in an associative way stills remains to be resolved. Currently, two different approaches are being discussed by industry experts: Linking mechanical and electrical components in a retroactive way, after they have been created in their respective environments, or, alternatively, creating a unique representation upfront by adopting a functional approach to design. 6 The layout of the electrical product structure within an EDM system, in which the electrical product structure is represented within a database, is technically complex and should not be implemented as a customized integration. typically represented in a PLM system in the shape of a structure tree, which we all are familiar with from mechanical engineering. The MCAD data model is hierarchically structured and typically consists of the levels of product, assembly, sub-assembly, part and sourced or standard part. This structure can be represented within a relational database, together with all related derivatives, such as physical drawings or NC files. Historically MCAD data models like these used to first be represented in local or proprietary EDM environments. PDM and PLM have environments subsequently adopted this type of data model layout as their foundation. It is possible to proceed in a similar way when trying to adapt the missing link the electrical data structure for the requirements of a comprehensive mechatronic data model to be represented within PLM. The first step is to define a suitable ECAD data structure that needs to be object-oriented and associative, in the same way as the MCAD data structure. This means: article, component and devices need to be associative, just like all documents and BOMS derived from the schematic. In the second step, the data model can be laid out within an EDM system in which the electrical product structure is represented within a database. This step is technically complex and should therefore not be implemented as a customized integration. To reduce implementation and maintenance The approach of retroactively linking mechanical and electrical components requires a manual mapping of the ECAD and MCAD data models represented in the respective EDM or PDM environments. The matching process, however, requires a substantial manual reconciliation effort that can only be partially automated. Therefore, an upfront functional definition of the product appears to be a valid alternative, as it ensures unique representations of all elements. For the electrical designer this is a well-established practice; for mechanical designers, however, a certain degree of rethinking is required, as they need to add a number of functional specifications to electrical devices (e.g. sensors) that in the mechanical world traditionally used to be represented only as geometric entities. With E 3.EDM Zuken provides a solution that is capable of managing electrical and fluid engineering data in a native environment. The solution manages work-in-progress engineering as well as library data of the object-oriented ECAD system, E 3.series, in a native format. It is therefore able to manage all associations between mechanical and electrical engineering and to consistently map all change processes. Those who worry that this solution might represent just another item in an already complex IT environment can be reassured: an electrical engineering data management solution replaces a multitude of difficultto-manage interfaces and spreadsheets through a single, controlled and revision-proof environment. All trademarks mentioned are the property of their respective owners. Copyright Zuken GmbH. 150703 zuken.com/e3edm