Automated testing of digital keys for vehicles

Abstract

A method of testing a digital key is described, the method: providing a standard digital key instruction from a digital key test manager device to a computing device to send a message to a device under test; communicating with the device under test from the digital key test manager device to determine operation of the device under test as a result of the message; and evaluating the operation of the device under test at the digital key test manager device to assess the functionality of the digital key.

Description

Background Art

[0001] The development of personal computing devices that a user can carry or otherwise maintain, such as cellular phones (including so-called "smartphones"), wearable devices (such as so-called smart watches, smart head-mounted devices - such as headphones, smart glasses, head-mounted displays - such as extended reality head-mounted devices, including virtual reality head-mounted devices, augmented reality head-mounted devices, etc.), laptop computers, tablet computers, etc., has created many evolving use cases that enable interaction with different devices including vehicles. As an example, a personal computing device can provide a digital key (DK), such as a digital car key (DCK), which allows a user to interact with a vehicle such as a car (or in other words, a car) to lock, unlock, and operate the vehicle. This allows the personal computing device to be used as a replacement or backup for conventional car keys.

[0002] However, as the number of different personal computing devices (both in terms of different models from different manufacturers and different versions of the same model from the same manufacturer) and the number of computing devices (e.g., which can refer to vehicles of different models and trims and even different head units within a given vehicle of the same model and trim) increases, testing of digital keys grows exponentially. Since testing may be performed manually, testing of digital keys may require a significant amount of time, especially when the digital key application fails verification due to software bugs, hardware anomalies, etc. Manual testing may be costly and prone to human error. Since each digital key device and vehicle may have a different operating mode, manual testing may also require extensive knowledge on the part of the tester and considerable preparation time. Summary of the invention

[0003] In general, the techniques of this disclosure relate to automated testing of digital keys for interacting with another computing device, including a computing device present in a vehicle—a vehicle such as an automobile (or in other words, a car, where such a computing device is referred to as a head unit), a motorcycle, an electric bicycle (which may be referred to as an e-bike), farm equipment, an aircraft, etc.—a home automation system (e.g., a smart lock), and / or any other computing device that uses a digital key to protect access to and / or operation of the computing device. Rather than resorting to manual testing of individual computing devices relative to different head units or other computing devices, the techniques described in this disclosure provide a unified digital key testing application programming interface (API) that can automate testing of digital key application software, underlying computing device hardware, head unit (or another computing device) software, and various combinations of head unit (or other computing device) software.

[0004] In general, the technology of the present disclosure relates to the interoperability and / or testability of digital keys. The device test application can interact with the digital key framework and the digital key test manager using a standardized application programming interface (API) to reduce interoperability issues of the digital key application and make the digital key application more likely to pass the test check. A potential problem with digital car keys is that a large number of different vehicle models and digital car key applications create interoperability and testing challenges. Each digital car key application must be tested for each vehicle model, and each vehicle model must be tested for each digital car key application.

[0005] A unified testing approach can reduce the effort of adding new computing devices, digital car key applications and vehicles to the ecosystem. Interoperability and functional verification benefit from unified testing across different devices and vehicles. Shared system test architecture and infrastructure help original equipment manufacturers (OEMs) reduce costs by using common test criteria as part of self-verification or as a quality check before entering an external laboratory. Unified automated testing methods can reduce the time, cost and human errors that may occur in manual testing.

[0006] In one example, the present disclosure relates to a method for testing a digital key, comprising: providing standard digital key instructions from a digital key test manager device to a computing device to send a message to a device under test; communicating from the digital key test manager device with the device under test to determine an operation of the device under test as a result of the message; and evaluating the operation of the device under test at the digital key test manager device to assess the functionality of the digital key.

[0007] In another example, the present disclosure relates to a method for testing a digital key, comprising: providing standard digital key instructions from a digital key test manager device to a computing device to send a message to a device under test; communicating from the digital key test manager device with the device under test to determine an operation of the device under test as a result of the message; and evaluating the operation of the device under test at the digital key test manager device to assess the functionality of the digital key.

[0008] In another example, the present disclosure relates to a computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to: provide a device test application of a computing device with a standard digital key command to send a message to a device under test; communicate with the device under test to determine an operation of the device under test as a result of the message; and evaluate the operation of the device under test to assess the functionality of the digital key.

[0009] In yet another example, the present disclosure relates to a system comprising: means for providing a device test application of a computing device with a standard digital key command to send a message to a device under test; means for communicating with the device under test to determine an operation of the device under test as a result of the message; and means for evaluating the operation of the device under test to assess the functionality of the digital key.

[0010] The details of one or more examples of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the present disclosure will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1A is a conceptual diagram illustrating a device test application and a digital key test manager device in accordance with one or more techniques of this disclosure.

[0012] Figure 1B is a conceptual diagram illustrating a device test application, a digital key test manager device, a sniffer module, a radio frequency (RF) jammer, and a mechanical fixture in accordance with one or more techniques of this disclosure.

[0013] Figure 1C is a conceptual diagram illustrating a device test application and a digital key test manager device showing a user interface (UI) test, according to one or more techniques of this disclosure.

[0014] Figure 1D is a conceptual diagram illustrating a digital key test manager apparatus with test extensions according to one or more techniques of this disclosure.

[0015] Figure 1E is a conceptual diagram illustrating a device test application and a digital key test manager device in accordance with one or more techniques of this disclosure.

[0016] Figure 1F is a conceptual diagram illustrating an application programming interface (API) for a computing device and a device under test in accordance with one or more techniques of this disclosure.

[0017] Figure 2 is a block diagram illustrating an example computing device for digital key testing according to one or more aspects of the present disclosure.

[0018] Figure 3 is a block diagram illustrating a digital key test manager apparatus for digital key testing according to one or more aspects of the present disclosure.

[0019] Figure 4A is a flow chart illustrating an exemplary setup test case for a digital key testing process according to one or more aspects of the present disclosure.

[0020] Figure 4B is a flow chart illustrating an exemplary owner pairing test case of a digital key testing process according to one or more aspects of the present disclosure.

[0021] Figure 4C is a flow chart illustrating an exemplary key sharing test case of a digital key testing process according to one or more aspects of the present disclosure.

[0022] Figure 5 is a flow chart illustrating example operations of a digital key testing process performed by a computing system in accordance with one or more aspects of the present disclosure.

[0023] Figure 6 is a flow chart illustrating example operations of a digital key test process performed by a digital key test manager device in accordance with one or more aspects of the present disclosure. DETAILED DESCRIPTION

[0024] Figure 1A-1F The system shown in shows automated testing of a digital key, where a computing device 110 interacts with a test device under test 112 to determine whether a specific computing device digital key functionality at the computing device 110 works with the specific device under test 112. The digital key test manager device 110 allows automation of testing using standardized test instructions.

