Software Probes Monitor And Repair Applications

A program that never needs changing or fixing is a rare one. That's why debugging, monitoring, and patching tools are in every programmer's toolbox. While some of these tools are akin to rope and stone knives, more advanced development environments provide dynamic insight into applications. This is where Wind River's SensorPoint technology fits.

SensorPoints are part of Wind River's Lab Diagnostics and Device Management programs, which address the entire development and deployment cycle. It's an ambitious approach that so far has been well-received, though it is still growing.

SensorPoint support is integrated with Wind River's Eclipse-based Workbench integrated development environment (IDE). It requires tight coupling between all development components, including the IDE, compiler, linker, and diagnostic tools (see "SensorPoints,"). SensorPoints can be added not only to applications with debugging hooks but also to production applications that lack this information—one reason for this tight integration requirement.

PATCHING PROGRAMS
Developers can add script code into applications while they are debugging, allowing them to monitor the application or change its operation on the fly for what-if scenarios. While useful, past implementations tended to be restricted to development work on applications with debug information. The process also tended to be unwieldy as the number of modifications grew. Most were used in a transient fashion.

Application patching is similar. This is normally done so a small set of patches can be delivered using a larger application to generate a new version with the patches incorporated. It makes delivery of these changes faster and easier, but the changes must be applied before an application is run. Patching systems are rarely used for debugging purposes, and selective addition of changes is sometimes difficult.

Finally, there are logging and tracking tools that can be added at compile time or run time. Some require diagnostic information, while others do not. SensorPoints tie all these approaches together.

PLACING PROBES
SensorPoints are C code compiled to machine code so execution is as efficient as the original application. Linked into an application at run time, they can either replace an existing block of code or add code (Fig. 1). In the latter, the linkage to the new code overwrites one or more instructions that must be replicated in the new code so the application continues to run as originally intended.

Adding a SensorPoint might be as simple as adding a jump instruction to the new code that ends in a jump back to the old code after the newly added instruction. But in practice, many things can make the process harder. For example, some architectures use different instruction sizes for jumps, so any code overwritten by the new addition must be included in the SensorPoint code.

Likewise, the overwritten code may be the jump target from other parts of the application. These must be modified appropriately as well. The task becomes even more complex when optimized code is part of the process. Such large numbers of variables require tight integration with the make system, compiler, and linker.

SensorPoints are designed to be reused. They're defined in C source code using a slightly modified syntax that makes it easier to incorporate this code into application code. This tends to be of little interest for logging or debugging code, but it is imperative for patches that need to be rolled back into the main application source-code tree.

The source code for a SensorPoint is maintained in separate files from the application code. This makes management significantly easier. It also makes the process much easier to manage using source-code management tools.

USING SENSORPOINTS
Developers will first use SensorPoints for debugging and diagnostic purposes. They can be created ahead of time or during the debugging process. For instance, a developer hits a breakpoint and decides that a change is needed or that details need to be monitored. A SensorPoint can be created while the program is stopped and then incorporated into the application without having to relaunch it.

If developers need to fix a problem, they could add one or more SensorPoints for the fix. Once the problem is solved, the SensorPoints could be forwarded to users of the application. The changes could then be rolled into the main source tree and the new application could be used as the basis for further development. Of course, the application may be in the field and SensorPoints may be the only way to deliver fixes if wholesale application upgrades aren't possible.

The quality-assurance group can also take advantage of SensorPoints, though programmers familiar with the application will likely create them. SensorPoint code then can be used to simulate problems or boundary conditions. It can also be used to automate testing, adjusting either the program targeted for shipment or the one in the field. This eliminates the need to use a debug version of an application or to ship an application with debug information.

SensorPoints can be used in the manufacturing process as well, running burn-in tests that would not be done in the field. SensorPoints allow this to occur without delivering the matching code with the final product.

Finally, SensorPoints can be used in the field to monitor a system, logging information when developers are in search of an error or tracking performance. Remote access or logging via SensorPoints can provide custom information about platforms in the field that weren't delivered with these types of hooks in place. Often, this kind of information cannot be duplicated in the lab. This enables the data to be obtained at the point of failure.

MANAGING MODIFICATIONS
SensorPoints are powerful, but applying them arbitrarily can cause more problems than solutions. A particular binary instance must match the target, or applying the SensorPoint will result in a corrupt program. Additionally, one SensorPoint may require others as well as support modules.

Tracking SensorPoints, applications, and related details are part of Wind River's solution (Fig. 2). SensorPoints can be grouped, managed, stored, and even deployed in a range of environments, from single developers working on an application to target systems shared by a group.

In fact, SensorPoints are just a small part of a much larger lab development and management system that includes Wind River's Device Management, Field Management, and Lab Diagnostics tools. These tools support Wind River's Linux and VxWorks operating systems as well as the Workbench IDE.

Wind River's system allows central and common tracking, logging, result and resource sharing, etc. It includes a Web-based repository for SensorPoints that should facilitate reuse. It also includes the ability to group SensorPoints and incorporate dependencies so their use can be automated and made more predictable. The system keeps track of which SensorPoints can be applied to a particular application instance.

Although not all the features a company may want are in place, many are. SensorPoints can be posted, tracked, and managed from a testing and deployment standpoint. This means code won't be lost after it's developed, and only the proper combination will be used.

In a sense, SensorPoints are simply an extension of application development tools that can be applied to a program in any form, not just a debug version. As in any programming environment, SensorPoints are likely to find a wide range of uses that may be unrelated to their original purpose.

Wind River's technology is tightly integrated with its own development tools. Since some are based on open-source technology, this approach may eventually make it into wider distribution.

Wind River
www.windriver.com