Overview of Technology and Functionality Standards for Digitalization in Mechanical Engineering

1. Introduction

At the Hannover Messe in 2015, Joe Kaeser, CEO of Siemens, made the following much-quoted statement:

"Industry 4.0 is a revolution that will define the 2020s. It will change entire business models and industry worldwide"

This was more than seven years ago. In the meantime, there has been a large selection of books and publications on the topic of Industry 4.0 and the international term IoT. These mainly deal with the generalist or strategic use and the focus on the business model or the effects of the change brought about by Industry 4.0 on these, see Figure 1 and Figure 2.

The machine or mechanical engineering itself, as the centrepiece and data supplier, is given little attention in the publications on Industry 4.0 or is treated as a subordinate criterion. One reason for this is the far-reaching approach to the topic of IoT or Industry 4.0. In the studies published on this topic, mechanical engineering is viewed as a homogeneous unit in which, for example, construction machinery is treated in the same way as precision machinery or no differentiation is made between mechanical engineering companies in a corporate environment and Small and medium-sized enterprises (SME). However, this rough generalisation does not allow sufficient conclusions to be drawn about the true situation in the mechanical engineering sector.

The aim of this paper is to identify the technologies and functions of digitalization in the transition to the Industry 4.0 environment based on existing literature. The main focus of the thesis is on machines and mechanical engineering as an independent party. Both the phase of the third industrial revolution and that of the fourth industrial revolution are considered, as these partially overlap. Due to the focus on machines and mechanical engineering and the long amortisation periods in this area, the technological standard is regarded as given and reproduced here. While the requirements for functionalities, in relation to the technological standards, are regarded as undefined and the research basis and dissemination are progressing rapidly.

2. Digitalization and Industry 4.0

In the following, the concepts of digitalization and Industry 4.0 are explained for a better understanding, as well as how they interlock.

The term digitalization, particularly in the industrial environment, is defined by two aspects: The transfer of analogue available information into a digital form as well as its storage, forwarding and the use of this very information to generate greater benefits by means of software applications. [1,2]

"Industry 4.0 refers to the intelligent networking of machines and processes in industry with the help of information and communication technology." [3] and was adopted as a term by the German Federal Government in 2011 [4]. In the international environment, the terms IoT (Internet of Things) [5] and IIoT (Industrial Internet of Things) [6] are used. Regardless of this, all of these terms are collective terms with a strong marketing character [7,8].

There is agreement on the term Industry 4.0 mainly in the distinction between the previous development stages, mechanisation, mass production and automation, and the fourth stage, which stands for itself conceptually Figure 3.

It is important to note that both terms, digitalization and Industry 4.0, are intertwined and are difficult to differentiate from one another, see Figure 4.

3. Paper Scope

The focus of the work is on the identification of functionalities and technologies of digitalization with Industry 4.0 reference, which are directly connected to the machine see Figure 5.

Technologies and functionality are only related to digitalization and Industry 4.0 if they can be maintained through communication or networking with other systems [10,11]. IT solutions that are designed as stand-alone solutions are not included [12].

For the machine, the core competence lies in receiving data from other physical or virtual sources, in processing and generating new or additional information and in passing this information on to physical or virtual recipients see Figure 6. [13,14] While the interpretation of the data and the measures derived from it lie outside the core competence of the machine. This lies in network-based services [15,16] which are either provided by third parties or made available directly by the machine manufacturer in the form of digital tools (apps) as a separate product [17,18].

The distinction between technology and functionality with regard to digitalization and Industry 4.0 is based on the question: How is it possible? - Which corresponds to the question of the necessary technology and the question: What should be achieved? - Which corresponds to the consideration of functionality [19].

In terms of literature, the thesis will focus on German literature, as the term Industry 4.0 was characterize in Germany [4] and mechanical engineering and the manufacturing/processing industry are highly relevant to the German economy as a whole [20]. In addition, where reference is made to literature or literature research is carried out, an attempt is made to compare this with English-language literature or to evaluate the derived statements with English-language literature.

4. Technologies

How communication between machine and software can be established corresponds to the question of technology. A distinction can be made between the hardware aspect and the type of communication [21].

