Test Automation Support Tool for Automobile Software
Total Page：16
File Type：pdf, Size：1020Kb
AUTOMOTIVE Test Automation Support Tool for Automobile Software Tomomi KATAOKA*, Ikuko SAKA, Ken FURUTO, Tatsuji MATSUMOTO In recent years, automotive components have become more sophisticated and the electronic control unit (ECU) has employed more complex large-scale software. As the product scale becomes larger, an increasing number of tests are required to assure product quality. Even in the case that the auto-testing tools are used, test patterns need to be input manually. This process requires significant amounts of man-hours particularly when the product types vary and the test patterns need to be modified for input signal changes. In order to improve the efficiency of this product development process, we have developed a tool that converts the simulation patterns used in model-based design into those for product tests. This tool automatically adjusts the input signals, and thus, successfully reduces the man-hours by 50% and improves the test quality with common test patterns. Keywords: software, test method, model based development 1. Introduction System Specification System Test *1 We develop electrical control units (ECUs ). ECU HILS software (hereinafter referred as “vehicle-embedded soft- Software Design Integration Test ware”) is less likely to have a completely new design, and MILS Actual Test for ECU in many cases, the former model design is used in the de- Unit Design Unit Test velopment process of the software. When the former de- Design Simulation sign is used, the former test pattern is also used in order to SILS ensure software quality. However, there is the possibility Coding that the entire design of the vehicle may be reviewed for functional decomposition to multiple ECUs and the design MILS SILS HILS changes of connection interfaces. In this case, test patterns ECUs Model Model Actual Unit should be modified due to the changes of signal I/O inter- faces for each ECU, even though the basic functions of the Control Unit Model Program Program vehicle are not changed. Vehicle Model Model Model On the other hand, the vehicle-embedded software tends to be more complex and larger(1). To solve the issues Fig. 1. Model-based Development Process of the increase in the number of test items and risks for val- idation errors, the model-based development method has been promoted in the automobile industry(2). In this method, design verification is conducted by simulation using a design drawing (model) (MILS*2) (Fig. 1). This 2. Quality of ECU Common Development Process method enables us to improve the design quality, minimize rework, and detect bugs during the test process(3). More- 2-1 Issues on design modification of test patterns over, by using the common test patterns in the phases of For software development with the former design, test design simulation and ECU testing, the efficiency of the patterns need to be modified in some cases even if the entire development process can be improved. However, functions of the model have not been changed. This sec- signal I/O timing may vary due to the variations of the sig- tion shows an example of these cases. nal I/O interfaces between the model and ECUs intended As shown in Fig. 2, the functions of one ECU are allo- for verification (HILS*3). These issues may form a bottle- cated to multiple ECUs. In Structure (a), one ECU controls neck in achieving the standardization. the functions of receiving an input signal from “SW_X” and This paper describes how we can improve the effi- transmitting the output signal to load “RLY_Y.” In Struc- ciency in embedded software development by reusing the ture (b), ECU-1 receives the input signal from “SW_X” and former design. In our experiment, we first worked on the then the ECU-2 transmits the output signals to “RLY_Y.” technology of using the common test patterns for I/O in- By regulating the multiple ECUs via network commu- terfaces of ECUs before and after the design change. We nications, it is possible to reduce costs by shortening the en- then used the common test patterns at the phases of ECU tire length of vehicle wiring systems. If the structure of the testing and design simulation, with the technology speci- ECU is changed, ECU test pattern in Structure 1 can be fied above, to achieve high efficiency in the model-based converted to the ECU-1 and ECU2 in Structure 2 for testing development. the same functions to achieve the effective test design. As shown in Figs. 2 (c), (d), many changes should be SEI TECHNICAL REVIEW · NUMBER 77 · OCTOBER 2013 · 79 made to the test pattern due to the variations of interfaces development target, the affected area tends to be extensive, such as presence or absence of the signals and respective due to the increased number of changes for I/O interfaces I/O signal types (a direct connection*4 or network commu- for multiple I/O signals involved in this software. nications). Because of the significant amount of workload, there In Figs. 2 (e), (f), we compared the switch timing, is the possibility that errors may occur due to a human in- based on the test patterns between “ECU in Structure 1” tervention in creating the test patterns, and we were con- and “ECU2 in Structure 2.” This is an example of changing cerned about the product quality. the input interfaces from a “direct connection” to “CAN*5.” 2-2 I/O signal allocation and conversion tool The filter processing is performed using the software To resolve the problems specified in 2-1, we developed to retrieve information of the switch input from a “direct a tool called “signal allocation and conversion tool” to au- connection.” The filter processing is to monitor the signal tomatically convert the changes in I/O signal allocations, state at regular time intervals. If the condition remains con- such as signal names, input types, and input timing, based stant beyond a predetermined time, then it is judged as on the original test pattern. input information inside of the software. This function is To be concrete, the “basic test pattern” is created in also incorporated into the vehicle-embedded software to advance, according to the timing of switch input and the eliminate chattering of the contact switch. For Structure 1, recognition of input information, as shown in Fig. 3 (a). As the switch input operation by a user is judged as the inter- for the input type of a “direct connection,” time duration nal information of the software, after a certain period of (Ta) from the timing of switch input to that of input con- time of filter processing (Ta). On the other hand, for the firmation is moved to an earlier point, by filter processing. ECU2 pattern in Structure 2, filter processing may not be So, the test pattern that changes at the earlier point can be triggered to receive information of the switch input via net- created automatically, as shown in Fig. 3 (b). work communications on the ECU-2 side, because filter processing is already complete on the ECU1 side. There- fore, the time from the signal input to output may differ between those test patterns. Then, it is required to adjust the time duration from the signal input to output, in addi- (a) Standard Test Patterns tion to the changes of I/O interfaces, I/O signal types, and → t Input Data ON presence or absence of signals. OFF Output ON In order to respond to the variations of I/O interfaces Expected Value OFF and timings for ECUs, design of each test pattern should (b) Test Patterns for a Direct Connection be modified manually. Although the commercially avail- → Input Data t ON Ta able auto-testing tool is used to enhance the efficiency of Switch Operation OFF (Direct Connection) Move to the earlier timing testing, it is required to change the test patterns. For ECU ON software used for the body control module*6, which is our (Internal Information) Output Expected Value ON OFF Ta=Time duration until the input Load Activation filter is confirmed. (c) Test Patterns for Communication → Input Information ON t Switch Operation (CAN) Before Design Change (Original) After Design Change (Changes are made) (Internal Information) ON A direct Connection Output Expected Value ON Communication Load Activation OFF (a) 1 ECU (Structure 1) (b) 2 ECUs -Structure2 SW_X RLY_Y SW_X RLY_Y Fig. 3. Examples of Signal Input Timing ECU ECU-1 ECU-2 (c) I/O Signals -Structure 1 (d) I/O Signals -Structure 2 These allocation and conversion tools have several pa- RLY_Y RLY_Y Activation Activation rameters that can be set separately for each signal included ECU ECU-1 ECU-2 SW_X SW_X in the test patterns (Table 1). Necessary items for various CAN_Sw_X test patterns related to signal names, input types, input tim- (e) Test Patterns -Structure 1 (f) Test Patterns -Structure 2 ECU ing, and deleting the signals, can be set to the parameter, ON although the functions are the same. Data can be consoli- ON SW_X SW_X OFF ECU-1 OFF dated using one setting file. (Internal ON Ta ON (Internal Ta Information) Time base, which is used to adjust timings, can be set Information) ON in a manner relative to the original test pattern. If the test ON CAN_Sw_X RLY_Y OFF pattern exists for a specific car model, it enables us to con- ON ECU-2 RLY_Y vert test patterns directly to the other input types without Ta: Filtering Processing Time OFF creating the “basic test pattern” again. Fig. 2. ECU Structure and Test Patterns 80 · Test Automation Support Tool for Automobile Software Table 1. Settings of Signal Allocation Parameters scopes differ between the model and ECUs, posing a prob- (a) Descriptions of Signal Allocation Setting Parameter lem in the use of common test patterns.