Development environment device, device control method and program

Abstract

A development environment device comprises a software-defined radio that processes data from a target device and a device control unit that controls the operation of the target device based on an output from the software-defined radio. The software-defined radio is configured to decode data corresponding to an output signal from the tuner, transmitted by the device environment over the communication network, and to output the decoded data to the device control unit. The device control unit is configured to determine, based on the data transmission rate in the communication network, whether the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped, and if it is determined that the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped, to send a stop command to the device environment.

Description

Technical field

[0001] The present disclosure relates to a development environment device, a device control method and a program. Technical background

[0002] Previous techniques involved device development using a virtual environment. By emulating a hardware-implemented device as software and integrating the device as a virtual device into a development environment, it is possible to test the device's operation without physical hardware.

[0003] Furthermore, device development is carried out using a development environment in which a virtual device and a hardware-implemented device, i.e., a physical device, coexist. For example, patent literature 1 discloses a system for creating a development environment that generates a development environment for software that controls a hardware-implemented target device. In patent literature 1, a local environment containing a physical device and a cloud environment comprising a system for creating a development environment are interconnected, and data is exchanged between the cloud environment and the local environment. Quotation list patent literature

[0004] Patent literature 1: JP 7 554 022 B2 Summary of the invention

[0005] The present disclosure was made taking into account the above circumstances, and one objective of the present disclosure is to improve the efficiency of device development in a virtual environment capable of data communication with a device in a physical environment.

[0006] A development environment device connected via a predetermined communication network to a device environment comprising a target device with multiple tuners, wherein the development environment device includes a software-defined radio configured to process data from the target device; and a device control unit configured to control operation of the target device based on an output from the software-defined radio. The software-defined radio is configured to decode data corresponding to an output signal from the tuner transmitted by the device environment via the communication network and to output the decoded data to the device control unit.The device control unit is designed to determine, based on the data transmission rate in the communication network, whether the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped, and to send a stop command to the device environment when it is determined that the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped.

[0007] A device control method comprises, in a predetermined communication network connecting a device environment comprising a target device with multiple tuners and a development environment device controlling the operation of the target device, determining whether to stop the output of data corresponding to an output signal from at least one of the multiple tuners based on a data transmission rate corresponding to an output signal of the tuner; and sending a stop command to the device environment when determined to stop the output of data corresponding to an output signal from at least one of the multiple tuners.

[0008] A program that causes a development environment device to execute the following processes, wherein the development environment device is connected via a predetermined communication network to a device environment comprising a target device with multiple tuners and configured to control the operation of the target device, wherein the processes include determining, based on a data transmission rate corresponding to an output signal of the tuner in the communication network, whether to stop the output of data corresponding to an output signal from at least one of the multiple tuners; and sending a stop command to the device environment when determined to stop the output of data corresponding to an output signal from at least one of the multiple tuners.

[0009] A development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner. It is determined whether an initial wait time is equal to or longer than a predetermined initial duration, where the initial wait time is the time from the transmission of a change command for a tuner receive frequency to the device environment until the device environment receives a change completion response to the change command. If the initial wait time is shorter than the initial duration, transmission and reception with the device environment are performed sequentially for multiple checks that occur when the tuner receive frequency is changed.If the first waiting time is equal to or longer than the first duration, transmission and reception during the multiple tests are skipped, and transmission and reception with the device environment are performed for a final test.

[0010] A development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner. It is determined whether a second waiting time is equal to or longer than a predetermined second duration, where the second waiting time is the time from the transmission of a measurement command for a received signal strength indicator (RSSI) to the device environment upon changing a tuner's receive frequency until the device environment receives a measurement result in response to the measurement command. If the second waiting time is shorter than the second duration, the transmission and reception for multiple tests performed upon changing the tuner's receive frequency are performed sequentially with the device environment.If the second waiting time is equal to or longer than the second duration, the transmission and reception during the multiple tests are skipped, and the transmission and reception are performed for a final test with the device environment.

[0011] A development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner. If the average waiting time from the transmission of a past command to the target device until a response to the command from the target device is less than a predetermined third of a time period, the transmission and reception for changing a tuner's receive frequency are performed with the device environment, and furthermore, the transmission and reception for several checks performed at the time of the change are performed sequentially with the device environment.If the average waiting time is equal to or longer than the third duration, the transmission and reception for the change are performed with the device environment, and furthermore, the transmission and reception during the multiple tests are omitted, and the transmission and reception are performed for a final test with the device environment.

[0012] A device control method executed by a development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein the device control method comprises: determining whether an initial wait time is equal to or longer than a predetermined initial duration, the initial wait time being the duration from the transmission of a change command for a receive frequency of the tuner to the device environment until the receipt of a change completion response to the change command from the device environment; sequentially executing, if the initial wait time is shorter than the initial duration, transmit and receive for several checks performed with the device environment when changing the receive frequency of the tuner;and omitting the transmission and reception during the multiple tests and performing the transmission and reception for a final test with the device environment if the first waiting time is equal to or longer than the first duration.

[0013] A program that causes a development environment device to execute the following processes, wherein the development environment device is connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein the processes comprise: determining whether an initial wait time is equal to or longer than a predetermined initial duration, wherein the initial wait time is the duration from the transmission of a change command for a receive frequency of the tuner to the device environment until the receipt of a change completion response to the change command from the device environment; sequentially executing, if the initial wait time is shorter than the initial duration, transmit and receive for several checks performed with the device environment when changing the receive frequency of the tuner;and omitting the transmission and reception during the multiple tests and performing the transmission and reception for a final test with the device environment if the first waiting time is equal to or longer than the first duration.

[0014] Any combination of the above-mentioned components and any transformation of an expression of the present disclosure between a method, a device, a system, a storage medium, a computer program and the like shall also be effective in an aspect of the present disclosure.

[0015] According to the present disclosure, it is possible to improve the efficiency of device development in a virtual environment capable of data communication with a device in a physical environment. Brief description of the drawings Fig. Figure 1 is a block diagram illustrating an example of the design of a device development system according to a first embodiment; Fig. Figure 2 is a flowchart illustrating a first example of a process for reducing the transmission rate according to the first embodiment; Fig. Figure 3 is a schematic diagram illustrating the role of a tuner performing a backsearch according to the first embodiment; Fig. Figure 4 is a flowchart illustrating a second example of the transmission rate reduction process according to the first embodiment; Fig. Figure 5 is a schematic diagram illustrating an example of a method for reducing the transmission rate according to the first embodiment; Fig. Figure 6 is a block diagram illustrating an example of the design of a device development system according to a second embodiment; Fig. Figure 7 is a sequence diagram of a search process in the prior art; Fig. 8 is a flowchart illustrating a first example of a search process according to the second embodiment; Fig. Figure 9 is a flowchart illustrating a second example of the search process according to the second embodiment; and Fig. Figure 10 is a flowchart illustrating a third example of the search process according to the second embodiment. Description of the embodiments (background of the present disclosure)

[0016] As described in patent literature 1, data loss can occur during data exchange between a physical environment containing a physical device and a virtual environment for device development due to limitations in the transmission rate. Furthermore, if a delay occurs during data transmission, device development can become time-consuming. Therefore, the system for creating a development environment described in patent literature 1 offers potential for improvements in the efficiency of device development using a virtual environment, particularly regarding time and cost.

[0017] Therefore, one objective of the following embodiments is to improve the efficiency of device development in a virtual environment capable of data communication with a device in a physical environment.

[0018] In the following, embodiments in which a development environment device, a device control method, and a program are specifically disclosed according to the present disclosure are described in detail, with reference to the drawings. However, unnecessarily detailed descriptions may be omitted. For example, detailed descriptions of already known facts and repeated descriptions of essentially identical embodiments may be omitted. This serves to avoid unnecessary redundancies in the following description and to facilitate understanding by a person skilled in the art. The accompanying drawings and the following description are intended to provide a person skilled in the art with a complete understanding of the present disclosure and are not intended to limit the subject matter described in the claims.Furthermore, in the present description, the terms "first" and "second" are used only to distinguish components and the like, for the sake of simplicity, and should not be interpreted as being limited to specific components and the like. (First embodiment)

[0019] Fig. Figure 1 is a block diagram illustrating an example of the design of a device development system 1 according to a first embodiment. The device development system 1 according to the present embodiment is a system that enables a user, for example a device developer, to carry out device development using a virtual environment that is connected via a communication network to a device provided in a physical environment.

[0020] The device development system 1 comprises a computing device C1, a cloud environment 10, and a device environment 20. Each unit contained in the device development system 1 is connected via a network NW.

[0021] The computing device C1 is implemented using a general-purpose computing device such as a personal computer or a server computer. Cloud environment 10 is a virtual environment accessible via the network NW. A user can perform device development by operating the computing device C1 and utilizing various resources (described later) of cloud environment 10 via the network NW.

[0022] The computing device C1 may include a control unit, a storage unit, a communication unit, an input / output unit, and the like, all of which are not shown. The control unit (not shown) may be implemented, for example, using a central processing unit (CPU), a microprocessing unit (MPU), a digital signal processor (DSP), a graphics processing unit (GPU), or a field-programmable gate array (FPGA). The storage unit (not shown) is a memory area for storing and retaining various types of data and may be implemented, for example, by a non-volatile memory area such as read-only memory (ROM) or a hard disk drive (HDD), or a volatile memory area such as random-access memory (RAM).For example, the control unit can read and execute various data and programs stored in the memory unit to implement various functions, such as a communication function of the computing device C1.

[0023] The cloud environment 10 comprises a communication unit 11, a software-defined radio 12, and a device control unit 13. The communication unit 11 sends and receives data between the cloud environment 10 and other systems, devices, and the like. The software-defined radio 12 processes data output by a device 22, which will be described later. The device control unit 13 controls the device 22, which will be described later, over the network NW based on the data processed by the software-defined radio 12. The device control unit 13 is a so-called radio middleware.

[0024] The cloud environment 10 according to the first embodiment can be implemented as a device. A device with various functions of the cloud environment 10 according to this embodiment can be referred to below as a development environment device. The development environment device can be provided in the cloud environment 10. Similar to the computing grip C1, the development environment device can include a control unit, a storage unit, and the like (not shown). The control unit can read and execute various data and programs stored in the storage unit to implement various functions of the communication unit, the software-defined radio, and the device control unit of the development environment device.

[0025] The device environment 20 is a physical environment in which the device 22 is provided. In the present embodiment, the device 22 is assumed to be a radio device. The device 22 comprises a tuner T1, a tuner T2, and a tuner T3. Tuners T1 and T2 are connected to an antenna A1, and tuner T3 is connected to an antenna A2. The function and role of each tuner will be described later.

[0026] The device environment 20 further comprises a computing device C2. Similar to computing device C1, computing device C2 can be implemented by a general computer arrangement. In addition to a communication unit 21, computing device C2 can include a control unit, a storage unit, an input / output unit, and the like (not shown). The function of the communication unit 21 can be achieved through the interaction of a control unit and a storage unit (not shown). Computing device C2 is capable of communicating with the cloud environment 10 via the network NW. Computing device C2 transmits data output by device 22 to the cloud environment 10 via the network NW, receives data transmitted by the cloud environment 10 via the network NW, and transmits the data to device 22.It is advantageous if the computing device C2 and the device 22 are connected via an interface that enables high-speed communication, such as a Universal Serial Bus (USB).

[0027] The user can use computing device C2 instead of computing device C1 for device development. Therefore, computing device C1 can be omitted in device development system 1.

[0028] The present embodiment describes a case in which a user develops a vehicle radio. For example, a radio installed in a high-end vehicle equipped with two antennas, i.e., a high-performance vehicle, may include three tuners. In this case, two of the three tuners are used to achieve a diversity effect, and one of the three tuners is used for return search. To develop the radio that can be installed in such a high-end vehicle, a device 22 with three tuners is provided in the device environment 20. Subsequently, the user can test the device 22 in the cloud environment 10 using the software-defined radio 12 and the device control unit 13.

[0029] Antenna A1 and antenna A2 are each connected to the device 22. A signal generator (not shown) is attached to each antenna A1 and antenna A2. Accordingly, a signal of sufficient strength to test the device 22 can be transmitted from each antenna to the device 22. Each tuner of the device 22 receives a signal at a specified frequency. Tuners T1 and T2 receive a signal transmitted by antenna A1, and tuner T3 receives a signal transmitted by antenna A2. The signals transmitted from each antenna to the device 22 are assumed to be high-frequency signals, for example, in the megahertz range. Each tuner converts the received signal into an intermediate frequency (IF) signal. Each tuner further converts the IF signal into in-phase quadrature (IQ) data. The IQ data is transmitted from the device 22 to the computing device C2.The computing device C2 then transmits the IQ data over the network NW to the cloud environment 10. The conversion of the intermediate frequency band signal into the IQ data is not limited to being performed by any tuner. For example, the device 22 may also include a section with a function for converting a signal into IQ data, or the computing device C2 may be capable of performing such a function.

[0030] The communication unit 11 of the cloud environment 10 receives the IQ data transmitted by the device environment 20 via the network NW and transmits the IQ data to the software-defined radio 12. The software-defined radio 12 decodes the IQ data and converts it into a signal that conforms to the broadcast standard. The software-defined radio 12 then extracts data such as audio and information from the broadcast-standard signal and transmits the data to the device control unit 13. The device control unit 13 performs processing such as audio playback or the display of information based on the data transmitted by the software-defined radio 12. The audio, information, and the like are listened to and acknowledged by the user. If the user wishes to configure the device 22, they can instruct the device control unit 13 to transmit a command.The device control unit 13 transmits the command for the device 22 via the software-defined radio 12 or directly to the communication unit 11. The command for the device 22 from the device control unit 13, for example, a command or a control signal, is transmitted by the communication unit 11 via the network NW to the processing unit C2. Subsequently, the command for the device 22 is transmitted from the processing unit C2 to the device 22.

[0031] In this way, when performing a test or similar operation on the device 22, the IQ data required for processing by the software-defined radio 12 is transferred from the device environment 20 to the cloud environment 10. A transfer rate of 24 MB / s is assumed here. This is the transfer rate required when 2 × 10⁶ IQ data is transferred per second, one IQ data unit comprises 16 bits, and three tuners are present.

[0032] However, when data is transferred between device environment 20 and cloud environment 10 over the network NW, maintaining the required transmission rate can be challenging. To compensate for a temporary drop in the transmission rate, it is conceivable to provide a transmit buffer on the transmitting side, i.e., the communication unit 21 of device environment 20, and a receive buffer on the receiving side, i.e., the communication unit 11 of cloud environment 10. Even with these buffers in place, however, a significant reduction in the transmission rate can lead to an overflow of the transmit buffer, an exhaustion of the receive buffer, or both. In this case, processing by the software-defined radio device 12 in cloud environment 10 may be interrupted, or the software-defined radio device 12 may operate erratically, potentially leading to problems such as data loss.

[0033] In the present embodiment, if a measured transmission rate is lower than the required transmission rate, the device control unit 13 reduces the required transmission rate to such an extent that no problems arise during device development. This allows the device control unit 13 to reduce data loss or similar issues due to transmission rate limitations and improve the efficiency of device development for the user.

[0034] To reduce the required transmission rate, the device control unit 13 causes the device 22 to stop outputting data from a specific tuner among the three tuners contained in the device 22. In the present embodiment, tuner T3 is used as a sub-tuner among tuner T1, tuner T2, and tuner T3 to achieve the diversity effect. If the diversity effect is not evaluated during device development, then outputting data from tuner T3 is not strictly necessary. When the device control unit 13 stops outputting data from tuner T3, the required transmission rate is two-thirds.

[0035] Tuner T1 and tuner T2 operate while exchanging roles as follows. For example, tuner T1 receives a signal at a set frequency and tuner T2 performs a backsearch, or tuner T2 receives a signal at a set frequency and tuner T1 performs a backsearch. Receiving a signal at a set frequency, in other words, means receiving a user-selected broadcast. If backsearching is not required in the device design, it is not necessary to output data from the tuner performing the backsearch. If the device control unit 13 stops the output of data from the tuner performing the backsearch, either tuner T1 or tuner T2, the required transmission rate can be further reduced.For example, if the device control unit 13 stops the output of data from tuner T2 and tuner T3, the required transmission rate is one third of the originally required transmission rate.

[0036] Next, a first example of a process for reducing the transmission rate according to the first embodiment will be given with reference to Fig. 2 described. Fig. Figure 2 is a flowchart illustrating the first example of the process for reducing the transmission rate according to the first embodiment. Each process of the in Fig. The flowchart shown in Figure 2 can, for example, be executed by the device control unit 13 of the cloud environment 10 when a user operates the computing device C1. The following description assumes that the device control unit 13 executes each process in the flowchart shown in Figure 2. Fig. The process is carried out as shown in flowchart 2. Furthermore, it is assumed that a transfer rate of 24 MB / s is required for device development.

[0037] The device control unit 13 measures an average transmission rate between the device environment 20 and the cloud environment 10 (step S100). For example, the device control unit 13 can measure an average transmission rate over a predetermined period, which is defined in advance by a predetermined operation or the like.

[0038] The device control unit 13 determines whether the average transfer rate measured in step S100 is less than 24 MB / s (step S101). The transfer rate is not less than a certain value if it is equal to or greater than that value.

[0039] If the average transfer rate measured in step S100 is found to be at least 24 MB / s (step S101: NO), the device control unit 13 terminates the processing sequence. This is because the actual transfer rate is equal to or greater than the required transfer rate, and therefore the device control unit 13 does not need to reduce the required transfer rate.

[0040] If it is determined that the average transfer rate measured in step S100 is less than 24 MB / s (step S101: YES), the device control unit 13 determines whether the average transfer rate measured in step S100 is less than 16 MB / s (step S102).

[0041] If the average transfer rate measured in step S100 is found to be no less than 16 MB / s (step S102: NO), the device control unit 13 stops the output of data from tuner T3 to achieve the diversity effect (step S103). The device control unit 13 then terminates the processing flow. By stopping the data output from tuner T3, the required transfer rate is reduced to two-thirds of 24 MB / s, or 16 MB / s. This allows the device control unit 13 to reduce the occurrence of problems such as data loss during device development.

[0042] If the average transfer rate measured in step S100 is found to be less than 16 MB / s (step S102: YES), the device control unit 13 stops the output of data from tuner T3 to achieve the diversity effect and the output of data from the tuner performing the backsearch (step S104). The tuner performing the backsearch is either tuner T1 or tuner T2. The device control unit 13 then terminates the processing flow. By stopping the data output from two of the three tuners in the device 22, the required transfer rate is reduced to one-third of 24 MB / s, i.e., 8 MB / s. This allows the device control unit 13 to reduce the occurrence of problems such as data loss during device development.

[0043] In the present embodiment, the required transfer rate is specified as 24 MB / s. In step S101 of the in Fig. In the flowchart shown in Figure 2, the required transmission rate is used as a decision criterion. Furthermore, in step S102, the value of two-thirds of the required transmission rate was specified as a decision criterion. However, these numerical values ​​are merely examples, and the device control unit 13 can determine in step S101 whether the measured average transmission rate is below a predetermined first threshold. In step S102, the device control unit 13 can determine whether the measured average transmission rate is below a predetermined second threshold.

[0044] Next, a second example of a process for reducing the transmission rate according to the first embodiment will be presented with reference to the Fig. 3 and Fig. 4 described. Fig. Figure 3 is a schematic diagram illustrating the role of the tuner, which performs the backsearch according to the first embodiment.

[0045] The tuner, which performs the search, works while changing roles at regular time intervals. Fig. Figure 3 illustrates the operation of a tuner performing a backscan. From time t1 to time t2, the backscan tuner checks for information on alternative frequencies for a selected station. That is, the backscan tuner searches for alternative frequencies to the station currently selected by the user. From time t2 to time t3, the backscan tuner then performs other processes. These other processes might include, for example, searching for a different station than the one currently selected. The backscan tuner then performs the backscan again from time t3 to time t4 and performs other processes from time t4 to time t5. As described above, the backscan tuner alternates between searching for an alternative frequency and performing the other processes at regular intervals.In the second example of the transmission rate reduction process according to the first embodiment, the device control unit 13 stops the output of data from the tuner performing the backsearch completely or stops it for a certain period of time, depending on the measured average transmission rate, during which a process other than the search process for an alternative frequency is carried out.

[0046] Fig. 4 is a flowchart illustrating the second example of the transmission rate reduction process according to the first embodiment. Each process of the in Fig. The flowchart shown in section 4 can, for example, be executed by the device control unit 13 of the cloud environment 10 when a user operates the computing device C1. The following description assumes that the device control unit 13 executes each process in the flowchart shown in section 4. Fig. The process is carried out as shown in the flowchart 4. Furthermore, it is assumed that the required data transfer rate for device development is 24 MB / s.

[0047] The device control unit 13 measures an average transmission rate between the device environment 20 and the cloud environment 10 (step S200). For example, the device control unit 13 can measure an average transmission rate over a predetermined period, which is set in advance by a user operation or the like.

[0048] The device control unit 13 determines whether the average transfer rate measured in step S200 is less than 24 MB / s (step S201).

[0049] If the average transfer rate measured in step S200 is found to be at least 24 MB / s (step S201: NO), the device control unit 13 terminates the processing sequence. This is because the actual transfer rate is equal to or greater than the required transfer rate, and therefore the device control unit 13 does not need to reduce the required transfer rate.

[0050] If it is determined that the average transfer rate measured in step S200 is less than 24 MB / s (step S201: YES), the device control unit 13 determines whether the average transfer rate measured in step S100 is less than 16 MB / s (step S202).

[0051] If the average transfer rate measured in step S200 is found to be no less than 16 MB / s (step S202: NO), the device control unit 13 stops the output of data from tuner T3 to achieve the diversity effect (step S203). The device control unit 13 then terminates the processing flow. By stopping the data output from tuner T3, the required transfer rate is reduced to two-thirds of 24 MB / s, or 16 MB / s. This allows the device control unit 13 to reduce the occurrence of problems such as data loss during device development.

[0052] If it is determined that the average transfer rate measured in step S200 is less than 16 MB / s (step S202: YES), the device control unit 13 determines whether the average transfer rate measured in step S200 is less than 12 MB / s (step S204).

[0053] If it is determined that the average transmission rate measured in step S200 is not less than 12 MB / s (step S204: NO), the device control unit 13 stops the output of data from tuner T3 to achieve the diversity effect and the output of data from the tuner performing the backsearch for a specified period (step S205). The tuner performing the backsearch is either tuner T1 or tuner T2. Here, the specified period is a timeframe during which the tuner performing the backsearch is performing a process other than searching for an alternative frequency to the currently selected transmit frequency. In other words, the device control unit 13 does not stop the output of data from the tuner performing the backsearch during a period in which the tuner is searching for an alternative frequency to the currently selected transmit frequency.This allows the device control unit 13 to reduce the required transmission rate and at the same time enable the tuner performing the search to look for an alternative frequency to the currently selected transmit frequency.

[0054] If the average transfer rate measured in step S200 is found to be less than 12 MB / s (step S204: YES), the device control unit 13 stops the output of data from tuner T3 to achieve the diversity effect and the output of data from the tuner performing the backsearch (step S206). The backsearch tuner is either tuner T1 or tuner T2. The device control unit 13 then terminates the processing flow. By stopping the data output from two of the three tuners in the device 22, the required transfer rate is reduced to one-third of 24 MB / s, i.e., 8 MB / s. This allows the device control unit 13 to reduce the occurrence of problems such as data loss during device development.

[0055] In step S201 of the Fig. In the flowchart shown in Figure 4, the required transmission rate is used as a decision criterion. Furthermore, in step S204, half the required transmission rate was described as a decision criterion. However, these numerical values ​​are merely examples, and the device control unit 13 can determine in step S204 whether the measured average transmission rate is below a predetermined third threshold.

[0056] Next, with reference to Fig. 5 describes a method for reducing the required transmission rate by reducing the number of bits of IQ data to be transferred from the device environment 20 to the cloud environment 10. Fig. Figure 5 is a schematic diagram illustrating an example of the method for reducing the transmission rate according to the first embodiment.

[0057] To illustrate, show Fig. Figure 5 is an example where a piece of IQ data is transferred from tuner T1 to the software-defined radio 12. In the prior art, 16-bit data is first transferred from tuner T1 to communication unit 21 in the device environment 20. The 16-bit data is then transferred from communication unit 21 of device environment 20 via the network NW to communication unit 11 of cloud environment 10. Finally, the 16-bit data is transferred from communication unit 11 to the software-defined radio 12 in cloud environment 10.

