Distributed system resource discovery and task management method based on CoAP protocol

Abstract

The invention discloses a distributed system resource discovery and task management method based on a CoAP protocol, and belongs to the field of embedded and distributed communication. The method comprises the following steps: building a distributed system framework based on a CoAP protocol on a plurality of multi-core DSP (Digital Signal Processor) platforms and a PC (Personal Computer); a CoAP client is deployed on the PC, a master CoAP server is deployed on one core of each multi-core DSP platform, and slave CoAP servers are deployed on the remaining cores; the client sends a discovery request and a task management request to the main server, and updates a discovered resource list in combination with a timestamp; the main server responds to the discovery request, informs the client of current resource information, and sends a task scheduling request to the slave server of the platform and other main servers; and starting the to-be-scheduled task on the core of the slave server side. The distributed system resource discovery and task management method realizes the effects of low overhead, high speed and low load of distributed system resource discovery and task management, and has the advantage of autonomous and controllable source codes.

Description

Technical Field

[0001] The present invention belongs to the field of embedded and distributed communications, and relates to embedded device resource discovery and task management, and specifically to a distributed system resource discovery and task management method based on the CoAP (Constrained Application Protocol) protocol in a multi-core DSP (digital signal processor) environment in which a domestic operating system SylixOS is installed. Background Art

[0002] Embedded systems are lightweight, scalable, and have strong computing power. They can bring the advantages of software and hardware to the best state. As the needs become more and more complex and the processor performance becomes more and more powerful, large-scale embedded operating systems have been applied to all aspects, especially suitable for scenarios with extremely high complexity and computing requirements such as aerospace.

[0003] Due to the different time of technology development, most of the early application scenarios were based on foreign operating systems such as VxWorks and RTEMS for platform development, which was technically uncontrollable and had high security risks. With the rise of domestic RTOS (real-time operating system) technology, the current domestic embedded real-time operating system SylixOS has reached or exceeded the level of many real-time operating systems in terms of performance parameters. Research and design of application software technology based on domestic OS platforms is the general trend. However, there are still many problems: (1) The development scenario of SylixOS adapted to DSP hardware is relatively simple, and there is little relevant technical experience; (2) According to the needs of the task environment, it is necessary to solve the decoupling of application software and system hardware resources on the (1) platform, break through the limitations of the hardware platform, and realize hardware mutual assistance, multi-task scheduling, resource sharing and unified management among multi-core and multi-device. At present, there is almost no technical development in this regard; (3) The main advantage of embedded is to ensure lightweight and excellent performance. How to break through the limitations of multi-core and multi-device and realize efficient processing and analysis of multi-tasks and data requires design and implementation. Summary of the invention

[0004] The prior art lacks a distributed system resource discovery and task management method in a multi-core DSP environment where the domestic operating system SylixOS is installed. To address this gap, the present invention proposes a distributed system resource discovery and task management method based on the CoAP protocol, which is mainly based on a distributed, strong real-time architecture foundation and a network communication protocol, adapted to the domestic operating system, and realizes the perception, discovery and task management functions of nodes, devices and service resources.

[0005] The distributed system resource discovery and task management method based on the CoAP protocol of the present invention comprises the following steps:

[0006] Step 1: Build a distributed system framework based on the CoAP protocol;

[0007] In terms of hardware environment, the system consists of multiple multi-core DSP platforms and a PC interconnected by an Ethernet switch. The multi-core DSP is a discoverable resource, and each core can perform different tasks. The PC discovers resources and displays the discovered resources visually, and also issues task scheduling instructions to the multi-core DSP. In terms of software environment, the multi-core DSP is installed with the domestic operating system SylixOS, and the CoAP protocol open source implementation libcoap environment is configured on the multi-core DSP and PC. When configuring the libcoap environment, the parameters of the libcoap backoff retransmission mechanism are customized to shorten the waiting time for the requester to send the CoAP request again.

[0008] Step 2: Deploy the CoAP client on the PC; deploy the master CoAP server on one core in each multi-core DSP platform, and deploy the slave CoAP server on the remaining cores; where:

