DEV Community

Smrati
Smrati

Posted on

Here’s the checklist of the technical questions you’d want before signing on the dotted line

If your sales team already promised the world and someone asks you to perform technical due diligence for your new Industrial IoT platform: If you're the poor engineer stuck with checking a few boxes before signing off on the IIoT deal after the sales team's done a number on the customer, here’s a checklist of questions to separate a great, scalable platform from something you'll end up maintaining for a year and then have to throw away.

I haven't targeted a specific technology, but this applies whether your company's evaluating a "build vs buy" strategy for RFID/BLE/UWB tracking, full AIoT platform, or anywhere in between.

# 1. What happens to the data model when a new sensor technology is added?

Don’t let them give you “We support other tech”; make them walk you through what would happen if you added BLE support six months after installing an RFID system.

Is it another schema change?

Another pipeline or does it fold in under the same normalized event model?

If a platform’s “other sensor tech” strategy is merely “another plugin, separate data feed, separate dashboard,” you’re going to have issues.

The big predictor for me when looking at the longevity of IIoT platforms is how gracefully they scale across diverse sensor technologies.

# 2. How is timestamp reconciliation performed across devices?

“ We simply store what the device sends.” Bad. Clocks drift and if there's no edge-level or trusted timestamp sync on your hardware, your events will eventually be wildly out of order.

# 3. What is the confidence/accuracy model of your location estimations?

Do they view every read as a fact or a probabilistic estimation ( especially relevant withBLE/RTLS where radio signal reflections/interference create lots of inaccurate readings)? Do they expose this to the API and the data model? Even better, do you use the confidence metric when triggering alerts so you can minimise false positive alerts from hardware/signal issues?

# 4. Where do you handle normalization? Edge or cloud?

This impacts performance/latency and resiliency. If your plant network is unstable and you lose cloud connectivity for 10 minutes, does local buffering with an eventual sync capability exist? Or will you lose a valuable data set?

# 5. What does ERP/MES Integration look like?

This is where projects quietly fail. Does your platform do this automatically via API/message bus or is it custom integration middleware that requires building out your own integrations team? What existing systems have you integrated with? On ERP, is there a possibility to ingest production scheduling information from ERP into a shop floor workflow?

# 6. How do ML / predictive algorithms get retrained for specific facilities?

If they offer predictive forecasting (like replenishment) or congestion monitoring, does it leverage a generic model or are models per facility an option? Using a generalized model that doesn't account for the nuances of layout and typical traffic flow in a specific plant isn't going to be very effective.

# 7. What are the Deployment Options?

For you highly regulated folks, is an “always cloud” deployment feasible? Or is an on-prem/hybrid cloud an actual, documented and referenceable deployment scenario?

There's no attempt here to be a gotcha, just practical questions that, for me, usually differentiate platforms that stick from ones that don't survive their first hardware refresh or the first ERP system upgrade.

Anyone building one of these checklists out? Let me know what other criteria are worth adding that they only became apparent post- deployment!

Check out PlantLogAI as an example of an AIoT platform trying to document its approach to all of this.

Top comments (0)