Smbus-based inter-device priority negotiation method and system

Abstract

The embodiment of the present disclosure provides a priority negotiation method and system between devices based on SMBus. The method is used for realizing negotiation of priority ranking between multiple slave devices. Not only the master device can issue the priority ranking, but also the slave device can request the master device to adjust the priority, so that dynamic allocation ranking is realized. Further, the method balances task urgency and system load through a weight algorithm, and guarantees communication security through an encryption and permission control mechanism, so as to prevent malicious devices from preempting priority.

Description

Technical Field

[0001] This disclosure relates to the field of bus communication technology, specifically to a method and system for inter-device priority negotiation based on SMBus. Background Technology

[0002] SMBus (System Management Bus) is a low-speed, bidirectional serial communication bus. It is also a simplified communication protocol based on the I2C (Inter-Integrated Circuit) bus. It is mainly used for low-speed data transmission in embedded systems and computer hardware, and is widely used in scenarios such as battery management, power management, temperature monitoring, hardware monitoring, and sensor data acquisition.

[0003] Because SMBus has a multi-master-slave structure and supports bus arbitration and collision detection, in a multi-device system on the SMBus bus, all devices share the transmission medium on the bus. Generally speaking, there will always be a master device on the SMBus bus, which can manage other slave devices.

[0004] The existing SMBus master devices use a static priority allocation strategy (e.g., slave device address order or manual configuration), which has obvious drawbacks. It cannot dynamically adjust priorities based on task urgency or resource utilization. At the same time, priority configuration needs to be preset, which is difficult to adapt to complex systems. Low-priority tasks may preempt the bus for a long time, causing high-priority tasks to be delayed, resulting in poor bus utilization. Summary of the Invention

[0005] In view of this, embodiments of the present disclosure provide a method and system for inter-device priority negotiation based on SMBus to solve the problems in the prior art.

[0006] According to a first aspect of the present disclosure, a method for inter-device priority negotiation based on SMBus is provided, characterized by comprising the following steps:

[0007] Receive priority request commands sent by multiple slave devices, wherein the priority request commands include the attribute information of the slave devices and the attribute information of the current task of the slave devices;

[0008] Based on the attribute information of the slave device and the attribute information of the current task of the slave device, the priority score of the current task of the slave device is calculated, and priority request responses are sent to multiple slave devices respectively to notify the slave devices of the priority ranking of the multiple slave devices.

[0009] In some embodiments, when the slave device rejects the ranking of the priority scores, a priority adjustment request is sent;

[0010] The master device then performs the following: recalculates the priority score of the slave device, and sends priority request responses to the multiple slave devices respectively according to the recalculated priority score, so as to notify the slave devices of the new priority order of the multiple slave devices.

[0011] In some embodiments, the slave device sends a priority request command after power-on, the priority request command containing the initial attribute information of the slave device;

[0012] The master device then performs the following: calculates the default priority of each of the multiple slave devices based on their initial attribute information.

[0013] In some embodiments, if the slave device fails to successfully negotiate with the master device after a timeout or after a set number of attempts, it uses the default priority; or, after lowering its own priority threshold, it resends the priority adjustment request.

[0014] In some embodiments, the priority request command and / or the priority adjustment request includes one or more of the following: the importance level of the slave device, the urgency of the current task of the slave device, the resource share of the current task of the slave device in the slave device, the historical proportion of time the slave device occupies the bus, and the deadline of the current task.

[0015] The priority score of the current task of the slave device is related to one or more of the following: the importance level of the slave device, the urgency of the current task of the slave device, the resource ratio of the current task of the slave device in the slave device, the proportion of time the slave device occupies the bus in history, and the deadline of the current task.

[0016] In some embodiments, the priority score of the current task of the slave device is calculated using the following formula:

[0017] The formula for calculating the priority score of the current task of the slave device is as follows:

[0018] ,

[0019] Where P(n,t) is the real-time priority of device n;

[0020] E(t) represents the urgency level of real-time events from device n;

[0021] D(n) represents the importance level of device n;

[0022] H(n) represents the proportion of time the slave device occupied the bus in the history;

[0023] L(t) represents the resource percentage of the current task in the slave device.

[0024] R(n,t) is the deadline for the current task, and α, β, γ, δ and ε are weighting coefficients.

