Image Processing Reference
In-Depth Information
and ORBexpress RT [] are general-purpose CORBA implementations that provide real-time and
distribution features for a wide variety of application domains.
2.1.2 Networked Embedded Systems Middleware
General purpose middleware is increasingly taking the role that operating systems held three decades
ago. Middleware based on standards such as CORBA [], EJB [], COM [], and Java RMI []
now caters to the requirements of a broad range of distributed applications such as banking trans-
actions [,], online stock trading [], and avionics mission computing []. Different kinds of
general-purpose middleware have thus become key enabling technologies for a variety of distributed
applications.
To meet the needs of diverse applications, general-purpose middleware solutions have tended to
support a “breadth” of features. In large-scale applications, “layers” of middleware have been added
to provide different kinds of services [].
However, simply adding features breaks down for certain kinds of applications. In particular, fea-
tures are rarely innocuous in applications with requirements for real-time performance or small
memory footprint. Instead, every feature of an application and its supporting middleware is likely
either to contribute to or detract from the application in those dimensions. herefore, careful selec-
tion of features is crucial for memory constrained and/or real-time networked embedded systems.
As middleware is applied to a wider range of networked embedded systems, a fundamental
tension between breadth of applicability and customization to the needs of each application becomes
increasingly apparent. To resolve this tension, special-purpose middleware must be designed to
address the following two design forces.
. Middleware should provide common abstractions that can be reused across different
applications in the same domain.
. It should then be possible to make fine-grained modifications to tailor the middleware to
the requirements of each specific application.
In the following section, we describe a motivating example application and the design constraints
it imposes. In Section .., we describe additional design constraints imposed by the engineering
life cycle for this application.
2.1.3 Example Application: Ping Node Scheduling for Active
Damage Detection
To illustrate how application domain constraints drive the design of special-purpose middle-
ware, we now describe a next-generation aerospace application [], in which a number of MEMS
sensor/actuator nodes are mounted on a surface of a physical structure such as an aircraft wing. he
physical structure may be damaged during operation, and the goal of this application is to detect
such damage when it occurs. Vibration sensor/actuator nodes are arranged in a mesh with (wired
or wireless) network connectivity to a fixed number of neighboring nodes. To detect possible dam-
age, selected actuators called “ping nodes” generate vibrations which propagate across the surface of
the physical structure. Sensors within a defined neighborhood can then detect possible damage near
their locations by measuring the frequencies and strengths of these induced vibrations. he sensors
convey their data to other nodes in the system, which aggregate data from multiple sensors, process
the data to detect damage, and issue alerts or initiate mitigating actions accordingly.
Three restrictions on the system make the problem of damage detection difficult. First, the
sensor/actuator nodes are resource-constrained. Second, two vibrations whose strengths are above
a certain threshold at a given sensor location will interfere with each other. Third, sensor/actuator
nodes may malfunction over time. These constraints, therefore, require that the actions of two
 
Search WWH ::




Custom Search