There was a time when computer programs always needed a human to initiate them. Once executed, the software programs would run until a specified condition occurred, and then they would shut off. Eventually, programming allowed for conditional triggers, which gave an ability to connect to some kind of a defined stimuli from a sensor and, when triggered, that initiated the program execution or changes.
Advancement Brings Two Steps Forward One Step Backward
Today, software can be embedded into minor and capital equipment and portable hardware directly with very complex executions. Once turned on, the equipment will operate and function in its own capacity based on the programming already included in its hardware storage banks and will execute until turned off or its power source is terminated. However, then comes the problem that always occurs with computer programming over time – when something runs for too long, a processing error eventually occurs. Even in the software world, minute degradations in the calculations applied add up and become programming errors over a running duration. It could be a rounding issue, a momentary disconnect of a motherboard circuit, or a heat buildup on a chip. Nothing is perfect, and neither are computers. When this happens, the program stops or hangs. Again, humans were needed for a long time to turn off and turn on the related equipment again, essentially re-booting the system. Now, modern systems can re-boot themselves without assistance, even when their programming hangs. This is possible with the use of what is known as a watchdog timer.
Program Solution Fixed by Another Program
The name of the feature is appropriate for the function of the watchdog timer. It literally operates in the background, waiting and sensing for when there is a variance or anomaly in the operation of adjacent embedded software. After a certain time or performance condition is met, the watchdog timer program takes over and forces a reset signal, re-booting the embedded software in the equipment. The logic is not rocket science; it basically follows a simplistic if-then logic script. If the sensor receives a signal, then it acts in a specified way. However, to be effective, the sensor must always be in “on” mode, running in the background.
The expected variance is identified by a numerical report the watchdog timer program receives. As long as the report is something other than 0 or a defined parameter, then the equipment functions as normal. However, when it reaches 0, i.e. the timer runs out, the watchdog program kicks on and does its very simple task of re-booting. That’s it. For a simple, one- task job, the watchdog timer is probably the most important form of self-awareness software designed for an embedded equipment’s unmonitored operation.
Humor in Technology Going to the Dogs
Interestingly, probably because someone had an odd sense of humor at the time, the watchdog timer also needs to be reset to work again when an embedded hardware program is restored to normal operating function. This particular reset aside from the primary re-boot is known as “kicking the dog,” literally. The analogy comes from the idea of a human repeatedly kicking a dog to avoid the animal biting the human. As long as the primary chip sends its signal, the watchdog stays in passive mode and doesn’t do anything, ergo the dog stays away. However, when the signal-sending stops, then it kicks in with a reset, as noted above, ergo the dog “bites.” This relationship between signal sender and watcher could effectively run for as long as the hardware can hold up, i.e. an infinite loop operation.
Caveats to Think About
On its own, the watchdog timer might seem like a singular task type fix to a known programming risk. However, it shouldn’t be over-applied in practice. Building in a watchdog timer on every particular piece of embedded equipment could end up being a nightmare with lots of unnecessary re-boots just because there was a momentary blip somewhere along the line. Imagine what would happen when the power goes out? Every piece of equipment would automatically re-boot when it might not be necessary, potentially causing a lot of avoidable physical damage along the way.
Keep in mind also, not every software hang should necessarily be restarted. Sometimes, a stall can happen because a safety prevention feature has been triggered, blocking any further operation. This is common with embedded software responding to specific condition codes or signals. The block is an intentional safety feature shutting down the equipment until the risk is dealt with and fixed. In most cases, such stops are signaled by a specific code thrown to tell the operator of the risk’s presence. So there is an obvious reason. In these instances, a watchdog timer program shouldn’t be applied as it would in essence override the built-in safety protection.
Bringing in the Right, Specialized Help for System Programming
Connors Industrial has a significant depth of experience in helping design detection software and thermal management programming, including when systems should incorporate a re-boot due to a given temperature condition or similar. In such instances, a hanging system could end up resulting in serious equipment damage for prolonged exposure to high temperatures, so a watchdog timer would be essential to restart the related equipment so that they are operating properly again. If you’re dealing with a combination of both types of technology, then Connors Industrial would be an ideal partner to be working with on installation and updating of such systems for proper operation.