Co-Simulation and Runtime Verification of Micro-ROS Communication Mechanisms

1. Introduction

The Robot Operating System(ROS) [1] has become the most widely used middleware for the development of robotic software systems. Its safety and reliability are critical to ensuring the robustness of robotic systems. in ROS-based robotic applications, Micro-ROS serves to bridge the performance gap between resource-constrained microcontrollers and powerful computing devices [2,3]. ROS encompasses communication mechanisms, software toolkits, high-level robotic capabilities, and a comprehensive ecosystem. It is extensively applied in the research and development of autonomous robots, unmanned aerial vehicles [4], and intelligent vehicles [5,6], establishing it as a meta-operating system in robotic system development.

Micro-ROS employs XRCE-DDS (eXtremely Resource Constrained Environments DDS) as its core communication middleware in resource-constrained embedded devices. This design aims to adapt the powerful data distribution capabilities of DDS to low-power, limited-memory environments such as microcontrollers (MCUs). This design enables small devices such as microcontrollers to seamlessly integrate into the extensive DDS ecosystem without needing to run a full DDS stack, facilitating real-time and reliable data exchange with more powerful computing nodes (e.g., servers, robot main control computers, etc.).

XRCE-DDS is a client-agent-based standard that enables small, resource-constrained embedded devices to connect to the DDS global data space. The modeling, implementation and analysis of XRCE-DDS applications in distributed multiprocessor real-time embedded systems are key research focuses. Among these, XRCE-DDS utilizes an XML-based data description language to define the format and content of data exchange. Through modeling and implementation, researchers investigate approaches to guaranty real-time data transmission and processing in distributed environments.

The safety of XRCE-DDS is crucial to the Micro-ROS communication mechanism. To construct highly trustworthy Micro-ROS communication based on XRCE-DDS, formal methods are applied to model and verify data exchange in Micro-ROS.

Tools such as temporal logic and process algebra can be used to establish precise mathematical models for core interactions in XRCE-DDS, including client-agent handshakes, message sequences, and state machines. This approach rigorously proves that the protocol is free from deadlocks and livelocks under ideal conditions, satisfies critical safety properties, and eliminates logical flaws at the design stage. Safety policies, such as agent access control lists and topic permission mappings, can be defined using formal languages to enable automated verification of policy consistency and completeness.

The reliability of the XRCE-DDS architecture design has been significantly improved through the application of formal methods. When applied to high-safety fields such as autonomous driving and medical devices, this approach will effectively enhance the safety and operational reliability of these devices.

This paper focuses on the Micro-ROS communication mechanism, employing a combined approach of simulation and formal methods to explore the safety and reliability of XRCE-DDS. Timed automata are introduced for formal modeling, while constrained signal temporal logic is used to characterize the key properties of XRCE-DDS. The model is implemented in Simulink/Stateflow, and its effectiveness is evaluated through simulations. Furthermore, runtime verification is performed using the Logical and Temporal Assessments tool in Simulink Test’s Test Manager to validate critical properties.

The contributions of this paper are mainly reflected in three key aspects.

1.

This study treats the Micro-ROS communication middleware, specifically Micro XRCE-DDS, as a time-critical system and builds abstract modeling. Based on the open-source code of XRCE-DDS, timed automata models are built, including parallel of the client_publisher, client_subscriber, Agent, proxy_publisher, and proxy_subscriber modules.

2.

A constrained signal temporal logic, denoted as ${\mathtt{STL}}_{\mathrm{lb}=0}$, is proposed to describe the properties of the Micro-ROS communication mechanism. Key properties are formally specified by the constrained signal temporal logic. Based on an analysis of the XRCE-DDS protocol, critical properties are extracted from natural language descriptions and subsequently converted into logical formulas.

3.

This paper proposes a co-simulation and runtime verification framework based on models for Micro-ROS. The framework is implemented in Simulink/Stateflow, where simulations are conducted and runtime verification is performed to validate critical system properties.

The remainder of this paper is organized as follows. Section 2 provides background and related work; Section 3 presents the overall design architecture; Section 4 introduces the formal modeling of Micro-ROS; Section 5 extracts key properties from the XRCE-DDS protocol and describes them using the constrained signal temporal logic ${\mathtt{STL}}_{\mathrm{lb}=0}$; Section 6 details the model implementation and simulation in Simulink/Stateflow, as well as runtime verification. Finally, the conclusion and future work are summarized.

2. Related Work

Micro-ROS substantially bridges the performance gap between resource-constrained microcontrollers and powerful computing devices. As a lightweight and efficient solution designed for resource-constrained systems, Micro-ROS offers broad application prospects across various domains. To address real-time performance challenges in Micro-ROS, a priority-driven chain-aware scheduling system (PoDS) [2] based on the existing Micro-ROS architecture has been proposed, along with a novel executor, TIDE [7]. Both approaches aim to enhance the temporal predictability and runtime efficiency of Micro-ROS. Furthermore, by leveraging the functionalities of both ROS 2 and Micro-ROS, an experimental platform for developing attitude control algorithms [8] has been implemented. This platform enables the evaluation of response times, message loss rates, and message periodicity of ROS 2 entities under diverse network usage scenarios.

[9] presents a simplified integration approach for combining PXROS-HR with Micro-ROS for real-world applications. The implementation streamlines the integration process by leveraging UART communication and eliminating external dependencies. The transition from a packet-oriented to a stream-oriented custom transport enhances system consistency.

Based on assumptions regarding the ROS API and ecosystem [10], behavioral models of ROS-based systems are inferred through static analysis. This approach relies on behavioral patterns where developers utilize the ROS framework API to implement reactive, periodic, and state-dependent behaviors.

