Tech Safe Transport Podcast

It’s been a while since I last posted: I put this down to a glut of work, but also a little bit of a loss of focus on these topics in a world where so many more high profile political issues are in dangerous flux. Thankfully I have re-established my equilibrium now and I have a range of interesting areas I intend to deep dive into over the coming months: I hope that’s welcome news.

So anyway, it’s a podcast this time. Some months ago, I spoke to Dr Roger Short, a former colleague of mine, and someone whose orbit I have come into on a range of projects and initiatives dealing with the topic of software safety assurance over many years since.

Roger began his career with British Rail in the 1970s and led pioneering work on the safety assurance of the Advanced Passenger Train and the Solid State Interlocking (SSI) - the first computer based signalling system on the UK rail network. And his knowledge extends to the current day, where he is actively working on topics like machine learning and cyber security.

As well as being extremely knowledgeable on the subject of railway software safety Roger has an ability to communicate complex ideas clearly and succinctly. Many more people on the railway need to know how software is kept safe as the scope and breath of the ‘digital railway’ continues to expand so if you’d like to know more about the topic from a wise master, please plug in, settle back and listen to what he has to say.

I could have spoken to Roger for hours on this topic - and almost did: A full version of our discussion has been added as a bonus module on the course “Railway Software Safety as a Client” from Libusa.

And finally, for those who would prefer to read: A transcript of the discussion is included below.

[Please note that the software safety standard referred to in our discussions (EN50128) has now been superseded by EN50716 but the standards are essentially the same].

Thanks for listening

Please feel free to feed back any thoughts or comments and please do drop me an e-mail. My particular areas of professional and research interest are risk management, safety decision making and assurance of new transport technology. I’m always keen to consider interesting projects in these areas.

If you know anyone else who you think might appreciate a thought-provoking read or listen every few weeks, please let them know:

Transcription:

George Bearfield   Hi Roger. What is your background and how did you first come to work in the area of software safety?

Roger Short   Well, my background is as a railway signal engineer. I joined British Rail from school at age 18 and went on their student Apprentice scheme. This was in the railway signals department of the Western Region. But I've never been what you might call a mainstream signalling engineer, because when I finished my training, I went straight into working with electronic systems: hot axle box detectors, digital transmission equipment and so on. I don't have the background of having been involved in designing signalling schemes, testing them and implementing them and so on. When it came to getting involved in software, this happened a few years on, when I moved on to become a member of the Signal Development section at the British Railways Board. We were involved in safety approval of new signalling equipment and systems and the first software I was involved with was a system used on the advanced passenger train. This was in the late 1970s. The train was designed to travel at higher speeds over any given section of track than a normal conventional train, basically because of its tilting capability. The system would display in the driver's cab the permanent speed restriction which applied to the train, which was not the same as speed indicator restrictions indicated by lineside notices or by what it said in all the printed instructions, and so on. It worked by having transponders at intervals along the track which transmitted to the train the permitted speed for the coming section. There was a microprocessor-based system on board the train which decoded these messages and displayed them to the driver. If they provided a speed that was too high, there would be a danger of derailment. So, it was a safety-related system and it was developed by the British Rail Research Department. I was responsible for the safety approval of it and having to assess and validate the software system. So that was my first involvement in software.

George Bearfield   What is surprising to me is that often people think about technology as something which is relatively novel. But the techniques in the standards for software assurance have been around for decades, haven't they? And they're sort of tried and tested. For something which often people are only getting to grips with now, they might think of it as something which is fairly cutting edge. But it's actually pretty old and established.

Roger Short   Yes, this was just the period when there was a great deal of interest in applying software to things which had high demand for functional safety and at the same time software was sort of almost legendary for its ability to do things wrong with jokes around different themes such as: “To err is human, but to totally foul things up, it takes a computer.” And so there was a great deal of interest and lots of people working on how to get software we can rely on; software we can trust to deliver safety functions. So, I was there at that time and as you say, I'm aware that the things that are recommended now in in the software safety standards, like EN 50128 for railway signalling, are almost entirely things which were developed around the 1970s and 1980s.

George Bearfield   Just back to your career: we first worked together I think over 20 years ago. So I'm aware you worked also at British Rail Research on the first solid-state interlockings. People might not really know what that project was about, because that was a sort of paradigm shift in signalling at the time: moving safety critical functions from relay-based technology into code.

Roger Short   Oh yes: well an interlocking is actually a system which it is designed to prevent a railway signaller from setting train movements into unsafe situations, like setting up conflicting train movements or allowing trains to run across points which are not set correctly and so on. Since about the 1930s at least, this had been done largely using relays and relay logic. By the 1960s and 70s relays were providing the safety control of quite large areas of signalling, involving, in any particular installation, perhaps many thousands of relays. Railway signalling relays were designed to be inherently fail safe, which was achieved by making them big robust devices. A so-called ‘miniature relay’ was about the size of a house brick and there would be several thousands of those perhaps to control the signalling, say in an area like Bristol. So the relays themselves were costly. The work of installing them was costly and wiring them in too. As the signalling logic is relatively simple, you can define it in fairly simple Boolean logic. These new computers/microprocessors were devices that could do that easily. So British Rail Research came up with a project to develop a processor based interlocking system. And again, my perspective on it as being part of the headquarters signalling development team was: “Oh, so now we've got to approve this new system and it's right at the heart of our safety. I will be totally dependent on it for protecting our trains. So yeah, this is a big problem.” So this led to me leading the team that was dealing with the safety assessment and indeed safety validation of the software for the solid-state interlocking system. We also did the hardware as well which was interesting - and a lot of important engineering went into it - but it wasn't the same sort of really hard conceptual problem as there was with the software.

George Bearfield   You mentioned relays being inherently safe: In one of your papers you said that a failure rate of 10 to the minus 10 (failures per hour) is proven in use for relays. So, they're inherently very safe. I remember that you said that you sought to use a relay-based interlocking as a benchmark for a quantitative assessment of the performance of the software. I may have got that wrong, but I remember that from previous conversations which of course is very interesting, because any quantitative measures around software are inherently quite difficult to do.

Roger Short   Yes, it wasn't so much for assessing the software: It was for setting the target which we would be aiming at and hoping to achieve for the software and then extrapolating from that basing the sort of high level argument for the software validation process and by analogy with the series of test inspections, checks and so on, which were made on a relay interlocking system and mapping across from those to the the techniques, the testing, the analysis and so on, which was being done for the software. We were saying that in principle, they're doing the equivalent thing and that they're being done by people who are sufficiently competent in their field, either relay interlocking design or software people so it's reasonable to believe that the result of all of these activities - the overall result achieved - will be equivalent and we should achieve an equivalent level of safety with our software based interlockings as that achieved by the relay based interlockings.

George Bearfield  One advantage of relays is that they're quite transparent. You know in terms of their logic, and that’s a great benefit for assurance. I've always been fascinated by the trajectory of technology, so when you're talking about microprocessors [for the SSI project] they’re a similar sort of generation to the old ZX Spectrum or Commodore 64 type computers: that sort of level of complexity. But now obviously, modern interlockings are hugely more complicated with advances in processing and code and also network connectivity. So, I guess the scale of the assurance problem and the loss of transparency continues to move apace?

Roger Short   Oh yes, it does to some extent, although so far as the actual functional logic of the interlocking is concerned that hasn't become any more complex.

George Bearfield   That's a good point.

Roger Short   But the operating systems of the computers that it's running in have become a lot more complex and a lot more sophisticated. It was an 8-bit microprocessor which was being used for the SSI system.

George Bearfield   Yes. And so Roger, you already referred to the software safety standards and you mentioned the signalling standard EN 50128. Is it possible to give a lay persons understanding of what those software standards are and where they came from? And also, when you first came to grapple with them in your professional life?