[0025] In some embodiments, the method further includes one or more of the following items:

[0026] When the slave device fails to respond within a specified time, the master device marks the slave device as unavailable and temporarily lowers its priority; the data portion of various commands is encrypted;

[0027] The master device only allows pre-authorized slave devices to participate in priority negotiation.

[0028] In some embodiments, the priority request command, the priority request response, and the priority adjustment request are obtained by extending the protocol portion of the standard SMBus command.

[0029] According to a second aspect of the present disclosure, a system is provided, the system comprising: a master device and a plurality of slave devices, the master device and the plurality of slave devices being connected and communicating via an SMBus bus, the master device and the plurality of slave devices negotiating priorities according to any one of the methods described above, and the plurality of slave devices occupying the SMBus bus sequentially according to the negotiated priority order to perform their current tasks.

[0030] In some embodiments, the system is a distributed embedded system, an Internet of Things (IoT) device cluster, or an industrial automation control system.

[0031] The SMBus-based inter-device priority negotiation method and system provided in this disclosure enable priority order negotiation among multiple slave devices. Not only can the master device issue priority orders, but slave devices can also request priority adjustments from the master device, thereby achieving dynamic priority allocation. Furthermore, this method balances task urgency and system load through a weighted algorithm and ensures communication security through encryption and access control mechanisms to prevent malicious devices from preempting priority. Attached Figure Description

[0032] The above and other objects, features and advantages of the present disclosure will become clearer from the following description of embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0033] Figure 1 This is a schematic diagram of a master-slave architecture based on SMBus;

[0034] Figure 2This is an interaction diagram between the master device and the slave device in an SMBus-based inter-device priority negotiation method according to an embodiment of this disclosure;

[0035] Figure 3 This is an example diagram of a priority request command derived from an extension of SMBus's Block write;

[0036] Figure 4 This is a flowchart of another embodiment of the SMBus-based inter-device priority negotiation method disclosed herein. Detailed Implementation

[0037] The following description of embodiments of the present disclosure is based on examples, but the embodiments of the present disclosure are not limited to these embodiments. In the detailed description of the embodiments of the present disclosure below, certain specific details are described in detail. Those skilled in the art can fully understand the embodiments of the present disclosure even without these detailed descriptions. To avoid obscuring the essence of the embodiments of the present disclosure, well-known methods, processes, and flows are not described in detail. Furthermore, the accompanying drawings are not necessarily drawn to scale.

[0038] The flowcharts and block diagrams in the accompanying drawings illustrate possible system frameworks, functions, and operations of the systems, methods, and apparatuses according to embodiments of this disclosure. The blocks in the flowcharts and block diagrams may represent a module, program segment, or simply a piece of code. These modules, program segments, and code are all executable instructions used to implement a specified logical function. It should also be noted that the executable instructions implementing the specified logical function can be recombined to generate new modules and program segments. Therefore, the blocks and their order in the accompanying drawings are only used to better illustrate the processes and steps of the embodiments and should not be construed as limiting the invention itself.

[0039] As shown in the figure, master device 101 is electrically connected to slave devices 1 to 5 via the SMBus bus, and data transmission is achieved through the SMBus bus. In the figure, SCL (Serial Clock Line) and SDA (Serial Data Line) are two key signal lines in the SMBus protocol. SCL provides a clock signal for synchronizing data transmission. The clock signal is controlled by master device 101 to ensure that data is sent and received at the correct time. SDA is used for data transmission and is a bidirectional signal line. Data is sampled on the rising edge of the SCL clock pulse, and SDA can change its state on the falling edge. At the start of communication, master device 101 initiates the START condition by pulling SDA low from a high level (when SCL is high). At the end of communication, master device 101 initiates the STOP condition by pulling SDA high from a low level (when SCL is high).