The open-source ROS platform is widely used for rapidly reconfigurable robot units, enabling the development of high-level task programming. This development method is independent of hardware and software, employing virtualized machine control interfaces [11].

[12] proposes a bare-metal implementation of the XRCE-DDS standard on the CompSOC platform based on a multi-processor system-on-Chip (MPSoC) for the Micro-ROS communication mechanism. The framework includes a hosted XRCE-DDS client and a hosted XRCE-DDS agent. To capture the dynamics of system behavior, a Scenario-Aware Data Flow (SADF) model is introduced. This model characterizes the system’s behavior under various execution scenarios.

To accurately describe the latency of reliable DDS data transmission in ROS 2, [13] derives a closed-form analytical model. This model takes into account key parameters including the packet delivery ratio, data period, and heartbeat period in DDS. Guidelines are offered to optimize the data period and the heartbeat period to latency.

In the analysis of ROS 2 security policies, [14] designed and implemented a tool called LiSA4ROS 2. This tool automatically extracts the ROS 2 computation graph through static analysis. Developers use the graph to derive minimal correct configurations for ROS 2 security policies, thereby reducing the likelihood of errors.

Research on verification techniques for ROS systems has become increasingly active. Runtime verification has been applied to ROS systems to ensure that they satisfy predefined properties and specifications during execution. Runtime verification is commonly used to validate hierarchical properties in robotic clusters. With the release and adoption of ROS 2 and Micro-ROS, researchers are increasingly focusing on verifying their safety aspects, such as communication mechanisms and data distribution services.

[15] introduces the TeSSLa-ROS-Bridge (TRB), which enables interaction with ROS-based robotic systems via the temporal stream-based specification language TeSSLa. Using TRB, the resulting monitor runs in parallel with the actual robot code and ensures the given safety conditions. [16] proposes a runtime verification method called Robot Monitor on Multilayer (RMoM). RMoM integrates resources, communications, robots, and cluster properties into a systematic hierarchical monitoring framework to detect violations of specified temporal properties during robotic cluster operations.

[17] proposes a state machine-based notation called RoboChart. RoboTool, designed specifically for RoboChart, supports mathematical modeling of controllers and can automatically generate executable code. A robotic case study involving an exploration task demonstrates the application of RoboChart and its associated tools.

To ensure the safety and reliability of ROS, many researchers have employed formal methods in their studies. [18] focuses on the abstraction, modeling, and automated verification of DDS in ROS 2. By constructing a distributed model in PRISM and configuring interface parameters, properties such as safety and liveness are verified for DDS in ROS 2. [19] proposes an automatic static verification technique for system-level safety properties in ROS-based applications. [20,21] utilize model-driven engineering to simplify the formal verification of ROS 2 applications. Their approach generates traces from ROS 2 execution logs, models ROS 2 using UPPAAL, and employs model checking to verify system properties. While these studies all focus on verifying ROS, they approach it from different perspectives. [18] primarily addresses DDS verification; [19] introduces a static automated verification technique; and [20,21] propose a model-driven engineering verification approach.

Based on the preceding analysis, formal methods for the XRCE-DDS communication mechanism in Micro-ROS have rarely been studied. This paper focuses on the XRCE-DDS communication mechanism by investigating its formal modeling, simulation, and verification.

3. Framework of Micro-ROS Modeling and Analysis

3.1. Micro XRCE-DDS Communication Mechanism

Micro-ROS is a lightweight robot operating system optimized based on ROS 2. It integrates resource-constrained embedded device nodes into ROS 2 DDS and enables communication with these devices through the tailored Micro XRCE-DDS middleware [22]. The architecture of the Micro XRCE-DDS communication mechanism is illustrated in Figure 1 [23].

Micro XRCE-DDS is a protocol based on a client-server architecture that enables communication between resource-constrained embedded devices and DDS. It consists of servers (XRCE Agents) and clients (XRCE Clients). The XRCE Agent acts as an intermediary between the XRCE Client and the DDS global data space, serving as a bridge between embedded devices and DDS. Each XRCE Client on the embedded device side connects to the DDS domain through the XRCE Agent. The XRCE Agent represents the XRCE Client and interacts as a peer with other entities in the DDS domain.

Micro XRCE-DDS is designed with transport protocol independence. It ensures reliable communication while remaining agnostic to the underlying transport protocol, thereby decoupling its functionality from specific transport layer implementations.

3.2. Time Automata

Real-time performance is a critical characteristic of embedded devices. We employ timed automata to model real-time behavior. Timed automata are effective for modeling systems with timed characteristics. A timed automaton comprises a finite set of time variables called clocks. Clocks differ from ordinary variables due to restricted access, which implicitly increments as time progresses. Clocks have only two operation: read and reset. All clocks advance at a uniform rate. After the d time units have elapsed, each clock’s value increases by d. Thus, a clock’s value represents the time elapsed since its last reset.

Definition 1 $Clock$ $Constraint$ Clock constraints are primarily used to restrict possible time expenditures. They are defined as follows:

$$\begin{array}{cc}\hfill tc& ::=x<c\mid x>c\mid x\le c\mid x\ge c\mid tc\wedge t{c}^{\prime }\hfill \end{array}$$

where, c is a natural number.

C denotes a finite set of clock variables, where any variable x in C is a clock variable. Additionally, $CC\left(C\right)$ represents the set of clock constraints defined over the clock set C.

Definition 2 $timed$ $automata$ A timed automata $TA$ is a tuple:

