The ever-increasing demand for higher-quality and more complex parts has led the manufacturing industry to evolve and become more automated and computerized. Since the industrial revolution, the manufacturing industry has utilized computers to control machine tools and processes, which resulted in more accurate and more precise productions [1] . The increase in automation and computerization in the manufacturing industry has created a larger demand for cloud computing, and by extension increased the cost for cloud computing in relation to use [2, 3] . In other words, historically manufacturing has relied upon computerization to increase accuracy and precision while reducing errors, but with the advent and implementation of the Internet of Things, the industry is moving toward a new digital industrial revolution referred to as Industry 4.0. The technologies and trends in Industry 4.0 aim at facilitating the development of digital twins of the physical systems and processes and enabling analytics to perform in various decoupled systems to ultimately improve the product lifecycle [4] [5] [6] . Although the traditional Internet architectures and machine learning methods may address the current needs of the industry, as the number of devices and the amount of data that they publish increase, the
The ever-increasing demand for higher-quality and more complex parts has led the manufacturing industry to evolve and become more automated and computerized. Since the industrial revolution, the manufacturing industry has utilized computers to control machine tools and processes, which resulted in more accurate and more precise productions [1] . The increase in automation and computerization in the manufacturing industry has created a larger demand for cloud computing, and by extension increased the cost for cloud computing in relation to use [2, 3] . In other words, historically manufacturing has relied upon computerization to increase accuracy and precision while reducing errors, but with the advent and implementation of the Internet of Things, the industry is moving toward a new digital industrial revolution referred to as Industry 4.0. The technologies and trends in Industry 4.0 aim at facilitating the development of digital twins of the physical systems and processes and enabling analytics to perform in various decoupled systems to ultimately improve the product lifecycle [4] [5] [6] . Although the traditional Internet architectures and machine learning methods may address the current needs of the industry, as the number of devices and the amount of data that they publish increase, the [11] . As a summary, the literature on this subject includes either the CPS architectures that focus solely on the big pictures and high-level structures, or they propose edge-cloud architectures and how the cloud computations can be integrated into the manufacturing plants. There exist very few studies that focus on the computational aspects of the IoT architectures and how analytics could be efficiently performed for the streaming data generated by CPS and IoT systems. Current architectures have also other limitations such as Internet and cloud dependency for communication and analytics, requiring the proprietary data to be shared with cloud service providers and therefore requiring agreements with them, they require a high network bandwidth, and the machine learning algorithms are only trained with the historical data stored in the cloud, which do not address the needs of generating analytical models in realtime. This study, therefore, proposes a novel three-layer architecture, which is explained in high and low levels, with a particular focus on Fog Computing (FC) and Federated Learning (FL), that enhances communication reliability, latency, and privacy while allowing machine learning models to be created and trained with the collaboration of various companies without the need of sharing the raw data of the machines and processes.
This section briefly introduces the tools and terms such as communication protocols and algorithms that are related to this study.
With the need for collecting data in a standard format from computer-controlled machine-tools such as CNC machines and their built-in sensors, the development of MTConnect protocol was initiated [12] . MTConnect is an open standard, read-only, and XML-based protocol that facilitates data acquisitions from manufacturing machines through a TCP connection [13, 14] . MTConnect consists of two sections of the adapter and agent. The adapter collects data from different resources in the machine and provides those data to the agent. The agent formats the data based on the given templates and hosts the data in a TCP server. Data can be then retrieved via HTTP requests or streamed using socket connections to the agent. This communication chain is shown in FIGURE 1. 
Open Platform Communications -Unified Architecture (OPC-UA) was developed by the OPC Foundation for unified M2M HTTP communication and industrial automation of system and processes in industries [15] . The increase in the number of methods and protocols developed for communication between different platforms in the manufacturing industry had led to the development of this unified architecture to facilitate the data exchange. This has been the goal of other recently developed standards such as MTConnect as well. Modern manufacturing equipment is often compatible of communication with at least one of these technologies. The architecture of OPC-UA is presented in FIGURE 2 [15] [16] [17] . 
The majority of Internet-connected applications such as web browsers and smartphone apps exchange data on Representational State Transfer (REST) architecture with Hypertext Transfer Protocol (HTTP) [18] . REST is a technical description of working principals behind the World Wide Web, known as the web, that lives on the Application layer of the OSI model [19] . Since HTTP makes use of TCP, it can have reliable communication and assure a complete transfer of data with no loss in packets. HTTP uses communication verbs of GET, POST, PUT, and DELETE to perform different tasks with data in between the client and server as shown in FIGURE 3 [20] . 
In contrast to HTTP where data can be only transferred between a client and a sever, publish-subscription protocols such as Message Queue Telemetry Transport (MQTT) facilitate data exchange by enabling data to be transferred to multiple clients known as subscribers as shown in FIGURE 4 [21] . MQTT is an open protocol initially developed by IBM and has recently become a popular protocol. Publish-subscription communication protocols are known as many-to-many and are developed to address the need for quick and distributed communication as in IoT systems. Some of the other popular protocols in this category are Data Distribution Service (DDS), Advanced Message Queuing Protocol (AMQP), Simple/Streaming Text Oriented Messaging Protocol (STOMP), and Extensible Messaging and Presence Protocol (XMPP). Each one of these protocols or a combination of them could be utilized to address the needs of an application. Due to the simplicity of the architecture, efficient communication, as well as its use by cloud service providers such as Amazon Web Services (AWS), Microsoft Azure, and IBM Watson, MQTT has become a popular and prominent protocol for IoT. This study utilizes MQTT and HTTP as the major communication protocols for the data exchange between IoT gateways in the proposed architecture. 
Performing autonomous actions based on sensing conditions is one of the steps towards SM. Rather than raw sensor information, supervised classification models can be created using ubiquitous data from sensors and sensor arrays to predict meaningful events. Since many IoT applications in the industry often require a quick learning phase with a low number of data points, the Naïve Bayes (NB) classifier could be a proper choice, as it can generate accurate predictions even with a small number of training data and can provide them to machines and operators. This algorithm is used in the sample application explained towards the end of this manuscript with the sole purpose of better demonstrating how the proposed architecture can be used. With a given prior knowledge of the system, Bayesian statistics allows prediction of the likelihood of a given dataset. The Bayes theorem is the integration of joint probability and conditional probability [22] shown in Eq. (1).
where, ( | ) is a conditional probability: the likelihood of event A occurring given that the event B is true. In addition to discrete datasets, the Bayes theorem can be applied on continuous datasets as well by either discretizing the datasets or taking their distribution characteristics into account. Assuming the normal Gaussian distribution function for the datasets in this study, the mean and standard deviations of the datasets with a normal distribution can be used in the Bayesian algorithm. Referring to a study that proposes the Incremental Gaussian Naïve Bayes (IGNB) classifier [23] , considering the naïve Bayes formula (2), and assuming a normal distribution, the probability of an incoming data point can be calculated by the Gaussian distribution probability formulas, as shown in (3). Rather than keeping a log of all of the data points, the mean and standard deviation of the data can be incrementally calculated for the Gaussian distribution.
In this manuscript, a novel IoT architecture for CPS is proposed with the three layers of edge, fog, and cloud, which are described in this section. The high-level diagram as well as a more detailed version of this architecture are presented in FIGURE 5 and FIGURE 6 , respectively. Although the following roles are recommended for typical manufacturing applications, they can be moved between these layers depending on the needs and requirements of the application.
© 2020 by ASME 
The edge layer contains machine tools, embedded systems, operator inputs, and other sources of data from the manufacturing operations. As described in the background chapter, modern machine tools are capable of transmitting the data produced in the machining process with the aid of protocols such as OPC-UA and MTConnect. The edge layer of this architecture is dedicated to data acquisition, preprocessing, and EC. Ubiquitous data from operators, machine tools, sensor retrofits, as well as other CPS, using different gateways such as computers, microcontroller units (MCU), microprocessor units (MPU), and programmable logic controls (PLC) are captured, the key features of the data are retrieved, the proper formatting is applied, and the processed data are published with MQTT to a local area network (LAN) message broker that lives in the fog layer. 5 Mahmoud Parto, Christopher Saldana, Thomas Kurfess / Procedia Manufacturing 00 (2019) 000-000 5 © 2020 by ASME
The fog layer in this architecture has the main tasks of local communication, cloud communication, and incremental ML and stream analytics. This layer contains a local message broker that handles the communication between different components that live in the edge and fog layers. Dedicating a LAN message broker in the fog layer instead of relying only on a cloud message broker not only will improve the communication performance, but it also provides a more reliable data transfer due to the Internet independency. The next component in the fog layer is a broker-to-broker gateway bridge enabling the LAN message broker and the Internet area network (IAN) message broker to communicate with each other. Messages of interest, therefore, can be transmitted between edge, fog, and cloud layers. By properly managing the flow of the messages using these components, this design can also reduce the traffic and prevent unnecessary data transmissions. Last but not least, this layer is where the incremental training of ML algorithms and stream analytics takes place. For the computations, three categories of components are considered: first, the Engines, where computational and machine learning models are generated, they are incrementally trained, or they are used for predictions; second, the FL application programming interfaces (APIs) that are used for the transmission of the ML models back and forth with the cloud to have them aggregated with the cloud models; third, the Applications that will utilize the Engines and FL APIs to address specific needs in the manufacturing space.
The cloud layer in this architecture has two main objectives: communication and federated learning. Similar to the fog layer, there is a message broker in the cloud layer for communication and data exchange purposes. With the aid of the broker-to-broker bridge, data from the edge and fog layers of different facilities can be sent to the cloud and vice versa, and web applications can communicate with the gateways and CPS in the fog or edge layers. To allow fog layers to share their training results with one another, training elements are aggregated and stored in the cloud. This is done by the FL APIs in the cloud, which receive the trained models from the fog layers, aggregate them in the cloud, and transmit the results back to the fog layers. Rather than publishing the raw data to the cloud and generating historical data for future analytics, FL increases privacy, lowers the bandwidth, and reduces the requirements for storage and computing power while providing instant insights. FIGURE 7 presents the steps and resources needed in the fog and cloud layers for FL. Note that the fog layers in this design require two dedicated storage spaces: one for the new local models, and one for the aggregated models. This prevents redundant aggregation of the same pieces of training, as only the new local pieces of training are sent to the cloud. As shown in FIGURE 7, in the FL process, the new models will be added, and the existing ones will be mathematically aggregated to create more sophisticated models. The aggregation algorithms used in this study to compute the mean and standard deviation for two datasets are shown in Eq. (4) and (5). 
where , , and represent the number of datapoints in a dataset, mean of the dataset, and the variance of the dataset, respectively. Note that these algorithms do not require the actual raw data points of the datasets. This, therefore, eliminates the need to transfer the raw to the cloud.
To better illustrate how the proposed architecture can be utilized, a Bayesian framework for vibration recognition as a sample application is presented. As shown in FIGURE 8, in this framework, a user/operator begins the training process by defining the model name, class name, along with a request for data acquisition from CPS. CPS will collect the data of interest, preprocess the data to extract the key features of interest, and transmit the results back to the message broker. The response from CPS will be compiled with the class name and model name to form the training object, which will be sent to the Bayesian Engine. The prediction procedure is identical to the training procedure with the only difference that the user does not need to 
© 2020 by ASME provide the class name as the most probable class will be computed by the Bayesian Engine. The general formatting of the training and prediction objects are shown in Eq. (6) and Eq. (7), respectively. 
: , 1, 2, . . . ,
Two stacks of four Raspberry Pi 3B+ MPUs were developed as two fog layers. These two fog layers are meant to represent two different sites that would collaborate with each other and share their pieces of training to create more sophisticated machine learning models in the cloud. The MPUs in each of these stacks (shown in FIGURE 9 and FIGURE 10) , enumerated from top to bottom, are used as the LAN message broker, Application/Pre-processing, Bayesian Engine, and Outlier Engine, respectively. Since the architecture facilitates the development of decoupled systems, additional layers and computational engines can be added to the architecture independent of one another. These components are only example layers for a better demonstration of this sample application. For the edge layer, two sensor retrofit kits were developed that utilize Particle Photon as the MCU and ADXL203E as the accelerometer sensor. In this setup, the acceleration data are captured with the MCU and streamed to the MPU with 1KHz frequency. The features of interest such as the dominant frequency, maximum amplitude, average amplitude, and standard deviation of the data are then computed in the MPU and used to train and predict various vibration types such as the vibrations of a drill, an iPhone, and a Dremel in the low and highspeed modes. The specifications of the sensor are shown in TABLE 1.
© 2020 by ASME 
In this section, the results and discussion of the IGNB models that were trained with the two stacks, the FL model created by the aggregation of these two models, as well as the performance of the sample framework are presented. FIGURE  11 shows the trained model using the edge and fog layer components of the site A. In this IGNB model, Dremel_high, Dremel_low, and Normal conditions were trained, six, six, and two times, respectively. The trained model follows the IGNB formatting discussed before and include the means and standard deviation of the four key features of mean, standard deviation, maximum amplitude, and dominant frequency of the vibration data captured by the MCU and preprocessed using the MPU in the edge. © 2020 by ASME A benchmarking of this sample framework is presented in TABLE 2. Note that the fog computations are performed on the Raspberry Pi MPUs, which have a lower computational power than the computers that should be considered in an industrial setup. The FL computation, however, was performed using an EC2 server in AWS, which resulted in a faster computation. In this case, the aggregation of the two models only took 2.4ms. The results show that the trained models of the site A and site B were successfully aggregated without the need of transferring the raw data to the cloud. Both sites after receiving the central model from the cloud were able to predict all of the five trained classes. The results of the vibration recognition framework, Bayesian classification, and Federated Learning algorithms were successful in demonstrating how computational IoT frameworks with higher privacy and scalability can be designed according to the proposed architecture, where ML models can be trained in the local networks independent of Internet connectivity and shared with other sites using federated learning.
This paper has demonstrated a novel architecture for the development of a scalable IoT framework that would allow for more optimal growth of Industry 4.0. The research above shows that preprocessing and analyzing the data on the lower layers increases the computational performance and decreases the load, storage, and bandwidth requirements for the cloud, computational load, storage, and bandwidth requirements. EC can be used to extract critical features and prevent unnecessary transmission of raw data to the next layers. FC, similarly, can decrease communication traffic and lower computation loads in the cloud by analyzing data from ubiquitous resources, such as operator inputs and CPS, prior to transmission to the cloud. To create shared ML models with this method, FL can be used where only training results of the models are shared and aggregated with the other training elements in the cloud. FL also increases privacy since raw data are kept locally. Depending on the needs of the application the fog layer could be integrated into the IoT architectures while still being able to adapt and utilize the current best practices of edge-cloud implementation. A system utilizing the architecture and models above for similar setups and use cases can provide more efficient and reliable communication between the physical system and the cloud while being optimized for streaming data. These will increase the scalability, decrease the loads, and therefore, reduce the cost which will in turn allow for more growth and optimization.
Derivation steps for aggregation equations for federated learning are as follows: 