Test session
A near-field communication device adapts device responses to ensure accurate testing by intercepting and modifying responses, addressing the misinterpretation issue in existing tools and enhancing test compatibility.
Patent Information
- Application Number
- FR2024006384
- Authority / Receiving Office
- FR · FR
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-06-17
- Publication Date
- 2025-12-19
AI Technical Summary
Existing testing tools and devices are unable to account for all types of responses sent by a device under test, particularly in wireless communication scenarios, leading to misinterpretation of valid responses as errors.
A near-field communication device capable of intercepting and modifying responses from a device under test to ensure they are interpretable by the test tool, adapting its communication based on the test session context.
Enables test tools to recognize and accommodate a wider range of device responses, ensuring accurate testing without disrupting normal device operation.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
Title of the invention: Test session technical field
[0001] This description relates generally to electronic systems and devices, and more particularly to the implementation of tests for electronic systems and devices. More specifically, this description relates to the implementation of tests for a secure embedded component using near-field communication. Previous technique
[0002] It is very common to test electronic devices during their manufacture or before being placed on the market to verify their conformity to a norm or standard. For this purpose, one or more test tools are connected to the device and implement one or more operations to verify the physical and / or software functioning of the electronic device.
[0003] There are test tools that use wired connections with the devices to be tested, but there are also test tools that use wireless connections.
[0004] It would be desirable to be able to improve, at least in part, certain aspects of the implementations for testing electronic devices, and, in particular, certain aspects of the implementations for testing electronic devices using wireless connections. Summary of the invention
[0005] There is a need for electronic devices to be tested to be able to adapt their responses to tests according to the test tool used.
[0006] There is a need for electronic devices including wireless communication devices capable of understanding that a test session is in progress.
[0007] There is a need for electronic devices including wireless communication devices capable of understanding that a test session is in progress and adapting the information communicated by a device to be tested accordingly.
[0008] One embodiment provides for a test implementation enabling consideration of all kinds of information communicated by a device to be tested.
[0009] One embodiment provides a wireless communication device capable of understanding that a test session is in progress and adapting the information communicated by a device to be tested accordingly.
[0010] One embodiment provides a wireless communication device adapted to communicate with a test tool by establishing wireless communication, and adapted to communicate with a device to be tested, wherein said wireless communication device is adapted to: - intercept an initial command to start a test session sent by said test tool to said device under test; and - when a test session is started, provide a first modified response when the device under test responds to a second test command sent by said test tool with a second response that said test tool is not able to interpret.
[0011] Another embodiment provides a method for testing a device under test using a test tool, wherein said test tool is adapted to communicate with a wireless communication device by establishing wireless communication, and said wireless communication device is adapted to communicate with a device under test, wherein said wireless communication device is adapted to: - intercept an initial command to start a test session sent by said test tool to said device under test; and - when a test session is started, provide a first modified response when the device under test responds to a second test command sent by said test tool with a second response that said test tool is not able to interpret.
[0012] According to one embodiment, said wireless communication device is adapted to exit said test mode after processing said second test command.
[0013] According to one embodiment, said wireless communication device is adapted to exit said test mode after processing a finite number of third test commands.
[0014] According to one embodiment, said wireless communication device is adapted to exit said test mode after receiving a fourth command to stop said test session.
[0015] According to one embodiment, a value of said first response is stored in said wireless communication device.
[0016] According to one embodiment, the value of said first response is defined by said first command.
[0017] According to one embodiment, said wireless communication is a near field communication.
[0018] According to one embodiment, the device to be tested is a secure element.
[0019] According to one embodiment, the device to be tested is a secure element onboard.
[0020] Another embodiment provides for an electronic device comprising the wireless communication device described above and said device to be tested.
[0021] Another embodiment provides for an electronic system comprising the device described above and said test tool. Brief description of the drawings
[0022] These features and advantages, as well as others, will be described in detail in the following description of particular embodiments, given by way of non-limiting example, in relation to the accompanying figures, among which:
[0023] [Fig.1] represents, very schematically and in block form, an embodiment of a test system for an embedded secure element;
[0024] [Fig. 2] represents a block diagram illustrating a method for implementing a test procedure for an embedded security component; and
[0025] [Fig.3] represents a block diagram illustrating another method of implementing a test method for an embedded security element. Description of the implementation methods
[0026] The same elements have been designated by the same reference numerals in the different figures. In particular, structural and / or functional elements common to the different embodiments may have the same reference numerals and may have identical structural, dimensional and material properties.
[0027] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been represented and are detailed.
[0028] Unless otherwise specified, when referring to two elements connected together, this means directly connected without intermediate elements other than conductors, and when referring to two elements connected (in English "coupled") together, this means that these two elements can be connected or linked through one or more other elements.
[0029] In the following description, when reference is made to absolute position qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative position qualifiers, such as the terms "above", "below", "superior", "inferior", etc., or to orientation qualifiers, such as the terms "horizontal", "vertical", etc., reference is made, unless otherwise specified, to the orientation of the figures.
[0030] Unless otherwise specified, the expressions "approximately", "roughly", and "in the order of" mean within 10%, preferably within 5%.
[0031] The embodiments described below relate to the implementation of electronic device testing, and more particularly to the implementation of testing using wireless communication, such as, for example, Near Field Communication (NFC). The embodiments described below relate in more detail to the implementation of testing a secure electronic device, such as a secure component, for example, an embedded secure component.
[0032] The inventors discovered that certain testing tools or devices were not capable of taking into account all the kinds of responses sent by a device to be tested. For example, some testing tools or devices are unable to interpret a lack of response as a valid response to a test command, even though such a response is acceptable in a product usage context other than that of a test. To overcome this problem, the inventors decided to make a near-field communication device capable of adapting responses sent by a device under test during the execution of a test. These embodiments are described in relation to Figures 1 to 3.
[0033] The embodiments described above are particularly suitable for use in any type of industrial market where it may be necessary to test embedded security components using wireless communication. More specifically, a test system may be intended for: - the automotive industry, for example in the field of automotive electrification or in the field of Advanced Driver Assistance Systems (ADAS) or in systems allowing access to a car via unlocking the car by phone or another element such as a key; - the industrial sector, for example in the field of green energy, infrastructure electrification, the Internet of Things (IoT) and smart homes, where electricity and energy consumption and data exchange are key elements; and - the personal electronics industry, for example in the field of mobile telephony, the Internet of Things (IoT), the field of broadband interfaces, or the field of cards having at least one contactless interface for example of the Near Field Communication type such as payment card (bank card), identity card, passports, loyalty card.
[0034] More particularly, these embodiments are particularly suited to the field of mobile telephony, and to the testing of embedded secure elements, such as SIM cards.
[0035] Fig. 1 represents, very schematically and in block form, a system 100 implementing the test of an electronic device.
[0036] The system 100 includes a test tool 110 (TEST Tool) or test device 110 adapted to implement a test procedure for a part of an electronic device 120 to be tested. Examples of test procedures are described in detail with reference to Figures 2 and 3.
[0037] The test tool 110 is an electronic device or a program, or software, implemented by a computer. The test tool 110 is adapted to communicate with the device 120 using a communication device 111 (Server). In a preferred example, the test tool 110 is adapted to communicate with the device 120 by connecting to a server 111. In one example, the test tool 110 is configured to communicate with server 111 via an API1 link using different types of electronic and / or software interfaces.
[0038] The device 120 includes a device 121 (eSE) which is to be tested. According to one example, the device 121 is a secure device, such as a secure element. According to a preferred embodiment, the device 121 is a secure element, or an embedded secure element.
[0039] The device 120 further includes a wireless communication device 122 (NFCC) adapted to implement wireless communication for exchanging data with external devices, and in particular with the test tool 110. According to a preferred example, the wireless communication device 122 is adapted to implement near-field communication. In this case, the wireless communication device 122 can also be called an NFC controller. The wireless communication device 122 is adapted to exchange data with the device 121 via a wired connection, for example, a single-wire connection using a Single Wire Protocol (SWP), or via internal memories or registers.For example, a link using a communication protocol known as "Simplified High-Level Data Link Control" (sHDLC) or a secure communication protocol known as CEE Contact Less Transport (CLT) as defined in the referenced standard TS 102 613.
[0040] To communicate with each other, the tool 110 and the device 120 can use an intermediate device 130 comprising different hardware and / or software layers enabling the conversion of the format of the data transmitted by the tool 110 and by the device 120.
[0041] According to one variant, the various hardware and / or software layers of the intermediate device 130 may be included partially or entirely in the test tool 110 and / or partially or entirely in the device 120.
[0042] According to one example, the intermediate device 130 comprises: - a layer 131 (Client); - a 132-layer (Custom Layer); and - a 133 wireless reader (RF Reader).
[0043] Layer 131 is a software layer adapted to exchange data directly with device 111 using a TCP / IP link employing Transmission Control Protocol (TCP) and Internet Protocol (IP) type protocols, or a link using User Datagram Protocol (UDP) and Internet Protocol (IP) type protocols. The link between element 111 and element 131 allows the flexibility to run tests on a single PC or on multiple PCs on the same network or remotely via the internet.
[0044] Layer 131 is also adapted to exchange data directly with layer 132 using an API2 link. For example, the API2 link uses various types of electronic and / or software interfaces. Layer 131 is adapted to run on a computer, which may be the same as the one running element 100, or on a different computer, enabling the execution of links between two computers on the same (private) network or via the internet.
[0045] Layer 132 is a software and / or hardware layer adapted for communication with layer 132 and with the wireless reader 133. For example, layer 132 is adapted for direct communication with the wireless reader 133 via a PCSC link. For example, the PCSC link is a software abstraction layer that interfaces a smart card reader via a wired connection using, for example, a USB cable.
[0046] The wireless reader 133 is adapted to exchange data directly with layer 132 and directly with the wireless communication device 122 of device 120. Layer 132 has the advantage of providing an abstraction layer to layer 131 (client), which allows the test device to avoid having to adapt to all the communication modes and protocols that would be used by the target device being tested. In this case, if the test device is testing an eSIM, i.e., a digital personal identification card, it would probably have to implement the ISO7816 protocol (to simulate the so-called contact part of the phone) and sHDLC / CLT to simulate the wireless part of the transactions.If the target is a device combining wireless communication, such as near-field communication, and eSIM functionalities, the test device should implement a layer to communicate with the eSIM through the NFC controller—that is, the controller implementing the wireless communication (likely using communication protocols known as I2C (Inter-Integrated Circuit), I3C (Improved Inter-Integrated Circuit), or SPI (Serial Peripheral Interface)—and a wireless reader). This abstraction layer simplifies the server implementation and allows for new target implementations without requiring modifications to the test device implementations.
[0047] Figure 2 is a block diagram illustrating an implementation method of a test procedure 200 carried out within the system 100 described in relation to Figure 1. More specifically, Figure 2 illustrates the steps implemented by the test tool 110, the wireless communication device 122 and the device 121 to be tested.
[0048] At a step 201 (Start TEST Mode), implemented by test tool 110, test tool 110 starts a test session.
[0049] At a step 202 (Snd Activation CMD), subsequent to step 201, implemented by the test tool 110, the test tool 110 sends an Act_CMD command indicating the start of the test session to the device to be tested 121.
[0050] At step 203 (Int Activation CMD), following step 202, implemented by the wireless communication device 122, the wireless communication device 122 receives and intercepts the Act_CMD command. In other words, device 122 does not transmit the Act_CMD command to the device under test 121.
[0051] At a step 204 (Test Mode), subsequent to step 203, implemented by the wireless communication device 122, in response to the Act_CMD command, the wireless communication device 122 enters a test mode in which its operating mode differs. This is detailed below.
[0052] At a step 205 (Snd TEST CMD), subsequent to step 204, implemented by the test tool 110, the test session is started, and the test tool 110 sends a test command TEST_CMD to the device to be tested 121. For this purpose, the test tool 110 sends the test command TEST_CMD to the device 122 so that it can transmit it to the device 121 to be tested.
[0053] At a step 206 (Trans TEST CMD), subsequent to step 205, implemented by the wireless communication device 122, the wireless communication device 122 receives the test command TEST_CMD and transmits it to the device to be tested 121.
[0054] At a step 207 (Rev TEST CMD), subsequent to step 206, implemented by the device to be tested 121, the device to be tested 121 receives the TEST_CMD command from the wireless communication device 122 and begins its processing.
[0055] At a step 208 (Snd TEST CMD), subsequent to step 207, implemented by the device under test 121, the device 121 has completed the processing of the test command TEST_CMD and produced a response TEST_RSP. The device 121 sends the TEST_RSP response to the wireless communication device 122 for transmission to the test tool 110.
[0056] At a step 209 (Rsp Ok?), following step 208, implemented by the wireless communication device 122, the wireless communication device 122 receives the TEST_RSP response and verifies it. If the TEST_RSP response is of a type interpretable by the test tool 110, the next step is a step 210 (Trans Rsp). Otherwise, that is, if the TEST_RSP response is of a type interpretable by the test tool 110, the next step is a step 211 (Trans OtherRsp).
[0057] It is stated here that the test tool 110 is unable to interpret a response if it can be interpreted as an error message and not as a response, when it should be interpreted as a response. For example, the test tool 110 may be unable to interpret responses encoded with a certain This means that blank responses, or no response at all, are possible. Indeed, the wireless communication system is also adapted to determine if the 121 device is not sending a response.
[0058] One explanation for the non-response would be that the test performed by the test device is intended to verify that a command is indeed received and processed by the target (120 / 121), but that the correct test response is a non-response from the target. For example, the sent command is not addressed to it. In this case, the target receives the command but does not respond to it. A non-response on a contactless protocol is difficult to interpret because it could also be associated with a transmission error, which would have the same effect of a non-response. By replacing the command response with understandable information, the test device can be certain that the processing has been performed. In the described case, one can imagine that the embedded secure element would have responded with an empty communication frame (with no data to return over the contactless communication). The NFC controller interprets this response and responds with the response described in step 211.This response will be understood by the contactless reader and returned through the layers to the test device, which will validate this response according to the expected test result. Furthermore, this testing method allows test suites to be executed without disrupting the use of these same elements when deployed in the market and integrated into an infrastructure (such as a public transport ticket validation infrastructure).
[0059] In step 210, following step 209, implemented by the wireless communication device 122, the wireless communication device 122 transmits the TEST_RSP response to the test tool 110 without any modification.
[0060] In step 211 (Trans Other Rsp), following step 209, implemented by the wireless communication device 122, the wireless communication device 122 does not transmit the TEST_RSP response to the test tool 110, but replaces the TEST_RSP response with an NFCC_RSP response which is interpretable by the test tool 110. According to an example, the value of the NFCC_RSP response is stored in the wireless communication device.
[0061] At a step 212 (Rev Rsp), subsequent to step 210 or 211, implemented by the test tool 110, the test tool receives the TEST_RSP response or the NFCC_RSP response and draws the necessary conclusions.
[0062] Other steps of the type of step 205, i.e. steps of sending a test command, can be implemented after step 212.
[0063] The wireless communication device 110 can exit test mode in various ways.
[0064] According to a first example, the wireless communication device 122 is adapted to exit test mode after processing a single test command TEST_CMD.
[0065] According to a second example, the wireless communication device 122 is adapted to exit test mode after processing a finite number of TEST_CMD test commands.
[0066] According to a third example, the wireless communication device 122 is adapted to exit test mode after receiving a specific command to stop the test session from, for example, the test tool 110.
[0067] One advantage of this embodiment is that it allows a test tool to take into account, during a test period, all types of responses provided by a device under test. Put another way, this can make a test tool compatible with a wider range of different devices under test.
[0068] Figure 3 is a block diagram illustrating an implementation method of a test procedure 300 carried out within the system 100 described in relation to Figure 1. More specifically, Figure 3 illustrates the steps implemented by the test tool 110, the wireless communication device 122 and the device 121 to be tested.
[0069] Test method 300 of [Fig. 3] is similar to test method 200 described in relation to [Fig. 2]. The common elements of methods 200 and 300 are not described again in detail below. Only the differences between methods 200 and 300 are highlighted.
[0070] The main difference between method 300 and method 200 is that, in method 300, the command to start a test session also allows the value of the modified response sent by the wireless communication device 122 to be defined in the event of a response that cannot be interpreted by the test tool 110.
[0071] In other words, in process 300: - step 202 is replaced by a step 302 (Snd Set Rsp CMD); - Step 203 is replaced by step 303 (Int Set Rsp CMD); and - Step 211 is replaced by a step 311 (Trans Predefined Rsp).
[0072] Furthermore, the process 300 includes steps 201, 204 to 210 and 212 described in relation to [Fig.2].
[0073] At a step 302 (Snd Activation CMD), subsequent to step 201, implemented by the test tool 110, the test tool 110 sends a Set_Rsp_CMD command indicating the start of the test session to the device under test 121 and providing a replacement response value to the wireless communication device 122. This replacement value makes it possible to form a response which is interpretable by the test tool 110 in the subsequent step 311.
[0074] At step 303 (Int Activation CMD), following step 302, implemented by the wireless communication device 122, the wireless communication device 122 receives and intercepts the Set_Rsp_CMD command. In other words, device 122 does not transmit the Set_Rsp_CMD command to the device under test 121. Furthermore, the Wireless communication device 122 stores the replacement response value included in the Set_Rsp_CMD command.
[0075] In step 311 (Trans Other Rsp), following step 209, implemented by the wireless communication device 122, the wireless communication device 122 received the TEST_RSP response from the device under test 121, and this response is not interpretable by the test tool 110. The communication device 122 does not transmit the TEST_RSP response to the test tool 110, but replaces the TEST_RSP response with a Predef_RSP response, which is interpretable by the test tool 110 and whose value is equal to the value transmitted by the Set_Rsp_CMD command. This allows the test device to validate that the command had the expected effect. Since the verification message is introduced by the test device, this message is therefore unpredictable by the target, which could try to simulate it to skip / pass the test.
[0076] As before, other steps of the type of step 205, i.e. steps of sending a test command, can be implemented after step 212.
[0077] In addition, the wireless communication device 110 can exit test mode in various ways.
[0078] According to a first example, the wireless communication device 122 is adapted to exit test mode after processing the test command TEST_CMD.
[0079] According to a second example, the wireless communication device 122 is adapted to exit test mode after processing a finite number of TEST_CMD test commands.
[0080] According to a third example, the wireless communication device 122 is adapted to exit test mode after receiving a specific command to stop the test session from, for example, the test tool 110.
[0081] One advantage of this embodiment is that it allows a test tool to take into account, during a test period, all types of responses provided by a device under test. Put another way, this can make a test tool compatible with a wider range of different devices under test.
[0082] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will become apparent to them. In particular, alternative ways of exiting the test mode may be considered.
[0083] Finally, the practical implementation of the embodiments and variants described is within the reach of a person skilled in the art, based on the functional indications given above.
Claims
Demands
1. Wireless communication device (122) adapted to communicate with a test tool (110) by establishing wireless communication, and adapted to communicate with a device to be tested (121), wherein said wireless communication device (122) is adapted to: - intercept a first command (Act_CMD; Set_Rsp_CMD) to start a test session sent by said test tool (110) to said device to be tested (121); and - when a test session is started, provide a first modified response (NFCC_RSP; Predef_RSP) when the device to be tested (121) responds to a second test command (TEST_CMD) sent by said test tool (110) with a second response (TEST_RSP) that said test tool (110) is not able to interpret.
2. Method of implementing a test of a device to be tested (121) by a test tool (110), wherein said test tool (110) is adapted to communicate with a wireless communication device (122) by establishing a wireless communication, and said wireless communication device (122) is adapted to communicate with a device to be tested (121), wherein said wireless communication device (122) is adapted to: - intercept a first command (Act_CMD; Set_Rsp_CMD) to start a test session sent by said test tool (110) to said device to be tested (121); and - when a test session is started, provide a first modified response (NFCC_RSP; Predef_RSP) when the device under test (121) responds to a second test command (TEST_CMD) sent by said test tool (110) with a second response (TEST_RSP) which said test tool (110) is not able to interpret.
3. Device according to claim 1, or method according to claim 2, wherein said wireless communication device (122) is adapted to exit a test mode after processing said second test command (TEST_CMD).
4. Device according to claim 1, or method according to claim 2, wherein said wireless communication device (122) is adapted to exit a test mode after processing a finite number of third test commands.
5. Device according to claim 1, or method according to claim 2, wherein said wireless communication device (122) is adapted to exit a test mode after receiving a fourth command to stop said test session.
6. Device according to any one of claims 1, 3 to 5, or method according to any one of claims 2 to 5, wherein a value of said modified first response (NFCC_RSP) is stored in said wireless communication device.
7. Device according to any one of claims 1, 3 to 5, or method according to any one of claims 2 to 5, wherein the value of said first modified response (Predef_RSP) is set by said first command (Set_Rsp_CMD).
8. Device according to any one of claims 1, 3 to 7, or method according to any one of claims 2 to 7, wherein said wireless communication (122) is a near field communication.
9. Device according to any one of claims 1, 3 to 8, or method according to any one of claims 2 to 8, wherein said device to be tested (121) is a secure element.
10. Device or method according to claim 9, wherein said device to be tested (121) is an embedded security element.
11. Electronic device (120) comprising the wireless communication device (122) according to any one of claims 1, 3 to 10 and said device to be tested (121).
12. Electronic system comprising the device according to claim 11 and said test tool (110).
Citation Information
Patent Citations
Hardware security module and processing method in such a module
US20120159253A1
ELECTRONIC SUBSCRIBER IDENTITY MODULE (eSIM) INSTALLATION AND TESTING
US20180351945A1