[0009] The CoAP client sends discovery requests and task management requests to the main CoAP server, and receives responses to the discovery requests and task management requests. After receiving the discovery request response, the CoAP client also stores the resource information in the discovered resource list. In addition, the CoAP client also implements a timestamp-based resource departure judgment mechanism, so that the list of discovered resources can be updated in time when the resource leaves.

[0010] The main CoAP server receives the discovery request and task management request from the CoAP client, and after receiving the discovery request, responds to the CoAP client with the software and hardware resource information of the current multi-core DSP platform. After receiving the task management request, it sends a task scheduling request to the slave CoAP server of the current multi-core DSP platform and the main CoAP server of other multi-core DSP platforms and receives a response.

[0011] Receive the task scheduling request of the main CoAP server of the current multi-core DSP platform from the CoAP server, and after receiving the task scheduling request, respond to the scheduling result information to the main CoAP server of the current multi-core DSP platform, and start the task to be scheduled on the core running on itself.

[0012] In the step 1, when configuring the libcoap environment, the libcoap backoff retransmission mechanism parameters are customized, including: (1) modifying the ACK response timeout macro definition COAP_DEFAULT_ACK_TIMEOUT, setting the timeout from 2 seconds to 0.1 to 0.2 seconds; (2) modifying the retransmission maximum value macro definition COAP_DEFAULT_MAX_RETRANSMIT, setting it to 0.

[0013] In the step 2, in the CoAP client program, two threads, reqt and checkt, are created through the POSIX (Portable Operating System Interface) thread interface function, wherein the reqt thread is used to send discovery requests to each main CoAP server, and the checkt thread determines whether the resource has left based on the timestamp; in addition, when the user sends a task management request through the CoAP client visual interface, the client creates a ctrlt thread, which sends a task management request to the specified main CoAP server. In the reqt thread, libcoap is used to poll the resources of each IP address in the known list, and in each polling, the request path / hello is added to the discovery request data packet PDU and sent to the corresponding address. If no response is received within the timeout period, the CoAP environment is released and the process is repeated for the next resource in the list; if a response is received within the timeout period, the information of the resource and the timestamp of the information entry are updated in the discovered resource list. In the checkt thread, the timestamp of each resource in the discovered resource list is checked, and if the difference between the latest timestamp and the timestamp of the resource entry is greater than the set value, the resource corresponding to the entry is marked as having left.

[0014] In the step 2, in the main CoAP server program, two threads servert and infot are created through the POSIX thread interface function, wherein the servert thread listens to the discovery request of the CoAP client, the task management request of the CoAP client and other main CoAP servers; the infot thread is used to periodically update the resource information provided by the multi-core DSP platform to the CoAP client. In the servert thread, the CoAP environment is initialized, and then the IP address of the processor core is bound, and the CoAP context and request identifier URI are created. There are two types of URIs, namely / hello and / ctrl, which are bound to different response functions, and then enter an infinite loop to wait for the request. If the request matches / hello, the resource information is obtained from the global variable and sent back to the CoAP client. If the request matches / ctrl, it is determined according to the request parameters whether the task only needs to run on the current multi-core DSP device. If so, a task scheduling request is sent to the slave CoAP server, otherwise a task management request is also sent to other main CoAP servers. In the infot thread, resource information is periodically obtained through the built-in commands of the SylixOS system, and the information is updated to the global variable.

[0015] In step 2, from the CoAP server program, use libcoap to bind the response function and the corresponding identification URI, set the URI to / startdev, and then enter an infinite loop to listen for task scheduling requests from the main CoAP server. When a task scheduling request is received, enter the response function, extract the name of the task to be scheduled, send a successful request response to the main CoAP server, and start the corresponding task program.

[0016] In the method of the present invention, the source code of the multi-core DSP platform SylixOS is modified, and a self-built command runMyCoapApp is added to the bspBoardUserAppHook function. The command is bound to a function of the same name, and its function is to obtain the current core number, and judge whether to start the main CoAP server or the slave CoAP server on the current core according to the number, and then start the corresponding server through a shell command; add and execute the self-built command runMyCoapApp in the startup script startup.sh of the SylixOS operating system. After each core of the multi-core DSP platform is started, a startup script startup.sh is executed, so that each core starts the corresponding server according to its own core number.

[0017] The advantages of the distributed system resource discovery and task management method based on the CoAP protocol of the present invention are:

