INTRODUCTION

Manufacturing is experiencing a significant and difficult change. The rapid revolution of technology conflicts with the evolutionary pace of adaptation and implementation. This dichotomy between the revolution and evolution is unfolding in the digital transformations occurring now in manufacturing. This new transformational era is called the Fourth Industrial Revolution, or to use the term coined in 2011, Industry 4.0 (I4.0).

Just as previous industrial revolutions disrupted manufacturing, Industry 4.0 brings significant change to factories. The change is especially challenging because I4.0 is transforming all aspects of the factory while building on top of the previous industrial revolutions.

The interchangeable parts that created effortless assembly in the first industrial revolution are now the communication protocols transferring data seamlessly between distinct software systems. The massive volumes of data generated by manufacturing processes have succeeded in the mass production of assembly lines since the second industrial revolution. Industry 4.0 supercharges and connects the computers, robots, and controllers brought to manufacturing in the third industrial revolution. The creation of these complex cyber-physical systems is what defines and distinguishes the fourth industrial revolution from the third.

Integrating technologies, digital data, and the people involved is the challenge manufacturers must overcome today. The first two industrial revolutions combined new inventions with the people operating these processes. The third industrial revolution introduced a triad, adding the digital data generated from these systems. Much like Henry Ford’s assembly lines amplified the concept of interchangeable parts, the cyber-physical network of I4.0 accelerated and expanded the computer, robotic, and controller technologies developed in the previous industrial revolution. Manufacturing is digitally transforming, and companies must adapt.

I4.0 IS DIFFICULT TO EXECUTE

Industry 4.0 faces a dilemma in the speed dichotomy mentioned earlier. Research has highlighted the first decade of implementation of I4.0 has been poor. A McKinsey study showed 6 out of 10 manufacturers faced barriers so strong they achieved limited to no progress on their I4.0 initiatives. In 2018, a study of German industry showed 9% of companies were able to implement a comprehensive Industry 4.0 approach within their organization. In 2019, this dropped to 8% and by 2022 it was 7%. Numerous barriers have been identified as reasons for this low level of implementation: financial issues, organizational challenges, IT infrastructure maturity, company size, lack of employee skill sets, risk of security breaches, disruption to existing jobs, and general resistance to change. The lack of resources and employees’ competency and expertise are regularly identified as the most significant barriers for adopting I4.0.

Many barriers that manufacturers face today with Industry 4.0 parallel those encountered during the development of the assembly line in the second industrial revolution. Henry Ford pioneered the use of the assembly line to revolutionize automobile manufacturing in the early 1900s. By leveraging interchangeable parts and incorporating new technology, Ford upended the automobile industry. This transformation did not come easy. After much trial and error to perfect the assembly line in 1913, Ford immediately faced a worker shortage as employees left for competitors, complaining the work was now too simple and boring. Ford solved the technology problem, only to immediately be confronted with an employee culture problem. Ford’s success came from addressing both issues.

Today’s manufacturers will achieve the same success by merging the triad of the challenges they face: technology, data, and employees. To move forward, manufacturing management must understand how these three pieces fit together. A framework is needed to guide the connecting and communicating with equipment, collecting data, and providing it to employees to use. The human aspects of I4.0 must be fully appreciated by management. Following this technical and human framework will foster a data-driven culture that embraces the use of data in manufacturing.

The digitization of manufacturing brings programming and software front-and-center for factories, which historically are slow to adopt new technologies. Advances in areas like artificial intelligence (AI), machine learning (ML), and cyber security are difficult to fully understand, and change at blistering speeds.

Applying new technology, which constantly changes, creates hurdles for companies to find the right skill sets, train employees, and dedicate the financial resources required for I4.0. Manufacturing historically is centered around durable capital equipment. Installation of this type of hardware moves at a snail’s pace compared to improvements in AI.

Manufacturers in each of the industrial revolutions have faced this same dilemma. How do companies successfully implement the technologies and embed the culture needed to be successful with change? A roadmap or framework is needed to help guide manufacturing management.

I4.0 IS DIFFICULT TO DEFINE

