How to Choose Data Points for an Industrial IoT Proof of Concept
Choose data points for an industrial IoT proof of concept by starting with the decision someone will make, then selecting the smallest set of observations that can support or challenge that decision. Give each point a purpose, a location, and a testable interpretation. The Robustel IIoT Edge Starter Kit offers several possible sensing inputs, but collecting every available channel is not the objective. A focused measurement portfolio should explain what changed, provide relevant context, and reveal when the evidence is insufficient.
Illustrative industrial environment for the article's planning question.
Key Takeaways
- Begin with an operational question and a named decision owner.
- Separate the main observation, contextual observations, and data-quality evidence.
- Reject convenient measurements that cannot represent the condition of interest.
- Add a point only when it can change the pilot conclusion.
In This Guide
- What decision should a data point support?
- How should you divide the measurement portfolio?
- When is a sensor channel the wrong proxy?
- How can you rank and remove candidate points?
What decision should a data point support?
Write the intended decision as a conditional sentence: if a defined condition persists during a particular operating state, someone will investigate a named cause. Keep the wording provisional until the project team validates it. “Collect environmental data” describes an activity; “compare conditions in two approved storage locations during the same shift” describes a question that can guide selection.
For every proposed point, ask what different result would change the decision. If no plausible value changes the conclusion, the point is decorative at this stage. Set it aside, even when the interface makes it easy to collect. Conversely, if a point could change the decision but cannot be measured at the relevant location, mark the question as unresolved rather than substituting a nearby channel without explanation.
The example questions in this article are planning aids. They do not establish suitability for regulated monitoring, safety decisions, or a particular machine failure mode. Measurement suitability comes from the project's physical requirements and the sensor documentation, not the name of a dashboard panel.
How should you divide the measurement portfolio?
Use three roles. A primary observation addresses the question directly. Context helps distinguish alternative explanations. Quality evidence tells the reviewer whether the observation can be used at all. The latter may come from an application record or test procedure rather than a physical sensor channel.
| Role | Question it answers | Illustrative selection rule |
|---|---|---|
| Primary observation | What condition are we comparing? | Keep only points connected to the decision |
| Context | Under what circumstances was it observed? | Include location or operating state when interpretation depends on it |
| Quality evidence | Can this observation be trusted for this comparison? | Preserve source identity, acquisition time, and missing-data handling |
| Deferred candidate | What might help a later question? | Record the reason for deferral without adding it to acceptance |
For a room-condition comparison, temperature might be the proposed primary observation and occupancy or operating schedule might supply context. These are illustrative choices, not a configured kit solution. A team that cannot record the relevant context should acknowledge that limitation before claiming that a changed reading identifies a cause.
When is a sensor channel the wrong proxy?
Match the physical quantity before assessing convenience. The S6000U product record identifies its pressure measurement as barometric. That label matters when a proposal actually requires fluid pressure inside a process line. A similarly named data field cannot establish that two measurements represent the same physical condition.
Treat location and mounting as part of the point definition. A sensor observing air near a cabinet answers a different question from a measurement inside a component. Record the intended installation position, what influences it, and why that position is relevant. If the pilot cannot reproduce that placement, it may validate a data path while leaving the operational question open.
Create a “do not infer” statement for each selected point. For example, an environmental trend does not by itself identify the root cause of a machine fault. This statement helps the reviewer understand the boundary between the observation and the conclusion. It also gives the team a reason to add a genuinely useful contextual point later.
Illustrative industrial setting; equipment, placement, and operating conditions must be checked for the actual project.
How can you rank and remove candidate points?
Review candidates using four yes-or-no questions: does the point address the decision, does it represent the relevant physical condition, can it be independently checked, and can the team explain its time behavior? A missing answer is a task for the owner, not a reason to invent a numerical score. Approve a point only after the evidence needed for its role is available.
Walk through a hypothetical result before configuring the full list. Suppose the primary observation changes while the operating context remains unchanged. What would the team investigate? Now suppose both change together. Does the context support a different explanation? Finally, suppose freshness cannot be established. The correct result may be “insufficient evidence,” which is useful when it prevents a misleading conclusion.
Remove points that duplicate another observation without adding interpretive value. Keep a deferred list containing the proposed name, reason for exclusion, and condition that would justify reintroducing it. This turns scope control into a visible decision and makes future expansion easier to review.
How should the final point list be written?
Use a compact measurement brief for each approved point: decision role, physical quantity, source, placement, unit, reference method, expected observation window, and owner. Add the reason a missing or invalid result changes the conclusion. The exact communication parameters belong in the integration record; the brief explains why the measurement deserves to exist.
Separate real observations from illustrative software output. Robustel's S6000U integration example is useful for understanding a path, but a demonstration transform is not an additional sensor measurement. Require the reviewer to identify the source and interpretation of every field before counting it as evidence.
Frequently asked questions about selecting PoC data points
Should the PoC collect every available sensor channel?
Only when every channel has a defined role. An available field with no decision, context, or quality purpose increases review work without necessarily helping the pilot.
Is more frequent collection always a better point choice?
Frequency and usefulness are different questions. Define the change the project needs to observe, then verify an appropriate collection method and timing. Do not select a channel solely because it updates often.
What if one sensor cannot answer the operational question?
Record the missing physical measurement or placement requirement. Narrow the question or evaluate another sensing method rather than treating a convenient available channel as an equivalent.
How do we keep the point list from growing during commissioning?
Require each addition to name the conclusion it could change and the evidence needed to validate it. Put interesting but unrelated observations on the deferred list.
What should you do next?
Write one decision sentence and assign the three evidence roles. Review the Robustel IIoT Edge Starter Kit and the S6000U measurement specifications against that brief. Bring the measurement question and placement assumptions to Robustel before finalizing the sensor path.
About the Author
Mark, Technical Support Engineer at Robustel
Mark is a Technical Support Engineer at Robustel with hands-on experience in industrial networking and edge connectivity. He helps customers plan, deploy, configure, and troubleshoot industrial IoT solutions, including cellular routers, edge gateways, and LoRaWAN systems. His work spans technical support, product training, configuration review, and practical deployment guidance for reliable and repeatable field operations across global projects and long-term operational support.
Leave a comment