[0058] Next, a case is described in which the device control unit 13 reduces the required transmission rate. To reduce the required transmission rate, when transferring 16-bit data from the device environment 20 to the cloud environment 10, the device control unit 13 instructs the communication unit 21 to transmit the upper 8 bits of the data without the lower 8 bits. Accordingly, 8-bit data is transmitted from the device environment 20 to the cloud environment 10 over the network NW. Therefore, the required transmission rate is reduced. If the originally required transmission rate is 24 MB / s, changing the data to be transmitted from 16 bits to 8 bits reduces the required transmission rate to 12 MB / s. The communication unit 11 of the cloud environment 10 receives the 8-bit data.Communication unit 11 sets the received 8 bits as the upper part of the 16-bit data and sets each of the 8 bits of the lower part of the 16-bit data to 0. Accordingly, communication unit 11 receives 16-bit data in which the lower 8 bits are each set to 0. Communication unit 11 transmits the 16-bit data to software-defined radio 12. Software-defined radio 12 receives the 16-bit data in which the lower 8 bits are each set to 0.

[0059] The upper 8 bits of the data received by the software-defined radio 12 are identical to the upper 8 bits of the data output by the tuner T1. However, since each of the lower 8 bits of the data received by the software-defined radio 12 is 0, the accuracy of the data is reduced. In particular, the sound quality deteriorates. At this point, it is possible to reduce the deterioration of the sound quality to such an extent that no problems arise during device development by sending a signal of sufficient level from the antenna A1 to the tuner T1.

[0060] Fig. Figure 5 shows an example where the upper 8 bits of 16-bit data are transmitted. However, the present invention is not limited to this, and the device control unit 13 can further reduce the required transmission rate by further reducing the number of bits to be transmitted.

[0061] The method for reducing the number of data bits to be transferred from the device environment 20 to the cloud environment 10 can be combined with the method for stopping data output from a specific tuner, as described in relation to Fig. 2, Fig. 4 or similar. (Summary of the first embodiment)

[0062] The above description of the first embodiment discloses at least the following embodiments. Components corresponding to those in the first embodiment are shown in parentheses, but the present disclosure is not limited thereto. (Version 1)

[0063] A development environment device (for example, a cloud environment 10) connected via a predetermined communication network (for example, a network NW) to a device environment (for example, a device environment 20) comprising a target device (for example, a device 22) with multiple tuners (for example, tuner T1, tuner T2, tuner T3), wherein the development environment device comprises: a software-defined radio (for example, software-defined radio 12) configured to process data from the target device; and a device control unit (for example,Device control unit 13), which is configured to control the operation of the target device based on an output from the software-defined radio, wherein the software-defined radio is configured to decode data corresponding to an output signal from the tuner transmitted by the device environment via the communication network and to output the decoded data to the device control unit, and wherein the device control unit is configured to determine, based on a transmission rate of the data in the communication network, whether the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped, and if it is determined to stop the output of data corresponding to an output signal from at least one of the multiple tuners, to send a stop command to the device environment.

[0064] Accordingly, the development environment device, which is capable of data communication with the device environment in which the device is deployed, can limit a portion of the device's output based on the data transfer rate between the device environment and the development environment device. As a result, the transfer rate required for device development on the development environment device is reduced, and the efficiency of device development is improved. (Version 2)

[0065] In the development environment device according to embodiment 1, one of the several tuners is a sub-tuner to obtain a diversity effect with the other tuners, and the device control unit can be configured to transmit to the device environment the command to stop the output of data corresponding to an output signal from the sub-tuner when the transmission rate is below a predetermined first threshold.

[0066] For example, if a function is not required to achieve a diversity effect during a device development test, the development environment device can stop the function according to the measured data rate. Accordingly, the development environment device can reduce the data rate required for device development. (Version 3)

[0067] In the development environment device according to embodiment 2, one of the several tuners is a backsearch tuner, and the device control unit can be configured to send a command to stop the output of data corresponding to an output signal from the backsearch tuner to the device environment when the transmission rate is below a predetermined second threshold that is smaller than the first threshold.

[0068] For example, if a lookup is not required in a test for device development, the development environment device can stop the function according to the measured data rate. Accordingly, the development environment device can reduce the data rate required for device development. (Version 4)

[0069] In the development environment device according to embodiment 3, the backsearch tuner can perform a search process to find an alternative frequency of a currently selected broadcast and a different operation than the search process, and the device control unit can be configured to send to the device environment, when the transmission rate is less than the second threshold and equal to or greater than a predetermined third threshold that is less than the second threshold, the command to stop the output of data corresponding to an output signal during a period in which the backsearch tuner is performing a process other than the search process, and when the transmission rate is less than the third threshold, the command to stop the output of data corresponding to an output signal from the backsearch tuner to the device environment.

[0070] This allows the development environment device to stop the tuner's lookup data output during a period when the tuner is performing a specific function not required for testing the device development. Consequently, the development environment device can reduce the data rate required for device development. (Version 5)

[0071] In the development environment device according to one of embodiments 1 to 4, when transmitting data corresponding to the output signal from the device environment to the development environment device, the device control unit can transmit a predetermined number of upper bits of the data excluding a predetermined number of lower bits, and the software-defined radio can receive data containing the upper bits and the predetermined number of zeros by setting each of the lower bits to zero.

[0072] Accordingly, the development environment device can reduce the data transmitted over the communication network within a range where no problems arise during device development. Therefore, the development environment device can reduce the transmission rate required for device development. (Version 6)

[0073] In the development environment device according to one of embodiments 1 to 5, the target device can be provided in a physical environment, and the development environment device can be provided in a virtual environment.

[0074] Accordingly, the device is intended for the physical environment and the development environment device for the virtual environment. (Version 7)

[0075] A device control method comprises, in a predetermined communication network connecting a device environment comprising a target device with multiple tuners and a development environment device controlling an operation of the target device, determining whether the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped based on a data transmission rate corresponding to an output signal from the tuner; and, if determined to stop the output of data corresponding to an output signal from at least one of the multiple tuners, sending a stop command to the device environment.

[0076] Accordingly, the device control method can achieve the same effects as version 1. (Version 8)

[0077] A program that causes a development environment device to perform the following processes, wherein the development environment device is connected via a predetermined communication network to a device environment comprising a target device with multiple tuners, and is configured to control the operation of the target device, wherein the processes include: determining whether to stop the output of data corresponding to an output signal from at least one of the multiple tuners based on a data transmission rate corresponding to an output signal of the tuner in the communication network; and if determined to stop the output of data corresponding to an output signal from at least one of the multiple tuners, sending a stop command to the device environment.

[0078] Accordingly, the program can achieve similar effects to execution 1. (Second embodiment)

[0079] Fig. Figure 6 is a block diagram showing an example of the configuration of a device development system 1A according to a second embodiment. In the first embodiment, an example was described in which the software-defined radio device 12 is integrated into the cloud environment 10 in the device development system 1. In contrast, in the device development system 1A according to the second embodiment, the software-defined radio device 12 is not integrated into a cloud environment 10A. In the first embodiment, the software-defined radio device 12 decodes the IQ data, while in the second embodiment, the IQ data is decoded on the device environment 20A side.Accordingly, the number of data transmissions, such as control commands, between the device control unit 13, which is a radio middleware, and a device 22A increases, and the possibility of data delays also increases.

[0080] Therefore, the second embodiment describes the configuration of the device development system 1A, which reduces the impact of data transmission delays between the device environment 20A and the cloud environment 10A during device development and improves the efficiency of device development. In the description of the device development system 1A according to the second embodiment, descriptions identical to those of the device development system 1 according to the first embodiment are simplified or omitted, and the description focuses on the differences.

[0081] Device Development System 1A comprises Computing Device C1, Cloud Environment 10A, and Device Environment 20A. Each unit contained in Device Development System 1 is connected via a network NW.

[0082] The cloud environment 10A comprises the communication unit 11 and the device control unit 13. In contrast to the cloud environment 10 according to the first embodiment, the cloud environment 10A does not include the software-defined radio 12.

[0083] The device environment 20A comprises the device 22A and the computing unit C2. The device 22A includes a tuner T4 and a decoder D1. The tuner T4 is connected to an antenna A3. A signal generator (not shown) is attached to the antenna A3, and a signal of sufficient strength is transmitted from the antenna A3 to the device 22A to test the device 22A. For the sake of simplicity, an example is shown in which the device 22A includes one tuner T4, but the device 22A can also include multiple tuners.