Depending on the age of the machine, the requirements for the quality of the data and the financial scope of the user, there are different options for data acquisition on the machine [22]. As a result, the options used for the physical components of the machines to communicate with other systems vary greatly. From connecting the machine and sensors using I/O modules, the simplest solution for converting analogue data from the machine into digital information, to direct integration Programmable logic controllers (PLC) into data acquisition. [23,24]

Regardless of the physical component via which the communication is implemented, the way in which the recorded information can be made available to the outside world differs greatly depending on the age of the solution used [25]. "The limiting factor for application in manufacturing today, however, lies in the interfaces between production facilities and cloud infrastructures" [26].

A. 

Hardware in the transition between Industry 3.0 and Industry 4.0

At the beginning of the development of data transmission in the 1980s, information was transmitted between machines and software systems via separate hardware interfaces. [27] Individual market participants tried to establish standards based on their own components. Common formats were e.g. TTY (Teletype) or MPI/DP [28,29]

With the rise of the home PC and the spread of the Internet in the mid-1980s, Ethernet and thus the CAT cable became the norm, with the standard RJ-45 connector also became established in industrial applications [30]. Colloquially, the combination is referred to as LAN.

With the introduction of driverless transport systems and the use of tablets and mobile phones in the industrial environment, WLAN technology is also gaining in importance. However, it is rarely used in the area of data transmission from machines, as the requirements for availability, latency and connection security are high, which can usually only be ensured by expensive industrial WLAN networks. [32] In addition to these technical thresholds, the standard installation of WLAN modules directly in/on the machines is not yet very widespread, which means that LAN connections are used, which are now available on every modern machine. The use of 5G technology is generally in its infancy and so far there are neither use cases nor reliable data on the benefits and costs of this technology in the field of machine communication cf. [33,34]. [35]

With regard to the question of how data is collected, two phases must be considered. At the beginning of digitalization, there was a strong focus on fast and simple linking of machines [36]. I/O modules or I/O links were used for this purpose. This involves the installation of separate, machine-independent hardware for recording and converting electrical and physical signals into digital information. This is a fieldbus-neutral standardised point-to-point connection. This separate hardware has a network connection via the information is provided. [37]

Machines produced after the year 2000 usually have an integrated (LAN) network connection. [38] This is either contained in the control system (PLC) and is used to transfer information. Alternatively, there are also solutions in which physical server systems are linked to the controllers. In these cases, services are already provided by the machine in addition to the pure data [39].

B. 

Communication standards between Industry 3.0 and Industry 4.0

When it comes to communication, the question of how data is interpreted in a standardised way between sender and receiver must be resolved. At the beginning of digitalization, data was sent via fieldbus-neutral, standardised point-to-point connections using telegrams [36]. [37]

As development progressed, further options for machine communication with IT systems were developed. Some of these were further developments of existing technologies and protocols from the previous automation phase, as well as new developments. [25] The types of communication that became established in the field of machine communication were the possibility of communication via TCP/IP and UDP. Machine communication via TCP/IP involves several protocols for data transmission from machine to IT system. [40] The modelling is based on the ISO/OSI reference model, whereby the TCP/IP model represents a condensation see Figure 7. [41]

This connection of protocols is very important because, among other things, it forms the basis of Internet communication. It includes Ethernet, which describes both the hardware configuration itself and the protocol used to ensure network access. The IP protocol, which forms the basis of the other protocols and takes on the task of switching from sender to receiver, and the TCP protocol, which splits up the individual data blocks and reassembles them correctly on the receiver side. In addition, the TCP protocol has the ability to request lost data packets again. [40]

Machine communication via UDP is a method that is similar to the TCP/IP protocol. The major difference from the point of view of machine communication to the TCP/IP protocol is that with UDP there is no bidirectional communication with the receiver, but the data is provided once by the sender and a new request for a data packet, e.g. in the event of loss or inconsistency on the part of the receiver, is not possible. The advantage of this method is that larger quantities can be provided more quickly with less bandwidth. [42]

C. 

Machine communication in the transition from Industry 3.0 to Industry 4.0

In the following section, the procedure for data exchange from machine to higher-level software system in the transition period from Industry 3.0 to Industry 4.0 will be explained using the examples of EUROMAP 63 [43] and HTTP [44].

