IoT Platform & Connection System Suite

IOTS Platform

RUIYI IOTS Platform: the unified IoT foundation for device connectivity, lifecycle management and shared data across applications.

PlatformIoT

Connecting a device is not the hard part. Two devices are easy. Two hundred devices from several vendors, speaking different protocols, spread across plants, sitting at different firmware versions — that is where it stops being a project and becomes something that has to be maintained.

RUIYI IOTS Platform is the foundation the rest of the IoT suite runs on. It registers equipment, connects it over the protocols those devices already speak, keeps one record per device through commissioning, configuration, firmware, health and decommissioning, and makes that data available to the applications above it.

The point is not the connection. It is that the application above — digital twin, remote monitoring, energy, maintenance — reads the same device record instead of building its own. Connecting once, and reusing that connection, is the difference between a suite and a set of separate tools.

Connecting a device is easy. Keeping it correct, current and accounted for is the work.

Multi-protocol gatewayOne record per deviceLifecycle, not just connectionShared across the suite

What it is

The connection layer. Devices, gateways, controllers and PLCs are connected over the protocols they already use — Modbus, OPC UA, MQTT and others present on site — rather than through a driver written again for each project.
One record per device. Identity, location, model, firmware, configuration, credentials, owner and history sit in one place, not in a spreadsheet that was last edited last year.
Lifecycle, not just onboarding. Commissioning, configuration, firmware and parameter changes, health, and decommissioning are all stages of the same record.
A model the applications share. Points, units, states and events are modelled once, so the twin, the monitoring and the reporting read the same thing and mean the same thing.
A gateway for what cannot speak for itself. Where a device cannot publish on its own, an edge gateway bridges it. What reaches the platform arrives already in the platform's model.
Security handled in one place. Identity, credentials and certificates are issued and rotated centrally rather than being managed device by device.

What gets in the way today

Every new device type is a new integration. The same work is done again for each one.

Protocol handling, point lists and data models are written per project. So the second device type costs almost as much as the first.
The same device is connected separately by each application that needs it. Three applications, three integrations, three chances to disagree.
Changing a supplier means rewriting the integration. Which is why replacements get postponed.
The connection code becomes something nobody dares touch. Because it works, and nobody is sure why.

The device list lives somewhere else. What is installed is known, but not in any system.

What is actually on site is recorded in a spreadsheet. Last updated when the line was installed.
Firmware versions, parameter settings and who issued which credential are not recorded anywhere queryable. So they are established by asking, or by looking.
A device moves, or changes owner, and the record does not follow. So the record and the floor drift apart.
An audit or a stocktake means sending people to count. Because there is nothing to count against.

Connected is not the same as healthy. The link exists; whether data is flowing is another matter.

Nothing marks a device as gone quiet. Data can stop for days before anyone notices.
Nobody watches which devices are reporting, how often, and when the last value arrived. There is no place where that is visible.
A gateway going offline and a device going offline look the same. So the wrong person gets called.
Data quality is not marked. Missing, frozen and jumping values are indistinguishable from good ones.

Each application builds its own plumbing. Which is how a platform becomes three systems.

The twin connects, the monitoring connects, the energy application connects. Each on its own terms.
The same device has a different name in each one. So cross-referencing is manual.
Changing one point list means changing it in three places. And they get out of step.
The result is sold as one platform and operated as several. Because that is what it is.

What it manages

Five stages, all writing to the same record. A device is not finished when it is connected; it is finished when it is retired and its history is still available.

Stage	What the platform does
Commissioning	Registers identity, location, model and owner, and issues credentials
Configuration	Sets parameters and point lists, and records each version applied
Operation	Watches connection health and data quality, and records states and events
Update	Applies firmware and configuration changes, with batches and rollback recorded
Decommissioning	Takes the device out of service, revokes credentials, and keeps its history

What the platform can do depends on what the device exposes. A device that speaks a standard protocol and publishes its own data is straightforward. A device that does not needs a gateway, and what can be read is limited to what that device makes available. The platform does not manufacture data the equipment does not produce, and it does not replace the control system — it reads from it, within the access the site grants.

What you get

Where it is used

What changes between these settings is how many device types are involved and how much of the estate is already installed.

Setting	What the platform usually carries
Multi-vendor plants	Several protocols and several generations of equipment brought under one device record
Multi-site groups	One way of registering and describing equipment, applied consistently across plants
Brownfield retrofit	Existing equipment brought in through gateways rather than replaced
Machine builders and OEMs	Machines shipped with an identity, connected for commissioning and after-sales service
Utilities and infrastructure	Distributed assets — pump stations, substations, pipelines — where nobody is on site

Capabilities

Grouped by what they do. Applications above the platform read from these rather than connecting to devices themselves.

Capability	What it means
Multi-protocol connectivity	Connect over the industrial protocols already in use on site — Modbus, OPC UA, MQTT and others.
Edge gateway support	Bring in devices that cannot speak for themselves, through gateways at the edge.
Device registration	Register identity, model, location, owner and commissioning date for each unit.
Point and data modelling	Define points, units, states and events once, and reuse that definition everywhere.
Commissioning record	Keep what was done when a device was brought into service.
Configuration management	Apply parameters and point lists, and record every version that was applied.
Firmware management	Roll out firmware changes in batches, with what was applied and what can be rolled back recorded.
Change history	Record what changed, when, and who changed it, across configuration and firmware.
Connection health	Show which devices are reporting, how often, and when the last value arrived.
Data quality marking	Mark values as missing, frozen or out of pattern rather than passing them through as good data.
Gateway and device distinction	Tell a gateway going offline from a device going offline, so the right person is called.
Time-series storage	Hold the values devices report, for as long as the site's retention policy sets.
Events and alerts	Raise what devices report as events, in a form the applications above can use.
Interfaces for applications above	Serve the same device record to digital twin, remote monitoring, energy and maintenance.
Write-back where authorised	Send configuration and parameters down to devices, within the access the site grants.
Identity and credentials	Issue and rotate device identity and certificates from one place.
Role-based access	Control who may register, configure, update and retire devices, and log what they did.
Deployment choice	Run in the cloud, on site, or split between the two — usually decided by where operational data may go.
Integration	Connect to maintenance, asset registers and the applications that consume the data.

How it works

Register. The device is registered: identity, model, location, owner, commissioning date.
Connect. It is connected directly over its own protocol, or through an edge gateway where it cannot publish alone.
Model. Its points, units, states and events are defined once, against the platform's model.
Operate. Connection health and data quality are watched, and what it reports is recorded.
Serve. The device record is served upward, so twin, monitoring, energy and maintenance all read the same one.
Maintain and retire. Configuration and firmware changes are recorded; at retirement credentials are revoked and history is kept.

Deployment, integration and boundaries

Where it runs. In the cloud, on site, or split between the two. Where operational data is allowed to be processed and stored usually decides the split.
What it feeds. Digital twin, remote monitoring, energy management and maintenance read from the same device record rather than integrating separately.
What it does not replace. It does not replace the control system or the logic running in it. It reads from those systems, within the access the site grants.
What depends on the device. What can be read is limited to what the equipment exposes. Older devices may offer status and a few values; newer ones offer more. The platform reports what it can get, and marks what it cannot.
What is local. Network segmentation, remote access policy, data residency and retention depend on the jurisdiction and the site. Configuration is set to fit them; the platform does not make those decisions.