Roger Short  

Well, what the software standards do is they essentially set out a process, which is a whole series of processes, which need to be applied through the lifecycle of the software from the initial concept through to installation, commissioning and eventually decommissioning. The lifecycle is very central to the standards. They define the activities which have to be performed at each stage of the lifecycle. They define organisational things and in particular they're very strong, generally on independence between the people who do the design and the people who check and validate the design and so on. Also, although sometimes people tend to miss the importance of it - but it's very central to them - is they define what are suitable techniques to be applied at each stage of the lifecycle. Naive readers of the standard tend to regard the techniques as secondary because they appear as appendices rather than in the main body of the text. But they’re there and they're actually normative. The appendices tell you what you have to do, and they are very central to actually achieving the levels of integrity which you want.

George Bearfield   These standards came out of the process sector, didn't they; oil and gas,  petrochemicals and factory machinery through a standard called IEC 61508. This was adapted to EN50128 for rail signalling purposes. You talked about target setting before when we talked about the relays and the interlockings and the importance of setting safety targets to define the rigour of those processes that need to be applied and there's something called a safety integrity level or SIL level which is central to that concept. You wrote a paper called ‘the use and misuse of SIL’ which is a little bit of a bible for me really. I go back to it and read it from time to time, just as a reminder to bring some common sense into some of these debates around safety integrity levels. Could you explain what a safety integrity level is and how it should be applied?

Roger Short   Yes, the problem which has existed right since the early days of software and still exists is that there is no recognised way of predicting what the probability is that there will be errors or defects in the software and the probability that any such errors or defects will do something which is harmful from a safety point of view. You can make that kind of calculation for hardware - particularly for electronic hardware where we have published failure rates for all the components used and you can apply reliability theory to calculate the probabilities of particular failure. So, you can come up with a number which says “Yes, actually the probability of this system failing in an unsafe state is 10 to the minus 10 or to the minus eight or something per hour. It's not possible to do the same thing for software because software science still isn't able to provide you with any basic concept of failure rates.

George Bearfield   And the reason for that is basically that software has branching logic and this logic very quickly gets so vast that you can never exhaustively test it. So every time you exercise it in a different way, you might uncover something that you didn't know was there, that was sitting there in the software design just waiting to happen.

Roger Short   Yes, that's right. Theoretically, from a sort of philosophical point of view, you could prove your software was completely correct by absolutely exhaustively testing it. The problem is that to get anywhere near an exhaustive test would require such a literally astronomical number of tests that the testing time would be longer than the anticipated useful life of your system. It will take longer than that to actually test it exhaustively.

George Bearfield   Yes.

Roger Short   This was realised quite early on, in the early days and the approach which was adopted was to say that we can't give a numerical prediction, but we can give at least a qualitative guide to what has gone into the process of ensuring that the software is going to be sufficiently free of defects. The safety integrity levels were a series of progressive levels of applying more and more rigorous techniques to get a greater confidence that your software would be free of defects. I heard somebody give quite an interesting analogy to that in the early days. They said, “well, look, take a sort of physical process like welding: You can't go around testing all of your welds to see whether you can make them break because you'll just be left with a broken heap of scrap iron. So you have to trust the processes used for the welding will produce sound welds.” Extrapolating that to software you have to trust that the process and the techniques you've used to produce the software will  give you software which has sufficient integrity.

George Bearfield   This links back to what you said before then, Roger, because this means that you do need to read these standards in detail and understand exactly what the mandatory requirements are because they are your means of assurance. And I guess the danger is sometimes people see this all as ‘paperwork’ when actually it's about ensuring rigour of your fundamental test and assurance processes to make sure errors don't creep in. In the case of the interlocking you were talking about earlier, those errors could bring two trains together at speed.

Roger Short   Oh yes, absolutely. Yeah. Yeah, so the consensus came around that we need a set of successively more intense levels of protection. We’ll call them ‘safety integrity levels’ and the lowest level will be SIL1 and the highest level will be SIL4. It was anticipated that maybe in the future somebody would invent something even better and we’d have a SIL5, but we're still waiting for that.

George Bearfield   You mentioned that it's impossible to put failure rates on software. Even with traditional reliability engineering though as somebody with a design engineering background I’m always wary of absolute failure rates. I always see those as more of a design tool to find out where the relative weaknesses are in your design so that you can improve it. But the absolute numbers are always, often fairly sketchy even then. But for software you can't do it at all. But yet despite that, the various software standards have quoted indicative failure rates for functions developed with different SIL levels, which certainly can cause a lot of confusion, I think.

Roger Short   It is not a good thing to associate a number with the safety integrity level. That's sort of the biggest misuse of SIL. But it's very difficult to separate it out. I think actually in the EN50128 standard itself it says very clearly “SIL doesn't guarantee a specific number is achieved”. Nevertheless, the guidance that people are given is: “Well, if your random failure rate for the system you're developing needs to be sort of 10 to the minus nine, then you should be using the highest level available for software SIL 4. You know, if it's an order of magnitude lower, you can use SIL 3 and so on. So its kind of inevitable that, people think that if you've built your software to use all the things it says in the standard for SIL then you can be quite sure that the unsafe failure rate will be equivalent to the SIL 10 to the minus nine figure which is quoted for random hardware failures of the corresponding part of the system.

George Bearfield   Getting back to the timeline, I think we first worked together probably in the early 2000s on the next generation of signalling interlockings where the processers were getting a bit more complicated and there was a variety of suppliers, it was almost a generation after solid-state interlockings with a variety of international suppliers.

Roger Short   That's right. Yes. Yeah.

George Bearfield   The bit that's relevant to me here is ‘data preparation’. So, software, (whether it's a signalling interlocking or increasingly say rolling stock systems like selective door opening systems) needs to be configured with local data. What is integral to that is how the data is processed, configured and turned into functionality. The process is integral to the failure rate. And so, you know that's a whole area that's often neglected because you know - generally the supplier's job is to define the process for turning raw data into functions and the toolset to do that. That's actually part of the asset, part of the signalling system or part of the train, if you like. And it's included within the scope of the standards. But often it's missed at the time that those systems are approved, and the end user gets more involved with spreadsheets and uncontrolled processes to try and feed the system with data which they can get wrong.

 Roger Short   That's right, yes.

George Bearfield   They can get the wrong function and so the end-to-end process needs to be assured. I think that's often missed in the realities of how projects progress.

Roger Short  Yeah, yes, that's quite true. In fact, the EN50128 standard does have a chapter in it on software data preparation. That's really important. Going right back into the history of software right back to the solid-state interlocking days, there was a bit of discussion about, “Well, you know actually what you're doing with this data preparation is you're actually programming the interlocking. So it's really a programming activity.” It was considered to be a bit frightening to suggest that, you know, railway signal engineers are going to do programming. “This is only data preparation”, but in fact the data includes not only things about geographically which signals and which points apply to which tracks, but it applies the control logic between them too, so it includes logical statements. You are, in fact, programming the system. But it was felt that this would cause great alarm if it was suggested that people who were used to designing relay circuits should have to learn to do programming. “No, no, no…We won't frighten them. We'll say it's data preparation”. And that's how it stayed. But I think an unfortunate side effect of that is it's tended to be regarded that errors [in data are] less of a threat than software errors. But in fact it is a form of application software. I'm always stressing to people it needs to be treated as such. You're also in an area which isn't fully testable, so you need to include checking, analysis and so on as well as a functional test of your system which you've ‘configured with data’ as we put it. You've actually loaded an application programme into and what you're doing is testing and validating that application programme.

George Bearfield   And so, do you think Roger, given that what we said before, around the fact that some of these SIL concepts go back to the 1970s, 1980s, do you think that the SIL standards are restrictive and still fully fit for purpose with modern digital technologies and the way that systems are built.