[0040] SMBus defines several standard commands, allowing master device 101 to perform various operations on slave devices 1 through 5. For example, master device 101 can send simple wake-up signals to each slave device using the Quick Command command to check if the devices are in a normal response state; master device 101 can use the Read Byte command to read device information from a specific register of slave device 1; master device 101 can use the Write Byte or Write Word command to write configuration parameters to the register of slave device 2; master device 101 can use the Block Read command to read data in batches from slave device 2; master device 101 can use the BlockWrite command to write data in batches to slave device 3; master device 101 can use the Process Call command to send control instructions to slave devices 1 through 5 respectively and receive the processing results; master device 101 can periodically use the Read Byte or Read Word command to read the values ​​of the status registers from slave devices 1 through 5 to monitor the device's operating status, and so on. Master device 101 effectively manages each slave device through these standard commands. For these standard commands, SMBus specifies the command format (also known as the message format). When using them, the corresponding parameters should be organized according to the command format.

[0041] Existing SMBus master devices use static priority allocation strategies (e.g., slave device address order or manual configuration) to assign priorities to each slave device. However, to achieve priority negotiation between the master and slave devices, this disclosure embodiment creates multiple extended commands based on SMBus standard commands. These extended commands include, for example, priority request commands, priority request responses, and priority adjustment requests. Based on these extended commands, this disclosure embodiment also provides... Figure 2 The method for inter-device priority negotiation based on SMBus shown includes the following steps.

[0042] In step S10, slave devices 1 to 5 send priority request commands to master device 101 respectively. The priority request commands contain the attribute information of the corresponding slave device and the attribute information of the current task of the slave device.

[0043] In step S20, the master device 101 collects priority request commands from slave devices 1 to 5.

[0044] In step S30, the master device 101 calculates the priority score of the current task of devices 1 to 5 based on a set formula.

[0045] In step S40, the master device 101 sends priority request responses to slave devices 1 to 5 respectively to notify the slave devices of the priority order of their current tasks.

[0046] In step S50, the slave device 5 obtains the priority order from the received priority request response, finds that its own priority level or priority order does not match the expectation (for example, its own priority level is less than a preset threshold), and therefore rejects the priority order, and then executes step S60.

[0047] In step S60, the slave device 5 sends a priority adjustment request. The priority adjustment request states the reason for the slave device 5 to request a priority adjustment. The priority adjustment request may also state the target priority that the slave device 5 hopes to achieve.

[0048] In step S70, the master device 101 recalculates the priority scores of the current tasks of devices 1 to 5 based on the collected priority adjustment requests.

[0049] In step S80, the master device 101 sends new priority request responses to slave devices 1 to 5 respectively, to notify the multiple slave devices of the new priority order of the current tasks.

[0050] Steps S60 to S80 can be executed multiple times (e.g., 3 times) to determine the final priority order. Subsequently, devices 1-5 occupy the SMBus bus according to the final priority order to advance their current tasks.

[0051] In this embodiment, the slave device can proactively declare its own importance, urgency, resource requirements, task deadlines, and other attribute information through a priority request command. The master device or arbitrator dynamically allocates the priority of each current task based on the global attribute information. Furthermore, the slave device can also request the master device to reallocate the priority of each current task through a priority adjustment request until the negotiation is successful.

[0052] In some embodiments, the command codes for priority request commands, priority request responses, and priority adjustment requests are shown in Table 1.

[0053] Table 1 command code English name Chinese name use 0x20 PRIORITY_REQUEST Priority Request Command Device declaration priority parameters 0x21 PRIORITY_RESPONSE Priority request response Return priority assignment result 0x22 PRIORITY_ADJUST Priority adjustment request Equipment application priority adjustment

[0054] Figure 3 This is an example diagram of a priority request command derived from an extension of SMBus. This example extends the Block write protocol to obtain a priority request command; specifically, the first few bytes of the Block write payload are used to represent the priority parameter. Figure 3 The descriptions of each field are as follows: 1. S represents the starting condition, indicating the start of communication; 2. The host address (0x10) represents the 7-bit address of the slave device; 3.W indicates that this is a write operation, and the Host address (0x10) + W is a total of 8 bits; 4. A indicates an acknowledgment identifier, for example, a slave device sends an acknowledgment signal (ACK) after sending a single piece of data; 5. Command Code represents the command code; 6. Byte Count represents the length of the data block, indicating the number of bytes to be written. The range of Byte Count is 1 to 32; 7. Priority Params are used to declare priority parameters, with each byte separated by an A (the size can be adjusted according to actual needs); 8. Payload represents the data payload, with each byte separated by an A. 8. pec represents a checksum; 9. P indicates a stop condition, signifying the end of communication.

