Embedded system

An embedded system (also English embedded system ) is an electronic calculator or computer , in a technical context involved is (embedded). The computer either takes on monitoring, control or regulation functions or is responsible for some form of data or signal processing, for example for encryption or decryption, coding or decoding or filtering.

Embedded systems perform the service - largely invisible to the user - in a multitude of application areas and devices, for example in medical technology devices , washing machines, aircraft, motor vehicles, refrigerators, televisions, DVD players, set-top boxes , routers , mobile phones or generally in consumer electronics devices . In the case of complex overall systems, it is usually a matter of networking a large number of otherwise autonomous, embedded systems (such as in vehicles or aircraft).

Embedded systems are often specially adapted to a task. For reasons of cost, an optimized, mixed hardware-software implementation is chosen. Such a construction combines the great flexibility of software with the performance of the hardware . The software is used to control the system itself as well as to interact with the outside world via defined interfaces or protocols (e.g. LIN bus , CAN bus , ZigBee for wireless communication or IP via Ethernet ).

Embedded system on a plug-in card with processor, memory, power supply and external interfaces

characterization

In individual cases, embedded systems can be based on hardware similar to that of workstation computers ( embedded PCs ). However, they are typically subject to very restrictive boundary conditions: minimal costs, low space, energy and memory consumption. Individual components such as the processor and main memory are often based on the further development of older components, which facilitates long-term usability and the procurement of spare parts. "Modern" embedded systems are often based on processor platforms that have little in common with the PC world, but are highly integrated in terms of peripheral modules and consume significantly less energy thanks to modern power-saving technologies.

For many applications, using an older processor architecture can help reduce costs. The architectures of the MCS-51 , Microchip-8Bit-PIC or Z80 series are still a very popular basis for embedded systems despite their age and known weaknesses. The reuse of program code and toolchains as well as the reluctance to complete redesigns “without necessity” are also marginal factors that should not be underestimated in addition to the pure material costs.

In an embedded system, the software often has to meet real-time requirements. As a rule, there are only greatly reduced resources compared to PC hardware, mostly without a hard disk, often without an operating system, keyboard or screen. A ROM or flash chip replaces mechanical storage components like a hard drive; Energy-saving processors manage without fans, because moving parts mean wear and tear and susceptibility to errors. If at all, there is usually only one keypad and the output - if provided - is realized by an LCD .

The software on such a device is called firmware . It is usually on a ROM , but more and more often on flash memory . In the case of a flash memory, there is the option of a firmware update without having to replace the chip. If only one ROM is available, the entire chip usually has to be replaced, sometimes the entire circuit.

Firmware components

The firmware essentially consists of three components.

Bootloader: Provides for loading the operating system and the application software. This also offers the option of updating the operating system and application software in the flash memory . This can be done either via a serial interface (RS232) or via Ethernet and IP. Well-known boot loaders for embedded systems are RedBoot or U-Boot.
operating system: This software part provides u. a. for multitasking, storage and file management (e.g. JFFS2) as well as for IP services such as TFTP , HTTP , SNMP and Telnet
Application software: This part contains the application-specific software. This is also known as application software .

In the case of small embedded systems, the three software parts can be combined.

Platforms

Embedded systems are built using many different CPU architectures ( 8051 , ARM , AVR , TI MSP430 , MIPS , PowerPC , 68000 / Coldfire , Intel x86 , 68HC12, C167 , Renesas M16C , H8S and various other 8/16/32 bit CPUs ) realized.

A subgroup of the architectures are the processor families (e.g. 8051, AVR, PIC16, ARM7, PowerPC 5xx, MIPS 4k, AMD AU1000, Intel Pentium M), in which different variants can be operated with the same development tools and debugging tools. Differences within a processor family are speed and, above all, the equipment with memory and peripheral modules.

