Communication systems, terminal devices, and methods

Abstract

The objective is to provide a communication system, terminal device, and method that can improve user convenience. [Solution] According to the embodiment, a communication system is provided comprising a terminal device and a device connected to the terminal device. The device is equipped with a memory that stores a first program of a first form for operating the device. The terminal device is configured to load the first program of the first form from the device when the device is connected to the terminal device and to convert the first program of the first form into a first program of a second form that the terminal device can execute.

Description

Technical Field

[0001] Embodiments of the present invention relate to a communication system, a terminal device, and a method.

Background Art

[0002] For example, in a technology called IoT (Internet of Things), various services can be provided by adding (connecting) various devices such as sensor devices and control devices to edge devices connected via a cloud system and a network.

[0003] However, when adding a device to an edge device, a user needs to install a program (for example, driver software) for operating the device on the edge device, and the convenience of the user is low. Therefore, for example, it is conceivable to pre-install a mechanism for distributing or updating a necessary program from the cloud system side in the edge device. However, in a device that cannot always be connected to a network or in an environment where the communication volume and the cost thereof are limited, this method cannot be used when the size of the program is large.

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Therefore, the problem that the present invention aims to solve is to provide a communication system, terminal device, and method that can improve user convenience. [Means for solving the problem]

[0006] According to one embodiment, a communication system is provided comprising a terminal device and a device connected to the terminal device. The device is equipped with a memory that stores a first program of a first form for operating the device. The terminal device is configured to load the first program of the first form from the device when the device is connected to the terminal device and to convert the first program of the first form into a first program of a second form that the terminal device can execute. [Brief explanation of the drawing]

[0007] [Figure 1] A diagram illustrating the overview of the communication system according to the embodiment. [Figure 2] A diagram showing an example of a communication system configuration. [Figure 3] A flowchart illustrating an example of a communication system's processing procedure. [Figure 4] A diagram showing an example of a header. [Figure 5] A diagram showing an example of interface information. [Figure 6] A diagram showing an example of the combined code. [Modes for carrying out the invention]

[0008] The embodiments will be described below with reference to the drawings. First, an overview of the communication system according to this embodiment will be described with reference to Figure 1. Figure 1 shows a remote monitoring and control system for the heat exchanger of an air conditioning system 2 as an example of the communication system 1 according to this embodiment.

[0009] In the example shown in Figure 1, the air conditioning system 2 comprises a heat exchanger 2a located outdoors and an air conditioning unit 2b located indoors. The communication system 1 comprises a monitoring server 3 that provides remote monitoring services for the heat exchanger 2a, an edge device (terminal device) 10 that is communicably connected to the monitoring server 3 via a wireless communication network (e.g., an intranet), and a sensor device 20 attached to the heat exchanger 2a. Note that the monitoring server 3 shown in Figure 1 is an example of a cloud system that provides cloud services.

[0010] Figure 1 shows a scenario where, for example, a sensor device 20 equipped with a temperature sensor for measuring temperature and a sensor device 20 equipped with a pressure sensor for measuring pressure are connected to an edge device 10, and the edge device 10 and the sensor devices 20 are physically connected by signal lines. In the example shown in Figure 1, multiple sensor devices 20 attached to heat exchangers 2a are connected in parallel to the edge device 10 via a 2-wire RS485 standard communication bus (signal line bus). This enables communication between the edge device 10 and the sensor devices 20.

[0011] In this case, communication (serial communication) based on, for example, UART (Universal Asynchronous Receiver / Transmitter), SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit), Ethernet (registered trademark), CAN (Controller Area Network), and USB (Universal Serial Bus) can be performed between the edge device 10 and the sensor device 20.

[0012] The edge device 10 shown in Figure 1 corresponds to an IoT device. In the communication system 1, the edge device 10 collects sensor data such as temperature and pressure from the heat exchanger 2a used for air conditioning from the sensor device 20, and the collected sensor data is transmitted from the edge device 10 to the monitoring server 3 via the network. As a result, the monitoring server 3 can constantly monitor the sensor data (received data) transmitted from the edge device 10 and notify (warn) the user of any abnormalities in temperature or pressure (values). In this case, the user can repair or take countermeasures for the air conditioning system 2 (for example, the heat exchanger 2a) according to the notified abnormality.

