November 2016
40
I
ndustrIal
C
ontrol
& C
omputIng
tion can be implemented when replacing the
smaller FPGA. This allows the reduction of
hardware cost in case of an optimization and
the new function can be implemented with
the right number of logic gates. Being very
expensive, FPGAs are primarily used in the
prototype phase of a product ahead of any
cost optimization.
Application-specific devices are sometimes
referred as ASSP (application-specific stan-
dard products). They normally have a high
degree of integration with some or many
dedicated functions required for a specific
application. In contrast to an ASIC (appli-
cation-specific IC), ASSPs can be used for a
wider range of products in the dedicated mar-
ket segment. Nevertheless many ASSPs often
have an important commercial focus. They
need to be as cheap as possible, but with every
piece of flexibility or function enhancement
their price increases. With the focus on a
specific function and only the required logic,
ASSPs do not generally provide that much
flexibility. Based on such devices a traditional
PCB design may result in a complex board
integrating many different components as
indicated in figure 3. This is directly followed
by a huge amount of effort for the develop-
ment, testing and certification, and last but
not least for system support and maintenance
during the product lifetime.
ASICs on the other hand provide with their
specific function set the ideal solution for a
certain device. By definition an ASIC is spec-
ified and developed by a particular company
for its own products. ASICs are normally not
sold to other companies. Seen from the devel-
opment perspective it takes a long time and
a huge amount of money to develop such
devices today. Thus ASICs are the right choice
only for very high volumes.
Another solution in the sense of multi-pro-
tocol can be seen as a combination of the
two mentioned solutions. A module-based
approach in an automation product foresees
the exchange of rather small communication
modules when another communication pro-
tocol is required. Using small modules from
an external provider to modify the high-
er-level protocol of a system only partially
follows the idea of an unmodified hardware:
the more complex main system remains
unchanged while only the less complex mod-
ule is changed. This is a really good approach
for prototype systems and low-volume prod-
ucts. But having regard to legacy products
which cannot be changed, a module approach
can easily allow the adaptation of a legacy
system to a new communication protocol.
Another advantage of the module approach
is completely separating the application side
from the communication hardware and stack
software. As communication modules are rel-
atively expensive, they are at a big commercial
disadvantage. Mechanically they sometimes
need more space and volume (area x height
of module plus its connector) to be integrated
into a system. This is often the module-killer
criterion for a small product with a narrow or
flat housing.
As described, all these approaches to
multi-protocol have their own strength and
are a good choice under certain conditions
or in certain product phases (prototype, leg-
acy product extension). But looking into the
detail, all solutions have a common disadvan-
tage: pricing, especially under high volume
conditions!
How to escape from this conflict? Let us now
think about an ideal solution which allows the
simple product structure in figure 3 compared
with the traditional approach. First our solu-
tion should be based on a single-chip device
with more or less the characteristics of a small
communication module provided by a single
and well-defined hardware connection with
different interface options. The application
processing can be seen as an option in case
Figure 4. Block diagram R-IN Engine
Figure 3. Traditional vs. ideal solution
Figure 2. Industrial Ethernet protocol layers