A particularly flexible platform are highly integrated FPGA modules with which, on the one hand, different CPU architectures can be simulated (e.g. 68000 and PowerPC 405 on one chip), and on the other hand, well-parallel computing power without a processor - only using dedicated logic - is available can. In real applications, both approaches are often integrated in an FPGA as a SoC . Hard-wired hard macros such as the PowerPC cores in various Xilinx Virtex -FPGAs as well as flexibly configurable softcore processors such as Alteras Nios II , Xilinx's MicroBlaze , the Mico32 from Lattice or IP cores of a microcontroller such as PIC are used as processors or 8051.

operating system

Embedded PC Simatic Microbox PC 427B from Siemens on which the Windows XP Embedded operating system is installed.

Often no operating system is used in "small" systems.

If an operating system is used in embedded systems, it is usually a specialty operating system (examples: QNX , VxWorks , Nucleus , OSEK , OS-9 , RTEMS , ECOS ). Special so-called embedded versions of standard operating systems such as Linux (see Embedded Linux ), NetBSD or Windows ( 3.x , CE , XP Embedded , Automotive or Windows Embedded POSReady 2009 / POSReady 7 ) are now used. Applications often have soft or even hard real-time requirements , as described in more detail below. Special real-time operating systems or operating systems with appropriately adapted cores must be used for this.

Development environment, programming, tools

The software for program development, i.e. compiler , assembler and debugger (whereby hardware must also be used regularly for debugging), is usually offered by various manufacturers:

Semiconductor manufacturers interested in selling their processors and controllers, and
Software companies that specialize in such programs.

The software for embedded systems, the firmware, is usually generated using a cross compiler . This compiler runs on the development system (PC architecture), i.e. normally a different architecture from that of the target system. Many crosscompilers are not limited to a specific processor, but can generate machine code for an entire processor family, such as ARM7, PowerPC 8xx.

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

The software for embedded systems is increasingly being made with the help of model-based development, in which graphical models of the behavior are specified, which are then converted into C code by means of code generation .

The preferred programming language is generally C or C ++ , but there are also approaches such as OSGi for Java . Assembly language is used when time-critical or device driver functions are programmed primarily in interrupts , or when the operating system itself has to be adapted to a new environment or CPU. Above the operating system, assembler is more of a marginal phenomenon, but assembler is used more frequently in systems without an operating system and especially with massive memory restrictions. In safety-critical applications such as flight control computers, exotic languages such as Ada are also used in embedded systems - here, however, one must differentiate between the time-critical and the safety-critical application levels, for which different applications and programming languages may be responsible within the system. So-called model - based development with MATLAB / Simulink or ASCET is often used not only in the automotive industry . C code is automatically generated from the models, which in turn is compiled for the corresponding target processor.

The testing of software for embedded systems often takes place in early phases of development on the PC. For this, the environment of the application with which the embedded system communicates must often be simulated . This simulation is then called MiL ( Model in the Loop ) or SiL (Software in the Loop). If the software is implemented on the target hardware, it is referred to as HiL ( Hardware in the Loop ), and access to the test hardware from the PC usually takes place via a hardware emulator .

Software development

The software development for embedded systems is fundamentally different from that for desktop or PC systems, since in this case the focus is on the possibilities of the I / O input is. The functions for this are hardware-dependent and have to be developed anew for each system.

Debugging, troubleshooting

Debugging includes debugging both 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 to be tested in the system, i.e. on the target hardware. Traditionally, the actual controller has to be exchanged for the ICE hardware (a bond-out processor ). This allows the software to be developed comfortably and without further intervention in the target hardware. Since access to the periphery of the CPU is possible with the ICE, software and hardware errors can be distinguished and separated. In the past, a logic analyzer was required for this, which could emulate the target CPU as an additional option.

