search.noResults

search.searching

dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Test & measurement


replicate the subtle states resulting from such operations is simply not possible. Although it is extremely challenging to


The system includes a GPS simulator and a noise simulator


was developed using the LabVIEW system design platform. There are certain components that


cannot be converted to models, and the interface between human and vehicles is extremely challenging. Of those components that cannot be converted to a model-based format, the speedometer probably provides the simplest example. Imagine a speedometer displaying ‘50km/h’ as the value of a vehicle’s speed. In this case, the command to display ‘50km/hr’ is issued from the controller as an electrical signal. Such a signal can be evaluated during a simulation and can also be confirmed on the actual vehicle. As long as the system is functioning correctly, the speedometer would be expected to display ‘50km/h’ as a result of receiving the signal. However, to check if ‘50km/h’ is actually being displayed, a human is needed to visually confirm the results. In other words, the process by which a driver perceives information from the vehicle cannot be converted into a model. Similarly, operations performed by the driver to communicate information to the vehicle also cannot be modelled. For example, a driver can press a button to turn the air-conditioning on/off, or tap the touch panel to operate the navigation system. Building a model that can exactly


34


validate systems where there are no models, Mazda decided to put an extra effort to develop test engineering strategy and methodology for those challenging areas with Mazda’s motto “Be a driver”. As described above, it is extremely challenging to model interactions between the human driver and vehicle. Thinking about this as simply as possible, for a driver to communicate information to the vehicle (electronic components), a button or some other kind of instrumentation would need to be manipulated. And the performance of such manipulations would require human hands. Indeed, performing these kinds of manual tests have been the reality. However, manual testing requires an enormous amount of time and labour. Thus, it was critical that the team develop a mechanism for automating evaluation. To meet this need, the team added a robot to operate the electronic components. This computer-controlled robot pushed buttons and tapped the touch panel in place of a person. Similarly, the team also needed to consider how information would be communicated from the car to the driver. Returning to the speedometer example, the traditional testing process consisted of a human visually checking the display to determine if ‘50km/h’ was actually displayed. To automate this portion of the evaluation, an image processing system was added. Specifically, the automated process involved photographing the speedometer’s display with a camera, and then processing the obtained image to determine whether the result was correct. If, for example, the speed was displayed using a seven- segment LED display, the camera would photograph the LED display and process the obtained image to identify numbers and confirm the displayed speed. Alternatively, if the speed was represented by a needle display, image processing was used to measure the angle of the needle, and use that value to calculate the speed in kilometers per hour. By monitoring and comparing the signals from both the control unit and the display, the system can determine whether or not the speed is displayed correctly. Under this system, it is also possible to


substitute each electronic component using a virtual system (virtual electronic components) through software. The inability to proceed with evaluations until all electronic components are completed is a huge limitation. Since the team wanted to begin testing and get results as quickly as possible, they substituted virtual electronic components for the actual components whenever possible. Not only do these virtual components operate


October 2018 Instrumentation Monthly


similarly to the real thing, they also have a look and feel that closely resembles the actual component. This capability to utilise virtual components enables flexible testing. Depending on the contents of the test, actual parts can be used when deemed necessary; otherwise, virtual substitutes can be used. The content thus far describes the logic


verifying components of the automated testing system. In addition to this, adding functionality to evaluate robustness was necessary. Mazda places great importance on verifying robustness. At Mazda, the evaluation of robustness involves first identifying the conditions at which logically correct operations approach their limits, and then determining the amount of margin. The amount of margin necessary for a pass result is determined according to independent, in-house standards. This evaluation process enables the company to provide precise feedback to the design divisions of Mazda and its suppliers. Of all the conditions used to test


robustness, the most representative conditions would be a fluctuating power supply voltage and a high-noise environment. For example, the power supply voltage could be varied to ascertain the points at which the evaluated electronic components will stop operating correctly. To evaluate robustness during high-noise conditions, a noise simulator was added for the team’s Second Stage system. However, the performance of the


logic during unfavourable conditions is not the only element subject to robustness evaluation. For example, vehicle functionality includes the use of voice commands to operate the vehicle. This too is subject to robustness evaluation. To achieve this, a speech synthesis system was added to the system. This system was compatible with both Japanese and English languages, and would issue voice commands in a variety of different voices, including male or female, young or old, and with differing intensities and articulations. Mazda needed to evaluate the robustness of the system to identify the extent to which instructions could be correctly


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56