$$\mathrm{TA}=(\mathrm{Loc},{\mathrm{Loc}}_0,\mathrm{Act},C,\mathrm{Inv},\mapsto )$$

Where

• $Loc$: is the set of locations.
• $Lo{c}_0\subseteq Loc$ is the initial location set.
• $Act$ is a finite set of actions or events. Here, actions are divided into two types: general actions and communication actions. Specifically: $c!msg$ denotes sending a message $msg$ through channel c; $c?msg$ denotes receiving a message via channel c and storing it in the variable $msg$.
• C is the finite set of clocks.
• $inv$: $Loc\to CC\left(C\right)$ is the Invariant Function.
• $\mapsto \subseteq Loc\times Cond\left(C\right)\times Act\times Loc$ is the set of transition relation.

The transition relation is denoted by a quadruple $(l,g,a,l^{\prime })$, where $g\in Cond\left(C\right)$ is a clock constraint with $Cond\left(C\right)\subseteq CC\left(C\right)$, and a is an action. $(l,g,a,l^{\prime })\in \mapsto$ indicates that when g is satisfied, a transition occurs from location l to $l^{\prime }$, and the action a is executed during this transition. The function $inv\left(\right)$ assigns an invariant to each location,, representing the time constraint for remaining there. The clock invariant $inv\left(\right)$ must be satisfied while the system is at that location. If this invariant is violated, the system must leave the current location.

3.3. Framework of the Micro-ROS

The framework for formal modeling and analysis of micro-ROS communication mechanism, XRCE-DDS, is illustrated in Figure 2. For XRCE-DDS, timed automata are employed to abstract and construct models of the XRCE-DDS Agent and Client from open-source code. Key properties of the XRCE-DDS specification are extracted and specified using Constrained Signal Temporal Logic. The model is implemented and simulated in Simulink. Subsequently, runtime verification of key properties is performed using Simulink’s verification toolkit. Through simulation and verification, a model of XRCE-DDS extracted from the code is satisfied with the specification.

4. Formal Modeling the Micro-ROS

Micro XRCE-DDS of the micro-ROS communication mechanism consists of Agents and Clients. Based on the functionalities of these components, the system is modeled as five modules: client_publisher, client_subscriber, Agent, proxy_publisher, and proxy_subscriber modules. The modular architecture is illustrated in Figure 3.

The five modules in the architecture correspond to three types of devices: resource-constrained devices, Agents, and resource-unconstrained devices.

The client_publisher module and client_subscriber module represent two embedded devices operating in resource-constrained environments, such as cameras and alarm systems. These modules correspond to two functional roles of the Micro XRCE-DDS Client. The first acts as a publisher in the Micro XRCE-DDS domain, sending messages to a specified topic within the ROS 2 network. The other acts as a subscriber, receiving messages from topics of interest in the DDS domain.

The proxy_publisher and proxy_subscriber modules represent two non resource unconstrained devices. The proxy_publisher receives messages from the client_publisher, while the client_subscriber receives messages from the proxy_subscriber. In this process, the client_publisher and proxy_publisher form a corresponding client-proxy pair. The client_subscriber and proxy_subscriber form another client-proxy pair. The Agent module is responsible for receiving transmitted messages and performing selective distribution.

4.1. Client_Publisher Model

The client_publisher module comprises four functional components: a reliable input stream, a reliable output stream, a heartbeat reply message stream, and message transmission. These components are modeled using four concurrent timed automata, denoted as $T{A}_{CP\_RIS}$, $T{A}_{CP\_ROS}$, $T{A}_{CP\_HAS}$, and $T{A}_{CP\_FS}$.

The overall timed automaton model of the client_publisher is defined as:

$$T{A}_{CP}=T{A}_{CP\_RIS}\Vert T{A}_{CP\_ROS}\Vert T{A}_{CP\_HAS}\Vert T{A}_{CP\_FS}$$

Only the $T{A}_{CP\_ROS}$ model is provided here. $T{A}_{CP\_ROS}$ models the reliable output stream, and its timed automaton model is as follows:

Definition 3 $T{A}_{CP\_ROS}$ is a tuple:

$$T{A}_{CP\_ROS}=(Lo{c}_{CP\_ROS},Lo{c}_{0CP\_ROS},Ac{t}_{CP\_ROS},C_{CP\_ROS},In{v}_{CP\_ROS},{\mapsto }_{CP\_ROS})$$

Where,

• $Lo{c}_{CP\_ROS}=\{presending,sending\}$.
• $Lo{c}_{0CP\_ROS}=\left\{presending\right\}$.
• $Ac{t}_{CP\_ROS}=\{a\_queue\_msg,c\_balance\}$.
• $C_{CP\_ROS}=\left\{t\right\}$ represents the clock set.
• $in{v}_{CP\_ROS}=\{(presending,t\le 1),(sending,t\le 3)\}$. It is the invariant function in the reliable output stream model.
• ↦ is the set of transition relation in $T{A}_{CP\_ROS}$, shown as Figure 4.

In the action set, $c\_balance$ denotes a reliable channel used to receive responses to messages. $a\_queue\_msg$ is an unreliable message channel with a capacity of 1. Messages transmitted through $a\_queue\_msg$ have a structured format with two parts: DATA and HB. DATA contains the message content, while HB contains heartbeat information.

In this timed automaton model, the location $presending$ indicates preparing to send a message, with the location invariant being $t\le 1$. When the time guard $t>1$ is satisfied, a transition occurs: the message $msg$ is sent via the channel $a\_queue\_msg$, and the clock t is reset. The location transitions from $presending$ to $sending$.

