Image Processing Reference
In-Depth Information
TABLE .
Modularity Trade-Off Examples
Aspect
Pros
Cons
Reuse elements
Minimized development effort due
to reuse of HW/SW design (and
code)
Lower performance (footprint,
response time, power consumption,
etc.) due to increased overhead
Risk reduction
Design based on well-proven and
tested components
Integration of several components
can result in unclear/untested
behavior
Migration
Minimized effort to migrate to
other (newer) SW/HW versions
Lower performance due to
“wrappers” needed to maintain
system interfaces
Cost reduction
Lower cost due to second source
and larger volumes
(“standardized” components)
Added cost due to additional
resources required to support the
standardized components
27.8 Modularity
The main driving force behind a modular design is improved maintainability, i.e., how easily we can
modify the device in order to fix bugs, implement new functionality, upgrade to another SW/HW,
version, etc. his is achieved by a clear separation of system features into modules or components that
overlap in functionality as little as possible. These HW/SW modules are integrated into the device
via clearly defined interfaces, which provide an abstraction of the module, i.e., a separation of the
external communication with the module from its internal operations. his means that (in theory)
you are able to modify the module internally, or even replace it with another similar module, without
affecting how the rest of the device is operating or interacting with the module.
However, modularity comes at a cost as it places restrictions on the design, and care must be taken
to ensure that the interfaces between modules are sufficiently general, while adhering to the nonfunc-
tional requirements (response time, footprint, power consumption, etc.). Table . below illustrates
some typical aspects or goals of a modular design and their trade-offs.
As modularity does come at some cost, we have to balance the need for a highly modular design
with, on one hand the nonfunctional requirements, and on the other hand the products envisioned
life cycle. There is no need to pay the price for a highly modular system if you are going to change
it once every years. However, it can be quite tricky to foresee the maintenance need of industrial
products very accurately as it depends on large variety of aspects such as new user requirements,
deployment in unforeseen applications, and availability of the COTS components that make up the
design. Some form of modular design is therefore generally speaking a well-invested development
effort.
27.8.1 Levels of Modularity
What does a modular design really mean? Are not all modern embedded systems modular in some
sense, since they are built on standardized electronic components that you purchase and integrate
on a PCB? The answer is yes and no. Yes, the components are standardized and can be replaced
by another brand or type, but this does not automatically equate to a design that enables easy
modification, extensions, migration, or reuse of parts of the design.
There is always a value of standardizing on a given set of low-level components, but to achieve a
higher level of maintainability, you often need to raise the level of abstraction and divide the device
into a set of core system features that overlap in functionality as little as possible.
27.8.1.1 HW vs. SW Components
Standardizing on a given (set of) processors (CPU, MCU, DSP) of the same architecture has benefits
in terms of reduced training cost of engineers and facilitates porting of software. Reuse of printed
