One of the problems with risk assessments is how far do you keep digging? A number of recent news stories of the improbable caused me to think about some of these.
Let me start with the most bizarre and improbable; so bizarre that at first I thought it had to be an April Fool: "Spider invasion prompts Mazda software fix" - the article is www.bbc.co.uk/news/technology-26921734
As someone who used to write embedded software for cars many years ago - engine controllers, anti-lock brakes, dashboards etc, I maintain an interest in the field. This is a problem with a spider that likes to build its web in the vent in the fuel tank vent line; by definition, the vent line has to be open to the atmosphere. Re-reading the article, I realised I have actually suffered a similar problem - on my boat, the outboard motor draws cooling water through an impeller and then expels it through a small hole higher up as a "tell tale" i.e. after starting the outboard, you check to see that water is flowing. After a couple of months when I had not used the outboard, the next time I used it, I had the overheat alarm going, and sure enough, there was no tell tale flow of water. Close inspection showed that it was blocked by the web/nest of an insect - I didn't examine it closely to determine if it was a spider.
Are there any lessons we can learn from this?
Well there is an obvious one - any hole can get blocked; the cause - spider, mud, corrosion etc - is immaterial. When designing a system, and engineer should look at the physical system for what can happen - "vent/hole blocked" and what the consequences might be. On an outboard motor, because it is operated in a hostile environment, blockages of small pipes and vents is a common possibility; the most common consequence is a lack of cooling, so an overheat sensor is fitted.
It does highlight another risk - with increasing complexity and specialisation, many engineers may be focused on a small part of the system and don't have an overview of all of it - the mechanics, electronics and software. In the days when it was much simpler (and there was only 2kbytes for the entire engine controller program), I used to consider the failure modes of the sensors, write code to detect them and where possible have a default operation as well as a warning. For example, if the engine temperature sensor failed, then putting on a red warning light is obvious; less obvious is to turn on the electric cooling fan to full, as overcooling the engine is a safer default than potentially letting it overheat.
Another improbable risk is the risk of being hit by a meteorite. See www.bbc.co.uk/news/world-europe-26891782. By coincidence, this article on an event that happened a couple of years ago came out at the same time I saw a good meteorite/shooting star whilst out driving. There has been a lot of debate about whether or not this video is genuine or faked. There is a good article skydiver_almost_hit_by_meteoroid in which the author concludes that if the video was staged, rather than faked by editing, the risks would have been quite high and incredibly irresponsible. Thus, the author basically uses the risk arguments to decide on the balance of probability, the video is genuine.
Quite separately I was travelling with an engineer friend, who offered me his take on the missing flight MH370. He had calculated the probability of a plane being hit by a meteorite. This is very small, but when multiplied by the number of flights and a period of 20 years, it becomes a significant number. His argument is that if a plane had been hit by a meteorite during the last 20 years, we would have heard about it. Since we haven't, then it is a reasonable probability. After all, in 60 years, I have seen at least two meteorites and one UFO (there were 10,000 other reports of what I saw, so whatever it was, I didn't imagine it).
So this leads to another improbable risk - being in a plane hit by a meteorite, and what mitigating actions can you take, other than not flying?
What bizarre risks have you come across?