[0084] In the first embodiment, the IQ data is transmitted from the device environment 20 to the cloud environment 10, and the software-defined radio device 12 in the cloud environment 10 decodes the IQ data. In the second embodiment, the decoder D1 of the device 22A decodes the IQ data output by the tuner T4. The decoded data is then transmitted from the device environment 20A to the cloud environment 10A via the network NW. Since decoding is required on the device environment 20A side in the second embodiment, the number of data transmissions between the cloud environment 10A and the device environment 20A can increase compared to the first embodiment. Consequently, the probability of data delay increases. A specific example is given with reference to Fig. 7 described.

[0085] Fig. Figure 7 is a sequence diagram of a search process in the prior art. The search process is a procedure for locating a signal that satisfies a specific condition. An example, in which the device control unit 13 sends and receives data for a search process in the prior art to and from the device 22A, is given with reference to Fig. 7 described. Here, the device control unit 13 searches for a broadcast signal of a digital audio transmission.

[0086] In the prior art search process, the device control unit 13 first sends a command to the device 22A (step S300) to change the receiving frequency of tuner T4. Tuner T4 receives a signal at the set receiving frequency. Therefore, during the search process, the device control unit 13 looks for a signal that fulfills a specific condition while changing the receiving frequency of tuner T4. The range of changes to the receiving frequency, i.e., the range of frequencies that are the target of the search process, can, for example, be predefined by the user.

[0087] Device 22A, having received the command to change the receive frequency, changes the receive frequency based on the change command. Device 22A then sends a response to the device control unit 13 (step S301) indicating that the change in the receive frequency is complete. Hereinafter, the process carried out between the device control unit 13 and device 22A from step S300 to step S301 can be referred to as the "frequency change process".

[0088] The device control unit 13 receives the response regarding the change in the receive frequency from device 22A. Subsequently, the device control unit 13 sends a command to measure a receive signal strength indicator (RSSI) to device 22A (step S302).

[0089] Upon receiving the command to measure the RSSI, device 22A measures the RSSI. In short, device 22A measures the signal strength of the set receiving frequency. Device 22A then transmits the RSSI measurement result to the device control unit 13 (step S303). The process performed between device control unit 13 and device 22A from step S302 to step S303 can subsequently be referred to as the "RSSI check".

[0090] Device control unit 13 receives the RSSI measurement result from device 22A. Device control unit 13 may have a criterion to determine whether the RSSI measurement result is pass or fail. If the RSSI measurement result is fail, device control unit 13 returns to step S300 and executes the process from the frequency change process onward. Here, it is assumed that device control unit 13 determines that the RSSI measurement result is pass, and the process continues with the next step S304.

[0091] The device 22A can have the criterion to determine whether the RSSI measurement result is pass or fail, and can transmit the pass or fail result of the RSSI measurement to the device control unit 13.

[0092] The device control unit 13 transmits a command to test the synchronization of the orthogonal frequency division multiplexing (OFDM) technique to the device 22A (step S304).

[0093] Upon receiving the command to check the OFDM synchronization, device 22A checks the OFDM synchronization. In short, device 22A checks whether orthogonality between the subcarriers has been achieved. Device 22A then transmits the result of the OFDM synchronization check to the device control unit 13 (step S305). The process performed between the device control unit 13 and device 22A from step S304 to step S305 can subsequently be referred to as the "OFDM synchronization check".

[0094] Device control unit 13 receives the OFDM synchronization test result from device 22A. Device 22A can determine, based on a received signal, whether OFDM synchronization has been achieved and transmit a result to device control unit 13. Alternatively, device control unit 13 can determine whether OFDM synchronization has been achieved based on data received from device 22A. Device 22A or device control unit 13 may have a criterion for determining whether OFDM synchronization has been achieved. If the OFDM synchronization test fails, device control unit 13 returns to step S300 and executes the process from the frequency change process onward.Here, it is assumed that the device control unit 13 determines that the OFDM synchronization test result is successful, and the process continues with the next step S306.

[0095] The device control unit 13 sends a command to test the quality of the fast information channel (FIC) of the digital audio transmission to the device 22A (step S306).

[0096] Upon receiving the command to check the quality of the FIC, device 22A checks the quality of the FIC. Specifically, device 22A checks the strength or error rate of a signal transmitted via the FIC. Subsequently, device 22A transmits the result of the FIC quality check to the device control unit 13 (step S307). Hereinafter, the process carried out between the device control unit 13 and device 22A from step S306 to step S307 can be referred to as the "FIC quality check".

[0097] Device control unit 13 receives the FIC quality test result from device 22A. Device 22A may have a criterion to determine whether the FIC quality test is passed or failed. Device 22A can then transmit the pass / fail result to device control unit 13 based on these criteria. Alternatively, device control unit 13 may have its own criterion to determine whether the FIC quality test is passed or failed. In this case, device control unit 13 can determine whether the FIC quality test is passed or failed based on the data received from device 22A. If the FIC quality test is failed, device control unit 13 returns to step S300 and executes the process from the frequency change process onward.Here, it is assumed that the device control unit 13 determines that the FIC quality test result has been passed, and the process continues with the next step S308.

[0098] The device control unit 13 sends a command to test the quality of the main service channel (MSC) of the digital audio transmission to the device 22A (step S308).

[0099] Upon receiving the command to check the quality of the MSC, device 22A checks the quality of the MSC. Specifically, device 22A checks the strength or error rate of a signal transmitted via the MSC. Subsequently, device 22A transmits the result of the MSC quality check to the device control unit 13 (step S309). Hereinafter, the process performed between the device control unit 13 and device 22A from step S308 to step S309 can be referred to as the "MSC quality check".

[0100] Device control unit 13 receives the MSC quality test result from device 22A. Device 22A may have a criterion to determine whether the MSC quality test is passed or failed. Device 22A can then transmit the pass / fail result to device control unit 13 based on these criteria. Alternatively, device control unit 13 may have its own criterion to determine whether the MSC quality test is passed or failed. In this case, device control unit 13 can determine whether the MSC quality test is passed or failed based on the data received from device 22A. If the MSC quality test is failed, device control unit 13 returns to step S300 and executes the process from the frequency change process onward.For example, if the MSC quality is passed, the device control unit 13 sends a command to the device 22A to set the current frequency as the receiving frequency.

[0101] In this way, several tests are performed stepwise between cloud environment 10A and device environment 20A during the prior art search process. Data is exchanged between cloud environment 10A and device environment 20A via the network NW, and therefore the data latency increases with the frequency of data transfers. For example, if there is a data latency of 10 ms in one direction, a latency of approximately 20 ms may occur in both directions. If the data exchange is as in the example of... Fig. If step 7 is performed five times, the data latency can be around 100 ms. Such a long data latency can lead to dissatisfaction among device developers with the hardware environment in which the actual device is to be deployed. This means that problems can arise during device development.

[0102] Therefore, in its second embodiment, the device development system 1A reduces the number of data transmissions within a range where no problems arise during the user's device development. A specific example is given with reference to the Fig. 8, Fig. 9 to Fig. 10 described.

[0103] Fig. Figure 8 is a flowchart illustrating a first example of the search process according to the second embodiment. The search process is performed jointly by the device control unit 13 and the device 22A, but for simplicity, the device control unit 13 is mainly described.

[0104] First, the device control unit 13 performs a frequency change process (step S400). The device control unit 13 sends a command to change the receiving frequency to the device 22A and receives a response from the device 22A confirming that the change is complete.

[0105] The device control unit 13 determines whether the waiting time from the transmission of the change command to the device 22A until the receipt of the change response from the device 22A during the frequency change process in step S400 is equal to or longer than a predetermined first time interval (step S401). Hereinafter, the waiting time from the time of transmission of the change command by the device control unit 13 until the receipt of the change completion response during the frequency change process in step S400 can be referred to as the first waiting time. The predetermined first time interval can, for example, be predefined by the user.

[0106] First, a case is described in which the device control unit 13 determines that the first waiting time is equal to or longer than the predetermined first duration.

[0107] If it is determined that the initial waiting time is equal to or longer than the predetermined initial time interval (step S401: YES), the device control unit 13 performs the MSC quality inspection after a predetermined time interval (step S402). The predetermined time interval is explained later in conjunction with the description of step S405.

[0108] The device control unit 13 determines whether a result of the MSC quality inspection is acceptable (step S403). That is, the device control unit 13 determines whether the MSC quality has passed or failed. A case in which the result of the MSC quality inspection is acceptable is a case in which the device control unit 13 determines that the quality of the MSC is satisfactory. A case in which the result of the MSC quality inspection is not acceptable is a case in which the device control unit 13 determines that the quality of the MSC is not satisfactory.

