An Oracle blog about Internet Of Things

  • March 3, 2017

Introducing IoT Production Monitoring

Supreet Oberoi
Vice President, IoT and Big Data Applications

In my previous blog, I explored the modern supply chain experience that’s continually pushing for a more real-time manufacturing experience. Reflecting on the innovations in IoT, I talked about the benefits that a factory manager or VP of Supply Chain gets by deploying the Oracle IoT Production Monitoring application. 


When we designed the IoT Production Monitoring application, we wanted the factory manager to be able to answer questions like: 


Am I on track to deliver my products? 

Are my factories and machines used to their capacity? 

Which factory, product, or machine needs attention?

What creates the best performance of a factory or machine, and how can I improve that performance?

Where’s the bottleneck?

What product deliveries are at risk?


We wanted the line of business owner to be able to answer questions such as Will I meet the forecasted demand? We wanted the VP of Supply Chain to be able to identify production trends soon enough to make good business decisions.


We considered it critical to build the application architecture based on the viewpoints of a factory manager, a line of business owner, or a VP of Supply Chain, not on the viewpoints of the software architect with no experience in supply chain logistics. 


We used four core principles to design and implement our application. But first, to understand the rationale behind these principles, let me explain a term often used in supply chain circles. 

What’s a digital twin?

Let me give you a little frame of reference. 


When I think about my car (my asset), I think about Zuffenhausen where the car was born. I see the miles on the car, hear its noises, and notice any leaks. More important, when I take the car to be serviced, I don’t just rely on the mechanic’s diagnostic dongle for him to learn about my car. I give the mechanic as much context and history about the car before he enters the work order into his system. Why you might ask? To get the best overall experience, that is service result, there must be a combination of the machine (dongle) diagnosis with the car’s actual life cycle (when parts were changed, did the car get into an accident, how long have I been hearing its noises, and so on). 


Let me explain how my car servicing description applies to a typical modern manufacturing in the supply chain process. 


The factory manager creates her production schedule from data about the product definition (BOM), forecasts, and historical yields from each of two factory sites. She examines the production of these sites, San Antonio and Boston, because she has to pick one of them for an upcoming customer order. Historically, the San Antonio site has been more reliable in meeting its deadlines, so she leans toward selecting that site. What she doesn’t know is that the San Antonio site met its deadlines by skipping maintenance schedules and the machines are about to break down, potentially seriously affecting schedules. 


This is where the digital world of production planning can provide the factory manager with critically important insights about the state of the factory assets in her physical world. But if this manager relied wholly on digital information about her factory assets (products, production plan, routes, and so on), then she would have incomplete operational visibility into her tangible world. This could compromise her ability to meet business forecasts. The best chance for success is to combine the digital insights about the timing of the purchase of raw materials, the automatic creation of repair and servicing work orders, and the scheduling for asset maintenance with this factory manager’s awareness of the concrete manufacturing world.


OK, so what’s a digital twin?

The fusing of an asset’s digital and physical metadata to get a richer situational awareness has been part of the supply chain and IoT forums for some time. Perhaps it was best described in the paper published by Michael Grieves at the University of Michigan in 2001, calling for the creation of a Digital Twin <link to paper>. 


Some vendors, including our competitors, have attempted to address the supply chain need for a digital twin by simply maintaining the payload of a device as a JSON document or a Java object. 


Useful? Yes. Digital twin? Not really.  These vendors assume that if they just provide a JSON object such as this to the app developer, then they get complete situational awareness.


{ “sensors”:


{“id”:”0x77c3f” , “value”: “0.777736”}

{“id”:”0x4a92a” , “value”: “2e+4”}





This isn’t enough. 


We realized that there are four principles that we had to incorporate into our application design:


1. Demolish barriers between the physical and digital assets.

2. Provide situational awareness in manufacturing.

3. Simplify KPI development, but don’t go too far.

4. Don’t make the application stand apart – integration is key.


Principle 1: Demolish barriers between the physical and digital assets.

Our first design goal was to simplify the experience of understanding how the factory performance affects the production goals. Our application had to be able to explain to the VP of Supply Chain how an unexpected downtime from a particular line in a particular shift would affect her ability to meet the global demand forecasts. 


In addition to tightly integrating with Oracle’s supply chain suite of applications, our application exposes REST end points to integrate with third-party applications. We designed a system where physical KPIs (such as a pick rate) can be mapped to production plans and routes. 


We built an IoT application that not only measured machine data and predicted machine behavior, but also integrated with SCMs semantics for routes, plans, and products. We refused to build a silo product that had boundaries that exist only in applications, not in supply chains. 

Principle 2: Provide situational awareness in manufacturing.

Remember the butterfly effect? Even small changes to one machine’s downtime can affect the company’s global ability to deliver on a big order. For example, a workers’ strike in a zinc mine (an angry butterfly diving at the mine workers, perhaps?) in a remote region can affect global margins and forecast for a galvanizing enterprise. 


Providing situational awareness was a very ambitious goal – one that we achieved. We didn’t set out to develop an app that showed just sensor payloads in a slick dashboard. To provide rich situational awareness, we had to capture the relationships between the different manufacturing sites in an enterprise, different factories at a site, different lines in a factory, different machines in a line, making different products with different machines, variables in people and process, and on and on.


Sounds easy, right?


Using our app, a factory manager can now compare performance in real time between two factories and identify the cause of bad productivity, even down to the level of whether or not one machine on a line is properly tuned. Remember, I said in real time. Our app tracks lineage, that is, it can identify all products developed under specific environmental conditions (important for process manufacturing).  


By capturing the semantics that exist in enterprise SCM products and merging those semantics with real-time IoT data, we’ve produced a richly instrumented supply chain where many existing dark spots get eliminated. 

Principle 3: Simplify KPI development, but don't go too far.

Your enterprise might not have extensive IT resources so maybe your business has to settle on applications that contain oversimplified, generic KPIs. Maybe you don’t have enough personnel with sufficient expertise in the latest, most innovative technologies. Even if they try to define new KPIs (to get business insights) using the new and innovative technologies such as Big Data, Machine Learning, Machine Vision, Augmented Reality, and so on, perhaps they soon find themselves in over their heads.

To prevent this, we distilled the best practices in asset monitoring to provide outstanding, prepackaged KPIs. Your business has access to a diverse set of KPIs to track the performance and health of your assets at various organizational levels. 


But, because your business is unique, your application KPIs should be customizable, that is, unique to your business. As an asset owner, you, regardless of your programming experience, can use our UI to design your own KPIs because the IoT Asset Monitoring application tracks those KPIs that are unique to your business. 


For your IT resources with greater experience, we exposed Spark’s programmatic APIs in Java. We believe that APIs exist for a reason, so we didn’t want to deny it to your advanced practitioners of KPIs. 


Because we used the Hadoop-based platform to provide batch and streaming KPI computations, large volumes of data or the complexity of any algorithms won’t hinder your supply chain process.

Principle 4: Don’t make the application stand apart – integration is key.

To provide true situational awareness for your factory floor, our application fuses sensor data with data sitting in any ERP, CRM, or supply chain environment – and even PoS systems! Our architecture allows a low-code or no-code experience, which means there’s easy integration not only with Oracle apps, but also with third-party apps. 


Why is this important? Typically, for first-generation technology projects (for example, the IoT Production Monitoring application), integration costs can account for 60%-80% of the total implementation price.  Now you can significantly reduce if not eliminate these costs, because your project deployment is not only cheaper, but easier and faster. 



Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.