[0025] Figure 1A 1 is a conceptual diagram illustrating a device test application 134 and a digital key test manager device 110 according to one or more techniques of the present disclosure. The digital key test manager device 110 and the device test application 134 located at the computing device 102 may provide a standardized way to test the device under test 112. The digital key test manager device 110 may use a device test application 134 as discussed below. Figure 1F A standardized application programming interface (API) shown in FIG. 1 interconnects the computing device 102 and the device under test 112 .

[0026] The digital key test manager device 110 may be as follows: Figure 3 The digital key test manager device 110 may be a server, which may be local or remote. The digital key test manager device 110 may include multiple or a single computing device. The digital key test manager device 110 may be implemented and reused to run standard ecosystem test plans. The digital key test manager device 110 may be enhanced to support auxiliary test equipment for automation, such as the following about Figure 1CMechanical fixture 138 discussed. The digital key test manager device 110 and the universal test API can enable faster development and integration cycles, lower barriers to entry for new adopters, cheaper validation, higher interoperability and better quality at and after release, and accelerated adoption by the ecosystem and by users. The digital key test manager device 110 and the device test application 134 located at the computing device 102 can be used to test the process without relying on a specific digital key application such as the OEM digital key application 130 and the native digital key application 132.

[0027] The computing device 102 may include a digital key framework 114, a vehicle original equipment manufacturer (OEM) digital key application 130, a native digital key application 132, and a device test application 134. The device test application 134 may be a software layer for translating generic / abstract commands into vehicle-specific commands. The digital key framework 114 may be a standardized application that allows applications such as the OEM digital key application 130, the native digital key application 132, and the device test application 134 to send messages to the vehicle. The digital key framework 114 may interact with a secure element (SE) 116.

[0028] The secure element 116 may be a chip that is protected from unauthorized access and used to run a limited set of applications and store confidential and encrypted data. Security for digital keys such as digital car keys is very important, so some standards including the Car Connectivity Consortium (CCC) digital key require the use of a secure element 116.

[0029] The digital key test manager device 110 can be run on different systems (i.e., devices\servers) to execute test cases that are independent of the type of computing device and vehicle under test. The digital key test manager device 110 can test any combination of a digital key (DK) enabled device (such as a computing device 102 (e.g., a mobile phone or wearable device)) and any device under test (such as a device under test 112 (e.g., an equivalent test device\test bench\simulated or actual vehicle)) using a common set of digital device and vehicle test APIs, as described below with respect to Figure 1F discussed.

[0030] The device under test 112 has the ability to respond, receive instructions from the computing device, and authenticate the digital key from the computing device. The device under test 112 can be a vehicle under test with a computing element such as a head unit or other computing element. Alternatively, the device under test 112 can be a vehicle test bench using vehicle components or vehicle simulation. The device under test 112 can allow digital key testing of a specific vehicle from an OEM to test the digital key operation.

[0031] As more vehicles and devices join the digital key testing ecosystem, it becomes more difficult to join new vehicles and devices because digital key testing of computing devices needs to be performed for each different vehicle, and digital key testing of vehicles needs to be performed for each different type of computing device. A unified testing approach reduces the effort of joining the ecosystem by reducing the costs associated with system testing at all stages of product development.

[0032] Further, different digital key applications, such as the OEM digital key application 130 and the native digital key application 132, have different user interfaces (UIs), and tests that automate the UIs are often often broken and difficult to maintain. In addition, vehicles and test benches have various non-standardized operating modes, which also limits automation and standardization. As discussed below, the digital key test manager device 110 and the device test application 134 can avoid these problems and implement a unified, standardized digital key test architecture.

[0033] The digital key test manager device 110 may provide the computing device 120 with standard digital key instructions, such as test 160, to send a message to the device under test 112. The digital key test manager device 110 may communicate with the device under test 112 to determine the operation of the device under test as a result of the message. The digital key test manager device 110 may evaluate the operation of the device under test 112 to assess the functionality of the digital key.

[0034] The first phase of testing may not require a connection to a server. The second phase of testing (such as the 2nd and 3rd layers described above) includes providing additional standard digital key commands. The second phase of testing requires a connection to a server. The digital key test manager device 110 can be from Figure 1B At least one sniffer module 136 is shown receiving signals, the at least one sniffer module detecting communications from the computing device 102 to the device under test 412 .

[0035] The digital key test manager device 110 can control Figure 1B and Figure 1E The mechanical fixture 138 is shown to move the computing device 102 to test the device under test 112, such as moving the computing device 102 to a wireless communication module, such as a near field communication (NFC) reader, ultra-wideband (UWB), personal area network, wireless network, or cellular network. The digital key test manager device 110 can perform user interface (UI) testing on the original equipment manufacturer (OEM) digital key application 130 or the native application digital key application 132 at the computing device 102. The computing device 102 can include a device test application 134. The digital key can be a digital car key, and the digital key test manager device 110 can be a digital key test manager device.

[0036] The device test application 134 may provide a standard test instruction set to the digital key framework 114. The device test application 134 may emulate a digital key application, such as an OEM digital key application 130 or a native digital key application 132. The digital key framework 114 may generate and send messages to the secure element 116 according to the standard test instruction set. The secure element 116 may generate a modified message based on the message from the digital key framework 114, and provide the modified message from the secure element 116 to the device under test 112 to evaluate the digital key functionality.

[0037] The standard test instruction set may be received from the digital key test manager device 110 or generated at the device test application 134 , such as receiving a message from the digital key test manager device 110 to generate the result of the standard test instruction set.

[0038] The digital key test manager device 110 may generate standard DK instructions for the device test application 134 to send messages to the device under test 112. The digital key test manager device 110 may communicate with the device under test 112 to determine the operation of the device under test 112, and as a result of the message, the operation of the device under test 112 is evaluated at the digital key test manager device 110 to assess digital key functionality.

[0039] The digital key test manager device 110 may provide this standard test instruction set as part of a first phase test that does not require a connection to a server, and have a second phase test that includes providing additional standard DK instructions, requiring a connection to a server.

[0040] As discussed below Figure 1D As shown in , the digital key test manager device 110 can perform user interface (UI) testing for original equipment manufacturers (OEMs), native application applet testing for security elements 116, and manual step instructions for test step instruction applications.

[0041] Figure 1B1 is a conceptual diagram illustrating a device test application 134, a digital key test manager device 110, a sniffer module 136, a radio frequency (RF) jammer 137, and a mechanical fixture 138 according to one or more techniques of the present disclosure. The sniffer module 136 can be used to detect wireless signals between the computing device 102 and the device under test 112. The radio frequency (RF) jammer 137 can be used to interfere with signals from the computing device 102 to the device under test 112 to test error handling and recovery. The mechanical fixture 138 can be a mechanical arm that is used to tap a mobile phone such as the computing device 102 on a wireless communication module such as a near field communication (NFC) reader, an ultra-wideband (UWB), a personal area network, a wireless network, or a cellular network. For example, the mechanical fixture 138 can move the computing device near and away from the wireless communication module. The digital key test manager device 110 can control the sniffer module 136, the radio frequency (RF) jammer 137, and the mechanical fixture 138.

[0042] Figure 1C is a conceptual diagram illustrating a device test application and a digital key test manager device showing a user interface (UI) test, according to one or more techniques of this disclosure. Figure 1C The digital key test manager device 110 is shown connected to the device test application 134 through a standardized DK device test API, and to a device under test 112 such as a vehicle simulation, a vehicle test bench using vehicle components, or a real vehicle through a standardized DK vehicle test API.

[0043] Figure 1D 1 is a conceptual diagram illustrating a digital key test manager apparatus with test extensions according to one or more techniques of the present disclosure. System test 142 may be a system test plan through a standardized API. Digital key (DK) applet test 144 may allow testing of applications (applets) running on a secure element 116. The DK test manager may send DK applet commands that are routed to the secure element 116 without any framework logic. This allows applet testing in a production environment.

[0044] The user interface tests 146 allow testing of UI elements of DK applications such as the OEM digital key application 130 and the native digital key application 132. The user interface tests 146 may be maintained by application developers to test the user interfaces of the OEM digital key application 130 and the native digital key application 132.

[0045] Manual system testing 148 may be provided by a UI-based application that implements vehicle simulation control. A vehicle operator may use the test step instruction application 140 to step through manual test steps.

[0046] Figure 1E 2 is a conceptual diagram illustrating a device test application 234 and a digital key test manager device 110 according to one or more techniques of the present disclosure. The digital key test manager device 110 may use a standard test API to implement a unified test system. The digital key test manager device 110 may use a common test set 260 to test various devices under test and computing devices that implement the standard API. The digital key test manager device 110 may use test interfaces 162A, 162B, and 162C and device transmission 164, mechanical fixture transmission 166, and vehicle transmission 168 to transmit test instructions to the computing device 102, the mechanical fixture 138, and the device under test 112. The device under test 112 may also implement a transmission interface 170 to interface with the digital key test manager device 110.

[0047] Test interfaces 162A, 162B, and 162C may translate test 160 into a standard API format. Device transport 164, mechanical fixture transport 166, and vehicle transport 168 may implement standard or proprietary transport functionality expected by computing device 102, mechanical fixture 138, and device under test 112, respectively. Transport interface 170 at device under test 112 may also implement standard or proprietary transport functionality with digital key test manager device 110.

[0048] Test 160 may include testing functionality, such as testing configuration, log collection, crash reporting, starting owner pairing test, sharing key test, screen lock / unlock test, restart test, delete key test, digital key function reset test, engine start test and / or door open / close test. The start owner pairing test can test the functionality of the owner pairing with the digital key. The shared key test can test sharing the digital key with another device or user. The screen lock / unlock test can test whether the digital key works correctly with respect to any requirements for unlocking the screen for digital key operation (e.g., requiring the phone to be unlocked before using the digital key). The restart test can test whether the digital key operates correctly after restarting. The delete key test can test whether the digital key can be deleted from the computing device 102. The engine start test can be used to see whether the digital key can be used to start the vehicle engine or simulate the start of the vehicle engine. The door open / close test can be used to test the locking and unlocking of the vehicle doors.

[0049] Servers, such as device server 172 and vehicle server 174, can be used to perform some of the functionality of the digital key system, such as security, certificate provisioning, password provisioning, etc. This can complicate testing. Some processes require servers, such as remote termination processes, key sharing, etc., and connecting to servers requires pre-integration, such as cross-signing and connection certificates, endpoint exchange, health checks, etc.

[0050] Testing a system without a server is difficult. The security of the process relies on the server for certificate provisioning, password provisioning, etc. Some processes simply require a server, such as remote termination of processes, key sharing, etc. Connecting to the server requires pre-integration, cross-signed certificates, endpoint exchange, health checks, etc.

[0051] A multi-tier system can be implemented where the initial tier avoids the use of remote servers. In one case, Tier 1 has no server involvement. Test APIs can replace server involvement using configured passwords, standardized simulated certificates, and private keys. Logical flows such as key tracking, termination, sharing, etc. can be simulated. In Tier 2, servers can participate through test APIs. In a test environment, when the digital key test manager device 110 is connected to the device under test 112, the server can provide a test API (with simulated verification). Tier 3 can be a complete system with the same configuration and functional flows as in production, where testability APIs mostly replace user involvement.

[0052] Figure 1F is a conceptual diagram illustrating an application programming interface (API) for computing device 102 and device under test 112 in accordance with one or more techniques of this disclosure. Device test API 180 forms a standard interface for interconnecting with computing device 102. Various computing devices, such as simulation, test devices, and production devices from multiple manufacturers, may implement device test API 180 and thus facilitate a standardized testing environment.

[0053] The vehicle test API 182 forms a standard interface for interconnecting with the device under test 112. Various devices under test, such as simulations, test benches, and production vehicles from multiple manufacturers, may implement the vehicle test API 182 and thus help achieve a standardized testing environment.

[0054] The device test API 180 and the vehicle test API 182 can be used to test processes (e.g., owner pairing, key sharing, key management, screen lock / unlock, etc.) without relying on more applications, as well as testing the device under test 112, such as a vehicle simulation, a vehicle test bench using vehicle components, or a real vehicle to test vehicle actions (e.g., door open / close, engine start, window up / down, etc.)

[0055] Standardized testability APIs may include device testing APIs 180 and vehicle testing APIs 182, and further include ecosystem testability APIs. The use of standardized testability APIs makes the system independent of devices and vehicles. The testability system can be API-driven and independent of the user interface UI, so it is more stable, maintainable and automatable. Standardized domain-specific actions may include DK steps (such as owner pairing, key sharing, key management, etc.), device actions (such as screen off / on, flight mode, etc.) and vehicle actions such as door opening / closing, engine starting, window raising / lowering, etc. The standard testability API allows ecosystem system testing. Any device and any vehicle that implements the API can be tested with a universal test set. A universal shared test manager can be implemented and reused to run ecosystem standard test plans. Exemplary test APIs include general testability APIs such as Start / End Test Log Collection, Device Testability APIs such as StartOwnerPairing (pairingPassword, friendlyName, vehicleBrandId), Screen Lock / Unlock API, Restart Vehicle Testability API, ProvisionOwnerPairing (pairingPassword), Engine Start API, and Door Open / Close API.

