Technology Category
- Functional Applications - Enterprise Resource Planning Systems (ERP)
- Infrastructure as a Service (IaaS)
- Networks & Connectivity - Gateways
Applicable Functions
- Discrete Manufacturing
Use Cases
- Manufacturing System Automation
The Challenge
The discrete manufacturing domain is characterized by a strictly hierarchical structure of the automation systems, commonly referred to as the automation pyramid. Data acquired by a sensor typically flows through an IO-module into a Programmable Logic Controller (PLC) which manages the local real-time control system. As all process data are concentrated in the PLC, re-programming the PLC and thus, implementing interfaces to access these data appear to be the natural choice to transfer them to the IT system. However, for brownfield installations this choice has proven impracticable for the following two reasons:
In brownfield facilities, PLC usually operate within a once-specified environment and are rarely re-programmed. That is why the active staff is often not familiar with the code and lacks of the competence to modify the existing implementation in a reasonable amount of time.
Furthermore, for cost reasons, any PLC was selected to exactly match the requirements of the environment within which it was intended to operate. That is why it cannot be assumed that a PLC will be able to support additional tasks such as communicating data through additional interfaces.
The Solution
*This is an IIC testbed currently in progress.*
LEAD MEMBERS
TE Connectivity, SAP SE
SUPPORTING MEMBERS
ifm, OPC Foundation
MARKET SEGMENT
Discrete manufacturing
This testbed implements an alternative solution by substituting IO-modules that connect the sensors with the real-time automation system by a gateway that extracts the sensor data and transfers them to the IT system through an additional communication channel via OPC UA (IEC 62541). This “Y-Gateway” re-uses existing physical connectivity and supports the easy integration of an IO-Link sensor with the IT by using a common device model based on an open standard (the IO Device Description which is based on ISO 15745-1) and thus enables the remote configuration of the sensor. This common device model is implemented through Manufacturing Data Objects in SAP Manufacturing Integration and Intelligence (SAP MII).
TESTBED INTRODUCTION
This testbed is essentially about implementing a sensor’s virtual representation at platform tier level by
1. A hardware component that establishes a separate OT/IT communication to deliver sensor data to the IT systems and to receive configuration data.
2. The implementation of a common device model based on an open standard that enables the control and manipulation of the physical device from within the IT systems.
This testbed uses open standards for the OT/IT communication, the sensor devices and the common device model:
• IO-Link is standardized as IEC 61131-9:2013 Programmable controllers - Part 9: Single-drop digital communication interface for small sensors and actuators (SDCI).
• OPC UA is standardized within the IEC 62541 OPC Unified Architecture series.
• The IO Device Description (IODD) is based on ISO 15745-1:2003 Industrial automation systems and integration – Open systems application integration framework – Part 1: Generic reference description
As IO-Link is also based on the IODD, there is a consistent device description from the IT to the sensor level – supported through the semantics-independent data transfer provided by OPC UA – that allows for the easy configuration of a sensor and the interoperability with a large range of devices and analytic services.
LEAD MEMBERS
TE Connectivity, SAP SE
SUPPORTING MEMBERS
ifm, OPC Foundation
MARKET SEGMENT
Discrete manufacturing
This testbed implements an alternative solution by substituting IO-modules that connect the sensors with the real-time automation system by a gateway that extracts the sensor data and transfers them to the IT system through an additional communication channel via OPC UA (IEC 62541). This “Y-Gateway” re-uses existing physical connectivity and supports the easy integration of an IO-Link sensor with the IT by using a common device model based on an open standard (the IO Device Description which is based on ISO 15745-1) and thus enables the remote configuration of the sensor. This common device model is implemented through Manufacturing Data Objects in SAP Manufacturing Integration and Intelligence (SAP MII).
TESTBED INTRODUCTION
This testbed is essentially about implementing a sensor’s virtual representation at platform tier level by
1. A hardware component that establishes a separate OT/IT communication to deliver sensor data to the IT systems and to receive configuration data.
2. The implementation of a common device model based on an open standard that enables the control and manipulation of the physical device from within the IT systems.
This testbed uses open standards for the OT/IT communication, the sensor devices and the common device model:
• IO-Link is standardized as IEC 61131-9:2013 Programmable controllers - Part 9: Single-drop digital communication interface for small sensors and actuators (SDCI).
• OPC UA is standardized within the IEC 62541 OPC Unified Architecture series.
• The IO Device Description (IODD) is based on ISO 15745-1:2003 Industrial automation systems and integration – Open systems application integration framework – Part 1: Generic reference description
As IO-Link is also based on the IODD, there is a consistent device description from the IT to the sensor level – supported through the semantics-independent data transfer provided by OPC UA – that allows for the easy configuration of a sensor and the interoperability with a large range of devices and analytic services.
Operational Impact
Case Study missing?
Start adding your own!
Register with your work email and create a new case study profile for your business.
Related Case Studies.
Case Study
Plastic Spoons Case study: Injection Moulding
In order to meet customer expectations by supplying a wide variety of packaging units, from 36 to 1000 spoons per package, a new production and packaging line needed to be built. DeSter wanted to achieve higher production capacity, lower cycle time and a high degree of operator friendliness with this new production line.
Case Study
Robot Saves Money and Time for US Custom Molding Company
Injection Technology (Itech) is a custom molder for a variety of clients that require precision plastic parts for such products as electric meter covers, dental appliance cases and spools. With 95 employees operating 23 molding machines in a 30,000 square foot plant, Itech wanted to reduce man hours and increase efficiency.
Case Study
Fully Automated Visual Inspection System
Tofflon has developed a fully automatic machine that uses light to inspect vials, medicine bottles, or infusion containers for glass fragments, aluminum particles, rubber grains, hairs, fibers, or other contaminants. It also detects damaged containers with cracks or inclusions (microscopic imperfections), automatically removing faulty or contaminated products. In order to cover all production processes for freeze-dried pharmaceuticals, Tofflon needed to create an open, consistent, and module-based automation concept.
Case Study
SAP Leonardo Enabling Rocket Science
At times, ULA has as many as 15 different operating systems dedicated to overlapping processes, such as rocket design, testing, and launch. Multiple systems created unnecessary costs and unwanted confusion among workers at offices, factories, and launch sites in different location. In order to improve collaboration and transparency during vital activities that directly influence mission success, ULA wanted to improve data sharing and streamline manufacturing processes.
Case Study
Human–Robot Control
Industry 4.0 is changing the way manufacturing industry operates. Increasingly more manufacturers are leveraging advanced technologies such as robotics and automation systems to improve productivity and efficiency. As a result, human–machine interfaces (HMIs) are becoming more important in their role in the digital connectedness of humans and machines. However, using the wrong HMI can lengthen development times and increase implementation costs.
Case Study
Smart Factory Solutions for Tobacco Industries: Bridging the Manufacturing Generation Gap and Improving Operational Efficiency
The tobacco industry, represented in this case by British American Tobacco (BAT), is facing a decline in cigarette volumes worldwide. This decline has led to an increased emphasis on efficient supply chains and optimized production processes. The industry is also grappling with the need for agile production facilities and the integration of Industry 4.0 to accommodate diverse production requirements. BAT, in particular, was seeking a factory solution to automate their product control processes, from the transportation of tobacco and cigarette paper to the placement on cigarette machines and the packing conveyor. The company also needed to support the continuous use of legacy equipment, such as relay-controlled cigarette machines dating back to the 90s and AMK servo drive systems, to sustain production levels at speeds of 8000 to 16000 pieces per minute. Furthermore, changing regulatory guidelines necessitated flexibility in labeling requirements.