One example of machine communication that was developed directly by machine builders in the 1990s is EUROMAP 63 for the plastics industry. This uses the CCP protocol in which, among other things, network communication using TCP/IP and data exchange is described [45]. [46] In practical application, this means that a data package or programme file is created by the machine, e.g. ".csv", and stored in a folder on the machine or on a server or, in the case of bidirectional communication, retrieved from the folder by the machine [47]. The type of file as well as the data content including syntax are created directly in the machine controller by the protocol implemented on it. With this type of communication, the result is defined via the standardised protocol and the implementation is left solely to the machine manufacturer. [46]

Another example of communication in the transition period between Industry 3.0 and Industry 4.0 of data exchange from machine to higher-level software system is communication via HTTP (Hypertext Transfer Protocol). Although its development predates the World Wide Web, it only became relevant with its breakthrough in the 1980s. Existing World Wide Web structures and protocols, including TCP/IP, for example, are used for machine communication without there being a standard for the data content. With this approach, the type of communication is specified, but the content must be agreed between the customer or software manufacturer and the machine manufacturer [48]. [49] In addition to the specification of the data content, it should be noted that data exchange via HTTP is unencrypted; this was solved by the successor protocol HTTPS (Hypertext Transfer Protocol Secure) from 1994, which is still common today [50].

D. 

Industry 4.0 communication standard OPC UA

Since the mid-2010s, machine communication via OPC UA has established itself as the standard for new machines [51,52] regardless of whether they communicate with IT systems or with other machines (M2M). OPC UA is subject to continuous further development [53] based on the TCP/IP protocol and following the OSI model [54]. The aim of OPC UA is to create a way to transfer data in a manufacturer-independent, standardised way. Care was taken to avoid the weaknesses of older protocols, including platform dependency and security vulnerabilities [55]. [56] The framework conditions for this are defined by the OPC Foundation, an association of various stakeholders from industry and research. The standardisation carried out by the OPC Foundation is limited to the definition of basic structures, which still leave machine manufacturers the option of individual design. [57]. In addition, standardisation offers the possibility of developing so-called Companion Specifications. These are information models with which machine signals and other information modules can be defined, depending on the type of industry in which the machine is to be used [58]. Examples of such specifications are the "OPC for Machinery" [59] which applies to mechanical engineering in general, the "EUROMAP 77" [60] or "OPC-40083" [61] for the plastics processing industry and the "OPC-40600 Weihenstephan Standards" in the food and packaging industry [62].

The ability to flexibly adapt OPC UA to future requirements is ensured by the manufacturer independence of both the hardware and the machine software, as well as the expandability to include new communication protocols and programming languages for implementation.

This flexibility and independence, which characterises OPC UA, allows the systems of all controller manufacturers to be used. All leading control system manufacturers have now developed and offer applications for OPC UA communication [63,64,65,66]. However, it is also possible to use third-party systems as long as they are able to access the controller itself [67]. The decisive factor for this decision is the desired degree of harmonisation of the IT infrastructure.

1)

OPC UA machine communication

When communicating data from machines to IT systems, OPC UA uses either a server-client architecture [54] or the so-called PubSub method [59]. In the much more widespread server-client architecture, the machine is usually the server while the IT system is the client [68]. The server on the machine allows queries and conditions to be generated directly from the raw data of the machine and thus forms an initial filter. The client’s implementation in the area of IT systems has the advantage that different software agents can access the server’s data independently. However, it is also possible that both server and client are implemented in the IT systems, whereby in this case the central (aggregation) server serves as a middleware for forwarding data, see Figure 8. [69]

In machine-to-machine (M2M) communication, both machines can act as both server and client, see Figure 9. [70]

With the PubSub method, data can be provided by different machines or senders (publishers) and retrieved by one or more data processors (subscribers) via a message broker, depending on the network architecture, in contrast to the client-server system. [71,72]

2)

Data structures in OPC UA

"OPC UA provides a structure with which complex information can be represented as objects in an address space. These objects consist of nodes that are connected by references.

Different classes of nodes convey different semantics. These include variable nodes that have a value that can be read or written and have an associated data type that defines the value. Or method nodes that represent a function that can be called.

Each node has a number of attributes, including a unique identifier known as NodeId and a non-localised name known as BrowseName.