[0013] Here, we consider a case where, in order to extend the remote monitoring service provided by the monitoring server 3 described above, a new sensor device 20, for example, equipped with a vibration sensor, is added to the communication system 1 (edge ​​device 10) (i.e., the sensor device 20 is newly connected to the signal line). In this case, driver software is required in the edge device 10 that communicates with the newly added sensor device 20 to operate the sensor device 20. This driver software is provided by the operating system (OS) and is initialized and made available for use after recognizing the hardware configuration at startup.

[0014] However, the driver software for the sensor device 20, which was not present when the edge device was installed, is often not pre-installed in the OS and needs to be installed on the edge device 10. The same applies to the application program that processes the data provided by the sensor device 20 equipped with a vibration sensor (reading the signal output from the vibration sensor, converting the data, and transmitting it).

[0015] When installing a program (software) such as the above-described driver software and application program, the intranet may be used. However, when using a wireless communication network such as 3G or 4G, from the perspective of bandwidth limitation and communication cost suppression, it may be impossible to transmit a large amount of data required for the installation.

[0016] In addition, for example, the edge device 10 may load and install a program stored in a USB memory. However, when the USB port of the edge device 10 is in a state where it cannot be used for purposes such as security, waterproofing, or dustproofing, operations such as temporarily stopping and removing the edge device 10 are required, and it is difficult to install a program using the USB memory.

[0017] Furthermore, since the required programs differ depending on the model of the edge device 10 and the OS operating on the edge device 10, it is necessary to prepare a program suitable for each edge device 10 for the user to install. In such a situation, it is difficult to divert programs, leading to an increase in development costs and operational complexity.

[0018] Also, it may be considered to pre-install a program on the edge device 10. However, since various sensor devices 20 can be connected to the edge device 10, the size of the entire program to be installed becomes large, and it is necessary to increase the memory capacity of the edge device 10. Such an increase in memory capacity directly leads to an increase in the cost of the edge device 10.

[0019] Furthermore, even if technologies such as virtualization and containers are applied, their images depend on the CPU architecture (instruction set of the central processing unit of a computer) of the edge device 10 and are not compatible. Also, containers need to individually hold libraries and programs required for the execution environment. Therefore, when corresponding to all CPU architectures, for example, a storage (storage area) in the order of several GB is required, and the portability decreases.

[0020] Therefore, in the present embodiment, a communication system 1 is provided that does not require the user to perform the operation of installing a program and enables the easy addition of devices (for example, sensor devices 20, etc.) to the edge device 10.

[0021] Hereinafter, referring to FIG. 2, an example of the configuration of the communication system 1 according to the present embodiment will be described. In FIG. 2, the case of adding a new sensor device 20 to the edge device 10 shown in FIG. 1 described above will be described.

[0022] The edge device 10 is equipped with a CPU 10a and a memory 10b. Further, the edge device 10 is equipped with a network interface (communication device) 10c for communicating with a system (cloud system) that provides a cloud service such as the monitoring server 3 described above.

[0023] In the edge device 10, the CPU 10a executes an OS (operating system) 10d. In the present embodiment, a WASM runtime 10e (runtime software) operates on the OS 10d. The WASM runtime 10e is a software program that provides an environment necessary when a program is executed. Specifically, it operates to execute code (program) in the WebAssembly format. WebAssembly corresponds to binary format code that can be executed at high speed on different platforms for the purpose of improving the performance of application programs operating on, for example, web browsers.

[0024] Also, in the edge device 10, a peripheral interface driver 10f operates within the OS 10d. The peripheral interface driver 10f is a program (software) for operating the peripheral interface 10g, and controls and manages the communication between the CPU 10a and the sensor device 20 (peripheral device).

[0025] The peripheral interface 10g refers to the physical and logical structure that enables communication between the CPU 10a and the sensor device 20. The peripheral interface 10g communicates with the sensor device 20 via the OS 10d and the peripheral interface driver 10f.

[0026] In this embodiment, the edge device 10 is pre-configured with a main application 10h, a device detection program 10i, and a coupling code generation program 10j, which operate on the WASM runtime 10e described above. The main application 10h is an application program that enables the edge device 10 to operate in a manner that realizes, for example, a remote monitoring service provided by the monitoring server 3. The device detection program 10i is a program for detecting sensor devices 20 added (connected) to the edge device 10. The coupling code generation program 10j is a program for generating coupling code, which will be described later.

[0027] The sensor device 20 is connected to the edge device 10 via the communication bus described above (for example, a bus conforming to the RS485 standard). The communication bus may be, for example, an I2C / SPI bus.

[0028] The sensor device 20 includes a sensor 20a and a peripheral interface 20b for communication with the edge device 10. The sensor device 20 also includes a non-volatile memory 20c connected to a communication bus.

