OT Control and Integration of Mobile Robotic Networks

Abstract

This paper introduces a configuration and integration model for mobile robots deployed in emergency and special operations scenarios. The proposed method is designed for implementation within the operational technology (OT) domain, enforcing security protocols that ensure both data encryption and network isolation. The primary objective is to establish a dedicated operational environment encompassing a command and control center where the robotic network server resides, alongside real-time data storage from network clients and remote control of field-deployed mobile robots. Building on this infrastructure, operational strategies are developed to enable an efficient robotic response in critical situations. By leveraging remote robotic networks, significant benefits are achieved in terms of personnel safety and mission efficiency, minimizing response time and reducing the risk of injury to human operators during hazardous interventions. Unlike generic IoT or IoRT systems, this work focuses on secure robotic integration within segmented OT infrastructures. The technologies employed create a synergistic system that ensures data integrity, encryption, and safe user interaction through a web-based interface. Additionally, the system includes mobile robots and a read-only application positioned within a demilitarized zone (DMZ), allowing for secure data monitoring without granting control access to the robotic network, thus enabling cyber-physical isolation and auditability.

1. Introduction

Data security has become a critical concern in the development of robotic network architectures, primarily due to the increasing risk of information theft through various hacking techniques. As a result, operational environments involving the management and control of intelligent machines demand the integration of secure communication protocols within the operational technology (OT) domain. This ensures that data transmission across such systems remains encrypted and protected.

In this context, emergency scenarios involving mobile robotic networks, whether swarm-based or networked systems [1], require dedicated communication and data protection strategies to prevent interception or data breaches. Prior studies [2,3] have underscored the vulnerability of data within robotic networks to a broad spectrum of cyber threats. These include, but are not limited to, phishing schemes, man-in-the-middle attacks, and malicious activities originating from within the network, such as insider threats.

Pioneering work by Parker et al. [4] provides a foundational overview of distributed autonomous mobile robotics, emphasizing the importance of cooperative strategies and decentralized decision-making in dynamic environments. These early principles remain highly relevant as modern robotic networks increasingly depend on coordinated autonomy.

Reference [5] outlines the benefits of using mobile robotic networks for enhanced data acquisition from sensor-based systems via Wireless Sensor and Robot Network with Teleoperation (WSRNT). In addition, Leonardi et al. [6] propose a priority-based bandwidth management mechanism for virtualized software-defined networks (SDNs), offering a scalable and secure approach to traffic differentiation, an aspect crucial for robotic networks operating under bandwidth-constrained emergency conditions.

Furthermore, the integration of mobile robots into secure networks is reinforced through the adoption of emerging IoT-based technologies such as the Internet of Robotic Things (IoRT) [7]. This paradigm enables remote control capabilities via cloud computing platforms while ensuring secure access and data exchange. Vermesan et al. [7] illustrate how intelligent connectivity platforms and heterogeneous sensor integration through IoRT foster context awareness and operational resilience in robotic systems deployed across varied mission scenarios.

Moreover, the review article “Control Methods for Internet-Based Teleoperation Systems” [8] examines how latency and communication infrastructure scalability affect robot teleoperation. Intelligent control mechanisms are thus essential, as discussed in [9], where adaptive and robust control methods are compared. A reliable approach for managing such control involves defining structural schemes that map robotic control events, as introduced in [10], which utilize programmatic functions to link control blocks.

Advancements in swarm robotics have further reinforced the strategic use of multi-agent systems in dynamic and unpredictable environments. Brambilla et al. [11] provide a comprehensive review from a swarm engineering perspective, highlighting the critical features for robotic systems deployed in emergency scenarios, such as scalability, fault tolerance, and decentralized coordination. These properties are essential when individual agents must autonomously adapt to degraded communication or sensor failures while maintaining global objectives.

In parallel, robust teleoperation remains a vital fallback strategy when autonomy is not feasible or during high-risk tasks. Moniruzzaman et al. [12] present an extensive survey of teleoperation methods, enhancement techniques, and their relevance to mobile robots, emphasizing the role of interface responsiveness and situational awareness. In this context, latency-compensating strategies and predictive control mechanisms become indispensable for maintaining operator effectiveness over potentially unstable networks.

Further reinforcing the need for intelligent control, Zaborniak et al. [13] propose an iterative learning control (ILC) strategy tailored for mobile robots operating in uncertain or repetitive environments. Their approach supports improved path-tracking performance and adaptive correction based on prior motion executions—features that are particularly useful in search and rescue missions that involve repeated path exploration or return trajectories.

Lastly, Grosjean et al. [14] introduce a co-design framework for communication compute control in cyber-physical systems. Their model addresses the joint optimization of resource allocation, real-time computation, and reliable communication principles that are directly applicable to mobile robotic networks requiring synchronized control and data exchange across heterogeneous infrastructure.

In line with these approaches, the present study proposes a secure data management framework for mobile robotic networks in emergency scenarios. This is achieved by implementing a dedicated operational domain managed by a central command and control server that oversees and coordinates all necessary functionalities for optimal system performance.

