You are presented with multiple paper abstracts, alongside the associated literature review and chapter titles. Given the provided information, you are going to do a literature review. Please generate a coherent literature review that synthesizes the content, draws connections between different works, highlights major findings, and identifies any gaps in the existing research.

Literature Review Title: An overview on framework design for autonomous robots 
Chapter Title:  Runtime model 
1. Abstract of Cited Paper (BIB001):  Developing reusable robotic software is particularly difficult because there is no universally agreed upon definition of what a robot is. Over the past half-century, robots took many forms. Some were inspired by their biological counterparts such as humanoids, dogs, snakes, and spiders. Others were designed for particular domains such as manufacturing, medical, service, military, or space applications. They took the form of arms, wheeled robots, legged robots, hoppers, blimps, underwater vehicles, sub-surface diggers, and even reconfigurable robots. 
2. Abstract of Cited Paper (BIB002):  This paper proposes the RT-Middleware for robot system integration. "RT" means "Robot Technology" which is applied not only to industrial field but also to nonindustrial field such as human daily life support systems. We have studied modularization of RT elements and have developed software platform RT-Middleware which promotes application of RT in various field. Robotic system development methodology and our RT-Middleware concepts is discussed. The RT-Component which is a basic madular unit of RT-Middleware based system integration is derived from this discussion. A methodology of system development with RT-Components, and a framework to make component are shown. 
3. Abstract of Cited Paper (BIB003):  This paper presents the Robotics Service Bus (RSB), a new message-oriented, event-driven middleware based on a logically unified bus with hierarchical structure. Major goals for the development of RSB were openness and scalability in order to integrate diverse components in the context of robotics and intelligent systems. This includes the ability to operate on embedded platforms as well as desktop computers, reduction of framework lock-in, and the integration with other middlewares. We describe the design of the RSB middleware and explain how it meets requirements which lead to a scalable and open middleware concept. These requirements are based on several application scenarios which are used to verify the applicability of RSB. Furthermore, we relate RSB to other middlewares in the robotics domain. 
4. Abstract of Cited Paper (BIB004):  Communication between software components is one of the most important functionalities a software framework for modern complex robotic systems has to provide. Here, we present the highly performant realtime communication layer of our new robotic software framework aRDx (agile robot development - next generation), with, e.g., zero-copy semantics, realtime determinism and detailed control of the QoS (quality of service). In addition, we give an in-depth performance comparison to other popular robotic frameworks, namely ROS, YARP, Orocos and aRD. 
5. Abstract of Cited Paper (BIB005):  Because robotic systems get more complex all the time, developers around the world have, during the last decade, created component-based software frameworks (Orocos, Open-RTM, ROS, OPRoS, SmartSoft) to support the development and reuse of "large grained" pieces of robotics software. This paper introduces the BRICS Component Model (BCM) to provide robotics developers with a set of guidelines, metamodels and tools for structuring as much as possible the development of, both, individual components and component-based architectures, using one or more of the aforementioned software frameworks at the same time, without introducing any framework- or application-specific details. The BCM is built upon two complementary paradigms: the "5Cs" (separation of concerns between the development aspects of Computation, Communication, Coordination, Configuration and Composition) and the meta-modeling approach from Model-Driven Engineering.

Literature Review:
A framework's runtime model (see BIB002 ) comprises whether execution is synchronous or asynchronous and how it is triggered -periodically, or by events. Furthermore, it defines how threads are mapped to components. At the one extreme, each component has its own thread -or even process, as in ROS⁵ or Orca 2. Notably, executing components in different processes can increase systems' robustness by preventing memory corruption from other erroneous components. This feature can be preserved if processes use shared memory for data exchange, as Hammer et al. BIB005 show. On the other hand, they discuss the importance of avoiding thread clutter from too many running threads. In other frameworks (e. g. OpenRTM-aist, mca2), components can be assigned to threads. For instance, this allows the execution of "tightly coupled RTCs in a single (real-time) thread" BIB003 . As mentioned, the option of executing multiple components by the same thread is necessary for small components to be feasible. How many processes to distribute components to is a trade-off including factors such as robustness and efficiency. Synchronous implementations are typically simpler than asynchronous ones, but the latter often lead to lower latencies -especially when many threads are involved. mca2 and the Player Project are examples for frameworks that trigger execution periodically only. This has the advantage that it is simple and predictable. However, "it imposes an average delay of a half cycle on all data [. . . ]" BIB001 . Wienke et al. BIB004 present an entirely event-based solution. Nesnas BIB002 states that "robotic systems require both synchronous and asynchronous execution of different activities". Thus, a general-purpose framework should support both concepts. Design choices in the runtime model have an impact especially on responsiveness, scalability, robustness, and efficiency of a system. In Finroc, multiple components can be assigned to a thread. Both periodic and event-driven execution are supported. pose. Some kind of configuration interface is a common element as well. Bruyninckx et al. BIB006 captured these commonalities in a meta model. Finroc supports multiple component types via plugins. They are derived from a common base class, but have different kinds of interfaces, execution semantics, and e. g. connection constraints. The "SenseControlModule" was adopted from mca2. The behavior components use only data ports. Their semantics are explained in  .