[0029] The non-volatile memory 20c is a storage device such as flash memory or ROM, and stores a sensor driver 20d, which is a program (driver software) for operating the sensor device 20. The non-volatile memory 20c also stores an application program 20e specific to the sensor device 20 (hereinafter referred to as a device-specific application) for processing data provided by the sensor device 20 (sensor data based on signals output from sensor 20a).

[0030] The sensor driver 20d and the device-specific application 20e are stored in non-volatile memory 20c in WebAssembly format (a binary code format executable on different platforms). Furthermore, the non-volatile memory 20c also stores information 20f defining the interfaces of, for example, the sensor driver 20d and the device-specific application 20e (hereinafter referred to as interface information).

[0031] As will be described in detail later, in this embodiment, the WebAssembly-formatted sensor driver 20d and device-specific application 20e stored in the non-volatile memory 20c of the sensor device 20 are loaded into the edge device 10 and then converted into a program in a format that the edge device 10 can execute (for example, a format based on the CPU architecture of the edge device 10).

[0032] Furthermore, in this embodiment, when interface information stored in the non-volatile memory 20c of the sensor device 20 is loaded onto the edge device 10, a coupling code generation program 10j running on the edge device 10 generates coupling code based on that interface information. The coupling code is code that enables cooperation between different programs, and according to this coupling code, the sensor driver 20d and the device-specific application 20e can be executed, for example, by being called from the main application 10h running on the edge device 10 (WASM runtime 10e).

[0033] The following describes an example of the processing procedure of the communication system 1 according to this embodiment, with reference to the flowchart in Figure 3. Note that Figure 3 mainly shows the processing performed by the edge device 10.

[0034] First, when a new sensor device 20 is connected to the communication bus described above, the edge device 10 (device detection program 10i) detects the sensor device 20 (step S1). In step S1, the sensor device 20 may be detected by a response from the sensor device 20 to an ID acquisition request command from the edge device 10 at regular intervals, or, depending on the specifications of the communication bus, by the edge device 10 receiving a connection request from the sensor device 20.

[0035] When the sensor device 20 is detected in step S1, the edge device 10 sends a command (hereinafter referred to as the first read command) to the sensor device 20 (sensor 20a) to read identification information (hereinafter referred to as the sensor ID of the sensor device 20).

[0036] When the sensor device 20 receives the first read command transmitted from the edge device 10, the sensor device 20 transmits its sensor ID (code) to the edge device 10 as a response to the first read command.

[0037] In the edge device 10, the sensor ID of the sensor device 20 transmitted from the sensor device 20 is received as described above (step S2).

[0038] If the edge device 10 does not receive the sensor ID, the edge device 10 may wait until the sensor ID is received, resend the first read command, or terminate the process shown in Figure 3.

[0039] Here, the edge device 10 is assumed to manage a list (hereinafter referred to as the registered device list) containing the sensor IDs of sensor devices that have already been added to the edge device 10. A sensor device that has already been added to the edge device 10 refers to a sensor device for which, for example, a sensor driver has already been installed.

[0040] In this case, the edge device 10 compares the sensor ID received in step S2 with the registered device list (step S3). This allows the edge device 10 to determine whether the sensor device 20 whose sensor ID was received (i.e., the sensor device 20 detected in step S1) is an already registered sensor device (registered sensor device).

[0041] If the sensor ID received from sensor device 20 is registered in the registered device list, it is determined that sensor device 20 is a registered sensor device, and the process shown in Figure 3 is terminated.

[0042] On the other hand, if the sensor ID received from the sensor device 20 is not registered in the list of registered devices, the edge device 10 determines that the sensor device 20 is not a registered device, and sends a command (hereinafter referred to as the second read command) to the sensor device 20 to read the identification information (hereinafter referred to as the memory ID of the sensor device 20) for identifying the non-volatile memory 20c installed in the sensor device 20.

[0043] When the sensor device 20 receives a second read command transmitted from the edge device 10, the sensor device 20 transmits its memory ID to the edge device 10 as a response to the second read command.

[0044] In the edge device 10, the memory ID of the sensor device 20 transmitted from the sensor device 20 is received as described above (step S4).

[0045] If the memory ID is not received by the edge device 10, the edge device 10 may wait until the memory ID is received, resend the second read command, or terminate the process shown in Figure 3.

