A method for implementing strong real-time storage middleware based on layered architecture

Abstract

The present application relates to the field of strong real-time embedded environment, and is a strong real-time storage middleware implementation method based on a layered architecture. By decoupling the strong real-time embedded software and hardware, the overall structure is divided into functional components, each of which only performs a part of the function, and then the interface is unified by initializing those that can store resources. There is no need to configure multiple interface functions to transmit data, and the transmission efficiency between nodes is high. Then, all resource data are arranged in a shared area in an orderly arrangement. When the application software sends a request message, the resource data in the shared area can be found and sent to the application software by obtaining the data movement information of the resource data in the shared area. During this period, it is not necessary to read the resource data. The information transmission efficiency is high, the software portability is strong, the system resource configuration is flexible, and the software reusability and portability are high.

Description

Technical Field

[0001] The present application belongs to the field of strong real-time embedded environment, and in particular to a method for implementing strong real-time storage middleware based on a layered architecture. Background Art

[0002] With the development of network technology and "cloud" technology, distributed processing technology has become a hot topic in the field of computer software research, and how to achieve seamless storage and access to data on numerous distributed heterogeneous processing platforms has become the top priority of distributed processing technology. Storage middleware has thus emerged. It provides standard protocols for lower-level distributed systems and unified interfaces for upper-level applications, decoupling data operations from different distributed systems, achieving data interoperability and mutual access between embedded heterogeneous platforms, and making the distributed software system architecture more open. At present, the implementation and use of storage middleware technology generally exist in non-real-time distributed systems, mainly used for data movement, access and operation.

[0003] A strong real-time embedded environment refers to a software and hardware system platform that keeps processing delays below milliseconds or even microseconds and has extremely strict processing timing, such as radar signal processing or data processing software developed based on embedded hardware platforms such as DSP, PowerPC or FPGA. This type of software is based on strong real-time embedded operating systems, such as SYS / BIOS, VxWorks, etc., which are extremely sensitive to processing timing and have high requirements for system response. In addition, this type of software can run on a variety of embedded software and hardware platforms, each of which has the need to move and access data. If software is ported and reused between different platforms, it is necessary to re-move data and access interfaces on the new hardware platform, which reduces development efficiency and increases time costs.

[0004] In recent years, researchers have achieved certain results in storage middleware based on non-real-time distributed systems. For example, Li Jianhua et al. studied the structured design of pattern-oriented spatial data storage middleware, which solved two key technical problems in storage middleware: heterogeneous database integration and multi-transaction parallel processing; a storage middleware suitable for SAR information system, and proposed a storage middleware implementation method mainly used in synthetic aperture radar information system. However, there are very few related technologies and research on storage middleware technology in embedded strong real-time environment. The main reasons are the following technical difficulties:

[0005] Strong real-time embedded environments have high latency requirements, which requires that the protocol overhead of the storage middleware should not be too large;

[0006] There are many types of software and hardware platforms in strong real-time embedded environments, and it is difficult to decouple software and hardware;

[0007] The data movement and operation methods of strong real-time embedded application software are flexible and it is impossible to unify the interface.

[0008] In summary, according to the requirements of strong real-time embedded software applications, how to realize data transmission of storage middleware more efficiently and conveniently is a problem that needs to be solved. Summary of the invention

[0009] The purpose of this application is to provide a method for implementing a strong real-time storage middleware based on a layered structure to solve the problems in the prior art of high latency and inconvenient transmission caused by inconsistent interfaces of storage middleware in a strong real-time embedded environment.

[0010] The technical solution of the present application is: a method for implementing strong real-time storage middleware based on a layered architecture, including: decoupling the overall framework into several independent functional components, each functional component being a node, and using a public network for transmission between nodes; allocating all resource data in the storage space, all resource data being in a shared area of ​​all nodes, and then initializing storage resources for all resource data; the user-end node sends a request message, the sending-end node obtains all hardware resource information and obtains the resource data to be moved according to the request information, and then arranges the resource data according to the request information; obtains data movement information of the resource data; inserts the data movement information into a message queue, and then moves the data movement information from the end of the message queue to the head of the queue, the sending-end node receives the data movement information and moves the resource data to the user-end node.

[0011] Preferably, the method for moving resource data is to query all resource data that need to be moved in the node in sequence according to the request information; determine whether all resources are not idle, and if so, return to the previous step; if not, execute the next step; obtain data moving information of idle moving resources that need to be moved; move the idle moving resources according to the data moving information; and select a suitable moving method to move them to the user end.