Figure 1 illustrates and explains the two primary domains of networked environments, information technology (IT) and operational technology (OT), along with their general functionalities. The IT domain refers to the segment primarily dedicated to data management, communication, and general purpose applications, often characterized by high connectivity and interoperability but also greater exposure to external threats.

In contrast, the OT domain encompasses autonomous, isolated, and self-contained systems commonly found in industrial and critical infrastructure settings. These systems operate on proprietary software platforms and focus on the real-time control, monitoring, and automation of physical processes and intelligent machine infrastructures. The OT environment is not inherently secure and is typically segregated from IT networks to reduce risk and ensure operational continuity.

Gateways exist at the interface between OT and IT domains, facilitating controlled and secure communication, often employing virtualization and multi-factor authentication (MFA) to regulate remote user access. In the context of robotic networks, OT systems directly manage physical robots and their operational data, while IT systems provide broader capabilities such as data storage, analytics, and user interaction interfaces.

The proposed system represents an Internet of Robotic Things (IoRT) architecture built on a secure server–client communication model. It incorporates multiple data protection mechanisms, including Transport Layer Security (TLS) and hash-based signature verification, ensuring robust encryption and authentication. The system also includes a read-only web application deployed in the DMZ, enabling secure monitoring of robotic activity without granting control privileges. A separate Web Platform provides operators with encrypted access to real-time telemetry and system status, supporting traceable and isolated human–robot interaction within industrial or mission-critical environments.

This paper is organized into seven sections, each addressing a distinct component of the proposed solution for secure robotic networks designed to support emergency response operations. Section 2 focuses on the definition and development of the robotic network within the OT domain, detailing the communication protocols, software and security design strategies, client–server interaction model, and mechanisms for data storage and archiving. Section 3 describes the development of read-only applications within the DMZ domain, emphasizing the use of enforced firewall rules to ensure unidirectional data flow (from OT to DMZ) and prevent remote control from external layers.

Section 4 presents the results of robotic network development, including practical observations and system log excerpts. Section 5 discusses the current system limitations, especially regarding scalability, authentication flexibility, and performance under high-load scenarios. Section 6 outlines future research directions, such as implementing network redundancy and conducting broader real-world testing. Finally, Section 7 delivers the concluding remarks, summarizing the contribution and significance of the proposed architecture.

2. Definition and Development of the Robotic Network Within the OT Domain

As previously discussed, this study proposes the integration of a server–client-based robotic network within the OT domain using virtualization technologies. The architecture defines the connection between the server and its clients, including mobile robots and web browsers, through Wi-Fi communication.

2.1. Architecture and Deployment of the Command and Control Center

The first step in the development of the robotic network involves the definition and securement of the command and control center. This is implemented as a virtual machine (VM), deployed and secured using the AWS EC2 service. This virtual instance hosts a robotic network server and enables remote user access through a web-based platform. The VM runs on a Windows Server operating system and can be accessed via the Remote Desktop Protocol (RDP), following a defined authentication and connection procedure:

• The user must know the public IP address of the VM instance;
• The AWS VM instance administrator must allow inbound traffic from the user’s IP address, enabling the authentication process;
• The user must possess a valid username and password for access;
• The password is generated using a self-signed certificate and is securely shared with the user by the VM administrator;
• The user launches the Remote Desktop Protocol (RDP) application and enters the VM’s public IP address to initiate the remote connection.

Integrating the server into a virtual machine that can be accessed remotely enhances the flexibility of the command and control team by enabling simultaneous access from multiple geographic locations.

Figure 2 illustrates the network positioning of the command center, the server, and the login pathways for both users and client devices. The figure also outlines the functional relationship between the network server, the Web Platform, and the relational database management system (RDBMS).

All network components communicate with the central server, transmitting data to it, and are required to register and authenticate before interaction is permitted.

The following subsection defines and explains the core functionalities of the robotic network server by detailing its main operational components and services.

2.2. Architecture and Deployment of the Robotic Network Server

The robotic network server is utilized as the central entity responsible for processing all network data and facilitating communication with the other components of the infrastructure, specifically its connected clients. The main responsibilities of the robotic network server are as follows:

• Maintaining the network in an operational and stable state (Up and Normal–UN);
• Sustaining continuous connection with browser-based clients;
• Sustaining continuous connection with mobile robot clients;
• Ensuring that the Web Platform remains fully operational;
• Maintaining an active and stable connection with the PostgreSQL RDBMS;
• Securely processing incoming data from all connected clients;
• Transmitting control commands to client devices.

The functionalities of this server were developed using web backend technologies, employing asynchronous data processing to handle multiple HTTP/S requests concurrently. Server security is ensured through the use of WSS-based connections, which rely on certificates issued by a trusted certificate authority (CA), as well as WebSocket (WS) communication secured with hash signature-based authentication.

2.3. Definition of Networks’ Clients

The clients of the robotic network are virtual entities that maintain a continuous and secure connection with the command and control center. These clients connect to the server and issue HTTP/S requests as part of their interactions.