Roger Short   Well, yeah, there are two aspects to that. One is I feel that now, having these standards - having these established - has been a bit of a disincentive to look for any new or improved techniques. Why should you spend money on that when simply using the existing techniques according to the standards, is all you need to be able to get your product certified assessed and get it accepted? So the standards tend to create a disincentive to further research and improvement. The other area where I think they will be stressed is with the development of more complex systems and applications which the present standards have some difficulty in dealing with, and I'm thinking particularly there of machine learning techniques. If somebody is developing a system which has got some machine learning component within it and some functionality of that. I don't believe that the standards as they are at present - the EN50128 the software standard or indeed necessarily in 50129 the electronic system standard - would be sufficient to ensure that they were safe. There's some need for new techniques and for at least an extension and revision of some of the life cycle and process. Features of the standards need to be developed in order to extend them to be applied to technology such as machine learning. I think within the existing safety community, people would recognise “Oh no, this won't do. We can't entirely cover that with our present standards.” But I worry slightly that somebody quite outside the community will say “We're developing this we're going to use machine learning. Ohh we'll use EN 50128. Oh yeah, I will. We've done a lot of things. So we've now achieved the SIL.” From what I know of machine learning to date, I don't believe that that will be true. There are potential defects which the present standards would not prevent or maybe would not detect in their verification and added validation activities. I don't think it's impossible. I think we're back in the early 1980s situation where we need some more work development on techniques to extend that to cover technology such as machine learning. But what we have at present, I would have some doubt. I would feel that there would be dangerous gaps in it applied to a system which included machine learning in the development of its functions.

George Bearfield   There's a couple of points their, listening to what you say, I think. One thing that's misunderstood is that the standards do have flexibility, don't they? So you know if you've got a highly recommended technique for, you know, doing some sort of code analysis for example according to the standard, you're allowed to do something else as long as you justify it. But what you were referring to is that there's something structurally wrong with the standards and the mandatory requirements within them that needs rethinking: that is what I heard?

Roger Short   Yeah, I yes, I think. Possibly not entirely rethinking, but at least extending it. I regard machine learning not as some totally new phenomenon which is quite outside of anything we do at present. No, I don't believe that. It's just mathematics and software. But it's mathematics and software which is used in ways which our present techniques don't cover and we need to develop new techniques, a new lifecycle and new organisational arrangements to extend the standards to the new technology.

George Bearfield   And then. Roger, flipping it around, because you can look at AI and machine learning as both an opportunity and a challenge. Do you think machine learning offers some opportunities to enhance the verification, validation and assurance processes? I'm thinking particularly as you talked before about the practical difficulties of exhaustive testing, but you know, perhaps quantum computing and other things could start to make a dent in that, and particularly apply with some targeted testing [through simulation], for example additional brute force in an intelligent way?: you know, checking some of the automation and data preparation issues and removing some of the human error from that? Is that something you're given thought to and do you think there's opportunities to progress there?

Roger Short   I'm sure there's opportunity to progress there. I think there are lots of ways that AI and machine learning tools could support the development of safety critical systems. The bit about that which worries me is that, even at the moment, we're inclined to be a bit easy going about the tools that we use: “Oh well, this is only a tool. It's not actually being used functionally in the system. It's not providing the function itself.” But we're still depending on it. We're still depending on the tools in some ways for ensuring that the system we develop will perform the function correctly and I think people fall in to the trap “Oh well, since there's a tool we can always check it’s output,” but if it's a really sophisticated tool which does all kinds of clever things, it's really going to be difficult, if not impossible, to actually verify and prove to yourself that what that tool has done to the end system you're producing hasn't introduced some kind of defect. You're left with a problem with the tool which may introduce defects, which is just like the original problem of how do you ensure that there aren't any defects in in your functional system.

George Bearfield   Yes. Yeah.

Roger Short   I think that's perhaps manageable at present, but a step towards an AI type tool offers great benefits but being able to trust the tool and rely on that not to result in defects in in the actual operational system is still a question which has got to be solved.

George Bearfield   The final question from technical question from me Roger, really was around cyber security. I know we're both on the drafting group for 62543, the new cyber security rail standard. What additional challenges do you think cyber security poses for safety? I’d be interested to know conceptually how you think we should go about making safe, secure rail assets in the future?

Roger Short   Well, it seems to me that the biggest tension there - between safety and security communities - is that the security community wants to react very, very quickly as soon as they become aware of a new threat. They want to rush out and patch the software. The safety community wants to go to very great lengths to verify and validate any software modifications which are made in case they introduce some unforeseen defects and there are two sort of almost diametrically opposite goals there: “We want to do it quickly,” “Oh no we want to be absolutely sure that it's safe.” I think probably the most effective way of dealing with it is to be able to segregate the software which is essential to safety from the any software which might have to be patched quickly as a result of security threats and that will be an important part of system architecture: keeping the safety critical software in the areas where the security critical software, which has to be patched quickly is external to and segregated from the safety critical software.

George Bearfield   I'm glad you said that Roger because I agree with you entirely on that one and it brings me full circle then to the reason why I was keen to have a chat today. For those who've spent time thinking about these things there are clear principles. But we've got pressures for more flexibility, driven by cost and we've got a general lack of awareness of some of these things. So that was kind of the driver: More people need to understand these tensions and how they need to work: these principles. The understanding of some of the topics needs to broaden out and we need to help people get beyond thinking: “Well, this is just technical software stuff.” and really starting to understand how central this is becoming to the whole viability of the railway.

Thanks ever so much for your time. I'll draw stumps there, Roger. But I could keep talking for hours on these topics, and I know you've got plenty more you could say. Thanks for your time: I've always found you bring a common sense touch to this topic and I've always appreciated that. I’m really glad to have worked with you on these topics at a formative stage in my career because I often reflect on some of the conversations and things we worked through on projects. And I'm keen that more people understand some of this stuff as we move forward. So thanks so much for your time.

Roger Short  I've really enjoyed our chat, George that thank you very much.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit techsafetransport.substack.com

A Happy New Year to you all.

It’s another podcast this week, and a conversation I had a few weeks ago with Philip Ingram MBE BSc MA GCLI who is a widely published journalist, specialising in security and intelligence, following a long and senior career in British Military Intelligence.

It was a wide-ranging discussion that allowed us to explore the dynamic and evolving nature of transport cyber security, and in particular the increasingly grey boundary between civilian and military threats. If you want to understand more about these risks and threats and how they are likely to evolve please take a listen. There’s also a transcript below.

If you aren’t already subscribed please do so now, so you don’t miss the next post.

Transcript

George Bearfield: So, Philip, what's your background and where does your interest in military intelligence and cyber security come from?

Philip Ingram: Well, my background is 26 years in the military, with the majority of my career in military intelligence and as a strategic planner. Part of my role as a senior intelligence officer was setting - in the early days of cyber security - cyber security policy standards. So, I had overall responsibility for security in many roles and that got me into cyber. After I got out of the military and spent a couple of years not focusing on it at all, I got back into the media side of things. I’m running a publication that looks at all aspects of security and cyber because it has got its electronic and digital tentacles into everything is a really important subject.

George: And how do you think the cyber threat has escalated over the time you've been involved, particularly over recent years?

