Cisco Blogs

Wanted – New Patching Capabilities

March 27, 2012 - 0 Comments

The proliferation of devices that include computers in some form or another is on the rise. With the advent of the much heralded Internet-of-Things (IoT), the number of computerized devices will only become higher. And all of them will have to be maintained in some fashion. Maintained in a sense that we would like to install new features on them or upgrade them to fix existing problems in the currently running software. All of us using computers are aware of this maintenance and we (more or less) regularly patch our computers. However, extending this patching to other “non-standard” devices, such as appliances in our houses, may not be that easy. My previous post talked about the necessity to patch cars, and in this post we will examine what problems we may encounter along the way. Bear in mind that the previous post that focused on patching cars was just one example of the need for us to upgrade other devices. This discussion is applicable to many other devices we may have in or around our houses (e.g., smart gas meters, heating, air conditioning, etc.).

Let us start again with cars, as they are a nice exemplar. If we would like to patch (or re-flash) the software in our cars more often than once per year then how should we do it? An obvious answer would be to connect the car to our home network and download the updates from the car manufacturer’s website over the Internet, just the way we do it for our computers. If this sounds too easy and too good to be true then that’s because it is! I, for one, would like to have some confidence that the patch I am installing is indeed the correct one and it has not been tampered with either maliciously or otherwise. I would also like to have an assurance that the various basic functions of my car still perform as they should (e.g., braking, fuel mixture, door locking and similar). If something is not quite right with the patch I would like to be able to roll it back (i.e. remove it) and return the car to the exact state it was in before the patching was attempted.

In more technical terms, I would require authenticity and integrity of the patch, as well as self test, diagnostic and roll-back capabilities for the patch. All of this while preserving any user data that may exist (e.g., telephone numbers, seat position, driving routes and so on). The current state of the art in the computer industry is to ensure authenticity and the integrity of patches, but the rest is more of an exception than the rule.

How would we achieve self test and diagnostic capabilities? The straightforward approach would be to have the ability for the car to test itself. And I am not talking about power-on tests, which usually just verify that the correct voltage is present at the right places but nothing more. The kind of testing I have in mind is to verify that all systems have retained their existing functionalities and capabilities. The obvious problem with this approach is that the patch may interfere with the testing process itself. That can lead to false positives, i.e. the test will conclude that everything is good while, in reality, the test has failed. A second problem may arise from the way some tests are conducted or, more to the point, what are we actually measuring through these tests?

The workaround for the tampering with the testing process is to have a separate system that would perform testing. Separate in the sense that it cannot be patched together with the car itself. This separate system can either be an external, special-purpose computer or an additional computer built into the car. The external system would be a better option as it simplifies things when it needs to be updated and, additionally, one external system could be used for multiple cars.

The second problem is harder to address. Given that very few of us have all the equipment needed for testing a car’s roadworthiness at home we will have to simulate some of the inputs, for example, braking. Without brake testing equipment we cannot spin the wheels and then apply brakes to measure how they work. What we can do is apply the brakes and measure the force with which they are pressing on the disc, which is not quite the same as a real-world test scenario. The only way to address this problem would be if certain critical systems are patched we drive the car in the garage to perform patching and testing there.

Roll-back capabilities are less of an issue than testing. Some operating systems (e.g., Microsoft Windows, Solaris) and applications (e.g., Oracle database) do have this capability but it is not universally present in all products. Overall, the industry has the know-how so it is just a matter of the capabilities being built into the system.

While the above discussion has used cars as an example, the problem of patching devices is universal. Car, electricity meter, bread maker, television set or any other device we may possess has the same requirements. Nobody likes that a failed patch puts human lives in jeopardy or turns our precious gadgets into overpriced bricks. Vendors and operators/owners of devices have to improve patching capabilities built into the products. There will be more devices that will require patching and old support models where you would bring your device into a workshop cannot cope with that. Also, dispatching someone to patch a device to a customer premises is prohibitively expensive and equally impractical. The industry has knowledge of how to accomplish this and it is only a question of will to add the capabilities into the devices.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.