Recently, the development team has begun the process of finalizing the our new CMMS API (Application Programming Interface). The CMMS API is designed to allow other programs to directly communicate with the Fiix’s CMMS. These external programs can then use the CMMS data natively for their own purposes. This external connection will be really valuable for customers because, for example, it will allow financial software programs to keep track of purchases made through the CMMS and it will allow machines to push their data directly to the CMMS (known as Machine to Machine (M2M) communication).
My experiment with the CMMS API
Over the last few weeks, I have been trying out the capability of the API to be used for direct connection with machines. I wanted to do an experiment using the most inexpensive equipment that might be realistically used in an industrial environment. I settled on a Beaglebone Black, and a temperature sensor for a combined cost of under $60. In this blog I want to show you that I have been able to send temperature data to the CMMS and then use this data as a trigger for scheduled maintenance.
TMP36 and BeagleBone Black setup
The Beaglebone Black is an inexpensive Linux computer (~$55) available from many suppliers including Adafruit, Creatronic and Sparkfun . The Temperature sensor I used was a TMP36 (~$3) which has an output voltage that is proportional to temperature.
To start, I connected the temperature sensor to the Beaglebone with the help of a breadboard. Then using examples freely available on the internet , I programmed the Beaglebone in javascript to be report the temperature measured by the sensor by adapting some code from the Adafruit website. I connected the beaglebone to the CMMS using the soon-to-be released client library so that a temperature value was sent to the CMMS once every 3 seconds. To make the situation semi-realistic, I sent the temperature value to an Asset labeled “My office”.
The result was a continuous stream of temperature values recorded in the CMMS, with each separated by about 3 seconds as shown in the image below. The Chief Developer and I were both very pleased with this result.
The stream of temperature readings
Then, to make sure the concept was really useful, I wanted to set a scheduled maintenance that was triggered by a high temperature. This might be used to indicate that an air conditioner inspection should be conducted. I set up a scheduled maintenance for “My office”, and set it to trigger anytime the temperature rose above 35 C. The work instruction for this scheduled maintenance was fairly simple: “Check the Air conditioner – CMMS API experiment”.
The scheduled maintenance, set to make a work order when the temperature exceeded 35 degrees Celsius
Success
To fool the sensor into thinking it was warmer than it really was I took the device home to where I had a hair dryer. Under the hot air of the hair dryer the measured temperature rose and, as expected, a work order was generated. Using the CMMS the technician would be notified of the work order, and could inspect the temperature readings, all from the CMMS. This whole process happened automatically, without the maintenance manager, or operator, or office tenant being involved at any time.
Temperature datapoints after pointing a hair dryer at the temperature sensor. The temperature quickly rises from the ambient temperature.The datapoint that triggered the scheduled maintenance is highlighted yellow
The details of the datapoint that triggered the scheduled maintenance.
In addition to using the meter readings to trigger work orders, technicians and root cause investigators might use the recorded history of power use to help diagnose the fault and put in place a permanent solution. If needed, the data from other sensors could also be used to help with root cause analysis. In the air conditioner example, inlet and outlet air pressure sensors and humidity sensors may provide valuable information that helps to make a rapid diagnosis.
Machine to Machine communication and CMMS integration
I can think of many applications where this type of Machine 2 Machine communication technology will be incredibly valuable. Consider a vehicle that reports its odometer reading on a regular basis over a mobile phone 3G internet connection. Then, a work order can be generated for its regular service every 10,000 km. Or consider a power meter on an air conditioner that is used to trigger a work order when the air conditioner is working too hard. Perhaps it might be used to monitor the vibration levels of a rotating machine. Maybe, it is just an opportunity to record the operating condition of a machine over time, without ever going to the next step of using the data to trigger a scheduled maintenance.
The API is coming soon. I think it will be brilliant and very useful. It will be available for customers in selected pricing tiers. If you have any use cases you are looking forward to I’d love to hear them in the comments below.