The location $sending$ represents the message sending process. When the time guard $t>3$ is met, the previous message sent successfully and another message is transmitted through the channel $a\_queue\_msg$, and the clock t is reset.

Since $a\_queue\_msg$ is an unreliable channel, message loss may occur during transmission. If a message is received $bmsg$ from the reliable channel $c\_balance$ during 3 time units, a previously sent message was lost and needs to be retransmitted. The location then turns from $sending$ back to $presending$, ready to resend the message.

4.2. Client_Subscriber Model

Similar to the client_publisher, the client_subscriber also consists of four functional components: a reliable input stream, a reliable output stream, a heartbeat reply message stream, and message transmission. However, in terms of message transmission, unlike the client_publisher, it includes not only a sending model but also a receiving model. Therefore, this module consists of five timed automata, labeled $T{A}_{CS\_RIS}$, $T{A}_{CS\_ROS}$, $T{A}_{CS\_HAS}$, $T{A}_{CS\_FS}$, and $T{A}_{CP\_RM}$.

The overall timed automaton model of the $client\_subscriber$ can be expressed as:

$$T{A}_{CS}=T{A}_{CS\_RIS}\Vert T{A}_{CS\_ROS}\Vert T{A}_{CS\_HAS}\Vert T{A}_{CS\_FS}\Vert T{A}_{CS\_MS}$$

Here we provide the definition of $T{A}_{CS\_ROS}$. Since the client_subscriber must account for the device’s sleep characteristics, the $T{A}_{CS\_ROS}$ automaton incorporates this feature by adding a $sleep$ location. The formal model $T{A}_{CS\_ROS}$ is defined as follows.

Definition 4 $T{A}_{CS\_ROS}$ is a five tuple:

$$T{A}_{CS\_ROS}=(Lo{c}_{CS\_ROS},Lo{c}_{0CS\_ROS},Ac{t}_{CS\_ROS},C_{CS\_ROS},In{v}_{CS\_ROS},{\mapsto }_{CS\_ROS})$$

Where,

• $Lo{c}_{Cs\_ROS}=\{init,waitRet,timeout,sleep\}$.
• $Lo{c}_{0CS\_ROS}=\left\{init\right\}$.
• $Ac{t}_{CS\_ROS}=\{a\_set\_push\_sub\_msg,c\_subs\_success,a\_storeInfo,a\_restoreInfo,f\_sub\_finished,leftwaketime\}$.
  The communication actions are $a\_set\_push\_sub\_msg$, $c\_subs\_success$ and $f\_sub\_finished$. $a\_set\_push\_sub\_msg$ is a channel with a certain capacity, capable of facilitating asynchronous communication.
• $C_{CS\_ROS}=\{t_1,t_2\}$ represents the clock set. $t_1$ is the clock used to record awake and sleep durations. $t_2$ tracks whether the sending time has exceeded the timeout threshold.
• $in{v}_{CS\_ROS}=\{(init,t_1\le 100)$, $(waitRet,(t_1\le 100)and(t_2\le 9))$,
  $(timeout,(t_1\le 100)and(t_2\le 10))$, $(sleep,t_1\le 100)\}$.
• ↦ is the set of transition relation in $T{A}_{CS\_ROS}$, shown as Figure 5.

In the location set, $init$ represents the initial location where the reliable output stream begins. $waitRet$ denotes the location where the reliable output stream awaits the return result of the subscription message after sending it. $timeout$ indicates the location reached when the reliable output stream times out while waiting. $sleep$ represents the location where the client_subscriber model enters sleep mode, causing the reliable output stream to cease operation.

In the initial state $init$, it is assumed that the embedded device is awake and the clock $t_1$ is reset. Once the channel $f\_sub\_finished$ receives a message from the proxy subscribe model, which is stored in the variable $fmsg$, and the message is correct, the location transitions to $waitRet$. Additionally, the clock $t_2$ is reset. If the clock $t_2>9$ and $fmsg\ne 0$ at the location $waitRet$, the received message is incorrect and the system changes to the location $timeout$. After remaining in the location $timeout$ for one time unit, the system returns to $init$ to attempt receiving the message again. The proxy subscribe model re-sends this message after the timeout.

An response message is sent through the channel $c\_subs\_success$ to indicate that the message has been received correctly, and the system returns to the initial location $init$.

Assuming that the embedded device has an awake duration of 100 time units and a sleep duration of 50 time units, if the device remains awake in the locations $init$, $waitRet$, or $timeout$ for more than 100 time units, it immediately enters the location $sleep$. The device remains dormant for 50 time units in the location $sleep$. When the device enters the location $sleep$, it stores the current context via the action $a\_storeInfo$. Upon awakening, the context is restored via the action $a\_restoreInfo$.

4.3. Agent Model

In the Micro XRCE-DDS Agent, there is a module responsible for retrieving various types of messages from the network and placing them into a scheduler, which utilizes a multi-level priority queue. Another module reads messages from the queue, distributes them to different ProxyClient objects based on their IDs, and processes them further. Based on these two steps, the Agent model abstracts two functionalities: message reception and message distribution. Message reception acquires incoming messages from the network, while message distribution determines the target agent of a message based on its content and forwards it accordingly. Both message reception and distribution can be modeled using two timed automata: $T{A}_{REV}$ and $T{A}_{DIS}$. The overall Agent module model can be represented as following.

$$T{A}_{AG}=T{A}_{REV}\Vert T{A}_{DIS}$$

In the agent module, the $T{A}_{REV}$ model is defined below.

Definition 5 $T{A}_{REV}$ is a tuple:

$$T{A}_{AG}=(Lo{c}_{REV},Lo{c}_{0REV},Ac{t}_{REV},C_{REV},In{v}_{REV},{\mapsto }_{REV})$$

Where,

• $Lo{c}_{REV}=Lo{c}_{0REV}=\left\{idle\right\}$.
• $Ac{t}_{REV}=\{a\_queue\_msg\}$.
• $C_{REV}=\left\{t\right\}$.
• $in{v}_{REV}=\left\{(idle,t\le 1)\right\}$.
• The transition relation is shown as Figure 6.

In the timed automaton $T{A}_{REV}$ model, when in the $idle$ location and the time guard condition $t>1$ is satisfied, the automaton receives a message from the channel $a\_pop\_push\_msg$, stores it in the variable $msg$, and resets the clock t to wait for the next message reception. The channel $a\_pop\_push\_msg$ has a certain capacity, enabling asynchronous communication. When the Agent module receives a message, it forwards the message to either the proxy_publisher module or the client_subscriber module via $T{A}_{DIV}$, depending on the type of message.

4.4. Proxy_Publisher Model

The proxy_publisher module represents a ProxyClient entity in a Micro XRCE-DDS. The ProxyClient is responsible for receiving data from the client_publisher through the Agent module and forwarding it to the DDS domain.

According to the description of XRCE-DDS in the XRCE-DDS protocol, when the XRCE-DDS Agent acts as a publisher proxy, it receives messages from the client_publisher. The proxy_publisher needs to abstract a timed automaton for the reliable input stream to process data received from the Agent module.

Therefore, the ProxyClient entity is abstracted into timed automata models responsible for the reliable input stream, heartbeat messages, and message transmission. The three timed automata constructed for the proxy_publisher module are $T{A}_{PP\_RIS}$, $T{A}_{PP\_HAS}$, and $T{A}_{PP\_FS}$. The overall timed automaton model for the proxy_publisher module can be expressed as:

$$T{A}_{PP}=T{A}_{PP\_RIS}\Vert T{A}_{PP\_HAS}\Vert T{A}_{PP\_FS}$$

In the proxy_publisher module, $T{A}_{PP\_HAS}$ is the heartbeat response module, and its model is as follows.

Definition 6 $T{A}_{PP\_HAS}$ is a tuple:

$$T{A}_{PP\_HAS}=(Lo{c}_{PP\_HAS},Lo{c}_{0PP\_HAS},Ac{t}_{PP\_HAS},C_{PP\_HAS},In{v}_{PP\_HAS},{\mapsto }_{PP\_HAS})$$

Where,

• $Lo{c}_{PP\_HAS}=\{Rev,MissMsg,CheckSeq\}$.
• $Lo{c}_{0PP\_HAS}=\left\{Rev\right\}$.
• $Ac{t}_{PP\_HAS}=\{ack\_msg,nack\_msg,HB\}$.
• $C_{PP\_HAS}=⌀$.
• $in{v}_{PP\_HAS}=⌀$.
• ↦ is the set of transition relation in $T{A}_{PP\_HAS}$, shown as Figure 7.

In the $Ac{t}_{PP\_HAS}$ set, three channels have been established. One is for heartbeat messages, one for response messages, and another for reporting packet loss. Heartbeat messages are received through the $HB$ channel and packet loss is checked. If no packet loss is detected, a response message is sent through the $ack\_msg$ channel. If packet loss occurs, the relevant information is transmitted via the $nack\_msg$ channel.

$T{A}_{PP\_HAS}$ receives messages through the $HB$ channel, unpacks them, and checks for packet loss. If the sequence number in the heartbeat message is greater than the recorded message number, it indicates that the packet was lost earlier. In this case, a message is sent through the $nack\_msg$ channel to request retransmission. Otherwise, if the message is received, a response is sent through the $ack\_msg$ channel to confirm receipt.

4.5. Proxy_Subscriber Model

The proxy_subscriber module serves as the entity model corresponding to the client_subscriber for the Micro XRCE-DDS Agent. It responds to client_subscriber subscriptions and sends data to the client_subscriber.

As described in the XRCE-DDS protocol, when the XRCE-DDS Agent acts as a proxy for subscribers, it must receive messages from the proxy_subscriber and retransmit them to the client_subscriber. To ensure consistency between sent and received messages, it is necessary to periodically send heartbeat messages and receive response messages. Furthermore, since the XRCE-DDS Client may periodically enter sleep mode, the proxy_subscriber must not send messages once the Client has entered the sleep state.

The proxy_subscriber module utilizes the reliable input stream module $T{A}_{PS\_RIS}$ and the reliable output stream module $T{A}_{PS\_ROS}$ to process incoming and outgoing messages. It also handles heartbeat messages to be sent and processes received response messages, which are modeled using the timed automaton $T{A}_{PS\_HAS}$. The proxy_subscriber sends two types of messages: basic messages requiring reliable transmission and heartbeat messages ensuring reliable delivery. This sub-function also checks whether the client_subscriber module is in a sleep state. The proxy_subscriber can only send messages when the client_subscriber is awake. A timed automaton, $T{A}_{PS\_FSWT}$, is constructed for Periodic Sending. The proxy_subscriber module consists of four timed automata models: $T{A}_{PS\_RIS}$, $T{A}_{PS\_ROS}$, $T{A}_{PS\_HAS}$, and $T{A}_{PS\_FSWT}$. The proxy_subscriber module can be represented as:

$$T{A}_{PS}=T{A}_{PS\_RIS}\Vert T{A}_{PS\_ROS}\Vert T{A}_{PS\_HAS}\Vert T{A}_{PS\_FSWT}$$