One challenge for manufacturers is to define all the technologies encompassed in I4.0. Implementing I4.0 can mean different things to different companies. For one company, I4.0 could mean implementing virtual reality to help train maintenance employees. Another factory might implement the latest networked industrial robots to speed up production, while a third could utilize simulation software to predict outcomes in production processes.

Some technologies, like blockchain, rose and fell from prominence over a few short years but still are cited as I4.0 technologies. Others, like AI and ML continue to rapidly evolve with releases of large language models and other chat-bot applications. AM is often stated as a key I4.0 technology, which contrasts with pillars like cybersecurity, data analytics, and digital twins.

There are two key points to consider regarding I4.0 technologies. First, there is no universal definition associated with the number of technology pillars within Industry 4.0. Authors have their own opinion on groupings, numbers, and importance. Multiple publications state there are anywhere from four to 14 different I4.0 technology pillars. Second, the technology pillars are extremely diverse. Some of the technological pillars of I4.0 are not compatible with all companies. For example, a company does not have to implement blockchain or additive manufacturing (AM) to have successfully implemented I4.0, especially if these technologies do not add value to the organization. The diversity of these technologies makes it confusing to discuss the process of implementing I4.0 in industry, as the term can represent many different technologies.

I4.0’S BENEFITS CAN BE ACHIEVED

The benefits of I4.0 must outweigh the challenges associated with the implementation, given the industry’s drive to adopt these technologies. The author believes the revolution brought by I4.0 lies in fully integrating the equipment, data, and people involved in manufacturing to achieve a step-change improvement in productivity, uptime, and quality. This view is supported by literature highlighting the benefits of Industry 4.0. Ultimately, operational excellence will be achieved through the utilization of real-time, data-driven decision-making across all aspects of manufacturing. While some decisions will be automated through computers and machine learning, a significant portion of decisions, especially in the near term, will continue to rely on employees.

To narrow the scope within this publication, the I4.0 technologies focused here relate to data connection, collection, and consumption in building a connected, or smart factory. Gaining the benefits of I4.0 occurs only when the company’s employees are aligned with the technology being implemented. 

This paper introduces the 6C Framework for Building a Connected Factory. It emphasizes six unique phases: Criteria, Connect, Communicate, Collect, Consume and Culture.

The framework aims to assist manufacturing management in addressing both technical and human challenges associated with implementing Industry 4.0 technologies in a connected factory.

6C FRAMEWORK

The 6C Framework presented in this paper is derived from the author’s experience in implementing data collection, data analysis, and I4.0 technologies across various manufacturing factories and processes. Although other I4.0 frameworks exist, they are often highly strategic, conceptual, or academic. These frameworks lack the tactical details or practical roadmap that small- and medium-sized manufacturing facility can immediately use to implement I4.0. The 6C Framework aims to address these shortcomings.

The 6C Framework not only structures data collection and consumption in manufacturing factories but also serves as a roadmap. The 6C Framework starts with the human centered Criteria phase before moving to the technical Connect, Communicate, and Collect phases. The framework also recognizes the feedback loop that refines the data collection criteria based on company’s use of data in the Consume phase. This sequencing of phases facilitates the decision-making processes during the creation of a connected factory. Culture encircles all these phases and plays a critical part of the framework. As illustrated in Figure 1, the 6C Framework also functions as a process flow diagram.

CRITERIA

The first C in the framework is Criteria. Decisions made in this phase are crucial as they drive the rest of the data collection process, from equipment and sensors used to where data is stored and how employees use the data.

Criteria serves as the foundation upon which the entire data collection process is built. Its importance cannot be understated.
Criteria can be thought of as the design requirements of the data collection process. During this phase, all critical questions should be answered before the data collection process begins. This will avoid much wasted effort. If these questions are not addressed, the employees performing the work will have to make assumptions about what data is needed. These assumptions will never be 100% correct, which creates rework of the previously completed data collection once clarified. Common excuses heard when skipping the Criteria phase include this was not the right data, this was not collected at the right time, the data needed to be summarized by shift, that data should be collected at a higher frequency, this data does not show the problem, etc.

