Views
6 years ago

Automation Technologies 3/2015

  • Text
  • Automation
  • Technologies
Automation Technologies 3/2015

COMPONENTS AND SOFTWARE

COMPONENTS AND SOFTWARE Integrated engineering reduces errors and costs Olaf Graeser, Josef Schmelter No matter if it’s a car, a multifunctional printer, or a new control cabinet – whenever there is a new development, the first step is product engineering. Combining established standards such as AutomationML and eClass facilitates an integrated process that not only avoids errors but also reduces costs. Author: Dipl.-Inf. Olaf Graeser, Technology Development & Industrial Automation, Manufacturing Solutions; Phoenix Contact GmbH & Co. KG, Blomberg, Germany Dipl.-Ing. Josef Schmelter, Master Specialist for Classification, Product Lifecycle Management, Phoenix Contact GmbH & Co. KG, Blomberg, Germany W hen a product is developed, this is a process that entails a lot more than just one engineering software tool. More often than not, there are several tools, each optimized for different tasks. This kind of development approach is known as an engineering chain. Because the engineering tools are each dedicated to different challenges, they have their own set of rules and specialized language. As a result, the data formats of the individual tools are not compatible with each other, and they certainly do not share a semantics definition. Also, there are only very few interfaces available for interconnecting these specialized software tools. As part of the engineering process, therefore, a lot of time is spent on transferring data from one format to another. It would make a lot more sense if there were a standardized data format shared by all of the engineering tools. Neither the eClass classification standard nor AutomationML is designed to satisfy this need, which makes each of them unsuitable as a sole shared format that can be used for both storing and exchanging planning data. Taken together, however, the two standards can be integrated with each other to facilitate a cohesive engineering platform. AUTOMATION TECHNOLOGIES 3/2015

COMPONENTS AND SOFTWARE About Company name: Phoenix Contact GmbH & Co. KG Headquarters: Blomberg, Germany Turnover: €1.77 bn (2014) Employees: 14,000 worldwide Products: Products, systems, and solutions for all aspects of electrical engineering and automation next page All engineering tools, one shared data format The engineering of a control cabinet e.g., involves creating a circuit diagram, selecting components to suit this circuit diagram, and planning the mechanical assembly as well as the wiring of the control cabinet. The sequence in which the engineering tools need to be used is often not stated explicitly but dictated by circumstance. As a first step, for example, the circuit diagram might be created using a tool that includes an interface to the product configurators of the electronic components. Later, the circuit diagram might stipulate the use of a pre-assembled terminal strip, which needs to be made known to assembly planning. The assembly planning structure, in turn, serves as a basis for the wiring layout. Interfaces for engineering chains such as this do indeed exist today; however, they usually only go in a single direction. Even very small revisions, such as exchanging a terminal block for another connection component, can cause a disproportionate amount of reworking. If there are no interfaces in place at all, the conversion of the project data can get very complicated, frequently involving manual data transfers. Also, as data passes through the various engineering tools, important details may be dropped. As a result, the detailed information from the product configurators often fails to make it through to the wiring planning stage. It would therefore be beneficial if all engineering tools were using the same data format. This way, there would be no need for format conversions and the data loss these often entail. A shared format would also make it easier for data to exit the engineering chain. However, a shared data format necessitates a uniform definition of all the aspects included in the chain – a so-called semantics definition. If this does not exist, it may be that the tools cannot talk to each other even though they share the same data format. Precise article description AutomationML is an XML-based exchange format for engineering data that brings together other existing data formats. CAEX (Computer Aided Engineering Exchange) acts as the outer bracket to map the system’s topology; from there, other standardized formats such as Collada (Collaborative Design Activity) and PLCopen XML can be referenced. Originally, AutomationML was only intended for describing plants and systems. However, the format was soon also found to be useful for describing the articles produced by the plants. With an article description scheme as precise as this one, it is possible to develop intelligent technical systems such as those currently being planned in the context of Industry 4.0. These systems can independently identify the manufacturing stations required for producing the article. Phoenix Contact is therefore deploying AutomationML as part of its AWaPro top cluster project (Automation for Adaptable Production Technology). 01 CAEX serves as the core format within AutomationML’s format architecture; from here, other formats such as Collada and PLCopen XML can be referenced AUTOMATION TECHNOLOGIES 3/2015

E-PAPER KIOSK: