Sensorpoint and Patchpoint Technology

Essential to the Wind River Test Management is the ability to create sensorpoints and patchpoints. A sensorpoint is software used to instrument live applications, while a patchpoint is similar software used to patch live applications. Both can be applied dynamically without modifying the application source code, rebuilding the application, reflashing boards, or rebooting the device.

Sensorpoints and patchpoints are minimally intrusive on device performance. They can be disabled after test and activated as needed to diagnose and repair a device under test. Sensorpoints can be created by development engineers and leveraged by test teams throughout the device lifecycle and across geographically disbursed teams.

Specific Applications of Sensorpoints and Patchpoints

Intelligently exercise subsystems and functions:

• Inject specific values in variables
• Force conditional expressions to execute code paths
• Inject faults for routines
• Alter the system's environment (e.g., change values read from sensors, set CPU and peripheral controllers register values, modify streaming data)

Expedite problem reproduction and resolution:

• Force the state of the system to reproduce the error by altering the system's environment
• Capture a trace of global and local variables, function calls, and data during the reproduction of a problem
• Timestamp any point in the system to determine timing defects and performance

Dynamically debug running software:

• Insert debug code (including logs and printfs) to isolate defects
• Insert code to test fixes
• Peek and poke variables, registers, and sensors to validate fixes
• Modify a running system without having to reboot and set up tests for every code change

Force the system to extreme conditions:

• Inject faults at any time during a test
• Force the environment of the device to a specific state (e.g., high temperature reading on a sensor)
• Log timestamps that quantify the performance of any part of the device
• Set the device to a specific state that may only be reached after hours of continuous operation (e.g., buffers full, queues empty, calculating PI to the 40 millionth decimal place)
• Eliminate the use of sophisticated test equipment (e.g., forcing the hop count to a large value in a data packet)

Create a fault documenting system:

• Set up automatic data logging and aggregation
• Set up dynamic instrumentation of applications for additional logs

Dynamically diagnose and fix running software:

• Run diagnostic applications without having to reboot the device
• Provide log function arguments and return values at customer site
• Timestamp any point in the system to determine timing and performance issues
• Augment designed-in diagnostics and logging facilities
• Perform "hitless" patching of applications to resolve issues