China
Africa
Explore chapters and articles related to this topic
Interoperability of Manufacturing Control and Web Based Facility Management Systems: Trends, Technologies, & Case Studies
Published in Barney L. Capehart, Timothy Middelkoop, Paul J. Allen, David C. Green, Handbook of Web Based Energy Information and Control Systems, 2020
The current state–of-the art of OPC has fully embraced the use of internet and web technologies in the OPC Unified Architecture (OPC UA) standard. OPC UA took all of the various first generation standards for Data Access, Historical Data Access, Alarm & Events, etc and has unified them into a common standard. Redundant code and specifications were eliminated, and rich information models are now possible using OPC UA.
Robot Programming
Published in Marina Indri, Roberto Oboe, Mechatronics and Robotics, 2020
Christian Schlegel, Dennis Stampfer, Alex Lotz, Matthias Lutz
Another example of such ecosystem tiers is the OPC UA ecosystem. The OPC Unified Architecture (OPC UA) with all its elements for modeling machine data, its communication stack to access and transport them, and the related predefined application programming interfaces (APIs) forms the overall frame and thus, is located at Tier 1. The ecosystem driver at Tier 1 managing and keeping things consistent is the OPC Foundation. However, this is just the basic frame, which still gives too much freedom, as everybody can invent their own information model for a device. At the end, all device interfaces are based on OPC UA, but devices of the same category from different vendors all use different information models. In consequence, one can still not replace one device by another one without adjusting the software that speaks to a device. This is where Tier 2 comes into the game: Companion Specifications define how to use the elements of Tier 1 in a particular domain. By that, as long as you conform to a specific companion specification, you speak OPC UA in the same way as the others do in that domain. Of course, the domain covered by a companion specification should not be too small, as then you end up with just a single manufacturer with its devices. It should also not be too broad, as then agreement across domains needs to be achieved, which is nearly impossible. Naturally, that is a continuous process with constant moderation as for example, a companion specification in robotics has links via coordinate systems to companion specifications of vision systems. The same kind of link exists between companion specifications for manipulators and those for grippers as you finally mount a gripper to a manipulator. Finally, at Tier 3, there are all the different devices that speak OPC UA and express their conformance to specific companion specifications so that you immediately know how to use that device and by which others you can replace it without reprogramming your software to talk to it.
Digital twin for smart manufacturing: a review of concepts towards a practical industrial implementation
Published in International Journal of Computer Integrated Manufacturing, 2021
Luca Lattanzi, Roberto Raffaeli, Margherita Peruzzini, Marcello Pellicciari
A first issue in deploying the Digital Twin vision is related to production resources data access. Synchronization and consistency between the physical and the virtual worlds must be ensured. How to implement proper two-way communication protocols still represents an open issue, strictly related to the need for standardized connection and communication means, so to unify data formats, as well as their representation and exchange. OPC Unified Architecture (OPC-UA) is a well-known and widespread machine-to-machine communication protocol for information exchange among industrial automation systems and equipment, that targets the definition of an integral information model for data collection and control.
Communication method for manufacturing services in a cyber–physical manufacturing cloud
Published in International Journal of Computer Integrated Manufacturing, 2018
S. M. Nahian Al Sunny, Xiaoqing F. Liu, Md Rakib Shahriar
OLE for Process Control (OPC) is a significant of many manufacturing networks at higher levels by offering a standardised interface for communication of industrial data. Maintained by the OPC Foundation, The OPC specification has combined object linking and embedding (OLE), component object model (COM), and distributed component object model (DCOM) technologies developed by Microsoft (Leitner and Mahnke 2006). The OPC specification outlined a standard set of objects, interfaces, and methods for use in process control and manufacturing automation applications to facilitate interoperability. OPC data access (OPC DA) is the most commonly used OPC specification, which is used to read and write real-time data. It allows real-time communication of process values over Ethernet with a client-server model. Several other variants of OPC have also been developed, including OPC historical data access which permits for acquiring stored values, OPC data exchange for two-way communication using a server-server model and OPC XML Data Access, which uses XML for communication. Later in 2006, the OPC Unified Architecture (OPC UA) has been specified and was being tested and implemented through its Early Adopters program. OPC UA (IEC 62541) combines the functionality of the existing OPC interfaces with new technologies such as XML and Web Services to deliver higher level manufacturing execution system (MES) and enterprise resource planning (ERP) support. OPC and OPC UA provided the opportunity of accessing machine tool not only from factory floor but also from outside the factory. In recent years, MTConnect has acquired much acknowledgements after the release of its version 1.0 in 2008 (Vijayaraghavan et al. 2008). MTConnect is designed to enhance interoperability of manufacturing machines by providing a uniform XML-based data reporting structure. It is fundamentally a read-only framework, i.e. its principal focus is data monitoring and analysis. MTConnect enables manufacturing machines to be monitored over the Internet. The primary objective of MTConnect is to create a universal machine language that is understandable to all machines and also to the users. MTConnect provides a RESTful interface – there is no need of establishing any session or logon/logoff sequence to acquire data. As MTConnect is not designed for any specific type of machines, several types of manufacturing resources such as CNC machine, industrial robot, milling machine, 3D printer (Liu, Sunny, et al. 2016) currently are made compatible with MTConnect standard. In 2010, The OPC Foundation and the MTConnect Institute declared a cooperation to ensure interoperability and consistency between the two standards (ThomasNet 2010). AutomationML (Automation Markup Language) is another promising upcoming open standard series (IEC 62714) for the description of production plants and plant components (Drath et al. 2008). AutomationML describes the contents – what is exchanged between the parties and systems involved. It helps to model plants and plant components with their skills, topology, interfaces, and relations to others, geometry, kinematics, and even logic and behaviour. A joint working group of the AutomationML e.V. and the OPC Foundation deals with the creation of a companion specification ‘AutomationML in OPC UA’ (Henssen and Schleipen 2014).