IT2354 Embedded System - Challenges in Embedded System

   Challenges in Embedded System?

ANS :

CHALLENGES IN EMBEDDED SYSTEM DESIGN

ü  How much hardware do we need?

-          How big is the CPU? Memory?

ü  How do we meet our deadlines?

-          Faster hardware or cleverer software?

ü  How do we minimize power?

-          Turn off unnecessary logic? Reduce memory accesses?

ü  Does it really work?

-          Is the specification correct?

-          Does the implementation meet the spec?

-          How do we test for real-time characteristics?

-          How do we test on real data?

ü  How do we work on the system?

-          Observability, controllability?

-          What is our development platform?

Ø  How much hardware do we need?

We have a great deal of control over the amount of computing power we apply to our problem. We cannot only select the type of microprocessor used, but also select the amount of memory, the peripheral devices, and more. Since we often must meet both performance deadlines and manufacturing cost constraints, the choice of hardware is important—too little hardware and the system fails to meet its deadlines, too much hardware and it becomes too expensive.

Ø  How do we meet deadlines?

The brute force way of meeting a deadline is to speed up the hardware so that the program runs faster. Of course, that makes the system more expensive. It is also entirely possible that increasing the CPU clock rate may not make enough difference to execution time, since the program’s speed may be limited by the memory system.

Ø  How do we minimize power consumption?

In battery-powered applications, power consumption is extremely important. Even in no battery applications, excessive power consumption can increase heat dissipation. One way to make a digital system consume less power is to make it run more slowly, but naively slowing down the system can obviously lead to missed deadlines. Careful design is required to slow down the noncritical parts of the machine for power consumption while still meeting necessary performance goals.

Ø  How do we design for upgradability?

The hardware platform may be used over several product generations or for several different versions of a product in the same generation, with few or no changes. However, we want to be able to add features by changing software. How can we design a machine that will provide the required performance for software that we haven’t yet written?

Ø  Does it really work?

Reliability is always important when selling products—customers rightly expect that products they buy will work. Reliability is especially important in some applications, such as safety-critical systems. If we wait until we have a running system and try to eliminate the bugs, we will be too late—we won’t find enough bugs, it will be too expensive to fix them, and it will take too long as well. Another set of challenges comes from the characteristics of the components and systems themselves. If workstation programming is like assembling a machine on a bench, then embedded system design is often more like working on a car—cramped, delicate, and difficult. Let’s consider some ways in which the nature of embedded computing machines makes their design more difficult.

■ Complex testing: Exercising an embedded system is generally more difficult than  typing in some data. We may have to run a real machine in order to generate the proper data. The timing of data is often important, meaning that we cannot separate the testing of an embedded computer from the machine in which it is embedded.

■ Limited observability and controllability: Embedded computing systems usually do not come with keyboards and screens. This makes it more difficult to see what is going on and to affect the system’s operation. We may be forced to watch the values of electrical signals on the microprocessor bus, for example, to know what is going on inside the system. Moreover, in real-time applications we may not be able to easily stop the system to see what is going on inside.

■ Restricted development environments: The development environments for embedded systems (the tools used to develop software and hardware) are often much more limited than those available for PCs and workstations. We generally compile code on one type of machine, such as a PC, and download it onto the embedded system. To debug the code, we must usually rely on programs that run on the PC or workstation and then look inside the embedded system.