In most factories the data already exists. Voltage is on the meter display, temperature is on the machine panel, and the running status sits inside the control cabinet. The problem is not a lack of data. It is that the data sits in separate places, has to be read one point at a time, and when something happens at two in the morning nobody can say how the values were moving beforehand.
This article explains how an IoT platform answers that problem, using Malin1, the platform DigitechX built, as the worked example. It also states plainly what this kind of platform still cannot do.
What an IoT platform is, and how it differs from adding sensors
IoT stands for Internet of Things, meaning devices that connect to a network and send out their own data. A platform here means the central system that receives data from those devices and holds it in one place.
The difference between adding sensors and having a platform sits here. A sensor lets you read a value at the point where it is installed. A platform keeps values from every point stored continuously, so they can be reviewed later, compared with each other, and watched by rules instead of by people.
Factories that have installed sensors but have no platform tend to report the same symptom. They know the current value, but they cannot say what the value was yesterday, and they do not know when it started to change.
What Malin1 is
Malin1 is an IoT management system that runs as a web application. It brings continuous value monitoring, hierarchical device management, historical analysis, and alerting together in one system.
On ownership of the work, DIGITECHX CO.,LTD. filed copyright information for the work named Malin1.com with the Department of Intellectual Property on 7 October 2025, recorded as a literary work of the computer program type, and the notification document was issued on 9 December 2025. That document states on its own face that it does not certify copyright ownership, so all that can be said is that the filing exists.
Why the data is split into four levels
Malin1 stores data in four levels. Project is the top level, used to group work and members. Gateway is the connecting unit that collects data from the devices beneath it. Device is an individual IoT device. Parameter is one value belonging to that device.
The structure looks like a technical detail, but the effect is practical. Adding another machine means adding one Device under an existing Gateway rather than rebuilding the system, and opening a second plant means adding a Project rather than installing a whole new setup.
Parameters come in three kinds: ordinary parameters that hold a measured value, Status parameters that report a state, and Setting parameters used to send a value to the device.
Two kinds of alarm, answering different questions
Malin1 sets alarms at the parameter level, and offers two kinds.
The first is Limit Alarm, which takes a minimum and a maximum. If the measured value leaves that band, it raises an alarm. This answers whether the current value is still within range.
The second is ROC Alarm, which takes a rate of change. It does not look at the value itself but at how fast the value is moving. This answers a question the first kind cannot, such as a temperature still inside its limits but climbing unusually fast, which is often the early sign before a real failure.
Both kinds let you choose notification channels separately, covering in-app notification, email, and Telegram.
Who sees what, and who changed what
The system defines four permission levels, Owner, Admin, Writer, and Viewer, set separately for each project. A contractor who looks after one production line therefore sees only that project, not the whole plant.
Something often overlooked when systems are compared is that the platform also records the history of alarm setting changes, including the time, the user, the old value, and the new value. When someone asks why there were no alarms this month when there were plenty last month, the answer can be checked in the system rather than recalled from memory.
All sign-in goes through Keycloak, a separate identity system, so passwords are not held inside the application itself.
Extending it with additional apps
Malin1 includes a built-in application store called M1-Store, which installs additional apps into the system. The most used one is mDashboard, which builds your own display screens, choosing which parameters to show and how the charts are arranged.
The benefit of keeping these as separate apps is that the maintenance team's screen and the production team's screen do not have to be the same, even though both draw on one set of data.
How those screens are built, which widget types you can choose, and how values are pinned onto a photo of the real machine are covered separately in the article on mDashboard and why each team should have its own screen
Three ways to deploy it
Where the data lives has to be decided early, because moving it later has a cost.
Cloud keeps the data on an external system and can be reached from anywhere, which suits organisations with several plants or branches. On-premise keeps all data inside the organisation, which suits plants with strict data security requirements or a need to control their own servers. Hybrid mixes the two, keeping sensitive data inside and sending part of it out for analysis or display.
On the technical side, the system can take data from PLCs, which are the controllers that run the machines, from sensors, from SCADA systems, which supervise and control the production process, and from IoT gateways.
What this kind of platform still does not do
An IoT platform does not replace the control systems on the floor. Machines still run as the PLC tells them to. The platform reads data, watches it, and raises alarms. It is not a substitute process controller.
Second, connecting devices is not the same job twice. Some older equipment has no way to send data out at all, and some can send data but only in a vendor-specific format. A site survey is therefore a step that cannot be skipped, and it defines the real scope of the work more than the platform does.
Third, collecting data does not immediately produce conclusions. Setting alarm thresholds well, so that alerts are neither so frequent that people stop reading them nor so loose that they arrive too late, takes a period of tuning against real operation.
Where to start
If you are considering this, a workable starting point is to pick one or two machines whose downtime costs the most, and measure the result there first. There is no need to begin with the whole plant.
Watching machine data answers how the equipment is running, but it does not answer whether people are following the procedure, which is a separate question we covered in the article on checking standard operating procedures with AI video analytics
For service details, deployment options, and usage examples, see the IoT Platform product and service page or contact the team to discuss your own site directly.