One common response from those attempting to shortcut this phase is to just collect everything. However, collecting everything is not a realistic solution. The volume of manufacturing data is overwhelming, even for basic manufacturing processes. To illustrate this, consider the simple process of sawing gating from a casting.

Gate Sawing Data. Aluminum die castings are formed by directing molten metal through gates. After the casting process, the gating system needs to be removed from the final product. In an automated diecasting cell, a large circular saw can be used to remove the gating. This section will explore the potential manufacturing data that could be generated from just this sawing process.
In any manufacturing process there are basic business metrics to be collected. These metrics include the number of parts produced or equipment uptime, which can be used to calculate parts per hour and utilization percentage. Often management needs this data enhanced with metadata including shift, part number, machine number, tooling or fixture information, operator name, calendar day, etc. This allows data to be summarized for management to see trends by these categories. Including this metadata is critical.

Often overlooked, the parameters setup in the equipment control are also valuable data, especially when comparing to the output results. Parameter sawing data can include the set point for revolutions per minute (RPM) and the feed rate of the shuttle. What if the typical run value for the saw is 2000 RPM, but one day it is running at 1800 RPM? This could be a trigger for maintenance on the saw. However, these results could also occur if an employee on a previous shift decided that a slower RPM would provide a longer saw blade life and made a change to the setting. This type of issue can quickly be identified by capturing the parameters setpoints from the equipment. Other manual parameter data, like the diameter or number of teeth on the saw blade, need to be captured as well. Those influence output data like amperage draw, saw blade life, and surface finish of the cut.

From a maintenance perspective, monitoring the RPM and amp draw of the motor during the cut is important. Since gate sizes vary, time-series data must be collected and analyzed. Determining the appropriate frequency for recording this data is necessary and will be discussed in the next section. Additionally, tracking manual processes occurring to the cell is essential to develop a comprehensive data story for the saw. Maintenance records need to be created and digitized to show date and time of saw blade changes, the specific saw blade style installed, and any maintenance work performed on the equipment during its life. These factors impact the RPM and amp draw during the cut. This data may be available through Enterprise Resource Planning (ERP) software or may require manual data entry. Understanding the potential data sources and being able to digitize data manually generated by employees is important.

Finally, if the goal is to collect everything then advanced sensors need to be considered. These sensors can measure the temperature of the casting as it enters the equipment and the saw blade temperature throughout the cut cycle. These temperature variables impact the saw blade’s life and motor’s power usage. Saw blade temperatures are also influenced by process changes such as longer time between cycles, start-of-shift warm-up, and duration of uptime on the saw. Thermal cameras can capture this type of data and provide outputs as seen in Figure 2. Infrared sensors, while more cost-effective, gather this data with less detail. The approach of collect everything lacks the necessary context and detail to determine which data collection device is appropriate for the specific problem data collection is helping address.

This gate sawing example illustrates the importance of clearly defining the Criteria for the data collection at the start of the process. Doing so can prevent unnecessary investment and installation of advanced sensors or time to develop connection patterns for data that may not be needed to solve the biggest problems associated with the process.

Collection Frequency. Data collection frequency is an important topic in Criteria. Time-series data will constitute the largest volume of data generated within manufacturing processes. In discrete manufacturing, like the sawing operation, the time-series data forms a routine pattern every time a specific part is processed. This is similar to an electrocardiogram (EKG) measuring a heartbeat––a repeating pattern of data that is consistent cycle-to-cycle. This heartbeat of data exists throughout manufacturing processes. It is found in the vibration of the spindle throughout the machining operation, the fluid flow for each spray cycle of a diecasting machine, the power draw as a motor starts, and the pressure of compacting a sand mold. 

A key question to consider during the Criteria phase is: “At what frequency should this data be collected?”

