wp-electrical-engineering-mechatronic-data-model-en
1 like98 views
The document discusses the need for an integrated mechatronic data model to facilitate collaboration between mechanical, electrical, and software engineering teams in product development. A key challenge is that mechanical and electrical engineering data models represent different levels of detail and have traditionally been managed separately. The document proposes representing both the mechanical and electrical product structures within a single Engineering Data Management system using an object-oriented data model. This would provide the deep integration and bidirectional associations between mechanical and electrical components needed for an effective mechatronic data model.
wp-electrical-engineering-mechatronic-data-model-en
- 1. 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 W H I T E P A P E R datamanagement z u k e n . c o m Electrical engineering da ta manage ment A practical foundation for a true mechatronic data model
- 2. Mechatronicproducts–arealityintoday’s engineeringpractice From connected vehicles to smart phones and household appliances, we are seeing rapid growth in the level of electronics and software inalmosteverysector.Oneofthemosttangible 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 property. It also provides the opportunity to differentiate from competitors through innovativesolutionapproaches. 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 Abstract Thegrowingcomplexityof modernproducts,machinesand systemscallsforinterdisciplinary collaborationduringtheearly phasesoftheproductdevelopment process(PDP).Inthecontext ofmechatronicengineering, establishedmethods,suchas managingmechanical,electrical andsoftwaredevelopmentdata inseparateenvironmentsor repositories,anddelayingtheir integrationtoalatephaseofthe PDP,arereachingtheirlimitations. Inordertoreliablymeetthe objectivesoftoday’sproduct developmentprograms,anefficient coordinationofthework-in- progressofallinvolveddisciplines isurgentlyrequired.Althoughan exchangeofdataandinformation betweenindividualCAD-Toolsets enablesaparameterexchangeon adetaileddesignlevel,thatalone isnotsufficientfromaprocess perspective.Whatisrequiredisa comprehensiverepresentationof allrelevantinformationandstatus changesbeginningfromtheearly phasesofaproductdevelopment process,sothatacomprehensive representationofthedigitalproduct isavailableatalltimes. WithE3 .EDM,Zukenisthefirst vendortosupplyanEngineering DataManagementsolution forelectrotechnicalandfluid engineeringthatprovidesthebasis foranin-depthrepresentationofthe electricalproductstructurewithin acompany-widePLMbackbone. Thesolutionmanagesinformation inahierarchicalorderwithinthe frameworkofanobject-oriented industrystandardrelational database. Optimalproductdevelopmentprocess: businessandengineeringprocessesare closelyaligned 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 Thecomplexityofmodernproductshasledtoagrowing degreeofspecializationandfragmentationwithinthe ProductDevelopmentProcess(PDP). Functional Description MCAD SoftwareE/E
- 3. Doestoday’sPDPmeettheneedsof tomorrow’smechatronicproduct developmentprocesses? 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 otherdisciplines. Inadialogbetweentheengineeringdisciplines 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 astheprototypestage. 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, areconsideredineveryinvolveddiscipline. To meet these objectives, two basic requirementshavetobemet: n All development processes are conducted in a parallel within their respective disciplines. However, mutual dependencies need to be comprehensivelyrepresented. n 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 Anelectricmotorispartofboththe mechanicalandelectricproduct structure. 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 duringwhichspecificworkhastobecompleted and made ready for review). But not only do the development processes show profound differences, so do the engineering data, formats and structures generated withinthem. Howtobettercontrol mutualdependencies 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 genericsolutionisrequired. 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 assemblyandmechanicalproductstructure,as wellasbeingpartofaschematicdrawinginthe ECAD system, and hence part of the electrical productstructure. 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 componentlevel. 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 mechanicalandelectricalengineering. “Weareconvincedthe capabilitiesofferedby nativemanagementofour electricalandfluiddesign datawillbringsignificant improvementsinour changeandvariant managementprocess,and inthere-useofexisting designs.” RolandFuhrmann HeadofITat Faymonville datamanagement z u k e n . c o m 3 differences, so do the engineering data, formats and structures generated Once we have identified the objectives, how can we achieve aobjectives, how can we achieve a practical implementation of a solution?
- 4. have proved to be difficult within today’s installed environments. For many engineering executives a mechatronic data model remains anunfulfilledpromisetothisday. 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 becross-referenced. 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 modelcanbewithinaPLMsystem. Thepracticalmechatronicdatamodel: an unfulfilledpromise? 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 4 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 TheelectricalBOMwithinthePLM backboneneedstobeasassociative asthemechanicalBOM,andit needstocontainreferencestothe schematicdrawingandthedevices usedinit. PLM: Identical level of granularity across MCAD and ECAD is a prerequisite Systems,dataandprocesses employedintoday’sPEP
- 5. 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 somesortofZIPfile. 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,costandproductquality. 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 definingamechatronicdatamodelhavefailed: 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. Enablingtheelectricalproductstructure forPLM How can the electrical product structure be enabled for PLM? Product structures are 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 wisdomthisoughttobeinthePLMsystem. This system then would represent both the process, as well as the data generated within this process. In addition it would provide secureversioningandchangemechanisms. 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 otherwords,theirdatamodeldoesnotsupport the depth of information that is required for a simultaneous representation of mechanical andelectricalBOMs. IsPLMtheidealplacetomanagethe digitalproduct? Representing mechanical product structures within a PLM system is typically not a big challenge, since most PLM systems were developedfrommechanicaldatamanagement environments, and hence are deeply rooted in the world of mechanical engineering. Representing CAD formats, including all dependencies and variants with a structured billofmaterials,isaneverydaypractice. 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 madeatsomepointinthePDP. The result is a serious fragmentation of the mechatronic data model: If the mechanic portion of the product is managed as a hierarchicalstructure,therequiredassociativity on a component (i.e., mechanical) and a device (i.e., electrical) level is not supported. In other datamanagement z u k e n . c o m 5 “Werealizedthatto continuetoserveour globalmarketswith leading-edgeproducts, weneededtotakeour mechanical,electrical andsoftwareengineering processestothenext level.Byintegrating domain-specific developmentprocesses intoanend-to-end mechatronicengineering environment,wewill beabletoofferour customerscost-efficient andcustomizedsolutions thatcuttheirengineering leadtimeandoverheads.“ TheodorDetermann, ManagingDirectorat Windmöller&Hölscher
- 6. typically represented in a PLM system in the shape of a structure tree, which we all are familiarwithfrommechanicalengineering.The MCAD data model is hierarchically structured and typically consists of the levels of product, assembly, sub-assembly, part and sourced or standardpart. 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 typeofdatamodellayoutastheirfoundation. 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 representedwithinPLM. n The first step is to define a suitable ECAD datastructurethatneedstobeobject-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. n 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 overheads, it should be part of a standard engineering data management environment forelectricalengineering(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 associativewaystillsremainstoberesolved. Currently, two different approaches are being discussed by industry experts: Linking mechanical and electrical components in a retroactiveway,aftertheyhavebeencreatedin their respective environments, or, alternatively, creating a unique representation upfront by adoptingafunctionalapproachtodesign. The approach of retroactively linking mechanicalandelectricalcomponentsrequires amanualmappingoftheECADandMCADdata 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 re- thinking 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 representedonlyasgeometricentities. With E3 .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, E3 .series, in a native format. It is therefore able to manage all associations between mechanical and electrical engineering and to consistently map allchangeprocesses. 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 difficult- to-manage interfaces and spreadsheets through a single, controlled and revision-proof environment. 6 Asuccessfulmechatronicdatamodel enablescontrolofmultipledependencies withinthePDP Thelayoutoftheelectrical productstructurewithinan EDMsystem,inwhichthe electricalproductstructureis representedwithina database,istechnically complexandshouldnotbe implementedasacustomized integration. 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 zuken.com/e3edmAll trademarks mentioned are the property of their respective owners. Copyright © Zuken GmbH. 150703