## 2 Component-Based Architecture  
The origins of the BICA architecture can be traced back to a behavior-based project originally conceived for easy design behaviors for the Aibo robotic dog used in the RoboCup Soccer competition. In this early version, named MBA [27], behaviors were the basic blocks of the architecture. Each behavior had a goal that must be satisfied, and may have one or more prerequisites. If any behavior's prerequisite was not met, it was set as a goal to the lower level.  
The public version of that preliminary architecture was named Behavior-based Iterative Component Architecture (BICA) ([[https://github.com/IntelligentRoboticsLabs/BICA](https://github.com/IntelligentRoboticsLabs/BICA)]([https://github.com/IntelligentRoboticsLabs/BICA](https://github.com/IntelligentRoboticsLabs/BICA))) [13]. The minimum unit of execution was defined as the component, and the behavior of the robot emerged from the concurrent execution of various components.  
Components (Figure 2) are software processes that, when active, are executed at a certain frequency depending on their function. Each component can establish other components that it requires for its operation, as shown in the left part of Figure 3, which we call dependencies. When a component is active, it cascades its dependencies, collecting the result of its computation or establishing the input it requires for its operation.  
Using this approach, we can create activation trees that correspond to the skills of the robot (navigation, perception, HRI, manipulation), whose leaves are the sensors and actuators, as shown in right part of Figure 3. Behaviors would be created by incorporating these trees with the skills as subtrees of a larger tree.  
We have implemented a particular type of component that contains a finite state machine and can be found multiple times anywhere in the tree. Dependencies are established at the state level, allowing a certain degree of intelligence about which dependencies are activated at any given time.  
We consider this approach to be a two-layer architecture: the bottom layer contains the robot's skills (navigation, perception, performance), and the top layer contains FSMs that control the robot's  
Figure 3: Different possible topologies in BICA (**left**). An example of a perceptive behavior implementation using BICA (**right**).  
Figure 2: A Behavior-based Iterative Component Architecture (BICA) component.  
mission and decide when to activate which skills. A component that requires information from another component obtains it with direct connections, for the moment lacking a transparent model of working memory or something similar.  
Several aspects must be taken into account:  
* Components can be activated from more than one component.
* A component becomes inactive when no component requires its activation. The only exception is the root of the activation tree.
* The system must be robust to components that suddenly disappear. All its dependencies must be able to discover this fact to be deactivated if it is its only activator.
* The system must be able to handle components that start late. If a component is among the dependencies of an active component, it must be activated immediately.  
This architecture is appropriate for many applications. We have played robot soccer and participated in social robot competitions with this approach. The disadvantages that we identified were:  
* The direct connection between activator-dependency components limits that several components cooperate at the same level.
* State machines do not scale well when applications become more complex, and the number of eventualities that can occur begins to grow.