Display devices play a vital role as the man-machine interface in most embedded domains. Display systems provide information regarding the health of safety-critical subsystems and the general status of the machine. Accuracy and precision of the information displayed is a key factor in proper machine operation. Hence, display systems need to be tested meticulously before they are delivered to the customer.
The present-generation display ECM’s (Electronic Control Module) function is not restricted to displaying parameters like fuel level or speed; it also acts as the virtual master of the vehicle. Most display ECMs in off-highway vehicles present at least half a dozen screens to the operator, who selects the one he wants to view based on the need. Testing the display ECM becomes as complex as its design (see figure).
A new technology called DTA (Display Test Automation) does not require any specific additional hardware or software. In fact, using the concept of DTA, one can develop custom software to suit specific purposes. This method can reduce time and effort in the software lifecycle and improve price-performance ratio. DTA aims to fully automate testing and solve the problems and limitations involved in display testing. Once testing of the display ECM is automated, the idea can be extended to all other ECMs and also perform integrated automated testing of the entire machine.
A majority of the problems in display testing can be solved by automating the testing process. One of the major reasons for performing manual testing is the fact that an operator/user needs to be present in order to press the buttons, check the indicators, or verify the screen. Simulating key presses solves these problems, and there are several ways to do it. Either the external hardware mechanically presses the keys, or hardware sends voltages to the key ports. But any external hardware needs corresponding software to control it, and the bundle tends to be costly and may not be suitable for all types of displays.
The simplest and most efficient way to simulate a key press is to send a datalink message that triggers the same behavior as a key press. This simulation can cover several scenarios such as key press and release, key hold for a time period and release, and multiple simultaneous key presses.
In the datalink message, a certain byte can be set as the key identifier and another byte as a status byte. The key identifier specifies which key is to be processed, and the status byte indicates whether it is pressed, released, or held. In the same datalink message, the time period for which the key is held, the number of times it should be pressed, and also the interval between presses can be specified. The DTA approach co-exists with the physical key press without affecting the normal key behavior.
Another roadblock in display automation is that there are test cases in which the tester needs to switch on and off the display ECM several times. There are two distinct restart modes: power cycle (remove power to the ECM abruptly and power it up again), and key cycle (turn off the key and turn the key back on).
This is usually the case in real machines. In order to simulate the power cycle, one needs to understand the processor specifications and pin details. Most processors have a configurable pin that can be used to reset them through software, and a datalink message can be sent to set/reset this pin to cause an immediate reset. This successfully simulates the power cycle.
In machines, NVM (Non Volatile Memory) gets corrupted or erased in certain scenarios, and the ECM is expected to gracefully recover. But since this is hard to simulate, it becomes very difficult to predict the display behavior. To solve this, a datalink message can be used to simulate NVM erase and corruption at any point (at startup, normal operation, just before key-off). Certain bytes can be set to identify the block of NVM, and another byte to specify the operation like erasure or corruption. Multiple blocks of NVM can also be selected.
During every release, a lot of time is spent testing the navigation between different screens. The tester has to understand the specification and manually check if the display moves from one screen to another on a particular key press. When a display contains 40-50 different screens, this process might take several hours or even days. In software, the different screens are tracked using a unique identifier (ID or screen address).
The framework for DTA can be implemented within a span of 2 weeks. With the initial framework in place, testers can immediately concentrate on developing automation test scripts. Any ECM can be tested using this technique. Multiple ECMs can be connected and the entire machine can also be tested.
This work was done by Narasimhan Rajagopal of Caterpillar India Private Limited. The full technical paper on this technology is available for purchase through SAE International at http://papers.sae.org/2013-01-0061.