[0012] Preferably, the migration of the idle migration resources includes one-dimensional data migration and two-dimensional data migration. When performing one-dimensional data migration, all resource data are arranged in one dimension; when performing two-dimensional data migration, all resource data are arranged in two dimensions.

[0013] Preferably, the one-dimensional data migration method of the idle migration resources includes defining a unified calling interface and parameters for one-dimensional data migration; obtaining the status of the hardware resources of each node, and determining the hardware resources to be used for data migration operations based on their status; obtaining user-side interface parameters, and extracting data migration information for one-dimensional data migration; determining the data migration method used by the user side, and inserting the data migration information into a message queue according to different positioning migration methods; calling the one-dimensional data migration interface to migrate data, and performing error monitoring.

[0014] Preferably, the two-dimensional data migration method of the idle migration resources includes defining a unified calling interface for two-dimensional data migration and its parameters; obtaining the hardware resource status of each node, and determining the use of corresponding hardware resources for data migration operations based on its status; obtaining user interface parameters and extracting data migration information for two-dimensional data migration; determining the data migration method used by the user end, and inserting the data migration information into a message queue according to different positioning migration methods; calling the two-dimensional data migration interface to migrate data, and performing error monitoring.

[0015] Preferably, the data migration information of the one-dimensional data migration method includes a source address, a destination address, a source step, a destination step, a blocking flag and a migration data length.

[0016] Preferably, the data moving information of the two-dimensional data moving method includes a source address, a destination address, a source row step, a source column step, a destination row step, a destination column step, a moving data length, a blocking flag and a transposition flag.

[0017] Preferably, the transfer mode is blocking transfer. When blocking transfer is adopted, the corresponding node does not run other functions at the same time, only performs blocking transfer and then waits for the data transfer to the user end to be completed and ends the transfer.

[0018] Preferably, the transport mode is non-blocking transport, and the transport method of the non-blocking transport is to determine whether the resource queue is full, and if so, report an error message; if not, execute the next step; insert the current hardware resources into the waiting queue; check the resource queue to determine whether it is a non-blocking move, and if not, exit the move function; if so, execute the next step; wait for the resource data move to be completed and release the resource queue space.

[0019] As a specific implementation method, a strong real-time storage middleware implementation system based on a layered architecture includes a hardware resource storage unit, including storage resource allocation and storage resource initialization, wherein the storage resource allocation is used to allocate hardware resources to each processing core of an embedded hardware processor; the storage resource initialization is used for each processing core of the embedded hardware processor to perform initialization operations on the allocated hardware resources; a first application interface layer, used to define a one-dimensional data migration unified calling interface and its parameters; a first device abstraction layer, used to obtain hardware resource status and user interface parameters, and insert hardware data into a message queue according to data migration information; a first device driver layer, used to call the underlying one-dimensional data migration interface to migrate data and perform error monitoring; a second application interface layer, used to define a two-dimensional data migration unified calling interface and its parameters; a second device abstraction layer, used to obtain hardware resource status and user interface parameters, and insert hardware data into a message queue according to data migration information; a second device driver layer, used to call the underlying two-dimensional data migration interface to migrate data and perform error monitoring.

[0020] The present application discloses a strong real-time storage middleware implementation method based on a layered architecture, which decouples strong real-time embedded software from hardware, divides the overall structure into functional components, each of which performs only a part of the function, and then unifies the interface by initializing those resources that can store them. There is no need to configure multiple interface functions to transmit data, and the transmission efficiency between nodes is high. All resource data are then arranged in a shared area in an orderly manner. When the application software sends a request message, the resource data in the shared area can be found and sent to the application software by obtaining data movement information of the resource data in the shared area. During this period, there is no need to read the resource data. The information transmission efficiency is high, the software portability is strong, the system resource configuration is flexible, and the software reusability and portability are high. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solution provided by the present application, the following is a brief introduction to the accompanying drawings. Obviously, the accompanying drawings described below are only some embodiments of the present application.

[0022] Figure 1 This is a schematic diagram of the overall process structure of this application;

[0023] Figure 2 A schematic diagram of the resource allocation method within the core for this application processing;

[0024] Figure 3 This is a schematic diagram of the overall migration process of hardware resources for this application;

[0025] Figure 4 This is a schematic diagram of the one-dimensional data migration process for this application;

[0026] Figure 5 This is a schematic diagram of the one-dimensional data movement operation of this application;

[0027] Figure 6 This is a schematic diagram of the two-dimensional data migration process for this application;

[0028] Figure 7 This is a schematic diagram of the two-dimensional data movement operation of this application;

[0029] Figure 8 This is a schematic diagram of the overall system structure of this application. DETAILED DESCRIPTION

[0030] In order to make the purpose, technical solutions and advantages of the implementation of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below in conjunction with the drawings in the embodiments of this application.

[0031] A method for implementing a strong real-time storage middleware based on a layered structure, such as Figure 1 , Figure 2 As shown, the following steps are included:

[0032] Step S100, decoupling the overall framework into several independent functional components, each of which is a node, and the node includes a processing core, application software and hardware resources, and the nodes are transmitted using a public network;

[0033] Step S200, all resource data are allocated in the storage space, all resource data are in the shared area of ​​all nodes, and the allocated resource data are initialized for storage resources; when allocating resources, storage resources such as EDMA channel number, controller number, etc. are allocated manually or according to the configuration file, and stored in the internal resource array; the storage resources of each processing core are initialized by calling the storage initialization button of the underlying hardware;

[0034] Step S300, the user end node sends a request message, the sending end node obtains all hardware resource information and obtains resource data to be moved according to the request message, and then arranges the resource data according to the request message;

[0035] Step S400, obtain the data movement information of the resource data, through which all the information required for the movement can be found and moved to the application software; the data movement information is inserted into the message queue, and then the data movement information is moved from the end of the message queue to the head of the queue, and the sending node receives the data movement information and moves the resource data to the user node.

[0036] By decoupling the strong real-time embedded software and hardware, there are only receiving, sending, calling and other relationships between the hardware, processing core and application software. By first placing the data operation hardware resources of each processing core into a public area and recording the address information of each hardware resource, at the user end, that is, when the application software sends a request information, the corresponding processing core can find the required resource data according to the request information and record the data movement information required to move the resource data to the application software. The resource data required by the application software can be moved to the application software through the data movement information.

[0037] In this process, resource data does not need to be read. Only interface information, data movement information and other information with less content need to be transmitted between nodes. The information transmission efficiency is improved, which greatly enhances the portability of the software. At the same time, strong real-time embedded software systems can be quickly developed through software definition, and system resource configuration, function expansion and performance improvement can be flexibly realized. By initializing resources, the data operation interface can be unified and simplified, so that the application software only needs to focus on the implementation of functional algorithms and does not need to care about the underlying data movement processing, which greatly reduces the workload of software developers; at the same time, it shortens the software development cycle and improves the reusability and portability of the software.

[0038] like Figure 3 As shown, preferably, the method for moving hardware resources includes:

[0039] Step S410, querying all resource data that needs to be moved in the node in sequence according to the request information;

[0040] Step S420, determine whether all resources are not idle, if so, return to the previous step; if not, execute the next step; obtain the relevant EDMA controller ID and channel ID by querying the resource data, and then obtain the EDMA channel controller handle, query the flag bit, if it is 0, it means that this channel is idle, if it is 1, it means that this channel is busy;

[0041] Step S430, obtaining data migration information of idle migration resources that need to be migrated;

[0042] Step S440, the idle migration resources are migrated according to the data migration information. The migration information is obtained by the request information of the client, and the request information contains the required migration method. If it is indicated that a one-dimensional migration method is adopted, all the hardware resources are arranged in one dimension to wait for migration; if it is indicated that a two-dimensional migration method is adopted, all the hardware resources are arranged in two dimensions to wait for migration;

[0043] Step S450, selecting a suitable transport method to transport to the user end.

[0044] After finding all the resource data that needs to be moved, there is a situation where the resource data package is in a non-idle state and cannot be moved. By querying all the hardware resources that need to be moved, you can quickly find the idle resource data package for migration, thereby achieving stable migration of resource data. When all resource data is in a non-idle state, it cannot be moved.

[0045] Preferably, the migration of idle migration resources includes one-dimensional data migration and two-dimensional data migration. When performing one-dimensional data migration, all resource data are arranged in one dimension; when performing two-dimensional data migration, all resource data are arranged in two dimensions. According to different user needs, some users need a one-dimensional data migration method, and some users need a two-dimensional data migration method. By setting two migration methods, different user needs can be met. The one-dimensional data migration method and the two-dimensional data migration method are two parallel migration methods.

