![Chapter 1
Introduction
Dependable, Embedded Software
This is a book about the development of dependable, embedded soft-
ware.
It is traditional to begin books and articles about embedded software
with the statistic of how many more lines of embedded code there are
in a modern motor car than in a modern airliner. It is traditional to
start books and articles about dependable code with a homily about
the penalties of finding bugs late in the development process — the
well-known exponential cost curve.
What inhibits me from this approach is that I have read Laurent
Bossavit’s wonderful book, The Leprechauns of Software Engineering
(reference [1]), which ruthlessly investigates such “well-known” soft-
ware engineering preconceptions and exposes their lack of foundation.
In particular, Bossavit points out the circular logic associated with
the exponential cost of finding and fixing bugs later in the development
process: “Software engineering is a social process, not a naturally oc-
curring one — it therefore has the property that what we believe about
software engineering has causal impacts on what is real about software
engineering.” Because we expect it to be more expensive to fix bugs
later in the development process, we have created procedures that make
it more expensive.
Bossavit’s observation is important and will be invoked several times
in this book because I hope to shake your faith in other “leprechauns”
associated with embedded software.
3
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-27-320.jpg)
![Introduction 5
The official inquiry into the Deepwater Horizon tragedy (reference [2])
specifically addresses the safety culture within the oil and gas industry:
“The immediate causes of the Macondo well blowout can be traced to a
series of identifiable mistakes made by BP, Halliburton, and Transocean
that reveal such systematic failures in risk management that they place
in doubt the safety culture of the entire industry.”
The term “safety culture” appears 116 times in the official Nimrod
Review (reference [3]) following the investigation into the crash of the
Nimrod aircraft XV230 in 2006. In particular, the review includes
a whole chapter describing what is required of a safety culture and
explicitly states that “The shortcomings in the current airworthiness
system in the MOD are manifold and include . . . a Safety Culture that
has allowed ‘business’ to eclipse Airworthiness.”
In a healthy safety culture, any developer working on a safety-
critical product has the right to know how to assess a risk, and has
the duty to bring safety considerations forward.
As Les Chambers said in his blog in February 2012∗
when comment-
ing on the Deepwater Horizon tragedy:
We have an ethical duty to come out of our mathemati-
cal sandboxes and take more social responsibility for the
systems we build — even if this means career threatening
conflict with a powerful boss. Knowledge is the tradi-
tional currency of engineering, but we must also deal in
belief.
One other question that Chambers addresses in that blog posting is
whether it is acceptable to pass a decision “upwards.” In the incident
described in Anecdote 1, I refused to sign the release documentation
and passed the decision to my boss. Would that have absolved me
morally or legally from any guilt in the matter, had the equipment
been shipped and had an injury resulted? In fact, my boss also refused
to sign and shipment was delayed at great expense.
I am reminded of an anecdote told at a conference on safety-critical
systems that I attended a few years back. One of the delegates said that
he had a friend who was a lawyer. This lawyer quite often defended
engineers who had been accused of developing a defective product that
had caused serious injury or death. Apparently, the lawyer was usu-
ally confident that he could get the engineer proven innocent if the case
came to court. But in many cases the case never came to court because
∗ http://www.systemsengineeringblog.com/deus_ex_machina/
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-29-320.jpg)
![6 Introduction
the engineer had committed suicide. This anecdote killed the conver-
sation as we all reflected on its implications for each of us personally.
Our Path
I have structured this book as follows:
Background material.
Chapter 2 introduces some of the terminology to be found later
in the book. This is important because words such as fault,
error, and failure, often used almost interchangeably in everyday
life, have much sharper meanings when discussing embedded
systems.
A device to be used in a safety-critical application will be de-
veloped in accordance with the requirements of an international
standard. Reference [4] by John McDermid and Andrew Rae
points out that there are several hundred standards related to
safety engineering.
From this smörgåsbord, I have chosen a small number for
discussion in Chapter 3, in particular IEC 61508, which relates
to industrial systems and forms the foundation for many other
standards; ISO 26262 which extends and specializes IEC 61508
for systems within cars; and IEC 62304, which covers software
in medical devices.
I also mention other standards, for example, IEC 29119, the
software testing standard, and EN 50128, the railway standard,
to support my arguments here and there in the text.
To make some of the discussion more concrete, in Chapter 4
I introduce two fictitious companies. One of these is producing
a device for sale into a safety-critical market, and the other
is providing a component for that device. This allows me to
illustrate how these two companies might work together within
the framework of the standards.
Developing a product for a safety-critical application.
Chapter 5 describes the analyses that are carried out for any
such development — a hazard and risk analysis, the safety case
analysis, the failure analysis, etc. — and Chapter 6 discusses
the problems associated with incorporating external (possibly
third-party) components into a safety-critical device.
Techniques recommended in the standards.
Both IEC 61508 and ISO 26262 contain a large number of tables
recommending various techniques to be applied during a soft-
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-30-320.jpg)
![Introduction 7
ware development. Many of these are commonly used in any
software development (e.g., interface testing), but some are less
well-known. Chapters 7 to 19 cover some of these less common
techniques.
For convenience, I have divided these into patterns used during
the architecture and design of a product (Chapters 7 to 10), the
tools that are used to ensure the validity of the design (Chapters
11 to 15), the techniques used during implementation (Chapters
16 to 18), and those used during implementation verification
(Chapter 19).
Development tools
One essential, but sometimes overlooked, task during a devel-
opment is preparing evidence of the correct operation of the
tools used; it is irrelevant whether or not the programmers are
producing good code if the compiler is compiling it incorrectly.
Chapter 20 provides some insights into how such evidence might
be collected.
I introduce the goal structuring notation and Bayesian belief networks
in Chapter 5, but relegate details about them to Appendices A and B
respectively. Finally, there is a little mathematics here and there in
this book. Appendix C describes the notations I have used.
Choosing the Techniques to Describe
I have used three criteria to guide me in selecting the tools and tech-
niques to describe:
1. The technique should be explicitly recommended in IEC 61508
or ISO 26262 or both. I think that I have only included one
technique not directly recommended in those standards.
2. I should have made direct use of the tool or technique myself.
3. The tool or technique should not be in common use in the ma-
jority of companies that I have recently visited.
Development Approach
There are many development methodologies ranging from pure water-
fall (to which Bossavit dedicates an entire chapter and appendix in ref-
erence [1]) through modified waterfall, design-to-schedule, theory-W,
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-31-320.jpg)
![10 Introduction
that one person can do both.
Another point emphasized by Figure 1.1 is the central role played
by the safety case. All of the analyses and decisions made during
the project must become elements of the safety case. This essential
document is described in Chapter 5, starting on page 61.
Today’s Challenges
Although the last ten to fifteen years have seen a tremendous growth
in tools and techniques that we can apply to the development of safe,
embedded systems, challenges still remain and new ones are emerging.
Security
Safety is now interlinked with security — the behavior of an insecure
device is effectively unpredictable once a hacker has broken in. This
topic is discussed briefly on page 92, but no general methodology exists
for combining security and safety issues. In the past, many embedded
systems have been physically secure, being locked in the driver’s cab of
a train or behind a locked fence on a shop floor. Today almost every
device supports external communications through Wi-Fi, Bluetooth,
USB drives, or from GPS satellites, and these channels are all security
vulnerabilities.
In reference [5], Peter Bernard Ladkin discusses whether the inter-
action between the company operating a safety-critical system and a
malicious attacker can be modeled as a form of game theory, actually
a form of meta-game theory, because each protagonist can choose the
game to play. He believes that this approach is much more suitable
for assessing security threats than the hazard and risk approaches de-
scribed in the safety standards.
Tools for Balancing Architectural Needs
Chapter 7 identifies the need for an architect and a designer to balance
the availability, reliability, performance, usefulness, security, and safety
of a system. These characteristics interact, and a design decision in one
area will affect all the others. I know of no tools that can help an analyst
manipulate these system characteristics and trade one off against the
others.
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-34-320.jpg)
![12 Introduction
erence [6] by Paul Hampton and Mike Parsons, contains a chilling list
of examples where human life has been lost through data errors, rather
than hardware or software errors.
References
1. L. Bossavit, The Leprechauns of Software Engineering: How Folklaw Turns
into Fact and What to Do about It. Leanpub, 2013.
2. B. Graham, W. K. Reilly, F. Beinecke, D. F. Boesch, T. D. Garcia, C. A.
Murray, and F. Ulmer, “Deep Water — The Gulf Oil Disaster and the Future
of Offshore Drilling: Report to the President,” 2011.
3. C. Haddon-Cave, The Nimrod Review. UK Government, 2009.
4. J. McDermid and A. Rae, “Goal-Based Safety Standards: Promises and
Pitfalls,” in 2012 Safety Critical Systems Symposium, SSS ’12, (Bristol, UK),
Safety-Critical Systems Club, 2012.
5. P. B. Ladkin, “Risks People Take and Games People Play,” in 2015 Safety
Critical Systems Symposium, SSS ’15, Safety-Critical Systems Club, 2015.
6. P. Hampton and M. Parsons, “The Data Elephant,” in 2015 Safety Critical
Systems Symposium, SSS ’15, Safety-Critical Systems Club, 2015.
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-36-320.jpg)
![14 Terminology
Risk: The secondary effects of cosmic rays.
These may cause a bit-flip in the configuration memory, chang-
ing the device’s operating mode unexpectedly and potentially
giving rise to a dangerous situation.
One mitigation against this risk might be to use error check-
ing and correcting memory (ECC) so that the errors are detected
(and possibly corrected).
Residual risks include the facts that not all errors are de-
tected by ECC memory, that the application may not correctly
handle the interrupt indicating the memory error and the fact
that ECC may not cover caches.
Risk: The exhaustion of memory.
An application may have a memory leak and, being unable to
access additional memory, may fail in an unexpected way, po-
tentially causing a dangerous situation.
One mitigation might be for each application to reserve suf-
ficient memory statically at startup and never release it.
There is still a residual risk that the amount of statically
allocated memory is inadequate when a condition occurs that
was never considered during design and test.
Usually, there are several risks associated with each hazard, and several
mitigations associated with each risk.
Availability, Reliability, and Dependability
When a software subsystem is invoked, it may fail in one of two ways:
It may fail to give a timely answer at all, or it may respond, but
with the wrong answer. The failure to provide an answer within the
time that makes it useful is termed an availability problem; the timely
presentation of the wrong answer is a reliability problem.
Increasing availability generally reduces reliability and vice versa.
Consider a server that performs some form of calculation. We can
increase the reliability of that system by getting two servers to do the
calculation and compare their answers. This is a venerable technique:
When the formula is very complicated, it may be alge-
braically arranged for computation in two or more dis-
tinct ways, and two or more sets of cards may be made.
If the same constants are now employed with each set,
and if under these circumstances the results agree, we
may be quite secure in the accuracy of them.
Charles Babbage, 1837 (reference [1])
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-38-320.jpg)
![Terminology 15
Unfortunately, although it improves the reliability of some systems,
duplication of this nature reduces availability — if either of the two
servers is unavailable, then the entire system is unavailable.
Given this antagonism between availability and reliability, it is im-
portant during the design process to understand which is to be empha-
sized in that design and how a balance is to be achieved. This topic is
explored further on page 90.
It is relatively easy to think of systems where reliability is essential
to safety, even at the expense of availability. It is harder, but possible,
to imagine systems where availability is more important. In reference
[2], Mats Heimdahl describes a deliberately far-fetched example of a
system where any increase in reliability will make the system less safe.
Note that, while the clients of a service can, in general, measure
the availability of the server they are accessing, it is often impossible
for them to measure the server’s reliability — if the clients knew the
correct answer then they presumably wouldn’t have needed to invoke
the provider.
Much of program testing is really testing reliability, only checking
availability in passing.
In this book, I use the term “dependability” to combine the two
terms “availability” and “reliability,” whichever is the more important
for the system under consideration. A common definition of “depend-
able” is that a system is dependable if it delivers a service that can be
justifiably trusted.
Functional Safety
Safety can be provided in different ways. Consider a laser on a piece of
telecommunications transmission equipment: such a laser is a hazard.
One risk associated with this hazard is that if an operator removed the
fiber and looked into the transmitter, eye damage could result.
One way of mitigating this risk might be to install the transmitter
facing downward close to the bottom of the rack — the position making
it impossible for an operator to align an eye with the transmitter. This
would be safe, relying on a passive safety system.
Another way of mitigating the risk would be to have software moni-
toring the connector and turning the laser off if the fiber were removed.
To be safe, this requires an active component, the software, to function
correctly. The software must be monitoring the connector all the time
and must turn the laser off within a few milliseconds to prevent harm.
The second of these techniques represents functional safety: Some-
thing must continue to function in order to keep the system safe.
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-39-320.jpg)
![16 Terminology
Fault, Error, and Failure
A programmer may introduce a fault into a program by typing some-
thing unintended into an editor. A fault is a passive flaw.
Sometimes a fault may cause the program to perform in a way that
produces an unintended outcome, the fault having caused an error.
Sometimes an error causes a failure of the system. In the words of
EN 50128, “a failure has occurred if a functional unit is no longer able
to perform its required function, i.e., a failure is an observable effect
outside the system boundary arising from an internal error or fault.
An error or fault does not always lead to a failure.”
The important word in these descriptions is “sometimes.” As the
quotation from EN 50128 states, a fault does not always cause an error.
If, for example, the programmer had meant to type
char x[10];
for a local variable, and accidentally typed
char x[11];
that is unlikely to cause an error unless the system is very short of
memory. It is, however, a fault.
If a programmer created a system that opened a file every 10 sec-
onds, but failed to close those files, then this fault would cause an error
every 10 seconds (a leak of a file descriptor). However, that error would
not cause a failure for some time — not for about 90 days for the com-
puter on which this paragraph was typed, which permits up to 777,101
open file descriptors. For a real example, see Anecdote 9 on page 114.
As illustrated in Figure 2.1, an error at one level in a system may
cause a fault at another. In that figure, a fault in Fred’s training causes
him to insert a bug in the code (he makes an error by inserting a fault).
Fred loses his job over this mistake (a failure — at least as far as Fred
is concerned). The fault in the code goes on to cause a failure in the
overall system.
Differentiating between faults, errors, and failures allows us to tackle
them in different ways — we want to reduce the number of faults in-
serted into the system, to detect and remove faults before they become
errors, to detect errors and prevent them from becoming failures and,
if a failure does occur, to handle it in the safest way possible.
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-40-320.jpg)
![Terminology 19
Backward and Forward Error Recovery
When a fault causes an error, that error can sometimes be trapped and
some form of recovery can take place before a failure occurs. The two
main forms of error recovery are:
Backward Error Recovery.
Once an error is discovered, the system returns to a previously-
stored state that is known (or believed) to be consistent and
sane. Whether the input that apparently caused the error is
then reapplied or discarded, and how the client is notified, vary
between implementations.
One of the disadvantages of backward error recovery is the
need to store the system’s state information before handling an
incoming request so that it is available if rollback is required.
Forward Error Recovery.
This removes the main disadvantage of backward error recovery
— the need to save the system’s state — by moving to a prede-
fined sane state independent of both the previous state and the
input that caused the error.
Accidental Systems
In the presentation associated with reference [3], Martyn Thomas de-
scribed an experiment wherein global positioning system (GPS) signals
were deliberately jammed in part of the North Sea and a ship was taken
through the area to see what would happen. As expected, the position
of the ship became imprecise (sometimes the ship was in the middle of
Norway, sometimes in the middle of Germany!), but unexpectedly, the
ship’s radar also stopped working. The experimental team contacted
the company that manufactured the radar and was told that GPS was
not used within it. They then contacted the manufacturers of the com-
ponents in the radar and found that one small component was using
GPS timing signals.
The radar constitutes an “accidental system.” The manufacturer of
the small component knew that any system into which it was incorpo-
rated would rely on the integrity of the GPS signals, but was not aware
of the radar system into which the component was being incorporated.
The designer of the radar was unaware of the dependency. No one had
the full picture, and a system had been built with accidental depen-
dencies. The system would not have been tested in the face of GPS
jamming, because the reliance on GPS was unknown.
Embedded software-based systems can also become accidental sys-
tems. Perhaps the designers of the complete system were unaware that
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-43-320.jpg)
![20 Terminology
an incorporated component was single-threaded or included recursion
that could exceed the allocated stack size.
Software-Specific Terminology
Software
In a book dedicated to embedded software, it may seem strange to ask
what software is — intuitively people feel that they can differentiate
between software and hardware. If it hurts when dropped on one’s foot,
it’s hardware.
But what about an Application-Specific Integrated Circuit (ASIC)
designed by a software tool? What about 5000 lines of C code generated
by a modeling tool?
Reference [4], published by the Rail Safety and Standards Board,
treats the distinction between hardware and software pragmatically by
noting that software is intrinsically more complex than hardware:
As a rule of thumb, we suggest that if a device has few
enough internal stored states that it is practical to cover
them all in testing, it may be better to regard it as hard-
ware and to show that it meets its safety requirements by
analysis of the design and testing of the completed de-
vice, including exhaustive testing of all input and state
combinations.
This is the definition that we will use in this book. If the system is
sufficiently simple that it can be tested exhaustively, then it will be
treated as hardware; otherwise as software.
Note that this is a one-way definition. Certainly, the embedded sys-
tems considered in this book are too complex for exhaustive testing and
will therefore be treated as software. However, it has also been impos-
sible to test some hardware devices exhaustively for many years. For
example, even a 64 kbit RAM (ludicrously small by today’s standards)
has 264×1024
possible states — a number containing 19,728 digits —
and, under the definition in reference [4], could be considered software.
I will ignore that interpretation.
There is another aspect of software that is often neglected: config-
uration data. Commission Regulation (EC) No 482/2008 of the Euro-
pean Union, explicitly defines the term “software” to include its asso-
ciated configuration data:
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-44-320.jpg)
![22 Terminology
System
Fault
.........
Potential
Errors
.........
Failures as
observed by
the test group
or customers
Fault
Fault
Faults that must
be traced and fixed
by the development
group
Debugging
.........................
Figure 2.2 Tracing the failure to the fault.
It is a characteristic of Heisenbugs that the same fault can give rise
to different failures, and the failures can occur much later than when
the fault was invoked (and in an entirely different piece of code). This
is what makes debugging difficult: Testing detects failures, whereas the
developers must fix faults. For all faults, but particularly for Heisen-
bugs, the path from the fault to the failure is many-to-many and this
makes tracing the fault, given the failure, very difficult — see Figure
2.2.
At the level that can be observed by a tester, many failures appear
to be identical. The errors that cause the failures are invisible to both
tester and programmer, and different faults may give rise to essentially
identical errors.
Jim Gray made the point, although not in the context of safety-
critical systems, that users prefer Heisenbugs to Bohrbugs; they prefer
a failure occurring randomly about once a month to a failure every
time a certain command is entered in a particular context. For this
reason, research has been carried out (e.g., reference [5]) on converting
Bohrbugs into Heisenbugs. For example, if more memory is allocated
for an object than is strictly required and the memory is allocated
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-46-320.jpg)
![Terminology 23
probabilistically, a memory overflow becomes a Heisenbug rather than
a Bohrbug.
The elusive nature of Heisenbugs make them particularly difficult to
fix, and some researchers, particularly Andrea Borr (see, for example,
reference [6]), have found that attempts to fix Heisenbugs generally
make the situation worse than it was before.
Irreverent programmers have extended the Bohrbug and Heisen-
bug terminology in more comical directions. Named after Erwin
Schrödinger (Nobel Laureate in 1933), the Schrödingbug, for exam-
ple, is a fault that has been in the code for many years and has never
caused a problem in the field. While reading the code one day, a pro-
grammer notices the bug. Immediately, field reports start to flow in
as the bug, having now been observed, like Schrödinger’s cat suddenly
wakes up in the field.
Real-Time
The term real-time is perhaps one of the most confusing and misused
terms in software development. A system is real-time simply if its
required behavior includes a time constraint.
Hence, a program that calculates a weather forecast from currently-
available data is a real-time program because an excellent forecast for
a period 12 hours ahead is useless if it takes 14 hours to produce.
Similarly, the payroll calculations performed by companies to pay their
employees are real-time because failure to complete them on time could
lead to very unhappy employees.
Within the embedded world, a system is real-time if part of its
contract specifies a time within which it will respond: “This system
reads the sensor every 10±2ms and makes the processed data available
within 5 ms of the reading.”
Fallacy 1 “Real-time” means “fast.”
Real-time systems tend to be slower than non-real-time ones because
of the time buffering needed to ensure that deadlines are always met,
irrespective of the timing of other subsystems.
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-47-320.jpg)
![24 Terminology
Programming by Contract
The concept of programming by contract or contract-first development
was devised by Bertrand Meyer for the Eiffel programming language
in the late 1980s∗
and is now available in other languages, such as D.
Programming by contract defines a three-part formal contract between
a client and a server:
1. The client has an obligation to ensure that its request meets the
server’s preconditions. For example, a precondition for invoking
the function to add an item to a queue may be that the queue
is not already full.
2. The server guarantees that certain post-conditions will apply to
its response. In the case of adding an item to a queue, this would
include the fact that the queue has exactly one more element
than it had previously and that the last element on the queue
is the one provided by the client.
3. The server guarantees that certain internal invariants will apply
on exit so that the next call to it will also be answered correctly.
If the contracts are coded into the server program when it is written,
then not only can they be checked at runtime to catch otherwise difficult
to find bugs, but they can also be used to assist static analysis tools
with their work: see reference [7] and Chapter 18.
For example, given the queue add() function above, a static anal-
ysis tool could analyze the whole code base to determine whether it
could ever be possible for the function to be called when the queue was
already full.
References
1. C. Babbage, “On the Mathematical Powers of the Calculating Engine.”
(Published in Origins of Digital Computers: Selected Papers (ed. B. Ran-
dell) Springer-Verlag, 1973), 1837.
2. M. P. E. Heimdahl, “Safety and software intensive systems: Challenges old
and new,” in 2007 Future of Software Engineering, FOSE ’07, (Washington,
DC, USA), pp. 137–152, IEEE Computer Society, 2007.
3. M. Thomas, “Accidental Systems, Hidden Assumptions and Safety Assur-
ance,” in SSS (C. Dale and T. Anderson, eds.), pp. 1–9, Springer, 2012.
∗ Note that Eiffel Software is the owner of the copyright on the related term Design by
Contract.
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-48-320.jpg)
![Chapter 3
Safety Standards and
Certification
All too often, writers of standards focus on questions of
what constitutes good practice, and lose sight of what the
followers of those standards truly need to demonstrate
in order to show safety. Safety is demonstrated not by
compliance with prescribed processes, but by assessing
hazards, mitigating those hazards, and showing that the
residual risk is acceptable.
From reference [1]
Standards Bodies
It is said that the good thing about standards is that, if you don’t
like one, then there is always another that you can apply instead. In
reference [2], John McDermid and Andrew Rae actually say “it is hard
to count [the safety engineering standards], but there are probably
several hundred.” And, of course, there is no clear boundary around
the safety standards — is IEC 29119, a standard that covers software
testing, a safety standard or not?
There are also numerous bodies that produce standards. In this
book I concentrate on a small number of standards produced by two
organizations: the International Electrotechnical Commission (IEC)
and the International Organization for Standards (ISO).
Both of these organizations are based in Switzerland, and although
27
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-50-320.jpg)
![30 Safety Standards
from an accredited body.
Certification bodies are accredited by national accreditation
authorities to carry out particular certifications. Thus, a cer-
tification body may be accredited to carry out certifications of
hardware (but not software) against IEC 61508 up to safety
integrity level 2 (SIL 2).
A company looking for a certification body should carefully
check the accreditations of the candidates to ensure that the
certificate that will be finally issued will be credible and com-
mercially valuable.
Accrediting the accreditors.
Each country that forms part of the International Accreditation
Forum (IAF)∗
, has one or more accreditation body members
that accredit certification bodies. As there is no higher body,
the obvious question is quis custodiet ipsos custodes?— who
accredits the accreditors? The answer is that they verify each
other’s compliance in an ongoing cycle of evaluations.
There is no reason why a company based in a particular country needs
to seek certification from a certification body accredited in that coun-
try; it may be commercially advantageous to get certification from a
company accredited by the country where the most customers reside.
Getting a certification to a standard such as IEC 61508 is not easy.
Reference [3] was written by Martin Lloyd and Paul Reeve, two very
experienced auditors working at that time for a UK certification body.
The reference describes the success rate that they had recently seen
for IEC 61508 and IEC 61511 certifications of software-based products.
Of the twelve companies that had completed the certification process
at the time of the report, only three (25%) had achieved certification
— the others had failed, in some cases after investing a lot of money
and time. Reference [3] is particularly useful because it lists some of
the common reasons for failure. Martin Lloyd updated the paper in
early 2015 (reference [4]) to include experience between 2010 and 2015.
Many of the same reasons for failure still exist, but the failure rate has
reduced. Martin believes that this is because companies are now more
aware of what is required and are less likely to start the certification
process if they do not have the necessary evidence.
To maximize the chances of getting a product certified, it is useful
to engage the certification company early in the development process.
In particular, it can be useful to discuss the structure of the argument
that will be presented in the safety case (see page 61) with the auditors
∗ http://www.iaf.nu
© 2016 by Taylor Francis Group, LLC](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-53-320.jpg)
![established in the neighbourhood in 1297. Bryants Puddle, a very
rude little hamlet situated on the River Piddle a little to the south-
west of Bere, receives its title from Brian de Turberville, who was
lord of the manor in the reign of Edward III. The village was
anciently called Piddle Turberville, but this name has been replaced
by Bryants Puddle.
At a later period the Turbervilles came into the possession of the
manor of Bere Regis at the breaking up of Tarent Abbey, and at this
time the good fortune of the family was at its zenith. But with the
spoils of the church came a gradual and general downfall of the old
family, and with the increased riches, we may conjecture, the
Turbervilles went roaring on their way more riotously than ever.
There is an entry in the parish registers of Bere, under the year
1710, of the interment of Thomas Turberville, the last of the ancient
race. An intermediate stage of the house is represented by D'Albigny
Turberville, the oculist mentioned by Pepys, who died in 1696 and
was buried in Salisbury Cathedral. After the year 1710 the old
manor-house of the Turbervilles, standing near the church, was
strangely silent. Their time was over and gone, the wine had been
drunk, the singers had departed. But the stories of their carousals
and great deeds were still a matter for dispute and discussion at the
village inn, and the eerie old house was especially regarded with
feelings of awe and few cared to go near it after dark. It was not
what they had seen, but what they might see, that caused them to
shun the old place. I can picture the Dorset rustic of that time (and
the distance between Hodge the Goodman of 1710 and Hodge the
driver of the motor tractor is almost nothing at all) shaking his head
on being asked his reasons for avoiding the house, and saying, with
a grin, as how he shouldn't like to go poking about such a divered
[dead] old hole.
The ancient manor-house was allowed to lapse into ruin, and now
nothing at all remains but a few crumbling stones:](https://image.slidesharecdn.com/2633288-250613121528-ef71d733/85/Embedded-Software-Development-For-Safetycritical-Systems-Chris-Hobbs-65-320.jpg)
Embedded Software Development For Safetycritical Systems Chris Hobbs
- 1. Embedded Software Development For Safetycritical Systems Chris Hobbs download https://ebookbell.com/product/embedded-software-development-for- safetycritical-systems-chris-hobbs-5266576 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Embedded Software Development For Safetycritical Systems 2nd Edition Chris Hobbs https://ebookbell.com/product/embedded-software-development-for- safetycritical-systems-2nd-edition-chris-hobbs-11091226 Embedded Software Development For The Internet Of Things The Basics The Technologies And Best Practices Klaus Elk https://ebookbell.com/product/embedded-software-development-for-the- internet-of-things-the-basics-the-technologies-and-best-practices- klaus-elk-5903222 Software Development For Embedded Multicore Systems A Practical Guide Using Embedded Intel Architecture 1st Edition Max Domeika https://ebookbell.com/product/software-development-for-embedded- multicore-systems-a-practical-guide-using-embedded-intel- architecture-1st-edition-max-domeika-2341628 Componentbased Software Development For Embedded Systems An Overview Of Current Research Trends 1st Edition Colin Atkinson https://ebookbell.com/product/componentbased-software-development-for- embedded-systems-an-overview-of-current-research-trends-1st-edition- colin-atkinson-4140976
- 3. Dsp Software Development Techniques For Embedded And Realtime Systems Robert Oshana https://ebookbell.com/product/dsp-software-development-techniques-for- embedded-and-realtime-systems-robert-oshana-1617174 Embedded Systems Security Practical Methods For Safe And Secure Software And Systems Development 1st Edition David Kleidermacher https://ebookbell.com/product/embedded-systems-security-practical- methods-for-safe-and-secure-software-and-systems-development-1st- edition-david-kleidermacher-49477756 Formal Development Of A Networkcentric Rtos Software Engineering For Reliable Embedded Systems 1st Edition Eric Verhulst https://ebookbell.com/product/formal-development-of-a-networkcentric- rtos-software-engineering-for-reliable-embedded-systems-1st-edition- eric-verhulst-2471660 Embedded Software Development With C 1st Edition Kai Qian David Den Haring https://ebookbell.com/product/embedded-software-development- with-c-1st-edition-kai-qian-david-den-haring-4391340 Embedded Software Development The Opensource Approach Bertolotti https://ebookbell.com/product/embedded-software-development-the- opensource-approach-bertolotti-5308484
- 5. Embedded Software Development for Safety-Critical Systems © 2016 by Taylor & Francis Group, LLC
- 6. © 2016 by Taylor & Francis Group, LLC
- 7. Embedded Software Development for Safety-Critical Systems Chris Hobbs © 2016 by Taylor & Francis Group, LLC
- 8. CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2016 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Version Date: 20150720 International Standard Book Number-13: 978-1-4987-2671-9 (eBook - PDF) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information stor- age or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copy- right.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that pro- vides licenses and registration for a variety of users. For organizations that have been granted a photo- copy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com © 2016 by Taylor & Francis Group, LLC
- 9. Dedication For Alexander, Thomas, and Edward πόλλ' οἶδ' ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα v © 2016 by Taylor & Francis Group, LLC
- 10. © 2016 by Taylor & Francis Group, LLC
- 11. Contents Preface ....................................................................xiii Acknowledgments ..................................................... xvii About the Author ..................................................... xix SECTION I: BACKGROUND 1 Introduction ...........................................................3 Dependable, Embedded Software 3 Safety Culture 4 Our Path 6 Choosing the Techniques to Describe 7 Development Approach 7 Today’s Challenges 10 References 12 2 Terminology of Safety ............................................ 13 General Safety Terminology 13 Software-Specific Terminology 20 References 24 3 Safety Standards and Certification........................... 27 Standards Bodies 27 Accreditation and Certification 29 Why Do We Need These Standards? 31 Goal- and Prescription-Based Standards 32 Functional Safety Standards 33 IEC 62304 and ISO 14971 41 Process and the Standards 43 vii © 2016 by Taylor & Francis Group, LLC
- 12. viii Embedded Software Development Summary 44 References 45 4 Representative Companies...................................... 47 Alpha Device Corporation 47 Beta Component Incorporated 48 Using a Certified Component 48 SECTION II: THE PROJECT 5 Foundational Analyses ........................................... 53 Analyses 53 Interrelationships 54 Hazard and Risk Analysis 56 Safety Case 61 Failure Analysis 67 Analyses by Example Companies 72 Summary 74 References 74 6 Certified and Uncertified Components...................... 77 SOUP by Any Other Name 77 Certified or Uncertified SOUP 78 Using Non-Certified Components 79 Using a Certified Component 83 Aligning Release Cycles 85 Example Companies 85 SECTION III: DESIGN PATTERNS 7 Architectural Balancing.......................................... 89 Availability/Reliability Balance 90 Usefulness/Safety Balance 91 Security/Performance/Safety Balance 92 Performance/Reliability Balance 94 Implementation Balance 94 Summary 95 References 95 8 Error Detection and Handling................................. 97 Why Detect Errors? 97 Error Detection and the Standards 98 Anomaly Detection 98 Rejuvenation 112 © 2016 by Taylor Francis Group, LLC
- 13. Contents ix Recovery Blocks 117 A Note on the Diverse Monitor 120 Summary 120 References 120 9 Expecting the Unexpected.................................... 123 Design Safe State 123 Recovery 126 Crash-Only Model 127 Anticipation of the Unexpected by the Example Companies 128 Summary 129 References 129 10 Replication and Diversification.............................. 131 History of Replication and Diversification 131 Replication in the Standards 132 Component or System Replication? 132 Replication 133 Diversification 136 Virtual Synchrony 141 Locked-Step Processors 146 Diverse Monitor 147 Summary 150 References 150 SECTION IV: DESIGN VALIDATION 11 Markov Models................................................... 155 Markov Models 155 Markov Models and the Standards 156 The Markovian Assumptions 156 Example Calculation 158 Markovian Advantages and Disadvantages 162 References 163 12 The Fault Tree.................................................... 165 FTA and FMECA 165 Fault Tree Analysis in the Standards 166 Types of Fault Tree 166 Example 1: Boolean Fault Tree 167 Example 2: Extended Boolean Fault Tree 169 Example 3: Bayesian Fault Tree 171 Combining FTAs 176 FTA Tools 176 © 2016 by Taylor Francis Group, LLC
- 14. x Embedded Software Development The Use of FTA 177 References 177 13 Software Failure Rates ......................................... 179 Underlying Heresy 179 Compiler and Hardware Effects 181 Assessing Failure Rates 182 Modeling the Failures 184 References 185 14 Semi-Formal Design Verification ............................ 187 Verification of a Reconstructed Design 188 Discrete Event Simulation 190 Timed Petri Nets 199 Simulation and the Example Companies 207 References 208 15 Formal Design Verification.................................... 211 What Are Formal Methods? 211 History of Formal Methods 212 Formal Methods and the Standards 213 Do Formal Methods Work? 216 Types of Formal Methods 217 Automatic Code Generation 218 Spin Modeling Tool 218 Rodin Modeling Tool 225 Formal Modeling by the Example Companies 230 Formal Methods 231 References 232 SECTION V: CODING 16 Coding Guidelines ............................................... 239 Programming Language Selection 239 Programming Languages and the Standards 240 Language Features 240 Use of Language Subsets 244 So, What Is the Best Programming Language? 246 References 246 17 Code Coverage Metrics ........................................ 247 Code Coverage Testing 247 Types of Code Coverage 248 Coverage and the Standards 254 Effectiveness of Coverage Testing 255 © 2016 by Taylor Francis Group, LLC
- 15. Contents xi Achieving Coverage 256 Combinatorial Testing 257 Summary 261 References 261 18 Static Analysis.................................................... 263 What Static Analysis Is Asked to Do 263 Static Code Analysis and the Standards 265 Static Code Analysis 265 Symbolic Execution 272 Summary 274 References 275 SECTION VI: VERIFICATION 19 Integration Testing .............................................. 279 Fault Injection Testing 280 Back-to-Back Comparison Test between Model and Code 284 Requirements-Based Testing 288 Anomaly Detection During Integration Testing 291 References 292 20 The Tool Chain................................................... 293 Validation of the Tool Chain 293 Tool Classification 294 BCI’s Tools Classification 295 Using Third-Party Tools 295 Verifying the Compiler 296 ADC’s and BCI’s Compiler Verification 302 References 305 21 Conclusion ......................................................... 307 SECTION VII: APPENDICES A Goal Structuring Notation.................................... 311 Background 311 Example 312 GSN or BBN? 314 References 314 B Bayesian Belief Networks ..................................... 315 Frequentists and Bayesians 315 Prior Probabilities 316 © 2016 by Taylor Francis Group, LLC
- 16. xii Embedded Software Development Bayes’ Theorem 317 A Bayesian Example 318 What Do the Arrows Mean in a BBN? 319 BBNs in Safety Case Arguments 320 BBNs in Fault Trees 324 BBN or GSN for a Safety Case? 324 References 326 C Notations ........................................................... 327 General Symbols 327 Pi and Ip 328 The Structure Function 329 Components in Parallel and Series 329 Temporal Logic 330 Vector Bases 333 References 334 Index...................................................................... 335 © 2016 by Taylor Francis Group, LLC
- 17. Preface I have written this book for systems designers, implementers, and ver- ifiers who are experienced in general embedded software development, but who are facing the prospect of delivering a software-based system for a safety-critical application. In particular, the book is aimed at people creating a product that must satisfy one or more of the interna- tional standards relating to safety-critical applications — IEC 61508, ISO 26262, EN 50128, IEC 62304 or related standards. Software and Safety The media seem to delight in describing radiotherapy machines that have given the wrong doses to patients, aviation disasters and near- misses, rockets that have had to be destroyed because of a missed comma in the FORTRAN code,∗ and many other such software-related failures. Less often recorded are the times where, hardware having failed, the software prevented a disaster. One example of this is the Airbus that landed in the Hudson River, USA, in January 2009 after the hardware of the engines had failed. Without the continued availability of the flight control software, there would almost certainly have been significant loss of life. The hardware/software divide is therefore not completely one-sided. I hope that this book provides designers, implementers, and verifiers with some ideas that will help to increase the proportion of incidents when software saved the day. ∗ Variously attributed to the Mariner and Mercury space craft. xiii © 2016 by Taylor Francis Group, LLC
- 18. xiv Embedded Software Development of Safety-Critical Systems References All of the techniques described in this book may be further explored through hundreds of academic articles. In order to provide you with a way in, I have provided references at the end of each chapter. With a few whimsical exceptions (e.g., Lardner’s 1834 paper on diverse pro- gramming and Babbage’s 1837 paper on the calculating engine), I have included only references that I have personally found useful as a work- ing software developer. Some of the papers and books I reference changed my ideas about a topic and, in many cases, caused me to start programming to check whether the concepts were actually useful. I have to admit that I object to paying money to journals to access published papers, and I believe that all the articles to which I refer in the bibliographies at the end of each chapter can be freely (and legally) downloaded from the Internet. In some cases, e.g., Kálmán’s original 1960 paper to which Chapter 8 refers, one has the option of paying the original journal $25 to retrieve the article, or going to the website of the associated educational establishment (in this case, the University of North Carolina, USA) and downloading the paper for free. I leave the choice to the reader. Most of the documents that I reference are various international standards. When I refer to a standard, in particular to a section number within a standard, I mean the following editions: ISO 26262 First Edition, 2011 ISO 29119 First Edition, 2013 (parts 1 to 3) ISO 14971 Second Edition, 2007 IEC 61508 Second Edition, 2010 IEC 62304 First Edition, 2006 Tools I have used the C programming language in examples because this is the language most strongly associated with embedded programming. Some knowledge of C would therefore be useful for the reader, but the examples are short and should be readable by software engineers familiar with other languages. From time to time in this book, I mention a particular tool. In gen- eral I describe open-source tools, not because these are always superior © 2016 by Taylor Francis Group, LLC
- 19. Embedded Software Development of Safety-Critical System xv to commercial tools, but because it would seem invidious to mention one commercial vendor rather than another unless I had carried out a careful comparison of the available products. Tools are also very personal. We all know that wars can arise from discussions of whether vi or emacs is the better editor. I refuse to take the bait in these discussions, comfortable in my knowledge that vi is far better than emacs. So, my choice of tool may not be your choice of tool. I hope that whenever I mention a tool, I provide enough information for you to seek out commercial vendors. © 2016 by Taylor Francis Group, LLC
- 20. © 2016 by Taylor Francis Group, LLC
- 21. Acknowledgments This book has evolved from material used by QNX Software Systems (QSS) for a training module covering tools and techniques for building embedded software systems to be used in safety-critical devices de- ployed in cars, medical devices, railway systems, industrial automation systems, etc. I am grateful to QSS management, and in particular my direct man- agers, Steve Bergwerff and Adam Mallory, for allowing me to develop many of the ideas contained in this book while working for them, and for allowing me to use the training material as the foundation for this book. The material in this book has emerged from my professional work and, of course, I have not worked alone. There are many people whom I need to thank for providing me with ideas and challenges. These particularly include Rob Paterson, Ernst Munter, John Hude- pohl, Will Snipes, John Bell, Martin Lloyd, and Patrick Lee — a stim- ulating group of people with whom I have worked over the years. Even with the ideas, creating a book is not a trivial task, and I would like to thank my wife, Alison, who has read every word with a pencil in her hand. I cannot count how many pencils she has worn out getting this book into a shape that she finds acceptable. I thank her. I also thank Chuck Clark and the anonymous reader provided by the publisher for their extremely thorough and detailed proofreading. Some of the cover pictures were provided by QNX Software Sys- tems and Chuck Clark. Many thanks for the permission to use these photographs. xvii © 2016 by Taylor Francis Group, LLC
- 22. © 2016 by Taylor Francis Group, LLC
- 23. About the Author To some extent, I have been shaped by three events. The first I can date precisely: 24th December 1968, at about 8 o’clock in the evening. I was home from university where I was a first-year undergraduate studying a general pure mathematics course. I had completed the first term of my first year, and before leaving for the vacation, I grabbed a book more or less at random from the library in the mathematics common room. I opened it on Christmas Eve and met Kurt Gödel’s incompleteness results for the first time. In those days, these meta-mathematical results were not taught at high school, and the intellectual excitement of Gödel’s argument hit me like a juggernaut. I went back after the vacation intent on studying this type of mathematics further and had the incredible opportunity of attending tutorials by Imre Lakatos at the London School of Economics. Even now, when I have a lot more knowledge of the context within which Gödel’s paper was published, I still think that these results were the highest peak of intellectual creativity of the 20th century. The most recent event had a gentler introduction. On a whim in 2002, I decided to learn the 24 songs that comprise Franz Schubert’s Winterreise song cycle. Thirteen years later, I am still working on them with my wife as accompanist, and, from time to time, feel that I have lifted a lid and been allowed to peep into their enormous emotional and intellectual depth. The intermediate event is of more direct relevance to this book and is recounted in Anecdote 1 on page 4. This event led me into the study of the development of software for safety-critical systems. It may seem strange to link Gödel’s results, safety-critical software and Winterreise, but I feel that each represents a first-rank intellectual challenge. xix © 2016 by Taylor Francis Group, LLC
- 24. xx Embedded Software Development of Safety-Critical Systems I met a project manager recently who said that developing software for a safety-critical application is just like developing software for any other application, with the overhead of a lot of paperwork. Perhaps I should have dedicated this book to him. Chris Hobbs Ottawa © 2016 by Taylor Francis Group, LLC
- 25. OTHER INFORMATION SECURITY BOOKS FROM AUERBACH Android Malware and Analysis Ken Dunham, Shane Hartman, Manu Quintans, Jose Andre Morales, and Tim Strazzere ISBN 978-1-4822-5219-4 Anonymous Communication Networks: Protecting Privacy on the Web Kun Peng ISBN 978-1-4398-8157-6 Case Studies in Secure Computing: Achievements and Trends Biju Issac and Nauman Israr ISBN 978-1-4822-0706-4 Conducting Network Penetration and Espionage in a Global Environment Bruce Middleton ISBN 978-1-4822-0647-0 Cybersecurity: Protecting Critical Infrastructures from Cyber Attack and Cyber Warfare Thomas A. Johnson ISBN 978-1-4822-3922-5 Cybervetting: Internet Searches for Vetting, Investigations, and Open-Source Intelligence, Second Edition Edward J. Appel ISBN 978-1-4822-3885-3 Data Privacy for the Smart Grid Rebecca Herold and Christine Hertzog ISBN 978-1-4665-7337-6 Ethical Hacking and Penetration Testing Guide Rafay Baloch ISBN 978-1-4822-3161-8 Leading the Internal Audit Function Lynn Fountain ISBN 978-1-4987-3042-6 Multilevel Modeling of Secure Systems in QoP-ML Bogdan Księżopolski ISBN 978-1-4822-0255-7 Multilevel Security for Relational Databases Osama S. Faragallah, El-Sayed M. El-Rabaie, Fathi E. Abd El-Samie, Ahmed I. Sallam, and Hala S. El-Sayed ISBN 978-1-4822-0539-8 PCI Compliance: The Definitive Guide Abhay Bhargav ISBN 978-1-4398-8740-0 Secure Data Provenance and Inference Control with Semantic Web Bhavani Thuraisingham, Tyrone Cadenhead, Murat Kantarcioglu, and Vaibhav Khadilkar ISBN 978-1-4665-6943-0 Securing Cyber-Physical Systems Al-Sakib Khan Pathan ISBN 978-1-4987-0098-6 Securing Systems: Applied Security Architecture and Threat Models Brook S. E. Schoenfield ISBN 978-1-4822-3397-1 Security for Service Oriented Architectures Walter Williams ISBN 978-1-4665-8402-0 Security without Obscurity: A Guide to Confidentiality, Authentication, and Integrity J.J. Stapleton ISBN 978-1-4665-9214-8 The Frugal CISO: Using Innovation and Smart Approaches to Maximize Your Security Posture Kerry Ann Anderson ISBN 978-1-4822-2007-0 The Practical Guide to HIPAA Privacy and Security Compliance, Second Edition Rebecca Herold and Kevin Beaver ISBN 978-1-4398-5558-4 Web Security: A WhiteHat Perspective Hanqing Wu, Liz Zhao ISBN 978-1-4665-9261-2 AUERBACH PUBLICATIONS www.auerbach-publications.com • To Order Call: 1-800-272-7737 • E-mail: orders@crcpress.com © 2016 by Taylor Francis Group, LLC
- 26. BACKGROUND I © 2016 by Taylor Francis Group, LLC
- 27. Chapter 1 Introduction Dependable, Embedded Software This is a book about the development of dependable, embedded soft- ware. It is traditional to begin books and articles about embedded software with the statistic of how many more lines of embedded code there are in a modern motor car than in a modern airliner. It is traditional to start books and articles about dependable code with a homily about the penalties of finding bugs late in the development process — the well-known exponential cost curve. What inhibits me from this approach is that I have read Laurent Bossavit’s wonderful book, The Leprechauns of Software Engineering (reference [1]), which ruthlessly investigates such “well-known” soft- ware engineering preconceptions and exposes their lack of foundation. In particular, Bossavit points out the circular logic associated with the exponential cost of finding and fixing bugs later in the development process: “Software engineering is a social process, not a naturally oc- curring one — it therefore has the property that what we believe about software engineering has causal impacts on what is real about software engineering.” Because we expect it to be more expensive to fix bugs later in the development process, we have created procedures that make it more expensive. Bossavit’s observation is important and will be invoked several times in this book because I hope to shake your faith in other “leprechauns” associated with embedded software. 3 © 2016 by Taylor Francis Group, LLC
- 28. 4 Introduction Safety Culture A safety culture is a culture that allows the boss to hear bad news. Sidney Dekker Most of this book addresses the technical aspects of building a product that can be certified to a standard, such as IEC 61508 or ISO 26262. There is one additional, critically important aspect of building a prod- uct that could affect public safety — the responsibilities carried by the individual designers, implementers and verification engineers. It is easy to read the safety standards mechanically, and treat their requirements as hoops through which the project has to jump, but those standards were written to be read by people working within a safety culture. Annex B of ISO 26262-2 provides a list of examples indicative of good or poor safety cultures, including “groupthink” (bad), intellec- tual diversity within the team (good), and a culture of identifying and disclosing potential risks to safety (good). Everyone concerned with the development of a safety-critical device needs to be aware that human life may hang on the quality of the design and implementation. Anecdote 1 I first started to think about the safety-critical aspects of a design in the late 1980s when I was managing the development of a piece of telecommunications equipment. A programmer, reading the code at his desk, realized that a safety check in our product could be bypassed. The system was designed in such a way that, when a technician was working on the equipment, a high-voltage test was carried out on the external line as a safety measure. If a high voltage was present, the software refused to close the relays that connected the technician’s equipment to the line. The fault found by the programmer allowed the high-voltage check to be omitted under very unusual conditions. I was under significant pressure from my management to ship the product. It was pointed out that high voltages rarely were present and, even if they were, it was only under very unusual circumstances that the check would be skipped. I now realize that, at that time, I had none of the techniques de- scribed in this book for assessing the situation and making a reasoned and justifiable decision. It was this incident that set me off down the road that has led to this book. © 2016 by Taylor Francis Group, LLC
- 29. Introduction 5 The official inquiry into the Deepwater Horizon tragedy (reference [2]) specifically addresses the safety culture within the oil and gas industry: “The immediate causes of the Macondo well blowout can be traced to a series of identifiable mistakes made by BP, Halliburton, and Transocean that reveal such systematic failures in risk management that they place in doubt the safety culture of the entire industry.” The term “safety culture” appears 116 times in the official Nimrod Review (reference [3]) following the investigation into the crash of the Nimrod aircraft XV230 in 2006. In particular, the review includes a whole chapter describing what is required of a safety culture and explicitly states that “The shortcomings in the current airworthiness system in the MOD are manifold and include . . . a Safety Culture that has allowed ‘business’ to eclipse Airworthiness.” In a healthy safety culture, any developer working on a safety- critical product has the right to know how to assess a risk, and has the duty to bring safety considerations forward. As Les Chambers said in his blog in February 2012∗ when comment- ing on the Deepwater Horizon tragedy: We have an ethical duty to come out of our mathemati- cal sandboxes and take more social responsibility for the systems we build — even if this means career threatening conflict with a powerful boss. Knowledge is the tradi- tional currency of engineering, but we must also deal in belief. One other question that Chambers addresses in that blog posting is whether it is acceptable to pass a decision “upwards.” In the incident described in Anecdote 1, I refused to sign the release documentation and passed the decision to my boss. Would that have absolved me morally or legally from any guilt in the matter, had the equipment been shipped and had an injury resulted? In fact, my boss also refused to sign and shipment was delayed at great expense. I am reminded of an anecdote told at a conference on safety-critical systems that I attended a few years back. One of the delegates said that he had a friend who was a lawyer. This lawyer quite often defended engineers who had been accused of developing a defective product that had caused serious injury or death. Apparently, the lawyer was usu- ally confident that he could get the engineer proven innocent if the case came to court. But in many cases the case never came to court because ∗ http://www.systemsengineeringblog.com/deus_ex_machina/ © 2016 by Taylor Francis Group, LLC
- 30. 6 Introduction the engineer had committed suicide. This anecdote killed the conver- sation as we all reflected on its implications for each of us personally. Our Path I have structured this book as follows: Background material. Chapter 2 introduces some of the terminology to be found later in the book. This is important because words such as fault, error, and failure, often used almost interchangeably in everyday life, have much sharper meanings when discussing embedded systems. A device to be used in a safety-critical application will be de- veloped in accordance with the requirements of an international standard. Reference [4] by John McDermid and Andrew Rae points out that there are several hundred standards related to safety engineering. From this smörgåsbord, I have chosen a small number for discussion in Chapter 3, in particular IEC 61508, which relates to industrial systems and forms the foundation for many other standards; ISO 26262 which extends and specializes IEC 61508 for systems within cars; and IEC 62304, which covers software in medical devices. I also mention other standards, for example, IEC 29119, the software testing standard, and EN 50128, the railway standard, to support my arguments here and there in the text. To make some of the discussion more concrete, in Chapter 4 I introduce two fictitious companies. One of these is producing a device for sale into a safety-critical market, and the other is providing a component for that device. This allows me to illustrate how these two companies might work together within the framework of the standards. Developing a product for a safety-critical application. Chapter 5 describes the analyses that are carried out for any such development — a hazard and risk analysis, the safety case analysis, the failure analysis, etc. — and Chapter 6 discusses the problems associated with incorporating external (possibly third-party) components into a safety-critical device. Techniques recommended in the standards. Both IEC 61508 and ISO 26262 contain a large number of tables recommending various techniques to be applied during a soft- © 2016 by Taylor Francis Group, LLC
- 31. Introduction 7 ware development. Many of these are commonly used in any software development (e.g., interface testing), but some are less well-known. Chapters 7 to 19 cover some of these less common techniques. For convenience, I have divided these into patterns used during the architecture and design of a product (Chapters 7 to 10), the tools that are used to ensure the validity of the design (Chapters 11 to 15), the techniques used during implementation (Chapters 16 to 18), and those used during implementation verification (Chapter 19). Development tools One essential, but sometimes overlooked, task during a devel- opment is preparing evidence of the correct operation of the tools used; it is irrelevant whether or not the programmers are producing good code if the compiler is compiling it incorrectly. Chapter 20 provides some insights into how such evidence might be collected. I introduce the goal structuring notation and Bayesian belief networks in Chapter 5, but relegate details about them to Appendices A and B respectively. Finally, there is a little mathematics here and there in this book. Appendix C describes the notations I have used. Choosing the Techniques to Describe I have used three criteria to guide me in selecting the tools and tech- niques to describe: 1. The technique should be explicitly recommended in IEC 61508 or ISO 26262 or both. I think that I have only included one technique not directly recommended in those standards. 2. I should have made direct use of the tool or technique myself. 3. The tool or technique should not be in common use in the ma- jority of companies that I have recently visited. Development Approach There are many development methodologies ranging from pure water- fall (to which Bossavit dedicates an entire chapter and appendix in ref- erence [1]) through modified waterfall, design-to-schedule, theory-W, © 2016 by Taylor Francis Group, LLC
- 32. 8 Introduction joint application development, rapid application development, timebox development, rapid prototyping, agile development with SCRUM to eXtreme programming. I do not wish to take sides in the debate about which of these tech- niques is the most appropriate for the development of an embedded system, and so, throughout this book, I will make use of the composite approach outlined in Figure 1.1. Initial Design Cycle D e t a i l e d D e s i g n C y c l e Implementation Cycle D e s i g n V e r i f i c a t i o n C y c l e automatic code generation Implementation Verification Implementation Design Verification Failure Analysis Gross Dependability Analysis Selection of Design Patterns Analysis of Requirements Safety Case Selection of Implementation Patterns manual code generation Figure 1.1 The suggested approach. © 2016 by Taylor Francis Group, LLC
- 33. Introduction 9 During a development process, certain tasks have to be completed (although typically not sequentially): Initial design cycle. During the initial design cycle, shown at the bottom of Figure 1.1 the requirements for a component or system are analyzed and proposals made for possible designs. These are subject to “quick-and-dirty” analysis (often a Markov Model: see Chapter 11) to see whether they could possibly offer the dependability required to form the basis of the final design. Detailed design cycle. Once one or more candidate designs are selected, a full failure analysis is performed. Whether the failure analysis is carried out by means of a simple Markov model, or by more sophis- ticated techniques such as fault tree analysis (Chapter 12), the predicted failure rate of the software must be known. Determin- ing the failure rate of software is a thorny issue which I address in Chapter 13. Design verification cycle. When the elements of the design have been selected, the design will need to be verified: Does it handle all possible circum- stances, could the device ever lockup and not make progress, etc.? Implementation cycle. Once the design is complete, implementation begins and pat- terns must be chosen to implement and verify the implementa- tion of the product. Note that I have carefully avoided saying whether these cycles are fol- lowed only once for the development of a particular device (a waterfall process), or are followed for each component, perhaps repeating once every few weeks (an agile process) or even once per day (eXtreme pro- gramming). Given this spectrum of methodologies, I have my personal belief about the end of the spectrum most likely to result in a successful project delivered on-time and on-budget and meeting its safety require- ments, but that belief is irrelevant to this book — the techniques I describe are necessary whatever approach is chosen. However, one point can be noted from the list above: I have placed a lot more emphasis on design and design verification than on imple- mentation and implementation verification. That is deliberate, and in Chapter 15, I try to justify my claim that the skills required for de- signing and for implementing are sufficiently diverse that it is unlikely © 2016 by Taylor Francis Group, LLC
- 34. 10 Introduction that one person can do both. Another point emphasized by Figure 1.1 is the central role played by the safety case. All of the analyses and decisions made during the project must become elements of the safety case. This essential document is described in Chapter 5, starting on page 61. Today’s Challenges Although the last ten to fifteen years have seen a tremendous growth in tools and techniques that we can apply to the development of safe, embedded systems, challenges still remain and new ones are emerging. Security Safety is now interlinked with security — the behavior of an insecure device is effectively unpredictable once a hacker has broken in. This topic is discussed briefly on page 92, but no general methodology exists for combining security and safety issues. In the past, many embedded systems have been physically secure, being locked in the driver’s cab of a train or behind a locked fence on a shop floor. Today almost every device supports external communications through Wi-Fi, Bluetooth, USB drives, or from GPS satellites, and these channels are all security vulnerabilities. In reference [5], Peter Bernard Ladkin discusses whether the inter- action between the company operating a safety-critical system and a malicious attacker can be modeled as a form of game theory, actually a form of meta-game theory, because each protagonist can choose the game to play. He believes that this approach is much more suitable for assessing security threats than the hazard and risk approaches de- scribed in the safety standards. Tools for Balancing Architectural Needs Chapter 7 identifies the need for an architect and a designer to balance the availability, reliability, performance, usefulness, security, and safety of a system. These characteristics interact, and a design decision in one area will affect all the others. I know of no tools that can help an analyst manipulate these system characteristics and trade one off against the others. © 2016 by Taylor Francis Group, LLC
- 35. Introduction 11 Hardware Error Detection As described on page 136, processor and memory hardware has become significantly less reliable over the last decade. This has occurred as a result of the increased complexity of chips (most processors come with 20 or more pages of errata), and the reduced size of cells that has made them more susceptible to cross-talk, electromagnetic interference and the secondary effects of cosmic rays. To make matters worse, much of a modern processor, including caches and coprocessors, is hidden from the operating system, and application programs and so errors cannot be detected directly, only through their effect on program operation. New processors are emerging that offer improved levels of error de- tection, but these are more expensive and not yet fit-for-purpose. Deadline Prediction Many embedded systems in the past have been very simple, and it has been possible to perform real-time calculations to show that, under all circumstances, certain deadlines will be met. As real-time appli- cations∗ migrate to running alongside other applications on multicore processors with non-deterministic instruction and data caches, these hard guarantees are disappearing and being replaced by guarantees of the form “the probability of deadline X being missed is less than 10−6 per hour of operation.” There are few tools beyond discrete-event simulation (see page 190) that allow these sorts of calculations to be performed. Data The development of safety-critical systems has only recently begun to take data, particularly configuration data, seriously. Until a few years ago, analysis tended to concentrate on two aspects of a system: hard- ware and software. It is now becoming increasingly recognized that there is a third element that is equally important: data. Under the direction of Mike Parsons, the Data Safety Initiative Working Group (DSIWG), which is part of the Safety Critical Sys- tems Club (SCSC), has prepared some very useful guidelines on the use of data in safety-critical systems, but much more work is needed in this area. Annex A of the report presented by the DSIWG to the 2015 Safety Critical Systems Symposium and the associated paper, ref- ∗ For a definition of “real-time,” see page 23. © 2016 by Taylor Francis Group, LLC
- 36. 12 Introduction erence [6] by Paul Hampton and Mike Parsons, contains a chilling list of examples where human life has been lost through data errors, rather than hardware or software errors. References 1. L. Bossavit, The Leprechauns of Software Engineering: How Folklaw Turns into Fact and What to Do about It. Leanpub, 2013. 2. B. Graham, W. K. Reilly, F. Beinecke, D. F. Boesch, T. D. Garcia, C. A. Murray, and F. Ulmer, “Deep Water — The Gulf Oil Disaster and the Future of Offshore Drilling: Report to the President,” 2011. 3. C. Haddon-Cave, The Nimrod Review. UK Government, 2009. 4. J. McDermid and A. Rae, “Goal-Based Safety Standards: Promises and Pitfalls,” in 2012 Safety Critical Systems Symposium, SSS ’12, (Bristol, UK), Safety-Critical Systems Club, 2012. 5. P. B. Ladkin, “Risks People Take and Games People Play,” in 2015 Safety Critical Systems Symposium, SSS ’15, Safety-Critical Systems Club, 2015. 6. P. Hampton and M. Parsons, “The Data Elephant,” in 2015 Safety Critical Systems Symposium, SSS ’15, Safety-Critical Systems Club, 2015. © 2016 by Taylor Francis Group, LLC
- 37. Chapter 2 Terminology of Safety To-day we have naming of parts. Henry Reed In order to discuss safety-critical software, we need to distinguish be- tween terms that are used almost interchangeably in everyday use. Differentiating, for example, between a “fault,” an “error,” and a “fail- ure” allows us to tackle them with different techniques; differentiating between “availability” and “reliability” allows us to balance the two in our system. This chapter describes a few of these terms. General Safety Terminology Hazard, Risk, Mitigation, and Residual Risk The iceberg is the hazard; the risk is that a ship will run into it. One mitigation might be to paint the iceberg yellow to make it more visible. Even when painted yellow, there is still the residual risk that a collision might happen at night or in fog. More generally, a hazard is something passive that exists in the environment and which may be the cause of risks. Risks are active and may give rise to dangerous conditions. When a risk has been identified, if it is serious enough, it will need to be mitigated; that is, action will need to be taken to reduce it. To take an example more pertinent to embedded software, the mem- ory used by the processor may be a hazard. The risks associated with it may include the following: 13 © 2016 by Taylor Francis Group, LLC
- 38. 14 Terminology Risk: The secondary effects of cosmic rays. These may cause a bit-flip in the configuration memory, chang- ing the device’s operating mode unexpectedly and potentially giving rise to a dangerous situation. One mitigation against this risk might be to use error check- ing and correcting memory (ECC) so that the errors are detected (and possibly corrected). Residual risks include the facts that not all errors are de- tected by ECC memory, that the application may not correctly handle the interrupt indicating the memory error and the fact that ECC may not cover caches. Risk: The exhaustion of memory. An application may have a memory leak and, being unable to access additional memory, may fail in an unexpected way, po- tentially causing a dangerous situation. One mitigation might be for each application to reserve suf- ficient memory statically at startup and never release it. There is still a residual risk that the amount of statically allocated memory is inadequate when a condition occurs that was never considered during design and test. Usually, there are several risks associated with each hazard, and several mitigations associated with each risk. Availability, Reliability, and Dependability When a software subsystem is invoked, it may fail in one of two ways: It may fail to give a timely answer at all, or it may respond, but with the wrong answer. The failure to provide an answer within the time that makes it useful is termed an availability problem; the timely presentation of the wrong answer is a reliability problem. Increasing availability generally reduces reliability and vice versa. Consider a server that performs some form of calculation. We can increase the reliability of that system by getting two servers to do the calculation and compare their answers. This is a venerable technique: When the formula is very complicated, it may be alge- braically arranged for computation in two or more dis- tinct ways, and two or more sets of cards may be made. If the same constants are now employed with each set, and if under these circumstances the results agree, we may be quite secure in the accuracy of them. Charles Babbage, 1837 (reference [1]) © 2016 by Taylor Francis Group, LLC
- 39. Terminology 15 Unfortunately, although it improves the reliability of some systems, duplication of this nature reduces availability — if either of the two servers is unavailable, then the entire system is unavailable. Given this antagonism between availability and reliability, it is im- portant during the design process to understand which is to be empha- sized in that design and how a balance is to be achieved. This topic is explored further on page 90. It is relatively easy to think of systems where reliability is essential to safety, even at the expense of availability. It is harder, but possible, to imagine systems where availability is more important. In reference [2], Mats Heimdahl describes a deliberately far-fetched example of a system where any increase in reliability will make the system less safe. Note that, while the clients of a service can, in general, measure the availability of the server they are accessing, it is often impossible for them to measure the server’s reliability — if the clients knew the correct answer then they presumably wouldn’t have needed to invoke the provider. Much of program testing is really testing reliability, only checking availability in passing. In this book, I use the term “dependability” to combine the two terms “availability” and “reliability,” whichever is the more important for the system under consideration. A common definition of “depend- able” is that a system is dependable if it delivers a service that can be justifiably trusted. Functional Safety Safety can be provided in different ways. Consider a laser on a piece of telecommunications transmission equipment: such a laser is a hazard. One risk associated with this hazard is that if an operator removed the fiber and looked into the transmitter, eye damage could result. One way of mitigating this risk might be to install the transmitter facing downward close to the bottom of the rack — the position making it impossible for an operator to align an eye with the transmitter. This would be safe, relying on a passive safety system. Another way of mitigating the risk would be to have software moni- toring the connector and turning the laser off if the fiber were removed. To be safe, this requires an active component, the software, to function correctly. The software must be monitoring the connector all the time and must turn the laser off within a few milliseconds to prevent harm. The second of these techniques represents functional safety: Some- thing must continue to function in order to keep the system safe. © 2016 by Taylor Francis Group, LLC
- 40. 16 Terminology Fault, Error, and Failure A programmer may introduce a fault into a program by typing some- thing unintended into an editor. A fault is a passive flaw. Sometimes a fault may cause the program to perform in a way that produces an unintended outcome, the fault having caused an error. Sometimes an error causes a failure of the system. In the words of EN 50128, “a failure has occurred if a functional unit is no longer able to perform its required function, i.e., a failure is an observable effect outside the system boundary arising from an internal error or fault. An error or fault does not always lead to a failure.” The important word in these descriptions is “sometimes.” As the quotation from EN 50128 states, a fault does not always cause an error. If, for example, the programmer had meant to type char x[10]; for a local variable, and accidentally typed char x[11]; that is unlikely to cause an error unless the system is very short of memory. It is, however, a fault. If a programmer created a system that opened a file every 10 sec- onds, but failed to close those files, then this fault would cause an error every 10 seconds (a leak of a file descriptor). However, that error would not cause a failure for some time — not for about 90 days for the com- puter on which this paragraph was typed, which permits up to 777,101 open file descriptors. For a real example, see Anecdote 9 on page 114. As illustrated in Figure 2.1, an error at one level in a system may cause a fault at another. In that figure, a fault in Fred’s training causes him to insert a bug in the code (he makes an error by inserting a fault). Fred loses his job over this mistake (a failure — at least as far as Fred is concerned). The fault in the code goes on to cause a failure in the overall system. Differentiating between faults, errors, and failures allows us to tackle them in different ways — we want to reduce the number of faults in- serted into the system, to detect and remove faults before they become errors, to detect errors and prevent them from becoming failures and, if a failure does occur, to handle it in the safest way possible. © 2016 by Taylor Francis Group, LLC
- 41. Terminology 17 Fault Error Failure Fault Error Failure There is a fault in Fred's training As a result, he makes an error and puts a fault into the code The error may cause Fred to lose his job The fault causes data to be overwritten The fault Fred introduced Fault Error Failure The database fault changes the stored dosage The corrupted data represent a fault in the database The incorrect dosage causes patient distress Figure 2.1 Faults, errors, and failures. Formal, Semi-formal, and Informal Languages Natural languages — English, Mandarin, German, Inuktitut — are ambiguous and subtle. The oft-repeated reference given for an ex-employee, “You’ll be lucky to get this person to work for you,” illustrates the ambiguity of English. Another job reference, once apparently given for a candi- date applying for a position as a philosophy professor, “This person has very nice handwriting,” illustrates its subtlety. Such a language is considered to be informal because both its syntax (grammar) and its semantics (meaning) are ambiguous. It is possible to make a language’s syntax formal, while retaining the flexibility of informal semantics and such languages are known as semi-formal. The universal modeling language, UML, and the systems modeling language, SysML, are both often used in a semi-formal man- ner. The syntax is well-defined in that an open, triangular arrow head always means “generalisation,” and a stick figure always means “actor”. However, when a block in a SysML diagram is labelled “Braking Sys- tem,” there is no definition of what that means, the everyday English usage being assumed. The language of mathematics allows us to express ideas about uni- versals. Mathematics doesn’t understand what a triangle actually is, but it can prove that the angles in any triangle add up to 180 degrees. The principle of duality in geometry emphasizes the abstraction from real objects by saying that, with a few constraints, we can exchange © 2016 by Taylor Francis Group, LLC
- 42. 18 Terminology the terms “point” and “line” and all the geometric theorems remain true. For example, two points/lines define a line/point. If we can express our designs in a mathematical (i.e., formal) lan- guage, then it should be possible to reason about universal concepts. Given our system design, we should be able to prove mathematically that for any combination and sequence of requests and interrupts, the system will continue to make progress and not lock up. Proving the correctness of a system differs from testing it: Testing demonstrates that it works for the particular set of conditions that oc- curred during the testing, whereas proving demonstrates that it works under all conditions. Safety, Liveness, and Fairness It is convenient to be able to distinguish between safety, liveness and fairness properties of a system, terms first coined by Leslie Lamport in 1983. Informally: A safety property says that the system never does anything bad, i.e., it remains safe. For example, the system will never transmit message A unless it has previously received message B. A liveness property says that the system eventually does something good, i.e., it will make progress and not live- or dead-lock. For example, if message B is received, then message A will always eventually be transmitted. A fairness property says that, if the system attempts actions, then those actions will eventually succeed, i.e., the system will not allow one activity to “take over” so that another activity’s re- quests remain permanently unanswered. There are many variations on fairness ranging from strong fairness (if the system attempts X infinitely often, then it will succeed infinitely often) to weaker forms (e.g., if the system continuously attempts X, then it will succeed at least once). In the case of a safety property, there is a finite (although possibly very large) set of states to be examined to check whether that property is valid. In this case the check may be practically infeasible, but can theoretically be performed. For a liveness property, the number of possible states that need to be checked is potentially infinite because of the term “eventually.” © 2016 by Taylor Francis Group, LLC
- 43. Terminology 19 Backward and Forward Error Recovery When a fault causes an error, that error can sometimes be trapped and some form of recovery can take place before a failure occurs. The two main forms of error recovery are: Backward Error Recovery. Once an error is discovered, the system returns to a previously- stored state that is known (or believed) to be consistent and sane. Whether the input that apparently caused the error is then reapplied or discarded, and how the client is notified, vary between implementations. One of the disadvantages of backward error recovery is the need to store the system’s state information before handling an incoming request so that it is available if rollback is required. Forward Error Recovery. This removes the main disadvantage of backward error recovery — the need to save the system’s state — by moving to a prede- fined sane state independent of both the previous state and the input that caused the error. Accidental Systems In the presentation associated with reference [3], Martyn Thomas de- scribed an experiment wherein global positioning system (GPS) signals were deliberately jammed in part of the North Sea and a ship was taken through the area to see what would happen. As expected, the position of the ship became imprecise (sometimes the ship was in the middle of Norway, sometimes in the middle of Germany!), but unexpectedly, the ship’s radar also stopped working. The experimental team contacted the company that manufactured the radar and was told that GPS was not used within it. They then contacted the manufacturers of the com- ponents in the radar and found that one small component was using GPS timing signals. The radar constitutes an “accidental system.” The manufacturer of the small component knew that any system into which it was incorpo- rated would rely on the integrity of the GPS signals, but was not aware of the radar system into which the component was being incorporated. The designer of the radar was unaware of the dependency. No one had the full picture, and a system had been built with accidental depen- dencies. The system would not have been tested in the face of GPS jamming, because the reliance on GPS was unknown. Embedded software-based systems can also become accidental sys- tems. Perhaps the designers of the complete system were unaware that © 2016 by Taylor Francis Group, LLC
- 44. 20 Terminology an incorporated component was single-threaded or included recursion that could exceed the allocated stack size. Software-Specific Terminology Software In a book dedicated to embedded software, it may seem strange to ask what software is — intuitively people feel that they can differentiate between software and hardware. If it hurts when dropped on one’s foot, it’s hardware. But what about an Application-Specific Integrated Circuit (ASIC) designed by a software tool? What about 5000 lines of C code generated by a modeling tool? Reference [4], published by the Rail Safety and Standards Board, treats the distinction between hardware and software pragmatically by noting that software is intrinsically more complex than hardware: As a rule of thumb, we suggest that if a device has few enough internal stored states that it is practical to cover them all in testing, it may be better to regard it as hard- ware and to show that it meets its safety requirements by analysis of the design and testing of the completed de- vice, including exhaustive testing of all input and state combinations. This is the definition that we will use in this book. If the system is sufficiently simple that it can be tested exhaustively, then it will be treated as hardware; otherwise as software. Note that this is a one-way definition. Certainly, the embedded sys- tems considered in this book are too complex for exhaustive testing and will therefore be treated as software. However, it has also been impos- sible to test some hardware devices exhaustively for many years. For example, even a 64 kbit RAM (ludicrously small by today’s standards) has 264×1024 possible states — a number containing 19,728 digits — and, under the definition in reference [4], could be considered software. I will ignore that interpretation. There is another aspect of software that is often neglected: config- uration data. Commission Regulation (EC) No 482/2008 of the Euro- pean Union, explicitly defines the term “software” to include its asso- ciated configuration data: © 2016 by Taylor Francis Group, LLC
- 45. Terminology 21 ‘software’ means computer programmes and correspond- ing configuration data . . . ‘configuration data’ means data that configures a generic software system to a particular instance of its use; Following the crash of an Airbus A400M military transport aircraft on 9th May 2015, an executive of Airbus Group confirmed in an interview with the German newspaper Handelsblatt that the crash was caused by a faulty software configuration. In particular, the executive said that “The error was not in the code itself, but in configuration settings programmed into the electronic control unit (ECU) of the engines.” Validating a program together with its configuration data is not well understood because of the combinatorial problem associated with con- figuration. If a program takes 5 configuration options, each of which can have any of 3 values, then there are really 35 = 243 different pro- grams to verify — see the discussion of combinatorial testing on page 257. The importance of including configuration data in program veri- fication is being increasingly recognized, and new standards are likely to emerge over the next few years. Heisenbugs and Bohrbugs Niels Bohr described a solid, billiard-ball model of the atom and won the 1922 Nobel Prize for his work. Werner Heisenberg, a student and colleague of Bohr’s, enhanced this model to make the atom much more uncertain: a probabilistic model of where the electrons, neutrons and protons might be. This work won Heisenberg the Nobel Prize in 1932. The etymology of the related terms Bohrbug and Heisenbug is un- clear, although Jim Gray used the term “Heisenbug” in a 1983 paper. It is believed to have originated sometime in the early 1980s. As with the atoms, so with the bugs. A Bohrbug is a nicely defined, solid bug with properties that don’t change when debug code is added to find the bug. Every time a particular line of code is executed with particular values of the input variables, the system misbehaves. A Heisenbug, in contrast, is a will-of-the-wisp that appears and disappears in a manner that makes it extremely elusive. Heisenbugs are caused by subtle timing problems: Thread A running on processor core 0 does something that affects thread B running on processor core 1 if, and only if, an interrupt of type C occurs, . . . . Heisenbugs are reported by test groups as being non-reproducible: “The eighth time that test case 1243 was run, the system crashed. We’ve run that test case several dozen times since, and no other failure has occurred. No memory dump is available. Please fix the bug.” © 2016 by Taylor Francis Group, LLC
- 46. 22 Terminology System Fault ......... Potential Errors ......... Failures as observed by the test group or customers Fault Fault Faults that must be traced and fixed by the development group Debugging ......................... Figure 2.2 Tracing the failure to the fault. It is a characteristic of Heisenbugs that the same fault can give rise to different failures, and the failures can occur much later than when the fault was invoked (and in an entirely different piece of code). This is what makes debugging difficult: Testing detects failures, whereas the developers must fix faults. For all faults, but particularly for Heisen- bugs, the path from the fault to the failure is many-to-many and this makes tracing the fault, given the failure, very difficult — see Figure 2.2. At the level that can be observed by a tester, many failures appear to be identical. The errors that cause the failures are invisible to both tester and programmer, and different faults may give rise to essentially identical errors. Jim Gray made the point, although not in the context of safety- critical systems, that users prefer Heisenbugs to Bohrbugs; they prefer a failure occurring randomly about once a month to a failure every time a certain command is entered in a particular context. For this reason, research has been carried out (e.g., reference [5]) on converting Bohrbugs into Heisenbugs. For example, if more memory is allocated for an object than is strictly required and the memory is allocated © 2016 by Taylor Francis Group, LLC
- 47. Terminology 23 probabilistically, a memory overflow becomes a Heisenbug rather than a Bohrbug. The elusive nature of Heisenbugs make them particularly difficult to fix, and some researchers, particularly Andrea Borr (see, for example, reference [6]), have found that attempts to fix Heisenbugs generally make the situation worse than it was before. Irreverent programmers have extended the Bohrbug and Heisen- bug terminology in more comical directions. Named after Erwin Schrödinger (Nobel Laureate in 1933), the Schrödingbug, for exam- ple, is a fault that has been in the code for many years and has never caused a problem in the field. While reading the code one day, a pro- grammer notices the bug. Immediately, field reports start to flow in as the bug, having now been observed, like Schrödinger’s cat suddenly wakes up in the field. Real-Time The term real-time is perhaps one of the most confusing and misused terms in software development. A system is real-time simply if its required behavior includes a time constraint. Hence, a program that calculates a weather forecast from currently- available data is a real-time program because an excellent forecast for a period 12 hours ahead is useless if it takes 14 hours to produce. Similarly, the payroll calculations performed by companies to pay their employees are real-time because failure to complete them on time could lead to very unhappy employees. Within the embedded world, a system is real-time if part of its contract specifies a time within which it will respond: “This system reads the sensor every 10±2ms and makes the processed data available within 5 ms of the reading.” Fallacy 1 “Real-time” means “fast.” Real-time systems tend to be slower than non-real-time ones because of the time buffering needed to ensure that deadlines are always met, irrespective of the timing of other subsystems. © 2016 by Taylor Francis Group, LLC
- 48. 24 Terminology Programming by Contract The concept of programming by contract or contract-first development was devised by Bertrand Meyer for the Eiffel programming language in the late 1980s∗ and is now available in other languages, such as D. Programming by contract defines a three-part formal contract between a client and a server: 1. The client has an obligation to ensure that its request meets the server’s preconditions. For example, a precondition for invoking the function to add an item to a queue may be that the queue is not already full. 2. The server guarantees that certain post-conditions will apply to its response. In the case of adding an item to a queue, this would include the fact that the queue has exactly one more element than it had previously and that the last element on the queue is the one provided by the client. 3. The server guarantees that certain internal invariants will apply on exit so that the next call to it will also be answered correctly. If the contracts are coded into the server program when it is written, then not only can they be checked at runtime to catch otherwise difficult to find bugs, but they can also be used to assist static analysis tools with their work: see reference [7] and Chapter 18. For example, given the queue add() function above, a static anal- ysis tool could analyze the whole code base to determine whether it could ever be possible for the function to be called when the queue was already full. References 1. C. Babbage, “On the Mathematical Powers of the Calculating Engine.” (Published in Origins of Digital Computers: Selected Papers (ed. B. Ran- dell) Springer-Verlag, 1973), 1837. 2. M. P. E. Heimdahl, “Safety and software intensive systems: Challenges old and new,” in 2007 Future of Software Engineering, FOSE ’07, (Washington, DC, USA), pp. 137–152, IEEE Computer Society, 2007. 3. M. Thomas, “Accidental Systems, Hidden Assumptions and Safety Assur- ance,” in SSS (C. Dale and T. Anderson, eds.), pp. 1–9, Springer, 2012. ∗ Note that Eiffel Software is the owner of the copyright on the related term Design by Contract. © 2016 by Taylor Francis Group, LLC
- 49. Terminology 25 4. Rail Safety and Standards Board, “Engineering Safety Management (The Yellow Book),” 2007. Available from www.yellowbook-rail.org.uk. 5. E. D. Berger, “Software needs seatbelts and airbags,” Commun. ACM, vol. 55, pp. 48–53, Sept. 2012. 6. A. J. Borr and C. Wilhelmy, “Highly-Available Data Services for UNIX Client-Server Networks: Why Fault Tolerant Hardware Isn’t the Answer,” in Hardware and Software Architectures for Fault Tolerance, pp. 285–304, 1993. 7. R. Ceballos, R. M. Gasca, and D. Borrego, “Constraint Satisfaction Tech- niques for Diagnosing Errors in Design by Contract Software,” in Proceedings of the 2005 conference on specification and verification of component-based systems, SAVCBS ’05, (New York, NY, USA), ACM, 2005. © 2016 by Taylor Francis Group, LLC
- 50. Chapter 3 Safety Standards and Certification All too often, writers of standards focus on questions of what constitutes good practice, and lose sight of what the followers of those standards truly need to demonstrate in order to show safety. Safety is demonstrated not by compliance with prescribed processes, but by assessing hazards, mitigating those hazards, and showing that the residual risk is acceptable. From reference [1] Standards Bodies It is said that the good thing about standards is that, if you don’t like one, then there is always another that you can apply instead. In reference [2], John McDermid and Andrew Rae actually say “it is hard to count [the safety engineering standards], but there are probably several hundred.” And, of course, there is no clear boundary around the safety standards — is IEC 29119, a standard that covers software testing, a safety standard or not? There are also numerous bodies that produce standards. In this book I concentrate on a small number of standards produced by two organizations: the International Electrotechnical Commission (IEC) and the International Organization for Standards (ISO). Both of these organizations are based in Switzerland, and although 27 © 2016 by Taylor Francis Group, LLC
- 51. 28 Safety Standards each produces its own standards, many standards are cross-issued. Thus, ISO/IEC/IEEE 42010, the standard describing how the archi- tecture of a system may be captured, has joint prefixes. One characteristic of both the IEC and ISO is that, unlike standards bodies such as the Internet Engineering Task Force (IETF) and the Distributed Management Task Force (DMTF), they charge for access to the standards. A single-user licence to read IEC 61508 costs around $1600 US: about $2.39 US for each of the 670 pages in the English edition. Note that this is for a single-user licence and if several people in an organization need to be able to read it, then either several licences or a more expensive site licence must be bought. Anecdote 2 One company for which I worked purchased a copy of one of the safety standards for me — a single reader licence. Unfor- tunately, when the PDF version was downloaded, it was marked on every page with the name of the person within the company’s purchas- ing department who had actually placed the order. Strictly, only that person was allowed to read it, and I was not allowed to look at it. This revenue source has been criticized for putting a barrier between companies, particularly small companies, and legal copies of important standards. It has been suggested that the IEC and ISO should provide the standards free of charge and get their revenue from the standard- ization process itself: a royalty whenever a certification body issues a certificate against a standard. This would encourage the production of useful standards, as the more a standard was used, the greater would be the revenue from it. However, questions of conflict of interest might arise if this model were adopted, because the IEC and ISO are required to be independent of the certification process. Standards from the IEC and ISO are produced in basically the same way: Industry experts work to create a standard, and the acceptance of the standard depends on the results of a vote, where each country participating in the IEC or ISO gets a single vote. Thus, the UK, Germany, China, and the USA each get one vote, as do Luxembourg, Mongolia, and Bhutan. To influence the vote on a particular ISO standard, an engineer needs to become associated with her country’s standards body: the Bureau voor Normalisatie in Belgium, the British Standards Institution in the UK, the Deutsches Institut für Normung (DIN) in Germany, © 2016 by Taylor Francis Group, LLC
- 52. Safety Standards 29 the American National Standards Institute in the USA, the Standards Council of Canada, etc. Accreditation and Certification e.g., UKAS: UK DAkkS: Germany CNAS: China HKAS: Hong Kong DA: Albania a c c r e d i t s c e r t i fi e s Accreditation Authority Certification Body Process or Product Figure 3.1 Accreditation and certification. Figure 3.1 illustrates the accreditation and certification process: Certifying a product or process. A company that wants to have one of its processes or products certified against a particular standard could self-declare that the process or product meets all the requirements of the appropriate standard, possibly employing an external auditing company to confirm the declaration. Alternatively, the company could employ an independent cer- tification body to certify the process or product. Accreditation of certification bodies. In principle, any company could act as an external certification body, but companies can become “accredited” to issue certifi- cates for a particular standard. The certificate from a body that is not accredited is less commercially valuable than a certificate © 2016 by Taylor Francis Group, LLC
- 53. 30 Safety Standards from an accredited body. Certification bodies are accredited by national accreditation authorities to carry out particular certifications. Thus, a cer- tification body may be accredited to carry out certifications of hardware (but not software) against IEC 61508 up to safety integrity level 2 (SIL 2). A company looking for a certification body should carefully check the accreditations of the candidates to ensure that the certificate that will be finally issued will be credible and com- mercially valuable. Accrediting the accreditors. Each country that forms part of the International Accreditation Forum (IAF)∗ , has one or more accreditation body members that accredit certification bodies. As there is no higher body, the obvious question is quis custodiet ipsos custodes?— who accredits the accreditors? The answer is that they verify each other’s compliance in an ongoing cycle of evaluations. There is no reason why a company based in a particular country needs to seek certification from a certification body accredited in that coun- try; it may be commercially advantageous to get certification from a company accredited by the country where the most customers reside. Getting a certification to a standard such as IEC 61508 is not easy. Reference [3] was written by Martin Lloyd and Paul Reeve, two very experienced auditors working at that time for a UK certification body. The reference describes the success rate that they had recently seen for IEC 61508 and IEC 61511 certifications of software-based products. Of the twelve companies that had completed the certification process at the time of the report, only three (25%) had achieved certification — the others had failed, in some cases after investing a lot of money and time. Reference [3] is particularly useful because it lists some of the common reasons for failure. Martin Lloyd updated the paper in early 2015 (reference [4]) to include experience between 2010 and 2015. Many of the same reasons for failure still exist, but the failure rate has reduced. Martin believes that this is because companies are now more aware of what is required and are less likely to start the certification process if they do not have the necessary evidence. To maximize the chances of getting a product certified, it is useful to engage the certification company early in the development process. In particular, it can be useful to discuss the structure of the argument that will be presented in the safety case (see page 61) with the auditors ∗ http://www.iaf.nu © 2016 by Taylor Francis Group, LLC
- 54. Safety Standards 31 from the certification company well before the final audit. Even before the evidence is added, a confirmation or even an agreement that the argument will be satisfactory if backed by evidence is well worth having. Why Do We Need These Standards? In some areas, the need for standards is very clear. If there were no standard defining the shape and size of the electrical sockets in our houses, then it would be impossible to buy an electrical device with confidence that it would connect to the electrical supply. Indeed, it would be very convenient if electrical sockets were standardized across the world. The need for standards defining how devices with safety-critical re- quirements are to be built and classified is less obvious. Historically, the creation of standards (and not just safety-related ones) has often been driven by disasters. A disaster occurs and the public demands that it never occur again. The response is the creation of a standard to which industry must comply, with the intent of raising the quality of products and reducing the chance of a repetition. In this sense, the standard provides protection for a public that does not understand the engineering process. From the point of view of a product development organization, stan- dards can be a useful definition of “adequate” practices. A company new to the development of a safety-critical application would find a useful set of tools and techniques listed in IEC 61508, ISO 26262, EN 50128, or other standards. Complying with such standards could also be a mitigation in the event of a court case: “We were following industry best practices.” From the point of view of a company buying a component or sub- system for use in a safety-critical application, the standard forms a shorthand that simplifies contractual relationships: “The component must comply with IEC 61508 at SIL3” is easier to write than an ex- plicit statement of the acceptable failure rate, development processes, etc. During a roundtable discussion at a conference of safety engineers I attended recently, the panel was asked whether system safety had im- proved over the last decade as a result of the number of standards that had appeared. The unanimous agreement of the experts was that safety has improved, but because of more attention being paid to software de- velopment, rather than because of the application of the standards. © 2016 by Taylor Francis Group, LLC
- 55. Random documents with unrelated content Scribd suggests to you:
- 56. To light at my shoulder, And then led her in at the doorway, Miles wide from Woak Hill. And that's why folk thought, for a season, My mind were a-wand'ring With sorrow, when I were so sorely A-tried at Woak Hill. But no; that my Mary mid never Behold herself slighted I wanted to think that I guided My guide from Woak Hill. Barnes saw the pathos in the joy of utter physical weariness of a labourer, and one of his finest poems depicts a cottage under a swaying poplar: An' hands a-tired by day, were still, Wi' moonlight on the door. He always has that deep, quiet craving for the hearth, the fire, the protecting thatch of a cottage, which gives his work a pathetic touch. I think sometimes that Barnes must have been nearer to being cold, homeless and tired at times than is generally understood.
- 57. CHAPTER VII BERE REGIS AND THE ANCIENT FAMILY OF TURBERVILLE We who have passed into the Upper Air Thence behold Earth, and know how she is fair. More than her sister Stars sweet Earth doth love us: She holds our hearts: the Stars are high above us. O Mother Earth! Stars are too far and rare! Bere Regis, that blinking little place with a history extending back to Saxon times (identified by Doctor Stukeley with the Roman Ibernium), is a typical little Dorset town about seven miles to the north-west of Wareham. It makes a capital walk or ride from Dorchester, and it was this way I travelled. I left Dorchester by High Street East, ascending Yellowham Hill, the Yalbury Hill of Troy's affecting meeting with Fanny Robin, leaving Troy Town to pass through Puddletown and Tolpuddle. Evening had fallen when I arrived at Bere Regis, and the rising wind and flying wrack of clouds above seemed to presage a wild night. I was just wondering whether, although it looked so threatening, I dared ride on to Wareham, when my eyes rested on the Royal Oak Inn, with its Elizabethan barns, mossed and mouldering red tiles and axe-hewn timbers. It is at such houses, I thought, that men may stretch out weary legs and taste home-cured bacon (I heard the squeak of a pig in the outhouse), and such places are the homes of adventure. I will go in and call for ale and a bed.
- 58. So I walked straight into the courtyard, which backs upon the church, and found there a large man with considerable girth, a square, honest face and kindly eyes. He was wearing a cap, and wearing it in a fine rakish way too. His appearance gave me the impression that his wife had tossed the cap at him and failed to drop it on his head squarely, but had landed it in a lopsided manner, and then our friend had walked off without thinking anything more about it. He was singing a song to himself and staring at a pile of bundles of straw. He looked up and nodded good-humouredly. Looks like rain! said I. Aw 'es, tu be sure, now you come to mention it. I dawnt think rain's far off. Can you tell me, said I, if I can get a meal and a bed at this inn? What you like, returned the man, with a quick tilt of his head, which drew my eyes with a kind of fascination to his ill-balanced cap, but as I've nothing to do with the place I should ask the landlord avore me. Ah, to be sure, said I. Sorry to trouble you. I thought you might be the landlord. The man stopped singing his song to stare at me wide-eyed. Well, I beant; but it's a fine thing to be a landlord, with barrels o' beer down 'ouze and money in the bank. Then may I ask what trade you follow, said I, and why you study that straw so intently? Young fellow, said he, staring, I follow a main-zorry trade in these days. I be a thatcher, and thatching to-the-truth-of-music is about done for. If you look at these thatched cottages about Dorset they will tell their own story. Why, the reed is just thrown on the roof hugger-mugger. They can't thatch no more down this part, I can tellee; they lay it on all of a heap.
- 59. And is this the straw for thatching? I inquired. Yes, said he, smiling; they call them bundles of reed in Dorset— but in my country, which is Devon, they call 'em 'nitches o' reed.' Then you are not contented with your trade? Not quite, answered the thatcher, his face falling. It has always been my wish to have a little inn—and barrels o' beer down 'ouze and money.... Far better be a thatcher, said I. I'll be dalled ef I can see why. It's an out-of-doors life in the first place, said I. The thatcher nodded, and his cap looked about as perilous as the Leaning Tower of Pisa. It is a happier life, too, I should say. Aw! I an't ayerd nort about that, he returned. And who ever heard of a starving thatcher? Young fellow, he sighed, there soon will be no thatchers to starve. Tez a lost art is thatching. I am the last of my family to follow the trade, and we can go back three hundred years. Then thatch is dying out? Yes, chiefly on the score of it being hard to 'dout' in case of fire. 'Dout' is a strange old word. It means extinguish, I take it, said I. To be sure—extinguished. Maybe you've heard the story about the Devon gal who went to London as a maid and when she told the mistress she had 'douted' the kitchen fire she was told to say 'extinguished' in future, and not use such ill-sounding words. 'Ess,
- 60. mum,' she said, 'and shall I sting-guish the old cat before I go to bed?' The thatcher laughed in his deep chest. But thatch suits us Devon folk middlin' well, he continued. It's warm in winter and cool in summer, and will stand more buffeting by the wind and rain than all your cheap tiles and slates. And thatch is cheap too, perhaps? I ventured. On the contrary, he answered. Lukee, those nitches of reed cost four shillings each, and you want three hundred bundles for a good- sized roof. Then there is the best tar twine (which comes from Ireland), the spars and the labour to be counted in. It takes three weeks on the average house, but if the thatch is well laid it will last for thirty years, and if I set my heart on a job and finish it off with a layer of heath atop, well, then, it will last for ever. Ess, fay! And what is the way you proceed to thatch a roof? I asked. Well, he answered, it's not easy to explain. 'Lanes' of reed—wheat straw, you would say—are first tied on the eave beams and gable beams; these are called eave locks and gable locks. A 'lane of reed' is about as long as a walking-stick and a bit thicker than a man's
- 61. wrist, and a thatched roof is composed of these 'lanes' tied on the roof beams, in ridge fashion. Then when the reeds are all tied on, overlapping each other, they are trimmed with a 'paring hook.' The reed has to be wet when put up; that is why thatchers wear leather knee-knaps. The best thatching reed comes from clay soil out Exeter and Crediton way. And where do you think, I asked, can be seen the most perfect examples of thatching in England? I lay you won't see any better than the cottages around Lyme Regis and Axminster. But soon Merry England will be done with thatch, for the boys of the village are too proud to learn how to cut a spar or use a thatcher's hook. Bless my soul! They all want to be clerks or school teachers. My friend the thatcher had a profound contempt for school larning and he waxed triumphantly eloquent when he touched upon Council School teachers. What poor, mimpsy-pimsy craychers they be, them teachers, he remarked. Fancy them trying to larn others, and ha'n't got the brains to larn themselves! * * * * * * Bere Regis church is the most beautiful little building of its size in Dorset. It is the captain and chief of all the village churches, and has just managed to touch perfection in all the things that a wayside shrine should achieve. There is an atmosphere about the old place that is soothing and above the pleasure of physical experience. The qualities of Bere Regis can only be fully appreciated with that sixth sense that transcends gross sight and touch. Upon entering the building one is captivated by the remarkable roof and the number of effigies, half life-size, in the dress of the period, which are carved on the hammer-beams. This magnificent carved and painted timber roof is said to have been the gift of Cardinal Morton, born at Milborne Stileman, in this parish. The roof effigies are supposed to represent
- 62. the Twelve Apostles, but they are not easily identified. The canopied Skerne tomb possesses a special interest for its brasses and verse: I Skerne doe show that all our earthlie trust All earthlie favours and goods and sweets are dust Look on the worlds inside and look on me Her outside is but painted vanity. In the south porch will be found an interesting relic in the shape of some old iron grappling-hooks used for pulling the thatch off a cottage in the event of fire. An ancient altar-slab on which, perchance, sacrifices have been offered has been preserved, and there is also a fine old priest's chair, the upper arms of which have supported the leaning bodies of a great company of Dorset vicars, for it must be remembered that the priest was not allowed to sit on the chair—but leaning was permitted. The Norman pillars in the south arcade are striking to the eye, and the humorous carvings on their capitals are objects of great interest. One of them gives a very good picture of a victim in the throes of toothache; apparently the sufferer has just arrived at that stage in which the pain is mounting to a crescendo of agony, for he has inserted his eight fingers in his mouth in an attempt to battle with his tormentors. The other figure displays some poor fellow who is a martyr to headache—perhaps a gentle reproof and warning to those who were inclined to tarry overlong in the taverns. But the main object of interest is the Turberville window in the south aisle, beneath which is the ledger- stone covering the last resting-place of this wild, land-snatching family, which is lettered as follows:— Ostium sepulchri antiquae Famillae Turberville 24 Junij 1710. (The door of the sepulchre of the ancient family of the Turbervilles.) It was at this vault stone that Tess bent down and said:
- 63. Why am I on the wrong side of this door! Perhaps it is as well to recite the outline of Hardy's story of Tess at this stage of our pilgrimage. Tess Durbeyfield, the daughter of poor and feeble- minded parents and descendant of a noble but somewhat wild old family, was forcibly seduced by a wealthy young loafer whose father had taken, with no right to it, Tess's proper name of D'Urberville. A child was born, but died. Some years after Tess became betrothed to a clergyman's son, Angel Clare. On their wedding night Tess confessed to him her past relations with Alec D'Urberville, and thereupon Clare, a man who was not without sin himself, left her. In the end Fate conspired to force Tess back into the protection of Alec. Clare, who cannot be looked upon as anything but half-baked and insincere, returns repentant from Canada and finds her living with D'Urberville. In order to be free to return to Clare, Tess stabbed Alec to the heart, for which she was arrested, tried and hanged. In this romance Bere Regis figures as Kingsbere, and the church is the subject of many references. It was on one of the canopied, altar-shaped Turberville tombs that poor Tess noticed, with a sudden qualm of blank fear, that the effigy moved. As soon as she drew close to it she discovered all in a moment that the figure was a living person; and the shock to her sense of not having been alone was so violent that she almost fainted, not, however, till she had recognised Alec D'Urberville in the form. Here Alec D'Urberville stamped with his heel heavily above the stones of the ancient family vault, whereupon there arose a hollow echo from below, and remarked airily to Tess: A family gathering is it not, with these old fellows under us here? In the south wall a doorway which has been long filled in can still be traced. There is nothing of special note in this alteration, but a legend has been handed down which is worth recording here. It is said that one of the Turberville family quarrelled with the vicar of Bere Regis and ended a stormy meeting by declaring that he would never again pass through the old door of the church. As time went on the lure of the Turberville dead in the ancient shrine obsessed
- 64. him and he grew to regret the haste in which he had cut himself off from the ancient possessors of his land. After some years Fate arranged a chance meeting between the vicar and Turberville at a village feast, and under the influence of the general good-fellowship and merry-making they buried the hatchet and fell to discussing old times and friends. When time came for the breaking up of the entertainment it was only Turberville's dogged determination to keep his vow which prevented a return to the old happy conditions before the breach of friendship. There is one thing I would ask you to do, Vicar, said Turberville as he parted. When you attend vespers to-morrow just tell the old Turberville squires to sleep soundly in their vault. Although I have vowed never to pass through the church door while I am alive, I cannot stop 'em carrying me through when I am dead—so I shall sleep with them in the end. However, the worthy vicar went to the town stone-mason next morning and arranged to cut a new doorway in the south wall, and thus it came to pass that the independent and stubborn Turberville once again was able to worship with the shades of his fathers and yet keep to his promise never to pass through the old door again. The first of the family of Turberville was Sir Payne de Turberville (de Turba Villa), who came over with William the Norman. From Sir Payne down to the last descendants of the family who form the theme of Thomas Hardy's romance, Tess of the D'Urbervilles, the Turbervilles were a strange, wild company. It is excusable, too, in a way, for it appears that the first of the line, after the battle of Hastings, was one of the twelve knights who helped Robert FitzHamon, Lord of Estremaville, in his evil work and returned to England when his commander was created Earl of Gloucester. In an ancient document of the time of Henry III. we come across a striking illustration of the unscrupulous ways of this family, for it is recorded that John de Turberville was then paying an annual fine on some land near Bere Regis, which his people before him had filched from the estate of the Earl of Hereford. The Turbervilles were
- 65. established in the neighbourhood in 1297. Bryants Puddle, a very rude little hamlet situated on the River Piddle a little to the south- west of Bere, receives its title from Brian de Turberville, who was lord of the manor in the reign of Edward III. The village was anciently called Piddle Turberville, but this name has been replaced by Bryants Puddle. At a later period the Turbervilles came into the possession of the manor of Bere Regis at the breaking up of Tarent Abbey, and at this time the good fortune of the family was at its zenith. But with the spoils of the church came a gradual and general downfall of the old family, and with the increased riches, we may conjecture, the Turbervilles went roaring on their way more riotously than ever. There is an entry in the parish registers of Bere, under the year 1710, of the interment of Thomas Turberville, the last of the ancient race. An intermediate stage of the house is represented by D'Albigny Turberville, the oculist mentioned by Pepys, who died in 1696 and was buried in Salisbury Cathedral. After the year 1710 the old manor-house of the Turbervilles, standing near the church, was strangely silent. Their time was over and gone, the wine had been drunk, the singers had departed. But the stories of their carousals and great deeds were still a matter for dispute and discussion at the village inn, and the eerie old house was especially regarded with feelings of awe and few cared to go near it after dark. It was not what they had seen, but what they might see, that caused them to shun the old place. I can picture the Dorset rustic of that time (and the distance between Hodge the Goodman of 1710 and Hodge the driver of the motor tractor is almost nothing at all) shaking his head on being asked his reasons for avoiding the house, and saying, with a grin, as how he shouldn't like to go poking about such a divered [dead] old hole. The ancient manor-house was allowed to lapse into ruin, and now nothing at all remains but a few crumbling stones:
- 66. Through broken walls and grey The winds blow bleak and shrill; They are all gone away. Nor is there one to-day To speak them good or ill; There is nothing more to say. There is reason to believe that the rustics in Wilts and Dorset who bear different forms of the name Turberville, altered into Tellafield and Troublefield, are in truth the descendants of illegitimate branches of the family. One ancient Dorset rustic with the name of Tollafield, who aroused my interest, said to me in all seriousness that he would not care to go rummaging into the history of the old Turberville people. You depend upon it, they were a bad lot—the parson told me so. There is no telling what them folks' speerits might not be up to, if so be the old devil had got ahold on 'em. This rustic, though an old man, had an eye as keen as a hawk's, was a man of immensely powerful frame, and would sleep under a hedge any night and feel little the worse for it. When I looked at his clear, hard blue eyes and straight, haughty nose he gave me the feeling that the Turberville blood had really survived in him. Then I learned that he was a flagrant poacher and, like the old earth-stopper in Masefield's poem, His snares made many a rabbit die. On moony nights he found it pleasant To stare the woods for roosting pheasants Up near the tree-trunk on the bough. He never trod behind a plough. He and his two sons got their food From wild things in the field and wood.
- 67. It was my fortune to run into the old fellow coming out of the Royal Oak one night with his friends. He was very exuberant and arrogant. I heard him offering to fight three men, knock one down, t'other come on style. Then it came over me with a sudden sense of largeness and quietude that the game old ruffian had his place in the order of things. This tyrant of the low Tudor tap-room was perhaps a Turberville, one of the rightful, immemorial owners of the land. If he has not the right to a pheasant for his Sunday dinner, then tell me who has. Perhaps when we, with our picture palaces and styles and jazzy-dances, have passed away our hoary friend the poacher will abide, his feet among his clods, rooted deep in his native soil. And if all this thin veneer of civilisation was suddenly ripped away from us, how should we emerge? Hodge would still go on poaching, sleeping under hedges, outwitting the wild things in the woods and drinking home-brewed ale. He would not even feel any temporary inconvenience. How old-fashioned and out-of-date we with all our new things would feel if we were suddenly brought into line with the eternally efficient Hodge!
- 68. From Bere Regis to Wool is a pleasant ride of five or six miles. Close to Wool station is the manor-house, now a farm, which was once the residence of a younger branch of the Turberville family, and readers will remember it is the place where Tess and Angel Clare came to spend their gloomy and tragic honeymoon. In Hardy's Tess the house is called Wellbridge Manor House, in remembrance of the days
- 69. when Wool was called Welle, on account of the springs which are so plentiful in this district. Of course the house is named from the five- arched Elizabethan bridge which spans the reed-fringed River Frome at this point. Each arch of the bridge is divided by triangular buttresses, which at the road-level form recesses where foot- passengers may take refuge from passing motors or carts. The manor-house is of about the time of Henry VIII., and has been much renovated. Over the doorway a date stone proclaims that the building was raised in 1635 (or 1655), but it has been suggested that this is the date of a restoration or addition to the building. The two pictures of Tess's ancestors mentioned in the novel actually exist, and are to be seen on the wall of the staircase: two life-sized portraits on panels built into the wall. As all visitors are aware, these paintings represent women of middle age, of a date some two hundred years ago, whose lineaments once seen can never be forgotten. The long pointed features, narrow eye, and smirk of the one, so suggestive of merciless treachery; the bill-hook nose, large teeth, and bold eye of the other, suggesting arrogance to the point of ferocity, haunt the beholder afterwards in his dreams. Old records show that in ancient times a curious custom was observed on Annual Court Day at Wool. It was known as collecting smoke-pence. It appears that the head of every house was called upon to pay a penny for each of his chimneys as a token that the property belonged to the manor. The money was collected by the constable, who was obliged to bring twenty pence into court, or make up the money himself. The most characteristic and altogether unique feature of this nook of earth around Bere Regis is that superstition has not ceased to exist among the old people of the land. It is difficult to believe that there is a little district in England where superstition is still a part—a very obscure part, it is true—of the life of the people. But here I have noticed the shadow of witchcraft and magic thrown across the commonplace things of rustic life again and again while talking with old cronies over their beer, or along the winding hill roads. But it
- 70. must be understood that the Dorset man does not talk to any chance wayfarer on such matters: the subject of the Borderland and spiritual creatures is strictly set apart for the log fire and chimney corner on winter evenings. It is when the wooden shutters are up to the windows, and the tranquillising clay pipes are sending up their incense to the oak cross-beams, that we may cautiously turn the conversation on to such matters. On one such occasion as I watched the keen, wrinkled faces, on which common sense, shrewdness and long experience had set their marks, I wondered if two local farmers had made such sinners of their memories as to credit their own fancy. But no, I would not believe they were in earnest. It was only their quaint humour asserting itself. They were surely piling it on in order to deceive me! However, that was not the solution, for when the time came, somewhere about midnight, for one of the farmers to return home he stolidly refused to face the dark trackway back to his farm, and preferred to spend the night in the arm-chair before the fire. But let one of the dwellers on Bere Heath tell of his own superstitions. Here is old Gover coming over the great Elizabethan bridge which spans the rushy River Frome at Wool. One glance at his cheerful, weather-beaten face will tell you better than a whole chapter of a book that he is no lablolly (fool), but a man of sound judgment, easy notions and general good character, like Hardy's Gabriel Oak. Leaning on the ancient stonework of the bridge, and smacking his vamplets (rough gaiters used by thatchers to defend the legs from wet) with a hazel stick, he stops to talk. A motor lorry filled with churns of milk passes on its way to drop its consignment at Wool railway siding. Tellee what 'tis, said Gover to me, pointing to the lorry: 'twill be a poor-come-a-long-o'-'t now them motors are taking the place o' horses everywhere. Can't get no manure from them things, and the land is no good without manure. Mr Davis the farmer at Five Mile Bottom hev got five Ford cars now where ten horses used to feed. He sez to me that he don't want any horse manure—chemical manures is good enough for him. But he dunnow nort 't-all-'bout-et! He'll eat the heart out of his soil with his chemicals, and his farm will
- 71. be barren in a year or so. Ess, by Gor! You bant agwain to do justice to the soil without real manure, and them as thinks they can dawnt know A from a 'oss's 'ead. Then I asked Gover about the Turberville ghost which we are told haunts this lane, and which is the subject of an allusion in Hardy's Tess of the D'Urbervilles. His keen old face became serious at once. No ghosts or goblins had troubled him, he said, but John Rawles and another chap saw as plain as could be a funeral going along from Woolbridge House to Bere Regis, and they heard the priest singing in front of the coffin, but they could not understand what he did say. There was a cattle gate across the road in those days and Rawles ran to open it, but before he could get there the coffin had passed through the gate and it had all vanished! He had often heard tell of people who had seen ghosts, and he would not be put about if he did see one himself. So you have not seen the blood-stained family coach of the Turbervilles? I inquired. No, I never see that, said Gover, shaking his head, nor never heard of it. Then, as it is a tale that every child should know, I said, I will tell you now, and you shall believe it or no, precisely as you choose. Once upon a time there was a Turberville who deserves to be remembered and to be called, so to speak, the limb of the 'old 'un' himself, for he spent all his days in wickedness, and went roaring to the devil as fast as all his vices could send him. I have heard it said that he snapped his fingers in the face of a good parson who came to see him on his death-bed, saying he did not wish to talk balderdash, or to hear it, and bade him clear out and send up his servant with fighting-cocks and a bottle of brandy. Gradually all the drinking and vice, which had besieged his soul for so long, swept him into a state of temporary madness and he murdered a friend while they were riding to Woolbridge House in the family coach. The friend he struck down had Turberville blood in his veins too, so you
- 72. may be certain the blame was not all on one side. Ever since the evil night the coach with the demon horses dragging it sways and rocks along the road between Wool and Bere, and the murderer rushes after it, moaning and wringing his hands, but never having the fortune to catch it up. The spectacle of the haunted coach cannot be seen by the ordinary wayfarer; it is only to be seen by persons in which the blood of the Turbervilles is mixed. Ah! nodded old Gover, I don't hold with that story. If so be as that 'ere Turberville who murdered t'other hev a-gone up above, 'tain't likely as how he'll be wishful to go rowstering after that ripping great coach on a dalled bad road like this. And then he shook his bony finger in my face and added: And if the dowl have a-got hold on 'im he won't be able to go gallyvanting about—he'll be kept there! Wool has another attraction in the ruins of Bindon Abbey, lying in the thick wood seen from the station, a few minutes to the south of the line towards Wareham. The ruins are very scanty. A few slabs and coffins are still preserved, and one stone bears the inscription in Lombardic characters: ABBAS RICARDUS DE MANERS HIC TUMULATUR APPOENAS TARDUS DEUS HUNC SALVANS TUEATUR The Abbey is in a wood by the river—a gloomy, fearsome, dark place. This is the Wellbridge Abbey of Hardy's Tess, and we read that against the north wall of the ruined choir was the empty stone coffin of an abbot, in which every tourist with a turn for grim humour was accustomed to stretch himself. This is, of course, the lidless coffin in which Angel Clare, walking in his sleep, laid Tess. Woolbridge House is not so near to this spot as Thomas Hardy gives one to understand in the novel. Near the ruin is the old mill of Bindon Abbey, situated on the Frome, where Angel Clare proposed to learn milling. It is called Wellbridge Mill in Tess.
- 73. The old Abbey wood is full of shadows and is the kind of place that one would write down as immemorially old, barren and sinister. The singular impressiveness of its ivy-grown walls, shadowed by heavy masses of foliage, depresses one dreadfully. The straight footpaths beneath the trees have been worn into deep tracks by the attrition of feet for many centuries. Under the trees are the fish-ponds which played such an important part in provisioning the monks' larder. They are so concealed from the daylight that they take on a shining jet-black surface. A book might be written about the place—a book of terrible and fateful ghost tales.
- 74. CHAPTER VIII ROUND AND ABOUT WEYMOUTH I walk in the world's great highways, In the dusty glare and riot, But my heart is in the byways That thread across the quiet; By the wild flowers in the coppice, There the track like a sleep goes past, And paven with peace and poppies, Comes down to the sea at last. E. G. Buckeridge. Modern Weymouth is made up of two distinct townships, Weymouth and Melcombe Regis, which were formerly separate boroughs, with their own parliamentary representatives. Of the two Weymouth is probably the older, but Melcombe can be traced well-nigh back to the Conquest; and now, although it is the name of Weymouth that has obtained the prominence, it is to Melcombe that it is commonly applied. Many visitors to Weymouth never really enter the real, ancient Weymouth, now chiefly concerned in the brewing of Dorset ale. The pier, town, railway station and residences are all in Melcombe Regis. The local conditions are something more than peculiar. The little River Wey has an estuary altogether out of proportion to its tiny stream, called the Blackwater. The true original Weymouth stands on the right bank of the estuary at its entrance into Weymouth Bay. Across the mouth of the estuary, leaving a narrow channel only open, stretches a narrow spit of land, on which stands Melcombe. The Blackwater has thus a lake-like character, and its continuation to the sea, the harbour, may be likened to a canal. The local annals of the kingdom can hardly furnish such another
- 75. instance of jealous rivalry as the strife between the two boroughs. Barely a stone's-throw apart, they were the most quarrelsome of neighbours, and for centuries lived the most persistent cat and dog life. Whatever was advanced by one community was certain to be opposed by the other, and not even German and English hated each other with a more perfect hatred than did the burgesses of Weymouth and Melcombe Regis. As they would not live happy single, it was resolved to try what married life would do, and so in 1571 the two corporations were rolled into one, the only vestige of the old days retained being the power of electing four members to Parliament from the joint municipality—a right which was exercised until 1832. Not until the union was the old-fashioned ferry over the Wey supplemented by a bridge, the predecessor of that which now joins the two divisions of the dual town. The union proved to be a success, and in this way Weymouth saved both itself and its name from becoming merely a shadow and a memory. It is to George III. that Weymouth must be eternally grateful, for just in the same way as George IV. turned Brighthelmstone into Brighton, it was George III. who made Weymouth. Of course there was a Weymouth long before his day, but whatever importance it once possessed had long disappeared when he took it up. For many years the King spent long summer holidays at Gloucester Lodge, a mansion facing the sea, and now the sedate Gloucester Hotel. Considering its undoubted age, Weymouth is remarkably barren in traces of the past, and a few Elizabethan houses, for the most part modernised, well-nigh exhaust its antiquities. Weymouth, which figures as Budmouth in Hardy's romances, is the subject of many references. Uncle Bengy, in The Trumpet Major, found Budmouth a plaguy expensive place, for If you only eat one egg, or even a poor windfall of an apple, you've got to pay; and a bunch of radishes is a halfpenny, and a quart o' cider tuppence three-farthings at lowest reckoning. Nothing without paying!
- 76. When George III. and the sun of prosperity shone upon the tradesfolk of Weymouth the spirit of pecuniary gain soon became rampant. The inflated prices which so roused poor old Uncle Bengy even staggered Queen Charlotte, and Peter Pindar (Dr John Wolcot) criticised her household thriftiness in bringing stores and provisions from Windsor: Bread, cheese, salt, catchup, vinegar and mustard, Small beer and bacon, apple pie and custard; All, all from Windsor, greets his frugal Grace, For Weymouth is a d——d expensive place. Sandsfoot Castle, built by Henry VIII., on the southern shore of the spit of land called the Nothe, Weymouth Bay, is now a mere pile of corroded stone. It was built as a fort when England feared an invasion prompted by the Pope. The old pile plays a prominent part in Hardy's The Well-Beloved. The statue of King George, which is such an object of ridicule to the writers of guide-books, was the meeting-place of Fancy Day and Dick Dewy in Under the Greenwood Tree. The Budmouth localities mentioned in The Trumpet Major are: the Quay; Theatre Royal; Barracks; Gloucester Lodge; and the Old Rooms Inn in Love Row, once a highly fashionable resort which was used for dances and other entertainments by the ladies and gentlemen who formed the Court of George III. It was also the spot where the battle of Trafalgar was discussed in The Dynasts. However, the old assembly rooms and the theatre have now vanished. Mention of Hardy's tremendous drama reminds me that it is rarely quoted in topographical works on Dorset, and yet it is full of the spirit and atmosphere of Wessex. Thus in a few words he tells us what Boney seemed like to the rustics of Dorset: Woman (in undertones). I can tell you a word or two on't. It is about His victuals. They say that He lives upon human flesh, and has
- 77. rashers o' baby every morning for breakfast—for all the world like the Cernel Giant in old ancient times! Second Old Man. I only believe half. And I only own—such is my challengeful character—that perhaps He do eat pagan infants when He's in the desert. But not Christian ones at home. Oh no—'tis too much! Woman. Whether or no, I sometimes—God forgi'e me!—laugh wi' horror at the queerness o't, till I am that weak I can hardly go round house. He should have the washing of 'em a few times; I warrent 'a wouldn't want to eat babies any more! There are a hundred clean-cut, bright things in The Dynasts, and some of the songs are so cunningly fashioned that we know the author must surely have overheard them so often that they have become part of his life. Does the reader remember this from the first volume?— In the wild October night-time, when the wind raved round the land, And the Back-sea met the Front-sea, and our doors were blocked with sand, And we heard the drub of Dead-man's Bay, where bones of thousands are, We knew not what the day had done for us at Trafalgar. (All) Had done, Had done For us at Trafalgar! Or the other ballad sung by a Peninsular sergeant—
- 78. When we lay where Budmouth Beach is, Oh, the girls were fresh as peaches, With their tall and tossing figures and their eyes of blue and brown! And our hearts would ache with longing As we passed from our sing-songing, With a smart Clink! Clink! up the Esplanade and down. The principal attraction of Weymouth is its magnificent bay, which has caused the town to be depicted on the railway posters as the Naples of England; but Mr Harper, in his charming book, The Hardy Country, cruelly remarks that no one has yet found Naples returning the compliment and calling itself the Weymouth of Italy. But there is no need for Weymouth to powder and paint herself with fanciful attractions, for her old-world glamour is full of enchantment. The pure Georgian houses on the Esplanade, with their fine bow windows and red-tiled roofs, are very warm and homely, and remind one of the glories of the coaching days. They are guiltless of taste or elaboration, it is true, but they have an honest savour about them which is redolent of William Cobbett, pig-skin saddles, real ale and baked apples. And those are some of the realest things in the world. There is a distinct atmosphere about the shops near the harbour too. They shrink back from the footpath in a most timid way, and each year they seem to settle down an inch or so below the street- level, with the result that they are often entered by awkward steps. Near the Church of St Mary is the Market, which on Fridays and Tuesdays presents a scene of colour and activity. In the Guildhall are several interesting relics, the old stocks and whipping-posts, a chest captured from the Spanish Armada and a chair from the old house of the Dominican friars which was long ago demolished. Preston, three miles north-east of Weymouth, is a prettily situated village on the main road to Wareham, with interesting old thatched cottages and a fifteenth-century church containing an ancient font, a
- 79. Norman door, holy-water stoups and squint. At the foot of the hill a little one-arched bridge over the stream was once regarded as Roman masonry, but the experts now think it is Early Norman work. Adjoining Preston is the still prettier village of Sutton Poyntz, hemmed in by the Downs, on the side of which, in a conspicuous position, is the famous figure, cut in the turf, of King George III. on horseback. He looks very impressive, with his cocked hat and marshal's baton. Sutton Poyntz is the principal locale of Hardy's story of The Trumpet Major. The tale is of a sweet girl, Anne Garland, and two brothers Loveday, who loved her; the gally-bagger sailor, Robert, who won her, and John, the easy-going, gentle soldier, who lost her. The Trumpet Major is a mellow, loamy novel, and the essence of a century of sunshine has found its way into the pages. Even the pensiveness of the story—the sadness of love unsatisfied— is mellow. The village to-day, with its tree-shaded stream, crooked old barns and stone cottages, recalls the spirit of the novel with Overcombe Mill as a central theme. How vividly the pilgrim can recall the Mill, with its pleasant rooms, old-world garden, and the stream where the cavalry soldiers came down to water their horses! It was a dearly loved corner of England for John Loveday, and if to keep those meadows safe and fair a life was required, he was perfectly willing to pay the price—nay, more, he was proud and glad to do so. In the end John was killed in one of the battles of the Peninsular War, and his spirit is echoed by a soldier poet who went to his death in 1914:
- 80. Mayhap I shall not walk again Down Dorset way, down Devon way. Nor pick a posy in a lane Down Somerset and Sussex way. But though my bones, unshriven, rot In some far-distant alien spot, What soul I have shall rest from care To know that meadows still are fair Down Dorset way, down Devon way. The mill is not the one sketched in the tale, but it still grinds corn, and one can still see the smooth mill-pond, over-full, and intruding into the hedge and into the road. The real mill is actually at Upwey. Bincombe, two miles north-east of Upwey, is one of the outstep placen, where the remnants of dialect spoken in the days of Wessex kings is not quite dead, and as we go in and out among the old cottages we come upon many a word which has now been classed by annotators as obsolete. I'd as lief be wooed of a snail, says Rosalind in As You Like It of the tardy Orlando, and I'd as lief or I'd liefer is still heard here in Bincombe. There is a large survival of pure Saxon in the Wessex speech, and Thomas Hardy has made a brave attempt to preserve the old local words in his novels. He has always deplored the fact that schools were driving out the racy Saxon words of the West Country, and once remarked to a friend: I have no sympathy with the criticism which would treat English as a dead language—a thing crystallised at an arbitrarily selected stage of its existence, and bidden to forget that it has a past and deny that it has a future. Purism, whether in grammar or vocabulary, almost always means ignorance. Language was made before grammar, not grammar before language. And as for the people who make it their business to insist on the utmost possible impoverishment of our
- 81. English vocabulary, they seem to me to ignore the lessons of history, science, and common sense. It has often seemed to me a pity, from many points of view—and from the point of view of language among the rest—that Winchester did not remain, as it once was, the royal, political, and social capital of England, leaving London to be the commercial capital. The relation between them might have been something like that between Paris and Marseilles or Havre; and perhaps, in that case, neither of them would have been so monstrously overgrown as London is to- day. We should then have had a metropolis free from the fogs of the Thames Valley; situated, not on clammy clay, but on chalk hills, the best soil in the world for habitation; and we might have preserved in our literary language a larger proportion of the racy Saxon of the West Country. Don't you think there is something in this? Returning from Bincombe and passing through Sutton to Preston we come in a mile to Osmington. A short distance beyond the village a narrow road leads off seawards to Osmington Mills. Crossing the hills, this narrower road descends to the coast and the Picnic Inn—a small hostelry noted for lobster lunches and prawn teas. If we strike inland from Osmington we come to Poxwell, the old manor- house of the Hennings, a curiously walled-in building with a very interesting gate-house. This is the Oxwell Manor of The Trumpet Major and the house of Benjamin Derriman—a wizened old gentleman, in a coat the colour of his farmyard, breeches of the same hue, unbuttoned at the knees, revealing a bit of leg above his stocking and a dazzlingly white shirt-frill to compensate for this untidiness below. The edge of his skull round his eye-sockets was visible through the skin, and he walked with great apparent difficulty. Pressing onward from this village, we arrive, after a two-mile walk, at Warm'ell Cross, three miles south-west of Moreton station. The left road leads to Dorchester, the right one to Wareham, and the centre one across the immemorially ancient and changeless Egdon Heath. Here we turn to the right and Owermoigne, the Nether
- 82. Mynton in which the events of The Distracted Preacher take place. Here indeed is a nook which seems to be a survival from another century; a patch of England of a hundred years ago set down in the England of to-day. The church where Lizzie Newberry and her smugglers stored the stuff is hidden from those who pass on the highroad and is reached by a little rutty, crooked lane. The body of the church has been rebuilt, but the tower where the smugglers looked down upon the coastguard officers searching for their casks of brandy remains the same. The highway leads for two miles along the verge of Egdon Heath, and then we come to a right-hand turning taking us past Winfrith Newburgh and over the crest of the chalk downs steeply down to West Lulworth. Lulworth Cove is justly considered one of the most delightful and picturesque retreats on the coast. It is a circular little basin enclosed by towering cliffs of chalk and sand and entered by a narrow opening between two bluffs of Portland stone. It exhibits a section of all the beds between the chalk and oolite, and owes its peculiar form to the unequal resistance of these strata to the action of the sea. The perpetually moving water, having once pierced the cliff of stone, soon worked its way deeply into the softer sand and chalk. Lulworth is the Lullstead Cove of the Hardy novels. Here Sergeant Troy was supposed to have been drowned; it is one of the landing- places chosen by the Distracted Preacher's parishioners during their smuggling exploits, and in Desperate Remedies it is the first meeting-place of Cynthera Graye and Edward Springrove. The cove is most conveniently reached from Swanage by steamer. By rail the journey is made to Wool and thence by bus for five miles southward. By road the short way is by Church Knowle, Steeple, Tyneham and East Lulworth—but the hills are rather teasing; however, the views are wonderful. It is nine miles if one takes the Wareham road from Corfe as far as Stoborough, there turning to the left for East Holme, West Holme and East Lulworth.
- 83. The entrance to the cove from the Channel is a narrow opening in the cliff, which here rises straight from the sea. Mounted on a summit on the eastern side of the breach is a coastguard's look-out, while in a hollow on the other side are the remains of Little Bindon Abbey. The cove is an almost perfect circle, and in summer the tide, as it flows in, fills the white cove with a shimmering sheet of light blue water. Each wave breaks the surface into a huge circle, and the effect from the heights is a succession of wonderful sparkling rings vanishing into the yellow sands. To the east rise the ridges of Bindon Hill and the grey heights of Portland stone that terminate seaward in the Mupe Rocks, then the towering mass of Ring's Hill, crowned by the large oblong entrenchment known as Flower's Barrow, which has probably been both a British and a Roman camp. In the summer steamers call daily at the cove. The landing is effected by means of boats or long gangways. After having climbed the hill roads into Lulworth, the pilgrim will not, I am certain, look with any delight upon a return to them, and will welcome an alternative trip to Swanage, Weymouth or Bournemouth by an excursion steamer.
- 84. Portisham, under the bold, furzy hills that rise to the commanding height of Blackdown, appears in The Trumpet Major as the village to which Bob Loveday (who was spasmodically in love with Anne Garland) comes to attach himself to Admiral Hardy for service in the Royal Navy. Notwithstanding the fact that Robert Loveday is merely an imaginary character, the admiral was a renowned hero in real life,
- 85. and no less a personage than Admiral Sir Thomas Hardy. He lived here, in a picturesque old house just outside the village, and the chimney-like tower on Black Down was erected to his memory. In a garden on the opposite side of the road to Hardy's house is a sundial, inscribed: JOSEPH HARDY, ESQ. KINGSTON RUSSELL, LAT. 50° 45' 1769 FUGIO FUGE Admiral Hardy was born at Kingston Russell, and his old home at Portisham is still in the possession of a descendant on the female side. From Portisham a walk of four miles leads to Abbotsbury, situated at the verge of the Vale of Wadden and the Chesil Beach. The railway station is about ten minutes' walk from the ancient village, which consists of a few houses picturesquely dotted around the church and scattered ruins of the Abbey of St Peter. The abbey was originally founded in King Knut's reign by Arius, the house-carl, or steward, to the king, about 1044, in the reign of Edward the Confessor. The building at the south-east corner of the church is part of the old abbey. It is now used as a carpenter's shop, but an old stoup can be seen in the corner. At the farther end of this building is a cell in which the last abbot is said to have been starved to death. A gate-house porch and a buttressed granary of fourteenth-century architecture, still used as a barn, and a pond, with a tree-covered island, the ancient fish-pond of the monks, are all that remain to remind us of the historic past of this spot.
- 86. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com