Philip: Well, the cyber threat in some ways is always changing, and in other ways it's quite simple. A lot of the successful attacks that are out there at the moment are the same sort of attacks that have been going on for years and they're just exploiting vulnerabilities that in many cases people have known for years. But ‘cyber’ changes because the way we use our digital assets changes and the cyber threat landscape changes as well. So only a few years ago, the majority of security devices were hard wired together. They weren't connected to a network and therefore they were connected electrically rather than electronically. But with the advent of IP devices we're starting to see more and more devices connected into networks and all that goes with that. It grows the cyber threat landscape and you then get the ‘Internet of Things’ - or as I call it, the ‘Internet of Threats’ because you know, that's exactly what it is. You're ever increasing this threat landscape that can be exploited again into your network. And I think we're just about to see another sea change in the coming years with generative AI. [Until now] it's been that you need to understand what you're doing to [develop] code for attacks against endpoints and attacks against networks and everything else. That has been exploited by cybercriminals carrying out attacks as a service (and you can buy those quite easily online - you don't even need to go to the dark web to get them). But now, with the advent of generative AI, anyone can write code because you can get ChatGPT, or other generative AI's to write you the code that you need to attack various endpoints by putting in only a few criteria and this is where I think we're about to see a change.

George: It's not even as if you need it to ask it to write code - you just set a goal and it will seek its way towards that goal.

Philip: Exactly. So, you know it's an ever-evolving environment. The one thing I will say is that people focus on cyber at the expense of everything else. You know, it's a ‘digital’ issue and I'm holding up one digit of my hand here: One of my fingers, you know, it starts in the physical environment whenever these digits type code because someone has gotten various ideas and how to what they want to do with a network and it's one of these digits that clicks on the link that tends to then infect a network. So it's a physical environment and cyber is just the enabling piece; the enabling environment, for that particular threat to exploit as it goes in.

George: Well, it's interesting that you mentioned generative AI in terms of it doing this sort of technical side, but of course generative AI can also mirror and make more complex the whole kind of social engineering side and attempts to trick people into doing certain things with messages that appear credible or as if they're coming from somebody that you trust.

Philip: Well, there's this. This is where you know it's not quite cyber, but we have to then get into the information game because you know, being able to produce credible messaging and we see that with a lot of the phishing scams that go out around the place. They get better and better and better and they've been relatively easy to spot over the last few years because the grammar is wrong or the phraseology is wrong or the images are wrong or something else is wrong in it. But once generative AI comes in, it's going to be much more difficult to spot. I know cybersecurity professionals who are responsible for overall security in their own companies and they've set up ‘red team’ attacks into their own company. They've been the one that have known the attacks are coming and they've fallen for the first phishing email themselves because people have used social engineering to exploit different bits and pieces. Then we get into the game of information exploitation and the ability to influence the way people think; their decision making, and that utilizes the digital environment. There's a debate as to whether it's actually a cyber security issue or not, but it's a security issue that doesn't really sit well anywhere. And with it exploiting cyber connectivity, especially through the use of social media and everything else but, but also manipulation and use of big data is something that I think we have started to see in the past but will become more important in the future.

George: One area I was particularly interested to get your viewpoint on Philip - given the background that you've set out - is this. I've [mostly] worked in civil transport and civil industry and mainly rail. And there's almost an implicit barrier in people’s heads between peacetime and wartime, but the more I learn about the cyber-security space, the more I start to see that the boundary between nation state, military confrontation and some of the criminal activity isn't as clear as perhaps we would have thought. This term ‘hybrid war’ keeps popping into my head and the idea that malign nation states are probably cataloguing our vulnerabilities and investigating our civil infrastructure now in readiness for a possible future situation where things might turn very nasty indeed.

Philip: There's no probable about it. They are doing it now and they're doing it in a number of different ways, and your hybrid warfare is where we are. If you wanted to look at it from a cyber perspective, we are effectively at war continuously every day. You describe the rial network: critical national infrastructure is one of the targets that is continuously being probed. Vulnerabilities are being looked at and every now and again we see little ‘beta’ testing of cyber weapons and that that nation states are doing it. But nation states are also sponsoring it. If you look at a number of the APT [advanced persistent threats] that are out there - and you look at where they're configured - it's no accident that there's a large number based in Russia, because they won't be prosecuted by the Russian authorities. But they'll only not be prosecuted by the Russian authorities if they continue to cooperate with what Russia wants to do. Therefore they pay their dues and their dues are financial dues because they make a lot of money out of a lot of the cyber-attacks that they're doing from a criminal perspective. But they're also their dues in carrying out operations on behalf of the Russian state. So that you know the Russian state can stay one step away if it's identified as come in and keep that that level of separation. You see the same in China. You see the same in North Korea, although we know that in North Korea everything is state controlled, and we know in China everything is state controlled. Russia, there's that little bit more liberalism. It was interesting when the Ukraine War happened because a lot of the criminal, cyber, APT that there are, especially Russian based: they'd run themselves like businesses and they'd have leave plans and they'd have people that specialize in particular areas. And they pay them quite well, and they’d have contracts and everything else. And once Russia invaded Ukraine, there were quite a significant number of their subcontractors who were Ukrainians, and they didn't want to work for a company that was based in Russia anymore. So they lost a degree of their capability and have been having to try and regenerate that again. It’s a professional organization whenever it comes to their business approach and that is recognised by nation states and forms an integral element of what nation states do, of course, nation states themselves have got their own their own integral cyber capability too. And that's not just Russia, China, and North Korea. It's also all other nation states. You know, the UK has got the National Cyber Force and that is an active cyber capability carrying out offensive cyber operations.

George: Absolutely. So when you said about paying dues as well, I think it might be good to make this explicit or at least get your view on what I suspect is the case, but don't often get the opportunity to talk to people about: which is, when there's a ransomware attack on, say, a transport company and the criminals are in the network for some time they’ll be ‘paying their dues’ in terms of disturbance caused and nuisance caused and also the financial terms. But they'll also be looking to exfiltrate as much data as they might be of us for that nation state to think about offensive cyber-attacks and crafting those in the future, as well as well as looking for backdoors and other places where they can set themselves up for future attacks in the network.

Philip: Of course they do. You've got a lot of people who think “Oh, I will never be subject to a cyber-attack, because who's going to be interested in little old me?” But then you sit down and start to ask them what contacts they've got on their mobile devices or on their computers and who those contacts work for, and you'll find that they've got say, a local politician. I deal with journalists a lot. You know, the journalists have got Minister’s private contact details on their phones and once you've got that, you may be attacked to get that data. So it can be exploited elsewhere, and every little bit of data helps. If they know who your friends are, and we've seen this with the phishing scam emails that come in, if you get one, you know from your best mate John saying, “hey, this is John,” and they've got the style of how he writes because they picked that up, from doing social media analysis and all the rest of it, and it comes in from an email that looks like his, you know, in a very busy work environment the chances are you're going to click and open the email. It's very difficult for people psychologically not to and that's how they're getting into different networks.

But the paying their dues is that for the different APT's sitting in different countries, they will pay a financial tax to allow them to continue to operate there and they will also do an operational tax. So they'll have to respond to tasks that are given to them by the nation state. So the nation state can remain sort of one step divorced from the actual attacks that happened. But it's all about data. A friend of mine, is the leading King's Council when it comes to data protection and all things cyber and Internet and has written the international legal textbooks on it. And he describes data as the new gold, the new oil. It’s that valuable.

George: So I have two related questions: I guess the first is that you talk about the importance of critical national infrastructure - I'm particularly interested in transport. How much of a target are Transport networks and above all critical [transport] infrastructure and what do you think the relative priorities are for Nation States in terms of trying to seek to gain a foothold?

Philip: Critical infrastructure across the board, and transport in in particular, will be being targeted on a daily basis. You know it is a very, very high priority for nation states, principally because of the amount of data that is processed. It'll link to so many other areas. So they want to do it for two thingsL to get access to the data that's linked to the critical national infrastructure so that they can begin to understand how it’s put together; who the key movers and shakers are in it, what the issues are that there are with it so that they can influence that at some stage in the future and tune their attacks to carry out the effect that they want: Something serious in the future. But they also know that anything around critical national infrastructure has got a political element to it. And therefore they'll try and exploit that. They'll exploit that from a wider information perspective and everything else.