The clients are divided into two main categories: mobile robots that operate within the robotic network and web browsers used to display data to end users via the Web Platform.

This approach leverages modern Internet of Things (IoT) functionalities to automate emergency missions and significantly reduce the need for human presence in the field.

The robotic network clients that connect to the server employ distinct protocols for authentication and registration within the network:

• mobile robots (connection via hash-sign protocol);
• web browsers running the Web Platform (GUI interface), which uses connection via TLS/SSL protocol with certificates signed by a certificate authority (CA).

For the network testing phase, the integration of three mobile robots into the system is proposed, aiming to establish interconnectivity. These robots are illustrated as 3D models in Figure 3a,b [15] and Figure 3c).

These mobile robots are identified based on the MAC address of the microcontroller used through the generation of an encrypted digital signature. The network can be easily extended by adding additional mobile robots, provided that the MAC addresses of their microcontrollers are known. It is mandatory for each MAC address to be present in the server’s database in order to instantiate the registration process within the network. This specific address was chosen for signature generation because it is static and uniquely represents each mobile robot’s control unit. The digital signature used for network registration may vary depending on the hash method employed for encryption.

Table 1. Definition of MAC addresses and microcontrollers of mobile robots for network integration.

Client	MAC Address	Microcontroller
Robot_1	94:0D:7A:1B:5A:E0	ESP 32 Wi-Fi Doit
Robot_2	C0:49:EF:6B:EC:0C	Arduino MKR 1010
Robot_3	E0:23:AB:3B:ED:0A	Arduino MKR 1010

lists the Media Access Control (MAC) addresses of mobile robot clients that will authenticate and register within the network.

The computed digital signature is transmitted to the server, and if successfully recognized, the mobile robot will authenticate and register within the network as a valid client.

Figure 4 illustrates the logic of the secure registration process implemented in the proposed mobile robotic network. Each robot is uniquely identified by its microcontroller’s MAC address, which serves as the basis for generating a digital signature used in the authentication phase. The corresponding pseudocode present in Algorithm 1 formalizes this process by defining the internal MAC address registry, the local signature generation method on the robot side, and the server side validation and registration procedure. If the received MAC address is found in the server’s database and the signature matches the expected result, the robot is authenticated and formally registered in the network. Otherwise, access is denied, thus ensuring both identity verification and communication integrity.

Algorithm 1. Pseudocode regarding Authentication and Registration of Mobile Robots via MAC Address and Digital Hash-Signature

// INITIAL SETUP

Define MAC_ROBOTS_DB = {

“94:0D:7A:1B:5A:E0”: "Robot_1",

“C0:49:EF:6B:EC:0C”: "Robot_2",

“E0:23:AB:3B:ED:0A”: "Robot_3"

}

// FUNCTION TO GENERATE DIGITAL SIGNATURE

Function generateSignature(MAC, secret, hash_method):

message = MAC + current_timestamp()

signature = apply_hash(message, secret, hash_method)

return signature

// CLIENT SIDE–MOBILE ROBOT

Function robot_send_signature():

local_MAC = get_MAC_address()

hash_method = “HMAC-SHA256”

secret = get_local_secret()

signature = generateSignature(local_MAC, secret, hash_method)

send_to_server(local_MAC, signature)

// SERVER SIDE–VALIDATION AND REGISTRATION

Function server_receive(MAC, signature):

If MAC not in MAC_ROBOTS_DB:

return “Unknown MAC–access denied”

expected_secret = get_secret_from_database(MAC)

expected_signature = generateSignature(MAC, expected_secret, “HMAC-SHA256”)

If signature == expected_signature:

register_client(MAC_ROBOTS_DB[MAC])

return “Authentication successful–robot registered”

Else:

return “Invalid signature–access denied”

return “Unknown MAC–access denied”

The communication strategy among the network components is based on the use of secure protocols and is detailed in Section 2.4.

2.4. Communication Strategy

This network utilizes two secure communication protocols to connect all its components. For communication between browser-based clients and the server, the WebSocket Secure (WSS) protocol is used, while mobile robot clients communicate with the server via the WebSocket (WS) protocol. Figure 5 illustrates the communication flow using these technologies.

Bidirectional communication refers to the ability of all network members to initiate HTTP/S requests and exchange data whenever necessary. Data encryption is achieved through the use of a secure communication tunnel based on the Transport Layer Security (TLS) methodology. This approach significantly mitigates the risk of man-in-the-middle attacks, which involve data interception during transmission to a third-party entity.

The standard port used for WSS connections is 443 on Windows-based machines and 8443 on Linux-based machines. Section 2.5 provides a detailed explanation of the network’s security protocol implementation.

2.5. Security Protocols and Strategy

Data security and encryption are critical aspects when transferring information to and from the network. Therefore, multiple security protocols are employed to ensure the protection and encryption of the robotic network.

