KR102553472B1 - Method for testing AT based on AUTOSAR standard - Google Patents

Abstract

An acceptance inspection test method based on the AUTOSAR standard is provided. An acceptance test test method based on the AUTOSAR standard according to an embodiment of the present invention includes a first request step in which a diagnostic tester requests a test with a software component; the software component invoking the requested test case and notifying the diagnostic tester of the state of the test case; the diagnostic tester confirming the notification; a second request step in which the diagnostic tester requests a test with the software component; the software component executing the requested test case; Responding the execution result to the diagnostic tester; and checking the result response by the diagnostic tester.

Description

Acceptance inspection test method based on AUTOSAR standard {Method for testing AT based on AUTOSAR standard}

The present invention relates to acceptance testing, and more particularly, to an acceptance testing method based on the AUTOSAR standard.

Recently, as various user-friendly functions are added to automobiles, there is an increasing demand for standardization of software for controlling electronic devices. As part of standardization, AUTOSAR (AUTomotive Open System Architecture) has been proposed.

In the case of some tests based on these AUTOSARs, they are triggered by the Lower Tester (LT) and verified by the Upper Tester (UT) or vice versa.

However, the method by which the verification of the test can be performed is not defined or no design is provided.

Also, when triggered according to the ATS (Autosar Test Specification), the AUTOSAR stack can only be verified using a white box testing approach. This approach requires a lot of effort, and the same result is not guaranteed to be 100% verified. It cannot be taken into account, there is always the possibility of manipulation in white box testing.

KR 2017-0111630 A

In order to solve the problems of the prior art as described above, an embodiment of the present invention is to provide an acceptance test method based on the AUTOSAR standard capable of improving test efficiency and reliability.

According to one aspect of the present invention for solving the above problems, a first request step of a diagnostic tester requesting a test as a software component; the software component invoking the requested test case and notifying the diagnostic tester of the state of the test case; the diagnostic tester confirming the notification; a second request step in which the diagnostic tester requests a test with the software component; the software component executing the requested test case; responding the execution result to the diagnostic tester; and confirming the result response by the diagnostic tester. An acceptance test test method based on the AUTOSAR standard is provided.

In one embodiment, the acceptance test test method based on the AUTOSAR standard may further include triggering, by an RTE module, a test case to the software component according to the test request.

In one embodiment, the triggering may include checking an ID of the requested test; and transmitting a debug frame response corresponding to the checked test ID to the software component.

In one embodiment, the executing step may include checking a command ID; performing an action requested by the checked command ID; checking whether the action has failed; and setting a failure bit when the action fails.

In one embodiment, the step of checking the result may check the response result based on the state of the test case checked in the step of checking.

The acceptance test method based on the AUTOSAR standard according to an embodiment of the present invention performs status check and result check according to a test request and test response between an upper tester (UT) and a lower tester (LT), respectively. However, since the acceptance test process can be easily verified, difficulties in the acceptance test can be solved.

In addition, when the upper tester (UT) executes a test case, the test efficiency can be improved by reducing the debugging time for verification by checking whether the test case has failed after execution and transmitting the result to the lower tester (LT). At the same time, it can be cost effective in terms of verification and testing.

In addition, the present invention verifies the test result by receiving status information from the upper tester (UT) when the lower tester (LT) requests a test and confirming the result response based on the status information when the upper tester (UT) responds to the test. Therefore, the reliability of the test can be improved.

1 is a schematic configuration diagram of an acceptance test test apparatus based on the AUTOSAR standard according to an embodiment of the present invention;
2 is a flowchart showing a test request process in the acceptance test test method based on the AUTOSAR standard according to an embodiment of the present invention;
3 is a flowchart showing a result response process in the acceptance test test method based on the AUTOSAR standard according to an embodiment of the present invention;
4 is a flowchart showing a detailed method of triggering a test case in FIG. 2;
5 is a flowchart showing a detailed method of test case execution in FIG. 3, and
6 is a diagram illustrating a CAN frame used in an acceptance inspection test method based on the AUTOSAR standard according to an embodiment of the present invention.

Hereinafter, with reference to the accompanying drawings, embodiments of the present invention will be described in detail so that those skilled in the art can easily carry out the present invention. This invention may be embodied in many different forms and is not limited to the embodiments set forth herein. In order to clearly describe the present invention in the drawings, parts irrelevant to the description are omitted, and the same reference numerals are assigned to the same or similar components throughout the specification.

Hereinafter, an acceptance test test apparatus based on the AUTOSAR standard according to an embodiment of the present invention will be described in more detail with reference to the drawings. 1 is a schematic configuration diagram of an acceptance test test apparatus based on the AUTOSAR standard according to an embodiment of the present invention.

Referring to FIG. 1, an acceptance inspection test apparatus 100 based on the AUTOSAR standard according to an embodiment of the present invention includes a lower tester (LT) 110, a CAN bus 120, and an RTE module 130 , upper tester (UT) 140 and BSW 150.

Here, the AUTOSAR stack of the acceptance inspection test apparatus 100 based on the AUTOSAR standard can be easily and efficiently tested.

To this end, the acceptance inspection test device 100 based on the AUTOSAR standard transmits a CAN frame to the SUT (System Under Test) 20 to trigger each test case, and the result is sent to the lower tester (LT). Send it back to (110). This allows a complete path to the test request and response to be created.

The lower tester (LT) 110 is provided in the test system 10 and may request a test to the upper tester (UT) 140 . Here, the lower tester (LT) 110 may be a diagnostic tester.

The CAN bus 120 may perform communication between the test system 10 and the SUT 20 . The CAN bus 120 may perform communication through a CAN frame between the lower tester (LT) 110 and the upper tester (UT) 140 .

The RTE (Run Time Environment) module 130 is located between the upper tester (UT) 140 and the BSW 150, and provides an interface for data exchange between the upper tester (UT) 140 and the BSW 150. can provide

The upper tester (UT) 140 may perform a test requested by the lower tester (LT) 110 . Here, the upper tester (UT) 140 may be a software component (SWC; SoftWare Component). The upper tester (UT) 140 may interwork with the ECU through a virtual network.

BSW (Basic Software) 150 provides a service for the upper tester (UT) 140 to perform a required task. Here, the BSW 150 may include service components such as a Non-volatile RAM Manager (NvM), a Diagnostic Communication Module (DCM), and a Diagnostics Event Manager (DEM).

The acceptance test test device 100 based on the AUTOSAR standard follows the following procedure for an acceptance test (AT) test.

When a test request is received by the SUT 20, the acceptance test device 100 based on the AUTOSAR standard triggers the lower tester (LT), receives and processes the software component (SWC), and notifies the SUT (20). It is possible to perform the procedure of transmission and sub-tester (LT) confirmation.

In addition, when the test response is transmitted by the SUT 20, the acceptance test device 100 based on the AUTOSAR standard triggers the lower tester (LT), receives the software component (SWC), and processes the software component (SWC). and transmission, and sub-tester (LT) confirmation procedures may be performed.

Hereinafter, the acceptance test method based on the AUTOSAR standard of the present invention will be described with reference to FIGS. 2 and 3 . 2 is a flow chart showing a test request process in the acceptance test method based on the AUTOSAR standard according to an embodiment of the present invention, and FIG. 3 is an acceptance test based on the AUTOSAR standard according to an embodiment of the present invention. It is a flow chart showing the result response process in the inspection test method.

The acceptance inspection test method based on the AUTOSAR standard is a process in which the upper tester (UT) 140 receives a test request from the lower tester (LT) 110 (see FIG. 2) and the upper tester (UT) 140 ) transmits a test response to the lower tester (LT) 110 (see FIG. 3).

More specifically, as shown in FIG. 2 , first, the lower tester (LT) 110 requests a test from the upper tester (UT) 140 (steps S201 to S203). Here, the lower tester (LT) 110 may transmit a CAN frame having valid data to the upper tester (UT) so that the upper tester (UT) 140 executes the test case.

At this time, the lower tester (LT) 110 transmits the CAN frame to the RTE module 130 through the CAN bus 120 (step S201). That is, the CAN bus 120 may receive the CAN frame transmitted from the lower tester (LT) 110 and transmit the received CAN frame to the RTE module 130.

Next, the RTE module 130 receives the CAN frame from the CAN bus 120, unpackages the received CAN frame, and analyzes (umpackage) (step S202).

Next, the RTE module 130 triggers a test case to the upper tester (UT) 140 according to the analyzed test request of the lower tester (LT) 110 (step S203). At this time, the RTE module 130 may trigger an executable by the RE_Common_Debug_Frame function as will be described later with reference to FIG. 4 based on the received event data.

Next, the upper tester (UT) 140 invokes the test case requested from the lower tester (LT) 110 (step S204). Here, the RE_Common_Debug_Frame function can call a test case based on the items of the received CAN frame.

Next, the upper tester (UT) 140 notifies the lower tester (LT) 110 of the state of the called test case (steps S205 to S207). Here, the upper tester (UT) 140 may transmit an acknowledgment (Ack) regarding the status of the called test case to the lower tester (LT) 110.

At this time, the upper tester (UT) 140 transmits a status notification to the RTE module 130 (step S205).

Next, the RTE module 130 receives the status notification from the upper tester (UT) 140, and packages the received status notification to be included in the CAN frame (step S206).

Next, the RTE module 130 notifies the status by transmitting the packaged CAN frame to the lower tester (LT) 110 through the CAN bus 120 (step S207). Here, the CAN bus 120 may receive the CAN frame from the RTE module 130 and transmit it to the lower tester (LT) 110.

Next, the lower tester (LT) 110 receives the CAN frame from the CAN bus 120 and checks the notification (S208). At this time, the lower tester (LT) 110 may check the notified state information. As will be described later, this state information can be used to confirm a result upon a result response from the higher level tester (UT) 140 . In this way, since the test result can be verified, the reliability of the test can be improved.

As shown in FIG. 3 , first, the lower tester (LT) 110 requests a test to the upper tester (UT) 140 (steps S301 to S303). Here, the lower tester (LT) 110 may transmit a CAN frame having valid data to the upper tester (UT) so that the upper tester (UT) 140 executes the test case.

At this time, the lower tester (LT) 110 transmits the CAN frame to the RTE module 130 through the CAN bus 120 (step S301). That is, the CAN bus 120 may receive the CAN frame transmitted from the lower tester (LT) 110 and transmit the received CAN frame to the RTE module 130.

Next, the RTE module 130 receives the CAN frame from the CAN bus 120, unpackages and analyzes the received CAN frame (step S302).

Next, the RTE module 130 triggers a test case to the upper tester (UT) 140 according to the analyzed test request of the lower tester (LT) 110 (step S303). At this time, the RTE module 130 may trigger an executable by the RE_Common_Debug_Frame function based on the received event data.

Next, the upper tester (UT) 140 executes the test case requested from the lower tester (LT) 110 (step S304). Here, the RE_Common_Debug_Frame function can call and process test cases based on the items of the CAN frame. At this time, the upper tester (UT) 140 may execute the Re_TestID_x function as will be described later with reference to FIG. 5 .

Next, the upper tester (UT) 140 responds to the lower tester (LT) 110 with the result of the executed test case (steps S305 to S307). Here, the upper tester (UT) 140 may set the failure bit to “1” in the CAN frame when the test case fails.

At this time, the upper tester (UT) 140 transmits the resulting response to the RTE module 130 (step S305).

Next, the RTE module 130 receives the result response from the upper tester (UT) 140, and packages the received result response to be included in the CAN frame (step S306).

Next, the RTE module 130 responds to the result by transmitting the packaged CAN frame to the lower tester (LT) 110 through the CAN bus 120 (step S307). Here, the CAN bus 120 may receive the CAN frame from the RTE module 130 and transmit it to the lower tester (LT) 110.

Next, the lower tester (LT) 110 receives the CAN frame from the CAN bus 120 and checks the result (step S308). At this time, the lower tester (LT) 110 may check the response result based on the previously notified status information. In this way, since the test result can be verified, the reliability of the test can be improved.

In this way, the acceptance test (AT) process can be easily verified by performing status confirmation and result confirmation according to the test request and test response between the upper tester (UT) 140 and the lower tester (LT) 110, respectively. Therefore, the difficulty of acceptance test (AT) can be solved.

4 is a flowchart illustrating a detailed method of triggering a test case in FIG. 2 . Here, the test case trigger can be performed by the RE_Common_Debug_Frame function.

First, the RTE module 130 checks the ID of the test requested from the lower tester (LT) 110 (step S401).

As a result of the check in step S401, if the checked test ID is "1", the RTE module 130 requests the upper tester (UT) 140 to execute the test ID 1 (step S402).

As a result of the check in step S401, if the checked test ID is "x", the RTE module 130 requests the upper tester (UT) 140 to execute the test ID x (step S403).

Next, the RTE module 130 transmits a debug frame response corresponding to the checked test ID to the upper tester (UT) 140 (step S404).

5 is a flowchart illustrating a detailed method of executing a test case in FIG. 3 . Here, test case execution can be performed by the Re_TestID_x function.

First, the higher tester (UT) 140 checks the command ID for the test requested by the higher tester (UT) 140 (step S401).