George: The capabilities which have been developed for really impactful attacks on critical infrastructure are by their very nature held back and would only be used when it's needed to use them, because otherwise people expose their capability and then that capability is copied, inevitably copied and shared by others. And we saw this with the Stuxnet attack, which of course you mentioned the fact that Western nations have a pretty sophisticated and cyber-attack capability. Well, that was evidenced in the Stuxnet attack on the Iranian nuclear centrifuges. But when you look into that attack, which was actually undertaken for a pretty high profile political objective - a political and military objective - it led to that level of technology and level of attack to be exposed for others to use. It was a hugely technologically advanced attack, and that was many, many years ago.

Philip: Yes.

George: So it makes me wonder what the what the capabilities are that aren't exposed but exist out there at the moment and what we might expect to happen should the political and military situation escalate to such a stage that some of those techniques would be used?

Philip: Well, we're seeing so many developments and techniques. You know, I'm looking at stuff that’s out there before I hypothesize a little bit. So we know that for the ‘Pegasus’ software to infect a mobile device, all you have to do is receive a message you don't have to open anything. You don't click anything. The device just has to receive a message and that gives control over everything that's in your device, even when your device is switched off, they can remotely switch the camera on they can access all the data that's on it. They can switch the microphone on and everything else. The only way you’d know was your battery tends to run down slightly faster than you expect, but that seems to happen with every upgrade that you get in an iPhone anyway. And that's a bit of software that we know about. It’s been found on a lot of senior politicians’ devices, and it was used to track the Saudi journalist Khashoggi in Istanbul before he was murdered in the Saudi embassy. But nation states will have something that is equally powerful, if not more powerful. And this is where we have to look at where our potential vulnerabilities are. Our networks are fantastic. Our networks and network protection are pretty good across the board because we've got, in many cases. AI enabled capability looking for any unusual activity on a network and I can spot it instantly and alert it and everything else. But you have to ask yourself how much actual work is done on something that is permanently connected to a network with mobile devices getting more and more powerful? The majority of work is actually being done on mobile devices, not permanently connected to the network. They just go to the network to access the data that you need. It draws that data down and saves it. You know you what it is that you're doing back up onto the network again, but if I wanted to attack to get data in particular a particular network, I'm not going to attack an endpoint that is connected into a network where there is a very sophisticated array of different capabilities protecting that network. I’m going to attack an endpoint that doesn't and that's a mobile device and therefore mobile devices I think are one of the biggest threat landscapes that there is at the moment. Within mobile devices we look at you where is a threat vector likely to come. How do you get illicit coding onto a device or get the user of a device to give permissions to access everything on there without them knowing it? You produce a viral app and I give a lecture around the world looking at Pokémon go. And you look at what Pokémon Go did and it encourages people to take pictures of different places. I was thinking with my old intelligence hat on if I wanted to send a specialist team to get some photographs of a top-secret establishment in a harsh country, it would take me 9 to 12 months to plan the operation. The team would probably last on the ground for two weeks maximum if I'm lucky, and there'd be a major diplomatic incident. However, I get the 12 or 14 year old child of someone that I know that works in there to take pictures around it because they're driving past it on the way to school because I put a high-priced monster outside and the additional bonus that I can access all the data that's on the device that's doing that. In those countries those devices are going to be, you know, the parents devices and potentially the work device because that's the only one that will be allowed to use these sorts of apps. Now I'm not saying Pokémon go has been, you know, in any way you used for that. But the potentials there.

But you look at the likes of Tik, T.O.K and you have to ask yourself a question. You know, is Tik T.O.K, a fantastic video sharing platform first and foremost is that its primary role or is it probably old ad data harvesting device and you know, data harvesting, what else can at harvest on your on your, on your phone whenever you've got it sitting there. And from the research that I've done, it can access literally everything.

So the threat landscape is changing. And we have to be very, very wary of it.

George: Going back to rail as critical infrastructure: I know you pay very close attention to the the war in Ukraine, and that's been a real test bed for technology. And obviously it's also been an area where rail has shown its importance for: evacuating refugees’ for bringing in supplies (military or otherwise) and for troop movements. I just wondered if you had the insights into what we've learned about the importance of rail and its security in a war footing from the war in Ukraine.

Philip: Well, Ukraine is an interesting one. Because, you know, Russia is so vast and it relies heavily on the rail network for getting its troops, it's equipment. But more importantly, its combat supplies, it's logistics, as close to the front line as possible. And they don't have huge numbers of trucks and everything else. So the rail network is absolutely critical to Russia's war effort. And you look at the size of Ukraine, Ukraine itself is the second largest country in Europe. It's really difficult to get your head around just how big it is. The frontline and fighting in the East is, you know, 400 plus kilometres long and what's going on in military terms, trying to get trucks to move stuff around, especially whenever you've got drones and missiles and other things that can intercept them is not good militarily. Getting vast quantities of Military material to one place by rail is essential, and we've seen a number of cyber-attacks against Russia’s rail network. Now the Russian rail network is still very Heath Robinson, and it's still quite old and therefore what we're seeing is Second World War type operations and destroying signal boxes and derailing trains and other things that are being used to disrupt what's going on.

And it's interesting to see the old techniques being applied with the new techniques as Ukraine tries to disrupt Russia's rail network and logistics supplies and they’ve been doing it quite successfully. I personally believe that this winter we're going to say a marked increase in those sorts of attacks across Russia.

George: You talked about disruptive technology, I think and from a sort of arm’s length perspective, one of the things I've been watching with interest is the extent to which drones have really become a disruptor in warfare and how Ukraine and Russia and seemingly every country is experimenting with drones. But I just wondered if you had any insights into where that's likely to go and what impact they've had on the battlefield.

Philip: Well, it's not just drones. It's commercial off-the-shelf drones that have had a massive impact because they've been able to get huge numbers of very cheap drones. $1000 gets you a very capable drone. Attach a cheap explosive device to it and fly it into the back of a multi-million dollar armoured personnel carrier and when it explodes it sets the ammunition off in the in the back of that and destroys the vehicle. It’s a very cost-effective way of destroying military material, and it's also being used effectively as a long-range sniper. So the FPV (first person view) drones in particular are being used to take individuals out. This is a sea change in conflict. Electronic warfare is then very important to jam the control mechanism for the drones and to try and protect against them. I do know that Ukraine is developing its own drone manufacturing capability at a huge rate of knots and a lot of that is designed to get round the electronic warfare jamming and other bits and pieces. Russia's taking a slightly different view on it, in that what they're doing is they're buying kamikaze drones and stuff from Iran and elsewhere, and we see that with the Shahed 136 and Shahed 131 kamikaze drones. But Russia is being squeezed by international sanctions and is having difficulty getting its hands on the electronics that it needs. Whereas Ukraine is getting as much help as the West can pour at it, and I think this is one of the big growth areas that we're seeing in warfare: the drone becoming the sniper rifle of the future.

George: And I guess we're seeing the effect of drones in the maritime war as well.

Philip: Oh hugely, Ukraine, a country without a Navy, has already sune one of Russia's largest ships. Some of its newest ships destroyed the submarine on all of this is using drone technology. You know it's using Western missile technology, but it's phenomenal what's going on. And I know within the militaries of the West it’s really raised a lot of eyebrows and people are really having to think about things in much more detail. Then if we extrapolate that into potential future threats, we see these amazing displays at a lot of big sporting events where you get the drone displays going up at night and you get swarms of drones doing different patterns in the sky. And we saw it in London and New Year's Eve last year. We'll see swarm drones connected with AI enabled targeting: that's frightening. You could use that to swarm into a crowd and take out people that you specify in AI. As to the targets that you're looking at and you're looking for, there's a lot more to come with this and this is where, conflict tends to accelerate technological change.