Continuing with the sawing example, Figure 3 shows a process photo of the casting in a sawing operation and a modeled depiction highlighting the gate areas for each cut zone. These number zones are referenced in Figure 4, which presents actual time-series data collected from multiple sawing cycles. As the cut enters and leaves a gate area, there is variable amp draw, and power needed for the cut. This variation is evident in Figure 4. These details would be lost if a statistical value, such as an average or maximum amp draw, were calculated to represent the time-series dataset. The true picture would not be known with these representative statistics.

There is no simple answer to the question “At what frequency does this data need to be collected?” Experience from previous data collection processes can provide guidelines, but each manufacturing process is unique. Data collection frequency needs to be discussed and possibly tested during the Criteria phase. Poor decisions on frequency can lead to erroneous data. High frequency data collection will require special sensors, hardware, communication protocols, and data storage impacting the Connect, Communicate, Collect phases.

Additionally, collecting too much data can result in unnecessary data points that do not add value in analysis. To contrast, if the frequency is too low, critical maximum values can be missed. Like any engineering decision, tradeoffs occur when determining data collection processes. Collecting everything is not an option.

Figure 5 illustrates the visual difference between various data collection frequencies. Data was collected at 100 millisecond (ms) data (10 Hz) during the sawing operation. This data heartbeat was processed to show how the graph would look at 500 ms (2 Hz) and 1000 ms (1 Hz) intervals. Max amp values and power, defined by the area under the curve, were calculated for each interval. The number of data points between 100 ms and 1000 ms was about 10 times smaller. With this, the max amp reading was approximately 20% less for the 1000 ms interval compared to the 100 ms, because the intervals missed the higher values compared to the higher frequency. The power values also were reduced by approximately 4% with the sampling difference. These details are presented in Table 1.

Criteria Questions. This relatively simple sawing process highlights the complexity of data collection that occurs in manufacturing. Building a connected factory requires significant upfront considerations to address these types of data questions. Failure to plan during the Criteria phase leads to mistakes and setbacks throughout the remaining phases of the framework. Each manufacturing process and data collection is unique. Therefore, a simple framework of 5W+H (Who, What, Where, Why, When, and How) can ensure the right questions are asked for any data collection process. A cross-functional project team, including those implementing the data collection process and those utilizing the data to solve problems, should be assembled to answer the questions found in Table 2. 

The Criteria phase is a human-centric part of the 6C Framework. While it involves many technical questions, its primary purpose it to clearly define the employees’ data needs and the decisions the data will drive. This foundation ensures the data collection process is focused and efficient. Decisions are made by employees and will impact employees. Defining the details ensures the data collected will address the problem and prevent excuses for not utilizing the data.

Finally, the effort and work during this phase create ownership of the collection process and the data generated. This buy-in fosters a desire among team members to see the data collection process succeed. They are engaged in the details and the future use of the data.

In contrast, a project where management says collect everything and then walks out of the room is destined to fail with limited ownership. Even an incredibly talented technical team will feel lost and incorrectly assume management’s objectives without the details being specified. People are a critical component of Industry 4.0, and the Criteria phase sets the foundation for the data collection process.

CONNECT

The Connect phase focuses on the technical aspects of hardware and software involved in generating data to be collected and stored. Manufacturing data sources are diverse. Sensors, humans, and software all create data. This phase includes various data patterns that can be followed based on the type of information being collected.

Sensors. The most common pattern in data collections involves a sensor and a controller. This basic technology has been around for a long time. The modern thermostat, which contains a temperature sensor and a controller for a heating source, was invented in the 1800s. The technology of monitoring conditions and reacting to them grew rapidly in the early 20th century. The advent of the computer and the acceleration of the Third Industrial Revolution enabled the storage of long-term digital data from sensors. The networking of I4.0 now allows for the connection, storage, and analysis of huge volumes of data from these sensors.

A simple definition of a sensor is an input device that measures a physical quantity and provides a signal as an output. There are dozens of types of sensors, measuring inputs such as temperature, pressure, humidity, acceleration, strain, light, infrared, sound, proximity, flow rate, and color, among others. Sensors can also be built into devices such thermal cameras, which provide a two-dimensional matrix of output datapoints, or laser scans, which provide three-dimensional points of a surface of the scanned part. Data comes in many different forms, and there are many sensors to capture the values.