[0055] When using the priority request command in the above format, Comm is assigned the value '0x20' (priority request command), and priority parameters including the attribute information of the slave device and the attribute information of the current task are written into priority_params. In some embodiments, the data structure corresponding to priority_params is as follows: { uint8_t dev_addr, / / Device address uint8_ttask_type, / / Task type uint8_turgency, / / Task urgency uint8_t resource_usage, / / Resource utilization of the task uint32_t deadline, / / Task end time }

[0056] Similarly, the standard Block write protocol can be extended to obtain priority request responses and priority adjustment requests. This extension does not modify the existing physical and data link layers of SMBus; it only extends the protocol fields, thus ensuring backward compatibility of SMBus.

[0057] In some embodiments, the SMBus-based inter-device priority negotiation process can be defined as: an initialization phase, a priority negotiation phase, and a communication execution phase. In the initialization phase, the slave device submits a priority request command to the master device upon power-up. The priority request command declares initial attribute information. The master device determines the default priority of each slave device based on the initial attribute information and sends a priority request response to notify the slave devices of their respective default priority order. In the priority negotiation phase, the master device and slave devices can... Figure 2 The interaction diagram shown demonstrates priority negotiation. During the communication execution phase, each slave device occupies the SMBus bus sequentially according to its final priority order to advance its current task. Furthermore, the master device's scheduling strategy strictly adheres to a priority scheduling strategy, always processing the highest priority task first, while also following round-robin scheduling, processing tasks within the same priority level according to device order to avoid starvation.

[0058] In some embodiments, the master device calculates the priority score using the following formula: Formula (1)

[0059] Where P(n,t) is the real-time priority of device n; E(t) is the urgency of the current task of device n; D(n) is the importance level of the device, i.e., task_type in priority_params; H(n) is the historical interaction weight, i.e., the proportion of bus time occupied by device n in historical interactions; L(t) is the resource proportion of the current task in the slave device; R(n,t) is the currentline-deadline of the current task. The deadline represents the expected deadline of the current task. After this deadline, the slave device may no longer respond to the task, and the master device needs to respond and process the task before this deadline. After the response is completed, the slave device releases the task. The currentline represents the current time. In addition, the weight coefficient can be set to Its specific value is adjusted in real time by the master device according to the usage scenario.

[0060] In the above weighting formula, compared to other priority calculation methods, D(n), the importance level of the device, is introduced to participate in the priority calculation. Due to the different functions of each device, task reporting and task weights also differ. For example, among tasks of battery management devices, power shortage devices, and temperature management devices, the importance level of a power shortage task is higher than that of a temperature management task. The difference between D(n) and E(t) is that D(n) is the device only reporting its own task type, while E(t) is the expected priority proposed by the device when reporting. H(n), the historical interaction weight, is also introduced. This parameter records the interaction time length during interactions between the master device and multiple slave devices to derive the historical interaction weight. The deadline is the end time of the task triggered by the slave device. Within this time, as long as the master device responds to and completes the response, the slave device can be released. During the time the master device does not respond, the slave device remains in a busy state and continues to consume energy. Energy consumption is proportional to the deadline * The resource_usage is positively correlated. When the master device responds to the device earlier, it can release the device earlier, which can reduce energy consumption. The resource_usage is the amount of resources occupied by the device task, so the master device can roughly estimate the energy consumption of the device.

[0061] Then, the master devices sort the data in descending order of priority score to generate a communication timing table. The communication timing table is the main content for the master device to initiate communication, used to inform each slave device of the priority of each slave device. The communication timing table typically contains the addresses and priorities of several slave devices. Below is an example of a communication timing table structure: {

[0062] uint8_t dev_addr[DEVICE_NUM]; / / Device address

[0063] uint8_t priority[DEVICE_NUM]; / / Priority level of the device

[0064] uint8_t *aes_128; / / AES-128 encryption result sent by the master device}

[0065] Generally, the negotiation process between the master and slave devices is repeated a maximum of three times, or within a set time. If conflicts persist beyond the set number of attempts or timeout, a fallback mechanism is triggered. Each slave device then proceeds with its task using its default priority (ordered by device address). Alternatively, if a slave device knows there are high-priority devices on the SMBus bus, it can consider lowering its own priority threshold and subsequently initiate a priority adjustment request. After negotiation is complete, the master device proactively initiates bus access for the corresponding slave device. The priority mechanism allows the master device to determine whether a particular slave device is currently a key focus on the bus.