One of the biggest areas of technological change that we're going to see is the use of drones from an aggressive and offensive perspective, but also the use of technology to try and defend against drone threats as well is being developed almost as fast.

George: And just again going back to the sort of the transportation side and critical infrastructure, if I look at rail for example and the cyber security threat, a saving grace really has always been that on rolling stock, for example, emergency brakes tend to be hard wired, relay driven or you know kept away from networks. But we're now moving - in the UK, Europe and the world - into digital signalling and which is integrating the traditionally slightly separate trackside signal interlockings and the trains into one sort of network enabled or Wi-Fi enabled set of functions. I mean from what you said before, it's probably inevitable that foreign nation states who are potential adversaries are looking in detail at this and what they might be able to do with it?

Philip: 100%. They will be and the and this is where I've got some real concern: you know driverless cars or interconnected cars now: I've seen those being hacked live. They can't be protected. The Americans can't keep their list of all of those with the highest-level security clearances across the whole country secure without it being hacked and released. Sony Pictures can't keep its latest blockbusters secure without it being hacked. And we connect our critical national infrastructure and our railways and all the rest of it. I'm really concerned that it gives a huge amount of potential to cause a massive amount of disruption and we only have to think back to the earliest movie that there was that showed a cyber-attack on a transport infrastructure network that caused complete chaos. It’s one that most people won't remember and won't think of. The cyber perpetrator in it, the actor that carried out the cyber-attack was Benny Hill, and the movie was ‘the Italian Job’.

George: Yeah.

Philip: Where they [dramatized bringing] the whole city's traffic light. system to a complete standstill by injecting the wrong code in through the computer control traffic light system. That was way back then. If we're bringing in network connected controls for our rail network and everything else, people will be working very, very hard trying to find vulnerabilities in it so that they can exploit that at some stage in the future with an exploit for political purposes. So you know Russia could cause disruption to a rail network in the run up to general elections, so that people go, “Oh, it's the government not investing.” and everything else. Whether it's to give advantage should they go into a conflict scenario or anything else in between. So it's extremely worrying. On the positive side, I think the UK's almost the envy of the world and that we've got this organisation called the National Cyber Security Centre that is sitting, looking at all of the threats that are coming in. They're harnessing the power of industry as well as what the government's got as well as what we're getting from international partners. And from what I'm seeing, they’re very, very good at identifying threats and mitigating most of them before they get in. But again, at the end of the day a cyber attacker only has to be successful once the NCSC has to be successful all of the time.

George: I'm a risk management person, so I spend a lot of my time thinking about low frequency, high consequence events. It can get a little bit disheartening when you're always in that space. I guess the difficulty is to do objective risk assessment because the likelihood [is difficult to estimate]. They're not random events, they're conscious events. And so it's a very difficult one to get a balanced picture of how credible the threats and the risks are.

Philip: Yeah, well, again we've got a dedicated organization that looks at that and puts that together. It's called the National Protective Security Authority, the MSA, and the MSA works very closely with NCSC from a cyber perspective. But it looks at things from a much more holistic side of things and into threats. It used to be called ‘the Centre of the Protection of National Infrastructure. But the remit has grown because they took in a lot more responsibility just outside critical national infrastructure and it's bringing the physical side together with the cyber side. They're continuously assessing the threats that there are. They know what high value targets across the UK would be and then provide advice and the lovely thing about the two organizations is not just that they work together. The level of advice that they provide is phenomenal and it's free and the capabilities that you have on their Internet links are superb. It's the sort of thing where a lot of consultants will go out and charge a lot of money for saying exactly the same thing that's available for free on these government websites and they are proactive.

George: Yeah, absolutely. So that's a good point to bring things to a close on Philip. That it's not all doom and gloom and we do have a pretty good, world class, capability in in the UK certainly and also with our partners in the Five Eyes and elsewhere across the world in trying to deal with some of these risks. Any advice or pointers for people working in transport sectors about how to approach these risks in the coming years?

Philip: Well, I think there's a couple of bits of advice. One is to get the basics right, because if you get the basics right then it will protect against the vast majority of attack vectors that there are out there and have a cyber mindset where recognise that everyone is part of the wider cyber community, it doesn't matter who you are. It doesn't matter whether you're the person tightening the bolts on the new rail that that goes in, you'll have to type something into an electronic device somewhere, or you'll have a fitness tracker on you, or you'll have your phone and you'll get work emails. Everyone is part of the wider piece. Everyone’s got a degree of responsibility. If something happens and something that's unusual goes on, you don't ignore it. Hopefully there's the culture within the different organisations too, to enable people to go and report it to a professional. And, you know, ninety-nine times out of a hundred it's not going to cause any problems whatsoever. But there’s that one nugget where a threat can be mitigated before it promulgates across the network and causes huge amounts of disaster. So you recognize that everyone has got a responsibility in this? We’re an interconnected society and we're only going to become more interconnected and therefore you've got as much responsibility for your security - your work security as the organisations that own all of the networks and the infrastructure.

George: Absolutely thanks ever so much. Philip: It’s been a pleasure talking to you.

Philip: George, my pleasure.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit techsafetransport.substack.com

A Happy New Year to you all.

This post is a recording of a chat I had at the end of last year with Diane Chadwick Jones, who is a former Human Performance Director at BP.

I’m afraid my transcription failed to work this time, so there is no written transcript. I will try to do better next time, but in summary, we spoke about:

* How Diane came to be involved in Safety Culture and Safety Management.

* What is Safety Culture? (2:57)

* The link between safety performance and reward structures (6:14)

* The use of leading indicators, and points reward schemes (10:29)

* Pressures that might be created by the current economic climate (13:40)

* The importance of safety culture to the prevention of rare, major accidents (16:15)

All industry sectors are under pressure at the moment from a range of challenges, with inevitable impacts for the workforce. This discussion was a timely reminder for me - as I hope it will also be for others - of some of the key principles of safety culture, and how to encourage the behaviours that are needed to prevent the occurrence of major accidents.

Diane’s paper “Rewarding safety performance: Improving safety or maintaining beliefs?”, which we discussed, is available here.

Thanks for listening

Please feel free to feed back any thoughts or comments and please do drop me an e-mail on [email protected]: My particular area of professional and research interest is practical risk management and assurance of new technology. I’m always keen to engage on interesting projects in this area.

I will continue to mix podcasts with written posts in 2023, covering topics as diverse as software safety engineering and the emerging security challenges in the war in Ukraine. Please do subscribe to make sure you don’t miss a post.

And if you know anyone else who you think might appreciate a thought-provoking read or listen every few weeks, please let them know:

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit techsafetransport.substack.com

It’s another podcast this week, and a conversation I recently had with Bloomberg reporter and author of “Flying Blind: The 737 Max Tragedy and the Fall of Boeing,” Peter Robison. For those who would rather read than listen the full transcript of the interview is below too:

George Bearfield: So how did you come to be interested in the topic of the Boeing 737 Max tragedies and interested enough to write a book about it?

Peter Robison: It really comes from my experience covering Boeing as a reporter for Bloomberg in the late 90s and early 2000s. I moved to Seattle for Bloomberg. I was the Beat reporter and Boeing at the time was flying high. It was, you know, widely considered one of the preeminent American manufacturers, and it had more than 60% of the aircraft market. But I was surprised to find there was a lot of internal disagreement about the course it was taking. It was pursuing a sort of a strategy replicating what General Electric and Jack Welch were doing and focusing on services rather than manufacturing, and top leadership is less interested in commercial airplanes as a business. Engineers at the time were telling me that there seemed to be less of a basic commitment to technical engineering that that research was being cut back. In 2000 there was a strike where the engineers left for 40 days and that was largely due to their disagreements with the company’s strategy.

