System safety

 A couple of decades ago, a company was working on a new transport system that was *the future*. It offered fast, silent, and comfortable transport that had the potential to replace both rail and air.

They got millions in funding, and developed a fully-functioning record-breaking prototype.

A publicity document (1) mentioned 'safety' several times. It claimed:

"Collisions between (the) vehicles are also ruled out due to the technical layout of the system and the section-wise switching of the ”guideway motor“. The vehicle and the traveling field of the guideway motor move synchronously, i.e. with the same speed and in the same direction. Additionally, the section of the longstator linear motor in which the vehicle is moving is only switched on as the vehicle passes."

In other words, you can only have one vehicle on a track at once. This sounds brilliant, as you can only have a collision if two vehicles are on the same track, and the system does not allow two vehicles on the same section of track.

The system was the German Transrapid Maglev system. 

In September 2006 (2), a Transrapid Maglev vehicle was in a collision at Lathen (3), killing 23 people. It collided with a maintenance vehicle on the track; a maintenance vehicle that did not depend on power from the track, and therefore 'defeated' the inherent safety systems mentioned in the paragraph above. Add in an earlier-than-usual Maglev test run, and multiple staff errors, and you had a tragedy. 

No-one wanted the crash to occur; it was an accident, and yet it was totally caused by Human error, not an act of nature. The systems were not in place to prevent it.

What can we learn from this? Simply, safety is difficult. Human and technical errors compound safety issues, and therefore you require safety in depth with many fail-safes. These lessons have been learnt the hard way over a couple of centuries on the 'traditional' railway; they should not be forgotten by new systems, as the lessons are often paid for in human blood.

Most of all, safety has to be built-in to the system, not an afterthought. No system can be made safe by liberal applications of handwavium. And I fear this is a major issue with the proposed Hyperloop systems.

(1): TRI_Flug_Hoehe_e_5_021.pdf

(2): Sadly, the document is undated. However, it obviously dayes from before the crash.

(3): https://en.wikipedia.org/wiki/Lathen_train_collision

The Venezuelan Petro.

In February 2018, the government of Venezuela - well known for its financial acumen - announced they were jumping on a digital bandwagon by launching their own cryptocurrency the Petro. The new currency had many stated aims, including to bolster the crashing Venezualan Bolivar currency, and to circumvent US sanctions.

This was an interesting move. The  initial sale allegedly raised $3.3 billion for the Maduro government, although there has been no independent verification of that claim.

I personally feel that government-backed cryptocurrencies are a good way forward for the technology. Although governmental backing reduces some of the advantages of such systems, it also gives a currency increased trust - and trust has been one thing holding cryptocurrencies back.

It is therefore interesting that Venezuela, a country that is in the depths of a massive financial and political crisis, is the first country to make such a move. So what has happened in the last year?

The answer appears to be 'not much'. You cannot go onto a market and buy a Petro or Petro Gold. No-one seems to have an idea about the value of a Petro. To make matters worse, the technology behind the Petro has changed several times of the year, even after launch - and there are even doubts that the currency even exists in any practical form.

I won't go into any jokes about the failure of a socialist state to create a reliable currency - after all, we capitalist countries haven't been brilliant at that, either. But the Petro does seem to be yet another scam cryptocurrency - albeit one created by a government that is in real trouble.

And meanwhile ordinary Venezuelans suffer.

6 April 2019 - it's GPS rollover day!

Today is a special day! You could be the lucky recipient of a rollover!

No, not a lottery win, but something even more unusual: the 1,024-week GPS week-number rollover! Stay tuned to see if you are a winner!

Okay, time to be serious. Twenty years ago the news was full of the upcoming Millennium  Bug, where ancient (and sometimes recent) computer systems that used two digits to represent dates - e.g. '99' for 1999, would roll over and start using '00' for 2000 - which causes all sorts of problems when you perform operations on the data and 2000 is seen as being before 1999.

Fortunately many good engineers  worked for years to ensure that the effects of the Millennium Bug were not as bad as some forecast. Some say that this means the Bug was overwrought nonsense: in fact, problems were avoided because people did lots of work to prevent those problems.

The Millennium bug was an epoch event: dates and times in computer systems have to be represented by numbers, and those numbers are of finite size. The larger the number, and the larger the granularity each number represents, the greater the length of time the number can represent.

Another example is GPS,which has exploded in popularity over the last twenty years. Most cars now have GPS receivers, they are in all smartphones, and many of us even have receivers in our wristwatches. Many vital system require timing and positional information from GPS. Yet GPS receivers also have an epoch - in this case, the data sent from the satellites to the receiver uses 10 bits to represent the week, allowing 1024 distinct values. This means that every 1024 weeks, it resets. If for some reason it gets the 'wrong' week, the receiver may start giving incorrect data to the user.

