Embedded system

The term embedded system ( also English embedded system) means an electronic calculator or computer that is integrated into a technical context ( embedded). It takes the computer either monitoring, control or control functions or is responsible for a form of data and signal processing, for example, when encryption or decryption, encoding or decoding or filtering.

Embedded systems do - largely invisible to the user - the service in a variety of applications and devices, such as devices of medical technology, washing machines, aircraft, motor vehicles, refrigerators, televisions, DVD players, set -top boxes, routers, mobile phones or widely used in consumer electronics devices. In the case of complex overall systems are usually made of a cross-linking a variety of otherwise autonomous, embedded systems (eg, in vehicle or aircraft ).

Often embedded systems are specially adapted to a task. An optimized, mixed hardware - software implementation is chosen for cost reasons. It unites such a design, the flexibility of software with the performance of the hardware. The software serves both to control of the system itself, as well as optionally to interact with the system to the outside world via defined interfaces or protocols (e.g., LIN bus, CAN bus, ZigBee wireless communication or IP over Ethernet).


Embedded systems can, in individual cases, on similar hardware to workstation based (so-called embedded PCs). Typically, however, they are subject to debilitating conditions: minimum cost, low space, energy, and memory consumption. Individual components such as processor and memory are often based on further developments of older components, which facilitates the long-term usability and spare parts. "Modern " embedded systems are often based on processor platforms that have little in common with the PC world, but are highly integrated with respect to the peripheral modules and by modern power management techniques use much less energy.

In many applications, the use of an older processor architecture can help reduce costs. Thus, the architecture of the MCS-51, Microchip PIC or Z80 series are despite their age and known weaknesses still a very popular base for embedded systems. The reuse of code and toolchains as well as the fear of complete redesigns " needlessly " in this context are also not to be underestimated edge factors in addition to purely material costs.

In an embedded system, software often must meet real time requirements. As a rule exist, compared with PC hardware, only greatly reduced resources, mostly without a hard drive, often without an operating system, keyboard or monitor. A ROM or flash memory chip replaces mechanical components such as a hard disk; low-power processors come without a fan, because moving parts mean wear and error-prone. If anything, then there is usually only a keypad, and the output is - if provided - realized by an LCD.

The software on such a device is called firmware. It is usually on a ROM, but more frequently on flash memory. In the case of a flash memory is the possibility of a firmware update, the chip must be replaced without. Is a ROM exists, the whole chip must usually be replaced, and sometimes also the entire circuit.

Firmware components

Consists essentially of three components, the firmware.

For small embedded systems, the three software components can be combined.


Embedded systems are through many different CPU architectures ( 8051, ARM, AVR, TI MSP430, MIPS, PowerPC, 68K/ColdFire, Intel x86, 68HC12, C167, Renesas M16C, H8S and various other 8/16/32-Bit-CPUs ) realized.

A subset of the architectures are the processor families, such as 8051, AVR, PIC16, ARM7, 5xx PowerPC, MIPS 4k, AMD Au1000 processor, Intel Pentium M, where different variants with the same development tools and debugging tools can be operated. Differences within a processor family is speed and most of all equipment with memory and peripheral devices.

A particularly flexible platform are highly integrated FPGA devices, which on the other hand also good parallel computational power without processor to a different CPU architectures reproduce ( 68k and PowerPC 405 on a chip, for example) - can run - only by logic. Today both approaches are integrated in an FPGA SoC in real-world applications often. The concrete contains a processor, both hard-wired hardware macros such as the PowerPC cores in various Xilinx Virtex FPGAs as well as a flexible configurable soft-core processors such as the Altera Nios II, Xilinx MicroBlaze, the Mico32 Lattice or IP cores of a microcontroller like PIC or 8051st

Operating system

For " small " systems often no operating system is used.

If an operating system is used, the reaction is mostly in embedded systems with very specialized operating systems ( QNX, VxWorks, Nucleus, OSEK, OS -9, RTEMS, ECOS, etc.). Also special embedded versions of the standard operating systems such as Linux ( see embedded Linux), NetBSD, or Windows (CE, XP Embedded, Automotive, Embedded for POS) find now very popular. Often one uses configurations with hard / soft real-time requirements, as described in more detail below. For this special real-time operating systems or operating systems must be used with adapted seeds.

See also the list of operating systems for embedded systems.

Development environment, programming, tools

The software to program development, ie compiler, assembler and debugger (where regularly and hardware must be used when debugging ) is usually offered by various manufacturers:

  • Semiconductor manufacturers, who are interested in the sale of its processors and controllers, and
  • Software companies that specialize in such programs.

The software for embedded systems, the so-called firmware, is usually generated via a cross compiler. This compiler is running on a different architecture (usually on a PC architecture ) than that of the target system. These cross compiler are not usually limited to a specific processor, but can generate machine code for a whole family of processors, such as ARM7, PowerPC 8xx.

Some manufacturers also offer system design kits that contain a prototype board with the processor in question together with a set of software development kit and documentation for hardware and software.

Increasingly, the software for embedded systems is carried out by means of model-based development, are specified in the graphical models of behavior, which are then transferred by means of code generation in C code.

Preferred programming language is generally C or C , but also for Java, there are approaches such as OSGi. Assembly language is used when time-sensitive or device driver functions are programmed primarily in interrupts, or if the operating system has to be adapted to a new environment or CPU itself. Above the operating system assembler is more of a side issue, but assembler is more common in systems with no operating system and especially with massive memory restrictions apply. In safety- critical applications such as in flight control computers even more exotic languages ​​like Ada are used in embedded systems - but you have to differentiate between the time-critical and safety-critical application levels, may be responsible for the possibly different within the system applications and programming languages ​​here. Frequently not only in the automotive industry is the so-called model-based development with MATLAB / Simulink or ASCET application. From the models C code is automatically generated, which in turn is compiled for the appropriate target processor.

The testing of software for embedded systems often takes place in early stages of development on the PC. For this often has the environment of the application, with communicating the embedded system to be simulated. This simulation is, then MiL ( Model in the loop) or SiL ( Software in the Loop ). If the software is implemented on the target hardware, one speaks on the other hand of HIL ( Hardware in the Loop ), the access to the hardware test from the PC is done usually via a hardware emulator.

Software Development

The development of software for these systems is fundamentally different from that of, for example, desktop or PC systems. In contrast to this, the software developer for embedded systems usually have to deal with even the possibilities of Ein-/Ausgabe. The features of this are very hardware dependent and generally to develop new for each system. See also Embedded Software Engineering.

Debugging, troubleshooting

Debugging includes both debugging the software and the integrated system. For Software Testing an "in - circuit emulator " (ICE ) can be used, a combination of program and hardware that allows the software " in the system", that is, to test for the target hardware. To do the actual controller against the ICE hardware ( a so-called " bondout chip " ) to be replaced. This allows the software comfortably without developing further interventions in the target hardware. Since accesses to the periphery of the CPU are possible with the ICE, can be so different software hardware failures and disconnect. Formerly a logic analyzer was needed to who could emulate as an additional option, the target CPU.

Today's embedded CPUs have typically been a " narrow gauge " ICE on board, so that the hardware -ICE is not necessarily required. For the action possibilities of debugging software are restricted significantly on the target CPU. A complete monitoring of the CPU is not possible, but the costs are considerably reduced. The price of a full-fledged ICE system for example, a 68k - derivative up to a 6-digit euro amount, the cost of such a " narrow gauge " system frequently in the lower three - digit euro range. Here is usually an interface of type " JTAG " used. ( Especially for ColdFire and 68K derivatives there is an interface, the " Background Debug Module", BDM, called that was used before the JTAG interfaces from Motorola a long time. Again, the costs are lower by almost three orders of magnitude. )

Alternatively, if you do not have ICE available, often use simulators which simulate the internal structure and the peripherals of the microcontroller in software. Here, however, must in debugging the "external" signals (keys, display etc. ) "by hand" are simulated, which usually interrupts would have to be used which can not be realized in the simulator normally.

Meanwhile, there are also developments in embedded systems based on Java technology. Reasons include the possibility of simpler platform change or the platform independence and the absence of simulators (see OSGi and embedded Java).

The microcode interrupt lets the debugger on the hardware work on the otherwise only the CPU is operating. From the viewpoint of the CPU of CPU-based debuggers can then be used to test the electronic system of the computer and, if appropriate, to diagnose faults in the latter. This ability has been explored in the PDP -11 ( see Programmed Data Processor) and developed.

The test system is performed using the so-called hardware - in -the-loop technique in which the finished system is connected to a special hardware that simulates the environment of the system. In this way the behavior of the system with the test cases can be analyzed in detail.


The first system was the remarkable modern embedded Apollo computer guidance, which was developed by Charles Stark Draper with MIT Instrumentation Laboratory. Each flight to the moon had two of these systems, which were used for control. The inertial guidance system was used in both the command module and the lunar module (LEM, Lunar Excursion Module ).

At the beginning of the Apollo project, this system was just considered one of the riskiest components of the project.

The first embedded systems, however, were already used in the Minuteman missile and produced as a result of mass production. The application was a way search system after a single programming enabled the rocket an independent maneuvering. The integrated circuits used were after some time, thanks to mass production, affordable for everyone and thus made available.

The crucial property of the Minuteman computer was that you could program the way - find algorithm later, so you could use the rocket is much more precise. Another advantage was the self-test function of the missile in for your status and that you could forego large quantities of cables in favor of the weight.

Design of Embedded Systems

The electronics is usually a microprocessor with appropriate peripherals or microcontroller. Some larger, mostly outdated systems use general-purpose mainframes or minicomputers.

The following aspects play a role in design decisions of embedded systems:


All embedded systems have a start-up code that is executed after power on. Normally, this disables the interrupts, calibrates the internal electronics, testing computer (RAM, ROM, CPU, ), and starts the actual program code, after all has been successfully tested.

Many of these systems are operational within 100 ms. Even after a small power failure or voltage fluctuation, these devices immediately run further, as the internal hardware then skips the self test of the hardware and software and continues to work directly. Here, however, sometimes occurs through possibly changing bits in the RAM on undefined system behavior, which avoids a circuit for voltage monitoring (Supply Voltage Supervisor SVS or brownout detection called ). SVS triggers a "right" reset, so that the system is fully initialized and, indeed, through the self-test.

The duration of the startup is evident, for example in automotive electronics to control lights that light up when the ignition and go off again after a short time. The system start leads many devices to the fact that the switching takes longer than for analog devices, such as car radios.

Different types of architecture

There are various software application concepts. In particular, the first concept is, however, at best suitable for very simple embedded systems. The reactive approach in turn holds together really anything else to highly complex, Window- based user interface of a ticket vending machine with touch screen:

Control loop

Control loops are used for control systems, the cyclic to make calculations based on input signals and send output signals ( see control engineering ). Also referred to as time - controlled design (see Embedded Software Engineering ).

Reactive Systems

Reactive systems process aperiodically occurring events, such as pressing a button and initiate appropriate actions. Also referred to as an event -driven design (see Embedded Software Engineering ).

User interface

Embedded systems often do not have their own user interface. However, an indirect user communication can be provided via data interfaces by about network-enabled printers and similar devices usually have a web interface through which you can make all the important configuration settings via a browser. This is useful for applications where systems have not have a display or user interface via which the system can communicate with the user.

Problems with the use of embedded systems

With the increased use of embedded systems in automobiles currently, another issue to light. The number of systems is now so high that the available space is not enough in a car for more controls. In addition, the cabling increases. That's why you go to new controls over to combine multiple control functions in a control unit. This is possible through new, powerful 32 -bit microcontroller. Memory protection mechanisms such as MPU or MMU, which ensure that the individual functions can not influence each other, but in general to be rather unusual - also should not be underestimated the spread of 8/16-Bit-Controllersystemen. In this market segment, the maxim of the power consumption and the minimization of costs, and therefore the principle of " only as much as necessary."