So I mean, there's a very powerful narrative that you pull out in the book around the strategic change to Boeing over a very significant period of time. I've got some questions that I want to get into on that. But before we do, would it be possible just to explain, for those who don't know, what actually happened in those two really impactful accidents.

Yeah, of course the thing that really drew me in was the two accidents that happened within five months of each other in 2018 and 2019. It was almost a brand new plane: You know, the Max was supposed to be a simple update. It was launched, it was flying with airlines and then there was a crash with Lion Air in Indonesia and then five months later, a crash in Ethiopia. It became quickly apparent that they were due to the same cause, which was that a faulty AOA [Angle of Attack] vein had sent a signal to a piece of software called MCAS that ultimately tipped the nose of the plane down. The pilots had no control over the descent. So it was the single point of failure that commercial aircraft aren't supposed to have. And part of the book was in trying to understand how and why that happened.

It paints a pretty horrific picture of how that must have felt for the pilot and for those on board, doesn't it to have that kind of fault where the, plane is literally doing the opposite of what you want it to do. It's a really terrible fault mode. So going back to the story of Boeing then you paint the picture of Boeing: this sort of pioneer of aviation with a really good safety record. And then you paint the story of the various things that happened and almost inevitably seem to happen when their focus shifts to commerciality. And the bit that interests me is that it's such a long time frame, the story that you tell in the book, and it almost feels like there's a horrible inevitability to everything, and so I guess there are two questions I had. The first one is from your insights and what you've learned, how do you catch that in a reasonable amount of time and and steer things back?

Well, I mean, it's an interesting question because it does raise the idea of the narrative fallacy. You know, is it only obvious because we're looking at it in retrospect? But certainly when at the time, going back 20 years, there were warnings that something like what happened with these crashes was likely to happen. And you know the other really excruciating thing I'm trying to understand the narrative was that there were people on the engineering team who were raising questions about what might happen in this failure mode. What happens if we get a faulty AOA vein, and that person was told, you know, don't worry, the system will shut off immediately. And that was incorrect because there was a faulty communications loop. There had been a lot of business decisions made that separated people who had previously worked side by side from being in close contact with each other and you know the argument I make in the book is that it ultimately came back to this commercial pressure that was put on the engineering teams and that if they've been given the time to run all these problems to ground, you wouldn't have seen these crashes. The engineers that I talked to had worked there for decades, you know, said that what Boeing strengths had always been was that it identified problems, you know there are always problems that come up in something that has millions of parts. But you know Boeing’s strengths had been in putting huge teams of people together and just crushing the problems. And in this case, more recently, Boeing was pulling apart it's teams and trying to make do with less. It's structures were redesigned to focus on services and to outsource more and more.Yeah, the other thing that interests me, as an engineer, is that I spend a lot of time thinking about how to manage complexity because there's a growing creep towards automation and to making things more complicated. Complexity seems to be almost an end in itself sometimes, but actually the interesting thing here was that the AOA failure mode - despite all the complexity in the plane - was something that was fairly basic. Sort of undergraduate reliability engineering.

Yeah, it's interesting. And that's sort of the contrast of this plane. By the standards of modern aircraft, the 737 is rudimentary, according to the pilots and engineers I talked to. It was [originally] designed in an analogue era before there were significant amounts of software on the plane. And over time, it's been updated so that it's neither one nor the other. And that was where the potential for problems arose because there is a handoff between the automation and the person and unless the person is aware of what the automation is doing, they're not going to be able to intervene and understand what's going on.Yeah, that was very apparent from reading through the book. If you're familiar with the ‘Swiss cheese model’ of accident causation: It's a bit like, if you've got a leak eventually the water will find the way through the holes. There's maybe aspects of narrative fallacy, if you like, but the other side of it is if you put enough pressure on a system, eventually you'll find the holes through it. There seems to be, again, that classic example of the alignment of the different circumstances where you had the commercial pressures; you had this underlying fault; you had the training requirements being watered down; You had the failure to put in place an electronic checklist and in effect not making the fault fully visible. Then another aspect to it was the regulatory side, which I thought was quite fascinating and the sort of approach to ‘self-assurance’. Is it possible just to say a few words about what you gathered around what happened there and the dynamic around that?Yeah, for decades the regulation had been outsourced to some extent from the FAA to the manufacturers and the FAA relied on engineers at Boeing to check off on these dozens and dozens of individual requirements that needed to be followed, which would have ensured that there was redundancy in commercial aircraft systems over time. The FAA [had historically ensured that there were] checks and balances to that and the system that have been in place at Boeing. This relied on this ‘dotted line’ reporting relationship between the delegates at Boeing and managers at the FAA. But increasingly Congress, partly to save money and partly for philosophical reasons handed more control to private industry, Congress started allowing the FAA to allow the managers at Boeing to sign off on more of their own work. There was less of a relationship with the FAA manager. The engineers at Boeing would report to their managers at Boeing. The managers at Boeing would then interface with people at the FAA and the engineers at the ground level felt that what emerged was managers at both the manufacturer and the regulator working together to speed the aircraft to meet compliance rather than holding manufacturer's feet to the fire and making sure from the start that the compliance was met.And it is interesting because I like looking at trends and partly this is complexity driven, isn't it? Because the more you localize design, the more design complexity you make and the more of a sort of broader supply chain you have, the more it is likely that the regulator is not going to have the skills they need to truly understand the system. It sounds horrific when you look at it in the post-accident scenario. But also it's a function of the growing complexity of some of these technological systems.

Yeah. And also almost the deliberate dumbing down of the regulator. It was increasingly lacking funding to hire the best people to train its own workforce and just to have the number of people that needed to do that job.The other aspect of this is of course that Boeing is a huge corporation - there can't be many people who haven't flown on a Boeing plane, you know, many times - and the financial impact, because you talk about the cost savings and the cost drivers for this. But the financial impact of these accidents is astronomical. So, I mean, I remember reading somewhere that it caused 1/4 of a point drop in US GDP for a year or something - I'll come up with a figure - But it was something frightening. [Note:  sources speculated that a pause in 737 Max production in 2020 would lead to 0.2 percentage points from US GDP growth for the year GDP effect of a longer pause in 737 MAX production.]

Yeah, Boeing has long been the biggest manufacturing exporter in the country. And for a long time it's been also one of the few manufacturers that still has many jobs that are in in the United States rather than shifting overseas. And a massive supply chain as well, I guess.

Yeah,  a massive supply chain that so that that plays a role in, you know, decisions made by government where it's difficult to force change when you know so much of the economy depends on this company.Yes. So as well as obviously the massive human cost you've got, you know, it is an irony, isn't it -  in the analogies it’s the costs under the iceberg isn't it? If you could properly visualize the risk on the bottom line then clearly those cost savings didn't even make sense from a financial perspective.Right, right. Yeah. I mean, Boeing has for a long time been reluctant to fully update the 737 because of the sunk cost of this huge manufacturing and supply base. You know, the initial tooling is paid off. So its profitability for each of these airplanes is good. And so if it were to invest the amount that analysts had said, they would need to invest for an all new plane to match Airbus, which developed its plane 20 years later. That amount would have been $10-15 billion. Boeing made the argument to its board that [they could do it cheaper]. The tagline for its pitch to the board was that this new derivative would be “stingy a with a purpose” and the purpose was to match Airbus but not spend anymore than they needed to. It was that the cost was going to be a billion or two instead. Then Boeing had these terrible accidents and human toll and costs to its reputation. And the financial penalty ended up being more than $20 billion when all was said and done.

