REGISTER

Alena Griffiths MIEAust, CPEng, PhD, BSc(Hons), LLB

RGB Assurance Pty Ltd

Rarely a week goes by without a major software failure featuring prominently in the news. Some problems, such as the reported "computer glitches" with Virgin Blue's check-in software in 2010, merely result in financial loss. Others, such as the Queensland Health payroll debacle, in 2011, contribute to the downfall of governments. And of course there have also been cases where software unreliability has contributed to unavailability of critical public infrastructure, and in some cases, loss of life.

But how vulnerable is the rail industry to software unreliability, and what's the real likelihood that software problems could actually stop the trains (or even crash the trains)?

This paper will provide a brief survey of the extent to which modern railways depend on correct software operation. We will show that this dependency extends from customer facing applications such as web-based journey planners and fare sales and collection systems, through to critical service delivery applications such as routing trains, scheduling essential maintenance, and responding to emergencies.

Having elaborated the dependence of modern railways on software technology, we will then proceed to discuss the vulnerabilities this presents.

We will describe the main reasons why software engineering is different from other engineering disciplines, and hence why reliability of software must be approached differently to reliability of other engineering products. The explanation will range from the science that underpins software engineering, through to the complexity inherent in modern software systems, and ultimately through to social issues such as regulation of the software engineering profession and the psychology of the software development process.

In particular, we will consider traditional approaches to reliability engineering and explain why these approaches in general translate poorly to software. Finally, we will talk about how software reliability is being approached in the Australian rail industry today, and provide some suggestions for improving our handling of, and hence reducing our vulnerability to, software reliability issues.