SWA: Chapter 11 Applied Architecture and Styles
11.5
Architectures From Specific Domains
11.5 give us specific domains architecture of different applications. We can extend the
techniques used in development, the analyses of the design, and the resulting styles beyond these
specific domains.
11.5.1 Robotics
Robotics consist of systems that are based on autonomy and mobility.
Mobile tele-operated systems – bomb disposal robots, where it may be full or partial
control actions and movements by human operator at a remote location.
Industrial automation systems – automotive assembly robotic arms that perform
specific tasks without a change in their environment. The environment designs the robot’s tasks and
movements.
Mobile autonomous robots – DARPA Grand Challenge vehicles, the vehicles are
responsible for their own autonomous control without a human operator. Also, running through
unpredictable environments.
11.5.1.1 Challenges
There are two primary factor challenges in the robotics domain: the physical platforms and devices that
make up the robots and the unpredictable environments that the robots operate in.
Robotic platforms consist of large integration of sensors and devices that can be easily malfunctions.
These sensors and devices are wireless radio communications and vision sensors.
The OS on the robotic platforms must operate with diminished hardware capacity and the loss of
essential functions. Information from these sensors are unreliable and may spikes erroneous data
readings.
The second challenge is the robot’s operations in a dynamic environment. A mobile robot may traverse
through unknown terrain with random weather condition. It may be required to move obstacles. These
requirements greatly increase the difficulty in design such software that can account for the dynamic
environments.
Special interest qualities in robotic architecture are: robustness, performance, reusability, and
adaptability.
11.5.1.2 Robotic Architectures
Robotic architectures originate from artificial intelligence techniques for data representation and
reasoning.
SPA:
Sense-Plan-Act Architecture from Nilsson in 1980, identifies the need of using a continuous feedback
from the robot’s environment as an input to its actions. There are 3 components with a unidirection
flow of communication between them: Sense, Plan, and Act ( Figure 11-9).
The sense component gathers sensor information as inputs to the plan components.
The plan component uses these inputs to create actions that the robot should perform.
The act component is to communicate and execute using the robot’s motors and actuators.
The SPA architecture resembles the sense-compute-control (SCC) pattern in Chapter 4. But an important
distinction is in the plan component there is a world model that use the sensory inputs to determine the
robot’s actual state and determine what actions should perform next. The internal model is constantly
updated to be consistence with the actual environment conditions. The SCC pattern does not have such
a model.
The main drawback of SPA architecture is performance and scalability. Sensors information must be
integrated or sensor fusion into the robot’s planning model to determine its actions in each iteration.
These operations are time-consuming and cannot keep up with fast environmental changes.
Subsumption:
Subsumption attempted to address the drawback in SPA architecture by Brooks in 1986. Give up the
complete world models and plans as the central element in robotic systems. There is no explicit planning
step between sense and act.
Subsumption architecture composed of independent components and each encapsulated with a
specific behavior. Complex layers communicate through two operations: inhibition and
suppression (Figure 11-10). “In the figure, output from Skill C may cause the input from Skill
A to Skill B to be delayed by time t; similarly output from Skill C may override the output of
Skill B to Actuator 1 for time t”
Rather representing as a single plan model, subsumption architecture creates independent
modules arranged in layers. It is more reactive in nature. Subsumption offers fast and nimble
performance.
Subsumption drawbacks are lacking a coherent architecture plan and no support for the complex
layers.
Three-Layer:
Three-layer (3L) is a hybrid architecture that attempt to bridge the gap between SPA and
subsumption by Firby in 1989. This architecture separates the robot functionality into three
layers (name may differs from system to system Figure 11-11):
reactive layer-react to events with a quick action
sequencing layer-linking functionalities in the reactive layer into complex behaviors
planning layer-performs slower long-term planning
3L combines both reactive operation and long-term planning. Many 3L architectures have
special-purpose scripting language.
One challenge with the 3L architectures is separate functions into three layers. Depending on the
tasks, one layer may dominate the other layers in importance and complexity. The sequencing
layer may results in difficulties when translating higher-level planning into lower-level execution
and may cause unnecessary performance overhead.
Reuse-Oriented
With modern software and engineering technologies, the primary goals is component reuse to
maximize returns on time and cost during development.
Reuse-Oriented architectures consist of explicit object-oriented interface definitions for
components and the use of frameworks for developing component that are reusable across
different projects.
The WITAS unmanned aerial vehicle project by Doherty et al in 2004 uses CORBA as
information interchange and using CORBA IDL to clearly defined interfaces for each
component.
The CLARATy reusable robotic software architecture by Nesnas et al in 2006 is a two layer
architecture that use a goal-network approach for planning. It defined a generic device interfaces
so different devices of the same type can be use with any instance of CLARATy architecture.
Development Framework for Robotic Systems
Many robotic systems are designed and built independently. There are a number of frameworks
and tools to speed up the development process. Each framework targets a specific aspect of
robotic development.
Popular Frameworks:
Player-open-source project targets Unix-based environments. Provides networked
accessible interfaces to many devices with support for distributed operations of robotic
components. Supports integrations with the Stage and Gazebo 3D system.
Orca-open-source, cross-platform framework focused on component-based robotic
systems. It uses the Ice middleware framework for cross-component communication.
Microsoft Robotic Studio-MRS is a free integrated environment for robotic system
development. It supports .NET-based service-oriented architecture with C# and VB.NET
languages. The environment simulation supported through PhysX simulation engine.
Lego Mindstorms-provide both hardware and software. Low cost and easy application to
educational needs. The package contains servos and sensors along with a special-purpose OS and
LabVIEW graphic development environment by National Instruments.
11.5.2 Wireless Sensor Networks
Senors nets are a large reactive application that monitor the environment and report on its state.
Wireless sensor network (WSN) systems are used in various domain: medical systems,
navigation, industrial automation, and civil engineering such as monitoring and tracking.
These systems are low installation cost, inexpensive maintenance, and easy reconfiguration.
But it is very challenging to implement: it may need to integrate with legacy wired networks,
embedded devices, mobile networks with PDAs and cell phones for notifications.
The wireless devices are constrained with power consumption, communication bandwidth and
range, and processing capacity. Wireless sensor systems constraints are fault-tolerance,
performance, availability, and scalability.
MIDAS architecture contains 3 architecture styles (Figure 11-12):
Peer-to-peer-deployment activities, exchange application level components
Publish-subscribe-the communication backbone for routing and processing sensor data on
various platforms
Service-oriented-less used for system monitoring and adaption facilities. These services
are distributed among the platforms.
11.6 End Matter
The theme of this chapter was architectures for complex applications resulted from different
application domain. Careful choices of elements and styles and a hybrid of these elements create
a coherent solution. REST is an excellent example. REST coped with issues of presence latency
and agency in network.
Peer-to-peer highlighted area are discovery of other peers, search for resources, and risks of
performance problems and malicious entities. Security and trust will be discuss in Chapter 13.
Growing scope does not become more complex if we exploit ideas in large commercial
applications such as Google, Akamai, and Skype.
The next three chapter 12, 13, and 14 will address non-functional properties such as scale,
performance, and security.