Functionally, the sensor detects the changing physical characteristic, and it provides the output signal to a controller. These sensors are connected to PLCs (Programmable Logic Controllers) and other types of controllers to interpret the output signal. Much of the equipment that exists today in manufacturing factories has built-in sensors and controllers to facilitate the process of the equipment. For example, in a foundry furnace a temperature sensor can detect a drop in metal temperature. The controller monitoring this value then triggers the heating element to turn on to maintain a constant metal temperature.

A significant question for companies implementing a connected factory is if these sensors and controllers can be connected to and provide data outside the equipment through a network path to a database. If the connection can occur, the project can move to the next phases. If not, hardware additions, updates, or replacements are required to gain data access. Sensors provide valuable data related to the manufacturing process. However, process data is only one part of the overall data picture within manufacturing.

Programmed Logic. The next source of data to review is programmed logic data. Like sensor data, this data is generated within the controller of the equipment being monitored. The key difference is that programmed logic data is not tied to a physical input that is measured by a sensor. Instead, the data is generated from logic programmed into the controller. This concept is best explained through examples.

The first example of programmed logic data is a simple part count for production reporting. Collecting manufacturing business metrics is often an initial use-case for data collection. Sometimes, a sensor counts the part as it passes through, but this is not generally the approach used. Instead, the machine is programmed to recognize a specific action in the controller indicating the process is complete and ready for the next cycle. This could be a pour complete signal coming from the foundry robot or a M30 code in a CNC program. A trigger in the system’s logic informs the equipment that the part is finished and ready for the next one. The timing of this logic trigger becomes valuable information, which can be collected and converted into key business metrics to help manage the factory.

Another example is uptime data. Equipment controllers often operate in various states while processing parts.

Continuing the examples, a pouring robot might be waiting to start, filling the pouring ladle, or actively pouring the metal. Similarly, a CNC machine could be waiting to load a fixture, actively machining a part, or in an idle state waiting for the next part. The controller’s logic identifies the equipment’s current state and tracks state transactions. This data becomes valuable when associated with time, especially the total duration between state transitions. Now, data can be converted to information telling management the total amount of time per day the machine was running compared to idle.

These are just two examples. Additional programmed logic data include cycle time information between actions within the machine, the set points or recipe information for target values, and calculated values like heat index, which is derived from temperature, humidity, and dew point rather than a direct sensor reading. The key concept is this data is generated through the controller’s logic and not a sensor value.

Humans. The third data source to connect are the employees within the company. Currently, factories have many manually tracked spreadsheets or paper charts used for various purposes, including process inspections, quality checks, visual inspections, inventory counts, and test results. For a factory implementing I4.0, this data needs to be digitized and stored into databases for long-term access and dashboarding.

In the Connect phase for human data, hardware and software must be considered for data entry. Often the hardware is a computer or a mobile device like a tablet or cell phone. There are numerous software options for the front-end applications for this data entry. IoT platforms, which will be discussed in Collect, can often provide the means to develop these types of human data entry interfaces.

These data entry screens are typically tailored to specific needs of the data being captured. Figure 7, for example, shows a screen used to collect quality checks on slurry permeability in a foundry operation. Visual inspections or quality test results are often a key type of human data. The collection pattern for human data differs from sensors or programmed logic. Selecting the right software package allows for the team to easily develop applications to collect this data.

Software. The final data source in the Connect phase is data generated in different software systems. Both management and equipment software need to be considered. Management software includes systems like ERP, MES, time keeping, human resources, maintenance, sales, and scheduling, all of which are deployed by factories at different levels. Software is typically created by the OEMs (original equipment manufacturers) to control and store data from their equipment. Examples of these systems include CMM (coordinate measuring machines) software, which manages programming and data storage in one software package, and X-ray equipment that stores images during quality checks.

