Software engineering for real time systems cooling ebook

Hard, slow systems do not fall into any particular size category though, many, as with process controllers, are small. An illustrative example of such an application is an anti-aircraft missile-based point-defense system for fast patrol boats. Here, the total reaction time is in the order of 10 seconds. However, the consequences of failing to respond in this time frame are self-evident.

Larger systems usually include comprehensive, and sometimes complex, human-machine interfaces HMI s. Such interfaces may form an integral part of the total system operation as, for instance, in integrated weapon fire-control systems.

Fast operator responses may be required, but deadlines are not as critical as in the previous cases. Significant tolerance can be permitted in fact, this is generally true when humans form part of the system operation. HMI software tends to be large and complex. Frequently, such software is large and complex. Applications like these may be classified as information processing IP systems. It is clear that the fundamental difference between real-time and others such as batch and interactive systems is timeliness.

However, this in itself tells us little about the structure of such computer systems. So, before looking at modern real-time systems, it's worth digressing to consider the setup of IT-type mainframe installations.

While most modern mainframe systems are large and complex and may be used for a whole variety of jobs they have many features in common. In the first case, the essential architectures are broadly similar; the real differences lie in the applications themselves and the application software.

Second, the physical environments are usually benign ones, often including air conditioning. Peripheral devices include terminals, PCs, printers, plotters, disks, tapes, communication links, and little else. Common to many mainframe installations is the use of terabytes of disk and tape storage. The installation itself is staffed and maintained by professional data processing DP personnel. It requires maintenance in the broadest sense, including that for upgrading and modifying programs. In such a setting, it's not surprising that the computer is the focus of attention and concern.

By contrast, real-time systems come in many types and sizes. The largest, in geographical terms, are telemetry control systems Figure 1. Such systems are widely used in the gas, oil, water, and electricity industries. They provide centralized control and monitoring of remote sites from a single control room. Smaller in size, but probably more complex in nature, are missile control systems Figure 1. Many larger embedded applications involve a considerable degree of complex man-machine interaction.

Typical of these are the command and control systems of modern naval vessels Figure 1. Figure 1. And, of course, one of the major application areas of real-time systems is that of avionics Figure 1. On the industrial scene, there are many installations that use computer-based standalone controllers often for quite dedicated functions.

Applications include vending machines Figure 1. These examples differ in many detailed ways from DP installations, and such factors are discussed next. There are, though, two fundamental points. First, as stated previously, the computer is seen to be merely one component of a larger system. Second, the user does not normally have the requirements — or facilities — to modify programs on a day-to-day basis.

In practice, most users won't have the knowledge or skills to reprogram the machine. Embedded systems use a variety of hardware architectures or platforms , as shown in Figure 1. Many are based on special-to-purpose that is, bespoke designs, especially where there are significant constraints such as:. The advantage of bespoke systems is that products are optimized for the applications. Unfortunately, design and development is a costly and time-consuming process. A much cheaper and faster approach is to use ready-made items, a commercial off-the-shelf COTS buying policy.

Broadly speaking, there are two alternative approaches:. Many vendors offer single-board computer systems, based on particular processors and having a wide range of peripheral boards. In some cases, these may be compatible with standard PC buses such as PCI peripheral component interconnect. For embedded applications, it is problematic whether boards from different suppliers can be mixed and matched with confidence. However, where boards are designed to comply with well-defined standards, this can be done generally without worry.

One great advantage of this is that it doesn't tie a company to one specific supplier. It is especially important to developers of military and similar systems, as robust, wide-temperature range boards are available. It is essentially a PC but with a different physical construction, being based on stackable circuit boards it gets its name from its PC roots and the number of pins used to connect the boards together, that is, However, an alternative to the board solution is to use ready-made personal computers.

These may be tailored to particular applications by using specialized plug-in boards for example, stepper motor drives, data acquisition units, and so on.

If the machine is to be located in, say, an office environment, then a standard desktop computer may be satisfactory.

However, these are not designed to cope with conditions met on the factory floor, such as dust, moisture, and so on.

In such situations, ruggedized, industrial-standard PCs can be used. Where reliability, durability, and serviceability are concerned, these are immensely superior to the desktop machines. Embedded computers are defined to be those where the computer is used as a component within a system, not as a computing engine in its own right. This definition is the one that, at heart, separates embedded from non-embedded designs note that, from now on, "embedded" implicitly means "real-time embedded".

Environmental factors may, at first glance, seem to have little bearing on software. Primarily, they affect the following:. But these, to a large extent, determine how the complete system works — and that defines the overall software requirements. Consider the following physical effects:. The temperature ranges commonly met in embedded applications are shown in Figure 1.

Electronic components aren't usually a problem. Items such as terminals, display units, and hard disks are the weaknesses. As a result, the embedded designer must either do without them or else provide them with a protected environment — which can be a costly solution.

When the requirements to withstand shock, vibration, and water penetration are added, the options narrow. For instance, the ideal way to reprogram a system might be to update the system using a flashcard. But if we can't use this technology because of environmental factors, then what?

Size and weight are two factors at the forefront in the minds of many embedded systems designers. For vehicle systems, such as automobiles, aircraft, armored fighting vehicles, and submarines, they may be the crucial factors.

Not much to do with software, you may think. However, suppose a design requirement can only be met by using a single-chip micro learn in Section 1. Additionally, suppose that this device has only bytes of random-access memory RAM. So, how does that affect our choice of programming language?

The electrical environments of industrial and military systems are not easy to work in. Yet most systems are expected to cope with extensive power supply variations in a predictable manner. To handle problems like this, we may have to resort to defensive programming techniques Chapter 2 , The Search for Dependable Software. Program malfunction can result from electrical interference; again, defensive programming is needed to handle this.

