From sensor to asset meter: setting up a device in Maximo Monitor 9.2 and loading historic data
Every Maximo APM conversation eventually gets to Health, Predict and the clever dashboards. But those are where the story is told. The story is created further down, in Monitor, where a sensor reading first becomes something Maximo understands, and where it gets tied to an asset that a maintenance team actually recognises.
This article walks you through the mechanics of setting up a device type in Monitor leading to loading some static demo data that is linked to an Asset record.
The data chain we’ll see has five links: a device type, its metrics, a device, an asset, and finally the data. Each link depends on the one before it.
Huge thanks to Sven Strassburg, Tristan O’Gorman and IBM Champion Jan-Willem Steur for their recent APM session run at IBM Hursley.
Why Monitor, and why the data matters
Maximo Monitor is the part of Maximo Application Suite that takes operational data from sensors, controllers, gateways and historians and turns it into something a maintenance organisation can act on. In 9.2 it is noticeably easier to approach. Monitor can be installed on its own without the IoT platform underneath it, and its data sits in a single Monitor database. You can also ingest data straight from a CSV file, which is why the exercise below needs no physical device at all.
In the real world, this data would be fed from sources like your SCADA, sensors, edge devices or operational historians. Maximo Monitor provides Gateways to support this, although this is not covered in this article.
The Maximo artifacts we’ll be exploring build on one another. Device types and metrics give incoming readings a structure. Aggregations and calculated metrics turn a noisy stream into hourly and daily figures you can reason about. Anomaly functions and alerts tell you when behaviour has changed, not merely that a line was crossed once. In 9.2 that includes alerting on how often something occurs. Dashboards put it in front of people, and a parent can now roll up the metrics of its child devices. Finally, meter mapping puts the values onto the asset's meters in Manage, where condition monitoring and work orders already live.
This matters because every maintenance strategy beyond the calendar runs on this data. A time-based PM assumes how an asset is wearing, whereas a metric measures it. Condition monitoring needs a trusted reading against a known asset, and Health scores need a history of those readings. Predict needs that history lined up against failures to estimate what comes next. Prescriptive maintenance recommends the action as well as raising the warning, so it needs all of the above.
It’s worth remembering that none of this works on a number without context. A vibration of 7 mm/s means nothing until you know which pump it came from, what is normal for that pump, and what it was doing last month. Setting up a device properly is how a reading acquires that context.
1. Create the device type
In the Maximo Application Suite navigation, go to Monitor → Setup → Device types and click Add device type. Choose Empty template rather than the device library or one of the samples, then click Next.
Give it a name and a description. Choose the name carefully, because the screen tells you plainly that it cannot be changed later. Click Create.
At this point all you have created is a container: "this is the kind of thing I am going to be working with". Monitor drops you straight onto the Metrics tab, which is a fair hint about what it wants next. It’s worth taking a look on the Overview tab and clicking Edit. This is where you set how long metric and calculated-metric data is retained (365 days by default) and how devices are identified: by Device ID, by device name (alias), or by dimensions. If a client is worried about paying to store data for ever, this is the screen where you cap it.
2. Add the metrics
For years in Maximo we called these attributes, because they are the attributes a sensor sends in, and SCADA people still do. Monitor now calls them metrics. Same thing.
On the Metrics tab click Add metric. For each one you give a metric name, a display name, an event, a type and an optional unit. We kept it to two: Temp and Vibration, both of type NUMBER (the default is LITERAL, so change it), both on an event called Data.
The event is worth a sentence, because it comes back to bite later. It is a qualifier within the message topic, and the name is yours to choose. You could have one set of metrics on a Data event and another on an Alert event. Whatever you type here becomes part of the contract for any data you send or load. These event names must be referenced on the load csv file in the headers.
Click Add, and then, the step everyone misses, click Save on the Metrics tab. The metrics do not exist until you do.
3. Let Monitor do some arithmetic
Raw readings are rarely what you want to show anyone. Go to the Data tab, select a metric, open its Aggregation tab and tick the combinations you want. We took minimum, maximum and standard deviation, hourly and daily, for both metrics, and clicked Save.
Monitor builds the calculated metrics for you with predictable names such as Temp_Hourly_Maximum, and lists them on the Calculated metrics tab. That tab is also where Add calculated metric opens the function catalogue for anything more ambitious, such as anomaly scoring. Notice too that the indicator at the top right of the device type flips from Analysis off to Analysis on: the calculation engine now has something to do and is waiting for data.
4. Add the device and tie it to an asset
Back on the Device types list, select your device type and click Add device. Give it a Device ID and choose a token type. Auto-generated is the easy route. If you go custom, the rules are strict: 8 to 36 characters, upper and lower case, a number, a special character, and no repeated characters or full words.
When you save, Monitor shows the authentication token once. Copy it somewhere safe. It is stored hashed and is not recoverable, and you will need it the day a real device or gateway has to connect. The obvious question here is: what about a site with ten thousand devices? The honest answer is that you do not do this by hand; you register devices programmatically or let a gateway manage the relationship.
The device inherits every metric and calculated metric from its device type, so there is nothing more to define. What it does not yet have is any connection to Maximo Manage. Open the device, go to Overview, scroll down to Relationships, and on the Assets tab click Assign asset. Pick the asset and save.
It’s strange that the panel used here is at the bottom of the Overview tab, but that is where it lives. The same screen also has the Data simulator toggle, which is handy for demos: once enabled it keeps generating values against your metrics, so a demo you prepare today still has fresh data next week.
5. Map the metrics to the asset's meters
This is the step that surprises people. You do not map metrics to meters on the device type or the device. You do it on the asset. Click the asset name in the Relationships panel and you move up a level to the asset's page in Monitor. Open the Meters mapping tab and you will see the meters that Manage already holds for that asset.
Click Map metrics against a meter, select the device, click Next, then choose the metric.
The field that matters is Initial start time. It defaults to now. If you intend to load historic data, move it back to before your earliest reading. Leave it at today and everything older is simply ignored when it comes to the meter!
Click Submit, repeat for the second meter, and each row shows the metric, device, device type and Enabled under sync.
For the exercise we mapped the raw Temp and Vibration metrics. With a live, chatty sensor you would more likely map one of the hourly aggregates, otherwise the asset's meter gets every single reading.
6. Load the static data
Go back to the device type, open the Data Ingestion tab and click Upload file. Before you upload anything, click Download example .csv file.
That example file is generated from your device type, so it shows exactly the headers Monitor expects. Ours looked like this:
The pattern is TIMESTAMP, DEVICEID, then one column per metric in the form Event:Metric. Build your data file to match: same header row, your own Device ID in every row, and timestamps in that same format. Files must be CSV and no bigger than 50 MB. If you prepare the file in a spreadsheet, make sure it goes back out as plain CSV and that the timestamps have not been reformatted on the way.
Here's an example of the type of data we loaded.
Drop the file in and Monitor previews the first ten rows and tells you how many it found. Click Submit.
The file appears in the Data Ingestion list as Not started, and a file of around 18,000 rows took a minute or two to reach Complete, with a record count alongside. The overflow menu on the row lets you download the processed file, download an error file if it failed, or delete it.
You should then see the historic data sitting in Maximo against the Asset for both Temperature and Vibration, giving you some meaningful and realistic data to work with!
The two things that caught me out
The first was the header. Several uploads failed, and the error file looked identical to the file that went in, which did not help. The cause was the event name. The source data file I was using had columns headed Event:Temp and Event:Vibration, but I had called my event Data, so Monitor was looking for Data:Temp. Change the header and the same file loaded first time. This is exactly why you should download the example file from your own device type first.
The second is what happens when you want to undo something. These objects are linked across Monitor and Manage, so you have to unwind them in reverse order: remove the meter mappings, then the asset relationship, then the device, then the calculated metrics, and only then the metrics. It is another good reason to write the names down before you start typing.
Both are the kind of mistake people only make once, which is why I like teaching this as a hands-on lab: a practice device type, a sample CSV with a deliberate header error, and the unwind in reverse order. If you’d like a lab like this built on your own device types, that’s what we build.
Why bother?
Because once these five links are in place, everything above them has something real to stand on: meter readings flowing into Manage, condition monitoring, alerts, Health scores. And because in real projects, the hard part is rarely the screens I have just described. It is knowing which controller is bolted to which machine, and which asset record represents it. The mapping step in Monitor takes thirty seconds. Knowing what to map takes a team that understands both the plant and the data, and that’s a training job as much as a technical one.
Again, many thanks to Sven Strassburg, Tristan O'Gorman and Jan-Willem Steur for running these fantastic sessions for IBM Partners.
Which meters would you feed from sensors first on your own assets?
Join the discussion ↓No need to name your organisation. Tell us what you’ve seen, not who you saw it at.
4max turns walkthroughs like this into training for your own team, with hands-on labs on your device types and meters, a pre-loaded practice environment, and short videos for the steps people forget.
Comments