[0046] like Figure 4 , Figure 5 As shown, preferably, the one-dimensional data migration method of the idle migration resource includes:

[0047] Step S451, defining a unified calling interface for one-dimensional data migration and its parameters;

[0048] Step S452, obtaining the status of the hardware resources of each node, and determining the hardware resources to be used for data migration operation according to the status;

[0049] Step S453, obtaining a user terminal interface parameter, the parameter is obtained through the request information of the user terminal, and extracting data migration information of one-dimensional data migration;

[0050] Step S454, determining the data transfer mode used by the user end, and inserting the data transfer information into the message queue according to different positioning transfer modes; specifically, determining by a blocking signal, and using different transfer modes in blocking and non-blocking situations;

[0051] Step S455, calling a one-dimensional data migration interface to migrate data and perform error monitoring.

[0052] like Figure 6 , Figure 7 As shown, as a parallel method, the two-dimensional data migration method of the idle migration resource includes:

[0053] Step S451, defining a unified calling interface for two-dimensional data migration and its parameters;

[0054] Step S452, obtaining the hardware resource status of each node, and determining to use the corresponding hardware resource to perform the data migration operation according to the status;

[0055] Step S453, obtaining user interface parameters, which are obtained through request information from the user end, and extracting data migration information of two-dimensional data migration;

[0056] Step S454, determining the data transfer mode used by the user end, and inserting the data transfer information into the message queue according to different positioning transfer modes; specifically, determining by a blocking signal, and using different transfer modes in blocking and non-blocking situations;

[0057] Step S455, calling the two-dimensional data migration interface to migrate data and perform error monitoring.

[0058] By dividing the processing core into multiple separate units, each unit is used to perform different functions to achieve effective movement of one-dimensional or two-dimensional data. One unit is responsible for the unified call of the interface and its parameters, one unit is responsible for the acquisition and transmission of data movement information of hardware resources, and the last unit is responsible for data movement. The units work together to complete the data movement.

[0059] Preferably, the data migration information of the one-dimensional data migration method includes information such as source address, destination address, source step, destination step, blocking flag and migration data length.

[0060] The data moving information of the two-dimensional data moving method includes information such as source address, destination address, source row step, source column step, destination row step, destination column step, moving data length, blocking flag and transposition flag.

[0061] Preferably, when transferring data to an application, the processing core can select different transfer modes according to the needs, specifically, judging and processing by the obtained blocking flag. If the blocking flag is 1, the processing core waits for the data transfer to be completed before proceeding to the next operation, that is, blocking transfer is adopted; if the blocking flag is 0, the current data transfer information is saved in the data and waits for the next processing, and non-blocking transfer is adopted. When the transfer mode is blocking transfer, the corresponding node does not run other functions at the same time when blocking transfer is adopted, and only blocking transfer is performed and then the data transfer to the user end is completed and the transfer is ended.

[0062] like Figure 3 As shown, when the transport mode is non-blocking transport, the transport method of non-blocking transport is:

[0063] Step S460, determining whether the resource queue is full, if it is full, reporting an error message; if it is not full, executing the next step;

[0064] Step S470, inserting the current hardware resource into the waiting queue;

[0065] Step S480, check the resource queue to determine whether it is a non-blocking migration, if not, exit the migration function; if yes, execute the next step;

[0066] Step S490, waiting for the resource data migration to be completed and releasing the resource queue space.

[0067] like Figure 8 As shown, as a specific implementation method, it also includes a strong real-time storage middleware implementation system based on a layered architecture, including a hardware resource storage unit; a first application interface layer, a first device abstraction layer, and a first device driver layer for one-dimensional data migration; a second application interface layer, a second device abstraction layer, and a second device abstraction layer for two-dimensional data migration.

[0068] The hardware resource storage unit includes storage resource allocation and storage resource initialization, wherein the storage resource allocation is used to allocate hardware resources to each processing core of the embedded hardware processor; the storage resource initialization is used for each processing core of the embedded hardware processor to perform initialization operations on the allocated hardware resources; the first application interface layer is used to define a one-dimensional data migration unified calling interface and its parameters; the first device abstraction layer is used to obtain the hardware resource status and user interface parameters, and insert the hardware data into the message queue according to the data migration information; the first device driver layer is used to call the underlying one-dimensional data migration interface to migrate data and perform error monitoring; the second application interface layer is used to define a two-dimensional data migration unified calling interface and its parameters; the second device abstraction layer is used to obtain the hardware resource status and user interface parameters, and insert the hardware data into the message queue according to the data migration information; the second device driver layer is used to call the underlying two-dimensional data migration interface to migrate data and perform error monitoring.