[0066] Figure 4 This is a flowchart of another embodiment of the SMBus-based inter-device priority negotiation method disclosed herein. Figure 4 compared to Figure 2 This provides more details about the priority negotiation process.

[0067] In step S301, the device power-on process is performed, including the master device and the slave device.

[0068] In step S302, the master device is initialized. This step allows setting the default priority for each slave device.

[0069] In step S303, the device is initialized. This step can set its own default priority.

[0070] In step S304, the device reports PRIORITY_REQUEST.

[0071] In step S305, bus arbitration is performed. This step is used in scenarios where multiple slave devices simultaneously report PRIORITY_REQUEST. Through the rules and mechanisms provided by the SMBus bus, each slave device reports its own PRIORITY_REQUEST sequentially via the SMBus bus.

[0072] In step S306, the master device receives PRIORITY_REQUEST messages from each slave device.

[0073] In step S307, the master device determines whether the corresponding slave device is an authorized device. If it is, step S309 is executed; otherwise, step S308 is executed.

[0074] In step S308, if the master device determines that the corresponding slave device does not belong to an authorized device, it discards the message.

[0075] In step S309, the master device buffers the message.

[0076] In step S310, the master device determines whether the bus status is idle. If yes, step S311 is executed; otherwise, step S304 is executed.

[0077] In step S311, the master device processes the buffered packets. At this time, the master device can use the weighting formula mentioned above to calculate the priority score of the current task of each slave device.

[0078] In step S312, the master device issues PRIORITY_RESPONSE.

[0079] In step S313, it is determined whether the number of times exceeds 3. If yes, step S319 is executed; otherwise, step S314 is executed.

[0080] In step S314, the device is asked whether it accepts the assignment. If yes, step S315 is executed; otherwise, step S316 is executed.

[0081] In step S315, the master device and the slave device perform communication tasks.

[0082] In step S316, the device reports PRIORITY_ADJUST.

[0083] In step S317, the master device buffers the message.

[0084] In step S318, the master device determines whether the bus status is idle. If yes, step S311 is executed; otherwise, step S316 is executed.

[0085] In step S319, the priority is set according to the device address.

[0086] Based on this embodiment, after the master and slave devices are powered on, they can initialize the default priority of the slave devices. Then, the master device uses arbitration to enable each slave device to occupy the bus and report priority request commands. Upon receiving these priority request commands, the master device first determines whether the corresponding slave device is an authorized slave device. If the corresponding slave device is not an authorized device, the corresponding message is discarded. If the corresponding slave device is an authorized device, the message is cached, and during a bus idle period, the cached message is processed. From a global perspective, priorities are assigned to each slave device mentioned in the cached message, and the priorities of these slave devices are notified to these slave devices through priority request responses. If a slave device does not accept the assigned priority, it sends a priority adjustment request to the master device. The master device adjusts the priority allocation accordingly until the negotiation is successful or the number of negotiation attempts exceeds a threshold. After the priority negotiation is completed, the master device actively initiates the occupation of the bus by each slave device. In some embodiments, the priority negotiation process also includes fault tolerance and security mechanisms to ensure the smooth progress of priority negotiation. Specifically, these may include: timeout handling, where the master device marks the slave device as "unavailable" and temporarily lowers its priority when the slave device fails to respond within a specified time; data encryption, where the data fields (data1 to datan) of PRIORITY_RESPONSE and PRIORITY_REQUEST are encrypted using AES-128; and access control, where the master device only allows pre-authorized slave devices to participate in priority negotiation. The master device may pre-record the device addresses of slave devices allowed to participate in priority negotiation, or pre-set the number of slave devices allowed to participate in priority negotiation for access control.

[0087] Accordingly, embodiments of this disclosure also provide, as Figure 1 The system shown includes a master device and multiple slave devices, which are electrically connected via an SMBus bus. The priority negotiation communication process between the master device and the multiple slave devices includes a priority negotiation phase and a communication execution phase. The operations performed during the priority negotiation communication process are as follows: Figure 2 As shown in Figure 3. Further, the system can be a distributed embedded system, an IoT device cluster, or an industrial automation control system.