In designing the system’s security architecture, cryptographic parameters were carefully selected to balance robust protection with computational efficiency, considering the resource constraints of mobile robotic clients. For TLS/SSL communications, standard asymmetric key sizes of 2048-bit RSA or equivalent elliptic curve keys (e.g., P-256) are employed, providing strong resistance against brute force attacks without compromising system performance.

For message authentication and data integrity verification, the SHA-256 hashing algorithm is utilized, offering high collision resistance and broad support across cryptographic libraries while maintaining moderate resource consumption suitable for embedded robotic platforms. Certificate management for TLS is handled via a centralized system overseeing issuance, renewal, and revocation of X.509 certificates, thereby ensuring endpoint authenticity and mitigating man-in-the-middle attacks.

In the custom hash-based authentication mechanism, robotic devices are provisioned with pre-shared symmetric keys, avoiding the complexity of certificate management on resource-limited embedded systems. This approach simplifies the authentication workflow and reduces cryptographic overhead on the client side, enabling efficient and robust implementation in industrial and field environments.

2.5.1. Communication Protocol Between the Server and Browser-Based Clients

To establish a secure connection between the server and browser-based clients, the WSS communication protocol is used. WSS is a real-time, bidirectional communication protocol between a server and client that transmits data through a secure tunnel based on the Transport Layer Security (TLS) protocol.

The designated port for WSS connections is 443, as the server is hosted on a Windows-based machine. Data encryption and client authentication are secured using digital certificates signed by a trusted certificate authority (CA).

To limit and protect network traffic, browser clients are required to verify their identity before logging into the server using valid credentials. This identity verification is performed using Secure Socket Layer (SSL) security certificates, which are designed to secure communication via the TLS protocol.

2.5.2. Communication Protocol Between the Server and Mobile Robot Clients

To establish communication between the server and mobile robot clients, the WS (WebSocket) protocol is used. This is a real-time, bidirectional communication protocol between a server and a client. Unlike WSS, WS operates through an unsecured channel.

In order for mobile robots to successfully connect and verify their identity, each robot transmits a digital signature to the server for authentication. This digital signature is encrypted and includes the device’s MAC address. The encryption process involves encoding the signature using a hash function implemented via the Base64.h library. The signature is generated from a String package composed of the MAC address and a secret key, which is then hashed to produce the final signature.

The server’s internal database contains the same hash function and the MAC addresses of all eligible robots authorized to connect. If the signature generated by the client matches the one stored and computed by the server, the client is granted access and is marked as “Connected”.

All data exchanged between the server and this category of clients is encrypted using the same hash-based method and decrypted upon arrival. As a result, intercepted data may be captured, but remains unreadable without knowledge of the specific hash function used for decryption.

The system’s security model emphasizes low latency authentication and minimal computational overhead, as opposed to the complex, layered cryptographic frameworks typically used in large-scale IIoT infrastructures. Instead of relying on full TLS handshake cycles or certificate-based authentication schemes, which may introduce significant delay and require persistent secure sessions, the proposed architecture implements a stateless, hash-signature validation mechanism that is deterministic and lightweight.

Each robot uses its MAC address and a pre-shared secret to generate a Base64-encoded hash signature, which is then verified on the server side in a single computational step. This process avoids multi-step negotiations and reduces both processing time and memory requirements on the robotic clients, making the solution especially suitable for resource-constrained or embedded mobile robots operating in dynamic environments.

By eliminating the need for mutual certificate verification or session-based encryption, the system achieves fast and repeatable authentication cycles, allowing for real-time responsiveness in command and control operations. This trade-off prioritizes speed and deterministic behavior while still ensuring that every request is cryptographically validated and linked to a unique hardware identity. Although formal cryptographic benchmarking (e.g., encryption time, attack simulations) has not yet been performed, initial latency measurements during multi-client interactions remained under 50 ms, confirming the practical efficiency of the approach within the scope of the current deployment.

2.5.3. Communication Protocol Between the Server and the RDBMS

The robotic network uses a relational database management system (RDBMS) for data storage and archiving. To ensure secure communication between the server and the RDBMS, the WSS protocol with TLS encryption is employed. For server authentication with the PostgreSQL database, digital certificates signed by a certificate authority (CA) are used, similar to the browser client authentication mechanism.

To validate the SSL connection within PostgreSQL, a query is executed on the pg_stat_ssl table, as shown in Figure 6. This communication protocol is designed to enable the encrypted transmission of data from the robotic network server to the RDBMS for secure storage and archiving.

2.6. Web Platform

The Web Platform of the robotic network consists of a set of web pages developed using HTML, CSS, and JavaScript technologies. Its primary purpose is to display data and enable the control of mobile robots.

The Web Platform is composed of five main web pages:

• Authentication page;
• Dashboard (main page);
• 3 manual control pages for robot movement (for each mobile robot).

The Web Platform connects to the server via WSS on port 443. A WSS connection is therefore established to send and receive data from the server.

2.6.1. Web Platform’s Authentication Page

The login page of the Web Platform is always the first interface displayed when accessing any of the web pages (e.g., through a direct route link). The Web Platform’s security is designed so that any user attempting to access a route without prior authentication is automatically redirected to the login page.