As a result of the check in step S501, if the checked command ID is "1", the upper tester (UT) 140 performs the action requested by the command 1 (step S502).

As a result of the check in step S501, if the checked command ID is "x", the upper tester (UT) 140 performs the action requested by the command ID x (step S503).

Next, the upper tester (UT) 140 checks whether the performed action has failed (step S504).

As a result of checking in step S504, if the action performed fails, the upper tester (UT) 140 sets the failure bit of the CAN frame (step S505). Here, the upper tester (UT) 140 may set the failure bit to “1”.

As a result of checking in step S504, if the action performed has not failed, the series of processing is ended. At this time, the upper tester (UT) 140 maintains the failure bit of the CAN frame as "0". Here, the failure bit of the CAN frame is defaulted to "0".

In this way, the upper tester (UT) 140 checks whether the test requested by the lower tester (LT) 110 is executed and fails, and transmits the result to the lower tester (LT), thereby reducing debugging time for verification. By reducing it, test efficiency can be improved, and at the same time, it can be effective in terms of cost of verification and testing.

6 is a diagram illustrating a CAN frame used in an acceptance inspection test method based on the AUTOSAR standard according to an embodiment of the present invention.

The debug CAN ID may be specified as 0x444 as a test request from diagnostic test 110 to software component 140 . Also, the debug CAN ID may be specified as 0x555 as the resulting response from software component 140 to diagnostic tester 110 .

Meanwhile, the data layout of the CAN frame may include commands, execution results, test IDs, and data to be processed.

That is, the CAN frame consists of 8 bytes, Byte 0 is command and execution result, Byte 1 and Byte 2 are test ID, Byte 3 to Byte 6 are data to be processed, and Byte 7 is not used.

More specifically, the CAN frame may include a 6-bit command and a 1-bit failure indicating an execution result.

Also, the CAN frame may include a test ID according to ATS in 2 bytes.

In addition, the CAN frame may include 4 bytes of data to be processed as an argument for the requested command.

By this method, the acceptance test method based on the AUTOSAR standard can easily verify the acceptance test (AT) process, thereby solving the difficulty of the acceptance test (AT) and reducing the debugging time for verification. By reducing the test efficiency, it is possible to improve the test efficiency, and at the same time, it can be effective in terms of cost of verification and testing, and since the test result can be verified, the reliability of the test can be improved.

The above methods can be implemented by the acceptance test test apparatus 100 based on the AUTOSAR standard as shown in FIG. 1, and in particular, can be implemented by a software program that performs these steps. In this case, these programs may be stored in a computer readable recording medium or transmitted by a computer data signal combined with a carrier wave in a transmission medium or a communication network.

At this time, the computer-readable recording medium includes all types of recording devices in which data readable by a computer system is stored, and includes, for example, ROM, RAM, CD-ROM, DVD-ROM, DVD-RAM, and magnetic tape. , a floppy disk, a hard disk, an optical data storage device, and the like.

Although one embodiment of the present invention has been described above, the spirit of the present invention is not limited to the embodiments presented herein, and those skilled in the art who understand the spirit of the present invention may add elements within the scope of the same spirit. However, other embodiments can be easily proposed by means of changes, deletions, additions, etc., but these will also fall within the scope of the present invention.

100: Acceptance inspection test device based on AUTOSAR standard
110: sub tester (LT) 120: CNA bus
130: RTE module 140: upper tester (UT)
10: test system 20: SUT

Claims (5)

a first request step in which the diagnostic tester requests a test with the software component;
the software component invoking the requested test case and notifying the diagnostic tester of the status of the test case;
the diagnostic tester confirming the notification;
a second request step in which the diagnostic tester requests the test to the software component;
the software component executing the requested test case;
responding the execution result to the diagnostic tester; and
checking the result response by the diagnostic tester;
Acceptance inspection test method based on the AUTOSAR standard, including According to claim 1,
The acceptance test test method based on the AUTOSAR standard further comprising: triggering a test case with the software component according to the test request in the first request step and the second request step by the RTE module. According to claim 2,
The triggering step is
checking the ID of the requested test; and
Transmitting a debug frame response corresponding to the checked test ID to the software component. According to claim 1,
The steps to execute are:
Checking the command ID;
performing an action requested by the checked command ID;
checking whether the action has failed; and
If the action fails, setting a failure bit;
Acceptance inspection test method based on the AUTOSAR standard, including According to claim 1,
The acceptance test test method based on the AUTOSAR standard for checking the result response based on the state of the test case checked in the checking step.

Images