Software design for Real-time Systems by J.E. Cooling

Why this book and does it have special?

This book is actually a forerunner of Software Engineering for Real-Time Systems, which is mentioned under the IEC61508 literature references, in part 7 (Overview of tecniques and measures), but this is obviously not the only reason to include it here.

First of all, the book puts some names and people, as well as industry and research projects, behind the "dry" methods and techniques listed in the IEC61508 tables.

Secondly, it tackles the real-time software design aspects in a quite holistic and practical manner, considering economical aspects related to software production (to be done within expected timeframe and budget!!) and reminds the reader, at least indirectly, that software is essentially designed by humans and to be used by humans.

Furthermore, the writing style is a kind of mix between a constant pleading to criticism (author himself inviting the reader to question everything, including things in his book) and a hands-on approach from the industry, where research methods have been concretely applied, which types of failures were they exposed to, their effects and causes.

What is the book about?

The book is a thorough exploration of methods used to specify requirements and design, for real-time systems, culminating with concrete examples of them (exposed in chapter 10).

First three chapters are setting the stage, in the way of clarifying essential terminology that will be further used to judge or to determine: what real-time software is, what means good and bad software (including the economic aspects I mentioned above), why and where do we need it, which types of errors is it exposed to. Actually the book excels in classifying everything, is full of taxonomies, from types of system failures, like hard, soft, or fail-safe, to design and coding errors, like syntax, semantic, logic, algorithm, to types of environment interactions with the system.examples of them (exposed in chapter 10).

For someone being interested in software for safety systems, like me, is always helpful to read about interferences and overlaps between safe, real-time and reliable software (Nancy Levenson stresses on that, in her book, Safeware, which I also plan to comment as part of this series). The author does a lot of effort to clean up doubts, mis-understandings and popular wisdom related to what is each of them. Apart from that his personal appreciations (or research) are also interesting to read, like less than 1% of all embedded systems in UK are real-time systems … interesting how or whether this changed until today.

It also provides an overview of software distribution errors, as well as their corresponding costs, based on statistics obtained by Tom DeMarco, (like in the picture here to the left) which most of readers can be already familiar with, from James Martin’s magnum opus, ?An Information Systems Manifesto“.

Every chapter ends with a comprehensive list of literature references and recommended further readings.

Interesting effort distributions (split per requirements, implementation and testing) for some groundbreaking critical projects done in the past, like SAGE, NTDS, GEMINI, Saturn V, OS/360 (like is to be noticed in the picture to the right), have their place in the book, too.

Let’s not forget what is the book essentially about, and this is, methods to describe real-time systems, from requirements down to implementation. There is consequently explained the necessity to have a mathematical description of them, and are also introduced some diagramming methodologies which count as the forerunners of UML. These are what comes to be famously known as formal methods. Those are precisely the methods in IEC61508-7 where this book is referred and namely: Structured design (B.3.2), Modularisation (B.3.4), Structured diagrammatic methods (C.2.1), Defensive programming (C.2.5) Modular approach (C.2.9), Performance requirements and modelling (C.5.19 and C.5.20). Chapter 10, in the book is dedicated to them.

Behind those diagrams are names and even ?schools of tought“ which pioneered the computer science and safety/reliability research which definitely worth mention: Michael Jackson, Edward Yourdon, Stephen Mellor, Paul Ward or Larry Constantine.

Last chapter, about ?Documentation and testing“, is a compilation of everything and I liked especially the way it begins, which is, as a writing style, characteristic for the whole book:

Documentation. Paperwork. Records. Words which induce instant apathy in any design team. Such things appeal to bureaucrats, not to creative designers . Maybe this is a slighly harsh judgement – apologies to dedicated bureaucrats- but it is true. Unfortunately, documentation is a key feature of all professional design and development activities. It can be regarded as the life-blood of the design body. 

All of the chapter is worthy to be shared here, but I need to refrain only to few pages (here below), which I think, they are a boon to be read, for every safety expert.

What struck me most about this book and which are my take-aways?

In my opinion the gist of the book lies in the examples of formal methods and revealing from the research and concrete industry projects where they were initially deployed. It does a great job in familiarising the reader with some initial research projects done in the 70s and 80s in the field of requirements and tools specifications for real-time systems, like STARTS project (guide to methods and tools for construction of large real-time systems) or CASE (used to develop tools for high-quality, defect-free and maintainable software, and a fore-runner for todays' hardware CAD systems)

Furthermore, for me personally, it was one of the first places where I got to know about code "modularity" metrics, like cohesion and coupling, or on formal methods, and their notations, like VDM and Z, or structured analyses, and also on its criticism.

Beyond the facts that it presents and the systematic approach it takes to describe and classify everything, the book is interesting to read as a piece of literature. The author expresses on many occasions his personal views about various aspects, and some of them are interesting to read now, in retrospect, like for instance this forecast he makes about the evolution of programming languages (to the right).

All in all, this is definitely one of those books, which after reading it, makes you say Sometimes it is really incredible, how things written 40 years ago, can still be actual