Layered Architecture
The figure shows Alberto Elfes' definition of the idealized layered architecture [Elfes87] that influenced the design of the Dolphin sonar and navigation system, implemented on the Terregator and Neptune mobile robots [Champeny93, Podnar84].
Layered Architecture
At level 1, the lowest level, reside the robot control routines (motors, joints,...).
Levels 2 and 3 deal with the input from the real world. They perform sensor interpretation (the analysis of the data from one sensor) and sensor integration (the combined analysis of different sensor inputs).
Level 4 is concerned with maintaining the robot's model of the world.
Level 5 manages the navigation of the robot.
The next two levels, 6 and 7, schedule and plan the robot's actions. Dealing with problems and replanning is also part of the level-7 responsibilities.
The top level provides the user interface and overall supervisory functions.
(R1) Elfes' model sidesteps some of the problems encountered with the control loop by defining more components to which the required tasks can be delegated. Being specialized to autonomous robots, it points to the concerns that have to be addressed (e.g., sensor integration). Furthermore, it defines abstraction levels (e.g, robot control vs. navigation) to guide the design.
While it organizes well the components needed to coordinate the robot's operation, the layered architecture does not fit the actual data and control flow patterns. The layers suggest that services and requests are passed between adjacent components. In reality, as Elfes readily admits, the information exchange is less straightforward. For instance, data necessitating fast reaction may have to be sent directly from the sensors to the problem handling agent at level 7, and the corresponding commands may have to skip levels to reach the motors in time.
Another imprecision in the model is that it does not separate the two abstraction hierarchies that actually exist in the architecture:
(R2) The existence of abstraction layers addresses the need for managing uncertainty: what is uncertain at the lowest level may become clear with the added knowledge available in the higher layers. For instance, the context embodied in the world model can provide the clues to disambiguate conflicting sensor data.
(R3) Fault tolerance and passive safety (when you strive not do something) are served by the abstraction mechanism too. Data and commands are analyzed from different perspectives. It is possible to incorporate many checks and balances into the system.
As already mentioned, performance and active safety (when you have to do something rather than avoid doing something) may require that the communication pattern be short-circuited.
(R4) The fudged dependencies are an obstacle to easy replacement and addition of components. The fragile relationships between the layers can become more difficult to decipher with each change.
In summary, the abstraction levels defined by the layered architecture provide what constitutes the goal for software architectures in general: a framework for organizing the components. It achieves this objective by being precise about the role of the different layers.
The major drawback of the model is that it breaks down when it is taken to the greater level of detail demanded by an actual implementation. The communications patterns in a robot do most probably not follow the very orderly scheme implied by the architecture.
Updated Halloween 95 by
Mary Shaw
Comments to maintainer