## 1 Introduction  
The robot operating system (ROS) offers a service-oriented solution for the development of distributed robotic systems. It enables the integration of open-source libraries and tools by standardizing the methodology of software design and the underlying communication layer [1, 2]. Most robotic systems are classified as real-time and safety-critical. The predictable execution of the timing under real-time constraints is an important key design for such complex systems. ROS focuses on the fast and functional integration of different applications, while execution control and timing constraints are not adequately addressed by the middleware [3]. Despite the effort in the new ROS-2 distribution to address the support of real-time and fault-tolerance mechanisms [4], there is no clear definition of callback execution order within an executor and there is no control over the execution order between the different nodes. The precedence of execution and the dependencies between different nodes and callbacks cannot be clearly defined, and there are no mechanisms to define the real-time scheduling of running entities [5]. Research on the end-to-end real-time analysis of ROS-2 embedded applications has started recently. [PERSON] et al. [6] proposed a pioneering analysis of end-to-end timing chains in ROS-2. Subsequently, several studies addressed the real-time behavior of the ROS-2 execution model and its performance and security capabilities [3, 7]. New scheduling techniques were proposed to improve the conventional ROS-2 scheduler by proposing an alternate scheduler as in [8] or keeping it unmodified as in [9]. All these previous studies consider the number of callbacks and executors to be predefined and assume that the callbacks are already assigned to executors. They then propose solutions for the real-time scheduling of the application. To schedule an embedded application in ROS, we need to map callbacks to an executor in the context of which callbacks are executed on the processor. ROS does not impose any requirements on this step of configuration. The execution model is based on the processes that run the executors to receive messages and invoke callbacks [4]. For large systems, manually setting up an execution order of callbacks inside the executor, as well as assigning priorities to executors, is always error-prone and difficult to predict. In critical safety systems, static memory allocation is crucial. In the initialization phase, the system designer determines the number of callbacks for the embedded application and the necessary dynamic memory to be allocated before the system execution. Then, the system designer maps the callbacks to the executors. The order of callbacks within an executor is important because it may affect the real-time execution and performance of the embedded system in real-time. During the configuration step, the system designer shall define the number of callbacks and their sequence within the executor. The simplest approach is to bind each callback to one executor. However, mapping each callback to a dedicated executor leads to a lot of context switches and may lead to a deadline violation and significant OS overhead. Similarly, mapping all callbacks of a node to a single executor may leave the system unresponsive if the executor fails. In addition, the internal branching structure of such a process becomes complex to schedule. Having these two extremes in mind, finding a middle solution is an optimization goal. Our problem consists of finding a partitioning of the callbacks set that is schedulable with a minimum number of executors. The number of partitions to be explored for n callbacks is the Bell number [10]. The Bell number is exponential with respect to the number of callbacks n and can be computed by the following recurrence relation:  
\[B_{n+1}=\sum_{k=0}^{n}\binom{n}{k}B_{k}\ \ \ with\ B_{0}=1 \tag{1}\]  
For example, to search for a space of 500 callbacks, we obtain \(B_{500}\approx 10,844\).