For the $T{A}_{PS\_FSWT}$ timed automaton, according to the description of the XRCE-DDS Agent in the XRCE-DDS protocol, it is necessary to receive the subscriber messages and respond accordingly. According to the XRCE-DDS protocol, the timed automaton $T{A}_{PS\_FSWT}$ must receive sleep or awake messages from the client_subscriber and respond accordingly.

The XRCE-DDS Agent cannot send messages when the client_subscriber is in sleep state. This timed automaton is defined as follows.

Definition 7 $T{A}_{PS\_SFWT}$ is a tuple:

$$T{A}_{PS\_SFWT}=(Lo{c}_{PS\_SFWT},Lo{c}_{0PS\_SFWT},Ac{t}_{PS\_SFWT},C_{PS\_SFWT},In{v}_{PS\_SFWT},{\mapsto }_{PS\_SFWT})$$

Where,

• $Lo{c}_{PS\_SFWT}=\{clientSleep,clientWake,flushMsg\}$.
• $Lo{c}_{0PS\_SFWT}=\left\{clientSleep\right\}$.
• $Ac{t}_{PS\_SFWT}=\{C\_stat,C\_sleep,sleep\_flag,wake\_flag\}$.
• $C_{PS\_SFWT}=\left\{t\right\}$.
• $in{v}_{PS\_SFWT}=\{(clientWake,t<=100),(flushMsg,t<=100)\}$.
• ↦ is the set of transition relation in $T{A}_{PS\_SFWT}$, shown as Figure 8.

In the location set $LO{C}_{PS\_FSWT}$, $clientSleep$ is the initial location, representing that the client_subscriber, is asleep. Upon receiving a wake-up signal from the client_subscriber, a transition occurs from the $clientSleep$ to the $clientWake$ location, indicating that the client_subscriber has awaked. The $flushMsg$ location denotes the location in which the proxy_subscriber can transmit messages. Once a sleep message is received from client_subscriber, the system enters the location $ReadySleep$ and then transitions to the location $clientSleep$, and stops transmitting messages.

In the action set $Ac{t}_{PS\_SFWT}$, there are four actions. When the channel $C\_start$ receives the wake-up signal, the embedded device is awakened. The channel $C\_sleep$ receives the sleep signal, and the embedded device is going to enter a sleep state. The channel $sleep\_flag$ sends a message instructing the proxy_subscriber to stop transmitting messages to the embedded device. The channel $wake\_flag$ transmits a message to the proxy_subscriber model, which then sends data to the client_subscriber module.

The embedded device is sleep in the initial location $clientSleep$. Once it wakes up, the embedded device sends a signal to the proxy_subscriber module via the $C\_start$ channel, indicating that the embedded device has entered the awakened state. The $T{A}_{PS\_FSWT}$ then sends a signal to $T{A}_{PS\_ROS}$ notifying it that the embedded device is awake, which allows $T{A}_{PS\_ROS}$ to send messages. If the embedded device needs to enter the sleep state again, $T{A}_{PS\_FSWT}$ sends a signal to $T{A}_{PS\_ROS}$ indicating that the embedded device is going to sleep and no further messages should be sent.

5. Properties of Micro-ROS Model

To perform runtime verification of the model, it is to extract the key properties from the Micro-ROS communication specifications and represent them using constrained signal temporal logic formulas.

5.1. Constrained Signal Temporal Logic

Signal Temporal Logic (STL) is a temporal logic used to describe the behavior of continuous-time signals. By incorporating real-valued time variables and temporal operators, STL formally characterizes the dynamic properties of systems over continuous time intervals. Its semantics are based on measurements over time intervals, which provides a logical language for verifying and monitoring of real-time systems.

The syntax of an STL formula is defined as follows:

$$\begin{array}{cc}\hfill \varphi & ::=\mathtt{true}\mid p\mid \neg \varphi \mid {\varphi }_1\wedge {\varphi }_2\mid {\varphi }_1{\mathcal{U}}_{[a,b]}{\varphi }_2\hfill \end{array}$$

For the time interval $[a,b]$, $a,b\in {\mathbb{R}}_{\ge 0}$ and $a\le b$. In the Micro-ROS communication model, the focus is generally on the upper bound of the response time when describing the model’s properties, while the lower bound corresponds to the current moment. Therefore, to better represent the Micro-ROS requirements, we propose a constrained signal temporal logic, denoted as ${\mathtt{STL}}_{\mathrm{lb}=0}$. The syntax and semantics of ${\mathtt{STL}}_{\mathrm{lb}=0}$ are defined below.

Definition 8 An ${\mathtt{STL}}_{\mathrm{lb}=0}$ formula $\varphi$ is recursively defined:

$$\varphi ::=p\mid \neg \varphi \mid {\varphi }_1\vee {\varphi }_2\mid {\varphi }_1{\mathsf{U}}_{[0,a]}{\varphi }_2$$

Where p is an atomic proposition, a in the time interval $[0,a]$ denotes the upper bound of the time interval, and $a>0$. ${\varphi }_1$ and ${\varphi }_2$ are ${\mathtt{STL}}_{\mathrm{lb}=0}$ formulas.

Other operators, such as the implication operator →, the future operator $\mathtt{F}$, and the always operator $\mathtt{G}$, can be expressed as follows:

$${\varphi }_1\to {\varphi }_2=\neg {\varphi }_1\vee {\varphi }_2$$

$${\mathrm{F}}_{[0,a]}\varphi =\mathrm{True}{\mathrm{U}}_{[0,a]}\varphi$$