Additionally, with equipment manufacturers embracing I4.0 concepts and offering data services to their customers, many OEMs provide their own software that typically Connect, Communicate, and Collect the data from the equipment. This all-in-one solution simplifies many of the steps outlined in this framework. However, there are risks associated with this approach, such as limited access to raw data and connectivity issues with equipment brands outside of the OEM. Data is sometimes stored on OEM owned cloud servers, and the manufacturing company may only have access through pre-defined reports, without direct access to the raw data. This approach creates an income stream for the OEM, as they charge subscriptions for reporting and data storage. Years after installation, this approach can be a hurdle for factories looking to change equipment brands. Historical data could be lost or be expensive to transfer. Some equipment software is more open, allowing a company to store data on the factory’s server or provide interfaces to pull data on demand without additional cost. The variety of software strategies employed by OEMs necessitates companies to learn the details of the OEM data polices and ask many questions before selecting hardware and software.

The openness of data can be overlooked when management is deciding on a software system purchase. Before I4.0, this might not have been a significant factor since systems and data were not connected. With I4.0, this becomes critical. To highlight this importance, consider the following example. Imagine ERP software used for scheduling production orders and managing inventory levels. In a connected factory, this software can interface with the equipment, allowing information such as the number of parts produced to be exchanged between systems. This can update the ERP with the number of parts remaining on the order and add new parts to inventory. The two systems seamlessly communicate this information. In contrast, a non-connected factory relies on human data entry. An operator would have to manually count the number of parts produced during the shift and enter the information into the ERP software. If the operator makes a mistake, the schedule and inventory levels will be incorrect, potentially leading to incorrect ship dates, inventory losses, and additional production runs. Manual and repetitive tasks are prone to human error, whereas machine and computers do not make counting mistakes. The software systems companies decide on are more important than ever because of this system integration.

The four data sources discussed – sensors, programmed logic, humans, and software – each have unique patterns of hardware and software to consider in the Connect phase. This uniqueness introduces variability that management and the technical team must understand and adapt to when implementing data collection. The scale and complexity of options for sensors, controllers, and software needs to be appreciated. There are hundreds of sensor types, dozens of sensor brands, and numerous controller options, resulting in thousands of combinations of potential connection patterns. Additionally, these technologies and hardware evolve over time. A company making a sensor used today may not survive the next downturn, necessitating alternatives. Another challenge manufacturers face is that most existing factories contain equipment from various brands and processes which will require different data connection patterns. From a capital investment perspective, updating all the equipment with hardware to follow one pattern would be prohibitive.

Instead, manufacturers must hire skilled technical resources capable of managing this level of variation and be fluid in implementing different patterns throughout the factory. Ultimately, the data integration should appear seamless to the end user of the data. This is achieved only through careful planning in the Criteria phase and understanding and execution in the Connect phase.

COMMUNICATE

The Communicate phase serves as the bridge between the hardware and sensors that generate the data and the long- term storage of the data in the Collect phase. Two key factors are discussed in this phase. The first is the abundance of communication protocols that exist today. The second factor is understanding IoT Platforms, which are software that provide the connection between the hardware and the storage.

Communication Protocols. A protocol, as defined by NIST (National Institute of Standards and Technology), is a set of rules such as formats and procedures to implement and control some type of association between systems, such as communication.

Transferring data from a sensor to a database involves using various communication protocols. The data must be packaged in a format defined by a protocol to be sent through the system. There are protocols for addressing where the data is being sent within the network. Security, routing, and queuing protocols ensure safe and proper delivery of the data on this network. Transportation protocols define the flow of data through wires or airwaves. While all these protocols are critical to the success of data collection implementation, the focus in this work will be on two specific types of protocols.

The first protocol is the logistical aspects of moving data from the source to the storage. A decision must be made between wired or wireless connections to the hardware gathering the data. Wired connections offer robust solutions with better speed, lower latency, higher bandwidth, and more control and security over wireless connections. However, each new equipment requires a physical connection, taking time and cost to run network cables. Wired connections also face challenges with cable clutter and limited mobility. On the other hand, wireless connections eliminate the clutter and connection time but present challenges with security, bandwidth, speed, and throughput depending on the application.

Various protocols, such as Wi-Fi, cellular, and Bluetooth, can be used.