[0018] (1) The method of the present invention uses the open source implementation libcoap of the CoAP protocol on multiple multi-core DSP platforms installed with the domestic operating system SylixOS and a PC. Through the customization of libcoap backoff and retransmission mechanism parameters, resource departure judgment based on timestamps, and master-slave core interaction mechanism, the distributed system resource discovery and task management have low overhead, high speed, and low load, and has the advantage of independent and controllable source code.

[0019] (2) The method of the present invention is implemented based on the CoAP protocol. The CoAP protocol is lightweight and efficient, which enables it to reduce resource usage, reduce power consumption, and improve network efficiency when running on multi-core DSP embedded devices. The method of the present invention uses the open source implementation of the CoAP protocol, libcoap, and customizes its backoff and retransmission mechanism parameters. Libcoap is a C library based on the CoAP protocol. It has good portability on the multi-core DSP platform, and has high data transmission efficiency and low resource usage. It is lightweight and efficient. After customizing the backoff and retransmission mechanism parameters, the speed of resource discovery is improved. The method of the present invention uses the domestic operating system SylixOS on the multi-core DSP. The operating system provides support for multi-core DSPs, supports the POSIX standard, and has supporting development tools and compilation chains, which has obvious advantages in autonomous control.

[0020] (3) The present invention divides the CoAP server into two layers, master and slave. The master and slave CoAP servers are hierarchically designed and deployed on a multi-core DSP platform for operation. The advantage of this is that it reduces the resource discovery and task management load of the entire system. If the master CoAP server runs on each core of the multi-core DSP platform, the PC platform needs to request each core, not just one core running the master CoAP server in each multi-core DSP, which will increase the overhead. In addition, the master CoAP server has more functions than the slave CoAP server and requires relatively more resources to support its operation. Therefore, the hierarchical operation of the master and slave CoAP servers of the present invention reduces the resource overhead required for the CoAP client to send discovery requests and the CoAP server to run, thereby reducing the resource discovery and task management load of the entire system.

[0021] (4) The method of the present invention customizes the libcoap backoff and retransmission mechanism so that CoAP requests can be sent more timely and resources can be discovered more timely; a timestamp-based resource departure judgment mechanism is set on the CoAP client so that resources can be discovered in time when they leave, and when the resources appear again, they can be discovered again in time through the customized libcoap.

[0022] (5) In the CoAP client program, when the resource request does not receive a response within the timeout period, the method of the present invention releases the CoAP environment and continues to repeat the process of sending the discovery request to the next resource in the list. In this way, there is no need to wait for a long time for retransmission, and requests are sent to each resource in a timely manner, so that resources can be discovered more timely; and expired resources are marked as having left according to the timestamp, so that the resources can be discovered in time when they leave; in the main CoAP server program, the infot thread is used to periodically obtain resource information and update it to the global variable, which can reduce the load of the servert thread, so that the servert thread can directly read the resource information from the global variable, shorten the time for the CoAP main server to respond to the CoAP client discovery request, and make the response more timely. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a flowchart of the implementation of the CoAP client of the present invention;

[0024] Figure 2 This is a flow chart of the implementation of the main CoAP server of the present invention;

[0025] Figure 3 This is a flow chart of the implementation of the present invention from the CoAP server side;

[0026] Figure 4 This is a request interaction relationship diagram between the master-slave CoAP server and the CoAP client of the present invention. DETAILED DESCRIPTION

[0027] The technical solution of the present invention is described below in conjunction with the accompanying drawings and embodiments.

[0028] The present invention adopts libcoap, an open source implementation of the CoAP protocol, on multiple multi-core DSP platforms and a PC installed with the domestic operating system SylixOS. By customizing the backoff and retransmission mechanism parameters of libcoap and combining the resource departure judgment mechanism based on timestamp and the master-slave core interaction mechanism, the speed and timeliness of resource discovery are improved, and the load of the overall resource discovery and task management of the system is reduced, so as to achieve the effects of low overhead, high speed and low load of resource discovery and task management of distributed systems. A method for resource discovery and task management is provided on a multi-core DSP based on the domestic operating system SylixOS, and has the advantage of independent and controllable source code.

[0029] The present invention provides a distributed system resource discovery and task management method based on the CoAP protocol, which includes the following three steps, which are described in detail below.

