In order to get the data needed for properly measuring machine downtime and improving OEE you will need to develop a few things. You will need a well-defined business case, you will need to work through a complete planning and scoping phase, and finally you will need to develop a proof of concept.
Planning and Scoping
In planning and scoping, a company will need to define a problem to solve. Some key things to keep in mind here are to keep it simple, as overcomplicating the process can create unnecessary difficulties and delays. If you’re not sure about the productivity of the machine and operator, you will want to get more data. More data provides more information to accurately answer this question. And you will want to get downtime data, as this is the ideal place to start in improving overall equipment efficiency.
Getting more data sounds great, but what data do you really need? To define this, you will need to answer these questions:
What KPIs use to drive operations excellence?
What metrics use to measure performance, production, quality, and availability?
What does the data from user say about when the machine is in use and not, and why?
What does the data from machine say about when it is running and not running?
What are the failures in the machine with failure codes?
Next, you will want to review the machine. This includes all relevant machine information such as:
Machine model number, vendor name
Is there an alarm screen, alarm lists or status screens about state and condition? What types of faults and alarms exist?
Do we have technical manuals that list functions, operations, and data points available?
Does it have a PLC? Model, vendor? Other type of controller?
What is the communications protocol?
Is there an ethernet port?
Are there extra modules or licenses to buy to pull data from the machine?
Can data be read real-time? Or must be downloaded via CSV or other method?
You will want to review your network. In order to gather data you will need to know if the machines are connected, and if so how they are connected. You will need to know if a network exists and if it is hardwired (Ethernet, RS-232, RS-485, other), if it is on Wi-Fi, and what type. And finally, what kind of security this network has.
Selecting a software platform is the next step in your planning process and a crucial decision. If there is any chance you will connect to more machines, pull more data from machines, and expand the solution in other ways, a platform should be considered that has flexible visualizations, data models, many options for connectivity, data historian, etc. You will need to ascertain which IT servers and databases are already in place on-premises, if a cloud solution is acceptable and if you really need data to be viewed in real time.
You will of course need to design the solution. In doing so, you will design the LAN setup and other connectivity, required connectivity modules for the machine, protocols, tools to translate the data, tools to push the data to data storage, data storage itself, data processing for calculations, and the software platform for visualizing the data.
Finally, you will create a plan. This project plan will include a projected schedule, WBS, team members, responsibility assignments, and pricing for all services and products to purchase for the project.
Proof of Concept
The proof of concept will be an experiment or pilot project. This of course will be done with all the previously mentioned data and preparation, but it is not a final product. Some may worry that creating an IoT solution may be a one time implementation – but it is instead an evolving process, and so a proof of concept is a valuable first step.
During this phase you will want to set up a machine with modules, and you need a vendor to do this. You will setup a network and gateway devices, and software including Kepware and the chosen IoT platform. Next, you will connect the machine. Then, you will map the data to the OPC UA product, push data to the IoT software platform and display the data in that IoT software platform.