## 3 Background of ROS-2 Architecture  
An embedded application in ROS consists of a set of interconnected nodes (Figure 2). Each node contains one or more callbacks, which are the smallest pieces of code of the application. To ensure the consistent execution of programs written with different specific languages and different underlying platforms, a set of libraries provides the required abstraction at different layers. rmw is the middleware layer that ensures the interface between the data distribution service (dds) [32] layer and the robot client library (rcl) layer. The rcl layer provides the abstraction of application programming interfaces (APIs) to the application to ensure consistent execution between the rmw layer and specific language client libraries such as Python (rclpy) and C++ (rcpcpp) [33]. dds is a vendor-specific implementation of rmw that standardizes real-time communication between nodes. The nodes communicate using a publisher/subscriber communication paradigm or a client/server communication paradigm. The publisher/subscriber communication paradigm is suitable for data flow streaming and sensor nodes, while the client/server communication paradigm is more suitable for synchronous remote procedural call and control nodes. Nodes use topics to communicate between publishers and subscribers, and use services to communicate between clients and servers. Topics and services are identified by a unique name, and one node can publish data on several topics and may also subscribe to several topics. A server may have multiple clients, but a client must have one server. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Method Class** & **References** & **Online/Offline** & **Built-in ROS-2** & **Variables** & **Optimization Goals** \\ \hline Formal Analysis & [15; 20; 21; 22] & Offline & No & priority & latency-success ratio, data consistency \\ \cline{2-6}  & [6; 23; 24] & Offline & Yes & priority & latency \\ \cline{2-6}  & [8] & Online & Yes & priority, mapping & latency, core balancing \\ \cline{2-6}  & [26] & Offline & N/A & QoS profiles, threat generation & loss rate, coverage, latency \\ \hline Measurement-based & [3; 7; 27] & Offline & No & QoS policy, security & loss rate, latency, throughput \\ \hline Heuristic & [28] & Offline & No & priority, mapping & real-time performance, reliability \\ \cline{2-6}  & [11; 19] & Offline & No & mapping, priority, sequencing & real-time performance, preliminary \\ \cline{2-6}  & [12; 19] & Offline & No & mapping, scheduling & success ratio, latency \\ \cline{2-6}  & [13] & Offline & No & mapping, scheduling & inter-cores communication overhead, latency \\ \hline Metaheuristic & [29; 30; 31] & Offline & No & clustering & path cost \\ \cline{2-6}  & [11] & Offline & No & mapping, core balancing & resp. time analysis \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Summary of related worksScheduling in ROS-2  
This section gives a brief description of the ROS scheduling mechanism and scheduling-related artifacts. The ROS scheduling model is implemented using executors. An executor selects pending callbacks from the ready list to be executed. Basically, two implementations are defined in ROS: a single executor and a multithreaded executor. In this study, we consider a single-threaded executor. **Callback**: This is the smallest executable code scheduled in ROS-2. ROS-2 defines five types of callbacks: timers that are time-triggered by system-level timers, subscribers that are triggered by the reception of new messages at a topic, services, and clients callbacks that are triggered by service requests and responses, respectively. **Node**: The node is the minimal self-contained unit of behavior. A node contains a set of callbacks organized by application programmers for the modularity and logical partitioning of functions. All callbacks from the same node are executed by the same executor.