Middleware Design and Implementation for Networked Embedded Systems - Networked Embedded Systems - page 23

2.1.5 Middleware Design and Implementation Challenges
To facilitate exchanges of information between nodes as part of the distributed algorithm, a mid-
dleware framework that provides common services like remote object method invocation is needed.
Two key factors that motivate the development of ORB-style middleware for networked embedded
systems are () remote communication and () location independence.
Remote communication : Even though a fixed physical topology may connect a group of sensor/
actuator components, the “logical” grouping of these components may not strictly follow the
“physical” grouping.
Location independence : he behavior of communicating components should be independent of their
location to the extent possible. True location independence may not be achievable in all cases, e.g.,
due to timing constraints or explicit coupling to physical sensors or actuators. However, the imple-
mentation of object functionality should be able to be decoupled from the question of whether it
accesses other objects remotely or locally where appropriate. The programming model provided to
the object developer should thus provide a common programming abstraction for both remote and
local access.
In summary, the key challenges we faced in the design and implementation of special-purpose
middleware to address the application domain constraints described in Sections .. and .. are to
Reuse existing infrastructure : We want to avoid developing new middleware from scratch. Rather, we
want to reuse pre-built infrastructure to the extent possible.
Provide real-time assurances :heperformanceofmiddlewareitselfmustbepredictabletoallow
application-level predictability.
Provide a robust DOC middleware : We chose the DOC communication paradigm as it offers direct
communication among remote and local components, thus increasing location independence.
Reduce middleware footprint : The target for this middleware is memory-constrained embedded
microcontroller nodes.
Support simulation environments : Simulations should be done with the same application software and
middleware intended for deployment on the target. he middleware should also be able to deal with
heterogeneous simulation testbeds, i.e., different processor speeds, memory resources, etc.
2.2 Middleware Solution Space
General-purpose CORBA implementations like TAO [] offer generic CORBA implementations,
whose feature sets are determined apriori . Furthermore, faithful implementation of the entire
CORBA standard increases the number of features supported by ORBs and hence results in
increased footprint for the application. In the case of memory-constrained networked embedded
applications, this can become prohibitively expensive.
We instead want to get “only” the features that we need. The selection of features for our
special-purpose middleware implementation was strictly driven by the unique requirements of
the application domain. Two approaches to developing special-purpose middleware must then be
considered:
• Top-down : subdividing existing general-purpose middleware frameworks, e.g., TAO []
• Bottom-up : composing special-purpose middleware from lower level infrastructure, e.g.,
ADAPTIVE Communication Environment (ACE) []
Both approaches seek to balance reuse of features with customization to application-specific
requirements. he top-down approach is preferred when the number and kinds of features required