[0046] In step S4, when the memory ID of the sensor device 20 is received, the edge device 10 (device detection program 10i) detects the non-volatile memory 20c of the sensor device 20 and loads the headers of the sensor driver 20d and the device-specific application 20e stored in the non-volatile memory 20c (step S5). In step S5, it is sufficient that at least the header of the sensor driver 20d is loaded, and the header of the device-specific application 20e may be omitted.

[0047] The edge device 10 verifies the validity of the header loaded in step S5 (step S6).

[0048] Here, Figure 4 shows an example of a header loaded in step S5. While the header for the sensor driver 20d is described here, the same applies to the header for the device-specific application 20e.

[0049] As shown in Figure 4, the header 100 of the sensor driver 20d includes the first to fifth regions 101 to 105.

[0050] The first region 101 stores information (4 bytes) indicating the format of the sensor driver 20d. In the example shown in Figure 4, WASM (i.e., WebAssembly) is indicated as the format of the sensor driver 20d.

[0051] The second region 102 stores the sensor ID (4 bytes) of the sensor device 20, which is stored in the non-volatile memory 20c of the sensor driver 20d.

[0052] The third area 103 stores the sensor name (16 bytes) of the sensor device 20 (or the sensor 20a mounted on the sensor device 20).

[0053] The fourth area 104 stores the software size (4 bytes) of the sensor driver 20d.

[0054] Area 5 105 stores the digital signature (256 bytes) prepared in the sensor device 20. The digital signature (signature code) is generated, for example, by performing cryptographic processing using the private key of the sensor device 20, and corresponds to a digital signature that proves the program is legitimate.

[0055] If the header 100 described above is loaded into the edge device 10 in step S5, the validity of each of the first to fifth regions 101 to 105 contained in the header 100 is verified in step S6. Specifically, the validity of the first region 101 is verified, for example, by the fact that WASM is stored in the first region 101 in the format of the sensor driver 20d. The validity of the second to fourth regions 102 to 104 is verified, for example, by the fact that information that is presumed to be valid is stored in the second to fourth regions 102 to 104. The validity of the fifth region 105 is verified by the successful verification of the digital signature stored in the fifth region 105. The verification of the digital signature is performed, for example, based on the result of cryptographic processing of the digital signature using the public key of the sensor device 20.

[0056] If the validity of the header is not confirmed in step S6 described above, the process shown in Figure 3 is terminated.

[0057] On the other hand, if the validity of the header is confirmed in step S6, the edge device 10 loads programs such as the sensor driver 20d and the device-specific application 20e from the sensor device 20 (step S7).

[0058] In step S5, it was explained that the headers for the sensor driver 20d and the device-specific application 20e are loaded. However, the code for the program of the sensor driver 20d and the device-specific application 20e is stored in the area following the header (the first to fifth areas 101 to 105).

[0059] Furthermore, the edge device 10 loads the interface information stored in the non-volatile memory 20c of the sensor device 20 (step S8). The interface information is, for example, a text file that defines the interface specification written in WIT (WebAssembly Interface Types) format. Alternatively, the interface information may be embedded in code in WebAssembly format, for example.

[0060] Here, Figure 5 shows an example of interface information. In the example shown in Figure 5, the interface information corresponds to a WIT-format code.

[0061] In Figure 5, the first line of the interface information (WIT format code), `local:wasm_core`, indicates the package name containing the interface information. The third line of the interface information defines the `wasm_core` interface, which integrates all necessary interfaces and resources. Furthermore, the fourth line of the interface information declares a function `function()` as part of the `wasm_core` interface externally. This allows the `wasm_core` interface to be used externally. Note that in the example shown in Figure 5, the definition of function arguments is omitted.

[0062] Returning to Figure 3, the edge device 10 (coupling code generation program 10j) generates coupling code based on the interface information loaded in step S8 (step S9).

[0063] Here, Figure 6 shows an example of the combined code generated in step S9. In Figure 6 below, the combined code is shown in Javascript® format.

[0064] First, in the combined code shown in Figure 6, a function called async function loadWasmModule() is defined to load a WASM module (a program in WebAssembly format).

[0065] Here, the WASM module (file) is loaded, for example, from the non-volatile memory 20c of the sensor device 20 and output to a temporary directory in the edge device 10. In this case, the fourth line of the coupling code shown in Figure 6 indicates that a handle is prepared for accessing the WASM module located in the temporary directory from the script. Also, the sixth line of the coupling code indicates that the WASM module is placed in WebAssembly type memory.

[0066] Furthermore, line 7 of the combined code indicates the creation of a WebAssembly instance. Line 10 of the combined code indicates that the function defined in WIT is extracted from the WebAssembly instance so that it can be called externally.

