\nHere, we didn’t just build a dashboard to show numbers. We built an Industrial Safety Layer<\/strong> that “connects the dots.” By using GridDB, the system can track how machine conditions change across the factory and identify risks early.\n<\/p>\n \nImagine you are looking at a machine\u2019s temperature and it shows 90\u00b0C. Is that a problem?\n<\/p>\n A single sensor reading is just a number. But a sequence of readings over time tells a story.<\/strong> <\/p>\n \nThis type of information is known as time-series data<\/strong>. In industrial environments, machines generate thousands of such readings every second. Traditional databases, often used for typical web applications, can struggle when storing and querying large volumes of timestamped data.\n<\/p>\n \nTime-series databases are designed specifically for this purpose. They work like security footage for machines, allowing engineers to look back at recent sensor readings and understand whether a machine is moving toward a potentially unsafe condition.\n<\/p>\n \nIndustrial monitoring systems need a database that can store large amounts of sensor data and allow easy access to recent readings. GridDB Cloud<\/strong> provides an environment where the storage and management of such machine data are handled efficiently, allowing monitoring applications to focus on analyzing system conditions instead of managing database infrastructure.\n<\/p>\n \nGridDB is a highly scalable, memory-first NoSQL database designed specifically for high-frequency time-series data, making it well-suited for industrial IoT workloads.\n<\/p>\n \nWe use GridDB Cloud<\/strong> to:\n<\/p>\n Without GridDB:<\/strong><\/p>\n \nIn this project, we simulate a simple monitoring system for a sugar mill. For simplicity, we consider three machines and monitor them using sensors that track values such as temperature, vibration, and power usage. The sensor data is generated through a simulator and stored in GridDB Cloud. The system then analyzes recent machine data to check if any unusual patterns appear and shows the results on a monitoring dashboard.\n<\/p>\n \nThe overall system consists of the following main components:\n<\/p>\n \nA Python-based simulator generates sensor readings for the machines. It produces values such as temperature, vibration, and power usage at regular intervals to imitate how real industrial sensors send data continuously.\n<\/p>\n \nThe generated sensor readings are processed by the backend application. This layer receives the simulated data and prepares it for storage in the database.\n<\/p>\n \nGridDB Cloud stores the machine sensor data generated during the simulation. It acts as the central data layer from which the application can retrieve recent machine readings when evaluating system conditions.\n<\/p>\n \nA web-based dashboard displays the machine status and recent alerts. It visualizes sensor values and helps users observe how machine conditions change during monitoring.\n<\/p>\n \nTo store machine telemetry data, a GridDB Cloud instance can be deployed through the Microsoft Azure Marketplace. After subscribing to the service, users receive the cluster connection details including the notification provider address, cluster name, database name, and authentication credentials.\n<\/p>\n \nUsing the GridDB Python client, applications connect to the GridDB cluster through the native API using the notification provider address provided in the GridDB Cloud dashboard.\n<\/p>\n \nThe following example shows how a Python application can establish a connection to GridDB Cloud.\n<\/p>\n \nOnce connected, the application can create containers and store the sensor data generated by the monitoring system.\n<\/p>\n \nThis project builds a smart safety monitoring system for a sugar mill. The system monitors three key machines in the production process – the Boiler, Crusher, and Centrifugal. Different sensor data such as temperature, vibration, and power usage is generated and stored, where it can be analyzed to observe how machine behavior changes over time.\n<\/p>\n \nSince real industrial sensors were not available, the system uses a sensor simulator to generate realistic machine telemetry. The simulator creates readings for three machines in a sugar mill:\n<\/p>\n \nTo make the simulation more realistic, the dataset is generated in three phases:\n<\/p>\n \nThis models how failures in industrial environments often propagate through connected machines rather than occurring in isolation.\n<\/p>\n \nTo make the simulation mathematically sound and physically realistic, the system avoids generating flat, hardcoded values. Instead, it uses proportional interpolation and random noise to calculate sensor values dynamically:\n<\/p>\n \nThis approach guarantees that simulated sensors drift naturally within a range (and occasionally spike) rather than resting rigidly at a static median.\n<\/p>\n \nThe complete implementation can be found in the project repository: github.com\/ritigya03\/GridDB-Industrial-Safety-Monitoring<\/a>\n<\/p>\n \nTo demonstrate how failures develop over time, the project also includes a small Python script that simulates a live escalation scenario<\/strong> in the sugar mill.\n<\/p>\n \nInstead of inserting a full dataset at once, the script gradually sends sensor readings to GridDB Cloud to mimic how problems evolve in real industrial systems.\n<\/p>\n \nThe simulation follows three stages:\n<\/p>\n \nDuring the simulation, new sensor readings are continuously inserted into GridDB Cloud. This allows the monitoring system and dashboard to react in real time as the cascade develops.\n<\/p>\n \nA simplified example of the escalation trigger is shown below:\n<\/p>\n \nThe complete implementation can be found in the project repository: github.com\/ritigya03\/GridDB-Industrial-Safety-Monitoring<\/a>\n<\/p>\n \nWhen the user clicks the “Issue Addressed”<\/strong> button in the dashboard, the backend disables the simulation flag. This causes the escalation loop to stop, and the script injects a final batch of normal sensor readings into GridDB Cloud. These healthy readings immediately restore the system to a stable state on the monitoring dashboard.\n<\/p>\n \nAfter generating the simulated sensor readings, the data is stored in GridDB Cloud so it can be accessed by the monitoring system. Each machine is assigned its own TIME_SERIES container, where readings such as timestamp, temperature, vibration, and power consumption are stored. The timestamp acts as the key for each record, allowing the system to store and query machine telemetry in chronological order. Once the containers are created, the generated sensor dataset is inserted into GridDB so it can be used for monitoring and analysis.\n<\/p>\n Creating a TIME_SERIES container<\/strong><\/p>\n \nThe complete implementation can be found in the project repository: github.com\/ritigya03\/GridDB-Industrial-Safety-Monitoring<\/a>\n<\/p>\n Inserting Data into GridDB Cloud<\/strong><\/p>\n \nThe complete implementation can be found in the project repository: github.com\/ritigya03\/GridDB-Industrial-Safety-Monitoring<\/a>\n<\/p>\n \nThe multi_put<\/strong> operation allows rows for multiple containers to be written in a single request. This significantly improves ingestion efficiency when handling continuous machine telemetry streams.\n<\/p>\n \nIn addition to inserting the initial dataset, the system also supports a background data producer that continuously sends normal machine telemetry to GridDB Cloud.\n<\/p>\n \nThis producer acts as a heartbeat<\/strong>, ensuring that the monitoring dashboard always receives fresh sensor data. When the escalation simulation is triggered, the producer automatically pauses to avoid overwriting the simulated failure sequence. Once the simulation ends, the producer resumes sending healthy readings, allowing the system to recover naturally.\n<\/p>\n \nOnce sensor data is stored in GridDB Cloud, the monitoring system queries recent readings to evaluate machine conditions. The system retrieves the latest records for each machine and analyzes whether sensor values are approaching unsafe ranges.\n<\/p>\n GridDB\u2019s Time-Series Query Language (TQL)<\/strong> allows the system to efficiently fetch the most recent sensor readings from each machine container.<\/p>\n \nThe complete implementation can be found in the project repository: github.com\/ritigya03\/GridDB-Industrial-Safety-Monitoring<\/a>\n<\/p>\n \nTo avoid sudden status flickering near thresholds, the system evaluates machine conditions using a small rolling window of recent readings<\/strong>. By averaging the latest values, the monitoring logic becomes more stable and resistant to temporary sensor noise.\n<\/p>\n \nThe complete implementation can be found in the project repository: github.com\/ritigya03\/GridDB-Industrial-Safety-Monitoring<\/a>\n<\/p>\n \nInstead of a simple status label, each machine also receives a continuous risk score (0\u2013100)<\/strong> based on exactly how far its sensor values have drifted from safe ranges.\n<\/p>\n \nFor example, a boiler at 89\u00b0C and a boiler at 200\u00b0C both count as “Critical” in a simple system. With continuous scoring, the second scenario scores significantly higher because it is far more dangerous.\n<\/p>\n \nThe fleet-wide score is a weighted average across all machines \u2014 the boiler contributes more to the overall score because a boiler failure affects everything downstream. Active cascade conditions add extra penalty points on top.\n<\/p>\n \nThe system understands that machines in a sugar mill are connected. If the boiler fails, the crusher that depends on its steam will eventually be affected too. These relationships are defined as rules:\n<\/p>\n \nWhen a source machine is in a dangerous state and its downstream target also shows elevated readings, a cascade alert is triggered on the dashboard.\n<\/p>\n \nVisualization plays an important role in the monitoring system. To make machine conditions easier to understand, a web-based dashboard<\/strong> was created that displays machine status, sensor readings, cascade alerts, and the overall system risk score in real time. The interface is built using HTML, JavaScript, and Chart.js<\/strong>, which provides interactive charts for visualizing machine telemetry.\n<\/p>\n \nThe backend exposes a set of simple API endpoints that the dashboard polls periodically to retrieve updated monitoring data.\n<\/p>\nWhy Time-Series Databases Matter for Industrial IoT<\/h2>\n
\n
Why GridDB Cloud for Industrial Monitoring<\/h2>\n
\n
\n
System Architecture<\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2026\/04\/architecture.png\")
<\/a><\/p>\n\n
\n
\n
\n
Setting Up GridDB Cloud<\/h2>\n
import griddb_python as griddb\r\nimport threading\r\n\r\n_local = threading.local()\r\n\r\ndef get_store():\r\n """Return a per-thread GridDB connection to avoid concurrent access errors."""\r\n if not hasattr(_local, "store") or _local.store is None:\r\n factory = griddb.StoreFactory.get_instance()\r\n _local.store = factory.get_store(\r\n notification_member=NOTIFICATION_MEMBER,\r\n cluster_name=CLUSTER_NAME,\r\n database="df321dsdJF", \r\n username=USERNAME,\r\n password=PASSWORD\r\n )\r\n return _local.store<\/code><\/pre>\n<\/div>\nProject Overview<\/h2>\n
Key ideas behind the system:<\/h3>\n
\n
Simulating Industrial Sensor Data<\/h2>\n
\n
\n
import random\r\n\r\ndef interpolate(low, high, progress=None):\r\n """Smoothly interpolate between two values with optional random progress."""\r\n if progress is None:\r\n progress = random.uniform(0.0, 1.0)\r\n return low + progress * (high - low)\r\n \r\ndef make_row(ts, machine_id, target_state):\r\n """Build a realistic sensor row using interpolation instead of hardcoded offsets."""\r\n t_nrm_low, t_nrm_high = MACHINES[machine_id]["normal"]["temperature"]\r\n t_warn = MACHINES[machine_id]["thresholds"]["temperature"]["warning"]\r\n \r\n # Add realistic environmental noise\r\n noise_t = random.uniform(-1.5, 1.5)\r\n \r\n if target_state == "Normal":\r\n # Calculate normal resting value + physical jitter\r\n return [ts, interpolate(t_nrm_low, t_nrm_high) + noise_t, ...]\r\n \r\n elif target_state == "Warning":\r\n # Proportionally ramp upward toward the warning threshold\r\n prog = random.uniform(0.1, 0.6)\r\n return [ts, interpolate(t_nrm_high, t_warn, prog) + noise_t, ...]<\/code><\/pre>\n<\/div>\nLive Escalation Simulation<\/h3>\n
\n
def trigger_cascade():\r\n """Simulates a live cascade that persists until resolved in the dashboard."""\r\n store = insert_data.get_gridstore()\r\n start_sim()\r\n\r\n i = 0\r\n while is_sim_active():\r\n ts = datetime.now(timezone.utc)\r\n batch = {}\r\n\r\n for machine_id in MACHINES:\r\n # Dynamically generate realistic telemetry\r\n row = make_row(ts, machine_id, determine_phase(i, machine_id))\r\n batch[MACHINES[machine_id]["container"]] = [row]\r\n\r\n store.multi_put(batch)\r\n i += 1\r\n time.sleep(1)<\/code><\/pre>\n<\/div>\nStoring Sensor Data in GridDB Cloud<\/h2>\n
def create_container(store, container_name):\r\n con_info = griddb.ContainerInfo(\r\n container_name,\r\n [\r\n ["timestamp", griddb.Type.TIMESTAMP],\r\n ["temperature", griddb.Type.DOUBLE],\r\n ["vibration", griddb.Type.DOUBLE],\r\n ["power", griddb.Type.DOUBLE],\r\n ],\r\n griddb.ContainerType.TIME_SERIES\r\n )\r\n\r\n return store.put_container(con_info)<\/code><\/pre>\n<\/div>\nfrom datetime import datetime\r\n\r\ndef insert_data(store, dataset):\r\n batch = {}\r\n\r\n for machine_id, readings in dataset.items():\r\n container_name = MACHINES[machine_id]["container"]\r\n\r\n rows = []\r\n for r in readings:\r\n ts = datetime.fromisoformat(r["timestamp"].replace("Z", "+00:00"))\r\n rows.append([ts, r["temperature"], r["vibration"], r["power"]])\r\n\r\n batch[container_name] = rows\r\n\r\n store.multi_put(batch)<\/code><\/pre>\n<\/div>\nContinuous Telemetry Stream<\/h3>\n
Querying Sensor Data and Detecting Pre-Incident Conditions<\/h2>\n
def query_recent(store, machine_id, limit=20):\r\n container = store.get_container(MACHINES[machine_id]["container"])\r\n\r\n query = container.query(f"select * order by timestamp desc limit {limit}")\r\n rs = query.fetch()\r\n\r\n readings = []\r\n while rs.has_next():\r\n row = rs.next()\r\n readings.append({\r\n "temperature": row[1],\r\n "vibration": row[2],\r\n "power": row[3],\r\n })\r\n\r\n return readings<\/code><\/pre>\n<\/div>\ndef machine_risk_score(machine_id, avg_t, avg_v, avg_p):\r\n """Calculates a 0\u2013100 risk score based on continuous sensor severity."""\r\n\r\n s_t = sensor_severity(avg_t, nrm["temperature"][1], thr["temperature"]["warning"], thr["temperature"]["critical"])\r\n s_v = sensor_severity(avg_v, nrm["vibration"][1], thr["vibration"]["warning"], thr["vibration"]["critical"])\r\n s_p = sensor_severity(avg_p, nrm["power"][1], thr["power"]["warning"], thr["power"]["critical"])\r\n\r\n weighted = (\r\n s_t * SENSOR_WEIGHTS["temperature"] +\r\n s_v * SENSOR_WEIGHTS["vibration"] +\r\n s_p * SENSOR_WEIGHTS["power"]\r\n )\r\n\r\n return min(round(weighted * 100), 100)<\/code><\/pre>\n<\/div>\nRisk Scoring<\/h3>\n
Cascade Detection<\/h3>\n
CASCADE_RULES = [\r\n {"source": "boiler", "target": "crusher", "message": "Boiler instability propagating to Crusher..."},\r\n {"source": "crusher", "target": "centrifugal", "message": "Crusher anomaly affecting Centrifugal..."},\r\n {"source": "boiler", "target": "centrifugal", "message": "Full-Chain Cascade detected..."},\r\n]<\/code><\/pre>\n<\/div>\nBuilding the Monitoring Dashboard<\/h2>\n