$${\mathrm{G}}_{[0,a]}\varphi =\neg {\mathrm{F}}_{[0,a]}\neg \varphi$$

The satisfaction relation $(s,t)\vDash \phi$ denotes if a signal s satisfies an ${\mathtt{STL}}_{\mathrm{lb}=0}$ formula $\varphi$ at time t.

Definition 9 The ${\mathtt{STL}}_{\mathrm{lb}=0}$ semantics for a signal s is given recursively below.

$$\begin{array}{cc}\hfill (s,t)& \vDash p\iff p\left(s\right(t\left)\right)=T\hfill \\ \hfill (s,t)& \vDash \neg \varphi \iff (s,t)\neg \vDash \varphi \hfill \\ \hfill (s,t)& \vDash {\varphi }_1\vee {\varphi }_2\iff (s,t)\vDash {\varphi }_1\vee (s,t)\vDash {\varphi }_2\hfill \\ \hfill (s,t)& \vDash {\varphi }_1{U}_{[0,a]}{\varphi }_2\iff \exists t^{\prime }\in [t,t+a],(s,t^{\prime })\vDash {\varphi }_2\mathrm{and}\forall t^{\prime \prime }\in [t,t^{\prime }],\hfill \\ & (s,t^{\prime \prime })\vDash {\varphi }_1\hfill \end{array}$$

Where $p\left(s\right(t\left)\right)$ indicates that the signal s satisfies property p at time t. For example, consider the property: "Within 200 seconds, if property p is satisfied, then property q will be satisfied within 3 seconds." This property can be expressed using the ${\mathtt{STL}}_{\mathrm{lb}=0}$ formula as:

$${\mathrm{G}}_{[0,200]}(p\to {\mathrm{F}}_{[0,3]}q)$$

the outermost ${\mathrm{G}}_{[0,200]}$ represents the duration of the system’s monitoring. During this monitoring period, if property p is satisfied, then property q will also be satisfied within 3 seconds.

5.2. Key Properties Abstraction

To ensure the reliability of communication, seven key properties are extracted based on the Micro-ROS communication specifications. These properties primarily address message transmission and reception, ensuring consistent ordering of messages and the ability to retransmit them in case of loss.

•

property ECFS: All messages sent by the client_publisher can be delivered.

The property is formulated as follows:

$${\mathrm{F}}_{[0,180]}client\_pub\_finished=1$$

In runtime verification, when the proxy_publisher receives all messages sent by the client_publisher, the signal $client\_pub\_finished$ eventually becomes 1, indicating that all messages have been delivered.

•

property ECRA: The client_subscriber can receive all messages to which it has subscribed.

This property is formulated as follows:

$${\mathrm{F}}_{[0,180]}client\_received\_all=1$$

In runtime verification, when the client_subscriber has received all subscribed messages, the signal $client\_received\_all$ eventually becomes 1.

•

property NIWS: Once the client_subscriber enters sleep mode, no additional messages will arrive to wake it.

This property is formulated as follows:

$${\mathrm{G}}_{[0,180]}(subClient\_status=1\to {\mathrm{G}}_{[0,50]}subClient\_receiveSig=false)$$

When the client_subscriber enters sleep mode (indicated by the signal $subClient\_status$ changing to 1), it will no longer passively receive messages from the proxy_subscriber. At this point, the value of the signal $subClient\_receiveSig$ for message arrivals becomes false and remains so throughout the sleep duration (50 seconds).

•

property RMIO: The proxy_publisher always receives messages in the same order as they are sent by the client_publisher.

This property is formulated as follows:

$${\mathrm{G}}_{[0,180]}(publisher\_last\_received\ge 10\to VideoInfo=TDDS)$$

When the proxy_publisher receives the 10th message (i.e., the final message), the $VideoInfo$ array containing the messages to be sent must be identical to the TDDS array of received messages. Since the array indices correspond to the sequential order of message transmission and reception, identical arrays indicate that the order of message sending and receiving order is consistent.

•

property RMIO2: The client_subscriber always receives messages in the same order as they are sent by the proxy_subscriber.

This property is formulated as follows:

$${\mathrm{G}}_{[0,180]}(subscriber\_last\_received\ge 10\to GetInfo=FDDS)$$

When the client_subscriber receives the 10th message (i.e., the final message), the $GetInfo$ array containing the messages to be sent must be identical to the FDDS array of received messages. Since the array indices correspond to the sequential order of message transmission and reception, identical arrays indicate that the order of messages sending and receiving is consistent.

•

property TMRK: When a message is lost, the receiver can detect it in a timely manner.

This property is formulated as follows:

$${\mathrm{G}}_{[0,180]}(missing\_fig=1\&\&sendMissSeq<last\_receive)\to$$

$${\mathrm{F}}_{[0,20]}findMissSeq=sendMissSeq$$

If a message is not acknowledged by the receiver, the receiver will detect the loss within 20 seconds and notify the sender of the missing sequence number by setting the $findMissSeq$ signal.

•

property FARS: All messages not received by the client_subscriber will be promptly resent by the proxy_subscriber.

This property is formulated as follows:

$${\mathrm{G}}_{[0,180]}(last\_sent>last\_ack+1\to {\mathrm{F}}_{[0,20]}last\_sent=last\_ack+1)$$

When the client_subscriber fails to receive a message, the $last\_sent$ value of the proxy_subscriber will be greater than the acknowledged value of $last\_ack$. The proxy_subscriber attempts to resend the message; upon successful transmission, it adjusts the $last\_sent$ value to match $last\_ack$ within 20 seconds.

