Image Processing Reference
In-Depth Information
overlapping ping nodes be synchronized so that no interfering vibrations will be generated at a sensor
location at any time.
This damage detection problem can be captured by a constraint model. Scheduling the activities
of the ping nodes can be formulated as a distributed graph coloring problem. A color in the graph
coloring problem corresponds to a specific time slot in which a ping node vibrates. hus two adjacent
nodes in the graph, each representing an actuator, cannot have the same color as the vibrations from
these actuators would then interfere with each other. he number of colors is therefore the length (in
distinct time slots) of a schedule. he problem is to find a minimal schedule such that the ping nodes
do not interfere with one another, to minimize damage detection and response times. Distributed
algorithms [] have been shown to be effective for solving the distributed constraint satisfaction
problem in such large scale and dynamic
∗
networks.
2.1.4 Engineering Life Cycle
Large-scale networked embedded systems are often expensive and time-consuming to develop,
deploy, and test. Allowing separate development and testing of the middleware and the target system
hardware can reduce development costs and cycle times. However, this separation imposes additional
design and implementation challenges for special-purpose middleware.
For example, to gauge performance of the distributed ping-scheduling algorithm in the actual
system, physical, computational, and communication processes must be simulated for hundreds of
nodes at once. For physical processes, tools such as Matlab or Simulink must be integrated within
the simulation environment. Computation should be performed using the actual software that will
be deployed in the target system. However, that software may be run on significantly different, and
often fewer, actual endsystems in the simulation environment than in the target system. Similarly,
communication in the simulation environment will often occur over conventional networks such as
switched Ethernet which may not be representative of the target system's network.
The following issues must be addressed in the design and implementation of middleware that is
suitable for both the simulation and target system environments:
•
Weneedtouseasmuchofthesotwarethatwillbeusedinthetargetsystemaspossible
in the simulation environment. his helps us obtain relatively faithful metrics about the
application and middleware that will be integrated with the target system.
•
We need to allow arbitrary configurations for the simulation. he hardware and software
coniguration may be different for each machine used to run the simulation, and different
kinds and numbers of target system nodes may be simulated on each machine.
•
Simple time scaling will not work as it does not guarantee that the nodes are synchronized.
First, it is not practical to require that all the computation and communication times are
known
apriori
, as one function of the simulation may be to gauge those times. Moreover,
even if we could scale the time to a “safe” upper bound, the wall-clock time it takes to run
the simulation would likely be prohibitively large.
•
Because of the heterogeneous configuration of the simulation environment, some simu-
lated nodes might run faster than others, leading to causal inconsistencies in the simula-
tion [,].
•
Additional infrastructure is thus necessary to encapsulate the heterogeneity of different
simulation environments and simulate real-time performance on top of general-purpose
operating systems and networks, with simulation of physical processes in the loop.
∗
For example, with occasional reconfiguration due to sensor/actuator failures online.