Manufacturing companies will eventually adopt a hybrid approach, utilizing both wire and wireless solutions. For critical, high-speed data collection, wired connections are preferred. For low speed, non-critical data, such as human-entered test results, wireless communication via a laptop will suffice. Each type has its trade-offs. This wired versus wireless decision should be made during the Criteria phase, ensuring the team can effectively execute the plan in the Communicate phase.

The second protocol manufacturers must consider is the application protocol, which dictates how devices communicate with each other. In the industrial data collection space, many commonly used protocols exist. A few different protocols include OPC UA, MQTT, REST API, HTTP, MTConnect, Modbus, BACnet, and Profibus. Each protocol was developed to help address specific shortcomings of the others. As with all engineering problems, trade-offs occur between choices. For example, low file size and bandwidth is extremely important in cellular data connections, while speed and robustness are more important in other scenarios.

For most manufacturers, the various equipment installed in their facilities will use different protocols. BACnet protocols are heavily used in building automation and heating, ventilation and cooling (HVAC) systems. Be prepared to use these protocols when trying to connect to HVAC systems to collect real-time energy use or temperature data within the factory. MTConnect is a popular protocol used in CNC machining equipment.

OPC UA or Modbus are commonly used by industrial PLCs found in manufacturing equipment. MQTT is a lightweight protocol often leveraged for wireless data collection applications.

There is a large variety of communication protocols used in manufacturing today. Hiring skilled technical resources is a requirement to manage the variation of protocols. These employees benefit from the slow evolution of the different communication protocols.

Additionally, IoT platforms, which will be discussed next, often contain extensive driver libraries, facilitating easy connections to these protocols. The challenge, and where the talented technical team helps, is to ensure the data is correctly set up on the different hardware devices to enable successful communication between the IoT platform and the hardware.

IoT Platforms. An IoT platform is a software package that connects devices to networks and manages the data that is generated. IoT platforms are the bridge between the hardware and the storage of the data. It provides a connection between OT (Operational Technology) and IT (Information Technology).

The IoT platform also provides control and logic to the data collection process. This is best explained with an example. Imagine a foundry with a furnace holding aluminum at a liquid temperature. Within this equipment, a temperature sensor in the metal is connected to a PLC. A tag, or variable, represents the temperature value stored in the PLC. The PLC can read this sensor near real-time and adjusts the furnace controls, turning the heating element on or off to maintain the temperature. The PLC is connected to the IoT platform through the network. The IoT platform communicates with the PLC and has access to all the PLC tags. The IoT platform can see the sensor values changing in the PLC. Additionally, the IoT platform has access to the database server that stores all the historical process data.

With this bridge in place, the IoT platform must be configured to trigger data transfer based on the established criteria. If the requirement is to collect data every five minutes regardless of the process, the IoT platform would populate the database with rules created to write the tag to the database with a five-minute timer trigger. Alternatively, if the criteria specify collecting temperature data right before the next robot takes a ladle of metal out, a different rule would be created in the IoT platform. This rule would monitor the metal temperature tag but only trigger a data write when a separate tag controlled by the robot is activated. Instead of having data points every five minutes and estimating which temperature is closest to the casting process, a set trigger from the casting process controls the data generation through the IoT platform. The Criteria should define these triggers and data collection rules to ensure the IoT platform generates the desired data. This example illustrates the important logic and control that IoT platforms provide in the data collection process.

Finally, selecting an IoT platform is probably the most significant decision management must make when starting to implement data collection at a factory. As with other aspects discussed, many different software packages can serve as an IoT platform. Each has advantages and disadvantages. Unlike sensors, controllers, and communication protocols, once an IoT platform is chosen, a factory typically only uses that one platform. It becomes a long-term commitment. Employees need to be trained, and many rules and triggers will be programmed into the IoT platform that will be difficult or impossible to transfer to other software in the future. This makes the IoT platform a critical management decision for the data collection process. In the Communicate phase, the device has been bridged and can transfer data to storage. The OT and IT systems are connected. All the effort to gather this data is about to be stored in a location discussed in the next phase.