Today, the 6th of April, the week number rolls over. It is not the first time it has happened (it last happened on August 21st 1999. There were far fewer receivers back then (in fact, is it about the time I got my first Magellan handheld GPS), and the problems were not as significant.

However today it may be different: manufacturers will have been aware of this issue, and will have  put some protections in place. However if your receiver is over a decade old, and has not had its firmware updated, then there might be problems.

The good news is that the GPS constellation is being updated, and the new signals have a 13-bit week, enough for 8,192 weeks - or 157 years. I doubt a rollover of those new signals will affect me much!

But if you have an older receiver, I hope you don't win the GPS rollover lottery!

The Galileo satellite constellation

The Galileo satellite constellation is a keystone European project. It is designed to provide Europe with an independent global navigation satellite system (GNSS), similar to the global American GPS, Russian Glonass and Chinese BeiDou systems (along with regional ones such as India's NAVIC system or Japan's little-known QZSS).

There are two major aspects to such systems: the civilian, which you or I use (generally for free) to tell us where we are, and a secure subsystem (in the case of Galileo, called the 'Public Regulated Service') [4], which is encrypted. In times of war, the civilian system can have its accuracy degraded, be spoofed, or even be switched off, whilst military and other official users maintain their access via the secure PRS. The US GPS system operates a similar encrypted system called 'Precision Code' or 'Military Code', which is only accessible to US military users.

Satellite navigation systems have become a massively important part of our nation's infrastructure. As the government says [1]:

"Recent estimates indicate that over 11 per cent of the UK’s GDP is directly supported by satellite navigation systems and the Blackett review [3] estimated that a failure of service could cost the UK economy £1 billion a day."

With at least three competing global systems, it is unlikely that they will all be degraded simultaneously for the civilian user - and if they are, it will probably be the least of our worries.

But access to such systems are becoming vital for military and governmental users, with all sorts of equipment requiring accurate positioning and timing information, from the big-ticket items such as ships and planes, through missiles and smart bombs to communication systems. Losing access to guaranteed accurate positioning and timing information could well make even the best equipped and trained force a loser.

If you are a world power, you have to have trusted access to the secure parts of a GNSS. Failure to do so could literally leave you adrift in a conflict.

The Galileo project was started by the European Space Agency in 1999, and the European Union took it over, somewhat controversially, in mid-2006 after funding problems. This is part of a trend of the EU taking over and assimilating ESA projects - even after Brexit, the UK will remain a firm member of ESA.

The first Galileo satellites, GIOVE-A and GIOVE-B, were launched in 2005 and 2008 respectively. GIOVE-A was built by Surrey Satellite Technology Ltd in the UK, and it was designed to secure the frequencies required by the Galileo system and to test some of its key technologies. The first two In-Orbit Validation (IOV) satellites were launched in 2011, and the first Full Operational Capability satellites were launched in August 2014.

The Galileo constellation will eventually consist of 30 satellites for full global coverage, with 24 operational at any time, and 6 active spares. Each satellite weights about 700kg, and four can be launched on the same Ariane 5 launch. About 18 satellites are currently operational, with another 4 under commission. This is enough to operate Galileo's civilian side, and many devices can access the signals, including most recent smartphones. The secure side of the system is due to start operation in 2026.

In addition to the satellites, ground stations of various types needed to be constructed, including control centres, data uplink and telemetry stations. Many of these have to be spread globally to allow full control of the satellites, and are costly to run.

Galileo has two additional features: a paid-for commercial system that gives increased accuracy over the standard civilian signals, and the MEOSAR search and rescue system (Galileo's implementation of MEOSAR also include a downlink, so messages can be sent to a beacon). Galileo is also designed to allow emergency access to first responders in the case of a national disaster.

Galileo is a vital piece of infrastructure for Europe. It has not been plain sailing, especially financially, but much of the constellation is now in orbit and operational.

Finally, an aside. One of the reasons the UK government under Blair was so keen on getting the Galileo project started was a proposal that would allow tracking of road vehicles [2]. This would allow governments to implement road pricing by usage - albeit with some rather major privacy implications.

If you want to know more about how GNSS systems such as Galileo work, then chapter 1 of the Blackett review [3] goes into a great deal of relatively-understandable detail.

[1]: https://www.gov.uk/government/news/uk-to-tell-eu-it-will-no-longer-seek-access-to-secure-aspects-of-galileo
[2]: https://www.theregister.co.uk/2007/02/22/blair_road_pricing_privacy/
[3]: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/676675/satellite-derived-time-and-position-blackett-review.pdf
[4]: https://www.gsa.europa.eu/security/prs

Driver aids

I have long been bearish on autonomous cars. This has not been helped by Elon Musk and Tesla consistently over-selling the autonomous capabilities of their cars, and of journalists sometimes  overawed reviews of other companies technology, e.g. Waymo.

The wheels have somewhat come off the autonomous car juggernaut over the last year (and I will try to write about this later). But for this post, I thought I would look at the other end of the problem: simple driver assistance aids.

Sencan recently got a new job with a longer commute, and we decided to get a new car. And for the first time in our lives, it would be a brand-new car.

After rejecting the new-style Honda Jazz, and covetously eyeing a Ford Fiesta, she decided upon a Hyundai I20. The model we chose has several driver aids: Lane Keeping Assist System, Lane Departure Warning System, Forward Collision Avoidance, and Driver Attention Alert.

Sencan has been driving it to and from work for the last few months, and I only recently got to drive it for a journey further than the local shops.

I have never driven a car with these aids before, so I thought I'd have a quick trial of them (excluding Forward Collision Avoidance, which would be rather difficult to test safely) to see what I thought.

Lane Keeping Assist System

This is where the car detects a lane ahead, and if you drift out of the lane, it pulls the car back in. Whilst active, a light illuminates on the dashboard and the feeling feels heavier: similar to an old, heavy vehicle without power steering. The car definitely lets you know it is in control.

Somewhat surprisingly, it also steered around bends (this is probably not recommended usage of it) if I just rested my hands on the wheel.

When enabled, lane keeping assist appears to work well. The steering is heavy enough to allow you to know that it is enabled without seeing the dashboard light, and it seems to follow the lane well - although on some bends it steers like a fifty-pence piece - perhaps because its cameras can only 'see' a short distance ahead.

However, it does not seem to trigger on country roads or in towns, and even on an A road, it occasionally flickers on and off.

Lane Departure Warning System

In this, a light flashes and a buzzer sounds if you go outside a lane - at least on the driver's side;  I had no safe opportunity to test it on the nearside.

Driver Attention Alert

I tried resting my hands loosely on the wheel to see how well it would keep to the lane (as safely as possible; I never actually let go), and a warning would flash up to tell me to keep my hands on the wheel. This also seemed fairly reliable and unremarkable.

General notes

In the case of lane assist, it seems to require white lines on both sides delineating the lane, and will only activate if both are there. If so, this makes sense, as such line detection is far easier than trying to detect the actual edge of the road if the lines are not present. However the flickering on and off of lane assist can be annoying; I presume it is trying to fail safe (i.e. off).

The lane warning is much more robust; if I go over a white line it beeps and a light flashes on the dashboard. This seems much more aggressive in its detection than the lane assist; perhaps because it is only a warning, a few false positives (i.e. warnings given when one is not required) does not matter.

Conclusions

All in all, it was a positive experience. It is an interesting first step towards automation, albeit a baby step. There is also a massive gulf between it and true autonomy, especially in the places lane assist would not enable itself, despite the lanes being obvious. In my opinion they can also be a valuable driving aid - if used correctly.

For me, the most impressive thing is that this capability is present in a reasonably-priced car, and appears to work well and unobtrusively. But there is a vast gulf between such assistant technologies and the ones required for automated driving, which will have to work 100% of the time.

Modern communications and disasters

The tragic sinking of The Sewol yesterday off the coast of South Korea has led to many sad stories, not the least of which are the text messages sent by people - many young - trapped in the ship as it tilted and sank.

Rumours continue that messages are being sent by people still alive within the ship. It is possible for people to be alive as it does not appear to be too deep; pictures show the tip of the bow protruding from the water. One report says that rescuers are pumping air into some parts of the hull to replenish any air pockets.

However, I doubt that many calls or text messages are being sent from within the ship at this time. Water attenuates RF signals rapidly, especially when at an angle to the receiver. It can be as much as a matter of a few inches or feet before the signal is fully attenuated, depending on the conditions. Although the effect is less than salt water, it increases as the signal's frequency increases.

So what might have happened? 

1) The people receiving the text messages may not have noticed them when they were sent, and picked up the phone later when they heard the news to see the message.

2) Text messages are not designed for reliability of data (*). They only display the time they were received at the network centre (called the short message centre). This includes a timezone which many phones do not compensate for, which may give the impression they were sent after the ship sank. In addition, many phones display the time the message was received by the phone, rather than the time in the message from the network centre. If the recipient's phone is switched off, the time displayed for the message would be the time the phone was switched on, not the time it was sent.