Object and variable nodes represent instances and always refer to a type definition node (object type or variable type) that describes their semantics and structure. The type nodes are templates that define all "children" that can be present in an instance of the type. Within a type, the BrowseNames uniquely identify the "children". This means that client applications can be designed in such a way that they search for subordinate elements using the BrowseNames of the type instead of NodeIds. This eliminates the need to manually reconfigure systems when a client uses types that are implemented by multiple servers. OPC UA also supports the concept of subtyping. This allows a modeller to take an existing type and extend it." See Figure 1. [11]

Figure 11. Objects in OPC UA [74].

Figure 11. Objects in OPC UA [74].

3)

Advantages and added value of OPC UA for mechanical engineering

The benefits of using OPC UA for machine builders can be summarised as follows.

• Spread and increasing acceptance of OPC UA as a communication standard between machines and higher-level software systems
• Generally defined structures for creating models for processing and transferring data from machines to higher-level systems
• Expandability of the structure due to modularity and object-orientation
• Industry-specific company specifications (CS) are provided for special cases in the respective industry sector
• Independence of the overall OPC UA concept for hardware and software
• Integrated security architecture for data exchange [75,76,77]

4)

Limitation of OPC UA

Like all technical systems, OPC UA has defined use cases, which are achieved, among other things, when data needs to be exchanged at high speed. This involves data that needs to be captured and processed at intervals of a few milliseconds. The realisation of deterministic communication using server-client systems is around 200 milliseconds, depending on the hardware and software. Intervals shorter than 200 milliseconds harbour the risk of data loss or inconsistency in data processing, as shown in the studies by Pott & Dietz [78] and Nakutis et al. [79] have shown. The reason for this limit is the latency between the individual systems that are linked using OPC UA. This means that OPC UA is not real-time capable with the current standard server-client configuration and is therefore not suitable for monitoring and controlling robots, for example, with control intervals in the range of 10 - 15 milliseconds. [80] This disadvantage can be eliminated in the future with the use of PubSub methods and or TSN [81]. [82]

5. IT Functionalities in the Field of Mechanical Engineering

Functionality refers to "the property of a thing of being very well suited to the purpose for which it was designed" [83]. In this chapter, the IT functionalities that are directly related to the machines and are therefore relevant for mechanical engineers who want to become active in the field of digitalization and Industry 4.0 will be determined and described on the basis of scientific publications.

A. 

Determination of relevant IT functionalities

To determine the relevant topics, discussions were held with people from the fields of mechanical engineering, production management and production software in order to gain an impression of the range of functions and functional requirements. The functionalities identified were then compared with and evaluated in anthologies on the topic of Industry 4.0 with different focal points.

The evaluation was carried out using a three-level categorisation from zero to two, whereby the categorisation was carried out as follows

2 = Is explicitly dealt with in connection with machines

1 = Mentioned in connection with I 4.0 or digitalization

0 = No mention

(Appendix A Table A1)

The summed values then allow an assessment of the relevance of the functionality as well as the relevance of the collective work to the overarching topic Overview of technology and functionality standards of Digitalization in mechanical engineering.

In addition, a keyword search was carried out via "Google Scholar" for the number of publications on the relevant functionalities in both German and English. Depending on the result, a specific term was searched for, and if the number of hits was low, the procedure was repeated with a simplification (secondary term). With this procedure, it occurred that publications were also counted that come from a subject area other than the one referred to, especially when searching with secondary terms in English-speaking language. A search was therefore carried out using the same system in the digital library IEEE Xplore, an English-language library for the subject areas of computer science, electrical engineering and electronics and related areas (Appendix B Table A2).

B. 

Functional description

The following section describes the functionalities identified and explains their relevance and categorisation in relation to mechanical engineering. The order is roughly based on the chronological order in which the functionalities appear.

1)

Remote management / Remote access / Teleservice

Remote management or the synonyms remote access and teleservice refer to the possibility of remotely accessing the control of a machine, reading and/or exchanging information or taking over the control of the machine [84].

The relevance of this topic for mechanical engineering becomes clear when you consider that teleservice needs to be considered right from the design phase. "In order to be able to offer customers faster fault diagnosis, a more efficient repair service and better advice, it is necessary to be able to monitor the operating status of your own products while they are in use at the customer’s premises. For such efficient teleservice solutions, the machines for which teleservice is offered as a product-accompanying service should be designed from the outset" [85]. The topic itself has been known for some time [86]. However, in the years of the corona pandemic and due to the progressive shortage of skilled labour, new impulses have been set which have led to both the market-ready further development of existing concepts and to new collaborations between classic machine component manufacturers and new market participants for mechanical engineering. [87]. This development has led to the availability of well-functioning plug and play systems that can be used by machine builders to establish a remote connection to machines [88,89]. The current challenge in this area for mechanical engineering arises from the fact that people from outside the company are granted access to machines and possibly the company network [90,91]. The associated risks for machine manufacturers and their customers, in an age in which not only criminals but also states attack IoT networks, cannot be neglected [92,93].

As the use of such systems is established in the field of mechanical engineering and saves costs for both customers and machine manufacturers, [94] such systems are standard for mechanical engineering companies involved in digitalization [95].

2)

Machine data collection (MDC)

Machine data collection or Machine data acquisition contains, in contrast to process data and condition monitoring data, rudimentary signals from the machine that provide information about the operational status and production performance of a machine [96].

MDC data are the basic elements of the digitalization of production, as they are sent automatically to higher-level systems and the information, supplemented with other data, forms the basis for all further evaluations of the machine [97]. It is generally a prerequisite for all further Industry 4.0 technologies. [98,99,100] "The MDC module provides real-time data from production. Monitoring and alarming in particular, but also maintenance, traceability or detailed planning, use the data provided by the MDC." [101]. [102], [103] The minimum requirements for an MDC are the collection of data to determine availability and performance, which means data on production time, good part quantities and scrap quantities, as they are also used, for example, to determine acceptance-relevant key figures [104]. This data can be collected via I/O modules. For machines with directly integrated MDC, additional information on the status of the machine can be recorded here, e.g. production interruption, malfunction and cause of malfunction. This allows the OEE (Overall Equipment Effectiveness) and its individual elements to be determined in higher-level systems without further human intervention. [105]

For the machine manufacturer dealing with the topic of digitalization & Industry 4.0, this means that a machine must provide this data in a common data format, since, as already mentioned, MDC forms the basis of digitalization.

3)

Energy & consumption data acquisition

Energy and consumption data acquisition, with regard to the use of machines, involves data that is collected on consumables that are used and measured directly on the machine. [106]

Examples of direct variables are power consumption, water consumption, gas consumption, etc., which are recorded both during production and downtime [107]. While indirect variables such as the "carbon foodprint" are determined outside the machine [108]. Depending on the industrial sector, there are legal requirements that define which data has to be collected, such as “Energy Efficiency Directive 2012/27/EU” [109] or “Industrial Emissions Directive 2010/75/EU” [110]. Parallel to this, there are also industry standards that define what should or must be recorded [111]. In addition to the legal requirements, however, more and more companies have an interest in recording the consumption data of their machines. Either to reduce consumption or to fulfil their own ambition to operate more sustainably [112,113]. There are separate hardware components for recording this data [114,115] which can be installed independently of the machine manufacturer. For machines that already have the appropriate internal hardware, this information can also be provided via the control system [60].

As legal and social requirements in this area will continue to increase [116] it makes sense for mechanical engineering companies to expand their sensor technology in this respect and to provide data on energy and media consumption in an open and standardised form. Depending on the industry and the size of the machine buyers, it may also make sense to provide software modules that interpret this data [117].

4)

Process data acquisition

"With process data acquisition, the production process itself is monitored and the respective states are recorded. The process data can be used for evaluation or for further processing in a control loop" [96]. For new machines and systems, the data of the environment and the production parameters are recorded directly for the product to be manufactured [118].

This usually serves the purpose of quality assurance or continuous process optimisation. This can involve data that is generated and influenced directly at the machine, such as speeds, injection pressure and feed rate, as well as data that is recorded purely for documentation purposes, such as material temperature, material flow and viscosity from the product being processed. These are recorded by the machine’s sensors and passed on to higher-level systems via its control system. [119] In addition to these variables that can be directly assigned to the product, environmental parameters are also recorded, including, for example, humidity and room temperature, which are transmitted to the machine via separate sensors. [120]