[0067] Additionally, line 13 of the combined code checks if the type of the extracted function is indeed a function, and line 18 of the combined code returns the reference to the function.

[0068] Furthermore, the combined code shown in Figure 6 defines a main function for calling the loaded WebAssembly (WASM module).

[0069] Specifically, line 25 of the combined code shown in Figure 6 indicates a call to loadWasmModule(). Line 28 of the combined code indicates a call to the externally extracted function function with arguments. Furthermore, line 29 of the combined code indicates outputting the execution result of the function function. This execution result of the function function could be, for example, sensor data provided by the sensor device 20.

[0070] Returning to Figure 3, the main application 10h is executed on the edge device 10 (step S10). The execution result of the function described above is used in the main application 10h.

[0071] Here, Figure 6 above shows an example of coupling code that makes a function call from WIT information (i.e., interface information). This method of function calling makes it possible to call the sensor driver 20d and device-specific application 20e loaded from the sensor device 20 to the edge device 10 from the main application 10h.

[0072] In this embodiment, the above-described coupling code is executed on the WASM runtime 10e, which reads the initialization code of the sensor driver 20d and the device-specific application 20e. The sensor driver 20d and the device-specific application 20e then operate on the WASM runtime 10e, enabling control and access to the sensor device 20 (sensor 20a) from the edge device 10.

[0073] Specifically, the edge device 10 acquires sensor data provided by the sensor device 20 in response to requests from the main application 10h and the device-specific application 20e, processes the sensor data such as filtering and data conversion, and provides the processed data to the monitoring server 3 (cloud system).

[0074] In the example shown in Figure 3, it was explained that the sensor ID is received after the sensor device 20 is detected. However, it is also possible to configure the system to periodically send read commands equivalent to a first read command and a second read command, and to detect the sensor device 20 that provided the response (sensor ID or memory ID) when a response to such read command is received.

[0075] In this embodiment, devices can be easily added to the edge device 10. For adding such devices, a new plug-and-play method is useful, utilizing common driver software and applications that are independent of the edge device 10 model and CPU architecture, thus eliminating the need for users to install software. Plug-and-play is a technology that automatically recognizes and enables the use of a new device when it is connected to a computer, without requiring the installation or configuration of additional programs.

[0076] However, even if the interface specifications can be standardized, the program will still depend on the CPU architecture of the edge device 10 itself, making complete software standardization difficult using commonly known methods such as virtualization and containerization. Furthermore, containers have large software image sizes, making their application to the edge device 10 difficult from a cost perspective.

[0077] Taking the above into consideration, the communication system 1 according to this embodiment relates to a plug-and-play method for common driver software and applications that is independent of the model or CPU architecture of the edge device 10 when adding devices in edge computing.

[0078] Specifically, in the communication system 1 according to this embodiment, the sensor device 20 is equipped with a non-volatile memory 20c connected to a communication bus (signal line), and a sensor driver 20d in WebAssembly format and a device-specific application 20e (i.e., a program that controls the interface) are stored in the non-volatile memory 20c. In this embodiment, when a new sensor device 20 is added to the edge device 10, the sensor driver 20d and the device-specific application 20e are automatically loaded from the sensor device 20 to the edge device 10, and the WebAssembly format sensor driver 20d and device-specific application 20e are converted into a format that the edge device 10 can execute on the edge device 10's WASM runtime 10e (runtime software) (i.e., a format based on the edge device 10's CPU architecture).

[0079] This makes it possible to provide a universal edge interface plug-and-play system that enables plug-and-play functionality using a common program, regardless of the model or CPU architecture of the edge device 10, in this embodiment.

[0080] According to the communication system 1 of this embodiment as described above, even in an environment where the edge device 10 is not connected to a network, for example, the user does not need to perform any software installation work and can easily use the sensor device 20 added to the edge device 10, thereby improving user convenience.

[0081] In the example shown in Figure 1 above, simply by connecting a new sensor device 20 equipped with a vibration sensor in parallel to the RS485 signal line, the edge device 10 can detect the sensor device 20, load (read) a program from the non-volatile memory 20c installed in the sensor device 20, and start (execute) the program. Therefore, operation using the newly added sensor device 20 can be started immediately.

[0082] Furthermore, in this embodiment, the user is saved the trouble of individually installing programs, and a common program can be used regardless of the model or CPU architecture of the edge device 10. This allows for the reuse of the program (software), contributing to a reduction in the development costs of the program. In addition, the cost of the non-volatile memory 20c itself installed in the sensor device 20 is expected to be less than 1% of the cost of the installation work.