[0056] One or more advantages of the technology described in the present disclosure include enabling the use of standardized APIs and standardized DK test managers to reduce costs by using common test criteria as part of self-validation or as a quality check before going to an external laboratory. By reducing the integration costs associated with testing, the adoption rate of digital keys for the entire ecosystem can be increased.

[0057] The standardized testability API can be independent of the type, model, brand or OEM of the device or vehicle used in production, testing or simulation. Therefore, the system can be API-driven (UI-independent), standardized, stable, maintainable and automatable. OEMs can implement test specifications and utilize shared test automation for the device under test.

[0058] Devices and vehicles that implement the API can take advantage of the automated testing system described. Lab validation can rely on the test API to achieve test automation and consistency. Further, shared test implementations can be used as a quality check before full validation. A test plan that includes automated pre-testing will result in fewer bugs found in full validation testing.

[0059] Figure 2is a block diagram illustrating an example computing device for digital key testing according to one or more aspects of the present disclosure. Figure 2 An example computing system in which the techniques of the present disclosure may be implemented is shown. Computing device 202 may include a desktop computer, a server, a mainframe, etc., and may communicate with remote computing systems via one or more networks. Many other examples of computing device 202 may be used in other situations and may include a subset of the components included in the exemplary computing device 202, or may include Figure 2 Additional components not shown.

[0060] like Figure 2 As shown in the example of , the computing device 202 includes a processor 204, one or more input / output components such as a user interface component (UIC) 206, one or more communication units 228, and one or more storage devices 208. The storage device 208 of the computing device 202 may include a device test application 234, a digital key framework 214, a native digital key application 232, an OEM digital key application 230, an operating system 250, and other applications 252.

[0061] For example, the one or more communication units 228 of the computing device 202 can communicate with external devices by sending data and / or receiving data at the computing device 202, such as sending data to and / or receiving data from a remote computer system. For example, the computing device 202 can use the communication unit 228 to receive instructions from the digital key test manager device 110 and send instructions to the external device. Figure 1A The communication unit 228 may be a device configured to send and receive signals to and from the device under test 112. Example communication units 228 include network interface cards (e.g., such as Ethernet cards), optical transceivers, radio frequency transceivers, or any other type of device that can send and / or receive information. Other examples of communication units 228 may be devices that are configured to send and receive Ultrawideband®, Bluetooth®, GPS, 3G, 4G, and Wi-Fi®, etc., as found in computing devices such as mobile devices.

[0062] like Figure 2 As shown in the example of , communication channel 231 can interconnect each of the components shown in the figure for inter-component communication (physically, communicatively, and / or operationally). In some examples, communication channel 231 can include a system bus, a network connection (e.g., to a wireless connection as described above), one or more inter-process communication data structures, or any other component for transmitting data locally or remotely between hardware and / or software.

[0063] One or more storage devices 208 within computing device 202 may store information such as data associated with applications and other data discussed herein for processing during operation of computing device 202. In some examples, one or more of storage devices 208 may be volatile or temporary memory. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, storage device 208 may also include one or more computer-readable storage media. Storage device 208 may be configured to store larger amounts of information for a longer period of time in non-volatile memory than in volatile memory. Examples of non-volatile memory include magnetic hard disks, optical disks, floppy disks, flash memory, or in the form of electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Storage device 208 may store information related to Figure 2 The device tests the program instructions and / or data associated with the application 234 , the digital key framework 214 , the native digital key application 232 , the OEM digital key application 230 , the operating system 250 and other applications 252 .

[0064] One or more I / O devices 226 of computing device 202 can receive input and generate output. Examples of input are tactile input, audio input, power input, and optical input, to name a few. In one example, the input devices of I / O devices 226 may include a touch screen, a touch pad, a mouse, a keyboard, a voice response system, a video camera, a button, a control panel, a microphone, or any other type of device for detecting input from a person or a machine. The output devices of I / O devices 226 may include a sound card, a video graphics adapter card, a speaker, a display, or any other type of device for generating output to a person or a machine.

[0065] The device test application 234 may be Figure 1A-Figure 1D The digital key framework 214 may be Figure 1A-Figure 1D The local digital key application 232 may be a version of the digital key framework 114 of the local computer. Figure 1A-Figure 1D The OEM digital key application 230 may be a version of the native digital key application 132. Figure 1A-Figure 1D Version 130 of the OEM Digital Key App

[0066] The device test application 234, the digital key framework 214, the native digital key application 232, the OEM digital key application 230, the operating system 250, and the other applications 252 may perform the operations described herein using software, hardware, firmware, or a mixture of hardware, software, and firmware that resides in and executes on the computing device 202 or is located at one or more other remote computing devices (e.g., cloud-based applications—not shown). The computing device 202 may utilize one or more processors 204 or execute one or more of the device test application 234, the digital key framework 214, the native digital key application 232, the OEM digital key application 230, the operating system 250, and the other applications 252 as a virtual machine executed on the underlying hardware or within the virtual machine. One or more of the device test application 234, the digital key framework 214, the native digital key application 232, the OEM digital key application 230, the operating system 250, and the other applications 252 may be implemented in various ways, for example, as a downloadable or pre-installed application, remotely as a cloud application, or as part of the operating system of the computing device 202. Other examples of computing devices 202 that implement the techniques of this disclosure may include Figure 2 Additional components not shown.

[0067] exist Figure 2 In the example of the embodiment of the present invention, one or more processors 204 can implement functionality and / or execute instructions within the computing device 202. For example, one or more processors 204 can receive and execute instructions that provide functionality of the UIC 206, the communication unit 228, one or more storage devices 208, and the operating system to perform one or more operations as described herein. The one or more processors 204 include a central processing unit (CPU) 224. Examples of CPU 224 include, but are not limited to: a digital signal processor (DSP), a general-purpose microprocessor, a tensor processing unit (TPU); a neural processing unit (NPU); a neural processing engine; a core of a CPU, VPU, GPU, TPU, NPU, or another processing device, an application-specific integrated circuit (ASIC), a field-programmable logic array (FPGA), or other equivalent integrated or discrete logic circuit systems or other equivalent integrated or discrete logic circuit systems.

[0068] The one or more processors 204 may implement functionality and / or execute instructions within the computing device 202. For example, the one or more processors 204 may receive and execute instructions that provide functionality for the device test application 234, the digital key framework 214, the native digital key application 232, the OEM digital key application 230, the operating system 250, and other applications 252 to perform one or more operations and various functions described herein.

[0069] like Figure 2As shown, the storage device 208 may include an operating system 250 ("OS 250") that provides an execution environment for one or more applications such as a device test application 234, a digital key framework 214, a native digital key application 232, an OEM digital key application 230, and other applications 252. OS 250 may represent a multi-threaded operating system or a single-threaded operating system. OS 250 may include a kernel that facilitates access to the underlying hardware of the computing device 202, wherein the kernel may present a plurality of different interfaces (e.g., an application programmer interface—API) that the device test application 234, the digital key framework 214, the native digital key application 232, the OEM digital key application 230, and other applications 252 may call to access the underlying hardware of the computing device 120.

[0070] Can be used with Figure 1A-Figure 1D The security element (SE) 216 corresponding to the security element 116 of the security element 116 can be a tamper-proof element, which can safely host applications and their confidential data and encrypted data (e.g., encryption keys) according to the rules and security requirements set by the trusted organization clearly identified. The security element 216 may include a CPU 254, such as a single-chip security microcontroller. When multiple applications are running on a single device, the security element 216 can host trusted applications and their associated credentials in a secure environment. The security element 216 can be used for functions such as authentication, identification, signature, and PIN management.

[0071] Figure 3 is a block diagram illustrating a digital key test manager apparatus 310 for digital key testing according to one or more aspects of the present disclosure. Figure 3 An example computing device that can implement the techniques of the present disclosure is shown. The digital key test manager device 310 can include a desktop computer, a server, a mainframe, etc., and can communicate with remote computing systems through one or more networks. Many other examples of the digital key test manager device 310 can be used in other situations and can include a subset of the components included in the digital key test manager device 310, or can include Figure 3 Additional components not shown.

[0072] like Figure 3As shown in the example of , the digital key test manager device 310 includes a processor 304, one or more input / output components such as a user interface component (UIC) 306, one or more communication units 328, and one or more storage devices 308. The storage device 308 of the digital key test manager device 310 may include a digital key test manager application 311, extensions including system tests 342, DK applet tests 344, UI tests 346, and manual system tests 348, an operating system 350, and other applications 352.

[0073] For example, the one or more communication units 328 of the digital key test manager device 310 can communicate with external devices by sending data and / or receiving data at the digital key test manager device 310, such as sending data to and receiving data from a remote computer system. For example, the digital key test manager device 310 can use the communication unit 328 to receive instructions from the digital key test manager device 110 and send instructions to the external device. Figure 1A-1E The communication unit 328 may be a device configured to send and receive signals to and from the device under test 112. Example communication units 328 include network interface cards (e.g., such as Ethernet cards), optical transceivers, radio frequency transceivers, or any other type of device that can send and / or receive information. Other examples of communication units 328 may be devices that are configured to send and receive Ultrawideband®, Bluetooth®, GPS, 3G, 4G, and Wi-Fi®, etc., as found in computing devices such as mobile devices.

[0074] like Figure 3 As shown in the example of , communication channel 331 can interconnect each of the components shown in the figure for inter-component communication (physically, communicatively, and / or operationally). In some examples, communication channel 331 can include a system bus, a network connection (e.g., to a wireless connection as described above), one or more inter-process communication data structures, or any other component for transferring data locally or remotely between hardware and / or software.

[0075] One or more storage devices 308 within the digital key test manager device 310 can store information, such as data associated with the application and other data discussed herein, for processing during operation of the digital key test manager device 310. In some examples, one or more of the storage devices 308 can be volatile or temporary memory. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, the storage device 308 can also include one or more computer-readable storage media. The storage device 308 can be configured to store larger amounts of information for a longer period of time in non-volatile memory than in volatile memory. Examples of non-volatile memory include magnetic hard disks, optical disks, floppy disks, flash memory, or in the form of electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. The storage device 308 can store information related to Figure 3 The digital key test manager application 311, extensions including system test 342, DK applet test 344, UI test 346 and manual system test 348, operating system 350 and other application 352 associated program instructions and / or data.

[0076] One or more I / O devices 326 of the digital key test manager device 310 can receive input and generate output. Examples of input are tactile input, audio input, power input, and optical input, to name a few. In one example, the input device of the I / O device 326 may include a touch screen, a touch pad, a mouse, a keyboard, a voice response system, a video camera, a button, a control panel, a microphone, or any other type of device for detecting input from a person or a machine. The output device of the I / O device 326 may include a sound card, a video graphics adapter card, a speaker, a display, or any other type of device for generating output to a person or a machine.

[0077] The digital key test manager application 311 may be Figure 1A-1E The system test 342 may be a version of the digital key test manager application 110. Figure 1D The system test 142 version. DK applet test 344 can be Figure 1D The DK applet test version 144. UI test 346 can be Figure 1D A version of UI testing 146. Manual system testing 348 can be Figure 1D Version 148 of the manual system test.

[0078] The device test application 334 may be Figure 1A-1EThe digital key framework 214 may be Figure 1A-1E The local digital key application 232 may be a version of the digital key framework 114 of the local computer. Figure 1A-Figure 1D The OEM digital key application 230 may be a version of the native digital key application 132. Figure 1A-1E Version 130 of the OEM Digital Key App.

[0079] The digital key test manager application 311, extensions including system tests 342, DK applet tests 344, UI tests 346, and manual system tests 348, operating system 350, and other applications 352 may perform the operations described herein using software, hardware, firmware, or a mixture of hardware, software, and firmware resident in and executing on the digital key test manager device 310 or located at one or more other remote computing devices (e.g., cloud-based applications—not shown). The digital key test manager device 310 may utilize one or more processors 304 or execute one or more of the digital key test manager application 311, extensions including system tests 342, DK applet tests 344, UI tests 346, and manual system tests 348, operating system 350, and other applications 352 as a virtual machine executing on underlying hardware or within the virtual machine. One or more of the digital key test manager application 311, the extensions including the system test 342, the DK applet test 344, the UI test 346, and the manual system test 348, the operating system 350, and the other applications 352 may be implemented in various ways, for example, as a downloadable or pre-installed application, remotely as a cloud application, or as part of the operating system of the digital key test manager device 310. Other examples of the digital key test manager device 310 implementing the technology of the present disclosure may include Figure 3 Additional components not shown.

[0080] exist Figure 3In the example of the digital key test manager device 310, one or more processors 304 can implement functionality and / or execute instructions within the digital key test manager device 310. For example, one or more processors 204 can receive and execute instructions that provide functionality of the UIC 306, the communication unit 328, one or more storage devices 308, and the operating system to perform one or more operations as described herein. The one or more processors 304 include a central processing unit (CPU) 324. Examples of CPU 324 include, but are not limited to: a digital signal processor (DSP), a general-purpose microprocessor, a tensor processing unit (TPU); a neural processing unit (NPU); a neural processing engine; a core of a CPU, VPU, GPU, TPU, NPU, or another processing device, an application-specific integrated circuit (ASIC), a field-programmable logic array (FPGA), or other equivalent integrated or discrete logic circuit systems or other equivalent integrated or discrete logic circuit systems.

