Embedded software

The term Embedded Software Engineering consists of the concepts embedded systems (Eng. " Embedded Systems" ), and software engineering, (Eng. " software engineering "). An embedded system is a binary valued digital system ( computer system ), which is embedded in a surrounding technical system and interacts with the latter. In this case, the computer system has the task of the system into which it is embedded to control, regulate or monitor. The software engineering is concerned with the production of software, ie the development and operation of programs and the organization and modeling of the associated data structures.

The special feature of the embedded systems lies in their capacity as "universal system integrator ". The technical systems are thereby formed by interacting components. The high number of components, the growing complexity of the individual components and the overall system and not least the requirements constantly improved systems make it necessary to equip the individual components and the interactions with more and more functions. Computer systems here are the only available technology to implement complex interactions among individual physical systems and control.

• 2.1 Reference Model for Embedded Systems
• 2.2 Design methods for meeting time constraints 2.2.1 Time - aided design
• 2.2.2 Event -driven design

Challenges of Embedded Software Engineering

In the development of software for embedded systems developers are faced with special boundary conditions, the fulfillment of which is necessary for proper function. These include the coupling to physical processes, the associated demands on reliability and the increasing number of distributed systems with high dynamics.

Coupling of physical processes

The physical processes, with which the embedded systems are coupled and whose interactions are to be handled by the software, forcing the system to a predetermined time response. Since you do not have the time sequences, for example in controlled engines change, the embedded system must operate in real time, be adapted so in its temporal behavior of the surrounding technical system. A distinction is made between hard and soft real-time behavior. The differentiation is carried out exclusively by the consequences, which may cause a temporal misbehavior: Adjusts misconduct a hazard to human health and / or material is, it may not occur, and the system must meet the timing constraints under all circumstances. Which is referred to as the hard real-time system. Is generated only by the misconduct of a reduction in quality, it is spoken by a soft real-time system. Other adjustments to the physical system can affect, for example, the maximum allowable power dissipation, such as due to the electrical power or the limitation of the heat generated maximum available, or the mean energy intake. In the case of battery-operated devices such determines the average energy intake, the duration of use. Adjustments to the electrical values ​​can usually only be achieved through common hardware and software engineering ( co-design ).

Reliability requirements

The reliability requirements placed on embedded systems especially true concerning the hardware and software quality. Software quality is the totality of characteristics and characteristic values ​​of a software product that bear on its ability, determined to meet or implied needs. As features, functionality, reliability, usability, efficiency, maintainability and portability apply. The reliability ( reliability english ) here is defined as the probability that a system fully meets its defined function within a specified period and under the expected operating conditions, ie is intact and there is no system failure. With errors or erroneous actions that compromise the reliability, must be between the erroneous action (english error ), which leads to a later error of the defect in the device or program code, also known as internal errors (English default) referred to and the actual misconduct, also referred to as error effect or external fault (English failure), are distinguished. The rate of the external error ( failure in time, number of errors occurring per 109 operating hours) measured in FIT. The errors caused by software exceed the hardware rate without special measures to about 100 to 1000. Herein lies a fundamental task of embedded software engineering to reduce this rate to the required values ​​.

With an increasing number of systems the number of ( independent ) electronic components is very high, it moves between some 100 and more than 1000 components. Developments such as smart sensors (sensors with built-in pre-processing, for example, microprocessors) or MEMS ( microelectromechanical system) show that the penetration of a physical process with electronic components for measurement, control and regulation can be very large extent and that the separation physical process / information processing not more can be maintained. The problems in the software development of such systems can be represented by two of the most requested features: First, should such a distributed application to be robust, reliable and working in real time, on the other hand, the distributed application is using highly parallel, and the entire system is usually also dynamically, the ie, the application must adapt to changing conditions. The combination of distribution, reliability and dynamic adaptation is considered a special challenge.

Approaches to Embedded Software Engineering