Nowadays, embedded CPUs already have a "narrow-gauge" ICE on board, so that the hardware ICE is not absolutely necessary. In contrast, the possibilities of the debugging software to influence the target CPU are limited. Complete monitoring of the CPU is not possible, but the costs are significantly reduced. If a fully developed ICE system costs up to six-digit euros for a 68000 derivative, the costs for such a “narrow-gauge” system are in the lower three-digit euro range. Usually an interface of the type JTAG is used. An alternative to Coldfire and 68000 derivatives is the Background Debug Module (BDM) interface from Motorola.

It is also available as a special debugging core in modern ARM architectures, controllers with Cortex-M3 core: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337e/DDI0337E_cortex_m3_r1p1_trm.pdf (Chapter 10… 13) This is a part of the microcontroller that is not necessary for the normal program sequence and is only built in for debugging. This debugging core can be addressed with debugging software via a JTAG or SWD adapter. This means that the processor can be stopped at any point in the program and the values of the registers or the memory can be viewed or changed. Step-by-step processing of the code for troubleshooting is also possible. The hardware required here is a JTAG or SWD adapter, which is often available for less than 100 €. The debugger software can range from fully functional freeware ( gdb + ddd , gdb + kgdb , Eclipse ) to professional software in the thousand euro range.

Alternatively, simulators are often used, which simulate the internal structure and the periphery of the microcontroller in software. When debugging, the “external” signals (keys, display) must be simulated “by hand”, whereby interrupts would have to be used that cannot be implemented in the simulator.

There are also developments based on Java for embedded systems . Based on the simpler platform change and the platform independence with the elimination of simulators (see OSGi and Embedded Java ).

The microcode interrupt lets the debugger work on the hardware instead of just the CPU. From the CPU standpoint, CPU based debuggers can then be used to test the electronics of the computer and diagnose errors if necessary. This ability was researched and developed on the PDP-11 (see Programmed Data Processor ).

The system test is carried out using hardware in the loop technology, in which the finished system is connected to special hardware that simulates the system's environment. In this way, the behavior of the system can be examined in detail with test cases.

history

The first prominent use of an embedded system was that of the Apollo Guidance Computer , which was developed by Charles Stark Draper together with the MIT Instrumentation Laboratory . Every flight to the moon had two of these systems that were used for control. The inertial guidance system was used both in the command module and in the lunar module (LEM, Lunar Excursion Module).

At the beginning of the Apollo project, this system was seen as one of the riskiest components of the project.

The first embedded systems but were already in the Minuteman - rocket used and produced in series. The application was a path-search system that enabled the missile to maneuver independently after one-time programming. With the fall in prices, the integrated circuits used gradually opened up to a wider range of applications.

The decisive feature of the Minuteman computer was that the way-finding algorithm could be programmed later, which meant that the missile could be deployed much more precisely. Another advantage was the rocket's self-test function for status queries and the fact that larger amounts of cables could be dispensed with in favor of weight.

Embedded Systems Design

The electronics form a microprocessor with appropriate peripherals or a microcontroller . Some more outdated systems still use general purpose mainframes or minicomputers .

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

