Embedded systems cover a wide range of computing needs from single-function microcontroller units (MCU) in microwave ovens to large multiprocessor distributed systems with terabytes of storage in data acquisition systems. I will attempt to answer three questions about embedded systems: what is an embedded system, what are examples of embedded systems and what are some of their design issues?
Wikipedia defines an embedded system as: “a computer system designed to perform one or a few dedicated functions often with real-time computing constraints. It is embedded as part of a complete device often including hardware and mechanical parts. By contrast, a general-purpose computer, such as a PC, is designed to be flexible and meet a wide range of user needs.”
The defining characteristic of an embedded system is purpose—not platform, peripherals or operating environment.
Embedded systems might have no user interactions. Such systems are referred to as headless, having no display, keyboard or buttons. An automobile's engine controller is a perfect example of a headless system.
But many embedded systems have significant user interactions. A portable instrument might have a two line display and keypad. Network routers use a Web browser for configuration and status. Process control systems, such as an automated manufacturing system, can have several dedicated workstations.
There is also a constraint of whether the systems should be real-time or not. A real-time system is one that has the requirement of handling a situation in an allotted unit of time. For example, an anti-lock brake system needs to execute its functions in time to prevent the wheels of the car from locking up—a very important action indeed.
Embedded systems start in size and complexity from a simple microcontroller unit—a system on a chip (SOC) controller—on circuit boards the size of a USB flash drive. The smallest MCUs handle a single function such as opening and closing a door lock. Larger systems use single board computers (SBCs), which have additional off-chip resources. A WiFi router is a good example of this. The largest embedded systems, like radar or image processing systems, have multiple processors and are often interconnected with many subsystems.
Recently I was part of a team developing one of these larger systems. It was a multi-spectral remote sensing system which gathered images for analysis and merged other collected data directly into the metadata of the images. Essentially, these images became their own libraries of information.
This system involved a high-end camera, an SBC unit, a real-time controller, a PowerPC as the front-end and data merging subsystem and an additional PC for file storage. Needless to say, it was highly complex.
There were several issues that arose during development. The first question was what operating systems to use on the various subsystems. Linux was the easy choice for the file server. Its jobs were to receive data, write them to disk and communicate over USB. All three areas are well supported by Linux. Additionally, being a PC, the OS configuration issues were minimal.
The question became more difficult when looking at the PowerPC subsystem. The answer was very complex since within this question were many other questions to be answered before a solution could be chosen.
In this case, the vendor supplied a Linux solution but it needed to meet performance requirements. To test, a series of benchmarks were developed and used to characterize its performance and to isolate software constraints from hardware limits. The vendor solution met the basic requirements and was another easy choice. This allowed the project to benefit from many other Linux resources.
The second question was, of these subsystems, what situations might justify additional embedded solutions? This would add further complexity to the already large system, but it is often asked when using PC-like solutions for real-time systems. The major problem with a PC and a high level OS like Linux or Windows is the latency they present that is not found in real-time systems. An additional problem is the lack of hardware timing resources.
A common requirement in embedded systems is the ability to timestamp events to microsecond accuracy. A good solution is to use an input capture timer which can acquire the time of an external event. A PC does not have this type of timer. It requires additional hardware in the form of a timer card or an embedded processor.
A timer card must either supply its own device drivers or it must be custom coded in order for the application to be able to use the card. An embedded processor requires bringing up its basic environment including its drivers and then development of its firmware, the code that runs its core functions. Further, the processor needs to be integrated so that it can communicate properly.
There are many processor cards available that include an OS and a timer. We chose one that came with its OS, timer and communications preloaded. It had extra functionality that added to the overall resources of the subsystem.
As described, embedded systems vary greatly and the complexity of the above large system was greatly reduced for the purposes of easy explanation. The variety and utility of embedded systems has integrated them so thoroughly into our everyday lives that they are often overlooked. We can easily see how embedded systems are applicable for use in projects as involved as those done by NASA, but how about that television remote or that new dishwasher?