In addition to the algorithmic correctness of an application one or more further conditions must be met for embedded applications usually. Apart from the basic principles of software engineering, which are also used in the embedded area for the application, additional methods can be used to meet these conditions. The design methods differ depending on the condition to be fulfilled.

Reference Model for Embedded Systems

Figure 1 shows the general reference model of a non-distributed embedded system. Characteristic strong outer binding is using actuators and sensors; they provide the essential link is to the technical environment in which the system is embedded. The user interface can be omitted, in which case it is a deeply embedded system (English deeply embedded system). The reference architecture shows that embedded applications a strong input-output ( Input/Output-, I/O- ) have binding. Accordingly, hardware and software are / running strong I O - dominant.

Design methods for meeting time constraints

The real-time capability of a software application is the most common condition that must be fulfilled. The real-time capability refers to the reference model of Figure 1, that is, the system must react in time to events in general from outside. The timeliness is that maximum time is defined by the event occurs, at which the reaction must have occurred, under certain circumstances, a minimum time after the event, before the reaction must not occur. The latter is necessary, for example, if several reactions must occur simultaneously within a single application may be distributed.

Time - controlled design

To establish the link between environment events and the embedded system, two methods are available: time - controlled design and event -driven style. The time - controlled design (English time-triggered design) assumes that there is a usually periodically called partial in the software, in which the occurrence of specific events is detected. The implementation can be done, for example by a periodically triggered by timer interrupt request ( IRQ) with associated interrupt service routine ( ISR). This cyclical running part notes the existence of events and starts the corresponding reaction routine. The cycle time depends on the required maximum response time for this event as well as other times of the system. This design methodology results in a static design where all activities at compile time (English compile time ) must be known. The real-time capability of this design can be proven if all maximal processing times (english worst- case execution time, WCET ) and all maximal uninterrupted periods (, WCIDT english worst-case interrupt disable time) are known.

Event -driven design

In event - driven design (English event -triggered design) is assigned to the events themselves, an interrupt request. This means that the associated service routines must be at least partially designed as interrupt service routine, and an interrupt priority management must govern the priorities for a simultaneous occurrence. The overall system is thus seemingly less burdened, because the event handler is only called when actually there is something. However, the system itself can not be designed to be weaker compared to the time - driven design, because the real-time capability has to be guaranteed. The system configuration of a (hard) real-time system has to always follow the maximum load, not an average. Negative on the event-driven design is also that the maximum defined event rate must not be automatically maintained. In addition, hardware measures are required if - can be exceeded assumed event rates to obtain the working ability of the application - for example by bouncing switch or sub-processes that operate outside of the specification.

Design methodology for distributed embedded systems with real -time capability

The time - controlled design can be generalized to the extent that a synchronous system design is selected. This system design corresponds to the most widely used model of digital hardware: Calculations are performed by an (asynchronous ) switching network and stored at the end of a time clock in flip-flops. Transferred to the software design, this means that algorithmic computation and communication may be performed (before or after the calculation ) in an accepted time span and all results are stored as input for the next period at the end of this period. The synchronous design method then provides a system architecture corresponding to a complex co-operating machines. For real-time distributed systems, the communication time must be self- limited, which is by special networks guarantees (for example, TTP / C, Time-Triggered Protocol Class C or various real-time Ethernet standards ). In the development itself then does the assumption that the algorithmic processing is carried out within a specified maximum time, can be detected ( WCET determination). Synchronous languages ​​that support the development, are Esterel, Lustre and Signal. For the temporal definition of the system behavior, especially in distributed systems, including timing Definition Language ( TDL) offers itself.

Design methods for meeting energy requirements

To meet energy loss or performance targets exist comparatively little software-based methods. The selection of a microcontroller based on the energetic properties or even switching to other programmable architectures such as Field Programmable Gate Arrays ( FPGA) can here saves much more energy act as a pure software solution. Within the software design three methods for reducing energy demand and the power dissipation can be used: