- Email: [email protected]
Mechatronic Data Models in Production Engineering
Mechatronic Data Models in Production Engineering M. Bergert*, J. Kiefer** *Institute for Automation Engineering, Otto-von-Guericke-Universität Magdeburg, Magdeburg, Germany (Tel.: +49-731-505-2421; e-mail: [email protected]) **Daimler AG, Group Research & Advanced Engineering, Integrated Production Modeling, Ulm, Germany (Tel.: +49-731-505-2459; e-mail: [email protected]) Abstract: In automotive industry, to manage the market-driven challenges in the form of soaring product variants and decreasing model cycles successfully, new methods and IT solutions are required, especially in the field of production engineering. In this context, mechatronics as a key technology will play a decisive role in the future. This mechatronic issue refers not only to the increased use of mechatronic components in real production systems but also to the use of mechatronic data models in production engineering phases. Apart from their main characteristics, this contribution highlights different application scenarios of developing, using and processing these cross-domain data models. Keywords: Mechatronics, Production Engineering, AutomationML, Virtual Commissioning
1. INTRODUCTION After years of rising profits, companies in the automotive industry are currently confronted with stagnant or even diminishing markets. Due to the resulting competition for key market shares, car manufacturers (OEM) are engaged in an innovation race characterized by the following core demands: • Soaring number of product variants with many product derivates • Decreasing innovation and model cycles • “Green technologies” in the field of future powertrain systems These market-driven challenges inevitably affect all phases of the overall product lifecycle, especially the productionrelated project phases both of production engineering and ramp-up. On the one hand, the considered processes become increasingly more complex and, in consequence, more errorprone. On the other hand, in order to gain important market shares, the time for production engineering and ramp-ups has to be cut to the bone. Last but not least, these challenges also lead to extensive changes of the production systems themselves. The production facilities will become more and more flexible (as base for the production of more than one product), the lifecycles are getting longer and longer and the number of production ramp-ups will be constantly rising – especially during running production. In order to manage these crucial production-related challenges, mechatronics as a key technology will play a significant role in the future. In this context, the following topic fields are presented both from a scientific- and useroriented point of view taking the example of the engineering process of highly flexible production systems in the automotive industry. The considered mechatronic-oriented engineering applications are:
• Functional engineering Functional engineering describes a methodology for improving the production-related electrical and control engineering process. Base of this new methodology is the definition and use of mechatronic objects. The most important characteristics of these mechatronic objects as well as the functional engineering workflow are illustrated. • Data exchange via AutomationML AutomationML focuses on the data exchange in production engineering. In this contribution the motivation and goals of AutomationML as well as the use for virtual commissioning are described. • Virtual commissioning Apart from the illustration of the goals and concept of this hybrid simulation technology, the most important characteristics as well as the development process of the required mechatronic plant model as base for virtual commissioning is presented.
2. FUNCTIONAL ENGINEERING Traditionally the process of production engineering is divided into mechanical design, robotics/simulation, electrical design and control design. Methods and tools of the digital factory primarily support the mechanical design as well as the simulation/robotics processes based on interdisciplinary workflows and an integrated data management. In the field of automation engineering (electrical/ control design), the situation is different. Innovative and integrated methods and technologies are still missing or they are currently developed by different companies. For example, Daimler pushes the mechatronic-oriented approach of „functional engineering“ to improve and standardize the processes of control engineering, robotics and drive engineering (Hirzle, 2008).
Kinematics Geometry
Electrics
Behavior
Identification Name: … ID: … Number: …
Mechatronic object
Visualization
x:= y+1; if z then else … y:= z;
Preparation phase
Execution phase Organization
Evaluation phase
Wiring diagrams
2D plant layout Mechanical data
Functional engineering
PLC programs, hardware configuration Plant-specific behavior model
Procedure
Process sequence
Libraries
• Identification Most important aspect of a mechatronic object; is uniquely defined in the standardization process (object identifier); at the first use the instance identifier is defined • Geometry/ Kinematics Used in mechanical design to develop and simulate the mechanical 3D plant model (e.g. use for DMU/ accessibility checks, robot simulation) • Electrics Contains all necessary information and templates both for wiring diagrams and the connection to the used controls (e.g. PLC: Programmable Logic Controller) and power supply • Behavior Description of the function-specific behavior of the mechatronic object in relation to a control (e.g. PLC, RC: Robot Controller); essential base for virtual commissioning (chapter 4) • Communication/ Control/ Visualization Definition and use of templates for PLC function blocks, human machine interface (HMI) and for the communication between controls and the mechatronic object
IT architecture
The basic idea of functional engineering is the use of a „mechatronic engineering kit”. Therefore, it is required to standardize all production-related resources used in the considered company (e.g. robots, conveyors). Such resources are described by their mechatronic characteristics illustrated in Figure 2. Once defined, these mechatronic objects can be used along the whole production engineering process. Related to the different engineering phases, the relevant aspects including a short description of these objects are:
including the planned resources (e.g. number of robots) and already defined PLC and protection areas. From the mechanical design more detailed information about the planned resources are necessary as for example which robots are used or how the clamps are connected to the valves (pneumatic plan). Based on pre-defined standardized configuration rules (e.g. concrete linkage between motor type and conveyor) and the needed mechatronic object library, the input data are enriched with electrical information. Thus, it is possible to generate all required types of wiring diagrams, PLC programs (incl. resource-specific function blocks) and the plant-specific behavior model as base for virtual commissioning (chapter 4) automatically. In chapter 3 exemplary the process of behavior model generation based on AutomationML is described in detail.
Configuration rules
2.1 Concept
Figure 3: Functional engineering – Phases, data flows and inputs/ outputs Apart from the resource-specific issues, functional engineering is also intended for improving the data consistency for process planning. On the one hand, the process sequence defined in the digital factory is enriched with control-specific information in order to generate the PLC Sequence Function Charts (SFC). Thus, the whole PLC program can be automatically generated. On the other hand, so far it is possible today, the motion planning for robots of the digital factory (OLP: Offline Programming) is enhanced with the necessary signal information for communication to the PLC. Based on this, the whole manufacturer-specific robot program code (e.g. KUKA, ABB) is generated.
Communication Control
e.g. GSD, FDCML, EDS, EDD
3 DATA EXCHANGE VIA AutomationML 3.1 Motivation
Figure 2: Aspects of a mechatronic object in production engineering 2.2 Engineering workflow The main inputs for functional engineering are results from the concept planning and the mechanical design. As illustrated in Figure 3, one base is the 2D plant layout
To achieve all goals of functional engineering in a most efficient way, it is essential to exchange the different heterogeneous planning and design data between the different software tools without loss of information. That means, respective interfaces between all relevant engineering tools are required. In order to avoid many proprietary interfaces, it is recommended to use an integrative data exchange format.
In this context, a few years ago Daimler initialized a consortium of different companies to push the development of the data exchange format AutomationML (Drath, 2008). The goal of AutomationML is the representation of crossfunction data as for example topology, geometry, kinematics, motion planning and logic/ behavior in an open, standardized format for improving the data exchange in the field of production engineering. AutomationML based on existing standards like CAEX (topology), COLLADA (geometry, kinematics) and PLCopenXML (logic, behavior). First applications and software interfaces are already available; in 2009, the AutomationML association for further development and publication of AutomationML was founded.
AutomationML Top level format CAEX IEC 62424 Topology of • Plants • Cells • Components • Attributes • Interfaces • Relations • References
Geometry and Kinematic format COLLADA
Object A Object A1
Init Init
Object A2 Object A3
Logic format PLCopenXML (Sequencing)
Step 1
End
Logic format PLCopenXML (Behavior)
a/ A=0
Z2
d/ A=0
b/ A=0 Z1
To solve this open issue, (Kiefer, 2009) suggests that the component manufacturers should provide the digital behavior models together with the real components. But the effort to build a behavior model for every available virtual commissioning tool at the market would be much too high for the component manufacturers. Thus, a software independent method for behavior modeling is required. AutomationML supports behavior modeling with PLCopen XML (see figure 3). So if the different tools for virtual commissioning provide an AutomationML interface the following behavior modeling workflow would be possible: Each component manufacturer develops on behavior model for its components in AutomationML (PLCopen XML) and provide it one the market • The virtual commissioning user chooses the software tool that is suitable for his requirements • The component-specific behavior models are imported in the chosen software tool via AutomationML With this workflow based on AutomationML the effort for behavior modeling for virtual commissioning can be reduced significantly. The component manufacturer only has to develop one model for each of its provided components and the user of virtual commissioning can use a basic, toolindependent library of behavior models. •
3.3 Plant-specific behavior model generation
Z3 c/ A=1
Figure 3. AutomationML basic architecture As pictured in figure 3, amongst others AutomationML focuses behavior as one aspect of mechatronic objects. In the following an AutomationML-based workflow for behavior modeling for virtual commissioning is presented. 3.2 Software independent behavior modeling For virtual commissioning (see chapter 4) a digital model of the production plant is needed. As well as real production plants, the digital model that is developed during the production engineering process consists of mechatronic objects. The smallest units (objects) within production engineering are so called components. These components normally are standard parts and purchase parts like robots, clamps or motors. For the mechanical aspects of these components (geometry, kinematics) normally digital representations are delivered by the manufacturer so that they are available in the production engineering process. In contrast, behavior models (necessary for virtual commissioning) of these components normally are not available. So the development of component-specific behavior models for virtual commissioning predominantly is a time-consuming and error-prone process.
Basis for the plant-specific behavior model generation is the library of component-specific behavior models. This library initially is independent from the user’s company, i.e. company neutral. In a second step, the component-specific behavior models are combined to functional, companyspecific modules. These modules usually represent companywide standardized resources, for example a robot with its controller or a conveyor. In the company-specific behavior model library these modules are characterized by standardized signal names and interfaces to other modules or controllers for virtual commissioning. With the standardized module-specific behavior library and the results of the functional engineering it is now possible to generate the plant-specific behavior model automatically. Thereto primarily the module list (which modules are used in the plant and how are they named) and plant-specific parameter sets (e.g. rotation speed of a particular drive, address range of a robot) are necessary. With the company-specific rules of the functional engineering standard and a generator (e.g. MS Excel tool) the connections between different modules and to the PLC can be generated automatically. The whole creation process of plant-specific behavior models is illustrated in figure 4.
CE
L
Functional engineering
LL
FL
Plant-specific behavior model
Drive 0815 M
+
BML
FI
CN
CL
ML
SL
CS
Generator
CL: Components level CEL: Cell level CN: Company neutral
ML: Module level LL: Line level CS: Company specific
SL: Station Level FL: Factory level BML: Behavior Model Library
Figure 4. Creation process of behavior models
Although much progress has been made in this topic in recent years, there are still some open issues that have to be solved in order to develop all benefits that can be gained by using this new simulation methodology. Relating to the entire production lifecycle, the main benefits of virtual commissioning are for example: • • • • • •
More efficient PLC programming and debugging Accelerated and more robust production ramp-ups Higher degree of soft- and hardware maturity at start of production (SOP) Operator trainings before SOP Higher availability of the manufacturing systems during running production More efficient integration processes during running production
Preparation phase
Digital product data (3D geometry) Mechatronic plant model Real control data (Hard-/ software, interfaces)
Execution phase Organization
Compared to the technology lifecycle model published in (Gausemeier, 2001), the method of virtual commissioning is a so-called key methodology that will be an important competitive advantage in the future. However, this new methodology is still an expert application that is currently only used for special production facilities in a selective way.
Virtual commissioning
Evaluation phase
Validated PLC program (incl. interactions to RCs) Validated interaction of mechanics, electrics and control Validated system behavior
Procedure
As published in (Kiefer, 2009), virtual commissioning describes a methodology for validating and optimizing real control programs (e.g. PLC, RC, HMI) and the whole system behavior (e.g. the cross-function interaction inside a production system) without having the real production facilities. Due to the necessary hybrid data inputs in the form of digital product and resource as well as real control data, the simulation method of virtual commissioning is also frequently referred to a transfer from the digital to the real factory.
IT architecture
4.1. Goals and concept
To take advantage of all these benefits in a most profitable way, a digital data model is required that represents not only the mechanical but also the electrical and functional portions of the real production facilities in a sufficiently exact way. Due to its contained information, this integrated data model is to be called mechatronic plant model. As illustrated in Fig. 7, apart from the mechatronic plant model, digital product as well as real control data are the necessary inputs for realizing virtual commissioning projects (preparation phase). Furthermore, Fig. 7 also portrays the main influencing variables on the execution of virtual commissioning as for example the IT architecture during runtime, the concrete validation goals as well as organizational issues (responsibility areas etc.).
Validation goals
4. VIRTUAL COMMISSIONING
Fig. 7. Virtual commissioning – Phases, data flows and inputs/ outputs
4.2. Mechatronic plant model Today, the crucial factor in accomplishing virtual commissioning projects as profitable as possible is not the technical execution itself but the development process of the needed mechatronic plant model: This preparation phase is currently characterized by a mostly manual, error-prone and time-consuming process. At Daimler, an engineering workflow for generating the mechatronic plant model as efficient as possible was developed, which main characteristics are illustrated in the following sections. As shown in Fig. 8, the mechatronic plant model is fundamentally composed of two corresponding parts: the extended 3D geometry model on the one hand and the control-oriented behavior model on the other hand. DIGITAL FACTORY
REAL FACTORY
Production engineering
Production
OU 1
OU 2
OU 3
OU n
Mechanical design (3D CAD model)
Electrical design (Function group list)
Control design (signal lists, bus structure)
Repair & maintenance Integration processes
AutomationML Control equipment
Mechatronic plant model Extended 3D geometry model
3D geometry Kinematics Material flow Sensors
OU: Organizational Unit
Signal exchange
Behavior model
x:= y+1; if z then else … y:= z;
PLC Behavior models Motion data PLC/ RC input/ output signals
PLC: Programmable Logic Controller
RC RC: Robot Controller
Fig. 8. Virtual commissioning – Data supply and workflow Depending on the company-specific strategy (goals of virtual commissioning, used IT architecture etc.), the mechatronic plant model can either consist of: one integrated data model (integration of the extended 3D geometry model and control-oriented behavior model in one common data model) or • two separate data models (as depicted in Fig. 8), which communicate over corresponding system interfaces during the execution phase. Each of these two strategies has their individual strengths and weaknesses. Last but not least, the strategic decision depends both on company- and tool-specific boundary conditions and can therefore only be made individually by each company. Relating to the second strategy, one possible virtual commissioning architecture is illustrated in Fig. 9. In this example, the IT systems WinMOD (behavior model) and Invision (extended 3D geometry model) are used. •
Fig. 9. Virtual commissioning architecture with WinMOD and Invision The approach of using one integrated data model as base for virtual commissioning was presented in (Kiefer, 2008). In the following, the engineering workflow for developing the mechatronic plant model according to the second strategy focusing the extended 3D geometry model is illustrated. As portrayed in Fig. 8, the extended 3D geometry model consists of different data sets such as 3D geometry, kinematics, material flow and sensor information. Due to profitability aspects, the crucial goal is to perform the development process of this data model as efficient as possible. The proposed solution mainly bases of the development and the integration of two core issues: Early use of 3D CAD models including mechatronic aspects • Use of a system-independent, cross-functional data exchange format for data transfer According to a typical frontloading procedure, the 3D CAD models normally used in mechanical design (e.g. fixtures, grippers) have to be enhanced with additional mechatronic information. Base of this mechatronic-oriented design process is the existence of standardized mechatronic components (e.g. clamps, robots, sensors). In order to allow a companywide access to these newly configured objects, all these mechatronic units are made available to the related departments in the form of a centrally organized mechatronic component library. In contrast to today's mechanical CAD models, the mechatronic components does not just solely consists of the pure 3D CAD model but also of kinematics (including end positions) and electrical information as for example the electrical name of the respective device. After taking the projectneutral mechatronic components from the library, the responsible department (e.g. the Tooling Design) only has to tailor them to their special installation situations in the respective production system (e.g. adaptation of the electrical name). •
After developing and validating the mechatronic CAD model of the production system, this data model has to be transferred to the used CAD-oriented IT system for virtual commissioning. In this context, two general cases have to be distinguished:
a) The used IT systems (3D CAD/ virtual commissioning system) are from the same IT vendor b) b) The used IT systems are not from the same IT vendor In case a), a seamless data exchange between the IT systems based on the vendor-specific proprietary data interfaces is normally given. Representatives of this one vendor solution are for example the companies Dassault Systèmes (CATIA/ DELMIA V5) and Siemens PLM Software (NX, Process Simulate). The situation in case b) is totally different. In the past, there was no possibility to exchange cross-functional data models between two IT systems (of different IT vendors) without loss of information. In order to improve this unsatisfactory situation, as mentioned in chapter three, the tool-neutral crossfunctional data exchange format AutomationML is being developed. Using this open data exchange format, the mechatronic CAD models can be completely exchanged between the considered heterogeneous IT systems without data loss.
5. SUMMARY AND OUTLOOK In this contribution, three mechatronic-based applications are introduced: Functional engineering, data exchange via AutomationML and virtual commissioning. Apart from the most important characteristics of these innovative solutions, the individual engineering workflows as well as the links between these topics are illustrated both from a scientificand user-oriented point of view. So far, a majority of the pictured aspects could be successfully executed using real production-related examples in the field of automotive industry. At present, the seamless implementation with the special focus on profitability aspects is being verified and evaluated critically. Although much progress has been made in these mechatronic-oriented topic fields, following issues still remain to be addressed in further activities: Further developments and industrialization of the open crossfunctional data exchange format AutomationML as base for the seamless data integration between the fields of digital factory and automation engineering. Organizational issues (e.g. definition of tasks distributions and responsibility areas, cooperation models between the OEM and their suppliers) have to be critically analyzed and adapted to these new mechatronic-oriented production engineering topics ACKNOWLEDGEMENT Parts of the presented activities and results are developed within the scope of the European Union research grant MyCar – Flexible Assembly Processes for the Car of the Third Millennium (NMP2-CT-2006-026631). More information about this project is available at: http://www.mycar-project.eu.
REFERENCES Drath, R., Lueder, A., Peschke, J., Hundt, L. (2008). AutomationML – the glue for seamless Automation Engineering. Proceedings of the 13th IEEE International Conference on Emerging Technologies and Factory Automation – ETFA 2008. Hamburg, Germany. pp. 616623. Gausemeier, J., Ebbesmeyer, P., Kallmeyer, F. (2001). Produktinnovation. Carl Hanser Verlag. Munich, Germany. Hirzle, A., Alonso Garcia, A., Burkhardt, A. (2008). Steuerungstechnische Standards als Fundament für die Leittechnik. atp - Automatisierungstechnische Praxis 9/2008. pp. 42-47. Kiefer, J., Baer, T., Bley, H. (2008). Mechatronic-Oriented Design of Automated Manufacturing Systems in the Automotive Body Shop. Proceedings of the 10th International Design Conference - DESIGN 2008. D. Marjanovic (Ed.). Dubrovnik, Croatia. pp. 1295-1302. Kiefer, J., Ollinger, L., Bergert, M. (2009). Virtuelle Inbetriebnahme - Standardisierte Verhaltensmodellierung mechatronischer Betriebsmittel im automobilen Karosserierohbau. atp - Automatisierungstechnische Praxis, 7/2009. pp. 40-46. Kiefer, J., Prieur, M., Schmidgall, G., Baer, T. (2009). Digital Planning and Validation of Highly Flexible Manufacturing Systems in the Automotive Body Shop. Proceedings of the 42nd CIRP International Seminar on Manufacturing Systems - ICMS 2009. Grenoble, France.
1. INTRODUCTION After years of rising profits, companies in the automotive industry are currently confronted with stagnant or even diminishing markets. Due to the resulting competition for key market shares, car manufacturers (OEM) are engaged in an innovation race characterized by the following core demands: • Soaring number of product variants with many product derivates • Decreasing innovation and model cycles • “Green technologies” in the field of future powertrain systems These market-driven challenges inevitably affect all phases of the overall product lifecycle, especially the productionrelated project phases both of production engineering and ramp-up. On the one hand, the considered processes become increasingly more complex and, in consequence, more errorprone. On the other hand, in order to gain important market shares, the time for production engineering and ramp-ups has to be cut to the bone. Last but not least, these challenges also lead to extensive changes of the production systems themselves. The production facilities will become more and more flexible (as base for the production of more than one product), the lifecycles are getting longer and longer and the number of production ramp-ups will be constantly rising – especially during running production. In order to manage these crucial production-related challenges, mechatronics as a key technology will play a significant role in the future. In this context, the following topic fields are presented both from a scientific- and useroriented point of view taking the example of the engineering process of highly flexible production systems in the automotive industry. The considered mechatronic-oriented engineering applications are:
• Functional engineering Functional engineering describes a methodology for improving the production-related electrical and control engineering process. Base of this new methodology is the definition and use of mechatronic objects. The most important characteristics of these mechatronic objects as well as the functional engineering workflow are illustrated. • Data exchange via AutomationML AutomationML focuses on the data exchange in production engineering. In this contribution the motivation and goals of AutomationML as well as the use for virtual commissioning are described. • Virtual commissioning Apart from the illustration of the goals and concept of this hybrid simulation technology, the most important characteristics as well as the development process of the required mechatronic plant model as base for virtual commissioning is presented.
2. FUNCTIONAL ENGINEERING Traditionally the process of production engineering is divided into mechanical design, robotics/simulation, electrical design and control design. Methods and tools of the digital factory primarily support the mechanical design as well as the simulation/robotics processes based on interdisciplinary workflows and an integrated data management. In the field of automation engineering (electrical/ control design), the situation is different. Innovative and integrated methods and technologies are still missing or they are currently developed by different companies. For example, Daimler pushes the mechatronic-oriented approach of „functional engineering“ to improve and standardize the processes of control engineering, robotics and drive engineering (Hirzle, 2008).
Kinematics Geometry
Electrics
Behavior
Identification Name: … ID: … Number: …
Mechatronic object
Visualization
x:= y+1; if z then else … y:= z;
Preparation phase
Execution phase Organization
Evaluation phase
Wiring diagrams
2D plant layout Mechanical data
Functional engineering
PLC programs, hardware configuration Plant-specific behavior model
Procedure
Process sequence
Libraries
• Identification Most important aspect of a mechatronic object; is uniquely defined in the standardization process (object identifier); at the first use the instance identifier is defined • Geometry/ Kinematics Used in mechanical design to develop and simulate the mechanical 3D plant model (e.g. use for DMU/ accessibility checks, robot simulation) • Electrics Contains all necessary information and templates both for wiring diagrams and the connection to the used controls (e.g. PLC: Programmable Logic Controller) and power supply • Behavior Description of the function-specific behavior of the mechatronic object in relation to a control (e.g. PLC, RC: Robot Controller); essential base for virtual commissioning (chapter 4) • Communication/ Control/ Visualization Definition and use of templates for PLC function blocks, human machine interface (HMI) and for the communication between controls and the mechatronic object
IT architecture
The basic idea of functional engineering is the use of a „mechatronic engineering kit”. Therefore, it is required to standardize all production-related resources used in the considered company (e.g. robots, conveyors). Such resources are described by their mechatronic characteristics illustrated in Figure 2. Once defined, these mechatronic objects can be used along the whole production engineering process. Related to the different engineering phases, the relevant aspects including a short description of these objects are:
including the planned resources (e.g. number of robots) and already defined PLC and protection areas. From the mechanical design more detailed information about the planned resources are necessary as for example which robots are used or how the clamps are connected to the valves (pneumatic plan). Based on pre-defined standardized configuration rules (e.g. concrete linkage between motor type and conveyor) and the needed mechatronic object library, the input data are enriched with electrical information. Thus, it is possible to generate all required types of wiring diagrams, PLC programs (incl. resource-specific function blocks) and the plant-specific behavior model as base for virtual commissioning (chapter 4) automatically. In chapter 3 exemplary the process of behavior model generation based on AutomationML is described in detail.
Configuration rules
2.1 Concept
Figure 3: Functional engineering – Phases, data flows and inputs/ outputs Apart from the resource-specific issues, functional engineering is also intended for improving the data consistency for process planning. On the one hand, the process sequence defined in the digital factory is enriched with control-specific information in order to generate the PLC Sequence Function Charts (SFC). Thus, the whole PLC program can be automatically generated. On the other hand, so far it is possible today, the motion planning for robots of the digital factory (OLP: Offline Programming) is enhanced with the necessary signal information for communication to the PLC. Based on this, the whole manufacturer-specific robot program code (e.g. KUKA, ABB) is generated.
Communication Control
e.g. GSD, FDCML, EDS, EDD
3 DATA EXCHANGE VIA AutomationML 3.1 Motivation
Figure 2: Aspects of a mechatronic object in production engineering 2.2 Engineering workflow The main inputs for functional engineering are results from the concept planning and the mechanical design. As illustrated in Figure 3, one base is the 2D plant layout
To achieve all goals of functional engineering in a most efficient way, it is essential to exchange the different heterogeneous planning and design data between the different software tools without loss of information. That means, respective interfaces between all relevant engineering tools are required. In order to avoid many proprietary interfaces, it is recommended to use an integrative data exchange format.
In this context, a few years ago Daimler initialized a consortium of different companies to push the development of the data exchange format AutomationML (Drath, 2008). The goal of AutomationML is the representation of crossfunction data as for example topology, geometry, kinematics, motion planning and logic/ behavior in an open, standardized format for improving the data exchange in the field of production engineering. AutomationML based on existing standards like CAEX (topology), COLLADA (geometry, kinematics) and PLCopenXML (logic, behavior). First applications and software interfaces are already available; in 2009, the AutomationML association for further development and publication of AutomationML was founded.
AutomationML Top level format CAEX IEC 62424 Topology of • Plants • Cells • Components • Attributes • Interfaces • Relations • References
Geometry and Kinematic format COLLADA
Object A Object A1
Init Init
Object A2 Object A3
Logic format PLCopenXML (Sequencing)
Step 1
End
Logic format PLCopenXML (Behavior)
a/ A=0
Z2
d/ A=0
b/ A=0 Z1
To solve this open issue, (Kiefer, 2009) suggests that the component manufacturers should provide the digital behavior models together with the real components. But the effort to build a behavior model for every available virtual commissioning tool at the market would be much too high for the component manufacturers. Thus, a software independent method for behavior modeling is required. AutomationML supports behavior modeling with PLCopen XML (see figure 3). So if the different tools for virtual commissioning provide an AutomationML interface the following behavior modeling workflow would be possible: Each component manufacturer develops on behavior model for its components in AutomationML (PLCopen XML) and provide it one the market • The virtual commissioning user chooses the software tool that is suitable for his requirements • The component-specific behavior models are imported in the chosen software tool via AutomationML With this workflow based on AutomationML the effort for behavior modeling for virtual commissioning can be reduced significantly. The component manufacturer only has to develop one model for each of its provided components and the user of virtual commissioning can use a basic, toolindependent library of behavior models. •
3.3 Plant-specific behavior model generation
Z3 c/ A=1
Figure 3. AutomationML basic architecture As pictured in figure 3, amongst others AutomationML focuses behavior as one aspect of mechatronic objects. In the following an AutomationML-based workflow for behavior modeling for virtual commissioning is presented. 3.2 Software independent behavior modeling For virtual commissioning (see chapter 4) a digital model of the production plant is needed. As well as real production plants, the digital model that is developed during the production engineering process consists of mechatronic objects. The smallest units (objects) within production engineering are so called components. These components normally are standard parts and purchase parts like robots, clamps or motors. For the mechanical aspects of these components (geometry, kinematics) normally digital representations are delivered by the manufacturer so that they are available in the production engineering process. In contrast, behavior models (necessary for virtual commissioning) of these components normally are not available. So the development of component-specific behavior models for virtual commissioning predominantly is a time-consuming and error-prone process.
Basis for the plant-specific behavior model generation is the library of component-specific behavior models. This library initially is independent from the user’s company, i.e. company neutral. In a second step, the component-specific behavior models are combined to functional, companyspecific modules. These modules usually represent companywide standardized resources, for example a robot with its controller or a conveyor. In the company-specific behavior model library these modules are characterized by standardized signal names and interfaces to other modules or controllers for virtual commissioning. With the standardized module-specific behavior library and the results of the functional engineering it is now possible to generate the plant-specific behavior model automatically. Thereto primarily the module list (which modules are used in the plant and how are they named) and plant-specific parameter sets (e.g. rotation speed of a particular drive, address range of a robot) are necessary. With the company-specific rules of the functional engineering standard and a generator (e.g. MS Excel tool) the connections between different modules and to the PLC can be generated automatically. The whole creation process of plant-specific behavior models is illustrated in figure 4.
CE
L
Functional engineering
LL
FL
Plant-specific behavior model
Drive 0815 M
+
BML
FI
CN
CL
ML
SL
CS
Generator
CL: Components level CEL: Cell level CN: Company neutral
ML: Module level LL: Line level CS: Company specific
SL: Station Level FL: Factory level BML: Behavior Model Library
Figure 4. Creation process of behavior models
Although much progress has been made in this topic in recent years, there are still some open issues that have to be solved in order to develop all benefits that can be gained by using this new simulation methodology. Relating to the entire production lifecycle, the main benefits of virtual commissioning are for example: • • • • • •
More efficient PLC programming and debugging Accelerated and more robust production ramp-ups Higher degree of soft- and hardware maturity at start of production (SOP) Operator trainings before SOP Higher availability of the manufacturing systems during running production More efficient integration processes during running production
Preparation phase
Digital product data (3D geometry) Mechatronic plant model Real control data (Hard-/ software, interfaces)
Execution phase Organization
Compared to the technology lifecycle model published in (Gausemeier, 2001), the method of virtual commissioning is a so-called key methodology that will be an important competitive advantage in the future. However, this new methodology is still an expert application that is currently only used for special production facilities in a selective way.
Virtual commissioning
Evaluation phase
Validated PLC program (incl. interactions to RCs) Validated interaction of mechanics, electrics and control Validated system behavior
Procedure
As published in (Kiefer, 2009), virtual commissioning describes a methodology for validating and optimizing real control programs (e.g. PLC, RC, HMI) and the whole system behavior (e.g. the cross-function interaction inside a production system) without having the real production facilities. Due to the necessary hybrid data inputs in the form of digital product and resource as well as real control data, the simulation method of virtual commissioning is also frequently referred to a transfer from the digital to the real factory.
IT architecture
4.1. Goals and concept
To take advantage of all these benefits in a most profitable way, a digital data model is required that represents not only the mechanical but also the electrical and functional portions of the real production facilities in a sufficiently exact way. Due to its contained information, this integrated data model is to be called mechatronic plant model. As illustrated in Fig. 7, apart from the mechatronic plant model, digital product as well as real control data are the necessary inputs for realizing virtual commissioning projects (preparation phase). Furthermore, Fig. 7 also portrays the main influencing variables on the execution of virtual commissioning as for example the IT architecture during runtime, the concrete validation goals as well as organizational issues (responsibility areas etc.).
Validation goals
4. VIRTUAL COMMISSIONING
Fig. 7. Virtual commissioning – Phases, data flows and inputs/ outputs
4.2. Mechatronic plant model Today, the crucial factor in accomplishing virtual commissioning projects as profitable as possible is not the technical execution itself but the development process of the needed mechatronic plant model: This preparation phase is currently characterized by a mostly manual, error-prone and time-consuming process. At Daimler, an engineering workflow for generating the mechatronic plant model as efficient as possible was developed, which main characteristics are illustrated in the following sections. As shown in Fig. 8, the mechatronic plant model is fundamentally composed of two corresponding parts: the extended 3D geometry model on the one hand and the control-oriented behavior model on the other hand. DIGITAL FACTORY
REAL FACTORY
Production engineering
Production
OU 1
OU 2
OU 3
OU n
Mechanical design (3D CAD model)
Electrical design (Function group list)
Control design (signal lists, bus structure)
Repair & maintenance Integration processes
AutomationML Control equipment
Mechatronic plant model Extended 3D geometry model
3D geometry Kinematics Material flow Sensors
OU: Organizational Unit
Signal exchange
Behavior model
x:= y+1; if z then else … y:= z;
PLC Behavior models Motion data PLC/ RC input/ output signals
PLC: Programmable Logic Controller
RC RC: Robot Controller
Fig. 8. Virtual commissioning – Data supply and workflow Depending on the company-specific strategy (goals of virtual commissioning, used IT architecture etc.), the mechatronic plant model can either consist of: one integrated data model (integration of the extended 3D geometry model and control-oriented behavior model in one common data model) or • two separate data models (as depicted in Fig. 8), which communicate over corresponding system interfaces during the execution phase. Each of these two strategies has their individual strengths and weaknesses. Last but not least, the strategic decision depends both on company- and tool-specific boundary conditions and can therefore only be made individually by each company. Relating to the second strategy, one possible virtual commissioning architecture is illustrated in Fig. 9. In this example, the IT systems WinMOD (behavior model) and Invision (extended 3D geometry model) are used. •
Fig. 9. Virtual commissioning architecture with WinMOD and Invision The approach of using one integrated data model as base for virtual commissioning was presented in (Kiefer, 2008). In the following, the engineering workflow for developing the mechatronic plant model according to the second strategy focusing the extended 3D geometry model is illustrated. As portrayed in Fig. 8, the extended 3D geometry model consists of different data sets such as 3D geometry, kinematics, material flow and sensor information. Due to profitability aspects, the crucial goal is to perform the development process of this data model as efficient as possible. The proposed solution mainly bases of the development and the integration of two core issues: Early use of 3D CAD models including mechatronic aspects • Use of a system-independent, cross-functional data exchange format for data transfer According to a typical frontloading procedure, the 3D CAD models normally used in mechanical design (e.g. fixtures, grippers) have to be enhanced with additional mechatronic information. Base of this mechatronic-oriented design process is the existence of standardized mechatronic components (e.g. clamps, robots, sensors). In order to allow a companywide access to these newly configured objects, all these mechatronic units are made available to the related departments in the form of a centrally organized mechatronic component library. In contrast to today's mechanical CAD models, the mechatronic components does not just solely consists of the pure 3D CAD model but also of kinematics (including end positions) and electrical information as for example the electrical name of the respective device. After taking the projectneutral mechatronic components from the library, the responsible department (e.g. the Tooling Design) only has to tailor them to their special installation situations in the respective production system (e.g. adaptation of the electrical name). •
After developing and validating the mechatronic CAD model of the production system, this data model has to be transferred to the used CAD-oriented IT system for virtual commissioning. In this context, two general cases have to be distinguished:
a) The used IT systems (3D CAD/ virtual commissioning system) are from the same IT vendor b) b) The used IT systems are not from the same IT vendor In case a), a seamless data exchange between the IT systems based on the vendor-specific proprietary data interfaces is normally given. Representatives of this one vendor solution are for example the companies Dassault Systèmes (CATIA/ DELMIA V5) and Siemens PLM Software (NX, Process Simulate). The situation in case b) is totally different. In the past, there was no possibility to exchange cross-functional data models between two IT systems (of different IT vendors) without loss of information. In order to improve this unsatisfactory situation, as mentioned in chapter three, the tool-neutral crossfunctional data exchange format AutomationML is being developed. Using this open data exchange format, the mechatronic CAD models can be completely exchanged between the considered heterogeneous IT systems without data loss.
5. SUMMARY AND OUTLOOK In this contribution, three mechatronic-based applications are introduced: Functional engineering, data exchange via AutomationML and virtual commissioning. Apart from the most important characteristics of these innovative solutions, the individual engineering workflows as well as the links between these topics are illustrated both from a scientificand user-oriented point of view. So far, a majority of the pictured aspects could be successfully executed using real production-related examples in the field of automotive industry. At present, the seamless implementation with the special focus on profitability aspects is being verified and evaluated critically. Although much progress has been made in these mechatronic-oriented topic fields, following issues still remain to be addressed in further activities: Further developments and industrialization of the open crossfunctional data exchange format AutomationML as base for the seamless data integration between the fields of digital factory and automation engineering. Organizational issues (e.g. definition of tasks distributions and responsibility areas, cooperation models between the OEM and their suppliers) have to be critically analyzed and adapted to these new mechatronic-oriented production engineering topics ACKNOWLEDGEMENT Parts of the presented activities and results are developed within the scope of the European Union research grant MyCar – Flexible Assembly Processes for the Car of the Third Millennium (NMP2-CT-2006-026631). More information about this project is available at: http://www.mycar-project.eu.
REFERENCES Drath, R., Lueder, A., Peschke, J., Hundt, L. (2008). AutomationML – the glue for seamless Automation Engineering. Proceedings of the 13th IEEE International Conference on Emerging Technologies and Factory Automation – ETFA 2008. Hamburg, Germany. pp. 616623. Gausemeier, J., Ebbesmeyer, P., Kallmeyer, F. (2001). Produktinnovation. Carl Hanser Verlag. Munich, Germany. Hirzle, A., Alonso Garcia, A., Burkhardt, A. (2008). Steuerungstechnische Standards als Fundament für die Leittechnik. atp - Automatisierungstechnische Praxis 9/2008. pp. 42-47. Kiefer, J., Baer, T., Bley, H. (2008). Mechatronic-Oriented Design of Automated Manufacturing Systems in the Automotive Body Shop. Proceedings of the 10th International Design Conference - DESIGN 2008. D. Marjanovic (Ed.). Dubrovnik, Croatia. pp. 1295-1302. Kiefer, J., Ollinger, L., Bergert, M. (2009). Virtuelle Inbetriebnahme - Standardisierte Verhaltensmodellierung mechatronischer Betriebsmittel im automobilen Karosserierohbau. atp - Automatisierungstechnische Praxis, 7/2009. pp. 40-46. Kiefer, J., Prieur, M., Schmidgall, G., Baer, T. (2009). Digital Planning and Validation of Highly Flexible Manufacturing Systems in the Automotive Body Shop. Proceedings of the 42nd CIRP International Seminar on Manufacturing Systems - ICMS 2009. Grenoble, France.