[0030] Step 1: Build a distributed system framework based on the CoAP protocol.

[0031] In terms of hardware environment, the system consists of multiple multi-core DSP platforms and a PC interconnected through an Ethernet switch. The multi-core DSP is a discoverable resource, and each core runs independently and can perform different tasks. The role of the PC is to discover resources and visualize the information of discovered resources, and also issue task scheduling instructions to the multi-core DSP.

[0032] In terms of software environment, the domestic operating system SylixOS is installed on the multi-core DSP, and the Linux system is installed on the PC. On the multi-core DSP and PC, the CoAP protocol open source implementation libcoap environment is configured. The CoAP protocol is lightweight and efficient, which enables it to reduce resource usage, reduce power consumption, and improve network efficiency when running on multi-core DSP embedded devices. Libcoap is a C library based on the CoAP protocol. It has good portability on the multi-core DSP platform, and has high data transmission efficiency and low resource usage. It is lightweight and efficient. The domestic operating system SylixOS provides support for multi-core DSP, supports the POSIX standard, and has supporting development tools and compilation chains, which has obvious advantages in autonomous control.

[0033] When configuring the libcoap environment, customize the parameters of the libcoap backoff retransmission mechanism, including two aspects: (1) modify the ACK (acknowledgement character) response timeout macro definition COAP_DEFAULT_ACK_TIMEOUT, and set the timeout from 2 seconds to 0.1~0.2 seconds; (2) modify the maximum retransmission macro definition COAP_DEFAULT_MAX_RETRANSMIT and set it to 0. The advantage of these two settings is that when the CoAP request cannot be delivered, the requester does not need to wait for the original ACK timeout of 2 seconds, but can send the CoAP request again in 0.1~0.2 seconds, which prevents the situation where the resource can be discovered during a long waiting time but the request is not sent to the resource in time, so that the CoAP request can be sent more timely, so that the resource can be discovered more timely.

[0034] Step 2: Implement the master and slave CoAP servers and CoAP clients.

[0035] (1) Implement the CoAP client.

[0036] The function of the CoAP client is to send discovery requests and task management requests to the main CoAP server, and receive responses to discovery requests and task management requests. After receiving the response to the discovery request, the resource information is stored in the list of discovered resources. In addition, the CoAP client also implements a timestamp-based resource departure judgment mechanism, so that the list of discovered resources can be updated in time when the resource leaves. The implementation process of the CoAP client is as follows Figure 1 shown.

[0037] After entering the client program, two threads, reqt and checkt, are created through the POSIX thread interface function. The reqt thread is used to send discovery requests to each main CoAP server, and the checkt thread determines whether the resource has left based on the timestamp. In addition, when the user sends a task management request through the CoAP client visual interface, the client creates a ctrlt thread, which sends a task management request to the specified main CoAP server.

[0038] In the reqt thread, according to the pre-set IP address list, poll the resources of each address in the list. In each poll, first initialize the CoAP environment, then parse the resource address, create a CoAP context and bind the response function, and then create a discovery request packet PDU (protocol data unit), add the request path / hello to the PDU and send it to the corresponding IP address. If no response is received within the timeout, release the CoAP environment and continue to repeat the process to the next IP address in the list; if a response is received within the timeout, update the resource information and the timestamp of the information entry in the discovered resource list. The advantage of this is that there is no need to wait for a long time for retransmission, and requests can be sent to each resource in a timely manner, so that resources can be discovered more timely.

[0039] In the checkt thread, the timestamp of each resource in the discovered resource list is checked by obtaining the latest timestamp and comparing it with the timestamp of the resource entry. If the difference is greater than the set value RESRECORD_OVERTIME, which is within the range of 1 to 2 seconds in the embodiment of the present invention, the resource corresponding to the entry is marked as having left. This approach allows the resource to be discovered in a timely manner when it leaves. If the resource appears again, its information will be added to the discovered resource list again in the aforementioned reqt thread.

[0040] In the ctrlt thread, first initialize the CoAP environment, then parse the resource address, create a CoAP context and bind the response function, then create a task management request data packet PDU, add the request path / ctrl in the PDU, and add the request parameter with the value of the task name to be scheduled, and then send it to the corresponding resource address. If no response is received within the timeout period, release the CoAP environment and request again; if a response is received within the timeout period, the user is prompted through the visual interface that the request is sent successfully.

