The Complete Edition – Software Engineering for Real-Time Systems

A software engineering perspective toward designing real-time systems

Jim Cooling

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781839213526
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

Adopt a diagrammatic approach to creating robust real-time embedded systems

Key Features

• Explore the impact of real-time systems on software design
• Understand the role of diagramming in the software development process
• Learn why software performance is a key element in real-time systems

Book Description

From air traffic control systems to network multimedia systems, real-time systems are everywhere. The correctness of the real-time system depends on the physical instant and the logical results of the computations. This book provides an elaborate introduction to software engineering for real-time systems, including a range of activities and methods required to produce a great real-time system.

The book kicks off by describing real-time systems, their applications, and their impact on software design. 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.

What you will learn

• Differentiate between correct, reliable, and safe software
• Discover modern design methodologies for designing a real-time system
• Use interrupts to implement concurrency in the system
• Test, integrate, and debug the code
• Demonstrate test issues for OOP constructs
• Overcome software faults with hardware-based techniques

Who this book is for

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.

1. Real-Time Systems – Setting the Scene

40 years ago, software development was widely seen as consisting of only programming. And it was regarded more as an art than a science (and certainly not as an engineering discipline). Perhaps that's why this period is associated with so many gloomy tales of project failure. Well, the industry has matured. Along the way, we had new languages, real design methods, and, in 1968, the distinction between computer science and software engineering.

The microprocessor arrived circa 1970 and set a revolution in motion. However, experienced software developers played little part in this. For, until the late 1970s, most developers of microcomputer software were electronic, electrical, or control engineers. And they proceeded to make exactly the same mistakes as their predecessors. Now, why didn't they learn from the experience of earlier workers? There were three main reasons for this. In the first place, there was little contact between electronic engineers (and the like) and computer scientists. In the second place, many proposed software design methods weren't suitable for real-time applications. Thirdly, traditional computer scientists were quite dismissive of the difficulties met by microprocessor systems designers. Because programs were small, the tasks were trivial (or so it was concluded).

Over the years, the industry has changed considerably. The driving force for this has been the need to:

• Reduce costs
• Improve quality, reliability, and safety
• Reduce design, development, and commissioning timescales
• Design complex systems
• Build complex systems

Without this pressure for change, the tools, techniques, and concepts discussed in this book would probably still be academic playthings.

Early design methods can be likened to handcrafting, while the latest ones are more like automated manufacture. But, as in any industry, it's no good automating the wrong tools; we have to use the right tools in the right place at the right time. This chapter lays the groundwork for later work by giving a general picture of real-time systems. It does this with the following:

• Highlights the differences between general-purpose computer applications (for example, information technology, management information systems, and more) and real-time systems
• Looks at the types of real-time systems met in practice
• Describes the environmental and performance requirements of embedded real-time systems
• Describes the typical structures of modern microprocessors and microcomputers
• Shows, in general, how software design and development techniques are influenced by these factors

The detailed features of modern software methods are covered in later chapters.

1.1 Categorizing Computer Systems

So, how are computer systems categorized? There are many answers to this, sometimes conflicting, sometimes overlapping. But if we use the speed of response as the main criterion, then three general groups emerge:

• Batch: I don't mind when the computer results arrive, within reason (the time taken may be hours or even days in such systems).
• Interactive online: I would like the results within a fairly short period of time, typically, a few seconds.
• Real-time: I need the results within definite timescales; otherwise, the system just won't work properly.

Let's consider these in turn.

An example of a modern batch system is shown in Figure 1.1. Methods like this are used:

Figure 1.1: Modern batch system

Where, computing resources are scarce and/or expensive as it is a very efficient technique.

Here, the user usually preprocesses all programs and information, perhaps storing data on a local computer. At a convenient time, say, at the start of an evening shift, this job is passed over the data link to a remote site (often, a number of jobs are transmitted as a single job lot). When all the jobs are finished, the results are transmitted back to the originating site.

Interactive online computer systems are widely used in banking, holiday booking, and mail-order systems. Here, for private systems, access to the system is made using (typically) PC-based remote terminals (Figure 1.2):

Figure 1.2: Typical interactive online computer system

The local processing of data isn't normally done in this instance. Instead, all transactions are handled by the central computer in a time-slice fashion. Routing and access control is the responsibility of the frontend processors and local multiplexers. Many readers will, of course, have experience of such systems through their use of the internet and the web (perhaps the importance of timeliness in interactive systems is summed up by the definition of www as standing for world wide wait). A further point to take note of is that response times depend on the amount of activity. All systems slow down as load builds up, sometimes, seizing up at peak times. For time-critical applications, this type of response is unacceptable, as, for example, in auto cruise control systems (Figure 1.3):

Figure 1.3: Real-time computer system

Here, the driver dials in the desired cruising speed. The cruise control computer notes this and compares it with the actual vehicle speed. If there is a difference, correcting signals are sent to the power unit. The vehicle will either speed up or slow down, depending on the desired response. Provided the control is executed quickly, the vehicle will be powered in a smooth and responsive manner. However, if there is a significant delay in the computer, a kangaroo-like performance occurs. Clearly, in this case, the computer is worse than useless; it degrades the car's performance.

In this book, "real-time" is taken to imply time-bound response constraints. Should computer responses exceed specific time bounds, then this results in performance degradation and/or malfunction. So, within this definition, batch and interactive online systems are not considered to operate in real-time.

1.2 Real-Time Computer Systems

1.2.1 Time and Criticality Issues

From what's been said so far, one factor distinguishes real-time systems from batch and online applications: timeliness. Unfortunately, this is a rather limited definition; a more precise one is needed. Many ways of categorizing real-time systems have been proposed and are in use. One particular pragmatic scheme, based on time and criticality, is shown in Figure 1.4. An arbitrary boundary between slow and fast is 1 second (chosen because problems shift from individual computing issues to overall system aspects at around this point). The related attributes are given in Figure 1.5.

Hard, fast embedded systems tend, in computing terms, to be small (or maybe a small, localized part of a larger system). Computation times are short (typically, in the tens of milliseconds or faster), and deadlines are critical. Software complexity is usually low, especially in safety-critical work. A good example is the airbag deployment system in motor vehicles. Late deployment defeats the whole purpose of airbag protection:

Figure 1.4: Real-time system categorization

Figure 1.5: Attributes of real-time systems

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 (HMIs). 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.

The final category, soft/slow, is typified by condition monitoring, trend analysis, and statistical analysis in, for example, factory automation. Frequently, such software is large and complex. Applications like these may be classified as information processing (IP) systems.

1.2.2 Real-Time System Structures

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. Sec...