For mechanical engineering, process data can be a unique selling point compared to software providers, as the processes cannot be generalised on the same scale as the previous topics. Machine builders, especially manufacturers of individual machines and small series, usually know the specific processes of their systems and the corresponding requirements of their customers very well, which allows them to provide a generalised data offering that is individualised for the customer. [121]

5)

Condition Monitoring

With condition monitoring, the focus is on the machine itself, in contrast to process data acquisition, which is why data is collected over the entire service life of a machine. [122]

Information such as force, power and pressure curves or the vibration behaviour of individual machine components is recorded via sensors and forwarded to higher-level systems where the analysis takes place [123]. [124] Machine builders can determine which individual elements should be monitored using classic FMEA (Failure Mode and Effects Analysis) [125] based on empirical values or, if available, failure statistics. The correct choice of data filter must be considered, which must already be applied in the signal generation in the machine. The signals can be subdivided into data to be recorded permanently, snapshots or the observation of maxima. [126,127] In all this cases the machine has the role of data generation and forwarding. [128]

As there are no legal requirements for condition monitoring, condition monitoring is difficult to realise and amortise as a functionality for machine manufacturers, apart from specific customer requirements [129] In addition, there are competitors from the software sector who sell corresponding sensor modules in a package with software applications [130]. However, condition monitoring forms the basis for the "preventive maintenance" described in the following chapter, which can become an exclusive business area of machine construction. [131]

6)

Predictive maintenance

The topic of predictive maintenance in the context of digitalization or Industry 4.0 is made possible by functioning condition monitoring. The aim is to predict when individual components will fail based on data collected by the machine itself or with sensors connected to the machine [132].

Determining the failure scenarios requires a large amount of data on failure scenarios that must already be available [133]. For ongoing operation, it is also necessary to collect and store the data required to determine the probability of failure of a machine over very long periods of time, time intervals of several months but also over several years are not uncommon [134,135].

The advantage of this Industry 4.0 functionality for the machine manufacturer compared to the other Industry 4.0 functionalities presented is that it is a software application based on machine information. It can be used to directly realise new business models in mechanical engineering that can be integrated into the existing value chain of machine manufacturers. For example, maintenance and spare parts supply contracts based on failure forecasts. This offers the customer the benefit of increasing the availability of his machine and reducing the need to maintain his own resources, as well as reducing costs for machine builders who can optimise the use of their own capacities through better utilisation and additional income through support activities. [90,135,136]. The necessary IT infrastructure and database expertise can be provided by the machine manufacturer itself, by third parties or, in the case of larger company units, directly by the customer itself. [137]

7)

Order management

As a cumulative data point of information processing in production, the order is of particular importance as a link between the producing element, the machine, and the recording systems. [138]

Therefore, a machine operating in such a network must also be able to receive, process and forward order information to other network participants. How the order and the associated information is handled is heavily dependent on the requirements of the respective authorisation concept of the manufacturing company and the production IT infrastructure which is used there [139]. This makes the implementation of order management on a machine more difficult and two aspects must therefore be taken into account for the machine manufacturer. [140]

Firstly, the degree of automation with which the decision to select the specific order is to be made by the customer [141]. Most companies are in the range between Level 2 - "The technology offers a complete list of possible alternatives" and Level 5 - "The preferred alternative is executed if confirmed by a human". Higher levels can only be achieved by companies that also use other automated systems that do not require any further human interaction, such as AI-supported detailed planning or autonomously operating production networks. [142] This aspect defines the physical elements for data selection and provision as well as the type of data processing in a machine.

Secondly, the data structure, which in most cases is specified by higher-level systems, mainly derived from the master data of the ERP system [143] but can differ due to different production concepts such as series production, batch production, single-part production, etc. [144]. Current interfaces for individual industries have already taken this on board and developed structures. [62,74] Several cross-industry specifications are currently being developed with the aim of providing a homogeneous definition for order data structures for machine manufacturers [59,145].

8)

Distributed Numerical Control (DNC)

Distributed Numerical Control or Programme management refers to the assignment of a machine programme to the machine, depending on the product to be manufactured and other parameters such as the machine itself, tool, raw material, etc. [146]

On machines with programme management, as soon as the frame parameters are known, the corresponding programme is loaded from a storage location onto the machine and released for production. [147] The advantage of this type of programme management is that it is rule-based and therefore it is also possible to ensure that only approved programmes are used. Furthermore, it reduces the effort and complexity in production itself, as the organisation, allocation and transport of physical storage media, such as memory cards, is no longer necessary. [148]