3) Finally, hope might make them think it was received after the ship sank even if evidence suggests otherwise.

4) Somehow, the people trapped inside the ship managed to send a signal through the water and to a distant mobile phone base station on the shore.

The first three of these effects will sadly give false hope to many families. But let's hope I'm wrong.

(*)From RFC5724:

In particular, SMS messages between different network operators sometimes take a long time to be delivered (hours or even days) or are not delivered at all, so applications SHOULD NOT make any assumptions about the reliability and performance of SMS message transmission.

Hyperloop

I have long been a fan of Elon Musk, the Internet entrepreneur who has made the difficult jump into hardware with his successful SpaceX company, which sends cargo (and soon passengers) to the International Space Station.

He also co-founded Tesla, the company that proved that electric cars can be sporty.

But SpaceX is just an iteration on existing technology: that is not to denigrate what they have done, but at the end of the day it is just a long tube of fuel sitting on top of rocket motors, just as all rockets have been since Sputnik 1 first orbited the earth. And Tesla also uses proven technology, albeit in a novel way.

It is therefore with interest that I note that Mr Musk and his team have come up with the Hyperloop, a solution for mass transit between Los Angeles and San Francisco.

The Hyperloop is a tube running between the two cities. A partial vacuum is maintained in the tube whilst a linear induction motor fires off a pod containing passengers (and in some designs cars) through it. The partial air pressure is sucked in at the front of the pod, compressed, and used to levitate the pod on a cushion of air (so-called 'air bearings'). Occasional linear induction motors continue to accelerate the pod to account for the small amount of friction and aerodynamic drag; for most of the time the pod coasts. One pod can be fired off every 30 seconds, and they travel at high subsonic speeds (to a maximum of 760 MPH).

The tube is supported on pylons above ground, and is covered with solar panels which will provide the power for the system. The pods contain batteries that run the compressors that provide the lift air.

The whole scheme is described in the following link:
http://www.spacex.com/sites/spacex/files/hyperloop_alpha-20130812.pdf

I have read the paper, and the following issues come to mind. None of these are necessarily game changers, but will need addressing:

• Crashworthiness: The energies involved at high-subsonic travel are immense. What happens if a component breaks off and is left in the tube to be hit by the next vehicle? Or if the vehicle makes contacts with the sides somehow, imparting great energies to the tube and pod? Even a 5 gram nut has significant energy when hit at over 700 MPH.
• Evacuation: If there is a problem and people need to evacuate, how does that happen? Remember, the tube is sealed and in a partial vacuum. And as the tube is intended to be supported on pylons above ground, how do passengers get from the tube to the ground?
• Life support: the air pressure within the tube (i.e. outside the pod) will be harmful to human life. The pods will have to maintain a pressure that we can survive in, and all hatches and seals will have to be foolproof. They have addressed this in the document, but I'm not sure they have the whole answer, especially with hatches and seals that will have to be repeatedly used over a period of days, months or years. Will the air inside the pod be at normal sea-level atmospheric pressure, or reduced as in aircraft?
• Claustrophobia: the passenger-only vehicle appears rather cramped. Claustrophobia may be a significant problem for many passengers - airplanes are bad enough for some people. This effect may be worsened by G-forces, which will be considerably more than is the case for high-speed rail.
• Breakdowns: With one pod every 30 seconds, what happens if one breaks down mid-tube and away from one of the accelerator areas? The paper says there will be deployable wheels that can be driven along using electric motors; this is not only extra complexity, but the power required may be significant if a long way away from an accelerator area. In addition, there is no mention of gradients. If the tube has a significant gradient, the amount of energy required to take a pod up slope will be large. And what happens if the emergency wheel system fails?
• Construction: in the paper, I fear the team underestimate the costs and complexities of construction. They have designed the route on Google Earth to follow existing transport corridors where possible (for example Interstates). This takes no account of ground conditions: if the line passes through an area of soft or difficult ground, the costs of constructing the pylons will grow significantly. As the route will be passing through an area that can exhibit significant seismic activity, the pylon foundations will have to be designed to cope with liquefaction and other effects.
• Braking and signalling: If a car does stop, how do the others get messages to stop? What sort of signalling system will be used, and how fail-safe will it be? The proposed system of braking is simply referred to as 'emergency mechanical braking system' What is this, and how does it work?
• Pointwork: One of the deal breakers with Maglev systems is pointwork. With one pod leaving every 30 seconds, there will be many pods at the stations unloading and loading. The paper suggest that there may be branch lines to other cities in the area. How are the pods transferred to different tubes or tracks at the stations (or indeed into depots or maintenance areas)? If this is done in tubes, you will need moving tubes and/or walls, preferably whilst keeping a low pressure vacuum. Not an easy task.
• Charging: the on-board batteries will need charging every few journeys. How is this done during intensive usage of the pods?
• Fire: all mechanical and electrical systems suffer from the risk of fire, and those risks need managing. Being in a sealed pod with a fire, and a vacuum outside, is not necessarily healthy. In addition, there are the risks of smoke for other pods further down the line. Fire and smoke management are very costly in similar tube-like systems such as the Channel Tunnel, which has a service tunnel and refuges at regular intervals.

I could be wrong about all of this, and could end up sounding like Doctor Dionysius Lardner who in the 1830s said the following:

Rail travel at high speed is not possible because passengers, unable to breathe, would die of asphyxia.

On a positive note: engineering-wise, it is perfectly feasible to construct a partially-evacuated tube that is supported by pylons. The propulsion system also appears feasible at first glance, as is the air-cushion support mechanism. Engineering difficulties will happen, but if you throw enough money at it, it should work.

However, getting such a system to work reliably and safely is a whole different matter, and I am unsure that anywhere near enough thought has been put into this.

Another view on the Hyperloop's feasibility is at the Ambivalent Engineer blog. The costings are explored at the New York Times. The New Statesman is sceptical.

And the Daily Mash has its own take on the Hyperloop....

Google Pathview?

I just noticed this post on the Ambivalent Engineer blog. It shows a man-portable Google Streetview rig, for use on trails.

More information is available at the TechCrunch website, and there is the obligatory YouTube video.

I wonder where I apply to walk the National Trails with one? ;-)

The risks of technology

A couple of weeks ago the US announced that they had lost contact with one of their exceptionally high-tech and modern RQ-170 Sentinel drones. Later the Iranians said that an electronic warfare unit had captured the drone.

The Iranians later showed detailed video of what appears to be an RQ-170. It seemed remarkably intact - although the underside and undercarriage could not be seen, the top seemed nowhere near as damaged as would be expected from a shoot-down or even a crash landing. However the video and pictures are far clearer than would be expected if they were trying to fake the images.

Naturally, some people have been in denial about this. One theory has it that the Iranians had a mock-up ready made, and when the US lost contact with their drone the Iranians used the mock-up to pretend they had captured it. Whilst it is likely that nations may construct mock-ups of aggressor craft - for identification training if nothing else - it would be an embarrassing strategy if the real wreckage was discovered.

Another is that a rogue Iranian agent in the US military had deliberately crashed the plane within Iran. This seems rather unrealistic.

Today it is alleged that the Iranians forced the craft to land. The control protocols for the aircraft are certainly encrypted (although embarrassingly some of the data such as the video may not be) and I doubted that they had actually taken control of it. However today's claim does make sense, at least to an armchair (in)expert such as myself.

The drones are controlled from stations that can be anywhere in the world; for instance Britain's Predator and Reaper drones are flown from Creech Air Force Base in Nevada (*). Control signals are encrypted and sent over to the drones, presumably by satellite. If the radio signal is lost then the drones are programmed to fly automatically to a friendly base for landing, using GPS for positional information (**).

The Iranians are claiming that they jammed the 'proper' control signals coming from the US. This is important; they are not claiming to have hacked and decrypted the control signals, just to have blocked them. Without the signals, the drones would have automatically flown back to a base. This is where the Iranians got clever. It is possible to block and alter ('spoof') GPS signals; this is believed to be what is going on when GPS and SatNav users are warned that their devices will not work. The Iranians are claimed to have spoofed the drone's GPS signals so that it thought it was flying back to a friendly base.

Damage possibly occurred to the drone's underside on landing as the strip in Iran had a slightly different altitude to the base the drone believed it was landing at.