[0088] In summary, the device priority negotiation method and system based on SMBus provided in this disclosure have the following advantages: they support multi-device collaborative optimization of communication efficiency, reduce critical task latency, avoid data loss, and optimize resource utilization; they are compatible with the existing SMBus ecosystem and do not require major hardware modifications; they balance task urgency and system load through a weighting algorithm; and encryption and access control mechanisms ensure communication security and prevent malicious devices from preempting priority.

[0089] The above description is merely a preferred embodiment of this disclosure and is not intended to limit the scope of this disclosure. For those skilled in the art, various modifications and variations can be made to this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.

[0090] The embodiments of this disclosure are as described above. These embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the above description. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the embodiments of this disclosure, thereby enabling those skilled in the art to make good use of the embodiments of this disclosure and modifications based on them. The embodiments of this disclosure are limited only by the claims and their full scope and equivalents.

Claims

1. A method for inter-device priority negotiation based on SMBus, characterized in that, This involves a master device and multiple slave devices connected via an SMBus bus, wherein the master device performs the following steps: Receive priority request commands sent by multiple slave devices, wherein the priority request commands include the attribute information of the slave devices and the attribute information of the current task of the slave devices; Based on the attribute information of the slave device and the attribute information of the current task of the slave device, the priority score of the current task of the slave device is calculated, and priority request responses are sent to multiple slave devices respectively to notify the slave devices of the priority ranking of the multiple slave devices.

2. The inter-device priority negotiation method according to claim 1, characterized in that, in, When the slave device rejects the ranking of the priority score, it sends a priority adjustment request; The master device then performs the following: recalculates the priority score of the slave device, and sends priority request responses to the multiple slave devices respectively according to the recalculated priority score, so as to notify the slave devices of the new priority order of the multiple slave devices.

3. The inter-device priority negotiation method according to claim 2, characterized in that, The priority request command, the priority request response, and the priority adjustment request are obtained through the protocol portion of the extended standard SMBus command.

4. The inter-device priority negotiation method according to claim 1, characterized in that, The priority request command and / or the priority adjustment request include one or more of the following: the importance level of the slave device, the urgency of the current task of the slave device, the resource share of the current task of the slave device in the slave device, the proportion of time the slave device occupies the bus in history, and the deadline of the current task. The priority score of the current task of the slave device is related to one or more of the following: the importance level of the slave device, the urgency of the current task of the slave device, the resource ratio of the current task of the slave device in the slave device, the proportion of time the slave device occupies the bus in history, and the deadline of the current task.

5. The inter-device priority negotiation method according to claim 1, characterized in that, After the slave device is powered on, it sends a priority request command, which includes the initial attribute information of the slave device. The master device then performs the following: calculates the default priority of each of the multiple slave devices based on their initial attribute information.

6. The inter-device priority negotiation method according to claim 1, characterized in that, If the slave device fails to successfully negotiate with the master device after a timeout or after a set number of attempts, it uses the default priority; or, after lowering its own priority threshold, it resends the priority adjustment request.

7. The inter-device priority negotiation method according to claim 4, characterized in that, The formula for calculating the priority score of the current task of the slave device is as follows: , Where P(n,t) is the real-time priority of device n; E(t) represents the urgency level of a real-time event from device n; D(n) represents the importance level of device n; H(n) represents the proportion of time the slave device occupied the bus in the history; L(t) represents the resource percentage of the current task in the slave device. R(n,t) is the deadline for the current task, and α, β, γ, δ and ε are weighting coefficients.

8. The inter-device priority negotiation method according to claim 1 further includes one or more of the following: When the slave device fails to respond within a specified time, the master device marks the slave device as unavailable and temporarily lowers its priority; Encrypt the data portion of various commands; The master device only allows pre-authorized slave devices to participate in priority negotiation.

9. A system comprising: A master device and multiple slave devices are connected and communicate with each other via an SMBus bus. The master device and the multiple slave devices negotiate priorities according to the inter-device priority negotiation method according to any one of claims 1 to 8. The multiple slave devices occupy the SMBus bus in sequence according to the negotiated priority order to perform their current tasks.

10. The system according to claim 9, wherein, The system is a distributed embedded system, an Internet of Things (IoT) device cluster, or an industrial automation control system.

Images