Embedded software engineering
The term embedded software engineering is made up of the terms embedded systems (German " embedded systems ") and software engineering (German " software technology "). An embedded system is a binary digital system (computer system) that is embedded in and interacts with a surrounding technical system. The task of the computer system is to control, regulate or monitor the system in which it is embedded. Software engineering deals with the production of software, i.e. the development and operation of programs and the organization and modeling of the associated data structures.
What is special about the embedded systems is their capacity as a "universal system integrator". The technical systems are formed by interacting components. The high number of components, the growing complexity of the individual components and the overall system and, last but not least, the requirements of constantly improved systems make it necessary to equip the individual components and the interactions with more and more functions. Computer systems are the only technology available to implement and control complex interactions between individual physical systems.
Challenges of embedded software engineering
When developing software for embedded systems, developers are faced with special boundary conditions that must be met for correct functioning. This includes the coupling to physical processes, the associated requirements for reliability and the increasing number of distributed systems with high dynamics.
Coupling to physical processes
The physical processes with which the embedded systems are coupled and whose interactions are to be dealt with by the software force the system to adopt a predefined time behavior. Since the timing cannot be changed, for example with controlled motors, the embedded system must work in real time , i.e. its temporal behavior must be adapted to the surrounding technical system. A distinction is made between hard and soft real-time behavior. The differentiation takes place exclusively through the consequences that temporal misconduct can cause: If a misconduct represents a hazard to people and / or material, it must not occur and the system must meet the temporal conditions under all circumstances. This is known as a hard real-time system. If the incorrect behavior only produces a reduction in quality, it is referred to as a soft real-time system. Other adaptations to the physical system can relate, for example, to the maximum permitted power loss, for example due to the maximum available electrical power or the limitation of the generated heat, or the average energy consumption. In the case of battery-operated devices, for example, the average energy consumption determines the duration of use. Adjustments to the electrical values can usually only be achieved through joint hardware and software engineering (co-design).
Reliability requirements
The reliability requirements that are placed on embedded systems in particular relate to hardware and software quality. Software quality is the entirety of the features and characteristic values of a software product that relate to its suitability to meet specified or required requirements. Features include functionality, reliability, usability, efficiency, changeability and transferability. The reliability (English reliability ) is defined here as the probability that a system's defined function fully met within a specified period and under the expected operating conditions, ie is intact and there is no system failure. In the case of errors or faulty actions that reduce reliability, a distinction must be made between the faulty action (English error ), which leads to a later error, the faulty location in the device or program code, also known as an internal fault (English fault ), and the actual Misconduct, also referred to as failure effect or external failure (English failure ), can be distinguished. The rate of external errors is measured in FIT ( Failure in Time , number of errors occurring per 10 9 operating hours). The errors caused by software exceed the hardware rate by around 100 to 1000 without special measures. One of the main tasks of embedded software engineering is to reduce this rate to the required values.
Distributed systems with high dynamics
With an increasing number of systems, the number of (independent) electronic components is very high, ranging from a few 100 to over 1000 components. Developments such as smart sensors (sensors with built-in preprocessing, e.g. by microprocessors) or MEMS (microelectromechanical system) show that the penetration of a physical process with electronic components for measurement, control and regulation can be very extensive and that the separation of physical process / information processing cannot more can be sustained. The problems in the software development of such systems can be represented by two mostly required properties: On the one hand, such a distributed application should be robust, reliable and work in real time; on the other hand, the distributed application works to a high degree in parallel, and the overall system is usually also dynamic means the application has to adapt to the changing conditions. The combination of distribution, reliability and dynamic adaptation is a particular challenge.
Approaches to embedded software engineering
In addition to the algorithmic correctness of an application, one or more other conditions usually have to be met with embedded applications. Apart from the basic principles of software engineering, which are also used in the embedded area, additional methods can be used to meet these conditions. The design methods differ depending on the condition to be met.
Reference model for embedded systems
Figure 1 shows the general reference model of a non-distributed embedded system. The strong external bond with the help of actuators and sensors is characteristic; they represent the essential coupling to the technical environment in which the system is embedded. The user interface can be omitted, in this case it is a deeply embedded system. The reference architecture shows that embedded applications have a strong input / output (I / O) bond. Accordingly, hardware and software are designed to be I / O-dominant.
Design methods to meet time requirements
The real-time capability of a software application is the most common condition that must be met. The real-time capability relates to the reference model from Figure 1, which means that the system generally has to react in good time to external events. Timeliness consists in defining a maximum time after the occurrence of the event, at which the reaction must have occurred, and possibly also a minimum time after the event, before which the reaction must not occur. The latter is necessary, for example, if several reactions have to occur simultaneously in a possibly distributed application.
Timed design
To establish the coupling between environmental events and the embedded system, two methods are available: time-controlled design and event-controlled design. The time-triggered design assumes that there is a mostly periodically called part of the software in which the occurrence of events is determined. The implementation can take place, for example, by means of an interrupt request (IRQ) triggered periodically by a timer with an associated interrupt service routine (ISR). This cyclical part determines the presence of events and starts the corresponding reaction routine. The cycle time is based on the required maximum response time for this event and other times in the system. This design methodology results in a static design, in which all activities aimed at compile time (English compile time) must be known. The real-time capability of this design can be proven if all maximum processing times (English worst-case execution time, WCET ) and all maximum interruption-free times (English worst-case interrupt disable time, WCIDT) are known.
Event-driven design
In event-triggered design, the events themselves are assigned an interrupt request. This means that the associated service routines must at least partially be designed as interrupt service routines, and an interrupt priority management system must regulate the priorities when they occur simultaneously. The overall system is apparently less stressed because the event handling is only called when something is actually present. However, the system itself cannot be designed to be weaker than the time-controlled design, because real-time capability must be guaranteed. The system design of a (hard) real-time system must always follow the maximum load, not a medium one. Another negative aspect of the event-driven design is that the maximum defined event rate does not have to be adhered to automatically. Additional hardware measures are necessary if - for example, bouncing switches or sub-processes that work outside the specification - can exceed assumed event rates in order to maintain the functionality of the application.
Design methodology for distributed embedded systems with real-time capability
The timed design can be generalized to the effect that a synchronous system design is chosen. This system design corresponds to the most commonly used model of digital hardware: calculations are carried out by an (asynchronous) switching network and stored in flip-flops at the end of a clock cycle. Applied to the software design, this means that algorithmic computation and communication (before or after the computation) are carried out in an assumed time span and at the end of this time span all results are stored as input for the next time segment. The synchronous design methodology then results in a system architecture that corresponds to that of a complex, cooperating machine. For real-time-capable distributed systems, the communication time itself must be limited, which is guaranteed by special networks (e.g. TTP / C, Time-Triggered Protocol Class C or various real-time Ethernet standards). In the development itself, the assumption that the algorithmic processing takes place within a specified maximum time must then be proven ( WCET determination ). Synchronous languages that aid development are Esterel , Luster, and Signal. Timing Definition Language (TDL) can also be used to define the system behavior over time, especially in the case of distributed systems .
Design methods to meet energetic requirements
There are comparatively few software-based methods to meet energy-related or power loss-related requirements. The selection of a microcontroller based on its energetic properties or even a change to other programmable architectures such as field programmable gate arrays (FPGA) can have a significantly more energy-saving effect than pure software solutions. Three methods can be used within the software design to reduce energy consumption and power loss:
- The actual running time of the program per unit of time considered is designed to be as minimal as possible, and when the processor is idle, the operating state “sleeping” or similar is selected. This operating state (of the hardware) is characterized by the fact that many parts of the processor are switched off, which greatly reduces energy consumption. How extensively it can be switched off and how the processor is woken up can only be decided on a case-by-case basis and depends on the processor type, the ability to plan the application and so on.
- In another approach, the attempt is made to design the program in such a way that, if all time limits are adhered to, idle times that are as equal as possible (per considered time unit) are created. In the second step, the clock frequency of the processor (and thus also the operating voltage) can be adjusted so that there are no more idle times. This provides a uniformly operating design with minimized power dissipation. The ideal time unit, the sequence of which is optimized, is the super period (= smallest common multiple over all different periodic sequences in the system), but the adjustment of the clock frequency must be possible for each individual period.
- As an alternative or in addition, specialized compilers can also be used which deliver code that is particularly favorable in terms of energy. The need for electrical energy for different instructions is different, which can be used.
Individual evidence
- ^ Helmut Balzert: Textbook of software technology. Volume 1: Software Development. Spektrum Akademischer Verlag, Heidelberg 1996, 1998, 2001, ISBN 3-8274-0480-0 .
- ↑ Antonio González, Scott Mahlke, Shubu Mukherjee, Resit Sendag, Derek Chiou, Joshua J. Yi: Reliability: Fallacy or Reality? In: IEEE Micro 24 (6), pp. 36-45.
literature
- Shankar Sastry, Janos Szipanovitis, Ruzena Bajcsy, Helen Gill: Modeling & Design of Embedded Software. In: Proceedings of the IEEE 91 (1), 2003, ISSN 0018-9219 .
- Christian Siemers: A little history of time. In: Elektronikpraxis 43, 2007, pp. 42–43.