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
