<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>MQTT &#8211; Science</title>
	<atom:link href="https://scienmag.com/tag/mqtt/feed/" rel="self" type="application/rss+xml" />
	<link>https://scienmag.com</link>
	<description></description>
	<lastBuildDate>Thu, 15 Oct 2026 22:01:57 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.3</generator>

<image>
	<url>https://scienmag.com/wp-content/uploads/2024/07/cropped-scienmag_ico-32x32.jpg</url>
	<title>MQTT &#8211; Science</title>
	<link>https://scienmag.com</link>
	<width>32</width>
	<height>32</height>
</image> 
<site xmlns="com-wordpress:feed-additions:1">73899611</site>	<item>
		<title>$74 Wi-Fi and MQTT network gives legacy factories a digital twin on a budget</title>
		<link>https://scienmag.com/74-wi-fi-and-mqtt-network-gives-legacy-factories-a-digital-twin-on-a-budget/</link>
		
		<dc:creator><![CDATA[Beatrice Stafford]]></dc:creator>
		<pubDate>Thu, 15 Oct 2026 22:01:57 +0000</pubDate>
				<category><![CDATA[Science News]]></category>
		<category><![CDATA[affordable industrial connectivity]]></category>
		<category><![CDATA[analytical]]></category>
		<category><![CDATA[architecture]]></category>
		<category><![CDATA[brownfield]]></category>
		<category><![CDATA[cost-effective factory digitization]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[digitization]]></category>
		<category><![CDATA[edge-to-cloud industrial architecture]]></category>
		<category><![CDATA[Hierarchical]]></category>
		<category><![CDATA[IIoT]]></category>
		<category><![CDATA[industrial automation on a budget]]></category>
		<category><![CDATA[Industrial IoT retrofit]]></category>
		<category><![CDATA[Insights]]></category>
		<category><![CDATA[legacy factory automation]]></category>
		<category><![CDATA[low-cost digital twin]]></category>
		<category><![CDATA[MQTT]]></category>
		<category><![CDATA[MQTT sensor network]]></category>
		<category><![CDATA[open-source industrial IoT solutions]]></category>
		<category><![CDATA[retrofitting aging manufacturing equipment]]></category>
		<category><![CDATA[sensor-based predictive maintenance]]></category>
		<category><![CDATA[ultra-low-cost]]></category>
		<category><![CDATA[validation]]></category>
		<category><![CDATA[Wi-Fi]]></category>
		<category><![CDATA[Wi-Fi industrial monitoring]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=278398</guid>

					<description><![CDATA[For most of the world's factories, Industry 4.0 is less a revolution than a locked door. The glossy visions of digital twins, predictive maintenance, and AI-driven optimization were designed around greenfield plants bristling with sensors, but the overwhelming majority of]]></description>
										<content:encoded><![CDATA[<p>For most of the world&#8217;s factories, Industry 4.0 is less a revolution than a locked door. The glossy visions of digital twins, predictive maintenance, and AI-driven optimization were designed around greenfield plants bristling with sensors, but the overwhelming majority of actual manufacturing happens in brownfield facilities: aging bakeries, machine shops, and food processors running on decades-old ovens, mixers, and motors that predate modern connectivity by a generation. Replacing functional machinery is economically absurd, and the conventional retrofitting route—industrial PLC upgrades, proprietary gateways such as the Siemens Simatic IoT line, or extensive rewiring—can cost hundreds or thousands of dollars per machine. Now a research team from Almaty Technological University and Al-Farabi Kazakh National University has demonstrated that the door can be opened with parts that cost less than a dinner out, publishing the design and validation of an ultra-low-cost Industrial Internet of Things framework that wires a working industrial bakery into the digital age for roughly $74 per monitoring node.</p>
<p>The study, published in Frontiers in Communications and Networks, is deliberately unglamorous in its architecture and radical in its economics. Rather than proposing a novel network topology, the researchers formalized a conventional hierarchical edge-to-cloud blueprint built entirely from commercial off-the-shelf components: ESP32 microcontrollers reading certified three-phase energy meters over a localized RS-485 bus, publishing telemetry through the lightweight MQTT protocol across the facility&#8217;s existing Wi-Fi, and landing the data in an on-premise Raspberry Pi 5 server running the Eclipse Mosquitto broker, the InfluxDB time-series database, and Grafana dashboards. The scientific contribution is not the topology itself but the extraction of transferable deployment rules—about spectrum selection, buffer management, and network-health proxies—validated empirically over 30 continuous days in one of the harshest radio environments a small factory can offer.</p>
<p>The economics are the headline. A complete node—ESP32-WROOM-32 development board at $6.50, a certified three-phase energy meter with RS-485 output at $45.00, a $1.50 MAX485 transceiver, a $3.00 HLK-PM01 AC-DC converter that draws power directly from the monitored line, a $10.00 IP65-rated enclosure, and $8.00 of wiring and connectors—totals exactly $74.00. Commercial IIoT gateways and industrial standards-based solutions typically start around $500 per point and climb steeply once specialized expertise is factored in. For the entire 19-node pilot deployment, including the Raspberry Pi 5 server, the total hardware investment came in under $1,500. That figure matters because the literature consistently identifies cost, not technology, as the fundamental barrier preventing small and medium-sized enterprises from digitizing: many SMEs operate with critical data blind spots, unable to track energy consumption, monitor asset health, or implement predictive maintenance because the entry price of visibility is prohibitive.</p>
<p>The hardware design embeds several engineering decisions aimed squarely at surviving industrial abuse. Each node is housed in a dust- and humidity-protected enclosure and interfaces with its energy meter through a MAX485 transceiver that converts the ESP32&#8217;s 3.3-volt TTL UART signals into the differential signaling of the RS-485 standard, running Modbus RTU—a protocol chosen for its metrology compatibility but deliberately confined inside the enclosure rather than used for network transport, sidestepping the well-documented security weaknesses of Modbus over TCP/IP. The firmware implements a circular ring buffer in RAM: when Wi-Fi congestion pushes acknowledgment delays beyond roughly 700 milliseconds, outgoing payloads queue locally, and if memory runs short the oldest state data is overwritten by the freshest readings. The design philosophy is explicit—preserve real-time operational context over historical completeness, because a digital twin that lags behind the machine it mirrors is worse than useless.</p>
<p>The pilot site was a medium-sized industrial bakery in Almaty, Kazakhstan, a textbook brownfield: a mix of modern and legacy equipment, heavy electrical loads, fluctuating temperatures, airborne flour dust, and—critically for radio—massive metal obstructions including multi-deck Wachtel industrial ovens, structural steel, and racking, all radiating electromagnetic interference from variable frequency drives. Before deployment, the facility had no granular energy monitoring whatsoever. The 19 nodes were attached non-invasively to ovens, dough mixers, and ice machines, communicating over the existing Wi-Fi network restricted to the 2.4 GHz ISM band on channels 6 and 11. The choice of legacy Wi-Fi 4 over modern 5 GHz standards was deliberate and dual-purpose: 2.4 GHz wavelengths penetrate dense metal obstructions far more effectively than 5 GHz, which suffers rapid attenuation, and the older hardware aligns with extreme cost constraints while its bandwidth comfortably handles MQTT&#8217;s 256-byte payloads published every 10 seconds.</p>
<p>Despite the hostile environment, the radio survey results were striking. Strategic placement and the propagation characteristics of the 2.4 GHz band held the average received signal strength indicator across all 19 nodes at −68 dBm, ranging from −55 to −82 dBm, with a signal-to-noise ratio consistently above 20 dB—a threshold the authors characterize as an excellent, high-quality channel. A subtler methodological insight emerged from hardware constraints: the ESP32&#8217;s standard network stack exposes RSSI but lacks the hooks to report raw signal-to-interference-plus-noise ratio, the metric that truly captures co-channel collisions in dense 2.4 GHz environments. The team&#8217;s workaround—treating application-layer packet loss rate and timestamp-derived network jitter as proxies for true channel health—offers a replicable recipe for any engineer deploying ultra-low-cost sensors where the silicon cannot see interference directly.</p>
<p>Over 30 days, the broker processed approximately 4.92 million telemetry messages, and the performance numbers challenge the assumption that industrial monitoring demands specialized wired infrastructure. System uptime, measured by heartbeat messages exchanged every 60 seconds across the full 720-hour window, reached 99.92 percent—above the 99.9 percent industry benchmark. Packet loss was 0.8 percent against a 2 percent tolerance, and network jitter, the standard deviation of packet arrival times, was 86 milliseconds, under the 100-millisecond benchmark. End-to-end latency, defined from sensor acquisition to database insertion and measured with NTP-synchronized clocks holding offsets within ±10 milliseconds, averaged 185 milliseconds with a median of 165. The latency distribution&#8217;s tail matters most for soft real-time monitoring: 99 percent of packets arrived within 453 milliseconds, comfortably inside the 1,000-millisecond worst-case bound, and the histogram fit a narrow Gaussian profile confirming consistent performance despite persistent electromagnetic interference.</p>
<p>To probe scalability beyond the physical testbed, the team built a discrete-event simulation in Python&#8217;s SimPy library, modeling the MQTT broker as an M/M/1 queue with Poisson packet arrivals, 256-byte payloads, 10-second transmission intervals, and deliberately conservative CSMA/CA contention parameters. Sweeping from 19 to 300 nodes revealed two distinct regimes: in the linear phase up to roughly 200 nodes, average latency rose only marginally, reaching 492 milliseconds at N = 200—just under the 500-millisecond monitoring threshold—before the system entered exponential degradation, with 99th-percentile latency exceeding 700 milliseconds at 300 nodes as channel saturation and collision backoffs compounded. The authors are careful about what this proves: the simulated baseline of about 220 milliseconds at 19 nodes intentionally exceeds the empirical 185 milliseconds because worst-case overheads were assumed, making the model a conservative upper bound on degradation rather than a validation. Beyond roughly 200 nodes, they conclude, network segmentation through additional access points or frequency division becomes a requirement, not an option.</p>
<p>The security discussion is unusually candid for a framework paper. The deployment transmits MQTT payloads in plaintext within a dedicated virtual local area network, logically air-gapped from corporate IT and the public internet, with broker access restricted by MAC filtering and firewall whitelisting. The trade-off is theoretically justified: a TLS 1.2 handshake with RSA-2048 key exchange would demand roughly 1.5 to 2.0 seconds of processing on the ESP32&#8217;s Xtensa LX6 core, and in a high-interference environment where Wi-Fi reconnections are inevitable, every reconnection would trigger that penalty, repeatedly violating the sub-500-millisecond latency budget and creating data blind spots. The authors prioritize availability and latency over device-level confidentiality—a defensible defense-in-depth position, though they acknowledge the residual risks: an insider on the local network could intercept or replay readings, and a physically stolen node could surrender its plaintext credentials, since flash encryption is not implemented. Evaluating DTLS or symmetric AES-128-GCM payload encryption is flagged as critical future work.</p>
<p>What the framework ultimately delivers is the foundational data layer on which everything else in Industry 4.0 depends. The bakery&#8217;s dashboards now resolve per-phase voltage asymmetries, pulsed current draw that delineates machine cycles, and total active power in real time; environmental nodes track temperature and humidity in production areas; and the system automatically detected and annotated a grid frequency instability event, the kind of deviation that can damage asynchronous motors and variable frequency drives. The team&#8217;s transferable guidelines—favor 2.4 GHz penetration over 5 GHz bandwidth in metal-heavy facilities, proxy channel health through packet loss and jitter when hardware cannot report SINR, buffer aggressively at the edge, and tune MQTT acknowledgment timeouts to the facility&#8217;s worst-case tail latency to avoid recursive publish loops—read as a field manual for anyone retrofitting legacy industry on a shoestring. Next steps include applying machine learning to the accumulated energy data for predictive maintenance, hardening security, and building a full dynamic digital twin of the bakery&#8217;s production line. For the millions of small factories that have watched the fourth industrial revolution from the sidelines, the message is that the price of admission has dropped to roughly the cost of a pizza per machine.</p>
<p><strong>Subject of Research:</strong> A hierarchical architecture for brownfield digitization: design, analytical insights, and validation of an ultra-low-cost Wi-Fi/MQTT IIoT framework</p>
<p><strong>Article Title:</strong> A hierarchical architecture for brownfield digitization: design, analytical insights, and validation of an ultra-low-cost Wi-Fi/MQTT IIoT framework</p>
<p><strong>Article References:</strong> Amirkhanova, G., Zhasuzakova, M., Abdulkhamit, N., Amirkhanov, B., Alipbeki, O., &amp; Raeva, A. (2026). A hierarchical architecture for brownfield digitization: design, analytical insights, and validation of an ultra-low-cost Wi-Fi/MQTT IIoT framework. <em>Frontiers in Communications and Networks, 7</em>, Article 1822183. <a href="https://doi.org/10.3389/frcmn.2026.1822183" rel="noopener noreferrer">https://doi.org/10.3389/frcmn.2026.1822183</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.3389/frcmn.2026.1822183" rel="noopener noreferrer">10.3389/frcmn.2026.1822183</a></p>
<p><strong>Keywords:</strong> hierarchical, architecture, brownfield, digitization, design, analytical, insights, validation, ultra-low-cost, Wi-Fi, MQTT, IIoT</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">278398</post-id>	</item>
		<item>
		<title>Open-Source Python Framework BRACE Brings Clinical Robotics Control Within Reach</title>
		<link>https://scienmag.com/open-source-python-framework-brace-brings-clinical-robotics-control-within-reach/</link>
		
		<dc:creator><![CDATA[Denise Maddox]]></dc:creator>
		<pubDate>Sun, 11 Oct 2026 04:56:30 +0000</pubDate>
				<category><![CDATA[Technology and Engineering]]></category>
		<category><![CDATA[biomedical experiment automation with Python]]></category>
		<category><![CDATA[BRACE]]></category>
		<category><![CDATA[cerebral palsy]]></category>
		<category><![CDATA[clinical robotics]]></category>
		<category><![CDATA[clinical robotics control framework]]></category>
		<category><![CDATA[exoskeleton]]></category>
		<category><![CDATA[hierarchical control]]></category>
		<category><![CDATA[mechanosensation]]></category>
		<category><![CDATA[MQTT]]></category>
		<category><![CDATA[open-source Python biomedical robotics]]></category>
		<category><![CDATA[open-source software]]></category>
		<category><![CDATA[open-source tools for neurological probing devices]]></category>
		<category><![CDATA[Python]]></category>
		<category><![CDATA[Python libraries for robotic system integration]]></category>
		<category><![CDATA[Python-based communication protocols for medical robots]]></category>
		<category><![CDATA[Raspberry Pi]]></category>
		<category><![CDATA[real-time control]]></category>
		<category><![CDATA[real-time robotic device control for clinical research]]></category>
		<category><![CDATA[reducing software barriers in clinical robotics development]]></category>
		<category><![CDATA[rehabilitation robotics]]></category>
		<category><![CDATA[safety monitoring in robotic medical devices]]></category>
		<category><![CDATA[sensor data acquisition in clinical robotics]]></category>
		<category><![CDATA[software for powered exoskeletons rehabilitation]]></category>
		<category><![CDATA[user interface development for clinical robots]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=261238</guid>

					<description><![CDATA[NIH researchers have released BRACE, an open-source pure-Python software framework that lets clinical researchers rapidly build, control, and tune robotic devices from exoskeletons to mechanoreception instruments without large-scale robotics infrastructure.]]></description>
										<content:encoded><![CDATA[<p>Robotic devices are quietly transforming rehabilitation medicine, from powered exoskeletons that help children with cerebral palsy walk more upright to precision actuators that probe the nervous system&#8217;s sense of touch. Yet behind every one of these machines sits a daunting wall of software: sensor drivers, communication protocols, data acquisition pipelines, safety monitors, and user interfaces that all have to work together in perfect synchrony. For clinical research teams, which rarely employ dedicated software engineers, that wall has often been enough to stop promising devices before they ever reach a patient. A new open-source framework called BRACE, short for Biomedical Robotics Architecture for Clinical Experimentation, aims to tear it down.</p>
<p>Developed by Scott Shen, Noah Rubin, and Thomas C. Bulea at the National Institutes of Health Clinical Center and described in the journal SoftwareX, BRACE is a pure-Python software framework for real-time robotic control in clinical research settings. It is released under the GNU GPL-3.0 license, available through the Python Package Index and GitHub, and built entirely from widely used Python libraries including NumPy, PySide6, PyQtGraph, pandas, and h5py. The design goal is deceptively simple: let researchers focus on the science-specific control logic of their device while the framework handles everything else, from streaming data over Wi-Fi to enforcing safety limits on actuator commands.</p>
<p>The architecture rests on a hierarchical control strategy that is already the standard structure in rehabilitation robotics. Control flow is segmented into three layers. The supervisory layer manages high-level goals such as recognizing a user&#8217;s intent or determining which phase of a cyclic task like walking the patient is in. The action layer transforms state information into actuator commands that accomplish specific objectives, such as imposing a desired torque profile on a knee joint. The execution layer carries out those commands while maintaining precision and safety. In BRACE, these layers are implemented through a set of abstract base classes and interfaces, including RobotAssemblyABC, RobotABC, IInputCom, IOutputCom, IMeasurementLists, IControlLogic, and ISafetyCheck, which researchers subclass to describe their particular hardware and controllers.</p>
<p>This compartmentalization follows the well-known Strategy design pattern from software engineering, and its practical payoff is modularity. A standardized hardware configuration can share a common set of inputs, outputs, and safety mechanisms while accommodating interchangeable control logic modules that execute distinct behaviors. Custom remote procedure call functions can be defined and invoked at runtime, dynamically modifying attributes across any subsystem without interrupting execution. In other words, an experimenter can change how a robot behaves mid-experiment without stopping the program, recompiling code, or reflashing a device, a capability that matters enormously when trial time with patients or animal subjects is scarce.</p>
<p>The framework&#8217;s client-server design links a laptop graphical interface to an embedded controller, typically a Raspberry Pi 4B, through an MQTT message broker using the Mosquitto implementation. The GUI, built with PySide6, abstracts remote procedure calls into intuitive controls for parameter configuration and command execution. A key feature is supervised soft real-time control law switching: the experimenter can transition interactively between control modes within a single experimental session. Safety is built into the switching procedure, which disables actuator torque before the change, swaps in the new controller, and then re-enables torque. During streaming, the interface deliberately locks down most configuration options to prevent unintended changes mid-trial.</p>
<p>Data handling is equally considered. Streaming data travels over Wi-Fi through the AnimatedGraphManager class, which subscribes to MQTT topics, classifies incoming messages using registered picklable NamedTuple datatypes as a portable schema, and buffers them in memory for live soft real-time visualization. Saved datasets are written to client-side storage in the Apache Parquet format, with NamedTuple field names serving as column headers so that controller-specific data subclasses can coexist within one unified streaming session. Controller transitions are encoded with NaN values that register as time-series discontinuities, and all remote procedure calls made during a session are captured, enabling post-hoc analysis of event ordering and deterministic replay.</p>
<p>Perhaps the most clinically motivated feature is the integrated offline simulator. Because clinical participants often cannot complete a high volume of trials, iterative tuning under time pressure is a chronic bottleneck. The simulator replays previously collected data as a simulated stream, allowing researchers to apply updated controller parameters and evaluate alternative configurations without the participant present. In the team&#8217;s exoskeleton example, the simulator achieved a replay accuracy of 98.1 percent, with the residual error traced to the unknown initial state of a finite-state-machine walking controller, a problem the authors address by recommending a nominal streaming blanking period before online actions begin.</p>
<p>Two independent clinical use cases demonstrate the framework&#8217;s range. The first is a lower-limb exoskeleton designed to treat crouch gait, the excessive knee flexion seen in children with cerebral palsy and other neuromotor disorders. The system runs on a Raspberry Pi 4B with a two-channel CAN bus expansion board, interfaced with bilaterally mounted Agilik knee actuators on a knee-ankle-foot orthosis, powered by a 36-volt battery stepped down to 5 volts. In testing, the control loop achieved 199.97 hertz against a 200 hertz target with only 0.66 percent jitter per 5-millisecond cycle and mean CPU usage of 43 percent per core, and controller switching took just 1.88 milliseconds, below the threshold of human perception. Streaming reliability was verified for at least six minutes, the duration required for standard 6-Minute Walk tests, and the software supported soft real-time switching between a gait-phase finite state machine and a proportional knee-angle-to-torque controller for squatting.</p>
<p>The second example is strikingly different: a closed-loop mechanoreceptive device for basic science. Mechanosensation, the ability to sense mechanical force, underlies touch perception and proprioception through molecular channels such as PIEZO2. Traditional rodent studies rely on Von Frey monofilaments, which buckle at defined forces but suffer from discrete force scaling and the variability of manual stimulus application. The BRACE-based device pairs a Zaber linear actuator with a load cell, an Arduino for signal digitization, and a Raspberry Pi running the framework&#8217;s control loop, enabling programmable, closed-loop delivery of mechanical stimuli across a continuous force range. The result is faster, more precise, and less variable measurement of stimulus thresholds and tissue stiffness, with less unnecessary exposure for animal subjects. That two such disparate systems, a wearable pediatric exoskeleton and a benchtop neurobiology instrument, could share the same software foundation illustrates the framework&#8217;s central claim of modularity.</p>
<p>The authors are candid about limitations. Hard real-time performance depends on hardware, and the framework has so far been validated only on the Raspberry Pi 4B with a CAN HAT across two sensor and actuator configurations. Meaningful customization requires proficiency in Python and object-oriented programming, deployment requires installing an MQTT broker, and the pickle-based serialization used for data collection poses a security risk that the team says makes the software suitable only for controlled research environments with trusted parties, with JSON or Protobuf suggested as safer future alternatives. Unlike commercial microcontroller firmware, it lacks encryption and verification schemes against unauthorized installation, limiting commercial applicability. Still, by lowering the technological barrier for novice programmers, supporting rapid prototyping of novel controllers, and potentially reducing participant fatigue through offline tuning, BRACE fills a genuine complexity gap. For a field where software infrastructure too often dictates the pace of clinical translation, an accessible, portable, and extensible foundation may prove to be the accelerant clinical robotics has been waiting for.</p>
<p><strong>Subject of Research:</strong> An open-source Python software framework for real-time control of robotic devices in clinical research</p>
<p><strong>Article Title:</strong> Biomedical robotics architecture for clinical experimentation (BRACE): A software framework for clinical robotics research</p>
<p><strong>Article References:</strong> Shen, S., Rubin, N., &amp; Bulea, T. C. (2026). Biomedical robotics architecture for clinical experimentation (BRACE): A software framework for clinical robotics research. <em>SoftwareX, 36</em>, Article 103096. <a href="https://doi.org/10.1016/j.softx.2026.103096" rel="noopener noreferrer">https://doi.org/10.1016/j.softx.2026.103096</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1016/j.softx.2026.103096" rel="noopener noreferrer">10.1016/j.softx.2026.103096</a></p>
<p><strong>Keywords:</strong> BRACE, clinical robotics, open-source software, Python, exoskeleton, rehabilitation robotics, hierarchical control, MQTT, Raspberry Pi, cerebral palsy, mechanosensation, real-time control</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">261238</post-id>	</item>
		<item>
		<title>Federated Learning Meets OneM2M: Smarter, Faster AI for the Internet of Things</title>
		<link>https://scienmag.com/federated-learning-meets-onem2m-smarter-faster-ai-for-the-internet-of-things/</link>
		
		<dc:creator><![CDATA[Veronica Carney]]></dc:creator>
		<pubDate>Tue, 06 Oct 2026 21:20:24 +0000</pubDate>
				<category><![CDATA[Technology and Engineering]]></category>
		<category><![CDATA[Cluster Computing]]></category>
		<category><![CDATA[distributed machine learning]]></category>
		<category><![CDATA[edge computing for IoT]]></category>
		<category><![CDATA[edge intelligence]]></category>
		<category><![CDATA[FedAvg]]></category>
		<category><![CDATA[federated learning]]></category>
		<category><![CDATA[FedProx]]></category>
		<category><![CDATA[FL-OneM2M framework]]></category>
		<category><![CDATA[Internet of Things]]></category>
		<category><![CDATA[IoT data privacy]]></category>
		<category><![CDATA[IoT sensor data analysis]]></category>
		<category><![CDATA[MQTT]]></category>
		<category><![CDATA[network-efficient AI models]]></category>
		<category><![CDATA[OneM2M]]></category>
		<category><![CDATA[privacy-preserving AI]]></category>
		<category><![CDATA[privacy-preserving machine learning]]></category>
		<category><![CDATA[quality of service]]></category>
		<category><![CDATA[real-time IoT data processing]]></category>
		<category><![CDATA[scalability]]></category>
		<category><![CDATA[scalable AI for smart cities]]></category>
		<category><![CDATA[Smart Agriculture]]></category>
		<category><![CDATA[standardized IoT service layers]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=242391</guid>

					<description><![CDATA[Researchers in Morocco have integrated federated learning with the OneM2M IoT service layer, showing faster, privacy-preserving machine learning at the network edge.]]></description>
										<content:encoded><![CDATA[<p>The Internet of Things has quietly become one of the largest data-generating machines on the planet. Billions of sensors in greenhouses, factories, hospitals, and cities continuously measure temperature, humidity, vibration, and countless other variables, producing streams of information that could feed powerful machine learning models. Yet the traditional recipe for building those models—shipping all raw data to a central cloud server for training—collides with three stubborn realities of the IoT world: limited network bandwidth, strict privacy expectations, and the sheer latency of round-trips to distant data centers. A new study published in Cluster Computing by Jamal Et-Tousy and Abdellah Zyane of Cadi Ayyad University in Safi, Morocco, tackles this collision head-on with a framework called FL-OneM2M, which welds federated learning directly onto a standardized IoT service layer.</p>
<p>Federated learning, first popularized by researchers at Google in 2017, flips the conventional training pipeline on its head. Instead of moving data to the model, the model moves to the data. Each device—or client—trains a local copy of the algorithm on its own measurements and then transmits only the resulting parameter updates, typically small numerical gradients, to a coordinating server. The server averages these updates into a shared global model and sends it back down for another round of local training. Because raw sensor readings never leave the device, the approach reduces direct exposure of sensitive information while slashing the volume of traffic that must cross the network. For IoT deployments, where a single greenhouse or smart building may host dozens of constrained devices, that distinction is not a luxury but a prerequisite.</p>
<p>What makes the Moroccan team&#8217;s contribution distinctive is where the federation logic lives. The OneM2M standard is an internationally recognized service layer designed to sit between heterogeneous IoT devices and applications, providing common primitives for registration, data storage, subscription, and notification regardless of whether devices speak HTTP, MQTT, or CoAP. Rather than bolting federated learning onto an ad hoc middleware stack, FL-OneM2M embeds it into this operational backbone, turning OneM2M into an orchestration infrastructure for decentralized intelligence. The authors argue that this integration addresses a genuine gap: most federated learning research assumes idealized communication conditions, while most IoT standards work ignores machine learning entirely. By unifying the two, the framework promises both quality-of-service awareness and scalable learning in a single architecture.</p>
<p>The experimental setup drew on data generated from IoT agricultural deployments, collected through Azure IoT devices and processed via OneM2M-based data injectors. The raw sensor streams included humidity, temperature, environmental plant indicators, and a suite of agricultural growth metrics, partitioned across multiple simulated greenhouse clients. On top of this dataset, the researchers deployed logistic-regression clients and compared two canonical federated optimization algorithms. Federated Averaging, known as FedAvg, is the simplest and most widely used scheme: clients train locally and the server weights each update by client data volume. Federated Proximal, or FedProx, adds a proximal term to the local objective that penalizes clients whose local updates drift too far from the global model, a modification intended to stabilize learning when devices are heterogeneous or perform varying amounts of local work.</p>
<p>The results, reported for an independently and identically distributed—or IID—data setting, tell a nuanced story. FedAvg reached a final accuracy of 80 percent, a gain of 50 percentage points over its starting point, and achieved a higher peak accuracy than FedProx, which topped out at 75 percent. FedProx, however, exhibited smoother loss convergence, suggesting that its regularization term does damp oscillations even when it costs some final performance on this particular problem. The authors are careful to frame these numbers as trends observed under their specific conditions rather than universal verdicts. With a single model class, a single dataset, and at most ten clients, the study deliberately scopes its claims, and the paper discusses the resulting limitations—large-scale behavior, statistical heterogeneity across clients, and security—explicitly rather than glossing over them.</p>
<p>Perhaps the most striking findings concern communication efficiency, the resource that often determines whether federated learning is practical at the edge at all. Under the study&#8217;s test conditions, switching the transport protocol from HTTP to MQTT reduced the average round-trip time by 98.4 percent, and the system reached peak accuracy roughly 40 training rounds earlier. The explanation lies in protocol design. HTTP is a request-response protocol that carries substantial header overhead and requires a new exchange for every message, whereas MQTT is a lightweight publish-subscribe protocol built for constrained networks, using minimal headers and persistent connections. In a federated loop, where the server and clients exchange model updates hundreds of times, shaving milliseconds off every round compounds into a dramatic acceleration of the entire training process. For anyone deploying learning across battery-powered sensors, that difference can separate a viable system from an intractable one.</p>
<p>Scalability tests at small scale—three, five, and ten clients—added another practical insight: five clients produced the most stable convergence in the studied configuration. This counterintuitive result reflects a real tension in federated systems. With very few clients, each local update carries outsized weight, so a single noisy or poorly conditioned client can destabilize the global model. As the client count grows, averaging smooths out individual noise, but coordination overhead rises and, in real deployments, stragglers and dropouts multiply. The team also probed resilience by simulating clients dropping out mid-training and found that the system retained 80 percent accuracy under a 10 percent client-dropout rate, an encouraging signal that the OneM2M-based orchestration can absorb a degree of real-world unreliability without collapsing.</p>
<p>The choice of agriculture as the application domain is more than incidental. Smart farming is emerging as a natural proving ground for federated learning because farms are simultaneously data-rich and privacy-sensitive: yield forecasts, disease detections, and growth metrics carry commercial value, and farmers may be reluctant to surrender raw operational data to third parties. Recent work in the field has explored federated crop disease detection from images, model-pruned yield forecasting, and blockchain-assisted trust mechanisms, all pointing toward the same conclusion that collaborative intelligence is only acceptable to many stakeholders if the data stays local. FL-OneM2M fits squarely into this movement, demonstrating that a standardized service layer can serve as the connective tissue between field sensors and a learning pipeline without a central data lake.</p>
<p>The authors are refreshingly candid about what their study does not establish. Ten clients is a toy scale compared with the thousands or millions of devices a production IoT network might involve, and behavior at large scale—where communication bottlenecks, stragglers, and server load become dominant—remains untested. The IID assumption is similarly generous: real sensor networks are notoriously non-IID, with each greenhouse, factory floor, or city block exhibiting its own statistical fingerprint, a condition known to degrade federated averaging and motivate algorithms like FedProx, SCAFFOLD, and adaptive federated optimization in the broader literature. Security is another open front, since model updates themselves can leak information or be poisoned by malicious clients, and the paper positions these challenges as explicit future work rather than solved problems. The researchers also note that the underlying dataset was generated specifically for the study and contains sensitive operational information, so it is not publicly available, though processed or anonymized subsets can be requested from the corresponding author.</p>
<p>Even within those limits, the study offers a genuinely useful template. It shows that federated learning need not live in bespoke middleware but can ride on an open, interoperable standard that the IoT industry already deploys, and it quantifies how much protocol choice—MQTT over HTTP—matters to the speed of decentralized training. As edge hardware grows more capable and privacy regulation tightens worldwide, the pressure to move intelligence out of the cloud and into the network&#8217;s periphery will only intensify. Frameworks like FL-OneM2M suggest a path in which the same infrastructure that routes sensor data today becomes the stage on which devices learn together tomorrow, one carefully averaged model update at a time.</p>
<p><strong>Subject of Research:</strong> Federated learning integrated with the OneM2M service layer for quality-of-service-aware, scalable machine learning in Internet of Things networks</p>
<p><strong>Article Title:</strong> A novel federated learning approach for enhancing QoS and scalability in IoT networks</p>
<p><strong>Article References:</strong> Et-Tousy, J., &amp; Zyane, A. (2026). A novel federated learning approach for enhancing QoS and scalability in IoT networks. <em>Cluster Computing, 29</em>(14), Article 825. <a href="https://doi.org/10.1007/s10586-026-06633-5" rel="noopener noreferrer">https://doi.org/10.1007/s10586-026-06633-5</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1007/s10586-026-06633-5" rel="noopener noreferrer">10.1007/s10586-026-06633-5</a></p>
<p><strong>Keywords:</strong> federated learning, Internet of Things, OneM2M, edge intelligence, MQTT, quality of service, FedAvg, FedProx, smart agriculture, privacy-preserving machine learning, scalability, Cluster Computing</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">242391</post-id>	</item>
		<item>
		<title>Digital Twins Meet ESG: New Framework Aims to Make Smart Factories Predictive and Sustainable</title>
		<link>https://scienmag.com/digital-twins-meet-esg-new-framework-aims-to-make-smart-factories-predictive-and-sustainable/</link>
		
		<dc:creator><![CDATA[Denise Maddox]]></dc:creator>
		<pubDate>Thu, 24 Sep 2026 23:12:53 +0000</pubDate>
				<category><![CDATA[Technology and Engineering]]></category>
		<category><![CDATA[conceptual framework]]></category>
		<category><![CDATA[decision support]]></category>
		<category><![CDATA[decision support systems for manufacturing]]></category>
		<category><![CDATA[digital twin]]></category>
		<category><![CDATA[Digital twin integration]]></category>
		<category><![CDATA[digital twin simulation and decision-making]]></category>
		<category><![CDATA[discrete-event simulation]]></category>
		<category><![CDATA[ESG]]></category>
		<category><![CDATA[ESG-oriented smart factory framework]]></category>
		<category><![CDATA[event-driven industrial architecture]]></category>
		<category><![CDATA[heterogeneous industrial data management]]></category>
		<category><![CDATA[industrial communication protocols (MQTT]]></category>
		<category><![CDATA[industrial IoT]]></category>
		<category><![CDATA[Industry 5.0]]></category>
		<category><![CDATA[Industry 5.0 manufacturing]]></category>
		<category><![CDATA[IoT sensor data integration]]></category>
		<category><![CDATA[MQTT]]></category>
		<category><![CDATA[OPC UA]]></category>
		<category><![CDATA[predictive analytics for factories]]></category>
		<category><![CDATA[predictive production planning]]></category>
		<category><![CDATA[smart manufacturing]]></category>
		<category><![CDATA[Sustainability]]></category>
		<category><![CDATA[sustainability dashboards for Industry 4.0]]></category>
		<category><![CDATA[sustainable industrial automation]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=213039</guid>

					<description><![CDATA[Researchers have proposed a six-layer, event-driven digital twin framework that links live factory data, predictive simulation, and human-approved ESG-oriented decisions in smart manufacturing.]]></description>
										<content:encoded><![CDATA[<p>Smart manufacturing has spent the last decade collecting data at a staggering rate, yet most factories still treat their digital tools as isolated islands. A digital twin might simulate a production line, an industrial IoT network might shuttle sensor readings to the cloud, and a sustainability dashboard might track emissions, but rarely do these systems talk to each other in a coordinated, decision-ready way. A new conceptual framework published in Mobile Networks and Applications argues that this fragmentation is precisely what prevents Industry 5.0 ambitions from becoming operational reality, and it proposes a detailed architecture for knitting the pieces together.</p>
<p>The framework, developed by researchers at the Technical University of Košice in the Slovak Republic, integrates six distinct concerns that the literature has typically handled separately: heterogeneous industrial data, a discrete-event simulation-based digital twin, MQTT and OPC UA communication protocols, external predictive analytics, operational ESG-oriented evaluation, and planner decision support. Rather than treating each as a standalone project, the authors arrange them into a six-layer, event-driven architecture in which information flows between layers as discrete events, triggering analysis, prediction, and ultimately human-approved decisions on the factory floor.</p>
<p>At the heart of the proposal is the idea that events, not periodic reports, should drive production planning and control. In an event-driven design, every meaningful occurrence on the shop floor, such as a machine fault, a material shortage, or a completed batch, becomes a message that propagates through the architecture. Lightweight publish-subscribe protocols like MQTT can carry high-frequency telemetry from sensors to cloud services, while OPC UA provides the standardized, semantically rich interface that industrial equipment uses to expose its state. Prior performance studies of these protocols, cited in the paper, show they are well suited to exchanging data between industrial plants and cloud servers, which makes them natural candidates for the communication backbone of a digital twin.</p>
<p>The digital twin itself is built on discrete-event simulation, a modeling technique that represents a production system as a chronological sequence of events and state changes. This choice matters because discrete-event simulation can answer the questions production planners actually ask: what happens to throughput if a machine goes down for two hours, how a rush order reshapes the schedule, or where buffers will overflow. By coupling the simulation model to live industrial data streams, the twin becomes a predictive instrument rather than a static mirror, allowing planners to test candidate schedules and interventions in silico before committing resources on the floor.</p>
<p>The second major contribution is what the authors call a four-layer transformation logic, and it is here that the framework makes its most distinctive claim. Digital technologies, the authors argue, do not directly improve environmental, social, or governance outcomes. Instead, they influence ESG-relevant results only through changes in production planning and control processes and in managerial evaluation. A sensor network by itself reduces nothing; it is the rescheduled batch, the avoided machine failure, or the reweighted performance indicator, approved by a human planner, that translates digital capability into measurable sustainability impact. This mediating logic is intended to correct what the authors see as a common weakness in the literature, where digitalization and sustainability are linked loosely without specifying the causal pathway.</p>
<p>To make the framework concrete, the paper illustrates it with a hypothetical manufacturing scenario, a complete event trace showing how messages move through the six layers, and formal definitions of measurable indicators. The indicator definitions are designed to be operational, meaning they specify exactly what is measured, from what data, and how the resulting values feed into ESG-oriented evaluation. This level of specification is what separates a genuine decision-support architecture from a conceptual diagram: planners can, in principle, implement the indicators directly and audit how each recommendation was derived from underlying events.</p>
<p>Human oversight is built into the architecture rather than bolted on. The framework explicitly positions planner decision support as the final layer, so that predictive outputs and ESG evaluations arrive as recommendations that a human decision-maker reviews and approves before any change to production planning takes effect. This design reflects the broader Industry 5.0 movement, which, as the European policy literature cited in the paper emphasizes, seeks a sustainable, human-centric, and resilient industry rather than full autonomy. The authors position their work in this tradition, drawing on recent scholarship that frames Industry 5.0 as a corrective to the technology-first ethos of Industry 4.0.</p>
<p>The intellectual lineage of the framework is broad. It builds on established digital twin reference models and six-layer architectural patterns from the manufacturing literature, on systematic reviews of machine learning applications in production lines and predictive quality, and on a growing body of work connecting intelligent manufacturing to ESG performance, including empirical studies of Chinese manufacturing firms and recent analyses asking whether smarter production is also greener. By synthesizing these strands, the authors aim to provide what they describe as an explicit integration of technical event flows with human-approved, ESG-oriented production planning and control decisions, something they argue no single existing framework delivers.</p>
<p>The authors are candid about the limits of the current study. The framework is derived through a structured conceptual synthesis, and the paper does not report implemented or empirically validated performance results. No datasets were generated or analyzed, and the hypothetical scenario exists to illustrate the architecture, not to prove it. The authors list as future work a set of concrete validation steps: discrete-event simulation experiments, construction of an MQTT and OPC UA testbed, expert assessment, and industrial validation in real manufacturing settings. Until those studies are complete, the framework should be read as a rigorous design proposal and a research agenda rather than a demonstrated solution.</p>
<p>Even so, the timing of the proposal is significant. Manufacturers worldwide face simultaneous pressure to digitize operations and to report credible environmental, social, and governance performance, and regulators and investors increasingly demand that sustainability claims rest on verifiable operational data. A framework that traces a straight line from a sensor event, through a predictive simulation, to a planner-approved scheduling decision and a defined ESG indicator offers exactly the kind of auditable causal chain that both engineers and sustainability officers need. If the planned testbed and industrial validation bear out the design, event-driven digital twins could become the connective tissue that finally unifies the smart factory&#8217;s many brains, turning streams of industrial telemetry into decisions that are simultaneously faster, more predictive, and demonstrably more sustainable.</p>
<p><strong>Subject of Research:</strong> An event-driven digital twin framework for predictive production planning and ESG-oriented decision support in smart manufacturing</p>
<p><strong>Article Title:</strong> A Conceptual Framework for Event-Driven Digital Twin-Based Predictive Production Planning and ESG-Oriented Decision Support in Smart Manufacturing</p>
<p><strong>Article References:</strong> Karakai, M., &amp; Bobko, D. (2026). A Conceptual Framework for Event-Driven Digital Twin-Based Predictive Production Planning and ESG-Oriented Decision Support in Smart Manufacturing. <em>Mobile Networks and Applications</em>. <a href="https://doi.org/10.1007/s11036-026-02535-3" rel="noopener noreferrer">https://doi.org/10.1007/s11036-026-02535-3</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1007/s11036-026-02535-3" rel="noopener noreferrer">10.1007/s11036-026-02535-3</a></p>
<p><strong>Keywords:</strong> digital twin, smart manufacturing, Industry 5.0, discrete-event simulation, MQTT, OPC UA, predictive production planning, ESG, decision support, industrial IoT, sustainability, conceptual framework</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">213039</post-id>	</item>
		<item>
		<title>Harley the Robot Brings Multilingual AI Home Automation for Under 10,000 Rupees</title>
		<link>https://scienmag.com/harley-the-robot-brings-multilingual-ai-home-automation-for-under-10000-rupees/</link>
		
		<dc:creator><![CDATA[Denise Maddox]]></dc:creator>
		<pubDate>Sun, 13 Sep 2026 00:18:35 +0000</pubDate>
				<category><![CDATA[Technology and Engineering]]></category>
		<category><![CDATA[affordable domestic robotics]]></category>
		<category><![CDATA[affordable intelligent home automation solutions]]></category>
		<category><![CDATA[assistive robots]]></category>
		<category><![CDATA[conversational AI]]></category>
		<category><![CDATA[cost-effective smart home devices]]></category>
		<category><![CDATA[ESP32]]></category>
		<category><![CDATA[Google Gemini]]></category>
		<category><![CDATA[home automation]]></category>
		<category><![CDATA[home automation robot]]></category>
		<category><![CDATA[Indian-developed home automation technology]]></category>
		<category><![CDATA[indoor navigation]]></category>
		<category><![CDATA[IoT]]></category>
		<category><![CDATA[low-cost AI home assistant]]></category>
		<category><![CDATA[MQTT]]></category>
		<category><![CDATA[multilingual AI home automation systems]]></category>
		<category><![CDATA[multilingual speech recognition in robotics]]></category>
		<category><![CDATA[multilingual technology]]></category>
		<category><![CDATA[multilingual voice-controlled home robot]]></category>
		<category><![CDATA[navigation and appliance control robot]]></category>
		<category><![CDATA[Raspberry Pi]]></category>
		<category><![CDATA[robotics]]></category>
		<category><![CDATA[robotics research in India]]></category>
		<category><![CDATA[voice interaction]]></category>
		<category><![CDATA[voice-controlled household robot for developing countries]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=199968</guid>

					<description><![CDATA[Researchers at Nirma University have built Harley, a sub-10,000-rupee robot that combines autonomous indoor navigation, MQTT-based appliance control, and multilingual conversational AI for home services.]]></description>
										<content:encoded><![CDATA[<p>A voice-controlled home robot that can navigate a house, switch appliances on and off, and hold a natural conversation in multiple languages has been built for less than 10,000 rupees — roughly one-fifth of the cost of comparable commercial systems. The robot, named Harley, was developed by Tanvi Chokshi of the Department of Electronics and Instrumentation and Dhaval Shah and Viranchi Pandya of the Department of Electronics and Communication at Nirma University in Ahmedabad, India, and described in the International Journal of Intelligent Robotics and Applications. The team set out to tackle three persistent problems in domestic robotics: prohibitive price tags, fragmented functionality that handles either navigation or smart-home control but rarely both, and the near-universal assumption that users speak English.</p>
<p>According to the researchers, existing voice-controlled home service robots typically cost between 150,000 and 250,000 rupees, placing them far beyond the reach of most households in developing economies. Those that are affordable tend to be narrow in capability, addressing a single subsystem such as autonomous movement or internet-of-things appliance control in isolation. And almost without exception, commercial platforms restrict voice interaction to English, excluding the hundreds of millions of users whose first languages are Hindi, Gujarati, or any of the other tongues spoken across linguistically diverse regions. Harley&#8217;s designers argue that no single commercial product currently combines mobile navigation, standard-protocol IoT control, and multilingual conversational AI at any comparable price point.</p>
<p>Technically, Harley rests on a deliberate division of labour between two compute tiers. A Raspberry Pi serves as the high-computing device, handling speech recognition, natural language understanding, navigation decision-making, and the coordination of subsystems. An ESP32 microcontroller sits at the other end of the architecture, tasked with driving the relays and circuits that switch high-power household appliances safely. The bridge between them is MQTT, the lightweight publish-subscribe messaging protocol that has become a de facto standard in industrial and consumer IoT deployments. By structuring communication around MQTT topics, the team decoupled the intelligence layer from the actuation layer, allowing the Raspberry Pi to issue commands to the ESP32 without direct electrical coupling and making the appliance-control subsystem extensible to any MQTT-compliant device.</p>
<p>The conversational layer is powered by the Google Gemini API, which the robot uses to interpret spoken commands and generate context-aware responses across multiple languages. Rather than relying on rigid, keyword-matched command grammars, Harley pipes captured speech to the large language model, which can handle paraphrase, mixed-language utterances, and open-ended questions in addition to discrete instructions such as switching off a fan or navigating to the kitchen. The researchers report that this integration enabled natural, context-aware communication, and that in experimental trials the system earned an average conversational quality rating of 4.1 out of 5.0 across multiple languages — a figure that, while drawn from their own residential evaluation, suggests the interaction model was judged substantially better than the brittle command-and-response behaviour typical of low-cost voice devices.</p>
<p>Navigation is the third pillar of the design. Harley supports voice-enabled navigation commands that direct the robot to predefined locations inside the home, using stored coordinates recorded within the environment. In practice, a user can ask the robot to travel to a named waypoint — a room, a charging dock, or a designated position — and the robot plans and executes the movement autonomously. The waypoint approach trades the complexity of full simultaneous localisation and mapping for a simpler, more robust scheme suited to static home layouts, and it keeps the computational burden low enough to run on modest hardware. The team notes that experimental validation in a residential setting measuring 75 square metres across four rooms demonstrated a high voice recognition accuracy and an improved navigation success rate alongside reliable appliance control with low latency.</p>
<p>The economics of the build are arguably its most striking feature. The researchers itemised the total component cost of Harley at 9,247 rupees, which they benchmarked against a mid-range alternative configuration assembled from commercial off-the-shelf parts at 47,850 rupees — an 80 percent component-level saving. Compared with the 150,000 to 250,000 rupee range quoted for existing voice-controlled home service robots, Harley comes in at roughly 19 percent of the cost of an equivalent system, and a small fraction of the premium end of the market. The authors frame this not merely as an engineering achievement but as a question of access: high-performance home automation robotics, they argue, is achievable at a fraction of current market cost, with particular relevance to multilingual and cost-sensitive environments, including those serving elderly users in developing economies.</p>
<p>That last point carries social weight. India&#8217;s ageing population, like much of Asia&#8217;s, is growing faster than the infrastructure available to support it, and voice-first interfaces are among the most accessible technologies for users with limited mobility, declining eyesight, or low digital literacy. A robot that understands commands in a user&#8217;s native language and can physically move through the home — fetching itself to a bedside, switching appliances, answering questions — addresses a genuinely different user group than the wall-mounted smart speakers and app-controlled plug ecosystems that dominate the consumer market. The researchers position Harley within a broader body of work on service robots in aged care, noting that prior deployments have shown promise but frequently stumble on cost, language support, and the integration gap between mobility and control functions.</p>
<p>The study is candid about its experimental scope. Validation was conducted in a single residential setting rather than across a fleet of homes, and the waypoint-based navigation scheme presumes a relatively stable floor plan, meaning a significant rearrangement of furniture would require re-recording stored coordinates. The conversational quality scores, while encouraging, originate from the development team&#8217;s own evaluation, and larger, independent user studies with elderly and non-technical participants would be needed to establish how the system performs under real-world acoustic conditions, accents, and background noise. The cloud dependence of the Gemini API also raises questions about latency, privacy, and behaviour during internet outages — a consideration the authors&#8217; own cited literature on offline voice interaction for elderly-care robots highlights as an open challenge in the field.</p>
<p>Even so, the work signals a shift in what low-cost robotics can credibly deliver. By pairing commodity single-board computers with lightweight IoT protocols and cloud-scale language models, small academic teams can now assemble systems that until recently demanded enterprise budgets. If the cost trajectory holds, the practical consequences could reach well beyond gadget enthusiasts: assistive robots for elderly users who speak minority languages, affordable automation for small clinics and care homes, and educational platforms that let students experiment with integrated robotics without institutional funding. The Nirma University team, which received no specific grant from any funding agency and developed the system with laboratory facilities and laser-cutting equipment at the institute, has demonstrated that the barrier to a genuinely useful, multilingual, mobile home robot is no longer primarily technical or financial — it is a matter of integration, and Harley shows one concrete way to close it.</p>
<p><strong>Subject of Research:</strong> A low-cost multilingual voice-interactive home service robot integrating navigation, IoT control, and conversational AI</p>
<p><strong>Article Title:</strong> Harley: a voice interactive intelligent robot for home services and automation</p>
<p><strong>Article References:</strong> Chokshi, T., Shah, D., &amp; Pandya, V. (2026). Harley: a voice interactive intelligent robot for home services and automation. <em>International Journal of Intelligent Robotics and Applications</em>. <a href="https://doi.org/10.1007/s41315-026-00587-y" rel="noopener noreferrer">https://doi.org/10.1007/s41315-026-00587-y</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1007/s41315-026-00587-y" rel="noopener noreferrer">10.1007/s41315-026-00587-y</a></p>
<p><strong>Keywords:</strong> robotics, home automation, voice interaction, MQTT, Raspberry Pi, ESP32, conversational AI, Google Gemini, indoor navigation, IoT, multilingual technology, assistive robots</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">199968</post-id>	</item>
		<item>
		<title>Marine Predator Algorithm Steers Smarter Fuzzing for Binary Protocols</title>
		<link>https://scienmag.com/marine-predator-algorithm-steers-smarter-fuzzing-for-binary-protocols/</link>
		
		<dc:creator><![CDATA[Hailey Crawford]]></dc:creator>
		<pubDate>Sat, 12 Sep 2026 19:02:07 +0000</pubDate>
				<category><![CDATA[Technology and Engineering]]></category>
		<category><![CDATA[AI-driven security testing]]></category>
		<category><![CDATA[automated fuzzing framework]]></category>
		<category><![CDATA[binary protocol vulnerability testing]]></category>
		<category><![CDATA[binary protocols]]></category>
		<category><![CDATA[CoAP]]></category>
		<category><![CDATA[coverage improvement in fuzzing]]></category>
		<category><![CDATA[crash discovery in binary protocols]]></category>
		<category><![CDATA[cybersecurity]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[DTLS]]></category>
		<category><![CDATA[efficient network protocol analysis]]></category>
		<category><![CDATA[greybox fuzzing]]></category>
		<category><![CDATA[industrial control system security]]></category>
		<category><![CDATA[IoT protocol fuzzing]]></category>
		<category><![CDATA[marine predator algorithm]]></category>
		<category><![CDATA[Marine Predators Algorithm]]></category>
		<category><![CDATA[MQTT]]></category>
		<category><![CDATA[mutation scheduling]]></category>
		<category><![CDATA[nature-inspired fuzzing]]></category>
		<category><![CDATA[network protocol security]]></category>
		<category><![CDATA[network security]]></category>
		<category><![CDATA[software testing]]></category>
		<category><![CDATA[vulnerability detection in binary formats]]></category>
		<category><![CDATA[vulnerability discovery]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=197624</guid>

					<description><![CDATA[Researchers have developed MPAuzz, a greybox fuzzer that uses the nature-inspired Marine Predators Algorithm to intelligently schedule mutations of binary protocol messages, dramatically improving test-case validity, code coverage, and crash discovery across MQTT, DTLS, DNS, and CoAP implementations.]]></description>
										<content:encoded><![CDATA[<p>Security researchers have unveiled a new fuzzing framework that borrows its search strategy from the hunting behavior of ocean predators, and the results suggest that nature-inspired optimization could reshape how the software industry hunts for vulnerabilities in binary network protocols. The tool, called MPAuzz, was developed by Chuan Jiang, Zheng Hong, Guomin Zhang, Yuxuan Li, and Jinbang Gu of the Army Engineering University of PLA in Nanjing, China, and is described in a study published in the open-access journal Cybersecurity. In head-to-head experiments against established protocol fuzzers, MPAuzz achieved a striking average valid-test-case ratio of 98.1 percent, improved branch coverage by 38.3 percent over AFLNet and 26.5 percent over StateAFL, and triggered the highest number of crashes across every target it was tested against.</p>
<p>Binary protocols, which encode data directly as compact byte sequences rather than human-readable text, form the backbone of much of the modern digital world. They underpin network devices, industrial control systems, and Internet of Things applications, where efficiency and low overhead are paramount. But their very compactness creates a security blind spot. Unlike text protocols, binary formats lack delimiters, tags, and other redundant markers that make field boundaries obvious. When implementations of these protocols mishandle malformed messages, the consequences can be severe. The researchers point to the infamous EternalBlue vulnerability in the SMB protocol, which arose from improper parsing of binary messages and enabled buffer overflow and remote code execution with global impact, as a stark reminder of what is at stake.</p>
<p>Mutation-based greybox fuzzing has become one of the most widely used techniques for discovering such flaws. Greybox fuzzers occupy a middle ground between blackbox and whitebox approaches: they do not require complete knowledge of a program&#8217;s internals, but they do use lightweight runtime feedback, such as coverage information gathered through instrumentation, to guide how inputs are mutated. Tools like AFL, AFL++, and MOPT generate malformed test cases by applying mutation operators such as bit flips and byte substitutions to well-formed seed messages, then monitor the target program for crashes, hangs, and other abnormal behavior. The approach has uncovered countless vulnerabilities, yet the authors argue that existing fuzzers stumble when confronted with structured binary messages.</p>
<p>The team identifies three core challenges. First, protocol parsing is difficult because binary protocols represent data as bit streams with unclear field boundaries and implicit semantics, making it laborious to determine which positions in a message can safely be mutated. Second, evaluating the mutation value of different fields is hard because the effect of changing a field depends on runtime behavior, field dependencies, and the target program&#8217;s responses, none of which can be reliably determined statically. Third, and perhaps most damaging, existing fuzzers schedule mutation operators blindly. A bit flip applied to a function code field may drive a program into entirely new logical states, while the same operation on a data field merely alters content. Worse, mutating a length field without adjusting the corresponding payload breaks the message structure, causing the test case to be discarded before it ever reaches deep parsing logic.</p>
<p>MPAuzz tackles these problems in two stages. The first is a feedback-based mutation position exploration module that partitions protocol messages at bit-level granularity rather than the coarser byte level used by most prior tools. This fine granularity matters: in an MQTT message, for example, the high four bits of the header flags field determine the message type while the low four bits serve as flags, a distinction that byte-level analysis cannot capture. The module flips one bit at a time, sends the mutated message to the target, and classifies the result. Normal responses mark a bit as mutable; format anomalies detected with protocol parsing tools such as Tshark mark it as restricted; and mutations of essential control fields such as protocol names and function codes mark regions as immutable. Adjacent bits with similar properties are then merged into continuous regions, giving the fuzzer a map of where mutation is safe, where it must respect constraints, and where it is forbidden.</p>
<p>The second stage is where the ocean comes in. MPAuzz formulates mutation operator scheduling as a multidimensional optimization problem in which each dimension corresponds to the operator choice for one mutation region, and it solves this problem using the Marine Predators Algorithm, a metaheuristic inspired by how marine predators forage. The historically best operator combination plays the role of the predator, while candidate combinations act as prey. The algorithm dynamically switches between Lévy flights, long-distance jumps that enable broad exploration, and Brownian motion, small-step searches that enable fine-grained exploitation. The researchers deliberately chose MPA over alternatives such as multi-armed bandit strategies and particle swarm optimization because mutating one region of a binary message often depends on other regions; treating each region as an independent arm can produce structurally invalid test cases, while PSO&#8217;s velocity-based updates risk premature convergence when early coverage gains come from only a few regions.</p>
<p>The scheduling unfolds across three adaptive stages that mirror the fuzzing lifecycle. In the early, high-speed exploration stage, Lévy-distributed random vectors drive wide-ranging tests of operator combinations to avoid premature convergence. In the middle, balanced coordination stage, the population splits: half fine-tunes the elite combination using Brownian perturbations governed by a quadratically decreasing convergence factor, while the bottom-performing half continues exploring with Lévy motion. In the final, low-speed exploitation stage, an enhanced social learning term pulls candidate combinations toward the best-known strategy, changing only one or a few region assignments at a time. Crucially, a candidate combination is retained only if it satisfies region-specific constraints and improves coverage feedback. The framework also includes a repairing step for restricted regions: when a mutable payload region changes size, the associated length field is recalculated automatically, with nested dependencies repaired from the innermost region outward.</p>
<p>To validate the design, the team evaluated MPAuzz on four widely used binary protocol implementations covering MQTT, DTLS, DNS, and CoAP, comparing it against AFLNet and StateAFL, two of the most prominent greybox protocol fuzzers. Each fuzzer ran continuously for 24 hours per target, with each experiment repeated ten times to account for the inherent randomness of fuzzing. The results were decisive. MPAuzz&#8217;s valid-test-case ratio exceeded 97 percent on every target, compared with 83.1 percent for a multi-armed bandit variant and 79.5 percent for a PSO variant of the same tool. It reached comparable coverage 3.47 times faster than AFLNet and 2.22 times faster than StateAFL on average, with Vargha-Delaney effect sizes mostly at or above 0.85, indicating a consistent statistical advantage.</p>
<p>The vulnerability discovery results were equally compelling. Instrumenting targets with AddressSanitizer to capture memory-related faults, the researchers found that MPAuzz produced more crashes than both baselines on all four targets. On the Mosquitto MQTT broker, MPAuzz triggered an average of 87.8 crashes per run, compared with 3.9 for AFLNet and 43.2 for StateAFL, and exposed its first crash just 32 minutes into testing, whereas AFLNet failed to crash the target within the allotted time at all. On Tinydtls, MPAuzz found its first crash in 15 seconds. Analysis of the proof-of-concept inputs showed that the anomalies detected in Mosquitto and Libcoap correspond to real, documented vulnerabilities: the medium-severity CVE-2021-28166, a null pointer dereference triggered when an authenticated client sends a mutated SUBSCRIBE message before the server issues a PUBLISH message, and the high-severity CVE-2024-46304. These findings demonstrate that the fuzzer can surface genuine security flaws arising from abnormal protocol-state sequences, not merely superficial parsing errors.</p>
<p>The authors are candid about limitations. MPAuzz currently leans on external parsers such as Tshark and Scapy for protocol-format feedback, so for proprietary or undocumented protocols the precision of restricted and immutable region identification may degrade, though the fuzzer can still operate using runtime responses and coverage feedback alone. The automatic repair mechanism primarily supports length-related constraints; checksums, authentication fields, and state-dependent constraints require protocol-specific rules. The evaluation, while rigorous, covers four protocol implementations, and the team notes that additional targets and longer experiments would strengthen the evidence. Still, the work makes a persuasive case that combining protocol-aware region classification with staged, nature-inspired operator scheduling is a practical path forward for binary-protocol fuzzing, and the researchers plan to reduce reliance on external parsers and extend support for proprietary protocols with complex field dependencies in future work.</p>
<p><strong>Subject of Research:</strong> A nature-inspired greybox fuzzing framework for discovering vulnerabilities in binary network protocol implementations</p>
<p><strong>Article Title:</strong> Binary protocol greybox fuzzing driven by marine predators algorithm</p>
<p><strong>Article References:</strong> Jiang, C., Hong, Z., Zhang, G., Li, Y., &amp; Gu, J. (2026). Binary protocol greybox fuzzing driven by marine predators algorithm. <em>Cybersecurity, 9</em>(1), Article 214. <a href="https://doi.org/10.1186/s42400-026-00646-8" rel="noopener noreferrer">https://doi.org/10.1186/s42400-026-00646-8</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1186/s42400-026-00646-8" rel="noopener noreferrer">10.1186/s42400-026-00646-8</a></p>
<p><strong>Keywords:</strong> binary protocols, greybox fuzzing, Marine Predators Algorithm, vulnerability discovery, mutation scheduling, network security, MQTT, DTLS, DNS, CoAP, software testing, cybersecurity</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">197624</post-id>	</item>
	</channel>
</rss>
