A distributed system resource discovery and task management method based on CoAP protocol

Abstract

The present invention is a distributed system resource discovery and task management method based on the CoAP protocol, which belongs to the field of embedded and distributed communications. The method of the present invention includes: building a distributed system framework based on the CoAP protocol on multiple multi-core DSP platforms and a PC; deploying a CoAP client on the PC, deploying a master CoAP server on one core of each multi-core DSP platform, and deploying slave CoAP servers on the remaining cores; the client sends a discovery request and a task management request to the master server, and updates the discovered resource list in combination with the timestamp; the master server responds to the discovery request, informs the client of the current resource information, and sends a task scheduling request to the slave server of this platform and other master servers; the slave server starts the task to be scheduled on its own core. The present invention achieves the effects of low overhead, high speed, and low load for distributed system resource discovery and task management, and has the advantage of independent and controllable source code.

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 installed with the domestic operating system SylixOS. Background Art

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

[0003] Due to the different time of technology development, most application scenarios in the early stage were developed based on foreign operating systems such as VxWorks and RTEMS, which were technically uncontrollable and had high security risks. With the rise of domestic RTOS (real-time operating system) technology, the 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 area; (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 existing technology 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. The method is mainly based on a distributed, strong real-time architecture foundation and 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 includes the following steps:

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

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

[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, it also stores the resource information 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 a resource leaves.

[0010] The master CoAP server receives discovery requests and task management requests 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 task scheduling requests 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 responses.

[0011] Receive the task scheduling request from 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 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 time 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 step 2, the CoAP client program creates two threads, reqt and checkt, using POSIX (Portable Operating System Interface) thread interface functions. The reqt thread sends discovery requests to each primary CoAP server, while the checkt thread determines whether a resource has left based on timestamps. Additionally, when a user sends a task management request through the CoAP client's visual interface, the client creates the ctrlt thread, which sends the task management request to the designated primary CoAP server. In the reqt thread, libcoap is used to poll resources at each IP address in a known list. During each poll, the discovery request packet (PDU) is appended with the request path " / hello" and sent to the corresponding address. If no response is received within the timeout, the CoAP environment is released and the process repeats for the next resource in the list. If a response is received within the timeout, the resource's information and the timestamp of the 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 latest timestamp and the timestamp of the resource entry is greater than a set value, the resource corresponding to that entry is marked as left.

[0014] In step 2, the master CoAP server program creates two threads, servert and infot, using POSIX thread interface functions. The servert thread listens for discovery requests from CoAP clients and task management requests from the CoAP client and other master CoAP servers. The infot thread periodically updates resource information provided by the multi-core DSP platform to the CoAP client. In the servert thread, the CoAP environment is initialized, the IP address of the processor core is bound, a CoAP context and request identifier URI are created. Two URIs are provided: / hello and / ctrl, each bound to a different response function. The program then enters an infinite loop waiting for requests. If the request matches / hello, resource information is retrieved from a global variable and sent back to the CoAP client. If the request matches / ctrl, the request parameters are used to determine 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, task management requests are sent to other master CoAP servers. In the infot thread, resource information is periodically retrieved using built-in commands in the SylixOS system and updated in the global variable.

[0015] In step 2, the CoAP server program uses libcoap to bind the response function and its corresponding identifier URI, set to / startdev, and then enters an infinite loop, listening 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 successful response is sent to the main CoAP server, and the corresponding task program is started.

[0016] In the method of the present invention, the source code of the multi-core DSP platform SylixOS is modified, and a custom command runMyCoapApp is added to the bspBoardUserAppHook function. This command is bound to a function of the same name and is used to obtain the current core number. Based on the number, it determines whether to start the master CoAP server or the slave CoAP server on the current core, and then starts the corresponding server through a shell command. The custom command runMyCoapApp is added and executed in the startup.sh startup script of the SylixOS operating system. After each core of the multi-core DSP platform is started, a startup script startup.sh is executed, causing each core to start the corresponding server according to its 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 adopts libcoap, an open source implementation 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 are achieved with 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 DSP, supports the POSIX standard, and has supporting development tools and compilation chains. It has obvious advantages in terms of independent control.

[0020] (3) The present invention divides the CoAP server into two layers, master and slave. The master and slave CoAP servers are designed and deployed in a hierarchical manner to run on a multi-core DSP platform. 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 in each multi-core DSP that runs the master CoAP server, which will lead to increased 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. After the resources reappear, 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 flowchart of the implementation of the main CoAP server of the present invention;

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

[0026] Figure 4 This is a diagram of the request interaction relationship 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 with reference to 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 installed with the domestic operating system SylixOS and a PC. By customizing the backoff and retransmission mechanism parameters of libcoap and combining it with a timestamp-based resource departure judgment mechanism and a master-slave core interaction mechanism, the speed and timeliness of resource discovery are improved, while the load of the overall resource discovery and task management of the system is reduced, achieving the effects of low overhead, high speed and low load for distributed system resource discovery and task management. 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, the system consists of multiple multi-core DSP platforms and a PC interconnected via an Ethernet switch. The multi-core DSPs are discoverable resources, each core operating independently and capable of performing distinct tasks. The PC discovers resources, visualizes their information, and issues task scheduling instructions to the multi-core DSPs.

[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. The open source libcoap environment for implementing the CoAP protocol is configured on the multi-core DSP and PC. 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 DSPs, supports the POSIX standard, and has supporting development tools and compilation chains. It has obvious advantages in terms of independent control.

[0033] When configuring the libcoap environment, the libcoap backoff and retransmission mechanism parameters are customized, specifically in two aspects: (1) modifying the ACK (acknowledgement character) response timeout macro definition COAP_DEFAULT_ACK_TIMEOUT, setting the timeout from 2 seconds to 0.1~0.2 seconds; (2) modifying the maximum retransmission count macro definition COAP_DEFAULT_MAX_RETRANSMIT, setting it to 0. The advantage of these two settings is that when a 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, preventing 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, thereby allowing the resource to 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 the ctrlt thread, which sends the task management request to the specified main CoAP server.

[0038] In the reqt thread, according to the pre-set IP address list, the resources of each address in the list are polled. In each poll, the CoAP environment is initialized first, then the resource address is parsed, the CoAP context is created and the response function is bound. Then, a discovery request packet PDU (Protocol Data Unit) is created, and the request path / hello is added to the PDU and sent to the corresponding IP address. If no response is received within the timeout, the CoAP environment is released and the process is repeated for the next IP address in the list; if a response is received within the timeout, the resource information and the timestamp of the information entry are updated 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, thereby discovering resources more promptly.

[0039] In the checkt thread, the timestamp of each resource in the discovered resource list is checked. Specifically, the latest timestamp is obtained and compared 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 this embodiment of the present invention), the resource corresponding to the entry is marked as having left. This approach ensures that when a resource leaves, it can be discovered promptly. If the resource reappears, its information is added to the discovered resource list in the aforementioned reqt thread.

[0040] In the ctrlt thread, the CoAP environment is initialized, the resource address is parsed, a CoAP context is created, and a response function is bound. A task management request packet (PDU) is then created. The request path, / ctrl, and a request parameter, representing the name of the task to be scheduled, are added to the PDU and sent to the corresponding resource address. If no response is received within the timeout, the CoAP environment is released and a new request is made. If a response is received within the timeout, a visual notification is displayed to the user indicating that the request was successfully sent.

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

[0042] The main CoAP server's function is to receive discovery requests and task management requests from CoAP clients, 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 task scheduling requests 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 responses. 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 for discovery requests from CoAP clients and task management requests from CoAP clients and other main CoAP servers; the infot thread is used to periodically update resource information provided to CoAP clients.

[0044] In the servert thread, the CoAP environment is first initialized, and 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 listen for 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 situation of the task to be scheduled: if the task to be scheduled only needs to run on the current multi-core DSP device, then it is sent to the CoAP client from the CoAP client. The P server sends a task scheduling request. The specific process is to first initialize the CoAP environment, then parse the resource address, create a CoAP context and bind the response function, then create a discovery request data packet PDU, add the request path / startdev in the PDU, and add the request parameter with the value of the task 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 the response function, then create a discovery request data packet PDU, add the request path / ctrl in the PDU, and add the request parameter with the value of the task to be scheduled before sending it.

[0045] The infot thread periodically retrieves platform resource information, including the number of processor cores, processor frequency, memory size, processor utilization, memory utilization, and information about running tasks, through built-in commands in the SylixOS system. This information is then updated to global variables. Having the infot thread update resource information instead of the servert thread reduces the servert thread's load, allowing it to read resource information directly from global variables. This reduces the time it takes for the CoAP master server to respond to CoAP client discovery requests, resulting in more timely responses.

[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, the IP address of the processor core is bound, a CoAP context is created, and a response function and its corresponding identifier URI are bound to / startdev. The slave server then enters an infinite loop, listening for task scheduling requests from the master CoAP server. Upon receiving a task scheduling request, the slave server enters the response function, extracting the request parameter containing the name of the task to be scheduled. The slave server then sends a successful response to the master CoAP server and starts the corresponding task program.

[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, slave CoAP server and CoAP client 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 SylixOS source code and add a self-built command runMyCoapApp. This command is bound to a function of the same name. Its 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 based on 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 this 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 to the bspBoardUserAppHook function in the SylixOS source code so that the self-built command runMyCoapApp can be effectively executed when each core executes the startup script startup.sh.

[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 running 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 other technical features are known to those skilled in the art. The present invention omits descriptions of well-known components and well-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. Based on the technical solution of the present invention, various modifications or variations that can be made by those skilled in the art without creative effort are still within the scope of protection 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 consists of multiple multi-core DSP platforms and a PC interconnected via an Ethernet switch. The multi-core DSP platform is a discoverable resource, and each core of the platform operates 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 and retransmission mechanism are customized to shorten the waiting time for the requester to send the CoAP request again. 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 discovery requests and task management requests to the main CoAP server, receives responses to the discovery requests and task management requests, and stores resource information in the discovered resource list after receiving the discovery request response; implements a timestamp-based resource departure judgment mechanism to promptly update the discovered resource list 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, customize the libcoap backoff retransmission mechanism parameters, 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 step 2, the CoAP client creates two threads, reqt and checkt, through the POSIX thread interface function, where 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 to send the task management request to the specified main CoAP server.

4. The method according to claim 3, characterized in that In step 2, in the reqt thread, according to the pre-set IP address list, the resources of each address in the list are polled. In each poll, 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 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 step 2, in the ctrlt thread, the CoAP environment is first initialized, the resource address is then parsed, a CoAP context is created and a response function is bound, and then a task management request packet PDU is created. The request path / ctrl is added to the PDU, and a request parameter with the value of the task 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 a new request is made; 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 step 2, the main CoAP server creates threads servert and infot through the POSIX thread interface function, where the servert thread listens to the discovery request of the CoAP client and 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 to the CoAP client by the multi-core DSP platform.

7. The method according to claim 6, characterized in that In step 2, in the servert thread, the CoAP environment is initialized, and then the IP address of the processor core is bound, and a CoAP context and request identifier URI are created. There are two types of URIs, / hello and / ctrl, which are bound to different response functions, and then an infinite loop is entered to wait for requests; if the request matches / hello, 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 based on 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 master 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 step 1, when deploying 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 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 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 successful request 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 described method, 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 bspBoardUserAppHook function of the source code. The command is bound to a function of the same name. The function obtains the current core number, determines whether to start the master CoAP server or the slave CoAP server on the current core according to the number, and starts the corresponding server; the self-built command runMyCoapApp is added to the startup script startup.sh of the SylixOS operating system for execution; 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