SEKE 2012 Proceedings - Knowledge Systems Institute

data dependencies required for keeping the impact level. A
component may receive data from the same type of multiple
components. In t his case, the com ponent depends on the
multiple components that have the same impact level. If the
dependent component cannot receive data from at least
some number of same type com ponents, it can have
additional impact from the missing data. In this case, t he
impact level of the sam e type components to its depe ndent
component needs to inc rease one level up. Each Camera
component (Fig. 2) has a tolerable im pact to the Car
Detection component, but the tolerable impact should
change to seri ous if both Camera components encounter
failures at the same time. This is because the Car Detection
component requires the data from at least one Cam era
component so as to generate the reliable output.
the failure. The application configuration manager checks
how much the failed component has impact on its dependent
components in the application. A component in the
Executor1 depends on the fai led component and the im pact
level is serious. Now the component in the Executor1 waits
for some data from the failed component. Without the failed
component, the component in the Executor1 cannot process
the data. The application configuration manager requests the
Executor1 to stop the dependent component. Similarly, the
second component in the Executor1 depends on the sec ond
and third components in the Executor2. However, the
dependent component can survive even though t he second
component in the Exec utor2 fails. T his is because t he
impact level is tolerable.
3. Reconfiguration
3.1 Prototype
An application configuration manager as a prototype is
developed to validate the reconfiguration of a robot
application using the data dependency relationships between
components and their impact analysis. The application
configuration manager decides whic h components need to
be reconfigured using the data dependency relationships
between components and their impact levels in response to a
component failure. The scope of reconfiguration is decided
depending on the criticality of c omponent dependencies,
such as insignificant, tolerable, serious, or catastrophic. For
this, the appl ication configuration manager generates a
reconfiguration plan by c onsidering ripple effects of the
failure using the data dependency relationships and t heir
impact levels. This plan includes all the components being
affected from the failure.
The application configuration m anager reconfigures an
application by interacting with executors in the OPROS
engine [Song08, Jang10]. The OPROS engine is a platform
for robot applications t hat executes robot applications
composed of components. Periodic components that process
data periodically are activate d and run by executors in the
OPROS engine. Each e xecutor runs components that have
the same periodic cycle tim es. When an executor detects a
component failure, it requests reconfiguring the components
associated with the failed c omponent from the application
configuration manager. Each executor has the worst ca se
execution times of c omponents, detecting a c omponent
failure if the component cannot finish its periodic cycle time
within its worst case execution time.
Figure 3 depicts the outline of our prototype for
reconfiguring components against component failures using
the data dependency relationships between components and
their impact analysis. Suppose two executors in the OPROS
engine execute periodic and same cycle-timed components.
When the first component in the Exec utor2 fails, the
executor notifies the application configuration manager of
Serious
tolerable
tolerable
Component
(50ms)
Component
(50ms)
Executor 1
failure
Component
(50ms)
failure
Component
(50ms) Executor 2
Component
(50ms)
Component
(50ms)
Failure
notifying
Reconfiguration
Message
Queue
Application
Configuration
Manager
Update configuration table
( dependency table &
impact table)
Dependency
table/I mpact
table
Fig. 3 Outline of Reconfiguration in OPROS
3.2 UGV Application
The approach proposed in th is paper is validated with
the Unmanned Ground V ehicle (UGV) application
[Roh11], which drives a car to the destination place
safely without a human driv er’s intervention. Fig. 4
depicts the data dependency relationships between
components and their impact levels for the Pedestrian
Detection that is used for validating our approach, along
with the Environment Modeling and Perception (Figs. 1
and 2) described in sectio n 2. The Th ermal Imaging
Camera (TIC) renders infrared radiation as a visual light.
The Car Detection component produc es other cars
trajectory by analysing the data that comes from LRF,
Camera, and TIF components. The Pedestrian component
detects people on the road and the Localizatio n
component generates th e world space absolute
coordinates. Using the data from the Localization, Car
Detection and Pedestrian components, the Dangerous
Situation component determines if it sh ould generate an
alarm to prevent critical accidents.
For test purpose, we inject ed failures to components
and the reconfiguration result were co mpared to th e
686