This claim is more plausible than the other alternatives. No real 'hacking' in the traditional senses was needed; instead gaping holes in the security logic were exploited. As much as I dislike the Iranian regime, the engineers must be congratulated for a very clever coup. My only question is why they have shown their hand so early; it gives the west time to understand the problems and close the exploits.

Unfortunately this will have serious implications. The obvious one - that the Americans have lost some of their top-secret military technology - might not be the most important. It it alleged that, although new, the RQ-170 does not use cutting-edge technology as they expected to lose one over enemy territory eventually, either through accident or combat. Far worse is the fact that American (and indeed western) commanders will have large doubts about the chances of their drones reaching a target in battle. And that may mean more manned aircraft are needed, and more friendly lives put at risk.

I am less bothered about the Iranian's claims that they will be able to reverse-engineer the aircraft. Although they have very capable engineers - they have allegedly been keeping some F14's in the air despite US sanctions and lack of spares - it would be a major task and money better spent on more useful platforms. It would be much more likely they would learn important lessons about how the drones work and how they can be combated. The Russians or Chinese would be in a much better position to take advantage of the aircraft.

(*) There is a valid debate to be had about how much we really control these drones. We have purchased them; would the US allow us to use them in a campaign that was against US interests? I am amazed that we have not paid to have the control stations here in the UK for a truly independent system.

(**) I would be surprised if they only used GPS for positional information, but it is possible. If so it was a major lack of foresight.

Tape out

My wife has been at Company X for about nine months now, and is undergoing a process that is known as 'tape out'. It is a time of extreme stress.

After a computer chip has been designed, the plans are sent off to a fabrication plant for samples to be made. These are then received back and tested before going to production. Unfortunately fabrication is a time-consuming process and production slots have to be booked many months' in advance. This all adds up to a wait of many months to see if your chip works; if it does not then you have to find the fault, fix it and go through the whole hellish process once again.

This means that it is important for the plans that are sent to the fabrication plant is as near perfect as possible. I am lucky; in software we can almost always do a change and see the effects of that change within a few minutes. In my wife's job it can take months and cost a small fortune.

I once was involved with a team of people working on a digital chip. The first ten samples came back from the fabrication plant on a Monday morning; no time was wasted in placing some into test boards. The news quickly spread: they were Dead On Arrival and would not even power up. I watched during the week as the engineers got increasingly frantic until, on the Thursday afternoon, they discovered the problem. The fault was not with the design but with the manufacture (*). I have rarely seen engineers more highly stressed.

So what is 'tape out'? Imagine a chip as being a bunch of lines representing the circuits. The final plans of a chip form a spaghetti-like mess of interconnecting lines called a 'mask'. In the early days of silicon chips the scale was so large that the mask could be altered by simply adding black sticky tape - you literally got the tape out. Although modern techniques have long outgrown this method the term is still used to represent the point at which the chip is finally designed.

Tape-out is an incredible stressful period for everyone involved. Any mistakes that are left after that stage may not be found for many months, delay the project by many more and cost hundreds of thousands, if not millions, of pounds. Incredibly intelligent people have left the industry because they cannot cope with the stress of tape-out and the wait for the chips to return. To compensate, tape-out is also a time of slap-up dinners for the development team and any hangers-on who might come along :-)


The construction of a chip is an immensely complex process; terms such as photolithography, finite barrier quantum wells and valence bands all add up to form a nearly-impenetrable barrier to comprehension. This is true for the design of digital chips; it is triply so for designers of analogue chips such as my wife. Digital chips are digital; they belong in the domain of ones and zeroes. Analogue chips are variable and utterly indeterminate; they are designed by magicians and witches.

So this note is a rather long-winded way to say to my wife how much I am so proud of her, how much I am amazed by what she does for a job. Not only is she a witch, but she is a damned good witch.

And not many husbands could get away with saying that...

(*) The silicon part of a chip sits in a piece of material (often plastic) called packaging that connects it to the outside world. The chips had been packaged 90 degrees out of orientation, meaning that the pins did not line up. It was someone else's problem and, even better, it was easy to fix...

Dennis Ritchie, RIP

With the media obsessing over the sad news of Steve Jobs's death, the passing of a man who had much more of an effect on the computer industry has gone virtually unnoticed.

You will certainly not have heard of Dennis Ritchie. His was not a household name, and he was not eulogised in the same way as Jobs. Yet he undoubtedly altered the world. I first heard of him when learning the programming language, 'C'. The bible on the earliest incarnations of the language was known colloquially as 'K&R'. As you may have guessed, the 'R' refers to Ritchie, who co-authored the book with fellow engineer Brian Kernighan.