[0081] One or more processors 304 may implement functionality and / or execute instructions within the digital key test manager device 310. For example, the one or more processors 304 may receive and execute instructions that provide functionality for the digital key test manager application 311, extensions including system tests 342, DK applet tests 344, UI tests 346, and manual system tests 348, operating system 350, and other applications 352 to perform one or more operations and various functions described herein.

[0082] like Figure 3 As shown, the storage device 308 may include an operating system 350 ("OS 350"), which provides an execution environment for one or more applications such as a digital key test manager application 311, extensions including system tests 342, DK applet tests 344, UI tests 346, and manual system tests 348, and other applications 352. OS 350 can represent a multi-threaded operating system or a single-threaded operating system. OS 350 may include a kernel that facilitates access to the underlying hardware of the digital key test manager device 310, wherein the kernel may present a plurality of different interfaces (e.g., application programmer interfaces - APIs), which the digital key test manager application 311, extensions including system tests 342, DK applet tests 344, UI tests 346, and manual system tests 348, and other applications 352 may call to access the underlying hardware of the digital key test manager device 310.

[0083] Figure 4A-4C Shows that you can use Figure 1A-1FThe system has a digital key test manager device 110, a mechanical fixture 138, a computing device 102, a device under test 112, and related test APIs, such as a device test API 180 and a vehicle test API 182. The digital key test manager device 410 corresponds to Figure 1A-1E The digital key test manager device 110. The mechanical fixing device 438 corresponds to Figure 1A-1E The computing device 402 corresponds to the mechanical fixing device 138. Figure 1A-1E The device under test 412 corresponds to the computing device 102. Figure 1A-1E The device under test 112. Figure 4A-4C The test procedures and steps are exemplary only and may be used in addition to or instead of Figure 4A-4C Use other test procedures and steps for the test process and steps. Figure 4A-4C For each test step in the test process, the digital key test manager 110 can evaluate and record whether the test step was successful or failed.

[0084] Figure 4A 4 is a flow chart illustrating an exemplary setup test case for a digital key test process according to one or more aspects of the present disclosure. In this example, the digital key test manager device 410 may send a signal to the mechanical fixation device 438 to physically move the computing device 402 away from the console reader. The digital key test manager device 410 may send a stop engine signal and a lock door signal to the device under test 412. The digital key test manager device 410 may send a kill key signal to the computing device 402 and to the device under test 412.

[0085] Figure 4B is a flow chart illustrating an exemplary owner pairing test case of a digital key testing process according to one or more aspects of the present disclosure. The digital key test manager device 410 may send a start test signal to the computing device 402 and to the device under test 412. The digital key test manager device 410 may then send a start owner pairing signal to the computing device 402 and to the device under test 412. The digital key test manager device 410 may send a signal to the mechanical fixture 438 to physically move the computing device 402 to the console reader. At this point, the digital key test manager device 410 may then send a complete owner pairing signal to the computing device 402 and to the device under test 412. The digital key test manager device 410 may then send an end test signal to the computing device 402 and to the device under test 412.

[0086] Figure 4C4 is a flow chart showing an exemplary key sharing test case of a digital key testing process according to one or more aspects of the present disclosure. In the test process, computing device 402 is the owner device, and computing device 403 is the friend device to receive the shared key. Computing device 403 may be structurally similar to Figure 1A-1E Corresponding to the computing device 102.

[0087] The digital key test manager device 410 may send a start test signal to the computing device 402, to the computing device 403, and to the device under test 412. The digital key test manager device 410 may request a shared uniform resource locator (URL) from the computing device 402 (owner device). The computing device 402 may provide the shared URL to the digital key test manager device 410. The digital key test manager device 410 may then extract the mailbox ID from the shared URL and exchange the shared URL with the computing device 403 (friend device). After the response from the computing device 403 (friend device), the digital key test manager device 410 may send a get key signal to the computing device 403 (friend device). At this point, the shared key is loaded at the computing device 403 (friend device). The digital key test manager device 410 may then activate the friend key and get the key with the device under test 412. At this point, the computing device 403 (friend device) may perform key verification with the device under test 112. The digital key test manager device 410 may then send an end test signal to the computing device 402 , to the computing device 403 , and to the device under test 412 to end the test.

[0088] Figure 5 is a flow chart illustrating an example operation of a digital key testing process 500 performed by a computing device according to one or more aspects of the present disclosure. Figure 1A-1E Description of the computing device 102 within the context of the Figure 5 operation.

[0089] The computing device 102 may provide a standard test instruction set from a device test application executed by the computing device to a digital key framework executed by the computing device, the device test application emulating a digital key application (502). The computing device 102 may generate a message for a security element according to the standard test instruction set at the digital key framework of the computing device (504). The computing device 102 may send a message for a security element from the digital key framework at the computing device to a security element at the computing device (506). The computing device 102 may generate a modified message from the security element of the computing device and based on the message from the digital key framework (508). The computing device 102 may provide the modified message from the security element of the computing device to the device under test to evaluate the functionality of the digital key (510).

[0090] Figure 6 6 is a flowchart illustrating an example operation of a digital key test process 600 performed by a digital key test manager device 110 according to one or more aspects of the present disclosure. Figure 1A-1E Description of the digital key test manager device 110 within the context of the Figure 6 operation.

[0091] The digital key test manager device 110 may provide a standard digital key command for a device test application of a computing device to send a message to a device under test (602). The digital key test manager device 110 may communicate with the device under test to determine the operation of the device under test as a result of the message (604). The digital key test manager device 110 may evaluate the operation of the device under test at the digital key test manager device to assess the functionality of the digital key (606).

[0092] This disclosure includes the following examples.

[0093] Example 1: A method for testing a digital key, comprising: providing standard digital key instructions from a digital key test manager device to a computing device to send a message to a device under test; communicating from the digital key test manager device with the device under test to determine the operation of the device under test as a result of the message; and evaluating the operation of the device under test at the digital key test manager device to assess the functionality of the digital key.

[0094] Example 2: A method as described in Example 1, wherein providing the standard digital key instructions to the computing device occurs during a first phase of testing for testing the digital key that does not require a connection to a server.

[0095] Example 3: The method as described in Example 2 further includes: providing the second stage test that requires connection to the server during the second stage test for testing the digital key.

[0096] Example 4: The method of Example 1 further comprises: receiving a signal from at least one sniffer module, the at least one sniffer module detecting communications from the computing device to the device under test.

[0097] Example 5: The method as described in Example 1 further includes: controlling a radio frequency (RF) jammer to interfere with the signal to the device under test to test error handling and recovery.