[0109] If the result of the MSC quality check is determined to be acceptable (step S403: YES), the device control unit 13 sets the receiving frequency of device 22A to the current frequency, i.e., to the receiving frequency obtained after the change in the process from step S400 (step S404). Then the device control unit 13 terminates the processing sequence.

[0110] If the result of the MSC quality check is found to be unacceptable (step S403: NO), the device control unit 13 returns to step S400 and repeats the process. Thus, the MSC quality check, or similar, is performed at a frequency different from the current frequency.

[0111] Even if the MSC quality check result is found to be acceptable, the device control unit 13 can return to step S400 and repeat the process at a different frequency than the current one. Such settings can be optionally configured by the user performing the device development.

[0112] Next, a case is described in which the device control unit 13 determines that the first waiting time is shorter than the predetermined first duration.

[0113] If it is determined that the initial waiting time is shorter than the predetermined initial duration (step S401: NO), the device control unit 13 performs the RSSI check, the OFDM synchronization check, the FIC quality check, and the MSC quality check in that order (step S405). For simplicity, it is assumed that the RSSI check, the OFDM synchronization check, and the FIC quality check are all passed, and the device control unit 13 continues the process to the MSC quality check. Then, the device control unit 13 continues the process to step S403.

[0114] During the frequency change process in step S400 and the various tests in step S405, the device control unit 13 sends commands to the device 22A. The device control unit 13 sends these commands at a preset transmission interval. For example, the device control unit 13 can be configured to send the next command 100 ms after receiving a response to any given command. This allows the device control unit 13 to exchange data with the device 22A in a continuous cycle.

[0115] However, if the waiting time between the transmission of the command to device 22A and the device 22A's response to the command is equal to or longer than a predetermined period, the device control unit 13 can change the transmission interval of the command to device 22A. For example, the device control unit 13 can increase the transmission interval, in which commands are transmitted to device 22A, to a longer interval than the current one, starting from the next time. As a more specific example, the device control unit 13 can increase the interval from receiving the response from device 22A to transmitting the next command to device 22A from 100 ms to 1 s.

[0116] If, in step S401, the device control unit 13 determines that the initial waiting time is equal to or longer than the predetermined initial duration, the device control unit 13 extends the transmission interval at which commands are sent to the device 22A. Therefore, the predetermined duration that the device control unit 13 waits for in step S402 is a duration extended from the predetermined transmission interval. When performing each check in step S405, the device control unit 13 also sends a command to the device 22A after a predetermined time has elapsed. However, the transmission interval for the command in step S405 is a preset transmission interval. In the description of step S402 above, the phrase "after a predetermined time has elapsed" is used to emphasize that the transmission interval for the command is extended.

[0117] The description regarding the “predetermined time period” in step S402 also applies to the “predetermined time period” in step S503. Fig. 9 and the “predetermined time period” in step S602 in Fig. 10.

[0118] As with reference to Fig. As described in Figure 8, the device control unit 13 can execute the frequency change process independently of the waiting time between the transmission of a command to the device 22A and the reception of a response. If the initial waiting time is equal to or longer than the first duration, the device control unit 13 can omit transmission and reception during several checks performed when the tuner T4's receive frequency is changed. Examples of the several checks performed when the tuner T4's receive frequency is changed include, for example, the RSSI check, the OFDM synchronization check, the FIC quality check, and the MSC quality check. The device control unit 13 can then perform transmission and reception for the last check among the several checks with the device environment 20A. In the example of Figure 8, the device control unit 13 can perform transmission and reception for the last check among the several checks with the device environment 20A. Fig. 8. The device control unit 13 omits the transmission and reception for the RSSI check, the OFDM synchronization check, and the FIC quality check if the first waiting time is equal to or longer than the first duration. Then, the device control unit 13 performs the final check, i.e., the transmission and reception for the MSC quality check, with the device environment 20A. This allows the device control unit 13 to reduce the number of data transmissions and decrease the data transmission delay time during device development. Consequently, the device control unit 13 can improve the efficiency of device development.

[0119] Fig. Figure 9 is a flowchart illustrating a second example of the search process according to the second embodiment. In the description of Fig. 9 can be a part that deals with the description of Fig. 8 overlaps, can be omitted or simplified.

[0120] First, the device control unit 13 performs a frequency change process (step S500). The device control unit 13 sends a command to change the receiving frequency to the device 22A and receives a response from the device 22A confirming that the change is complete.

[0121] The device control unit 13 performs the RSSI test using the receive frequency obtained after the change in step S500 (step S501). The device control unit 13 sends a command to measure the RSSI to the device 22A and receives a measurement result from the device 22A in response to the command.

[0122] The device control unit 13 determines whether the waiting time from the transmission of the measurement command to the device 22A until the receipt of the measurement result from the device 22A during the RSSI check in step S501 is equal to or longer than a predetermined second time interval (step S502). Hereinafter, the waiting time from the moment the device control unit 13 sends the measurement command until the moment it receives the measurement result during the RSSI check in step S501 can be referred to as the second waiting time. The predetermined second time interval can, for example, be set in advance by the user.

[0123] First, a case is described in which the device control unit 13 determines that the second waiting time is equal to or longer than the predetermined second time interval.

[0124] If it is determined that the second waiting time is equal to or longer than the predetermined second time interval (step S502: YES), the device control unit 13 performs the MSC quality check after a predetermined time interval has elapsed (step S503).

[0125] The device control unit 13 determines whether a result of the MSC quality inspection is acceptable (step S504).

[0126] If the result of the MSC quality check is determined to be acceptable (step S504: YES), the device control unit 13 sets the receiving frequency of device 22A to the current frequency, i.e., to the receiving frequency obtained after the change in the process of step S500 (step S505). The device control unit 13 then terminates the processing sequence.

[0127] If the result of the MSC quality inspection is found to be unacceptable (step S504: NO), the device control unit 13 returns to step S500 and repeats the process. Even if the result of the MSC quality inspection is found to be acceptable, the device control unit 13 may return to step S500 and repeat the process.

[0128] Next, a case is described in which the device control unit 13 determines that the second waiting time is shorter than the predetermined second time interval.

[0129] If it is determined that the second waiting time is shorter than the predetermined second time interval (step S502: NO), the fixture control unit 13 performs the OFDM synchronization check, the FIC quality check, and the MSC quality check in that order (step S506). For simplicity, it is assumed that the OFDM synchronization check and the FIC quality check are all passed, and the fixture control unit 13 continues with the process up to the MSC quality check. Then, the fixture control unit 13 continues with the process to step S504.

[0130] As with reference to Fig. As described in section 9, the device control unit 13 can perform the frequency change process and the RSSI check independently of the waiting time between transmitting a command to the device 22A and receiving a response. If the second waiting time is equal to or longer than the second duration, the device control unit 13 can omit transmission and reception during several checks that are performed when the receive frequency of tuner T4 is changed. Examples of the several checks performed when the receive frequency of tuner T4 change include, for example, the OFDM synchronization check, the FIC quality check, and the MSC quality check. The device control unit 13 can then perform transmission and reception for the last check among the several checks with the device environment 20A. In the example of Fig. 9. Device control unit 13 skips the transmission and reception for the OFDM synchronization check and the FIC quality check if the second waiting time is equal to or longer than the second duration. Then, device control unit 13 performs the final check, i.e., the transmission and reception for the MSC quality check, with the device environment 20A. This allows device control unit 13 to reduce the number of data transmissions and decrease the data transmission delay time during device development. Consequently, device control unit 13 can improve the efficiency of device development.

[0131] Fig. Figure 10 is a flowchart illustrating a third example of the search process according to the second embodiment. In the description of Fig. 10 can be parts that deal with the description of Fig. 8 or the description of Fig. 9 overlap, be omitted or simplified.

[0132] The device control unit 13 determines whether the average waiting time from the transmission of a previous command to the device 22A until the response from the device 22A is equal to or greater than a predetermined third time (step S600). Examples of previous commands to the device 22A include a command to change the frequency, a command to measure the RSSI, a command to check the OFDM synchronization, a command to check the quality of the FIC, and a command to check the quality of the MSC. For example, a history of previous data transmissions between the device control unit 13 and the device 22A can be stored in the cloud environment 10A, allowing the device control unit 13 to access this history. Accordingly, the device control unit 13 can calculate the average waiting time from the transmission of the previous command to the device 22A until the response from the device 22A.

