Automating & Educating the World’s Leading Companies

The Challenge 

A leading manufacturer of locomotive engines was looking for a solution to improve productivity during the testing of  diagnostic and control parameters in the locomotive. This testing was done after all manufacturing had been completed. The  application placed the locomotive into states seen while operating in the field. 

The Solution 

Data Science Automation (DSA) developed a system to emulate a Diagnostic Information Display (DID). The DID is a  custom serial device found on a large class of locomotives. The virtual DID (vDID) was a process that ran on a Windows PC  and emulated the DID. The customer required that the vDID be integrated with an existing, highly customized Visual Basic  (VB) test executive. This test executive was modified to launch the vDID when the user required DID parameter information.  This was done by compiling the vDID into a DLL. This DLL was then called whenever any DID information was required  by the test sequence.  

Abstract 

The purpose of this system was to automate an otherwise manually intensive testing process to identify problems with the  locomotive manufacturing process. This system was designed to be a flexible and portable system to facilitate the exhaustive testing of all functions and capabilities of the locomotive. In the end this increased the reliability of the locomotive and  eliminated potential test value transcription errors. 

The Locomotive System 

The locomotive has a multitude of working parts including the control systems to monitor and operate these parts. The main  control system that allows the user to interact with diagnostics consists of two main parts. The first part is the controller.  This controller is the main information center that controls all communications and operations of the locomotive. This  controller relays information requested to the diagnostic information display (DID) to allow the user to view parameter values such as temperatures, current, and to run embedded controller self-tests. The DID communicates with the controller  using an RS232 serial protocol. To allow the user the ability to automate a large number of information requests the vDID  

was developed using LabVIEW. The vDID is a seamless replacement of the DID which is located in the cab of a locomotive.  To allow for the use of either the DID or the vDID a custom wiring harness was built. This placed the vDID inline with the controller and the DID. The harness developed is shown below in Figure 1.

The harness allowed the sharing of the receive line for displaying purposes on both the vDID and the DID. The toggle switch  will route the transmit line between the either the DID to the controller or the vDID to the controller.  

The vDID 

The vDID was designed to reside on a laptop. This allowed the vDID solution to be portable and used in a variety of  environments. The vDID is controlled by a virtual keypad that was designed to allow the user to enter values, set values, and  enter requests for values. The vDID user interface is shown in Figure 2. 

Figure 2.   

Automating Testing of Locomotives 

There are six core tests that the vDID was to automate. These tests were controlled by the VB test executive. The test  executive allowed the user to configure test sequences and execute the sequence. The test executive user interface is shown in Figure 3.  

Figure 3. 

The first test used was the monitor parameter test. This test required the user to place the 4 digit monitor parameter ID into  the input string field of the test executive. This value was then passed to the LabVIEW DLL where communications  occurred with the controller. The buttons were programmatically “pressed” during this procedure and the vDID DLL  returned the response from the controller. The controller response was then placed into the “Output String” field of the test  executive user interface (Figure 3). This procedure allowed automatic retrieval of parameters such as temperatures,  currents, voltages, speeds, etc. 

The second test type was the fault trap test. This test would programmatically “press” vDID buttons to sequence a series of  steps to retrieve the most current fault that had occurred. Once the vDID was in its fault menu, the faults would be returned  as output parameters from the DLL function call and placed in the output string field in the test executive.