[Editor's Note: This was originally posted on the Embedded Master]
The software patch is a much maligned technique for keeping systems robust because many users perceive that the majority of these patches as merely fixes of feature bugs that the developers should have taken care of before shipping the software. While there are many examples where this sentiment has a strong ring of truth to it, the patch-it principle is a critical approach to maintaining robust systems so that they can continue to operate within an acceptable range of behavior despite the huge variability that the real world throws at them. This post focuses on the many other reasons (rather than sloppy and curtailed design, build, and test) for patching a system – all of which share the same basis:
The software patch is currently the primary approach for a system to manifest modified behaviors in light of additional information about the environment it needs to operate within.
The basis for this statement stems from what I have referred to as the omniscient knowledge syndrome, which is the assumption that designers should identify and resolve all relevant issues facing a system at design time. This is a necessary assumption because contemporary embedded systems are not capable of sufficient learning that allows them to determine an appropriate course of action to handle previously unspecified environmental conditions.
Common examples of patching are to add new capabilities to a system; to implement countermeasures to malicious attack attempts; and to implement special case processing to support interoperability across a wider range of hardware configurations, such as new combinations of video cards, system boards, and versions of operating systems.
New capabilities are added to systems experimentally and in response to how the market reacts to those experimental features. Patching enables developers to competitively distribute successful experiments to their existing base of systems without requiring their user base to buy new devices with each new feature.
A robust system should be able to counter malicious attacks, such as viruses and hacks. A perfect static defense against malicious attacks is impossible, or at least it has so far been impossible for the entire history of mankind. Attacks and countermeasures are based on responding to what the other side is doing. Patching helps mitigate device obsolescence that would otherwise ensue when malicious entities successfully compromise those systems.
The rate of evolution in the electronics market is too rapid for any developer to completely accommodate in any single project. The constant flow of new chips, boards, algorithms, communication protocols, and new ways of using devices mean that some mechanism, in this case patching, is needed to allow older devices to integrate with newer devices.
In essence, the patch-it principle is a “poor man’s” approach to allow systems to learn how to behave in a given condition. The designer is the part of the embedded system that is able to learn how the world is changing and develop appropriate responses for those changes. Until embedded systems are able to recognize context within their environment, identify trends, and become expert predictors, designers will have to rely on the patch-it principle to keep their products relevant as the world keeps changing.
Tags: Patch-It Principle
Processor Tracker
All Entries RSS Feed