This page features a minimalist design that includes two input fields for username and password and a login button, as illustrated in Figure 7.

2.6.2. Web Platform’s Dashboard Page

The main page of the Web Platform serves as the central interface for accessing all network functionalities. It includes a real-time monitoring section for mobile robots, receiving data from the server such as sensor values and location, as shown in Figure 8. Additionally, the robot’s position can be tracked on integrated maps using the Leaflet API. At the bottom of each section, users can access the manual control page, which provides movement control functions for the mobile robot.

2.6.3. Web Platform’s Manual Movement Control Page for Robots

The manual control page for mobile robots, shown in Figure 9, is accessible from the main Web Platform interface. Its purpose is to allow the transmission of manual movement commands to mobile robots operating in the field. This functionality was developed to be used in scenarios where a mobile robot becomes stuck or encounters a situation that cannot be resolved autonomously.

For the testing phase, the control of two DC motors via a dual H-bridge was implemented for the mobile robot with ID Robot_1. Four control methods were developed for managing the motors, as illustrated in Figure 10, where robot IDs were used for their identification.

• move_forward();
• move_backward();
• turn_left();
• turn_right();
• stop();

These commands are also transmitted from the Web Platform through the secure TLS port 443 using a WSS socket toward the field units. The next development stage involves enhancing the manual control pages of the mobile robots by integrating real-time video feed sections for field monitoring.

2.7. Data Storage and Archival

An essential functionality of such a control system is the storage and archiving of data within a database management system (DBMS). For the robotic network, a relational database management system (RDBMS) was selected, as it allows data to be stored in structured tables. The chosen RDBMS is PostgreSQL, a widely used and reliable database management system. Figure 11 illustrates the database configuration designed to store the values received from mobile robots operating in the field.

Connecting to and storing data in a database contributes to building a historical record of the robotic network. Database systems offer high data availability, allowing secure access to stored information through appropriate security protocols. This enables the creation of operational scenarios, data comparisons, and strategic planning based on historical data analysis. Additionally, storing data outside the memory of mobile robot microcontrollers enhances network security by preventing potential information leakage.

All these functionalities contribute to a complete and secure data communication system, both within and outside the robotic network. Based on this infrastructure, control scenarios for mobile robots can be developed using algorithmic approaches.

Section 3 extends the functionality of the robotic network into the demilitarized zone (DMZ) by proposing the development of a read-only application. This application receives read-only data from the OT domain, where the command center and the network server are located, and is intended for users who interpret data and perform analytical tasks based on it. These users are not granted control over the network; they are only permitted to view specific functional components.

2.8. Preliminary Testing and Analysis of Security Mechanisms

To preliminarily assess the robustness of the proposed secure communication framework for mobile robotic networks, a dedicated test suite was implemented targeting key threat vectors identified in the system architecture. The evaluation focused on both server-side and client-side resilience, with particular emphasis on TLS-based confidentiality, hash-based authentication, and integrity validation of messages transmitted by mobile robotic units.

Seven tests were designed to simulate realistic adversarial scenarios, including certificate spoofing, message tampering, replay attacks, and client impersonation. The tests also covered attack surfaces exposed through the Web Platform interface, such as the potential for cross-site scripting (XSS).

The outcomes confirmed that the system correctly enforces certificate validation during TLS handshakes, detects and rejects stale or tampered messages based on timestamp and HMAC verification, and effectively blocks unauthorized clients using incorrect cryptographic keys. However, two vulnerabilities were observed during testing: (1) the TLS client implementation failed to reject connections mediated by a man-in-the-middle proxy using a self-signed certificate, and (2) insufficient input sanitization was noted in the Web Platform, leading to a potential risk of script injection.

These preliminary tests demonstrate the framework’s effectiveness in enforcing baseline security properties’ confidentiality, integrity, and authentication, while also revealing specific areas for future hardening. As part of ongoing work, advanced countermeasures such as mutual TLS authentication, dynamic key rotation, and context-aware intrusion detection are planned to be integrated and tested under more rigorous and adversarial conditions.

• Test 1: TLS Handshake with Valid Certificate (Passed).

To verify that the system correctly accepts secure TLS connections, a test was performed using a valid certificate signed by a trusted CA. The robot client attempted to initiate a connection over port 443 using OpenSSL. The server’s certificate was validated successfully using: openssl s_client -connect myrobotserver.com:443 -CAfile trusted_ca.crt.

• Test 2: TLS Handshake with Invalid Certificate (Passed).

This test simulated a client attempting to connect using an untrusted or self-signed certificate. As expected, the handshake failed, indicating that the server properly rejects non-authorized CAs. Used command was: openssl s_client -connect myrobotserver.com:443 -CAfile fake_ca.crt.

• Test 3: Replay Attack on Hash Signature (Passed).

To simulate a replay attack, a previously valid login message signed with an HMAC was resent after its timestamp had expired. The server detected the outdated timestamp and rejected the message. Used script was:

• const crypto = require(“crypto”);
• const sharedSecret = “robotkey123”;
• const staleTimestamp = 1659347881;
• const message = “robot_id:123;timestamp:${staleTimestamp}”;
• const signature = crypto.createHmac(“sha256”, sharedSecret).update(message).digest(“hex”);
• const now = Math.floor(Date.now()/1000);
• if (now - staleTimestamp > 60) {
• console.warn(“Replay attack detected”);

• Test 4: Tampered Hash Payload (Passed).

An attacker modified the original message after signing, causing a signature mismatch. The system correctly flagged the message as invalid. Used script was:

• const message = “robot_id:123;timestamp:1700000000”;
• const sig = crypto.createHmac(“sha256”, “robotkey123”).update(message).digest(“hex”);
• const tampered = “robot_id:999;timestamp:1700000000”;
• const verify = (msg, sig, secret) => {
• const expected = crypto.createHmac(“sha256”, secret).update(msg).digest(“hex”);
• return expected === sig;
• };
• if (!verify(tampered, sig, “robotkey123”)) {
• console.log(“Tampering detected: signature mismatch”);}

• Test 5: Man in the Middle Proxy Intercept (Failed).

A man in the middle attack was simulated using mitmproxy to intercept TLS traffic. The client accepted the proxy’s self-signed certificate, which indicates that certificate pinning or strict CA validation was not enforced on the robot client. Command used was: mitmproxy --mode transparent --listen-port 443.

• Test 6: Unauthorized Robot with Wrong Shared Secret (Passed).

A robot using an incorrect HMAC secret key attempted to log in. The signature did not match, and the server correctly rejected the request. Used script was:

• const wrongSecret = “invalidkey”;
• const message = “robot_id:123;timestamp:1700000000”;
• const signature = crypto.createHmac(“sha256”, wrongSecret).update(message).digest(“hex”);
• const verify = (msg, sig, secret) => {
• const expected = crypto.createHmac(“sha256”, secret).update(msg).digest(“hex”);
• return expected === sig;
• };
• if (!verify(message, signature, “robotkey123”)) {
• console.log(“Unauthorized robot rejected”);}

• Test 7: Web Platform XSS Payload in Session (Failed).

A JavaScript payload was injected via a simulated form input to evaluate the sanitization mechanisms on the Web Platform. The payload was echoed back in a non-escaped format, demonstrating a potential XSS vulnerability. Used script was:

• const maliciousInput = “<script>alert(‘XSS’)</script>”;
• const sanitized = maliciousInput.replace(/</g, “&lt; ”).replace(/>/g, “&gt; ”);
• console.log(“Sanitized output: ”, sanitized);

The results of the preliminary security validation demonstrate that the proposed framework provides a solid baseline for secure communication between mobile robotic agents and the central command infrastructure. Out of the seven test cases designed to evaluate the system’s resilience against realistic threat scenarios, five passed successfully, indicating the correct enforcement of key principles such as confidentiality, integrity, and authentication. However, two critical vulnerabilities were identified:

The acceptance of a self-signed certificate during a TLS handshake indicates insufficient client-side verification and exposes the system to man-in-the-middle attacks. This highlights the need for certificate pinning or strict CA trust enforcement in resource-constrained robotic clients.

The Web Platform failed to sanitize injected script content, exposing the front-end interface to cross-site scripting (XSS) threats. Although this does not directly compromise robotic control, it opens the attack surface to session hacking and user-side exploits.

These findings confirm that while the core mechanisms of encrypted communication and signed authentication are functional, additional hardening is required at both the client and interface levels. Future work will incorporate mutual TLS (mTLS), nonce-based freshness tokens, and input validation libraries to close the identified gaps and enhance overall system robustness.

3. Development of Read-Only Applications Within the DMZ Domain

Read-only applications are implemented within the demilitarized zone (DMZ) of the internet to allow the retrieval of specific data from the robotic network. Securing this domain involves enforcing firewall rules that permit data flow in only one direction, from the OT domain to the DMZ. For the development of this application, firewall rules will be defined to reject unauthorized HTTP/S requests and to secure the communication tunnel using the TLS protocol, with certificates signed by a trusted CA. Figure 12 illustrates the data flow mechanism by defining the unidirectional communication path between the OT and DMZ domains.

This application is hosted on an application server and consists of a single page that displays only the data permitted for visualization by DMZ users, as shown in Figure 13. The read-only application page is similar to the main page of the Web Platform in the OT domain, except it does not include any network control functionalities.

It is important to note that this application is visible only when the network server within the OT domain is operational.

4. Results of the Robotic Network Development

The development of the robotic network across the OT and DMZ domains, with connections extending into the IT domain, provided significant insights into the core principles of integration, security, and encryption for networks involving mobile robots in emergency response scenarios. As a result, the main achievements of this paper are as follows:

• Implementation of a command and control center within the OT domain, designed for the development of the robotic network server using AWS EC2, as shown in Figure 14;

The current deployment consists of a centralized server hosted on a dedicated AWS EC2 virtual machine, acting as the secure endpoint for mobile robotic clients operating in the field. These clients connect remotely to transmit hashed authentication data and signed telemetry over an encrypted channel. The communication protocol is lightweight and stateless, allowing each interaction to be processed independently, without persistent sessions.

This architectural choice ensures baseline scalability, as multiple robotic units can establish secure connections to the same server without impacting each other. The use of short-lived transactions and minimal payload sizes supports efficient resource allocation on the server side, even in the presence of concurrent requests.

From a communication standpoint, the system employs deterministic signature-based validation rather than TLS handshakes, reducing latency and computational overhead. Since the messages are transmitted on demand and follow a predefined structure, bandwidth usage remains predictable and controlled, even as the number of connected clients increases.

The server handles incoming messages using asynchronous processing and hash verification routines, which allow it to respond in near real time while maintaining low CPU and memory consumption. This setup was validated under conditions involving multiple simultaneous robotic clients connecting from distinct IP addresses and transmitting telemetry without delays or congestion.

In practical tests involving three concurrent robotic clients, the system achieved a 95% authentication success rate, with average response times below 50 ms. While limited in scope, these results confirm the system’s responsiveness and indicate a moderate level of scalability suitable for controlled deployments or edge-based industrial applications.

2.

Development of the network server functionalities through the implementation of asynchronous code and the use of functions that orchestrate data flow;

3.

Definition of the robotic network clients and their classification into two categories: mobile robots and browsers running the Web Platform application;

4.

Creation of authentication and registration methods for network clients using TLS, SSL, and hash sign protocols, as illustrated in Figure 15;

Below, presented in

Table 2. Structured authentication analysis, hash sign-based handshake.

Metric	Value
Total authentication attempts	20
Successful authentications	19
Authentication success rate	95%
Failure cause	One signature exceeded server timeout
Packet loss observed	~2% (estimated at network layer)
Authentication method	Hash-based challenge with Base64 signature
Signature verification	Deterministic match (raw hash + secret key)
Communication channel	Encrypted TCP (application-level protocol)
Average response latency	~42 ms
Server side storage (auth logging)	Enabled (signed logs + timestamps)

, are the extracted performance indicators of the network:

During one of the attempts, the robot’s signature was correctly generated but arrived at the server after the expected timeout window, leading to rejection. This was attributed to temporary latency fluctuation in the test environment. All other requests were successfully authenticated and logged.

For experimental evaluation, we implemented a simple TCP client server architecture where each robotic message included an incremental message_id. The server monitored incoming messages and logged dropped or duplicated IDs. Out of 20 simulated transmissions, one message did not arrive within the server’s reception window (simulated 5% loss). This approach allowed us to estimate application layer loss independently of TCP-level retransmissions, which were not observed during testing. Figure 16 reflects this evaluation by describing the blueprint of the code for the server and clients.

The results demonstrate the system’s robustness and confirm that the authentication pipeline handles typical communication delays gracefully. Timeout thresholds can be tuned in future work to accommodate varying levels in different deployments.

5.

Network’s data encryption;

6.

Development and use of a Web Platform for data visualization and control of mobile robots; Figure 17 shows a portion of the Web Platform’s log, which receives, sends, and processes HTTP/S requests from network clients;

Additionally, Figure 18 presents the log of the mobile robot with ID Robot_1, which successfully receives and sends requests to and from the network server.

Each control command issued by the server triggers a corresponding execution confirmation message from the robot, enabling the server to compute a real-time success rate for command delivery and execution. This bidirectional communication ensures that every action is explicitly acknowledged, allowing the system to track motion reliability and detect delays or failures in control transmission. A set of predefined test commands was issued by the server through Web Platform and executed by the robot in the expected order and timing. Each command was followed by an acknowledgment response, and the system confirmed task completion with no detected deviations or delays. This confirms that command–response synchronization was respected and that motion execution accuracy remained within acceptable thresholds.

7.

Development of a web-based read-only application within the DMZ domain, designed for visualizing specific network data and enabling unidirectional communication from OT to DMZ;

8.

Preparation of a command and control infrastructure as a foundation for developing scenarios aimed at optimizing emergency response situations;

These functionalities require further extension in the area of redundancy for both the command and control center and the RDBMS in order to ensure high data availability in case of an online server connection failure.

5. System Limitations

The proposed communication and authentication framework for mobile robotic networks demonstrates promising results regarding security, latency, and operational efficiency within constrained industrial environments. However, several limitations currently restrict its broader applicability and require further investigation.

While initial testing has involved three concurrent robotic clients with preliminary latency and authentication success rate measurements, these experiments represent early-stage efforts and are insufficient to fully characterize the system’s scalability and resilience under real-world conditions.

The custom hash signature authentication mechanism, although efficient, has yet to undergo comprehensive formal security analysis or extensive attack resistance testing, such as protection against replay or side-channel attacks.

Additionally, comparative benchmarking against established industrial IoT security frameworks remains an area for future work, as such analysis would better position the proposed system’s advantages and limitations.

To mitigate these challenges, future work will focus on expanding the scale and scope of testing, including stress tests with larger numbers of robotic clients and deployment in realistic network environments. Incorporating formal security validation techniques and a detailed comparative performance analysis will further enhance the system’s credibility.

Extending test scenarios with concrete, quantitative measurements were initiated, including a detailed analysis of packet loss and authentication success rates. Our preliminary results indicate a packet loss rate of approximately 2%, while the authentication success rate reached 95%. The latter was affected primarily by timeout events during delayed message delivery. Further development of telemetry-based verification of robotic control accuracy and task completion rates will enrich the performance evaluation and provide a more comprehensive understanding of system robustness.

To enhance system reliability and mitigate the risks associated with the absence of backup mechanisms, future development will focus on partitioning the infrastructure into distinct subdomains featuring redundancy for both servers and databases. By deploying multiple redundant server instances across segregated subdomains, the architecture can ensure high availability and fault tolerance, preventing single points of failure in the robotic network’s communication and control layers.

Similarly, implementing database replication and clustering strategies will safeguard data integrity and continuity, enabling seamless failover in the case of hardware or software faults. This multi-tier redundancy approach will improve system robustness and operational resilience, particularly important in mission-critical environments such as emergency response and industrial automation.

These strategies and their potential integration into the current system architecture are discussed in detail in the Future Work section, providing a roadmap for scalable and secure deployment.

These ongoing efforts aim to provide a more rigorous validation framework supporting the reliable and secure deployment of the proposed architecture in industrial and emergency operation contexts.

6. Future Research, Development, and Deployment

These intelligent systems are developed progressively and follow continuous integration (CI) and continuous delivery (CD) processes, ensuring long-term usability in operational environments.

In the same context, the robotic network will undergo continuous development, optimization, and integration through the addition of new functionalities and the improvement of existing ones. Therefore, the authors propose several directions for future research and development.

The first and most important proposed direction for research and development is the implementation of a failover system within the network. This process involves introducing redundancy for the command center, the server, and the RDBMS of the robotic network. Figure 19 illustrates a schematic of the failover strategy with two levels of redundancy by defining two sites: the Primary Site (CC) and the Backup Site (BCC).

This creates two levels of redundancy for the command center and the robotic network server. The failover process is instantiated when the online server enters a failure state and a backup server takes over control of the network in real time. Additionally, when the primary site enters a failure state, the backup site automatically assumes control.

The second research direction focuses on the redundancy (also with two levels) of the database system. The authors propose a DBMS redundancy solution by utilizing a NoSQL Cassandra system. This technology provides increased data availability in a horizontal direction in the event that the online node enters a failure state. Figure 20 illustrates the connection and configuration of the data centers.

The database redundancy principle is based on the formation of a ring system with four data centers, which are continuously updated in real time. In the event of a failure in the online DBMS, the backup DBMS will control, provide, and archive the robotic network data.

Additionally, this network has been developed to integrate mobile robots within it, making the third area of further research and development the simulation of these robots in a virtual environment. This includes the creation of scenarios, hypotheses, and conclusions regarding the behavior of all network elements in special emergency situations. One possible approach is the use of the ROS2 robotics operating system [16] and the Gazebo physics simulation environment. ROS2 is capable of running web microservices [17], making the integration of the ROS2 environment with the robotic network seamless.

After dynamic simulation with ROS2 and Gazebo [18], the next step is to build physical mobile robots to test their locomotion capabilities [19]. These technologies are compatible with Arduino microcontrollers, enabling the development of control applications for mobile robots within the network [20].

All these proposed research and development directions are seen by the authors as key points in generating an intelligent and optimized system for the semi-autonomous management of special emergency situations.

7. Conclusions

In conclusion, robotic networks provide significant advantages in emergency response solutions by developing a collaborative team model. Swarm networks offer modularity through the use of identical mobile robots, while networked systems enable exploration of diverse environments through the use of both terrestrial and aerial mobile robots.

This paper has developed an infrastructure model for robotic networks by securing data within the OT domain, with the possibility of creating read-only applications in the DMZ domain.

The concept behind the development of such a network is based on research into emergency response solutions, following the trends in the operation, control, and integration of mobile robots within networks. The aim of this paper is to expand the use of robotic networks by implementing security elements, data storage, and archiving, placing the command and control center within the OT domain of the Internet. Additionally, a Web Platform is provided, enabling users to interact graphically with the network functions, while a web-based read-only application is proposed for use within the DMZ domain of the Internet.

Finally, future research and development directions are proposed that focus on the implementation of redundancy within the robotic network for both the command center and its DBMS.

This paper contributes valuable insights into the enhancement of network architectures integrating mobile robots, particularly in critical contexts. Methods are proposed for enabling effective collaboration between these robots to respond quickly to emergency situations. Emphasis is placed on improving communication, control, and reaction capabilities in unpredictable scenarios. The presented solutions aim to reduce intervention time and increase system reliability, thus providing a modern and practical approach to the autonomous management of emergency situations.