Are you still following progress? I'm aware obviously that plane finally got its certification to go back into operations some time ago internationally and I guess that was quite a ‘bun fight’ between European regulators and American regulators and others with the ongoing competition between Airbus and Boeing. But are you up to speed with where things are currently and is it possible to summarize from your perspective?Yeah, well, you know, so the Max is back in service in most of the world. The big exception there is China, which had been up to 1/3 of Boeing's order book for single aisles planes. But China - partly because it's developing its own single aisle plane - seems to be withholding support. So that's a real question for Boeing's commercial prospects going forward if that relationship isn't fixed. The other way that these accidents set back Boeing was that it had been on the verge of potentially introducing a new single aisle plane to match Airbus, the 797. However, Boeing has now said that that is not going to happen for at least a decade. In the meantime, Airbus is scoring thousands of orders: well ahead of Boeing in that market. So there's a real risk that Boeing tails off, as McDonnell/Douglas did before it, and becomes a secondary player going forward. These things take a long time so this is going forward over 10/20 years.You're right. I mean, nothing is permanent, is it? And they are certainly an impactful couple of accidents that are obviously going to have a major impact on the business. As a safety engineer, there are certain accidents that have happened in the past that become fundamental in terms of learning. That's one of the things you can always take out of a major accident in consolation and often the bereaved do that, by saying “Well, at least we can make sure that nothing like this ever happens again.” On the safety side, accidents like Challenger, Piper Alpha and the Bhopal chemical disaster in India spring to mind. For me now, the 737 Max has become one of those cautionary tales. They each have their own high-level lessons to learn. How would you summarize the kind of fundamental learning from what's happened with the 737 Max?I mean the fundamental lesson as it's been described to me is, is that you need to take into account the the human factors. That was the core problem in this crash that the reaction of the pilots was not what was expected. And that's because their reaction was not tested before Boeing introduced this plane and allowed the public to fly on it. That there was a rudimentary test done, but it didn't simulate what would actually be happening in the cockpit, which was a big change from how Boeing had preceded in the past, when it tested and tested and tested in in the real world, you know, each of these problems. So that's something that in the legislation the Congress introduced is supposed to be addressed: that the human factors need to be considered in any new aircraft. So hopefully that is a lesson that comes out of this and that these problems relating to the interface between the machine and the person don't crop up with the same severity in the future.Thanks for writing the book, Peter, because as I say with these sorts of incidents, it's really good to get the learning out. To be able to have a really strong narrative, and an engrossing book such as yours is a way of keeping some of those messages and information alive and sharing the learning. You know, you can read the technical reports, but I always try and search out the books like yours because it's a way of engaging with the topics without it being too dry or feeling like work. So for what it's worth, my thanks for taking the time and effort to do it. Has it piqued your interest for any other similar sorts of issues in the safety and technological space and is there anything you're researching now that you could talk about?

I mean, I'm still an investigative reporter for Bloomberg. So I'm, you know, always looking into new things but the main thing I'm writing about lately is online sports betting. OK. Well actually I'm quite interested in that myself as a student of probability and risk assessment. But there you go, that's another conversation.That's a different book. Yes. Well, thanks ever so much. It's a pleasure talking to you and I would highly recommend the book to anybody who's listening and wants to get a really engrossing trip through this really important story, to learn the experience from these accidents.Thanks so much.

The next issue

I will do my level best to get another post out before Christmas: fingers crossed that I do. Please subscribe now if you don’t want to miss it:

I’m keen to build the network for Tech Safe Transport. If you know anyone who is interested in the safety of modern transport technology, and who likes a thought provoking read every few weeks, please do share a link with them.

Thanks for reading

All views here are my own. Please feel free to feed back any thoughts or comments and please do feel free to drop me an e-mail on [email protected]: My particular area of professional and research interest is practical risk management and assurance of new technology. I’m always keen to engage on interesting projects in this area.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit techsafetransport.substack.com

This week it’s another podcast: I recently had the pleasure of a half hour chat with Dr James Rogers, who is Associate Professor in War Studies at the University of Southern Denmark and Special Advisor to the UK Parliament’s All-Party Parliamentary Group on Drones. In a wide-ranging conversation we discussed:

* How and why Odense in Denmark has become Europe’s ‘Silicon Valley of Drones.’

* The revolution underway in the use of drones and unmanned aerial vehicles, and what a world inhabited by them will look like.

* The ease with which even amateur drone users can cause significant security issues.

* The pace of innovation in commerical drone technology and the difficulties this arms-race is creating for those developing ‘counter-drone’ technologies.

* The safety challenges for wider use of drones in commerical transport of goods and people, in particular ambitions to use existing transport arteries as the coridoors for drone movement.

* The relative environmental footprint of drones compared with other modes of transport, and the desire for ‘net-zero’ drones, even in the military sector.

James is hugely knowledgeable and a great communicator: I really hope you enjoy the interview and find it informative. More of his views (in particular on the military use of drones) are available online including in his TED Talk, “The Edge of Drone Warfare.”

He also hosts the podcast History Hit: Warfare. Turn about is fair play, so if you’d like to hear an interview James did with me recently on an entirely different, military history topic you’ll find it here.

Feedback

The views expressed in this podcast are James’ and mine. Please do feed back your thoughts in the comments, on linkedin or on Twitter. Posts are biweekly for 2022; the second year of ‘Tech Safe Transport’. To make sure you don’t miss any of them please subscribe below:

I’m very keen to build the network to engage on these important topics, so if you know anyone who is interested in the safety of modern technology please do share a link with them:

Thanks for listening

The photograph used for social media is "Drone" by Sean MacEntee and is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/?ref=openverse.

If you’re interested in any advice, guidance or collaboration on any of the topics raised please feel free to drop me an e-mail on [email protected]: My particular area of professional and research interest is practical risk and assurance of new technology.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit techsafetransport.substack.com

Something different for you all in this edition of ‘Tech Safe Transport’: A podcast.

Dr Jeff Allan has worked on the development of hydrogen vehicles since 2005. In the last three years he was been involved in designing, building and testing hydrogen trains. In this podcast Jeff talks about:

* The fundamental and growing efficiency advantage of batteries over hydrogen fuel cells.

* How in his view the time has now passed for any significant use of hydrogen fuel cells in cars.

* Use of hydrogen for buses and trucks.

* Niche applications in rail.

* Safety topics for railway use.

* Compact hydrogen storage using metal hydrides.

* Use of hydrogen in aviation and shipping.

Ultimately Jeff concludes that as battery technology is advancing so rapidly, hydrogen fuel cells will be a transitory technology, likely to be used in a targeted way for the next 10 to 30 years. As well as being inherently less efficient, use of hydrogen as part of a decarbonisation strategy creates the a need to consume energy to create ‘green hydrogen’. In Jeff’s view this will significantly limit widespread use.

All in all, this is a fascinating take on an important topic from a very experienced engineer: Please take a listen…

In the podcast Jeff mentions the following video, which compares the impact of ignition of a fuel leak in a hydrogen car as compatred to a petrol car:

Feedback

The views expressed in this podcast are Jeff’s and mine. They are only opinions, and aren’t necessarily fixed ones. Please do feed back your thoughts in the comments, on linkedin or on Twitter. Posts are biweekly for 2022; the second year of ‘Tech Safe Transport’. To make sure you don’t miss any of them please subscribe below:

I’m very keen to build the network to engage on these important topics, so if you know anyone who is interested in the safety of modern technology please do share a link with them. If you’re already a regular subscriber, and enjoy the posts, I’d be very grateful if you could try and think of someone new each time you read one:

Thanks for listening

If you’re interested in any advice, guidance or collaboration on any of the topics raised please feel free to drop me an e-mail on [email protected]: My particular area of professional and research interest is practical risk and assurance of new technology. I’m always keen to engage on interesting projects in this area.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit techsafetransport.substack.com