Why a HAL saves your bacon

Recently, I had a great conversation with a guy working in one of the National Labs who had a system that used motion control to go to different points on a device and take measurements. It had been in place for more than 15 years and had been working fine...until it didn't. In the system, one of the motion control boards died. Sadly, the company that made them had discontinued them several years earlier. Based on that, he knew he would need a new model of motion controller but there was a big problem. The software was all written around the old motion controller. To get a new one, they would have to redo all of the software using the drivers from the new controller. 

This was no small task and so they brought in Testeract. Some of my engineering colleagues were able to get it working again but this time they did something slightly different. They used a hardware abstraction layer or HAL. Why did they do this? Because using a HAL meant that if anything else in the system went bad, they would be able to replace the bad device without having to rewrite the software. As systems are getting older and things are changing so rapidly, having a HAL can help you avoid a ton of downtime by making hardware much easier to change. 

For example, if he had originally written his software with a HAL, they would have simply had to make sure the new hardware was part of the HAL and then change a configuration file. The hardest part of this is usually adding the new model (a subset of the device type - motion controller) to the HAL. However, adding a new model to the HAL takes a fraction of the time it would take to rewrite all of the software. 

Moral of the story? Create you automated test systems with a HAL if you want to make them significantly more future-proof.