[0098] Example 6: The method of Example 1 further comprises: controlling a mechanical fixture to move the computing device close to the device under test to test the interaction between the device under test and the computing device.

[0099] Example 7: The method of Example 1, wherein the device under test is a vehicle, a vehicle simulation, or a test bench.

[0100] Example 8: The method of Example 1 further comprises: performing a user interface (UI) test on an original equipment manufacturer (OEM) digital key application or a native digital key application at the computing device.

[0101] Example 9: The method of Example 1 further comprises: sending the manual step instruction to a test step instruction application.

[0102] Example 10: A method as described in Example 1, wherein the computing device includes a device test application that receives the standard digital key instructions from the digital key test manager device and provides messages to the device under test through a digital key framework at the computing device.

[0103] Example 11: A digital key test manager device for a digital key, comprising: a memory; and at least one processor, the at least one processor being communicatively coupled to the memory and configured to: provide standard digital key instructions to a device test application of a computing device to send a message to a device under test; communicate with the device under test to determine the operation of the device under test as a result of the message; and evaluate the operation of the device under test to assess the functionality of the digital key.

[0104] Example 12: The digital key test manager device of Example 11, wherein providing the standard digital key instructions to the computing device occurs during a first phase test for testing the digital key that does not require a connection to a server.

[0105] Example 13: The digital key test manager apparatus as described in Example 12 further comprises: providing the second phase test requiring connection to the server during the second phase test for testing the digital key.

[0106] Example 14: The digital key test manager device of Example 11, wherein the at least one processor is further configured to receive a signal from at least one sniffer module that detects communications from the computing device to the device under test.

[0107] Example 15: The digital key test manager device of Example 11, wherein the at least one processor is further configured to control a radio frequency (RF) jammer to interfere with a signal to the device under test to test error handling and recovery.

[0108] Example 16: The digital key test manager device of Example 11, wherein the at least one processor is further configured to control a mechanical fixture to test the device under test.

[0109] Example 17: The digital key test manager device as described in Example 11, wherein the device under test is a vehicle, a vehicle simulation, or a test bench.

[0110] Example 18: The digital key test manager device of Example 11, wherein the at least one processor is further configured to perform a user interface (UI) test on an original equipment manufacturer (OEM) application or a native application at the computing device.

[0111] Example 19: The digital key test manager device of Example 11, wherein the at least one processor is further configured to send the manual step instruction to the test step instruction application.

[0112] Example 20: The digital key test manager device as described in Example 11 further includes a computing device, which includes a device test application, which receives the standard digital key instructions from the digital key test manager device and provides messages to the device under test through the digital key framework at the computing device.

[0113] Example 21: A computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to: provide standard digital key instructions to a device test application of a computing device to send a message to a device under test; communicate with the device under test to determine operation of the device under test as a result of the message; and evaluate the operation of the device under test to assess the functionality of the digital key.

[0114] Example 22: The computer-readable storage medium of Example 21, wherein providing the standard digital key instructions to the computing device occurs during a first phase of testing for testing the digital key that does not require a connection to a server.

[0115] Example 23: The computer-readable storage medium of Example 22 further comprises: providing the second phase test requiring connection to the server during the second phase test for testing the digital key.

[0116] Example 24: The computer-readable storage medium of Example 21, further comprising instructions for receiving a signal from at least one sniffer module that detects communications from the computing device to the device under test.

[0117] Example 25: The computer-readable storage medium of Example 21, further comprising instructions for controlling a radio frequency (RF) jammer to jam signals to the device under test to test error handling and recovery.

[0118] Example 26: The computer-readable storage medium of Example 21, further comprising instructions for controlling a mechanical fixture to move the computing device close to the device under test to test an interaction between the device under test and the computing device

[0119] Example 27: The computer-readable storage medium of Example 21, wherein the device under test is a vehicle, a vehicle simulation, or a test bench.

[0120] Example 28: The computer-readable storage medium of Example 21 further comprises instructions for performing a user interface (UI) test on an original equipment manufacturer (OEM) digital key application or a native digital key application at the computing device.

[0121] Example 29: The computer readable storage medium of Example 21, further comprising instructions for sending the manual step instructions to a test step instruction application.

[0122] Example 30: A computer-readable storage medium as described in Example 21, wherein the computing device includes a device test application that receives the standard digital key instructions from the digital key test manager device and provides messages to the device under test through a digital key framework at the computing device.

[0123] Example 31: A method, comprising: providing a standard test instruction set from a device test application executed by a computing device to a digital key framework executed by the computing device, the device test application emulating a digital key application; generating, at the digital key framework of the computing device, a message for a security element according to the standard test instruction set; sending the message for the security element from the digital key framework at the computing device to the security element at the computing device; generating a modified message by the security element of the computing device and based on the message from the digital key framework; and providing the modified message from the security element of the computing device to the device under test to assess the functionality of the digital key.

[0124] Example 32: The method described in Example 31 further includes: at the digital key framework at the computing device, generating a message for the device under test according to the standard test instruction set; and providing the message for the device under test from the digital key framework of the computing device to the device under test.

[0125] Example 33: The method of Example 31 further comprises: receiving the standard test instruction set from the digital key test manager at the device test application of the computing device.

[0126] Example 34: The method as described in Example 31 further includes: generating the standard test instruction set at the device test application of the computing device.

[0127] Example 35: The method of Example 31 further comprises: receiving, at the device test application of the computing device, a message from a digital key test manager to generate the standard test instruction set.

[0128] Example 36: A method as described in Example 31, wherein providing the standard test instruction set to the digital key framework at the computing device includes using a test application program interface (API) of the digital key framework.

[0129] Example 37: The method as described in Example 36 further includes: sending additional instructions to an original equipment manufacturer (OEM) API or a native API of the digital key framework.

[0130] Example 38: A method as described in Example 31, wherein the device under test is a vehicle, a vehicle simulation, or a test bench.

[0131] Example 39: A computing device comprising: a memory; and at least one processor, the at least one processor being communicatively coupled to the memory and configured to: provide a standard test instruction set from a device test application executed by the computing device to a digital key framework executed by the computing device, the device test application emulating a digital key application; generate, at the digital key framework of the computing device, a message for a security element according to the standard test instruction set; send the message for the security element from the digital key framework at the computing device to the security element at the computing device; generate a modified message by the security element of the computing device and based on the message from the digital key framework; and provide the modified message from the security element of the computing device to a device under test to evaluate the functionality of the digital key.

[0132] Example 40: A computing device as described in Example 39, wherein the at least one processor is further configured to: generate a message for the device under test according to the standard test instruction set at the digital key framework at the computing device; and provide the message for the device under test from the digital key framework of the computing device to the device under test.

