Start with one operational question and a machine that can provide useful evidence. Confirm access, agree the meaning of each signal, compare the readings with reality, and decide what would make the result worthwhile.
1. Choose a decision, not a screen.
“We need IoT” is too broad to define a useful first project. “We want to know when this machine stops during the night shift” is easier to investigate. It identifies an asset, a period and a question that someone can act on.
Write down who needs the information and what they would do differently after seeing it. If that decision is unclear, a more elaborate screen will not solve the underlying problem.
2. Check the equipment before promising a connection.
Gather the machine make, model, controller information and available documentation. Ask the appropriate equipment owner or manufacturer what information can be accessed and under which conditions.
Some installations provide software interfaces; others require additional sensors or a different approach. OPC UA and MQTT are examples of technologies you may encounter, but seeing either name in a proposal does not establish compatibility with a particular machine.
- OPC Foundation: OPC UA architecture and information exchange
- MQTT: publish/subscribe messaging for connected devices
Review network access, ownership of the data and the effect of any proposed change on the equipment’s operation. Connection work should follow the site’s approved procedures.
3. Agree what each signal means.
A name such as “running” can mean different things. Does it indicate power, an active cycle or actual production? The definition must be useful to the intended user.
| Information | What to establish |
|---|---|
| Machine state | Which states are available and what each state actually represents. |
| Timestamp | Where the time comes from and how records are aligned. |
| Update interval | How often a useful reading can be collected and shown. |
| Unavailable data | How a lost connection differs from a stopped machine. |
| Stop reason | Whether a cause is available automatically or needs operator review. |
4. Compare the reading with the real operation.
Review a small set of representative events alongside the equipment or operator records. Check more than the normal working state: a restart, missing communication or an incomplete record may reveal a problem that a smooth demonstration hides.
Agree who can access the information, how long it is needed and how failures become visible. NIST’s IoT work highlights the importance of privacy, security and reliability across connected systems. Read NIST’s overview.
5. Decide whether the first connection helps.
Use an agreed review period and a specific question. Could the team identify the stops it wanted to investigate? Did the information reduce uncertainty, or did it create extra checking work?
A successful technical connection is only one part of the result. Review the usefulness of the information before extending the design to more machines. Avoid claiming savings or improved output without a suitable comparison.
Bring a machine. Bring a question.
Have the equipment details and a short description of what you want to understand ready for the first conversation.
Discuss a first connection ↗Explore industrial edge computing →