Image Processing Reference
In-Depth Information
Automatic configuration
: he requirement for a plug-and-play-like configuration
can be justified by three arguments: First, an automatic or semiautomatic configuration
saves time and therefore leads to better maintainability and lower costs. Second, the nec-
essary qualification of the person who sets up the system may be lower if the overall
system is easier to conigure. hird, the number of configuration faults will decrease, since
monotone and error-prone tasks like looking up configuration parameters in heavy man-
uals are done by the computer. In most cases, a fully automatic configuration will only
be possible if the functionality of the system is reduced to a manageable subset. For more
complex applications, consulting a human mind is unavoidable. hus, we distinguish two
usecases,()theautomaticsetupofsimplesubsystemsandthe()computer-supported
configuration of large distributed systems. The first case mostly deals with systems that
require an automatic and autonomous (i.e., without human intervention) reconfigura-
tion of network and communication participants in order to adapt to different operating
environments. Usually, such systems either use very sophisticated (and often costly) nego-
tiation protocols or work only on closely bounded and well-known application domains.
The second case is the usual approach.
.
Comprehensible interfaces
: In order to minimize errors, all interfaces will be made as com-
prehensible as possible. his includes the uniform representation of data provided by the
interfaces and the capability of selectively restricting an interface to the data required
by its user. The comprehensibility of an interface can be expressed by the
mental load
that it puts onto the user. Different users need different specialized interfaces, each with
a minimum of mental load. For example, an application developer mostly has a service-
centered view of the system. Physical network details and other properties not relevant
for the application should be hidden from the developer [].
.
Uniform data structures
: The configuration and management of distributed embedded
systems require representations of system properties that are usable by software tools.
In order to avoid a situation where each application deals with the required information
in its own way, these representations should be generic, highly structured, and exactly
specified.
.
Lowoverheadonembeddedsystem
: Typical embedded hardware is restricted by require-
ments for cost, size, power consumption, and mechanical robustness. Thus, embedded
hardware usually provides far less memory and processing power than average desk-
top systems. Currently, typical microcontrollers provide about several hundred bytes of
RAMandtypicallylessthankBofFlashROM.Clockedbyaninternaloscillator,these
microcontrollers provide only a few million instructions per second (MIPS) of process-
ing power. Since the local application will consume most of the available resources, the
designers of configuration and management mechanisms must take care that there is not
too much overhead on the embedded system nodes. his requirement drives design deci-
sions where configuration data is compressed or even stored on a separate repository
outside the embedded network.
.
Use of standard software/hardware:
: Computers running standard Windows or Linux
operating systems do not provide guaranteed response times for programs, and most
hardware interfaces are controlled by the operating system. Since this might violate the
special timing requirements of an embedded real-time protocol, it is often not possible
to directly connect a configuration host computer to the fieldbus network without a gate-
way. Instead, a configuration tool must use some other means of communication, such
as standard communication protocols or interfaces like TCP/IP, RS, USB, or stan-
dard middleware like CORBA (Common Object Request Broker Architecture). Often,
.
(
Semi
)
