846 M A T E R I A L S E V A L U A T I O N • J U L Y 2 0 2 0 interaction and could be used for operator interfaces to store and read information regarding the component to be inspected. Low-latency and low-jitter communication is not necessary for typical NDE equipment therefore, DDS will not be considered further. OPC UA, being the standard protocol for manufacturing and due to its included semantic interoperability, seems like the ideal interface for NDE 4.0. OPC UA The high-level communication protocol/framework currently established in the manufacturing Industry 4.0 world is OPC UA (OPC Foundation 2019a IEC 2010–2019). OPC UA has its origin in the component object model (COM) and the object linking and embedding (OLE) protocol. OLE was developed by Microsoft to enable users to link or embed objects created with one program into another and is used extensively within Microsoft Office. COM is a technique developed by Microsoft for inter-process communication under Windows (introduced in 1992 with Windows 3.1). This standardized COM interface allows any program to communicate with another without having to define an interface separately. With the distributed component object model (DCOM), the possi- bility was created that COM can also communicate via computer networks. Based on these interfaces, a standardized software inter- face, OLE for process control (OPC), was created in 1996, which enabled operating system independent data exchange (such as for systems without Windows) in automation tech- nology between applications from different manufacturers. Shortly after the publication of the first OPC specification, the OPC Foundation was founded, which is responsible for the further development of this standard. The first version of the OPC Unified Architecture (OPC UA) was released in 2006. OPC UA differs from OPC in its ability to not only transport machine data, but also to describe it semantically in a machine-readable way. At the same time, the abbreviation OPC was redefined as open platform communications. OPC UA uses either TCP/IP for the binary protocol (OSI layer 4) or simple object access protocol (SOAP) for web services (OSI layer 7) (see Figures 6 and 7). Both client- server and PubSub architectures are supported by the OPC UA communication framework. Based on this, OPC UA imple- ments a security layer with authentication and authorization, encryption, and data integrity through signing. APIs are offered to easily implement OPC UA in programs. In the .net frame- work, OPC UA is even an integrated component. This means that the users do not have to worry about how the information is transmitted. This is done completely in the OPC UA framework (referred to as “Infrastructure” in Figure 8). The only thing that matters is what information is transmitted. As Figure 8 shows, the OPC information model already defines some basic core information models in which models are defined that are required in many applications. In addition, companion specifications exist for product classes ME TECHNICAL PAPER w nde 4.0: perception and reality Vendor-specific extensions Companion information models (for example, FDI, robots, scales, NDE) Core information models (for example, analog data, alarms, state machines, file transfer) Information model-building blocks (meta model) Information model access Browse and access data and semantics, execute methods, configure Data and event notifications Client-server Use case-specific protocol mappings PubSub Figure 8. OPC UA architecture (© Vrana GmbH, based on OPC Foundation 2019b and used with permission).

J U L Y 2 0 2 0 • M A T E R I A L S E V A L U A T I O N 847 such as field devices, robots, or scales. These companion spec- ifications provide semantic interoperability and are therefore the basis for Industry 4.0, ensuring smooth Industry 4.0 inter- faces and communication, and result in any OPC UA–enabled device being able to interpret data from others. In addition, there may also be manufacturer-specific specifications for the exchange of data between the devices of one manufacturer. OPC UA PubSub integrates DDS into OPC UA to enable one-to-many and many-to-many communications. Moreover, the OPC UA time sensitive network will make it possible to transfer data in real time and to extend OPC UA to the field level. The OPC UA specifications are also currently being converted into national Chinese and Korean standards. Moreover, it is planned to start the development of an NDE companion specification for OPC UA in a joint project between DGZfP, VDMA (Verband Deutscher Maschinen- und Anlagenbau, the German Mechanical Engineering Industry Association), and the OPC Foundation. OPC UA is, like HL7 in health care, the standard for an interface to the manufacturing Industry 4.0 world. Similar to medical diagnostics, large amounts of data can be generated with NDE (in OPC UA, larger files are split into smaller packages—for example, the OPC UA C++ toolkit has a maximum size of 16 MB). Computed tomography, auto- mated UT, and eddy current testing can easily result in several GB per day that need to be archived long-term. In the health care sector, large data files have resulted in the development of digital imaging and communications in medicine (DICOM) alongside HL7. DICOM DICOM is an open standard with semantic interoperability for the storage and communication of documents, images, video, signal data, and the associated metadata, as well as for order and status communication with the corresponding devices. This enables interoperability between systems from different vendors, which is what Industry 4.0 is striving for. In health management, this leads to the necessity of inter- faces between HL7 and DICOM (Figure 9). This interface is usually found in the picture archiving and communication system (PACS) server. In this process, patient and job data are translated from HL7 to DICOM for communication to the imaging devices. Information about the order status and provided services (such as “X-ray image of the lung”), as well as written findings and storage locations of the associated images, are communicated back. The returned data, texts, and references would usually be referred to in industry as KPIs. The central system for the “process logic” in hospitals is the hospital information system (HIS) (comparable to an ERP system in industry), which communicates with all other systems via HL7. All image, video, and signal data are stored in DICOM format in PACS, which is designed to handle large amounts of data and serves as the central system for archiving and communicating the data. HL7 DICOM CD production for patients Doctor Patients Referring doctor CHC Historical data Picture archiving and communication system (PACS) Images videos, signal data Images, CT MRI Angiography X-ray Ultrasound Status information Worklist Laboratory, OR planning, etc. Hospital information system (HIS) Radiology information system (RIS) Hospital Registration, updates Accounting Notification Findings Findings Planning, updates Figure 9. Interaction between HL7 and DICOM (© VISUS Industry IT GmbH, Germany, used with permission).