[0069] By decomposing the overall functions of the processing core and adjusting the coupling degree between each unit, it is possible to flexibly implement system resource configuration, data transmission between the processing core and application software, data delivery and other functions, greatly enhancing the portability of the software.

[0070] As a specific implementation method, a specific example is used to illustrate:

[0071] This part is based on the TI TMS320C6678 DSP hardware platform, and elaborates on the storage resource configuration of the storage middleware, the implementation of the one-dimensional data movement function, and the implementation process of the two-dimensional data movement function.

[0072] A storage middleware stores resource configuration, such as Figure 2 Shown

[0073] Storage resource allocation:

[0074] Create the hardware resource array g_DevResNum of each processing core of C6678, and set the maximum capacity of the array to 6. The attribute information of each element in the array is shown in Table 1.

[0075] Allocate the hardware handling resources of each processing core of C6678. Here, the EDMA controller ID and channel ID that each core can use are mainly allocated, and the allocation results are saved in the resource array g_DevResNum.

[0076] Table 1 Hardware resource attribute information

[0077]

[0078] Storage resource initialization: Call the C6678 underlying hardware storage initialization BSP interface lh_edma3_open() to initialize the storage resources of each processing core.

[0079] Second, the storage middleware realizes the one-dimensional data migration function. The implementation process is as follows Figure 3 Shown

[0080] Application interface layer: defines one-dimensional data transfer interface parameters, as shown in Table 2

[0081] Table 2 One-dimensional data transfer interface parameters

[0082]

[0083] 1) Device abstraction layer:

[0084] Get the current status of the storage resources in the processing core: query the resource array

[0085] g_DevResNum, get the relevant EDMA controller ID and channel ID, get the EDMA channel control handle according to the controller ID and channel ID

[0086] CSL_Edma3ChannelHandle, query the handle flag TPCC_CCSTAT, if it is 0, it means that this channel is in idle state, save this EDMA channel information to the variable g_HW_Info, if it is 1, it means that this channel is busy, then continue to query the next EDMA channel information of the processing core until an idle channel is found;

[0087] According to the user interface parameters in Table 2 and the queried channel information g_HW_Info, extract the data information on a continuous storage space according to the source address and source step, and then store the data in the destination memory in sequence according to the destination address and destination step. The number of bytes transferred is determined by the length of the moved data and the unit data length. Finally, obtain the EDMA controller ID and channel ID saved in the variable g_HW_Info, and start the data transfer operation. The one-dimensional data transfer diagram is shown in the figure. Figure 4 As shown;

[0088] The obtained blocking flag is judged and processed. If the blocking flag is 1, the processing core waits for the data transfer to be completed before the next step. If the blocking flag is 0, the current data transfer information is saved in the array g_WaitInfoBuf and waits for the next step. The saved transfer information is shown in Table 1.

[0089] 2) Device driver layer: Call the C6678 underlying EDMA data transfer interface lh_ext_edma3() and the data transfer completion interface lh_edma3_wait() to complete the data transfer operation from the source address to the destination address.

[0090] The three-dimensional data migration function of the storage middleware is realized, and the implementation process is as follows Figure 3 Shown

[0091] 1) Define the two-dimensional data transfer interface parameters, as shown in Table 3.

[0092]

[0093]

[0094] 2) Device abstraction layer:

[0095] Get the current status of the storage resources in the processing core: query the resource array

[0096] g_DevResNum, get the relevant EDMA controller ID and channel ID, get the EDMA channel control handle according to the controller ID and channel ID

[0097] CSL_Edma3ChannelHandle, query the handle flag TPCC_CCSTAT, if it is 0, it means that this channel is in idle state, save this EDMA channel information to the variable g_HW_Info, if it is 1, it means that this channel is busy, then continue to query the next EDMA channel information of the processing core until an idle channel is found;