[0133] First, a case is described in which the device control unit 13 determines that the average waiting time from the transmission of the command to the device 22A until the response is equal to or longer than the predetermined third time interval.

[0134] If it is determined that the average waiting time from the transmission of the command to device 22A until the response is equal to or longer than the predetermined third time interval (step S600: YES), the device control unit 13 performs the frequency change process (step S601).

[0135] Subsequently, after a predetermined time period, the device control unit 13 performs the MSC quality check (step S602).

[0136] The device control unit 13 determines whether a result of the MSC quality inspection is acceptable (step S603).

[0137] If the result of the MSC quality check is determined to be acceptable (step S603: YES), the device control unit 13 sets the receiving frequency of device 22A to the current frequency, i.e., to the receiving frequency obtained after the change in the process of step S601 (step S604). The device control unit 13 then terminates the processing sequence.

[0138] If the result of the MSC quality inspection is found to be unacceptable (step S603: NO), the device control unit 13 returns to step S600 and repeats the process. Even if the result of the MSC quality inspection is found to be acceptable, the device control unit 13 may return to step S600 and repeat the process.

[0139] Next, a case is described in which the device control unit 13 determines that the average waiting time from the transmission of the command to the device 22A until the response is shorter than the predetermined third time interval.

[0140] If it is determined that the average waiting time from the transmission of the command to device 22A until the response is shorter than the predetermined third time interval (step S600: NO), the device control unit 13 performs the frequency change process (step S605).

[0141] The device control unit 13 then performs the RSSI check, the OFDM synchronization check, the FIC quality check, and the MSC quality check in that order (step S606). For simplicity, it is assumed that the RSSI check, the OFDM synchronization check, and the FIC quality check are all successful, and the device control unit 13 continues with the process up to the MSC quality check. The device control unit 13 then proceeds to step S603.

[0142] As with reference to Fig. As described in Figure 10, the device control unit 13 can omit the transmission and reception during the multiple checks performed when changing the receive frequency of tuner T4, based on the elapsed average waiting time from the transmission of the command to device 22A until the reception of the response. Examples of the multiple checks performed when changing the receive frequency of tuner T4 include, for example, the RSSI check, the OFDM synchronization check, the FIC quality check, and the MSC quality check. In the example of Fig.10. The device control unit 13 skips the transmission and reception for the RSSI check, the OFDM synchronization check, and the FIC quality check if the third wait time is equal to or longer than the third duration. Subsequently, the device control unit 13 performs the final check, i.e., the transmission and reception for the MSC quality check, with the device environment 20A. This allows the device control unit 13 to reduce the number of data transmissions and decrease the data transmission delay time during device development. Consequently, the device control unit 13 can improve the efficiency of device development. (Summary of the second embodiment)

[0143] The above description of the second embodiment discloses at least the following embodiments. Components corresponding to those in the second embodiment are shown in parentheses, but the present disclosure is not limited thereto. (Version 9)

[0144] A development environment device (e.g., cloud environment 10A) connected via a predetermined communication network (e.g., network NW) to a device environment (e.g., device environment 20A) that connects a target device (e.g., device 22A) to a tuner (e.g.,Tuner T4) includes, wherein it is determined whether a first waiting time is equal to or longer than a predetermined first duration, wherein the first waiting time is a duration from the transmission of a change command for a receive frequency of the tuner to the device environment until the receipt of a change completion response to the change command from the device environment, wherein, if the first waiting time is shorter than the first duration, the transmission and reception for several checks performed when changing the receive frequency of the tuner are performed sequentially with the device environment, and wherein, if the first waiting time is equal to or longer than the first duration, the transmission and reception during the several checks are omitted and the transmission and reception for a final check are performed with the device environment.

[0145] As a result, the development environment device connects to the device environment where the device is equipped with a tuner to communicate data. The development environment device can then send a command to the device to change the tuner's receive frequency. If the device's response time is equal to or longer than the predetermined time, the development environment device can omit some of the checks performed when changing the tuner's receive frequency. Consequently, the development environment device can reduce the number of data transmissions with the device environment during device development, thus improving device development efficiency. (Version 10)

[0146] In the development environment device according to embodiment 9, if the first waiting time is shorter than the first time period, an RSSI (Received Signal Strength Indicator) test, an OFDM (Orthogonal Frequency Division Multiplexing) synchronization test, an FIC (Fast Information Channel) quality test for a digital audio channel and an MSC (Main Service Channel) quality test for the digital audio channel can be performed sequentially as multiple tests, and if the first waiting time is equal to or longer than the first time period, the MSC quality test can be performed as the last test.

[0147] Accordingly, the development environment device can omit the RSSI check, the OFDM synchronization check, and the FIC quality check depending on the waiting time until a response from the device environment. (Version 11)

[0148] A development environment device, connected via a predetermined communication network to a device environment comprising a target device with a tuner, determines whether a second waiting time is equal to or longer than a predetermined second time duration.wherein the second waiting time is a duration from the transmission of a measurement command for a received signal strength indicator (RSSI) to the device environment when changing a receive frequency of the tuner until the receipt of a measurement result in response to the measurement command from the device environment, wherein, if the second waiting time is shorter than the second duration, the transmission and reception for several tests performed when changing the receive frequency of the tuner are performed sequentially with the device environment, and wherein, if the second waiting time is equal to or longer than the second duration, the transmission and reception during the several tests are omitted and the transmission and reception for a final test are performed with the device environment.

[0149] As a result, the development environment device is connected to the device environment where the device is deployed with its tuner to communicate data. The development environment device can change the tuner's receive frequency and send a command to the device to check the RSSI (Receive Frequency Sensitivity Index). If the device's response time is equal to or longer than the predetermined duration, the development environment device can skip some of the checks performed when changing the tuner's receive frequency. Consequently, the development environment device can reduce the number of data transmissions with the device environment during device development, thus improving device development efficiency. (Version 12)

[0150] A development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein, if the average waiting time from the transmission of a past command to the target device until a response to the command from the target device is less than a predetermined third time period, the transmission and reception for changing a tuner's reception frequency are performed with the device environment, and furthermore, the transmission and reception for several tests performed at the time of the change are performed sequentially with the device environment, and wherein, if the average waiting time is equal to or longer than the third time period,The transmission and reception for the change are performed with the device environment, and furthermore, the transmission and reception are omitted during the multiple tests, and the transmission and reception are performed for a final test with the device environment.

[0151] As a result, the development environment device is connected to the device environment, where the device, including the tuner, is located to enable data communication. If the average waiting time from the transmission of a previous command to the device until the device responds is equal to or greater than the predetermined duration, the development environment device can omit some of the checks performed when changing the tuner's receive frequency. Consequently, the development environment device can reduce the number of data transmissions with the device environment during device development, thus improving device development efficiency. (Version 13)

[0152] In the development environment device according to one of embodiments 9 to 12, if a waiting time from the transmission of a command to the target device until a response to the command from the target device is equal to or longer than a predetermined time period, a transmission interval in which commands are transmitted to the target device from the next time point onwards is extended to a predetermined transmission interval that is longer than the current transmission interval.

[0153] Therefore, if the development environment device sends a command to the device and the waiting time until the device responds to the command is equal to or longer than the predetermined duration, the transmission interval at which commands are sent to the device from the next time can be extended. (Version 14)

[0154] In the development environment device according to one of embodiments 9 to 13, the target device may be provided in a physical environment, and the development environment device may be provided in a virtual environment.

[0155] Accordingly, the device is deployed in the physical environment, and the development environment device is deployed in the virtual environment. (Version 15)

[0156] A device control method executed by a development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein the device control method comprises: determining whether an initial wait time is equal to or longer than a predetermined initial duration, wherein the initial wait time is the duration from the transmission of a change command for a receive frequency of the tuner to the device environment until the receipt of a change completion response to the change command from the device environment; if the initial wait time is shorter than the initial duration, sequentially executing transmit and receive for several checks performed with the device environment when changing the receive frequency of the tuner;and if the first waiting time is equal to or longer than the first duration, omit sending and receiving during the multiple tests and perform sending and receiving for a final test with the device environment.

[0157] Accordingly, the device control method can achieve the same effects as version 9. (Version 16)