integration: The more functionality the microcontroller used already contains, the fewer peripheral components are required to enable the connection to the required system interfaces (input / output). The fewer components a circuit board requires, the lower the space requirements for the conductor tracks and the signal transit times between the components. These considerations led to the fact that sufficient RAM and other peripheral functions are already provided on microcontrollers.
Hardware requirements: Depending on the application environment of the system, a wide variety of framework conditions can arise. When it comes to harsh environmental conditions such as heat and dust, the hardware must be robust, i.e. above all hermetic encapsulation . When it comes to more complex systems, industrial PCs are often a solution. When it comes to constant mechanical vibrations, plug connections must be saved or made particularly robust. Components with moving components such as hard disk drives or fans should be avoided as far as possible.
Power consumption: In many cases, embedded systems are powered by batteries. As with water meters, these are only exchanged in the calibration interval (5 years + runtime reserve). The long runtimes are achieved through special chip technologies (e.g. CMOS ) and measures in the software, such as sleep mode.
Real-time requirements: High availability and defined response times are frequently asked requirements for an embedded system and thus also for its operating system and software. For example, the electronically controlled brake or the airbag must react almost instantaneously in the millisecond range; exceeding the defined latency period cannot be tolerated. The simple and closed design as well as the use of special real-time operating systems make it possible to estimate the response times of the overall system as early as the development phase.
Operational safety: In contrast to PCs, many embedded systems run continuously. Errors and malfunctions, such as problems with electromagnetic compatibility (EMC), require special measures in the embedded system in order to guarantee a reliable restart. Microcontrollers are therefore equipped with a watchdog . This brings about a controlled restart in the event of irregularities in the process and thus ensures the availability of the embedded system without user intervention.
Unit price: The unit price depends on the development and manufacturing costs. In the case of large production quantities, a lot of effort is therefore made in the development for optimal resource consumption. In the case of small quantities, the material costs are less important. More expensive but more flexible components (e.g. FPGAs ) will reduce development time.
Development environment: See System Design Kit .

System start

All embedded systems have a start-up code that is run through after being switched on. Usually this deactivates the interrupts , calibrates the internal electronics , tests the computer ( RAM , ROM , CPU ) and starts the actual program code after everything has been successfully tested.

Many of these systems are ready to use within 100 ms. Even after a small power outage or a voltage fluctuation, these devices continue to run immediately, as the internal hardware skips the hardware and software self-test . However, due to possibly changed bits in the RAM, undefined system behavior occurs that avoids a circuit for voltage monitoring (Supply Voltage Supervisor, SVS or also called Brownout Detection). The SVS triggers a “correct” reset so that the system is completely initialized and the self-tests run through.

The duration of the system start can be seen in the vehicle electronics by the indicator lights that light up after switching on the ignition and go out again after a short time. With many devices, the system start means that switching on takes longer than with analog devices such as car radios .

Different types of architecture

Different software concepts are used. The reactive approach sums everything up, right down to the highly complex, window-based user interface of a ticket machine with a touchscreen.

Control loop

Control loops are used for control systems that carry out cyclical calculations based on input signals and send output signals (see control technology ); also known as time-controlled design (see Embedded Software Engineering ).

Reactive systems

Reactive systems process events that occur aperiodically, such as pressing a key, and initiate appropriate actions; referred to as event-driven design (see Embedded Software Engineering ).

user interface

Embedded systems often do not have their own connection for a display or input devices. However, indirect user communication can be provided via data interfaces. Network-compatible printers and other devices have a web interface or a serial interface through which all important configuration settings can be made via browser or terminal emulation.

Problems with the use of embedded systems

With the increased use of embedded systems in automobiles, another problem becomes noticeable: the number of systems is so high that the available space in a car is insufficient and the cabling effort increases. Therefore, several control functions are combined in one control unit ; made possible by powerful 32-bit microcontrollers. Memory protection mechanisms such as MPU or MMU , which ensure that the individual functions cannot influence each other, are generally still rather uncommon - the spread of 8/16 bit controller systems should not be underestimated. In this market segment, the maxim of minimizing electricity consumption and minimizing costs applies and therefore the principle of "only as much as necessary".

literature

Jürgen Teich, Christian Haubelt: Digital hardware / software systems - synthesis and optimization . Springer, Berlin / Heidelberg 2007, ISBN 978-3-540-46822-6 .
Joachim Wietzke: Embedded Technologies: From the driver to the graphics connection . Springer, Berlin / Heidelberg 2012, ISBN 978-3-642-23995-3
Jörg Wiegelmann: Software development in C for microprocessors and microcontrollers: C programming for embedded systems VDE Verlag 2011, ISBN 978-3800732616

Web links

Commons : Embedded Systems - collection of images, videos and audio files

Literature on the subject of the embedded system in the catalog of the German National Library