A further complicating factor in some systems is that the available power may be limited. This won't cause difficulties in small systems. But if your software needs 10 gigabytes of dynamic RAM to run in, the power system designers are going to face problems. Let's now turn to the operational environmental aspects of embedded systems.

Normally, we expect that when the power is turned on, the system starts up safely and correctly. It should do this every time and without any operator intervention.

Conversely, when the power is turned off, the system should also behave safely. What we design for are "fit and forget" functions. In many instances, embedded systems have long operational lives, perhaps between 10 and 30 years. Often, it is necessary to upgrade the equipment a number of times in its lifetime. So, the software itself will also need upgrading. This aspect of software, its maintenance, may well affect how we design it in the first place.

All required responses are time-critical although these may vary from microseconds to days. Therefore, the designer should predict the delivered performance of the embedded system. The situation is complicated because there are two distinct sides to this issue — both relating to the way tasks are processed by the computer.

Case one concerns the demands to run jobs at regular, predefined intervals. A typical application is that of closed-loop digital controllers having fixed, preset sampling rates. This we'll define to be a "synchronous" or "periodic" task event synchronous with a real-time clock — Figure 1. Case two occurs when the computer must respond to generally external events that occur at random "asynchronous" or "aperiodic".

And the event must be serviced within a specific maximum time period. Where the computer handles only periodic events, response times can be determined reasonably well. This is also true where only one aperiodic event drives the system a rare event , such as in Figure 1. When the system has to cope with a number of asynchronous events, estimates are difficult to arrive at. However, by setting task priorities, good estimates of worst-case performance can be deduced Figure 1.

As shown here, task 1 has higher priority than task Where we get into trouble is in situations that involve a mixture of periodic and aperiodic events — which are usually in real-time designs. Much thought and skill are needed to deal with the response requirements of periodic and aperiodic tasks especially when using just one processor.

All systems go wrong at some time in their lives. It may be a transient condition or a hard failure; the cause may be hardware or software or a combination of both. It really doesn't matter; accept that it will happen. What we have to concern ourselves with are:. Because a system can tolerate faults without sustaining damage doesn't mean that such performance is acceptable. Nuisance tripping out of a large piece of plant, for instance, is not going to win many friends.

All real-time software must, therefore, be designed in a professional manner to handle all foreseen problems, that is, "exception" handling an exception is defined here to be an error or fault that produces program malfunction, see Chapter 2 , The Search for Dependable Software. It may originate within the program itself or be due to external factors.

If, on the other hand, software packages are bought in, their quality must be assessed. Regularly, claims are made concerning the benefits of using Windows operating systems in real-time applications.

Yet users of such systems often experience unpredictable behavior, including total system hang up. Could this really be trusted for plant control and similar applications? In other situations, we may not be able to cope with unrectified system faults. Three options are open to us. In the first, where no recovery action is possible, the system is put into a fail-safe condition. In the second, the system keeps on working, but with reduced service.

This may be achieved, say, by reducing response times or by servicing only the "good" elements of the system. Such systems are said to offer "graceful" degradation in their response characteristics. Finally, for fault-tolerant operations, full and safe performance is maintained in the presence of faults. The range of devices that interface to embedded computers is extensive. It includes sensors, actuators, motors, switches, display panels, serial communication links, parallel communication methods, analog-to-digital converters, digital-to-analog converters, voltage-to-frequency converters, pulse-width modulated controllers, and more.

Signals may be analog DC or AC or digital; voltage, current, or frequency encoding methods may be used. In anything but the smallest systems, hardware size is dominated by the interfacing electronics. This has a profound effect on system design strategies concerning processor replication and exception handling.

When the processor itself is the major item in a system, fitting a backup to cope with failures is feasible and sensible. Conventional exception handling schemes are usually concerned with detecting internal program problems. These include stack overflow, array bound violations, and arithmetic overflow. However, for most real-time systems, a new range of problems has to be considered. These relate to factors such as sensor failure, illegal operator actions, program malfunction induced by external interference, and more.

Detecting such faults is one thing; deciding what to do subsequently can be an even more difficult problem. Exception-handling strategies need careful design to prevent faults causing system or environmental damage or worse — injury or death. In real-time systems, computing elements are destined for use in either general-purpose or specialized applications Figure 1.

To use these effectively, the software designer should have a good understanding of their features. Author : J. Author : Phillip A. In literature we can find articles on several hard real - time operating systems , for example Ready 4 , Baker and Scallon 5 , Author : Albert M. Gerber and S. Kneis Ed. You will learn the concepts of software and program design, as well as the different types of programming, software errors, and software life cycles, and how a multitasking structure benefits a system design.

Moving ahead, you will learn why diagrams and diagramming plays a critical role in the software development process. You will practice documenting code-related work using Unified Modeling Language UML , and analyze and test source code in both host and target systems to understand why performance is a key design-driver in applications.

Next, you will develop a design strategy to overcome critical and fault-tolerant systems, and learn the importance of documentation in system design.

By the end of this book, you will have sound knowledge and skills for developing real-time embedded systems. If you are interested in developing a real-time embedded system, this is the ideal book for you. With a basic understanding of programming, microprocessor systems, and elementary digital logic, you will achieve the maximum with this book. Knowledge of assembly language would be an added advantage. Learn algorithms for solving classic computer science problems with this concise guide covering everything from fundamental ….

Through a series of recent breakthroughs, deep learning has boosted the entire field of machine learning. A friendly introduction to the most useful algorithms written in simple, intuitive English The revised and …. Build a strong foundation in designing and implementing real-time systems with the help of practical examples …. Skip to main content.