'Safe Software' Need Not Be an Oxymoron

Computer-based controls of transportation systems, industrial plants, sundry machinery, and consumer items became ubiquitous in the last quarter of the twentieth century. The microprocessor -- the heart of the microcomputer, microcontroller, programmable logic controller, and indeed today’s workstations, servers, and even mainframes -- is the enabling technology behind these digital control systems. The behavior of computer-based controls is determined by the combination of kernel, operating system, and application software that the controlling computers execute. Today’s multi-gigahertz and -gigabyte computer-hardware technology has seen a concomitant growth in the size and complexity of software development environments, i.e., in specification tools and languages, compilers and programming languages, and semi-automated tests. The quantitative aspects - size, speed, complexity - of the contemporary versions of these technologies have given rise to the general impression that hardware software architectures and software-development methodologies have changed fundamentally, i.e., qualitatively, from those of the 1960s. This is not the case, even for the vast majority of computer-based control applications in transportation, aerospace, and factory automation. To paraphrase a famous line in a famous film, the methodologies are the same, only more so. The notions safe software, along with those of secure software and trusted software, concern the real-world function, purpose, or ‘meaning’ of computer programs. Though not the stuff of daily headlines (but certainly the stuff of occasional, sensational ones), the correctness of software - it does what it’s supposed to do - has been the subject of great effort from Computing Science’s inception. This paper elaborates the issue of software-correctness, as it manifests itself in safety-critical (vital) transit applications; and describes emerging Best Practices in this area, including the safety-critical project life-cycle and an approach to safety certification. The paper also addresses cultural and economic influences that affect the education and training (a distinction with a difference) of the Software Engineering labor force, and that affect transit properties and their contractors, and provides an example risk assessment of the NYCT Canarsie Line safety-critical Communication Based Train Control (CBTC) transit system.