[0041] (2) Implement the main CoAP server.

[0042] The function of the main CoAP server is to receive the discovery request and task management request from the CoAP client, and after receiving the discovery request, respond to the CoAP client with the software and hardware information of the current multi-core DSP platform. After receiving the task management request, it sends the task scheduling request to the slave CoAP server of the current multi-core DSP platform and the master CoAP server of other multi-core DSP platforms and receives the response. The implementation process of the main CoAP server is as follows: Figure 2 shown.

[0043] After entering the main CoAP server program, two threads, servert and infot, are created through the POSIX thread interface function. The servert thread listens to the discovery requests of the CoAP client, the task management requests of the CoAP client and other main CoAP servers; the infot thread is used to periodically update the resource information provided to the CoAP client.

[0044] In the servert thread, the CoAP environment is initialized first, then the IP address of the processor core is bound, a CoAP context is created and the identification URI is bound. Two URIs are set, namely / hello and / ctrl, corresponding to the two request paths of the aforementioned CoAP client. The two URIs are bound to response functions with different functions, and then an infinite loop is entered to monitor resource discovery requests and task management requests. After receiving the request, different response functions are entered according to the request path. If it is / hello, it means that the request is a resource discovery request from the CoAP client. At this time, resource information is obtained from the global variables of the multi-core DSP platform, including the number of processor cores, processor main frequency, memory size, processor occupancy, memory occupancy, running task information, etc., and sent back to the CoAP client in the form of a response; if the path is / ctrl, it means that the request is a task management request from the CoAP client or other main CoAP server. At this time, the request parameters are extracted, and different requests are further sent according to the task to be scheduled: if the task to be scheduled only needs to run on the current multi-core DSP device, then send a request to the slave CoAP client. The P server sends a task scheduling request. The specific process is to initialize the CoAP environment first, then parse the resource address, create a CoAP context and bind a response function, then create a discovery request data packet PDU, add the request path / startdev in the PDU, and add a request parameter with the value of the task name to be scheduled before sending it. If the task to be scheduled needs to run on other multi-core DSP devices, a task management request is also sent to other main CoAP servers. First, initialize the CoAP environment, then parse the resource address, create a CoAP context and bind a response function, then create a discovery request data packet PDU, add the request path / ctrl in the PDU, and add a request parameter with the value of the task name to be scheduled before sending it.

[0045] In the infot thread, the resource information on the platform is periodically obtained through the built-in commands of the SylixOS system, including the number of processor cores, processor frequency, memory size, processor occupancy, memory occupancy, and running task information, and then updated to the global variables. The advantage of letting the additional thread infot to update resource information instead of servert is that it reduces the load of the servert thread, allowing the servert thread to read resource information directly from the global variables, shortening the time it takes for the CoAP main server to respond to the CoAP client's discovery request, and making the response more timely.

[0046] (3) Implemented from the CoAP server.

[0047] The function of the slave CoAP server is to receive the task scheduling request from the master CoAP server of the current multi-core DSP platform, and after receiving the task scheduling request, respond to the master CoAP server of the current multi-core DSP platform with the scheduling result information, and start the task to be scheduled on its own running core. The implementation process of the slave CoAP server is as follows Figure 3 shown.

[0048] After entering the slave server program, the CoAP environment is initialized first, then the IP address of the processor core is bound, the CoAP context is created and the response function and the corresponding identification URI are bound. The URI is set to / startdev, and then an infinite loop is entered to listen for task scheduling requests from the master CoAP server. When a task scheduling request is received, the response function is entered. In the response function, the request parameter with the value of the task name to be scheduled is extracted, and then a successful request response is sent to the master CoAP server, and the corresponding task program is started.

[0049] Step 3: System deployment and operation.