[0158] A program that causes a development environment device to perform the following processes, wherein the development environment device is connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein the processes comprise: determining whether an initial wait time is equal to or longer than a predetermined initial duration, wherein the initial wait time is the duration from the transmission of a change command for a receive frequency of the tuner to the device environment until the receipt of a change completion response to the change command from the device environment; if the initial wait time is shorter than the initial duration, sequentially performing transmit and receive for several checks that are performed with the device environment when changing the receive frequency of the tuner;and if the first waiting time is equal to or longer than the first duration, omit sending and receiving during the multiple tests and perform sending and receiving for a final test with the device environment.

[0159] Accordingly, the program can achieve similar effects to version 9.

[0160] The functions of the various embodiments described above can also be implemented by processing programs and applications to implement the functions of the various embodiments described above in a system or device using a network, a storage medium or the like, wherein one or more processors in a computer of this system or device read and execute the programs.

[0161] Furthermore, the functions of the various embodiments described above can be achieved by a circuit that implements one or more functions (e.g., an application-specific integrated circuit (hereinafter referred to as "ASIC") or a field-programmable gate array (hereinafter referred to as "FPGA")).

[0162] Although the various embodiments according to the present disclosure have been described above with reference to the drawings, it is self-evident that the present disclosure is not limited to such examples. It is obvious to those skilled in the art that various modifications, corrections, replacements, additions, deletions, and equivalents are conceivable within the scope of the claims, and it should be understood that such modifications, corrections, replacements, additions, deletions, and equivalents also fall within the technical scope of the present disclosure. Furthermore, components in the embodiments described above can be freely combined within a given area without departing from the spirit of the invention. Commercial applicability

[0163] The present disclosure is useful as a development environment device, device control method, and program. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] JP 7 554 022 B2

[0004]

Claims

[1] Development environment device connected via a predetermined communication network to a device environment comprising a target device with multiple tuners, wherein the development environment device comprises: a software-defined radio designed to process data from the targeting device; and a device control unit designed to control the operation of the target device based on an output from the software-defined radio, wherein the software-defined radio is configured to decode data corresponding to an output signal of the tuner transmitted from the device environment via the communication network, and to output the decoded data to the device control unit, and wherein the device control unit is designed, to determine, based on the data transmission rate in the communication network, whether the output of data corresponding to an output signal from at least one of the several tuners should be stopped, and to send a stop command to the device environment when it is determined that the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped. [2] Development environment device according to claim 1, where one of the multiple tuners is a sub-tuner to achieve a diversity effect with the other tuners, and wherein the device control unit is configured to send the command to stop the output of data corresponding to an output signal from the sub-tuner to the device environment when the transmission rate is below a predetermined first threshold. [3] Development environment device according to claim 2, where one of the several tuners is a tuner for a reverse lookup, and wherein the device control unit is configured to send to the device environment the command to stop the output of data corresponding to an output signal from the tuner for the lookup when the transmission rate is below a predetermined second threshold which is smaller than the first threshold. [4] Development environment device according to claim 3, wherein the tuner performs a search process to find an alternative frequency of a currently selected program and a different process than the search process for the rescan, and wherein the device control unit is configured to transmit to the device environment the command to stop the output of data corresponding to an output signal during a period in which the lookup tuner is performing a process other than the lookup process, if the transmission rate is below the second threshold and equal to or greater than a predetermined third threshold that is less than the second threshold, and to transmit to the device environment the command to stop the output of data corresponding to an output signal from the lookup tuner, if the transmission rate is less than the third threshold. [5] Development environment device according to claim 1, wherein, when transmitting data corresponding to the output signal from the device environment to the development environment device, the device control unit transmits a predetermined number of upper bits of the data to the exclusion of a predetermined number of lower bits, and where the software-defined radio receives data containing the upper bits and the predetermined number of zeros by setting each of the lower bits to zero. [6] Development environment device according to any one of claims 1 to 5, where the targeting device is provided in a physical environment, and where the development environment device is provided in a virtual environment. [7] Device control methods, with: Determine, in a predetermined communication network connecting a device environment comprising a target device with multiple tuners and a development environment device controlling the operation of the target device, whether the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped based on a data transmission rate corresponding to an output signal of the tuner; and Sending a stop command to the device environment when it is determined to stop the output of data corresponding to an output signal from at least one of the multiple tuners. [8] Program that causes a development environment device to execute the following processes, wherein the development environment device is connected via a predetermined communication network to a device environment comprising a target device with multiple tuners and configured to control operation of the target device, wherein the processes comprise: Determine, based on a data transmission rate corresponding to an output signal of the tuner in the communication network, whether the output of data corresponding to an output signal from at least one of the multiple tuners should be stopped; and Sending a stop command to the device environment when it is determined to stop the output of data corresponding to an output signal from at least one of the multiple tuners. [9] Development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein it is determined whether a first waiting time is equal to or longer than a predetermined first duration, wherein the first waiting time is a duration from the transmission of a change command for a receive frequency of the tuner to the device environment until the receipt of a change completion response to the change command from the device environment, wherein, if the first waiting time is shorter than the first duration, the transmission and reception with the device environment are carried out sequentially for several tests, which are performed when the tuner's receiving frequency is changed, and where, if the first waiting time is equal to or longer than the first duration, transmission and reception are omitted during the multiple tests and transmission and reception are performed with the device environment for a final test. [10] Development environment device according to claim 9, where, if the first waiting time is shorter than the first duration, a Receive Signal Strength Indicator (RSSI) test, an Orthogonal Frequency Division Multiplexing Synchronization (OFDM) synchronization test, a Fast Information Channel (FIC) quality test for digital audio transmission, and a Main Service Channel (MSC) quality test for digital audio transmission are performed sequentially as the multiple tests, and However, if the first waiting time is equal to or longer than the first time period, the MSC quality check is carried out as the last check. [11] Development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein it is determined whether a second waiting time is equal to or longer than a predetermined second waiting time, wherein the second waiting time is a time period from the transmission of a measurement command for a received signal strength indicator (RSSI) when changing a receive frequency of the tuner to the device environment until the receipt of a measurement result in response to the measurement command from the device environment, wherein, if the second waiting time is shorter than the second duration, the transmission and reception for multiple tests performed when changing the tuner's reception frequency are carried out sequentially with the device environment, and where, if the second waiting time is equal to or longer than the second duration, the transmission and reception during the multiple tests are omitted and the transmission and reception are performed for a final test with the device environment. [12] Development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein, if the average waiting time from the transmission of a past command to the targeting device until a response to the command from the targeting device is shorter than a predetermined third time period, the transmission and reception for changing a tuner's receive frequency are performed with the device environment, and furthermore, the transmission and reception for multiple tests being performed at the time of the change are performed sequentially with the device environment, and wherein, if the average waiting time is equal to or longer than the third duration, the transmission and reception for the change are performed with the device environment, and furthermore, the transmission and reception during the multiple tests are omitted, and the transmission and reception for a final test are performed with the device environment. [13] Development environment device according to one of claims 9 to 12, wherein, if a waiting time from the transmission of a command to the target device until a response to the command from the target device is equal to or longer than a predetermined time period, a transmission interval in which commands are transmitted to the target device from the next time point in time is extended to a predetermined transmission interval which is longer than the current transmission interval. [14] Development environment device according to any one of claims 9 to 12, where the targeting device is provided in a physical environment and where the development environment device is provided in a virtual environment. [15] Device control method executed by a development environment device connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein the device control method comprises: Determine whether an initial waiting time is equal to or longer than a predetermined initial duration, wherein the initial waiting time is a duration from the transmission of a change command for a tuner receive frequency to the device environment until the receipt of a change completion response to the change command from the device environment; Sequential execution, if the first waiting time is shorter than the first duration, of transmitting and receiving for multiple tests performed when changing the tuner's receive frequency with the device environment; and Omitting the transmission and reception during the multiple tests and performing the transmission and reception for a final test with the device environment if the first waiting time is equal to or longer than the first duration. [16] Program that causes a development environment device to perform the following processes, wherein the development environment device is connected via a predetermined communication network to a device environment comprising a target device with a tuner, wherein the processes comprise: Determine whether an initial waiting time is equal to or longer than a predetermined initial duration, wherein the initial waiting time is a duration from the transmission of a change command for a tuner receive frequency to the device environment until the receipt of a change completion response to the change command from the device environment; Sequential execution, if the first waiting time is shorter than the first duration, of transmitting and receiving for multiple tests performed when changing the tuner's receive frequency with the device environment; and Omitting the transmission and reception during the multiple tests and performing the transmission and reception for a final test with the device environment if the first waiting time is equal to or longer than the first duration.

Images