For the machine manufacturer, it should be noted that it is not absolutely necessary that the machine programmes themselves are readable for the functionality that controls the exchange, but only that the machine programme is clearly identifiable and there is a possibility of exchange. [149]

9)

Product tracking and batch recording

Batch recording and product tracking is a process that is strongly characterised by legal aspects and serves to reduce recalls and recourse costs. [150].

For implementation, the data on production, preliminary products and raw materials and, if applicable, customer allocation must be available and be able to be allocated to the individual product or batch. [151] Normally, the primary information ’batch’ is not produced by the machine, but is taken from other systems and expanded into a new data set [152]. However, the machine must be able to record, process and supplement data. To do this, the data is either collected manually via an HMI, external sensors such as RFID readers, barcode scanners, camera systems or provided by another system. [153] The batch data can then be forwarded to the higher-level IT system to provide an overview of the product. [154]

The machine usually serves as an intermediary for the data between the element to be recorded and higher-level systems. The reason why data is recorded at the machine is that batch data can no longer be resolved after processing in the case of incoming batches [155] while the generation of outgoing batches directly after the production process ensures that all production process data is recorded with batches [156].

10)

Tool data acquisition

Like batch recording, tool data recording on the machine is a function in which data recorded as part of other functionalities is added to a new set.

While the place of origin is decisive for batch recording, in tool management it is the fact that, on the one hand, the tool is currently, in a few cases, able to record and forward data to itself [157,158]. Another aspect is that a large part of the data required to manage the tools is generated redundantly during processing on the machine. [159] However, tools have a major influence on production and production quality.

However, since you do not collect any data yourself, but use data from the machine, it is sufficient from the machine builder’s point of view if the machine builder also records and communicates the tool currently in use via the machine [160]. Further processing and storage can then take place in separate systems [161]. [159]

11)

Recording of personnel data

Personnel data acquisition at the machine is relevant when data requiring documentation can be added to or manipulated directly at the machine and forwarded from there to other systems. This includes the machine programmes, specification of statuses, maintenance data and order information. [162]

It must be ensured that it is possible to attribute the manipulation of the data to an employee. The recording of personnel data on machines is subject to the documentation obligation with regard to traceability on the part of the legislator and the end customer [163] and not personnel data recording in the sense of personnel management and personnel controlling, which are subject to labour law or business management aspects compare to Schimmelpfeng [164], Wienkamp [165] & Wojak [166]. The employee can be recorded at a machine either by directly entering the identification element, e.g. clear name, ID number, personnel number, etc., on a machine HMI, [167] via separate hardware elements such as RFID token readers [168] or the information is forwarded directly to the machine from a third-party system, e.g. MES, time recording, etc. [169]

The integration of appropriate hardware and software interfaces by Recording of personnel data is the primary requirement for the machine manufacturer.

In addition to the software applications listed in the previous paragraphs, there are others from the field of mechanical engineering that will not be discussed further. These are applications that are relevant for specific machine types, such as integrated QA and visualisation solutions that cannot be generalised [170]. Furthermore, machine-related software applications that exceed the development capacities of traditional mechanical engineering companies or whose development stage and market penetration are still in their infancy, such as the topic of digital twins or AI-based applications.

6. Research for Industry Transfer

In the following chapter, the state of research on the implementation of the functionalities described in the previous chapter in practice will be determined. The focus here is on empirical data on the implementation and application of the functionalities mentioned.

A. 

Procedure

A multi-stage literature search was used to determine the current state of knowledge for implementing the functionalities described.

In the first step, "Google Scholar" was used to query publications with the search terms "survey" "Industry 4.0" "mechanical engineering" in German for the period of 3 years and the texts were analysed, evaluated and classified for data with corresponding content. The evaluation was based on a four-level categorisation, which was carried out as follows

• Category 1: Publications on the topic of Industry 4.0 in which the areas of mechanical engineering and production are explicitly considered
• Category 2: Publications in which survey results deal with tactical topics and individual overarching functional aspects from the field of mechanical engineering. Examples of this are [171,172]
• Category 3: Publications in which survey results deal with strategic or tactical topics in the field of mechanical engineering, functionality aspects are not considered. Examples of this are [173,174]
• Category 4: Publications that focus on topics outside of mechanical engineering or where no statistically usable data is available. [175]