[0050] After the system is deployed and running, the interaction relationship between the request identifier URI (Uniform Resource Identifier) ​​of the master and slave CoAP servers and CoAP clients is as follows: Figure 4As shown. The main CoAP server runs on one of the cores of each multi-core DSP platform, the slave CoAP server runs on the other cores of each DSP platform, and the CoAP client runs on the PC platform. The specific method is to modify the source code of SylixOS, add a self-built command runMyCoapApp, which is bound to a function of the same name. The function is to obtain the current core number, determine whether to start the main CoAP server or the slave CoAP server on the current core according to the number, and then start it through the shell (command line interpreter) command. According to the startup principle of SylixOS, each core will execute the startup script startup.sh after startup. Therefore, executing the self-built command runMyCoapApp in the script file can enable each core to start the corresponding server program according to its own core number. In addition, according to the startup principle of SylixOS, it is necessary to add the self-built command runMyCoapApp in the bspBoardUserAppHook function of the SylixOS source code, so that when each core executes the startup script startup.sh, the self-built command runMyCoapApp can be effectively executed.

[0051] The advantage of dividing the CoAP server into master and slave is that it reduces the resource discovery and task management load of the entire system: the master CoAP server can be run on each core of the multi-core DSP, and the CoAP client can be run on the PC platform at the same time. However, this situation will increase the discovery request overhead of the PC platform, and it is necessary to request each core of each multi-core DSP, rather than just one core of each multi-core DSP that runs the master CoAP server. In addition, the master CoAP server has more functions than the slave CoAP server and requires relatively more resources to support its operation. The layered operation of the master and slave CoAP servers also has the advantage of reducing resource consumption.

[0052] Except for the technical features described in the specification, all of them are known technologies to those skilled in the art. The present invention omits the description of known components and known technologies to avoid redundancy and unnecessary limitation of the present invention. The implementation methods described in the above embodiments do not represent all implementation methods consistent with the present application. On the basis of the technical solution of the present invention, various modifications or variations that can be made by those skilled in the art without creative labor are still within the protection scope of the present invention.

Claims

1. A distributed system resource discovery and task management method based on CoAP protocol, characterized in that: include: Step 1: Build a distributed system framework based on the CoAP protocol; The distributed system framework is composed of multiple multi-core DSP platforms and a PC interconnected by an Ethernet switch; the multi-core DSP platform is a resource that can be discovered, and each core of the platform runs independently; the PC issues task scheduling instructions to the multi-core DSP platform to visualize the discovered resources; the multi-core DSP platform is installed with the SylixOS operating system, and the CoAP protocol is configured on the multi-core DSP platform and the PC to implement the libcoap environment; when configuring the libcoap environment, the parameters of the libcoap backoff retransmission mechanism are customized to shorten the waiting time for the requester to send the CoAP request again; wherein DSP represents a digital signal processor; Step 2: Deploy the CoAP client on the PC; deploy the master CoAP server on one core in each multi-core DSP platform, and deploy the slave CoAP server on the remaining cores; The CoAP client sends a discovery request and a task management request to the main CoAP server, and receives responses to the discovery request and the task management request. After receiving the discovery request response, the resource information is stored in the discovered resource list; a resource departure judgment mechanism based on a timestamp is implemented, and the discovered resource list is updated in time when a resource leaves; The master CoAP server receives the discovery request and task management request from the CoAP client. After receiving the discovery request, it responds to the CoAP client with the software and hardware resource information of the current multi-core DSP platform. After receiving the task management request, it sends a task scheduling request to the slave CoAP server of the current multi-core DSP platform and the master CoAP server of other multi-core DSP platforms and receives a response. The slave CoAP server receives the task scheduling request from the master CoAP server of the current multi-core DSP platform, and after receiving the task scheduling request, responds to the master CoAP server of the current multi-core DSP platform with the scheduling result, and starts the task to be scheduled on the core running on itself.

2. The method according to claim 1, characterized in that In step 1, when configuring the libcoap environment, the libcoap backoff retransmission mechanism parameters are customized, including: (1) Modify the ACK response timeout macro definition COAP_DEFAULT_ACK_TIMEOUT and set the timeout value range to 0.1 to 0.2 seconds; ACK stands for confirmation character; (2) Modify the macro definition of the maximum number of retransmissions, COAP_DEFAULT_MAX_RETRANSMIT, and set the maximum number of retransmissions to 0.

3. The method according to claim 1, characterized in that In the step 2, in the CoAP client, two threads, reqt and checkt, are created through the POSIX thread interface function, wherein the reqt thread is used to send discovery requests to each main CoAP server, and the checkt thread determines whether the resource has left based on the timestamp; when the user sends a task management request through the CoAP client visual interface, the CoAP client creates a ctrlt thread for sending a task management request to the specified main CoAP server.