6. Implementation, Simulation and Verification

We utilized Simulink/Stateflow to implement and simulate each module, and analyzed the results. We also applied the Logical and Temporal Assessments tool from Simulink’s Simulink Test package Test Manager to perform runtime verification of key properties extracted from the Micrio-ROS specification.

Here, we take a specific and commonly used application scenario as an example and instantiate the model using Simulink/Stateflow. In this case study, an embedded device-controlled camera acts as an XRCE Client that publishes messages in the DDS domain. Additionally, an embedded device-controlled alarm functions as an XRCE Client that subscribes to messages in the DDS domain and has a periodic sleep characteristic. Furthermore, a PC runs an XRCE Agent, which acts as a proxy for both the camera and the alarm. The top-level module of the Simulink/Stateflow model is shown in Figure 9.

6.1. Simulation and Result Analysis

In Simulink, the model’s simulation duration is set to 160 seconds. The final simulation results are observed through the Scope, as shown in Figure 10.

In Figure 10, the horizontal axis represents time, and the vertical axis indicates the number of received messages. TDDS denotes the proxy_publisher in the XRCE-DDS Agent, which receives information from the camera. GetInfo represents the alarm in the XRCE-DDS Client, which receives information from the DDS domain. The varying time intervals between consecutive message receptions demonstrate that the experiment successfully simulated delays in message reception caused by transmission loss in an unreliable network. However, TDDS ultimately failed to receive all messages, primarily due to an error in calculating the simulation time. The maximum detection time was set to only 160 seconds, which was insufficient for receiving and acknowledging all messages. This is because our simulation model includes the emulation of message loss, where some messages are retransmitted after being lost, thereby delaying their normal transmission.

We modified the simulation time in the environment to 180 seconds. After running the simulation again, the data reception status shown in Figure 11 was observed.

Figure 11 shows that after $GetInfo$ receives the 9th message, approximately 80 seconds pass before the 10th message is received. This is due to the resource-constrained embedded device entering a sleep period. During this interval, the XRCE-DDS Client enters a sleep state and cannot receive messages from the XRCE-DDS Agent. When the XRCE-DDS Client wakes up and returns to an active state, it resumes receiving messages and successfully receives the 10th message from the XRCE-DDS Agent.

6.2. Runtime Verification and Result Analysis

To verify the properties of Micro-ROS, the Logical and Temporal Assessments tool from Simulink Test’s Test Manager package is applied for runtime verification. This tool accepts properties described in natural language and converts them into signal temporal logic(STL). The STL formulas generate a syntax trees, which is then evaluated from the leaf nodes upward to construct monitors for runtime verification.

The tool allows properties to be described in a manner close to natural language. Figure 12 shows the interface provided by the tool for engineers to input these properties.

When using this tool to describe properties, the engineer adds the signals involved in the property to the tool via the "Add Symbol" button at the bottom-right corner to configure the detector. Then, the specific property specifications are written in the "ASSESSMENT CALLBACK" section. The seven properties of Micro-ROS are defined in the tool as follows.

• ECFS: At any point of time, whenever true is true, with a delay of at most 180 seconds, $client\_pub\_finished==1$ must be true.
• ECRA: At any point of time, whenever true is true, with a delay of at most 180 seconds, $clien{t}_{r}eceive{d}_{a}ll==1$ must be true
• NIWS: At any point of time, whenever $subClien{t}_{s}tatue==1$ is true, with a delay between 0 seconds and 50 seconds, $subClient\_receiveSig==false$ must be true
• RMIO: At any point of time, whenever $publisher\_last\_received\ge 10$ is true, with no delay, $VedioInfo==TDDS$ must be true
• RMIO2: At any point of time, whenever $subscriber\_last\_received\ge 10$ is true, with no delay, $GetInfo==FDDS$ must be true
• TMRK: At any point of time, whenever $missing\_fig==1\&\&sendMissSeq<last\_receive$ is true, with a delay between 0 seconds and 20 seconds,
  $findMissSeq==sendMissSeq$ must be true
• FARS: At any point of time, whenever $last\_sent>last\_ack+1$ is true, with a delay between 0 seconds and 20 seconds, $last\_sent=last\_ack+1$ must be true

The tool was used to perform runtime verification on the seven properties mentioned above, and the model passed successfully all seven verifications. The verification results are presented in Figure 13.

As shown in Figure 13, the results indicate that all seven key properties have passed verification. The system model successfully transmits messages from resource-constrained embedded devices to other nodes. Additionally, resource-constrained embedded devices can receive messages from other nodes.

7. Conclusion

With the continuous development of the Robot Operating System(ROS), Micro-ROS designed for resource-constrained devices has garnered increasing attention from both academia and industry. To ensure the safety and reliability of Micro-ROS, we studied the Micro-ROS specifications and established a modeling, simulation, and verification framework for its communication mechanisms. This framework helps ensure the safety of communication mechanisms in simulated execution paths. Based on specific Micro-ROS application scenarios, we implemented models on the MATLAB Simulink/Stateflow platform to simulate the Micro-ROS communication process. Additionally, we performed runtime verification using the Simulink Test toolkit for the seven key properties extracted from the Micro-ROS specifications.

We have modeled and analyzed the communication behavior after the communication link was established. Before Micro-ROS performs data communication, the Micro XRCE-DDS Agent needs to authenticate and authorize the Micro XRCE-DDS Client in order to ensure its communication security. Future work will investigate the security of Micro XRCE-DDS Client permissions within the DDS domain from an information security perspective, aiming to prevent device impersonation and mitigate security risks.