It has been a long time coming but for those of us involved in the Maintenance industry, we finally have a set of tools to gain insight into the Operations side of our equipment. Now, with just a little learning, we can connect to the vast amount of operational data that is coming from our equipment, display it, and make decisions.

Welcome to a different world. A place where we talk about data streams, device interfaces, payloads, entities, and API keys. This article will give you an overall picture of the process within MAS Monitor to establish connections to device data and define the common terms you will need to be familiar with.

Let us start with a diagram of what you end up with:

What are Devices, Interfaces, and Applications?

The first step in MAS Monitor is to connect to the sources of equipment data. These can be actual hardware devices such as temperature sensors, position sensors, and the like that are capturing and then pushing out data (properties) about the equipment. A good example is an internet-connected weather station. Packed with devices (sensors) this type of asset can provide real-time weather data into Monitor. Sources of data could also be historian systems that are doing the actual data collection. Either way, making the connection between these devices/systems and Monitor may require some assistance from your IT staff to understand the paths available.

Part of the Monitor configuration is the establishment of device types and the actual device definition. A device type is a template you construct so as you add more devices to Monitor, you can point to a template vs. having to reenter information repeatedly. It is on the device type where you then define the interfaces. More on those in a bit.

As part of defining the device or source of data to Monitor, the authentication method is also determined. If, for example, the device is connected to the internet, and if it has its own API, then an API key can be established between the device and Monitor for a secure communication path. While not all devices/sources of data will be “open,” to the internet, that path to Monitor (in the cloud or on-prem) will need to be made.

Am I speaking in a different language yet? I warned you.

A side note: If your source of data is a historian vs. live device data, these systems can use REST calls (POST, GET, etc.) to “push” data into Monitor. The payload of data from these systems is POSTed to Monitor in a JSON format, of which makes up the data stream Monitor makes available to you. The same authentication and network path rules apply. Using a REST tool like Postman or the like is a simple way to make initial contact with Monitor in lieu of actual devices.

Time to move on!

Within Monitor there are two interface types: Physical and Logical. A Physical interface is where you establish the specific events and data elements (properties) that are coming in from the devices. This is where you can see the raw data and decide which properties you wish to process. Warning: Devices can be quite verbose in the data they provide, and while it is cool to see it all, most likely you are only interested in a few of the data points.

A Logical interface… or interfaces… are where you can further transform the incoming data. Here you can do things like convert Celsius to Fahrenheit, perform calculations on the data, etc. The Logical interface(es) are basically the “presentation” of the data to the potential consumers of the data. Given you can have multiple Logical interfaces available, each presenting the data differently, you can serve multiple consumers from the same data. A simple example would be to provide metric units to your team in the UK, while the team in the USA would use standard units. Same data, different presentation.

Finally, what are the “applications?” Within Monitor the simple example of an application… or a consumer of the incoming data, are the Dashboards that you can create. Here is an example:

Let me explain what you are looking at. The Nordic Thingy (no kidding) is a physical device full of temperature, position, CO2, humidity, etc. sensors. It is Bluetooth connected to my laptop, and then connected to Monitor via a secure API key. It provides a slew of data each 2 seconds. Using the Logical interface, you can create “cards” for your Dashboard(s) that show the incoming data in many different formats. Charts, graphs, simple value displays, etc. are all built in to choose from. Each property (data elements) coming from the device, through the interfaces, is then available to simply pick from the list and choose how to present it. You can even add a picture of the device/asset.

Now what? Taking action.

Believe me, you could stop right here and have many hours of fun and serious geeking-out with all you can do with the data and Dashboards. Quickly you can see the support Monitor provides for decision making. But you need to move on and set things up to use your new toys.

Depending on the device, it may be able to provide error conditions in the data stream. In the case of the Nordic Thingy, if it falls over on its face, it goes into alarm mode. The alarm is in the data stream and can be presented as such in the Dashboard. You can also establish alarm definitions if a property value has exceeded / not reached a certain value such as temperature and such.

Given an alarm has occurred, you can see them in Monitor, and then take action such as having a Service Request generated into a Maximo (Manage) instance of your choice.

It may be difficult to see in the picture, but over on the far right is a link to create the Service Request, based upon the Alert information.

Archiving and storing

An aspect of Monitor is the ability to archive Alerts and store device data. Given a connection to a database… or an entire lake… in which to store data, you can use Monitor in case history is needed for perhaps an investigation or other need to look back in time.

And finally…

As stated in the beginning, setting up Monitor will require you to learn some new terms and concepts. But, given that the technology and methods used within are well known in the IT and Development disciplines, there is no lack of assistance available. Once you make that initial connection and see raw data flowing into Monitor, you will wonder why you waited so long.

Article by John Q. Todd, Sr. Business Consultant at TRM. Reach out to us at AskTRM@trmnet.com if you have any questions or would like to discuss deploying MAS 8 or Maximo AAM for condition based maintenance / monitoring.