The query was then conducted in English and, due to the higher number of publications, randomly analysed for convergence with the first query.

In order to take the individual functionality aspects into account, the query was repeated with the search terms "survey" "mechanical engineering" and the corresponding functionality term and divided into three categories.

• Category 1: Publications in which the survey explicitly considers the functionality aspects of the field in relation to mechanical engineering or production
• Category 2: Publications in which the survey considers functionality aspects
• Category 3: Publications with the wrong thematic focus or no statistically usable data available

At the same time, a search was carried out in “Statista”, a German-language library for statistical publications, for any publications with the terms "Industry 4.0 and mechanical engineering" and the tags "machinery and plant engineering" and "Industry 4.0".

B. 

Result

The following section summarises the results of the research from section 6.1 is summarised below.

Publications "Google Scholar" with the search terms "survey" "Industrie 4.0" "mechanical engineering" in German in the period 3 years to 31 October 2023, n = 435 Figure 12: Publications on statistics and surveys on the topic of Industry 4.0 and mechanical engineering

Publications "Google Scholar" with the search terms "Survey" "Industry 4.0" "Mechanical engineering" in English in the period 3 years to 31 October 2023, 16100. sample n = 30 Figure 13: Sample of publications on statistics and surveys on the topic of Industry 4.0 and mechanical engineering

Publications "Google Scholar" "Survey" "Mechanical engineering" and the corresponding functionality term in German in the period 3 years to 31 October 2023 Figure 14: Publications surveys on functionality terms (German)

The search carried out in Statista for the period 2023 to 2016 with the terms "Industry 4.0 and mechanical engineering" and the tags "machinery and plant engineering" and "Industry 4.0" resulted in 50 hits, which can be classified into two categories, statistics that deal with the topic strategically/generalistically n=29 and statistics unrelated to the topic n=21. However, the 29 strategic/generalist statistics can be traced back to 7 publishers, Statista, Bitkom, EY, Commerzbank, Fraunhofer, Horvath & Partner and McKinsey. Statistics that explicitly deal with the functions of machines with regard to Industry 4.0 could not be found in Statista.

Overall, very little statistical material on the use of software in the manufacturing industry was found across all searches for scientific publications. The few sources that were available mostly had a commercial rather than a technical background.

7. Conclusions

The aim of the work was to identify the topics relevant to mechanical engineering with a focus on technology and functionality in the area of digitalization and Industry 4.0, with particular attention to implementation. To this end, reference architectures relating to these topics were analysed and summarised in terms of content and statistics.

As the work on the terms Industry 4.0 and digitalisation shows on the basis of the smooth transitions, the revolution mentioned in the field of mechanical engineering or Industry 4.0 is more of an evolution than a revolution, as a large part of the technology and function already existed before the definition of the term and has adapted to the further development of the technology. As can be deduced from the technological development, a technological standard has been established in mechanical engineering both on the hardware side with Ethernet and in the area of data communication with OPC UA.The 11 functionalities identified and presented form, at this point in time, a basis that a machine manufacturer must master in the current market environment or at least work on implementing. To avoid being substituted by software or third-party providers and losing control of their product. The main drivers for the functions are legal requirements and customer demands. From the perspective of machine manufacturers, the IT functionalities required by legislators and customers are mostly requirements for the pure provision of data. However, machine manufacturers should also show an interest in further developing their own products and services and putting themselves in a position to amortise this development themselves. This applies in particular to those functionalities where the data becomes relevant for their own new services.

What the study also showed is that the theoretical knowledge is available, as are lighthouse projects that have been developed in co-operation between research and practice. However, in terms of implementation, there is little statistically data relating to the identified functionalities in mechanical engineering or its individual sectors.

From a scientific perspective, the collection of statistically data for the implementation and validation of Industry 4.0 technologies in mechanical engineering is the next necessary step. Otherwise, there is a risk that research will establish too high expectations based on the state of research and "early bird" companies, which will miss the actual needs and opportunities. In addition, possible obstacles and challenges must be identified that hinder both the dissemination of the functionalities among mechanical engineering companies and their use by their customers.