[0133] Example 41: The computing device of Example 40, wherein the at least one processor is further configured to: receive the standard test instruction set from the digital key test manager at the device test application of the computing device.

[0134] Example 42: The computing device of Example 39, wherein the at least one processor is further configured to: generate the standard test instruction set at the device test application of the computing device.

[0135] Example 43: The computing device of Example 42, wherein the at least one processor is further configured to: receive a message from a digital key test manager at the device test application of the computing device to generate the standard test instruction set.

[0136] Example 44: A computing device as described in Example 39, wherein providing the standard test instruction set to the digital key framework at the computing device includes using a test application program interface (API) of the digital key framework.

[0137] Example 45: The computing device of Example 39, wherein the at least one processor is further configured to send additional instructions to an original equipment manufacturer (OEM) API or a native API of the digital key framework.

[0138] Example 46: The computing device of Example 39, wherein the device under test is a vehicle, a vehicle simulation, or a test bench.

[0139] Example 47: A computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors of a computing device to: provide a standard test instruction set from a device test application executed by the computing device to a digital key framework executed by the computing device, the device test application emulating a digital key application; generate, at the digital key framework of the computing device, a message for a security element based on the standard test instruction set; send the message for the security element from the digital key framework at the computing device to the security element at the computing device; generate a modified message by the security element of the computing device and based on the message from the digital key framework; and provide the modified message from the security element of the computing device to a device under test to evaluate digital key functionality.

[0140] Example 48: The computer-readable storage medium as described in Example 47 further includes instructions, which, when executed, cause one or more processors of the computing device to generate a message for the device under test at the digital key framework at the computing device according to the standard test instruction set; and provide the message for the device under test from the digital key framework of the computing device to the device under test.

[0141] Example 49: The computer-readable storage medium as described in Example 48 further includes instructions that, when executed, cause one or more processors of the computing device to receive the standard test instruction set from the digital key test manager at the device test application of the computing device.

[0142] Example 50: The computer-readable storage medium of Example 48, further comprising instructions that, when executed, cause one or more processors of the computing device to: generate the standard test instruction set at the device test application of the computing device.

[0143] Example 51: The computer-readable storage medium as described in Example 47 further includes instructions that, when executed, cause one or more processors of the computing device to: receive a message from the digital key test manager at the device test application of the computing device to generate the standard test instruction set.

[0144] Example 52: The computer-readable storage medium as described in Example 47 further includes instructions that, when executed, cause one or more processors of a computing device to provide the standard test instruction set to the digital key framework at the computing device, including using a test application program interface (API) of the digital key framework.

[0145] Example 53: The computer-readable storage medium as described in Example 47 further includes instructions that, when executed, cause one or more processors of the computing device to send additional instructions to an original equipment manufacturer (OEM) API or a native API of the digital key framework.

[0146] Example 54: The computer-readable storage medium of Example 47, wherein the device under test is a vehicle, a vehicle simulation, or a test bench.

[0147] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or sent through a computer-readable medium as one or more instructions or codes and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium corresponding to: a tangible medium, such as a data storage medium; or a communication medium, including, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. In this manner, a computer-readable medium may generally correspond to (1) a non-transitory tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in the present disclosure. A computer program product may include a computer-readable medium.

[0148] By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, flash memory, or any other storage medium that can be used to store the required program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves are used to send instructions from a website, server, or other remote source, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other temporary media, but rather relate to non-temporary tangible storage media. As used herein, disks and optical disks include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and blue-ray disks, wherein disks typically reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination should also be included in the scope of computer-readable media.

[0149] Instructions may be executed by one or more processors such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein may refer to any of the aforementioned structures or any other structures suitable for implementing the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules. In addition, the techniques may be fully implemented in one or more circuits or logic elements.

[0150] The techniques of the present disclosure may be implemented in a wide variety of devices or equipment, including wireless telephones, integrated circuits (ICs) or IC sets (e.g., chipsets). Various components, modules, or units are described in the present disclosure to emphasize the functional aspects of devices configured to perform the disclosed techniques, but the various components, modules, or units are not necessarily required to be implemented by different hardware units. Instead, as described above, the various units may be combined in a hardware unit, or provided by a collection of interoperable hardware units including one or more processors as described above in combination with appropriate software and / or firmware.

[0151] It should be appreciated that, depending on the embodiment, certain actions or events of any of the methods described herein may be performed in a different order, may be added, combined, or omitted entirely (e.g., not all of the actions or events described are necessary for the practice of the method). In addition, in some embodiments, actions or events may be performed simultaneously, for example, by multithreading, interrupt handling, or multiple processors, rather than sequentially.

[0152] In some examples, computer-readable storage media include non-transitory media. The term "non-transitory" indicates that the storage medium is not embodied in a carrier wave or propagating signal. In some examples, non-transitory storage media can store data that can change over time (e.g., in RAM or cache).

[0153] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for testing a digital key, include: providing a standard digital key command from a digital key test manager device to a computing device to send a message to a device under test; communicating from the digital key test manager device to the device under test to determine operation of the device under test as a result of the message; as well as The operation of the device under test is evaluated at the digital key test manager device to assess functionality of the digital key.

2. The method of claim 1, wherein providing the standard digital key instructions to the computing device occurs during a first phase of testing for testing the digital key that does not require a connection to a server.

3. The method of claim 2, further comprising: include: The second phase test requiring connection to the server is provided during the second phase test for testing the digital key.

4. The method according to any one of claims 1 to 3, further comprising: include: A signal is received from at least one sniffer module that detects communications from the computing device to the device under test.

5. The method according to any one of claims 1 to 4, further comprising: include: A radio frequency (RF) jammer is controlled to interfere with the signal to the device under test to test error handling and recovery.

6. The method according to any one of claims 1 to 5, further comprising: include: A mechanical fixture is controlled to move the computing device close to the device under test to test an interaction between the device under test and the computing device.

7. The method according to any one of claims 1 to 6, wherein the device under test is a vehicle, a vehicle simulation or a test bench.

8. The method according to any one of claims 1 to 7, further comprising: include: A user interface (UI) test is performed on an original equipment manufacturer (OEM) digital key application or a native digital key application at the computing device.

9. The method according to any one of claims 1 to 8, further include: Sends manual step instructions to the Test Step Instructions app.

10. A method as described in any one of claims 1 to 9, wherein the computing device includes a device test application, which receives the standard digital key instructions from the digital key test manager device and provides messages to the device under test through a digital key framework at the computing device.

11. A digital key test manager device for a digital key, comprising components for executing any combination of the methods of claims 1-10.

12. A non-transitory computer-readable medium encoded with instructions for performing any combination of the methods of claims 1-10.

Images