Image Processing Reference
In-Depth Information
Pincompatibilitycanplayamajorrolewhenchoosingcomponentsasitofersadegreeoffreedom
in terms of migrating from one HW component to another without requiring a complete redesign of
the PCB.
27.8.3 Subsystem Behavior
27.8.3.1 Local vs. Global Optimum
As discussed above, the sum of the parts can equal more than the individual parts together, at least
from a product maintenance point of view. However, great care must be taken to ensure that sum
of the parts also provides adequate performance (speed, power consumption, footprint, etc.). Even
if each component has been optimized individually (for speed, power consumption, footprint, etc.),
this does not guarantee that the final system behavior is optimal.
The principle operation of a WSN device can be described by the generic state machine depicted
in Figure .. This describes the overall behavior of the WSN device. The components that make
up your device will in turn have their own state machines. he timing and interaction between the
components thus is critical to arrive at an optimal overall system behavior. Care needs to be taken
to ensure that a given functionality from one component is available when it is needed (according to
the overall device state chart), or that enough memory or power is available to execute the requested
operation. This can be difficult to achieve, especially if COTS components are utilized where you
have little influence over the internal behavior of the component.
27.8.3.2 Control Freak
When reusing components, either developed in house or COTS, they will provide an interface and
level of control that could be nonoptimal from a low-power design perspective. For example, if the
communications stack is a black box COTS component, which only provides limited possibility of
controlling its internal behavior, it could seriously affect the sleep-wake-up scheme, and thus the
power consumption, of the device. How much control a component allows will thus dictate the low-
power design, which we describe in detail in Section ..
The interfaces are thus the Achilles' heel of a modular WSN design. As stated before, they
need to be sufficiently general to enable efficient integration and porting, while not adding an
excessive overhead. In addition, the interfaces also need to provide some control of the inter-
nalbehaviorofthecomponenttobeabletomediatebetweengeneralityandperformance.his
goes against the basic principle of information hiding employed by component-based develop-
ment, where internal state information is not shared and interaction is accomplished by exchanging
messages-carrying data. However, in low-power WSN devices, where the system is a sleep most of
the time, this “low-level” control is sometimes crucial to adhere to the sleep-wake-up schedule of the
device.
27.8.3.3 Debugging a Black Box
Using black box components has the advantage that the functionality provided by the component
is completely hidden. he developer thus does not need to bother about how the component works
in detail, nor invest time and effort in testing and validating its functionality. In theory, this is true,
but in addition to loss of control as described above, there is an additional risk that problems will
appear when debugging the total system and the component functionality is part of the debug trace.
As the name states, it is a black box, and there is no way to peer into the box to see what happens. his
increases the difficulty of locating the bugs, i.e., determine if they are present inside the component
or in other parts of the system. This problem is especially pronounced if the COTS component is
itself in a “beta stage” (which is very common in early development phases of new technology) and
bugs are certain to exist within it.
 
Search WWH ::




Custom Search