[0098] According to the user interface parameters in Table 3 and the queried channel information g_HW_Info, extract the data information on a continuous storage space according to the source address, source column stepping, and source row stepping, and then store the data in the destination memory in sequence according to the destination address, destination column stepping, and destination row stepping. The number of bytes transferred is determined by the number of rows and columns of the moved data and the unit data length. Finally, obtain the EDMA controller ID and channel ID saved in the variable g_HW_Info, and start the data transfer operation. The schematic diagram of two-dimensional data transfer is shown in the figure. Figure 5 As shown;

[0099] The obtained blocking flag is judged and processed. If the blocking flag is 1, the processing core waits for the data transfer to be completed before the next step. If the blocking flag is 0, the current data transfer information is saved in the array g_WaitInfoBuf and waits for the next step. The saved transfer information is shown in Table 1.

[0100] 3) Device driver layer: Call the C6678 underlying EDMA data transfer interface lh_ext_edma3() and the data transfer completion interface lh_edma3_wait() to complete the data transfer operation from the source address to the destination address.

[0101] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A method for implementing strong real-time storage middleware based on a layered architecture, characterized in that: include, Decouple the overall framework into several independent functional components, each of which is a node, and nodes are transmitted using a public network; All resource data are allocated in the storage space. All resource data are in the shared area of ​​all nodes, and then the storage resources of all resource data are initialized; The user end node sends a request message, the sending end node obtains all the hardware resource information and obtains the resource data that needs to be moved according to the request message, and then arranges the resource data according to the request message; Obtaining data movement information of resource data; inserting the data movement information into the message queue, and then moving the data movement information from the end of the message queue to the head of the queue, the sending end node receiving the data movement information and moving the resource data to the user end node; The method for moving the resource data is as follows: Query all resource data that needs to be moved in the node in turn according to the request information; Determine whether all resources are not idle. If so, return to the previous step; if not, execute the next step; Obtain data migration information of idle migration resources that need to be migrated; Migrate idle migration resources according to data migration information; Choose a suitable transport method to transport to the user end; The migration of the idle migration resources includes one-dimensional data migration and two-dimensional data migration. When performing one-dimensional data migration, all resource data are arranged in one dimension. When moving two-dimensional data, all resource data are arranged in two dimensions; The one-dimensional data migration method of the idle migration resource includes: Define the unified calling interface and parameters for one-dimensional data migration; Obtain the status of the hardware resources of each node, and determine the hardware resources to be used for data migration operations based on the status; Obtain user-side interface parameters and extract data movement information for one-dimensional data movement; Determine the data transfer method used by the user end, and insert the data transfer information into the message queue according to different positioning transfer methods; Call the one-dimensional data migration interface to migrate data and perform error monitoring; The two-dimensional data migration method of the idle migration resource includes: Define the unified calling interface and parameters for 2D data migration; Obtain the hardware resource status of each node, and determine the use of corresponding hardware resources for data migration operations based on the status; Obtain user interface parameters and extract data movement information for two-dimensional data movement; Determine the data transfer method used by the user end, and insert the data transfer information into the message queue according to different positioning transfer methods; Call the two-dimensional data migration interface to migrate data and perform error monitoring.

2. The method for implementing a strong real-time storage middleware based on a layered architecture as claimed in claim 1, characterized in that: The data transfer information of the one-dimensional data transfer method includes a source address, a destination address, a source step, a destination step, a blocking flag and a transfer data length.

3. The method for implementing strong real-time storage middleware based on layered architecture as claimed in claim 1, characterized in that: The data moving information of the two-dimensional data moving method includes a source address, a destination address, a source row step, a source column step, a destination row step, a destination column step, a moving data length, a blocking flag and a transposition flag.

4. The method for implementing strong real-time storage middleware based on layered architecture as claimed in claim 1, characterized in that: The transport mode is blocking transport. When blocking transport is adopted, the corresponding node does not run other functions at the same time, only performs blocking transport and then waits for the data to be moved to the user end to be completed, and then ends the transport.

5. The method for implementing strong real-time storage middleware based on layered architecture as claimed in claim 1, characterized in that: The transport mode is non-blocking transport, and the transport method of the non-blocking transport is: Determine whether the resource queue is full. If so, report an error message; if not, proceed to the next step. Insert the current hardware resource into the waiting queue; Check the resource queue to determine whether it is a non-blocking migration. If not, exit the migration function; if yes, proceed to the next step; Wait for resource data migration to complete and release resource queue space.

Images