Ritchie created the C programming language whilst working at Bell Labs in the early 1970s and, later, co-wrote the Unix operating system with Ken Thompson. C and its successor C++ are two of the most popular programming languages in use today, and Unix is used in a massive number of devices (even Apple's computers are based upon it).

Both inventions are far from flawless. They were created in the 1970s, when the computing world was very different. The C programming language is particularly flawed, and its extreme flexibility makes it difficult to write secure software. Yet that same flexibility led to its success, whilst many other technically superior languages have come and gone.

Someone once told me: "Anyone can program in Java, but C is for real men". If that is true, then Ritchie was a God.

The Register had a good obituary of the great man.

RIP Dennis Ritchie, and thank you.

Wikileaks

I have written about the WikiLeaks farrago before, but recent developments have made the story much more serious, and have cast serious questions on the behaviour of the protagonists.

Last year WikiLeaks got hold of 250,000 US Diplomatic cables that had been sent between US Embassies and the State Department. Several newspapers (the Guardian in Britain and the NYT in the US amongst others) did a deal with Assange and WikiLeaks to publish the data. They also said that they would redact any data that would prove dangerous to individuals before publication. Since then we have had a trickle of information coming out from these newspapers.

Much of this information has been fairly uninteresting. However a great deal of it involves third world or dictatorial regimes, and the redaction was necessary to protect people mentioned in the cables.

However, because of a series of stupid actions, the full unredacted cables are out in the public domain. Now anybody can read the full detail of the cables. And that can only be a really bad thing.

(A note: below I am using the term 'password' when it should really be 'encryption key' or 'passphrase'. I have done this to make it more readable to the layman).

As far as I can tell from various good sources, the following occurred:

1. Assange and the newspapers came to a deal to publish the cables.
2. The papers wanted to publish the data in redacted form; Assange reportedly did not like this.
3. Assange encrypted the data and placed it onto an obscure ('hidden') area of a server. As it happens, this was not very hidden.
4. He met with the Guardian journalists. He handed them most of the password on a piece of paper and told them the rest of it verbally.
5. The Guardian journalists decrypted the data, redacted pieces and started publishing.
6. The original file was not removed from the WikiLeaks server.
7. Meanwhile, a split occurred in the WikiLeaks organisation. Someone took a copy of all the WikiLeaks data - including the 'hidden' file - and published it on servers belonging to their new rival organisation. People downloaded all the data, including the hidden file.
8. Two Guardian journalists published a book that included the 'real' password of the file. They claim that they had been assured that WikiLeaks would remove the file once they had downloaded it. 
9. The Guardian and Assange had a falling-out after they investigated the claims of rape against him.
10. It takes a few months, but someone eventually realised that the password given in the book is the *real* password and managed to find and decrypt the file.

The password was, apparently, based on the following: 'ACollectionOfHistorySince_1966_ToThe_PresentDay#'. Assange also verbally instructed the journalists to add the word 'Diplomatic' before the word 'History', the idea being (wrongly) that the information on the piece of paper would be worthless without the verbally-given modifier word.

It was an atrocious password to be used in something of such importance (although not as bad as Rebekah Wade's hilariously poor password for her News International email account). True, Assange's password is long, but length does not equate to security. It is a spectacularly poor choice given Assange's paranoia about security - I would hope that his 'insurance' file has a better-conceived and executed password.


Ordinarily I would not have published the password in this posting myself, but given that it is available in a printed book and is on many other websites, I see little harm.

Even if the Guardian journalists had changed the password, the other information given in the book would give someone attempting to crack Assange's passwords an idea about how he generated them. For instance, it is clear that he thinks security is added by writing down a partial password then having a word that can be added to complete it - indeed, a word that makes sense in the context of the whole password. Such knowledge can help people work out what any particular password might be, and it was exceptionally stupid - nay, gormless - to put any such information in the public domain.

There is so much fail in this:

• WikiLeaks should not have relied on 'hiding' the data on a server.
• WikiLeaks should have kept the data much more secure. Once the Guardian had a copy of the data, it should have been removed from the hidden location.
• WikiLeaks should have used a more secure password (there are plenty of programs to pseudo-randomly generate passwords.
• The Guardian journalists should never, ever have published the real password in any public form.
• The Guardian journalists should have checked that the data had been removed.
• The Guardian and/or WikiLeaks should have realised that the password was publicly available and made attempts to mitigate the problem.

Strangely, the Guardian's take on this is that it is all WikiLeaks' and Assange's fault. I would agree with this, except for the mind-numbingly stupid behaviour of their journalists in publishing the actual password. Why was this necessary? Why not just say that Assange gave them a printed password and told them verbally how to alter it? Is the actual password of much interest to the reader? (of course, in the end it was as the file was still extant).

Assange seems to think of himself as a professional, but he has shown himself (and WikiLeaks) to be rank amateurs who evidently know little about security or the underlying technology. The Guardian journalists are meant to be professional, but have shown themselves to be dangerous amateurs.

WikiLeaks have now released the full unredacted form of the cables, which, it is suggested, Assange wanted to do in the first place. They can do this without being *blamed* for the data being made public, as they are blaming the Guardian for that. And the Guardian can blame WikiLeaks. Rather convenient, really...

People may well suffer or die because of this. There should be a special circle of hell reserved for people capable of such negligence.

Security

It is often said in computer circles that users are the most frequent cause of system insecurity. The recent phone hacking scandal is a classic example: users not changing their default PINs.

Likewise, what has recently become famous as 'blagging' has long been known known in computer circles as 'social engineering'; in a famous case the uber-hacker Kevn Mitnick phoned up a military base pretending to be the harassed aide of a senior officer who had forgotten his password; a fellow hacker had discovered the aide's name on a piece of paper found in a dumpster. The result: Mitnick got told the password and could access the military network.

Security measures are a hassle for users, and therefore users hate security measures.

It is therefore with interest that I see that the Government's laudable aims to improve security on mobile devices has been waylaid by Sellotape.

Spam

Hotmail has a fairly good spam filter, which captures the majority of spam whilst only getting a few false positives (i.e. characterising 'good' emails as spam).

I like to carefully go through my spam inbox to check for non-spam messages. Today, amongst the usual viagra and other spam saying that I need to 'enhance' my manhood, there is a message called 'Tax Refund Notification'. It appears to be from an HM Revenue and Customs email address, and the image looks official. It is the fourth time I have received this message, always claiming that I am due a refund of £468.50.

Of course it is spam. There are some obvious signs: a poorly-designed link to click on that goes to a website 'balearicproperty' instead of HM Revenue along with a couple of spelling mistakes, including lack of punctuation and full stops. The character set is also Cyrillic, which would be unusual for a British Government address.

The reason I mention this is that it is one of the more believable spam emails I have seen. The image and accurate 'from' addresses are things that would initially take people in, along with the greed of receiving a refund. Worryingly, if they were to take away the spelling and other mistakes, make the target link address more believable and add a great deal of official-looking small print, they would catch far more people.

I am not stupid enough to say that I will never be taken in by spam and other scams - all it needs is for someone to push the right buttons for greed and flattery to overcome my innate paranoia. But by examining spam message in this manner I learn to be more cautious.

A diesel-steam locomotive

I once had a fondness for railways. It was not so much the trains but the actual engineering; the bridges, tracks, and tunnels etc. However, osmosis did mean that I picked up some basic knowledge about the locomotives.

Over the years the various railway companies tried various experimental schemes for locomotives. Some of these are famous, such as Bullied's Leader class. However, there are undoubtedly many weird and wonderful experiments that I have never come across.

Whilst browsing the web somnolently, I came across a webpage on the LNER Encyclopedia. The page details the Kitson-Still locomotive built in the 1930s. It fascinates me as it shows the tentative way that many established organisations approach new technology.

At the time diesel engines and transmissions were relatively new and unreliable, especially in the sizes needed by a steam locomotive. The technology was a step too far for our mostly conservative railway companies. The Kitson-Still was designed to overcome some of these problems.

Diesel engines work by compressing diesel until it spontaneously ignites. Instead of having a seperate diesel engine, the Kitson-Still injected diesel into the opposite side of the cylinders from the steam, allowing the pressure of the steam to compress it to ignition. Hence this literal form of diesel injection would give the steam engine more power.

It was also more efficient - exhaust gasses from the diesel were taken through the boiler, preheating the water. In this manner, the locomotive got up to 40% efficiency - unheralded at the time.

Of course it was a technological dead-end. Diesel technology improved rapidly over the years, and the idea never got around many of the disadvantages of steam - whilst diesel and electric locomotives can be started at the flock of a switch, it takes many hours for a steam locomotive to get to working temperatures. But I must admit to a certain fondness towards this idea.

Unforeseen consequences

Designing electronics is very difficult. So difficult, in fact, that I am very glad that I chose to become a programmer rather than an electronics engineer.

The problem is always in the polishing. There is an old adage that completing the first 90% of a program takes 10% of the time, whilst completing the last 10% takes the remaining 90% of the time. To put it another way, it is far easier to get something basically working than it is to ensure that it always works well under all necessary conditions.

This is one of the reasons why there are so many buggy programs - the programmer write some code that appears to work and passes basic tests. He knows that there are some areas that may need work, but the management thinks it is good enough and wants him to work on the next task. That last 10% of the job, the polishing, often never occurs.

And it is far worse in electronics, and especially consumer electronics. And sometimes the truly weird and unexpected can come and bite you on the bottom. Take this story on the Connectify blog. Basically, some people with the new Kindle 3 E-Book readers noticed their units were rebooting at random intervals. The Kindle's come with a choice of leather covers, one of which has a light, and the other which is unlit.

Strangely, the failures were only occurring in the Kindles with unlit covers. Connectify did some research, and it turns out that on the powered cover, two gold-plated contacts touch the Kindle to power the light. In the unpowered version, these contacts are metal painted with a non-conductive paint. This paint was wearing off with repeated opening and closing of the cover, allowing a connection to be made. This was drawing power from the Kindle and causing various pseudo-random problems, including crashes and reboots.

Thus the design of a cover for a device has led to a problem with the device itself; circumstances which would have been difficult to foresee. This is one reason why automotive and military electronics are always more expensive: they go to much more bother about the construction and testing of their devices than consumer electronics companies.

Byte magazine

So Byte Magazine is coming back. Byte, for those who do not know, was probably the pre-eminent technical computer magazine. Between 1975 and 1998 it gave in-depth technical articles that were accessible to the layman. Unlike all other magazines, it actually gave you the technical detail about the latest computer technology.

We have a large pile of IEEE publications in our living room. They are fascinating reading, but the titles detail the problem: "Graphene transitors for the masses", 'Applications of Voltage and Current Unity Gain Cells in Nodal Admittance Matrix Expansion", and who could forget the amazing "Putting memory into Circuit Elements: Memrositors, Memcapacitors and Meminductors"?

The problem is obvious: you need a massive amount of background knowledge to even start reading the articles.

Byte magazine acted as a primer between general computing knowledge and the technical nitty-gritty. It gave you a springboard that allowed you to access more detailed information; it did not dumb-down the topics and treated the reader as an adult.

My uni's library was stocked with every issue of Byte (going back, I think, as far as the first issue). Major new developments in computing were covered in this accessible format; for this reason if I wanted to know about something, for instance pipelining in processors, I would search out the issue of Byte that introduced that particular topic. It was always better than the other books in the library.

Yet it failed, and with it went a way to teach computing to the masses. I have yet to find a website that comes near the accessibility of the Byte articles; take the article on instruction pipelines on Wikipedia as an example. It would be almost impenetrable for someone who did not already have a great deal of knowledge.

Unfortunately I doubt that the new Byte will be anything like the old beast. I can but hope.

Phone hacking

I could write a great deal about phone hacking, but will not for fear of my blood pressure.

Let me just say that concentrating on News International is wrong, as the Guardian well knows.

But I will express astonishment at the news that Gordon Brown believes that his mobile phone was hacked whilst he was in Government.

Firstly, there should be a clarification. The reports state that the reporters were doing - and paying someone to do - was simply log into people's voicemail using the default codes. When a voicemail account gets set up, it is given a default access code. It is up to the individual user to change the access code when they receive the phone.

If you use your voicemail - or believe that anyone will leave anything interesting on it - then you should change the code. Some users even disable the code, meaning that anyone who has your phone number can access the voicemail.

We had a Chancellor and PM who could not even perform this simplest of security measures. Who also was magically unaware that people in his closest circle - including some in his office - were smearing members of the opposition.

The man really is incompetent.

The future of computing?

The big tech news today is that Microsoft have announced that the next version of their operating system, Windows 8, will run on ARM as well as Intel chips. This is the first time for years that any of the main versions of Windows will be made available for non-Intel chips.

This is a big thing. Over the last couple of years both Apple and Google have been working to reduce the gap between mobile phones on one hand and fully-fledged desktop computers on the other. Smartphones, netbooks, tablets and laptops are all part of this process. Apple and especially Google hope that this convergence will give them a toehold into Microsoft's market; Microsoft are concerned that the market for traditional computers is going to reduce.

Microsoft's problem is that the majority of these new devices are battery powered, and Intel chips traditionally have very poor power consumption. Instead, manufacturers are using chips designed by Cambridge company ARM.

ARM is very different beast from Intel, and was a pioneer fabless semiconductor company. Whilst Intel design and manufacture their own chips, ARM design chips and associated components, and license these designs to other manufacturers. Therefore relatively small companies can take ARM designs and modify them for their own purposes, for instance by adding USB controllers or network interfaces. This means that one chip can provide almost an entire system, called a System-on-Chip (SoC), reducing cost and power consumption in comparison to an Intel design.

It is therefore newsworthy that in a demo at the industry show CES, Microsoft CEO Steve Ballmer showed an ARM SoC-powered computer running an early version of Windows 8 and Microsoft Word.

It is quite impressive that Windows - traditionally seen as being so tied to Intel that the term 'Wintel' was coined for the combination - had been made to work on a radically different platform so quickly. He also demonstrated printing a document, something that Apple does not support on many of its products. It indicates that the longstanding rumours that Microsoft have been building - if not selling - Windows on other systems are correct (doing this can make testing much easier).

There are dangers for Microsoft. As I have said before, Apple have a much easier job with their software due to the fact that they control the hardware. In contrast, Microsoft will be increasing the amount and types of hardware that they support. I foresee that Microsoft will be working exceptionally closely with the chip manufacturers to help get Windows working with their SoCs.

Then there is the problem that Windows has traditionally been a very 'heavy' operating system; it is fully-featured, but that means it consumes a great deal of resources such as RAM and processor power. Microsoft will have to look at ways of reducing this footprint by enabling parts to be cut out. For instance a tablet computer may have no need for code relating to a keyboard and mouse. Microsoft have been working towards this and other footprint problems for some time; witness the way that Windows 7 boots and shuts down much faster than XP.

The vast majority of third-party software will need altering to work on an ARM-based system, and it is questionable whether companies such as Adobe, Sage and others will want to support other platforms. Yet such a move may open many more markets for their products. It will be a difficult decision for some of them to make. Again, Microsoft has a brilliant development platform that may make altering the software relatively painless.

Another problem is the interface. Windows is based around a keyboard and mouse combination; Apple have done a superb job in inventing other interfaces. The handwriting-based Newton did not sell well in the 1990s, but the touch-based interface used by the iPhone and iPad is superb. Microsoft will have an interesting job creating an interface system that will work on multiple paradigms.

They have targeted such markets before; for instance nearly ten years ago I worked on a set-top box that ran on Microsoft's Windows CE operating system (abbreviated by all the engineers to the apt name WinCE). WinCE and their other cut-down operating systems have never really taken off as they are very different beasts from Microsoft's desktop operating systems.

Despite these problems, I think Microsoft may well succeed. Windows, although hated by many enthusiasts, is an extremely good software platform, and Microsoft Office is unrivalled. Business in particular might like small platform devices running exactly the same industry-standard software as their desktops. That is something that Apple, Google or Linux cannot currently offer.

We are living in interesting times.

Apple has problems again.

As someone who has worked extensively in high technology, I am well aware of how easy it is for bugs to creep into both the operating system and applications. That is why it is so important for testing to be at the heart of any software company.

So it is hardly a surprise that a bug has struck some Apple users when alarms on their iPhones failed to trigger. This is the latest in a series of bugs that have afflicted their alarm system.

Alarms are notoriously difficult to get right - what appears simple (just fire off an alarm at the appropriate moment) becomes infuriatingly complex when repeats, sleep, snooze, time zones, leap years, daylight saving, differing calenders, standby, user configuration, leap seconds (and more) are taken into account. However, it is far from rocket science.

Leap years alone seem almost impossible for some people to get right. From memory the rules are as follows:

• If a year is divisible by 4 (e.g. 2004) then it is a leap year.
• Unless it is divisible by 100 (e.g. 1900), in which case it is not.
• Unless it is divisible by 400 (e.g. 2000), in which case it is.

Believe me, I've had to code this logic a fair few times! Yet even Sony got this wrong in their Playstation 3, where 2010 was marked as being a leap year. Microsoft and others have also had problems with this simple formula.

Even something as simple as alarms matter; people rely on alarms for a whole multitude of reasons. An alarm failing to go off can cause real problems. If something is coded, even if it is an extra, then it should be fit for purpose. I am amazed that a company the size of Apple has got this so wrong.