[0083] Furthermore, in this embodiment, by adding multiple devices such as the sensor device 20, functions that the edge device 10 does not originally possess can be automatically added later, making it easy to expand services provided by a cloud system such as the monitoring server 3. In other words, the program (sensor driver 20d and device-specific application 20e) stored in the non-volatile memory 20c of the sensor device 20 is in WebAssembly format and can be executed on different hardware and operating systems, resulting in high compatibility, easy functional expansion of the edge device 10, and improved system flexibility.

[0084] Furthermore, in this embodiment, interface information (a file containing the information) of the sensor driver 20d and the device-specific application 20e is loaded from the sensor device 20 added to the edge device 10. Based on this interface information, the coupling code generation program 10j generates coupling code, and the sensor driver 20d and the device-specific application 20e can be called and executed from the main application 10h using this coupling code. This eliminates the need for configuration changes or other operations to execute the program loaded from the sensor device 20 added to the edge device 10, resulting in high user convenience.

[0085] In other words, in this embodiment, by easily adding a new device such as a sensor device 20 to the edge device 10, several advantages can be realized, including improved usability, improved software reusability, cost reduction, and improved system flexibility.

[0086] In this embodiment, as described above, the coupling code generated based on the interface information is executed on the WASM runtime 10e, thereby calling the sensor driver 20d and the device-specific application 20e from the main application 10h. However, in this embodiment, it is sufficient that the WebAssembly-formatted sensor driver 20d and the device-specific application 20e are converted into a format executable on the edge device 10, and this embodiment may omit the processing related to the generation of the coupling code described above.

[0087] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims and their equivalents. [Explanation of symbols]

[0088] 1...Communication system, 2...Air conditioning system, 2a...Heat exchanger, 2b...Air conditioning unit, 3...Monitoring server, 10...Edge device (terminal device), 10a...CPU, 10b...Memory, 10c...Network interface, 10d...OS, 10e...WASM runtime, 10f...Peripheral interface driver, 10g...Peripheral interface, 10h...Main application, 10i...Device detection program, 10j...Coupling code generation program, 20...Sensor device, 20a...Sensor, 20b...Peripheral interface, 20c...Non-volatile memory, 20d...Sensor driver, 20e...Device-specific application, 20f...Interface information.

Claims

1. In a communication system comprising a terminal device and a device connected to the terminal device, The device is equipped with a memory that stores a first program of a first form for operating the device, The terminal device is configured to load the first program in the first format from the device when the device is connected to the terminal device, and to convert the first program in the first format into a first program in a second format that the terminal device can execute. Communication system.

2. The communication system according to claim 1, wherein the first form includes a binary format that can be executed on different platforms.

3. The communication system according to claim 2, wherein the second form is a form based on the CPU architecture of the terminal device.

4. The communication system according to claim 3, wherein the first program in the first form is converted into the first program in the second form by runtime software running on the terminal device.

5. The terminal device acquires interface information in which the interface of the first program of the first form is defined, and generates coupling code based on the acquired interface information. The first program is called from the main application program executed on the terminal device based on the generated coupling code. The communication system according to claim 1.

6. The memory stores a second program of a first form that processes data provided from the device, The terminal device is further configured to load the second program in the first format from the device when the device is connected to the terminal device, and to convert the second program in the first format into the second program in the second format. A communication system according to any one of claims 1 to 5.

7. The first program includes driver software for the device, The second program includes an application program specific to the device. The communication system according to claim 6.

8. In a terminal device to which a device is connected, the device is equipped with a memory for storing a first program of a first form for operating the device, When the aforementioned device is connected, a loading means for loading the first program of the first format from the device, A conversion means for converting the first program in the first format into a first program in a second format that can be executed by the terminal device, A terminal device equipped with the following.

9. A method for a communication system comprising a terminal device and a device equipped with a memory for storing a first program of a first form for operating a device connected to the terminal device, When the device is connected to the terminal device, the terminal device loads the first program of the first format from the device. Converting the first program in the first format into a first program in a second format that can be executed by the terminal device. A method that provides for this.

10. A method to be executed by a terminal device to which a device is connected, the device having a memory for storing a first program of a first form for operating the device, When the aforementioned device is connected, the first program of the first format is loaded from the aforementioned device. Converting the first program in the first format into a first program in a second format that can be executed by the terminal device. A method that provides for this.

Images