4. The method according to claim 3, characterized in that: In the step 2, in the reqt thread, according to the pre-set IP address list, the resources of each address in the list are polled, and in each polling, the request path / hello is added to the discovery request data packet PDU and sent to the corresponding address; if no response is received within the timeout period, the CoAP environment is released and the discovery request is continued to be sent to the next address in the list; if a response is received within the timeout period, the resource information and the timestamp of the resource entry are updated in the discovered resource list; In the checkt thread, the timestamp of each resource in the discovered resource list is checked. If the difference between the timestamp of the resource entry and the latest timestamp is greater than the set value, the resource is marked as left.

5. The method according to claim 3, characterized in that: In the step 2, in the ctrlt thread, the CoAP environment is first initialized, then the resource address is parsed, the CoAP context is created and the response function is bound, and then a task management request data packet PDU is created, and the request path / ctrl is added to the PDU, and a request parameter with the value of the task name to be scheduled is added, and then sent to the corresponding resource address; if no response is received within the timeout period, the CoAP environment is released and re-requested; If a response is received within the timeout period, the user will be prompted through the visual interface that the request was sent successfully.

6. The method according to claim 1, characterized in that In the step 2, the main CoAP server creates threads servert and infot through the POSIX thread interface function, wherein the servert thread listens to the discovery request of the CoAP client, the task management request of the CoAP client and other main CoAP servers; the infot thread is used to periodically update the resource information provided by the multi-core DSP platform to the CoAP client.

7. The method according to claim 6, characterized in that In the step 2, in the servert thread, the CoAP environment is initialized, and then the IP address of the processor core is bound, and the CoAP context and request identifier URI are created. There are two types of URIs, namely / hello and / ctrl, which are bound to different response functions, and then enter an infinite loop to wait for requests; if the request matches / hello, the resource information is obtained from the global variables of the current platform and sent back to the CoAP client; if the request matches / ctrl, it is determined according to the request parameters whether the task only needs to run on the current multi-core DSP platform. If so, a task scheduling request is sent to the slave CoAP server, otherwise a task management request is also sent to other main CoAP servers; in the infot thread, the resource information of the current platform is periodically obtained through the built-in commands of the SylixOS system and updated to the global variables.

8. The method according to claim 7, characterized in that In the step 2, in the servert thread, if the request matches / ctrl, when the task only needs to run on the current multi-core DSP platform, the CoAP environment is initialized, the resource address is parsed, the CoAP context is created and the response function is bound, and then a discovery request data packet PDU is created, the request path / startdev is added to the PDU, and the request parameter with the value of the task to be scheduled is added and sent; when the task also needs to run on other multi-core DSP platforms, the servert thread sends a task management request to other main CoAP servers, first initializes the CoAP environment, then parses the resource address, creates a CoAP context and binds the response function, and then creates a discovery request data packet PDU, adds the request path / ctrl to the PDU, and adds the request parameter with the value of the task to be scheduled and sends it.

9. The method according to claim 1 or 6, characterized in that: In the step 1, when deployed from the CoAP server, the CoAP environment is first initialized, then the IP address of the processor core is bound, a CoAP context is created and a response function and a corresponding identification URI are bound, the URI is set to / startdev, and then an infinite loop is entered to listen for task scheduling requests from the main CoAP server; when a task scheduling request is received, the response function is entered, the name of the task to be scheduled is extracted, a request success response is sent to the main CoAP server, and the corresponding task program is started.

10. The method according to claim 1, characterized in that In the method described, the source code of the SylixOS operating system of the multi-core DSP platform is modified, and a self-built command runMyCoapApp is added to the source code bspBoardUserAppHook function. The command is bound to a function of the same name. The function of the function is to obtain the current core number, determine whether to start the main CoAP server or the slave CoAP server on the current core according to the number, and start the corresponding server; add and execute the self-built command runMyCoapApp in the startup script startup.sh of the SylixOS operating system; after each core of the multi-core DSP platform is started, a startup script startup.sh is executed, so that each core starts the corresponding server according to its own core number.

Images