A supervision and report integrated machine system based on hardware and software integration

Abstract

The present application relates to the technical field of finance and banking, and discloses a supervision reporting integrated machine system based on software and hardware integration, which comprises a compiling module, an access module, a scheduling module and an aggregation module.The compiling module parses supervision specifications into a fixed-width compliance state bit string and binds the bit string to the physical core of a multi-core processor to establish a hardware verification topology path.The access module writes business flow data into a physical memory pool and allocates a data physical pointer and a compliance state bitmap.The scheduling module executes compliance verification logic by using the data physical pointer according to the hardware verification topology path, and updates the compliance state bitmap when the execution is passed.The aggregation module reorganizes business flow data into a huge physical memory page by using a data flow accelerator when the updated compliance state bitmap meets a mask condition.The sending module triggers an encryption accelerator card to generate ciphertext data based on the starting address of the huge physical memory page and sends the ciphertext data through a network interface card.The present application avoids cross-core copying of full data, reduces hardware bus communication delay, and improves the execution efficiency of concurrent verification.

Description

Technical Field

[0001] This invention relates to the field of financial and banking technology, specifically to a regulatory reporting integrated system based on software and hardware integration. Background Technology

[0002] With the increasing concurrency of financial transactions, regulatory agencies are continuously raising their requirements for the timeliness and security of business transaction data reporting. Massive amounts of data need to undergo multi-branch compliance verification and encrypted transmission within a very short time. Traditional pure software reporting systems easily reach the bottleneck of general-purpose processor computing power when facing high-concurrency data streams, making it difficult to meet the low-latency processing requirements. Therefore, there is an urgent need for a hardware and software integrated architecture to improve the overall performance of the reporting system.

[0003] Existing technologies primarily rely on multi-core processors and multi-threaded software architectures to handle regulatory reporting tasks. After receiving business transaction data, the system parses the regulatory rules through different thread pools and copies the entire data body multiple times in memory, distributing it to different physical cores for concurrent comparison. In the verification result aggregation stage, the system uses mutex locks at the software level to synchronize the execution states of multiple threads. Finally, a general-purpose processor runs an Advanced Encryption Standard (AES) algorithm to encrypt the plaintext and sends it to the regulatory server via the operating system's network protocol stack.

[0004] While existing technologies utilize multi-threaded concurrency mechanisms to complete compliance verification and transmission of business data, some shortcomings remain: In multi-core architectures, operating system scheduling causes verification threads to migrate randomly between different physical cores, resulting in a large number of cross-node memory accesses and exacerbating bus communication latency; the full data cross-core copying during the task distribution phase severely wastes bus bandwidth, and software mutexes are prone to write conflicts and cache line pseudo-share failures during multi-core concurrent synchronization, causing state update blocking; during the network reporting phase, pure software cryptographic operations significantly increase the computational burden on general-purpose processors, and due to the lack of traffic shaping strategies based on the underlying clock, sudden bursts of data packets are easily injected into the physical link, leading to congestion and packet loss in downstream network devices. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a hardware and software integrated regulatory reporting system, which solves the problems of bus communication delays and general processor computing power bottlenecks caused by random migration of execution threads, cross-core copying of full data, and software cryptographic operations when processing high-concurrency data in existing reporting systems.

[0006] To achieve the above objectives, this invention provides a hardware-software integrated regulatory reporting system, running in a hardware environment configured with a multi-core processor, a data stream accelerator, a network interface card, and an encryption acceleration card, comprising:

[0007] The compilation module is used to parse the regulatory specifications into a fixed-width compliance status bit string and bind it to the multi-core processor, thus establishing a hardware verification topology path.

[0008] The access module is used to write business flow data into the physical memory pool and allocate data physical pointers and compliance status bitmaps according to the fixed-width compliance status bit string.

[0009] The scheduling module is used to flow the data physical pointer along the hardware verification topology path to execute compliance verification logic, and update the compliance status bitmap when the execution is successful.

[0010] The aggregation module is used to schedule the data stream accelerator to reassemble the business flow data into a giant physical memory page when the updated compliance status bitmap meets the mask conditions.

[0011] The sending module is used to trigger the encryption acceleration card to generate ciphertext data based on the starting address of the giant physical memory page and send it through the network interface card.

[0012] Preferably, the compilation module includes: a specification parsing unit, used to receive externally loaded regulatory specification files and analyze them, decomposing the macro-level verification logic into multiple basic verification operators;

[0013] The graph construction unit is used to map multiple basic verification operators to execution nodes in a graph structure, analyze the data dependencies between the basic verification operators, generate directed edges between the execution nodes with dependencies, and generate a fixed-width compliant state bit string with execution order constraints based on the combination of the execution nodes and the directed edges.

[0014] The weight evaluation unit is used to identify mutually independent connected subgraphs in the fixed-width compliant state bit string, and accumulate the estimated execution clock cycles of each basic check operator in the subgraph to obtain the computational complexity weight of each connected subgraph.

[0015] The topology binding unit is used to allocate resources according to the computational complexity weight, set the processor mask, bind the execution logic of each connected subgraph to the physical core specified in the multi-core processor, and determine the physical memory area in the same hardware bus control domain as the physical core as the corresponding local memory node, so as to establish the hardware verification topology path of the system.

[0016] Preferably, the processor mask is set by calling the processor affinity interface of the operating system.

[0017] Preferably, the access module includes:

[0018] The bypass receiving unit is used to bypass the operating system kernel network stack through the direct memory access engine of the network interface card and receive the externally input service pipeline data body.

[0019] A memory pool partitioning unit is used to pre-allocate contiguous physical space in the local memory nodes corresponding to the multi-core processor in order to construct a physical memory pool.

[0020] The pipeline construction unit is used to construct a non-consistent memory access aware memory pipeline in the local memory node and divide the non-consistent memory access aware memory pipeline into a business data payload area and a metadata control area.

[0021] The metadata allocation unit is used to store the business flow data body in the business data payload area in an append-only manner, and to continuously allocate the corresponding data physical pointer and the compliance status bitmap in the metadata control area.

[0022] Preferably, the data physical pointer points to the absolute memory index of the physical starting address of a single business transaction data entry within the business data payload area.

[0023] Preferably, the metadata allocation unit is further configured to dynamically determine the bit width length of the compliance status bitmap based on the number of execution nodes of the fixed-width compliance status bit string.

[0024] Preferably, the scheduling module includes:

[0025] The pointer transfer unit is used to establish a lock-free circular queue between adjacent physical cores in the same hardware verification topology path, and push the data physical pointer into the lock-free circular queue for downstream physical cores to obtain;

[0026] The rule addressing unit is used to address across inconsistent memory access nodes according to the obtained data physical pointer, and read the business flow data body stored in the business data payload area, and use the business flow data body to control the current physical core to execute the compliance verification logic allocated to the current physical core.

[0027] The state reconstruction unit is used to call the hardware bus locking atomic instruction of the multi-core processor to update the compliance state bitmap in place when the compliance verification logic passes.

[0028] Before performing the logical shift operation, the topology index value of the execution node mapped in the fixed-width compliance state bit string of the currently executed compliance verification logic is checked for boundary legality.

[0029] After the boundary validity verification is passed, logical shift and bitwise OR operations are performed on the compliance status bitmap based on the topology index value to obtain the updated compliance status bitmap, and the updated compliance status bitmap is stored in the metadata control area.

[0030] Preferably, the aggregation module includes:

[0031] The status monitoring unit is hard-bound to a dedicated idle physical core in the multi-core processor and is used to read the updated compliance status bitmap in the metadata control area through an independently running status monitoring daemon thread.

[0032] The mask matching unit is used to perform a bitwise AND operation between the updated compliance status bitmap and the preset signature mask; and when the result of the bitwise AND operation is exactly the same as the preset signature mask in the underlying binary value, it determines that the updated compliance status bitmap satisfies the mask condition.

[0033] The descriptor construction unit is used to extract the data physical pointer as the source memory absolute address after determining that the mask condition is met, and calculate the target physical address by combining it with the existing data tail offset of the pre-allocated giant physical memory page; when it is determined that the existing data tail offset plus the actual byte length of the business pipeline data to be copied does not exceed the physical capacity limit of the giant physical memory page, the source memory absolute address, the target physical address and the actual byte length are encapsulated into a memory block copy descriptor.

[0034] The hardware coordination unit is used to submit the memory block copy descriptor to the hardware command queue of the data stream accelerator to trigger the data stream accelerator to complete the reassembly.

[0035] Preferably, the sending module includes:

[0036] An encryption encapsulation unit is used to encapsulate the starting address and total data length of the giant physical memory page into a hardware encryption request descriptor and submit it to the encryption acceleration card, triggering the encryption acceleration card to read the business pipeline data and perform pipeline encryption, generate ciphertext data and write it into the isolated secure memory page;

[0037] The traffic shaping unit is used to maintain the rate limiting queue state machine based on the token bucket mechanism. In each physical hardware scheduling cycle, the rate limiting queue state machine is triggered to dynamically calculate the currently available data transmission quota based on the time span of the read multi-core processor hardware clock.

[0038] Preferably, when the currently available data transmission quota is greater than the actual byte length of the encrypted data, the physical link is in a hardware connectivity state, and the hardware transmission descriptor margin is greater than a preset security level threshold, the traffic shaping unit issues a transmission admission signal.

[0039] The present invention provides a software and hardware integrated regulatory reporting system, which has the following advantages:

[0040] This invention constructs a low-level physical acceleration pipeline that completely separates the data plane from the control plane through the coordinated hardware and software of five modules: access module, compilation module, scheduling module, sending module, and aggregation module. The access module directly deposits massive amounts of business pipeline data into a physical memory pool and extracts data physical pointers and fixed-width compliance status bit strings. In conjunction with the compilation module, the underlying regulatory specifications are pre-hardened into a directed acyclic topology and hardware verification topology path for the verification operator. This allows the scheduling module and sending module to completely abandon the handling of the business data itself, and only flow lightweight data physical pointers along the predetermined hardware path to drive the compliance verification logic. Finally, the aggregation module directly reassembles the data into a giant physical memory page based on the passed status.

[0041] This invention physically isolates the business data payload area from the metadata control area within the memory pipeline. During multi-core verification scheduling, only the physical pointer to the data and a fixed-length compliance status bitmap are transmitted. The underlying hardware bus of the multi-core processor is used to lock atomic instructions to perform in-situ updates to the bitmap. This mechanism abandons the traditional full data cross-core copy and software-level mutex locks. While completely avoiding bus bandwidth waste and cache line pseudo-share failures, it solves the state write conflict problem in a multi-core concurrent environment, achieving low-latency, non-blocking flow of verification data.

[0042] This invention utilizes an aggregation module to schedule a data stream accelerator, reassembling discrete data into physically aligned giant physical memory pages. A sending module then triggers an encryption accelerator card to perform low-level pipelined encryption, combined with a token bucket-based rate-limiting queue state machine to complete network transmission. By offloading intensive memory movement and cryptographic operations to a dedicated hardware engine, the system significantly reduces the computational burden on general-purpose processors. Simultaneously, a multi-dimensional traffic shaping strategy precisely constrains the injection rate of bursty data packets, preventing instantaneous overload from causing congestion and packet loss in downstream network devices, thus ensuring transmission stability in high-throughput regulatory reporting scenarios. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the overall architecture of the integrated regulatory reporting system based on hardware and software integration, according to an embodiment of the present invention.

[0044] Figure 2 This is a schematic diagram of the logical structure of the compilation module in an embodiment of the present invention;

[0045] Figure 3 This is a schematic diagram of the logical structure of the access module according to an embodiment of the present invention;

[0046] Figure 4 This is a schematic diagram of the logical structure of the scheduling module in an embodiment of the present invention;

[0047] Figure 5 This is a schematic diagram of the logical structure of the aggregation module in an embodiment of the present invention;

[0048] Figure 6 This is a schematic diagram of the logical structure of the sending module according to an embodiment of the present invention;

[0049] Figure 7 This is a comparison chart of system performance tests under a complex rule topology according to an embodiment of the present invention.

[0050] Among them, 10 is the compilation module; 20 is the access module; 30 is the scheduling module; 40 is the aggregation module; and 50 is the sending module. Detailed Implementation

[0051] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] like Figure 1 As shown, Figure 1 This is a schematic diagram of the overall architecture of a hardware-software integrated regulatory reporting system according to an embodiment of the present invention. The embodiment of the present invention provides a hardware-software integrated regulatory reporting system, which operates in a hardware environment configured with a multi-core processor, a data stream accelerator, a network interface card, and an encryption accelerator card. The hardware-software integrated regulatory reporting system includes: a compilation module 10, an access module 20, a scheduling module 30, an aggregation module 40, and a sending module 50.

[0053] The compilation module 10 parses the input regulatory specifications into a fixed-width compliance state bit string and calculates the computational complexity weight of each independent connected topology branch within the fixed-width compliance state bit string. Each execution node configured within the fixed-width compliance state bit string is physically hard-mapped to a low-level verification instruction block that can be directly decoded and executed by the multi-core processor. The unidirectional dependency links configured within the fixed-width compliance state bit string represent the mandatory sequential read-write association of data in memory. The acyclic characteristic provides a deterministic computational convergence guarantee for the finite state machine of the underlying hardware at the physical architecture level, completely avoiding processor physical core deadlock or infinite system hardware bus occupancy anomalies caused by circular verification at the physical execution level. This is a technical means of transforming upper-layer compliance business logic into a schedulable entity structure of the computer's underlying hardware. The compilation module 10 is also used to bind the execution logic of each independent connected topology branch to a specified physical core and corresponding local memory node in the multi-core processor according to the computational complexity weight through the processor affinity interface of the operating system, in order to establish the hardware verification topology path of the system for subsequent use by the scheduling module 30.

[0054] Access module 20 receives externally input service pipeline data and writes it to a pre-allocated physical memory pool by bypassing the operating system kernel network stack through the direct memory access engine of the network interface card. Access module 20 also constructs a non-consistent memory access-aware memory pipeline in the physical memory pool and, based on the execution node count characteristics of the directed acyclic topology generated by the compilation module 10, allocates a corresponding data physical pointer and a fixed-width compliance status bit string for each piece of service pipeline data written. It should be noted that the execution node count characteristic refers to the total number of underlying verification instruction blocks within the topology, used to determine the physical addressing boundary of the multi-core processor hardware cache byte alignment; the fixed-width compliance status bit string refers to the physical memory state space continuously allocated for service pipeline data in the memory pipeline, where internal physical binary bits establish an underlying hardware address mapping with specific execution nodes, and the physical bit width is statically locked to provide an exclusive physical target for lock-free concurrent updates. Subsequently, access module 20 outputs the data physical pointer and fixed-width compliance status bit string to scheduling module 30.

[0055] The scheduling module 30 receives the data physical pointer and fixed-length compliance status bitmap transmitted by the access module 20, and strictly follows the hardware verification topology path established by the compilation module 10 to transmit the data physical pointer and fixed-length compliance status bitmap between the corresponding physical cores of the multi-core processor. The scheduling module 30 is also used to read business flow data according to the data physical pointer to control the physical core to execute compliance verification logic, and when the compliance verification logic passes, it calls the atomic instructions of the multi-core processor to update the corresponding bits of the fixed-length compliance status bitmap to obtain the updated compliance status bitmap. The updated compliance status bitmap resides in the non-consistent memory access aware memory pipeline for the aggregation module 40 to read.

[0056] The aggregation module 40 continuously polls the updated compliance status bitmap residing in the non-consistent memory access awareness memory pipeline via an independently running status monitoring daemon thread within the system. When the updated compliance status bitmap is determined to meet preset signature mask conditions, the aggregation module 40 generates a memory block copy descriptor based on the data physical pointer passed by the scheduling module 30 and submits it to the data flow accelerator. This triggers the data flow accelerator to copy the business pipeline data written by the access module 20 across processor cores and arrange them consecutively into pre-allocated giant physical memory pages based on the memory block copy descriptor. It is important to note that a giant physical memory page refers to a contiguous physical memory block with a fixed size of two megabytes or 1 GB, pre-allocated by the underlying memory management unit, distinct from the standard four-kilobyte discrete memory pages allocated by the operating system by default. Using giant physical memory pages in reorganization scenarios can bypass traditional multi-level page table addressing mechanisms, reducing the page swapping miss rate of the translation backing buffer at the hardware physical level and avoiding page faults that could block the direct memory access engine. After completing the physical alignment of the business flow data, the aggregation module 40 notifies the sending module 50 of the giant physical memory page.

[0057] The sending module 50 receives the giant physical memory page notified by the aggregation module 40. When it determines that the amount of continuously arranged business pipeline data in the giant physical memory page reaches a preset hash aggregation threshold, it writes the physical starting address of the giant physical memory page into the control register of the encryption acceleration card. The sending module 50 is also used to trigger the encryption acceleration card to read the business pipeline data as plaintext data across the hardware bus and perform pipeline encryption to obtain ciphertext data based on the physical starting address of the giant physical memory page. Then, it writes the ciphertext data into the outgoing ciphertext ring buffer through an asynchronous loopback mechanism and generates a hardware completion event to trigger the network interface card to read the ciphertext data from the outgoing ciphertext ring buffer and perform network transmission.

[0058] Based on the relationships between the various modules, the overall workflow of the integrated regulatory reporting system based on hardware and software integration is as follows:

[0059] During system initialization, the compilation module 10 generates a fixed-width compliance status bit string and establishes the system's hardware verification topology path. In the data processing phase, the access module 20 receives business pipeline data, establishes a non-consistent memory access-aware memory pipeline, and generates a data physical pointer and a fixed-length compliance status bitmap, which are then processed by the scheduling module 30. The scheduling module 30 uses the data physical pointer to schedule the business pipeline data along the hardware verification topology path established by the compilation module 10, executes compliance verification logic, and updates the fixed-length compliance status bitmap in situ to obtain the updated compliance status bitmap. Subsequently, the aggregation module 40, based on the updated compliance status bitmap output by the scheduling module 30, uses the data physical pointer to generate a memory block copy descriptor and schedules the hardware data stream accelerator to reassemble the discrete business pipeline data into a giant physical memory page. Finally, the sending module 50, based on the physical starting address of the giant physical memory page reassembled by the aggregation module 40, schedules the encryption accelerator card to read the business pipeline data, performs hardware-level asynchronous encryption to obtain ciphertext data, and reads the ciphertext data through the network interface card to complete the final network transmission operation.

[0060] See Figure 2 , Figure 2 This is a schematic diagram of the logical structure of a compilation module 10 according to an embodiment of the present invention. In this embodiment, the compilation module 10 in the integrated hardware and software regulatory reporting system is internally configured with a specification parsing unit, a graph construction unit, a weight evaluation unit, and a topology binding unit. The compilation module 10 utilizes the aforementioned hardware or software units running on a processor to perform logical transformations and initial allocation of hardware resources.

[0061] The specification parsing unit receives externally loaded regulatory specification documents. Typically, these documents are written in Extensible Markup Language (EXPLAIN) or Lightweight Data Exchange (LDLE) formats, containing compliance verification conditions that various business transaction data must meet. The specification parsing unit performs lexical and syntactic analysis on the regulatory specification documents, breaking down the macro-level verification logic into the smallest granularity of basic verification operators. As a preferred approach, the basic verification operators are single operations that can be directly executed by the underlying code, such as non-null checks, cross-table primary key matching, or numerical range comparisons. For the specific implementation of using an abstract syntax tree to parse EXPLAIN, those skilled in the art can use existing parsers for program processing; the lexical parsing and syntax tree construction processes are well-known technologies in the field and will not be elaborated upon here. The macro-level verification logic is the sum of complex business rules initially received by the system from the external regulatory specification documents. The compliance verification logic is the part of the machine-level verification instructions that are actually executed by a specific CPU core after the macro-level verification logic is broken down, combined, and then topologically bound to specific physical cores by the compilation module.

[0062] The graph construction unit maps multiple basic verification operators output by the specification parsing unit to execution nodes in the graph structure. To ensure logical consistency in data processing, the graph construction unit analyzes the data dependencies between basic verification operators. When the execution of one basic verification operator must wait for the result of another, a directed edge is generated between the two execution nodes. Based on the combination of execution nodes and directed edges, the graph construction unit ultimately generates a fixed-width compliant state bit string with execution order constraints. It should be noted that for isolated basic verification operators that may not have prerequisite dependencies, the graph construction unit will attach them by default to a virtual starting node uniformly generated by the system to ensure the connectivity and integrity of the global graph structure and prevent traversal omissions.

[0063] After constructing the graph structure, the system needs to pre-quantify the computational overhead of each branch to provide a basis for subsequent physical resource scheduling. Specifically, the weight evaluation unit receives the fixed-width compliance status bit string output by the graph construction unit and uses a graph traversal algorithm to identify each connected subgraph within the graph structure that is independent and has no directed edges connecting them. Each connected subgraph represents an independent verification branch that can be processed in parallel. In this embodiment, the weight evaluation unit queries the estimated execution clock cycle constant corresponding to each basic verification operator on a multi-core processor in the connected subgraph according to the system's preset operator overhead dictionary, and performs cumulative calculation to obtain the computational complexity weight of each connected subgraph. The quantification relationship of the computational complexity weight satisfies the following formula:

[0064] ;

[0065] In the formula, Indicates the first The computational complexity weight of a connected subgraph represents the theoretical computational load required for parallel branches on a multi-core processor. Indicates the first The set of all execution nodes contained within a connected subgraph; This represents a single execution node in the set, i.e., a single basic verification operator; This indicates the estimated computational cost required to execute the basic verification operator. In practical applications, The value of is typically obtained by extracting historical execution features through offline benchmarking. For example, the system can set the overhead of a basic non-empty check operation to a basic unit of 1, while setting the overhead of complex operators involving multi-field regular expression matching to an integer within a certain range. This static overhead evaluation method based on an empirical dictionary can provide a reliable allocation reference for the underlying hardware scheduling without consuming the device's real-time computing power.

[0066] Based on the weight data obtained from the quantization, the topology binding unit acquires the underlying hardware topology information exported by the operating system kernel. This underlying hardware topology information includes the IDs of all physical cores within the multi-core processor and the identifiers of the non-consistent memory access nodes to which each physical core belongs. To avoid single-core overload or resource idleness in the multi-core processor, the topology binding unit allocates resources according to the computational complexity weights output by the weight evaluation unit, assigning connected subgraphs with higher computational complexity weights to physical cores with empty task queues or low loads. After allocation, the topology binding unit calls the operating system's processor affinity interface to hard-bind the execution logic of each connected subgraph to the specified physical core in the multi-core processor by setting the processor mask of the execution thread. Simultaneously, based on the underlying hardware topology information, the topology binding unit identifies the physical memory region within the same hardware bus control domain as the corresponding local memory node.

[0067] The topology binding unit combines the connected subgraph identifier, the bound physical core number, and the local memory node address into a mapping routing table. This mapping routing table establishes the system's hardware verification topology path during system initialization. The compilation module 10 writes the generated hardware verification topology path into a pre-allocated shared memory area for subsequent scheduling module 30 to read and call when transferring business pipeline data. Through the above-mentioned hardware-software co-working resource binding technology, the system completely avoids the random migration of verification execution threads between different physical cores at the physical level, effectively reducing the hardware bus communication latency caused by cross-node memory access.

[0068] See Figure 3 , Figure 3 This is a schematic diagram of the logical structure of the access module 20 according to an embodiment of the present invention. In this embodiment, the access module 20 in the integrated hardware and software monitoring and reporting system is internally configured with a bypass receiving unit, a memory pool partitioning unit, a pipeline construction unit, and a metadata allocation unit. The access module 20 utilizes the above-mentioned hardware logic units in conjunction with the underlying network interface card (NIC) device to complete the direct memory addressing of service flow data and the initialization of the underlying data structure.

[0069] The bypass receiving unit is used to take over the underlying network interface card (NIC) of the system and receive externally input service pipeline data. In traditional data receiving mechanisms, data packets need to undergo multiple hardware interrupt responses and memory context copies through the operating system kernel network stack, resulting in a significant consumption of computing power for multi-core processors. To address this resource overhead issue, the bypass receiving unit, based on data plane development kit (DPT) technology, directly takes over the hardware receiving queue of the NIC through a polling mode driver. When external service pipeline data arrives at the NIC, the bypass receiving unit schedules the NIC's direct memory access engine (DMI). This DMI bypasses the operating system kernel network stack and directly writes the effective payload of the service pipeline data into a pre-allocated physical memory pool. As a preferred approach, those skilled in the art can adapt existing network acceleration development libraries for taking over the NIC queue using the DPT and configuring the specific register operations at the underlying DMI. The underlying driver integration is well-known in the field and will not be elaborated upon here.

[0070] After completing the direct writing of underlying data, to ensure the concurrent execution efficiency of subsequent multi-core processor read processes, the memory pool partitioning unit and the pipeline construction unit are responsible for establishing a matching high-efficiency storage structure at the underlying level. Based on the hardware verification topology path established by the compilation module 10, the memory pool partitioning unit allocates a contiguous physical memory space as the financial bank's physical memory pool in the local memory node located in the same hardware bus control domain as the specified physical core. On this basis, the pipeline construction unit constructs a non-consistent memory access-aware memory pipeline in the physical memory pool. Specifically, this non-consistent memory access-aware memory pipeline is logically hard-divided into a business data payload area and a metadata control area. The payload area is configured as a lock-free circular buffer structure, used to store business pipeline data transported by the direct memory access engine in an append-only manner. The metadata control area is specifically used to store indexes and status information that control the flow of business data. This technique of isolating the data body and control information in physical memory can effectively prevent the false sharing failure problem of the underlying cache line from being triggered during subsequent multi-core concurrent read verification.

[0071] As business pipeline data is continuously written to the payload area of ​​the non-consistent memory access aware memory pipeline, the metadata allocation unit synchronously allocates a corresponding physical data pointer and a fixed-length compliance status bitmap for each piece of business pipeline data written in the metadata control area. The physical data pointer is an absolute memory index pointing to the physical starting address of a single piece of business pipeline data in the payload area. In subsequent system cycles, multi-core processors only need to pass this physical data pointer through a high-speed hardware bus, without having to move business pipeline data between different non-consistent memory access nodes. This replacement of data movement with passing the memory index avoids the large overhead of copying memory contexts.

[0072] Meanwhile, to accurately and with low overhead record the verification progress of each business transaction data in the fixed-width compliance status bit string, the metadata allocation unit dynamically determines the bit width length of the fixed-length compliance status bitmap based on the number of execution nodes in the fixed-width compliance status bit string generated by the compilation module 10. Specifically, the metadata allocation unit extracts the total number of execution nodes of the basic verification operators contained in the fixed-width compliance status bit string and allocates a binary bit string of corresponding length in the metadata control area as the compliance status bitmap for that business transaction data. The length calculation and initialization logic of the compliance status bitmap satisfies the following formula:

[0073] ;

[0074] In the formula, The bit width of the allocated compliance status bitmap is represented by bits. This indicates the total number of execution nodes contained in the fixed-width compliance status bit string. It is important to note that, to ensure the completeness of the algorithm's processing logic, if the parsed regulatory specification is empty or an anomaly occurs, resulting in the fixed-width compliance status bit string being... When the value equals zero, the system will trigger an empty graph exception handling branch. At this time, the metadata allocation unit will not allocate the control area space of the non-consistent memory access aware memory pipeline for this batch of business pipeline data, but will directly mark it as a default allowable state or discard it to prevent subsequent invalid memory allocations of zero length or pointer out-of-bounds hardware errors.

[0075] For normal positive integers , in the formula This represents the round-up operator. The physical purpose of this mathematical operation is to ensure that the length of the compliance state bitmap not only maps all check operator nodes in one-dimensional space, but also satisfies the addressing requirements of the underlying multi-core processor cache byte alignment.

[0076] ;

[0077] In the formula, The initial machine state of the compliance status bitmap is represented by this bitmap. After memory allocation, the metadata allocation unit directly writes all-zero machine code into this memory segment, initializing all bits in the compliance status bitmap to logical zero. Throughout the entire lifecycle of the business flow data, each bit in the compliance status bitmap establishes a unique hardware address mapping with the corresponding execution node in the fixed-width compliance status bit string. This memory space partitioning and mapping technology compresses the complex business verification flow state into underlying binary machine code, providing a compact physical storage foundation for the subsequent scheduling module 30 to directly use hardware atomic instructions to perform state changes when the verification branch passes.

[0078] See Figure 4 , Figure 4 This is a schematic diagram of the logical structure of the scheduling module 30 according to an embodiment of the present invention. In this embodiment, the scheduling module 30 in the integrated hardware and software monitoring and reporting system is internally configured with a pointer transfer unit, a rule addressing unit, and a state reconstruction unit. The scheduling module 30, in collaboration with the underlying multi-core processor, completes the cross-core distribution of business logic and the lock-free evolution of execution state based on a zero-copy scheduling mechanism.

[0079] The pointer transfer unit receives the physical data pointer and a fixed-length compliance status bitmap transmitted by the access module 20. In traditional multi-threaded concurrent processing architectures, task distribution often involves copying the entire dataset between different thread contexts, a process that can consume significant hardware bus bandwidth. To address this resource overhead, the pointer transfer unit, based on the hardware verification topology path established by the compilation module 10, only transmits the physical data pointer and a fixed-width compliance status bitmap between corresponding physical cores of the multi-core processor. Specifically, between adjacent physical cores on the same hardware verification topology path, the pointer transfer unit directly instantiates a lock-free circular queue based on a low-level compare-and-swap mechanism and pushes the physical data pointer into the lock-free circular queue for downstream physical cores to access. By pushing the physical data pointer into the lock-free circular queue, the downstream physical core can directly retrieve the memory index from the processor's cache. For concurrent enqueue and dequeue operations of the lock-free queue, those skilled in the art can implement them at the code level using existing concurrent data structures; the memory barrier settings and atomic operations are well-known technologies in the field and will not be elaborated upon here.

[0080] After obtaining the flowing memory index from the target physical core, the rule-based addressing unit directly addresses and reads the business pipeline data stored in the physical memory pool by traversing the non-consistent memory access nodes based on the received data physical pointer. Based on the above read operation, the rule-based addressing unit uses the read business pipeline data to control the current physical core to execute the specific compliance verification logic assigned to that core. Since the front-end compilation module 10 has hard-bound the specific compliance verification logic (i.e., the connected subgraph) to the physical core, the rule-based addressing unit does not need to perform complex context switching during execution, thereby ensuring the continuity of the processor instruction pipeline.

[0081] Upon completion of specific compliance verification logic, the state reconstruction unit is responsible for updating the control metadata in the non-consistent memory access-aware memory pipeline in situ when the compliance verification logic passes. To address concurrent write conflicts in a multi-core architecture, the system employs a lock-free state evolution technique based on bitmap operations. Specifically, to prevent multiple physical cores from competing to write to the same fixed-length compliance state bitmap while simultaneously verifying different branches, the state reconstruction unit invokes the hardware bus locking atomic instruction of the multi-core processor. This hardware bus locking atomic instruction is a low-level hardware instruction that directly locks the physical bus, thus avoiding software-level context switching (e.g., instructions with the LOCK prefix in x86 architecture). It performs logical shift and bitwise OR operations on the corresponding bits of the fixed-length compliance state bitmap. This low-level hardware instruction can lock the cache line containing the target memory address during execution, ensuring the exclusivity of state updates in a multi-core concurrent environment. The mathematical logic for the atomic update performed by the state reconstruction unit satisfies the following formula:

[0082] ;

[0083] In the formula, This represents the updated compliance status bitmap obtained after performing an atomic update operation. This represents the original compliance state bitmap currently residing in the non-consistent memory access aware memory pipeline; This represents the bitwise OR logical operator; This represents the logical left shift operator; This represents the topology index value of the execution node mapped by the currently executed compliance verification logic in the directed acyclic topology of the rule routing. This index value represents the relative physical position of the current verification operator in the overall execution topology.

[0084] It is important to note that, to ensure the safety of memory modifications and the completeness of the algorithm logic, the state reconstruction unit must perform boundary validity checks on the topology index value before performing the left shift operation. Topology index value The valid range of values ​​is limited to Within the closed interval, where The bit width (in bits) when allocating this bitmap to access module 20. If the input is affected by a rule engine parsing error... If the value exceeds the above range, or if the bit width of the underlying data type used in the shift operation is insufficient, leading to address overflow, the state reconstruction unit will trigger an out-of-bounds interrupt protection mechanism, refusing to execute the bitwise OR operation and forcibly marking the compliance status bitmap of the business pipeline data as a system error isolation state. Furthermore, considering the potential risk of underlying hardware bus deadlock for atomic instructions, the state reconstruction unit introduces a retry mechanism based on hardware clock cycles when executing hardware bus lock atomic instructions. When hardware bus lock fails or the waiting period exceeds a preset retry threshold (e.g., 0 hardware clock cycles), the system will abandon the current in-situ update and trigger a hardware bus timeout exception, handing the task over to the upper-layer module for reassignment.

[0085] Under the constraints of the aforementioned normal range and the exception handling mechanism, the physical purpose of the logical operation is to precisely write the "1" representing the current verification node's passage into a specified bit of a fixed-length compliance state bitmap using a single hardware clock cycle, without overwriting or corrupting the verification state written simultaneously by other physical cores. After completing the hardware atomic instruction call, the state reconstruction unit keeps the updated compliance state bitmap residing in the non-consistent memory access-aware memory pipeline. This bitmask-based in-situ reconstruction technology completely abandons the traditional software-level mutex mechanism, ensuring state consistency while providing a stable and non-blocking physical memory state for the high-frequency polling reads of the downstream aggregation module 40.

[0086] like Figure 5 As shown, Figure 5 This is a schematic diagram of the logical structure of the aggregation module 40 according to an embodiment of the present invention. In this embodiment, the aggregation module 40 in the integrated hardware and software regulatory reporting system is internally configured with a status monitoring unit, a mask matching unit, a descriptor construction unit, and a hardware coordination unit. The aggregation module 40 utilizes the above-mentioned hardware logic units to achieve non-blocking polling of compliance status and physical continuity reorganization of discrete memory data.

[0087] The state monitoring unit continuously polls the updated compliance state bitmap residing in the non-consistent memory access aware memory pipeline via an independently running state monitoring daemon thread. In traditional interrupt-driven mechanisms, notifications of data state changes require frequent context switching between kernel and user modes, consuming significant system hardware bus cycles. To address this overhead, the state monitoring daemon thread is hard-bound to a dedicated idle physical core of the processor, using a spin-polling method to directly read the metadata control area of ​​the non-consistent memory access aware memory pipeline across the hardware bus. As a preferred approach, the spinlock implementation and the daemon thread's kernel-mode physical core binding can be configured using existing operating system thread affinity application programming interfaces (APIs). The underlying system call mechanism is well-known in the field and will not be elaborated upon here.

[0088] Building upon this foundation, to quickly filter out compliant data amidst massive concurrency, the mask matching unit, while the status monitoring daemon thread continuously reads physical memory, triggers a subsequent physical memory reorganization process when it determines that the updated compliance status bitmap meets the preset signature mask conditions. Specifically, the status verification judgment logic executed by the mask matching unit satisfies the following formula:

[0089] ;

[0090] In the formula, This represents the mask matching result obtained after logical operations. This represents the updated compliance status bitmap read by the status monitoring daemon thread; This represents the bitwise AND logical operator; This represents the system's preset signature mask. The specific value of this signature mask is determined by the preceding compilation module 10 during the system initialization phase, based on the set of endpoint verification operators for the fixed-width compliant bit string. As a preferred approach, if certain types of business transaction data are only considered compliant after passing through verification nodes with topology indices of 0, 2, and 4, then... The corresponding bit is set to logic 1, and the remaining bits are logic 0.

[0091] To ensure memory security in scenarios with concurrent multi-source heterogeneous data, the mask matching unit must verify the validity of the bitmap memory boundaries before performing a bitwise AND operation. If the read data... memory alignment length and Inconsistency, or due to abnormal initialization of the memory pipe. If the address space is a null pointer, the mask matching unit will trigger the data format exception capture mechanism, discard the exception bitmap, and send an alarm interrupt to the system hardware bus. Under normal boundary constraints, if and only if the calculated... With the default signature mask When the underlying binary values ​​are completely equal, the mask matching unit determines that the business flow data has passed all the preceding compliance verification logic, thus establishing a valid state match. The physical purpose of the above-mentioned bitwise logic operation is to use the bitwise logic operation within a single hardware clock cycle of the processor to filter out compliant data that has completed all verification links, avoiding the risk of branch prediction failure and computational delay caused by using software to compare the state of each node in a loop.

[0092] After confirming a successful state match, the descriptor construction unit generates a memory block copy descriptor based on the data physical pointer passed by the scheduling module 30. Specifically, the descriptor construction unit extracts the data physical pointer as the source memory absolute address and calculates the target physical address by combining it with the existing data tail offset of the currently pre-allocated jumbo physical memory page. To prevent serious underlying errors such as physical memory overwrite exceeding limits, the descriptor construction unit enforces a jumbo physical memory page capacity check before calculating the target physical address. When it is determined that the existing data tail offset plus the actual byte length of the business pipeline data to be copied exceeds the physical capacity limit of the jumbo physical memory page, the descriptor construction unit encapsulates the current jumbo physical memory page and transfers it to subsequent modules. Simultaneously, it requests the operating system kernel to allocate a new physical jumbo physical memory page to reset the data tail offset. After confirming sufficient target memory space, the descriptor construction unit combines and encapsulates the source memory absolute address, target physical address, and actual byte length into a memory block copy descriptor conforming to the hardware-accelerated hardware bus transmission specification, based on the actual byte length of the business pipeline data. Pre-allocated giant physical memory pages use the giant page technology supported by the operating system to allocate contiguous physical memory space, thereby reducing the page miss rate of the translation back buffer in the memory management unit.

[0093] After encapsulation, the hardware coordination unit submits the memory block copy descriptor to the hardware command queue of the data flow accelerator. This submission operation triggers the direct memory access engine inside the data flow accelerator, which, based on the address information recorded in the memory block copy descriptor, directly copies the discrete business pipeline data written by the access module 20 across processor cores and arranges them consecutively into the pre-allocated giant physical memory page. During this process, considering the physical bottleneck of the underlying hardware bus throughput, the hardware coordination unit is equipped with a queue depth monitor. When it is detected that the remaining space in the hardware command queue of the data flow accelerator is close to zero (i.e., the hardware is fully loaded and blocked), the hardware coordination unit will trigger a dynamic backoff retry mechanism, suspend the issuance of memory block copy descriptors, or, after a timeout, degrade to an idle physical core using a software memory copy function to perform the transfer, in order to prevent system-level hardware bus deadlock. After the data flow accelerator completes the physical alignment and continuous splicing of the business pipeline data to the giant physical memory page, the hardware coordination unit generates a hardware interrupt signal to notify the sending module 50 of the encapsulated giant physical memory page. Through the aforementioned hardware and software co-control method, the system reduces the memory read and write load of multi-core processors and realizes the structural adjustment of discrete business states into continuous aggregated data blocks at the physical level.

[0094] Figure 6 This is a schematic diagram of the logical structure of the sending module 50 according to an embodiment of the present invention. In this embodiment, the sending module 50 in the integrated hardware and software regulatory reporting system is internally configured with an encryption and encapsulation unit, a traffic shaping unit, and a bypass sending unit. The sending module 50 utilizes the above-mentioned hardware logic units in conjunction with the underlying network adapter to achieve hardware-level encryption protection for continuously aggregated data blocks and direct output from the underlying network interface.

[0095] After the aggregation module 40 notifies the sending module 50 via a hardware interrupt signal that the giant physical memory page is ready, the encryption encapsulation unit performs physical-level access control and encryption conversion on the continuously transmitted data stored within the giant physical memory page. In traditional software encryption mechanisms, executing algorithms such as Advanced Encryption Standard (AES) on a general-purpose processor generates intensive floating-point operations and matrix substitution operations, which consume a large number of processor clock cycles. Based on this computational load issue, the encryption encapsulation unit calls the hardware encryption acceleration engine mounted within the system to perform data encryption operations. As a preferred approach, the encryption encapsulation unit encapsulates the physical base address of the giant physical memory page and the total data length into a hardware encryption request descriptor and submits it to the command queue of the hardware encryption acceleration engine. The hardware encryption acceleration engine reads the data through direct memory access and executes the AES algorithm based on the Galois counter mode to generate the corresponding ciphertext data and message authentication code. The encryption result is then written into a newly allocated isolated secure memory page. For the configuration of the underlying registers of the hardware encryption acceleration engine and the specific cryptographic implementation of the encryption algorithm, those skilled in the art can use existing hardware security development kits for instruction mapping. The key derivation and hardware engine driver interface are well-known technologies in this field and will not be elaborated here.

[0096] With the completion of hardware encryption, to ensure that the data transmission rate matches the processing capacity of the target regulatory agency's receiving server, the traffic shaping unit performs bandwidth rate control on the encrypted data to be sent, based on the underlying hardware clock cycle. Before the specific calculation, the system performs rate limiting modeling based on a general queuing theory model of discrete time slices and token bucket buffers. In this embodiment, the traffic shaping unit maintains a rate limiting queue state machine based on the token bucket mechanism in memory. Within each physical hardware scheduling cycle, this rate limiting queue state machine dynamically calculates the currently available data transmission quota based on the preset peak bandwidth limit of the regulatory network. The transmission quota update logic of this rate limiting state machine satisfies the following formula:

[0097] ;

[0098] In the formula, This represents the available data transmission limit calculated in the current physical scheduling cycle, and its unit of measurement is bytes. This indicates the maximum burst transmission capacity threshold allowed by the system; This indicates the remaining available data transmission quota in the previous scheduling cycle; This represents the data byte rate constant allowed per hardware clock cycle as defined in the service level agreement; This indicates the current high-precision hardware clock slice of the multi-core processor being read; This represents the historical clock segment from the last time the rate limiting state machine update was triggered; This represents the minimum value function. The physical purpose of this mathematical operation is to use the accumulation of time difference or hardware-level transmission permission to forcibly constrain the rate at which burst data packets are injected into the physical link, preventing instantaneous overload from causing congestion and packet loss in downstream network devices.

[0099] It is important to note that, to ensure the logical integrity of the flow shaping algorithm during long-term stable operation of the system, the flow shaping unit must perform overflow wraparound detection on the clock truncation before performing multiplication and addition operations. When overflow is detected... The value is less than When this occurs, it indicates that the underlying 64-bit hardware clock counter has overflowed and wrapped around. At this point, the flow shaping unit will trigger a clock compensation branch, subtracting the historical clock truncation from the maximum extreme value of the 64-bit unsigned integer, adding the current clock truncation, and compensating for the difference over one machine cycle to arrive at the correct true time span. Furthermore, The specific value range is usually set to 50% to 80% of the target receiver's transmission control protocol receive window size. This value is dynamically negotiated by the all-in-one system during the network handshake phase based on line delay and historical packet loss rate and written into the register.

[0100] To avoid the risk of hardware deadlock caused by a single rate-limiting metric, the traffic shaping unit employs multi-dimensional state-aware logic to establish the final transmission admission signal. In a specific embodiment, the traffic shaping unit not only verifies the currently calculated available data transmission quota... The system checks whether the data exceeds the actual byte length of the encrypted data to be sent. Simultaneously, it reads the physical link liveness status flag of the network interface card through the underlying physical registers and obtains the remaining hardware transmit descriptor space currently in an idle state. Only when the rate limiting quota is sufficient, the physical link is in a hardware connected state, and the remaining hardware transmit descriptor space is greater than the preset safety threshold, will the traffic shaping unit deduct the corresponding quota and send the transmission admission signal to the bypass transmission unit.

[0101] The bypass transmission unit is used to take over the transmission channel of the underlying network interface card. Based on the aforementioned system resource scheduling considerations, and to reduce the memory copy overhead incurred by the operating system kernel network stack during socket construction, the bypass transmission unit also utilizes data plane development kit technology to establish a direct mapping with the network interface card's hardware transmission ring queue. The bypass transmission unit extracts the physical base address and payload length of the isolated secure memory page, assembles them into a hardware transmission descriptor recognizable by the network interface card, and directly pushes it into the network interface card's transmission ring queue. During this process, if the hardware transmission ring queue is in a fully loaded and blocked state due to external network backpressure, the exception handling mechanism configured within the bypass transmission unit will trigger a retry spin operation based on exponential backoff to avoid network interface card descriptor loopback deadlock due to blind pushing. Finally, the network interface card's direct memory access engine directly reads the encrypted data from the isolated secure memory page according to the absolute physical address pointed to by the transmission descriptor, converts it into a corresponding signal, and injects it into the physical network link, thereby completing the stacking and reporting of the entire business pipeline data under a hardware-software co-working architecture.

[0102] This embodiment takes the scenario of commercial banks reporting anti-money laundering and real-time monitoring of large funds as an example to illustrate the workflow of a monitoring and reporting integrated system based on hardware and software integration.

[0103] During system initialization, compilation module 10 receives the anti-money laundering regulatory specification document. The specification parsing unit parses the rules in the specification document, such as cross-table transaction comparison and fund dispersion and concentration calculations, converts them into basic verification operators, and constructs a fixed-width compliance status bit string. The weight evaluation unit calculates the complexity of the rules, and the topology binding unit, based on the complexity weights, binds the connected subgraphs containing the computationally demanding cross-table comparison operators to specific physical cores and local memory nodes within the same hardware bus control domain via processor affinity interfaces. This process establishes the physical hardware routing topology for anti-money laundering verification.

[0104] During the data access and processing phase, access module 20 takes over the network interface card. When transaction logs from external systems arrive, the bypass receiving unit bypasses the operating system kernel network stack via the direct memory access engine and writes the transaction details data into the physical memory pool. The pipeline construction unit establishes a non-consistent memory access-aware memory pipeline in the memory pool. The metadata allocation unit allocates a data physical pointer and a fixed-length compliance status bitmap to each transaction log based on the number of execution nodes for the fixed-width compliance status bit string.

[0105] The scheduling module 30 receives the data physical pointer and the compliance status bitmap, and passes the pointer between the bound physical cores through a lock-free circular queue. The rule addressing unit reads the transaction flow based on the pointer and executes the anti-money laundering operator logic. When the flow meets a certain anti-money laundering rule, the state reconstruction unit calls the underlying hardware bus locking atomic instruction of the multi-core processor to perform a logical left shift and bitwise OR operation on the compliance status bitmap, updating the corresponding bits. This process only updates the state machine code and does not involve data movement.

[0106] During the data reorganization and transmission phase, the status monitoring unit of the aggregation module 40 polls the updated compliance status bitmap on the independent core.

[0107] The mask matching unit performs a bitwise AND operation between the bitmap and a preset reporting signature mask. When the operation results match, indicating that the transaction needs to be reported as large or suspicious, the descriptor construction unit generates a memory block copy descriptor containing the source address and the target jumbo page address. The hardware coordination unit submits the descriptor to the data stream accelerator, triggering a hardware-level continuous memory copy.

[0108] Finally, the encryption encapsulation unit of the sending module 50 obtains the physical base address of the giant physical memory page and schedules the encryption accelerator card to execute the Advanced Encryption Standard algorithm to generate ciphertext data.

[0109] The flow shaping unit, combined with a high-precision clock stamp, calculates the available transmission quota and controls the output rate of encrypted data. The bypass transmission unit extracts the physical address and pushes it into the network interface card's transmission queue, allowing the network interface card to directly send the encrypted data to the regulatory agency's front-end server.

[0110] Table 1. Performance Comparison of Traditional Architecture and Hardware-Software Integrated System under Complex Regular Topologies

[0111]

[0112] Based on the data in Table 1 and Figure 7 The integrated regulatory reporting system based on hardware and software provided in this embodiment of the invention is superior to the traditional pure software architecture in three dimensions: rule scalability, processing latency, and system resource overhead.

[0113] Analysis of system throughput metrics shows that when the rule topology complexity increases from 53 execution nodes to 289 execution nodes, the throughput of the traditional architecture decreases from 9.81Gbps to 2.94Gbps. The throughput of the integrated system of this invention decreases from 9.87Gbps to 8.83Gbps. This difference indicates that the traditional multi-threaded architecture incurs context switching and memory lock contention overhead when processing complex rule graphs. This solution eliminates cross-core data migration by statically binding hardware verification topology paths through the compilation module 10 and by using atomic instructions to update the compliance status bitmap in situ through the scheduling module 30. The system maintains stable processing bandwidth even as the number of operators increases.

[0114] Analysis of end-to-end processing latency metrics shows that, under various rule complexities, the latency of the integrated system of this invention is within 1.12ms, while the latency of the traditional architecture reaches 31.05ms with 289 execution nodes. This data confirms the effectiveness of the hardware-software collaboration in the data flow path of this solution. The access module 20 utilizes a direct memory access engine to bypass the operating system kernel network stack, avoiding initial data copying. The aggregation module 40 uses a data flow accelerator to perform data reassembly operations based on physical addresses, replacing traditional software-level loop access and memory splicing. These mechanisms reduce memory read / write intervention by multi-core processors and shorten the data processing cycle within the system.

[0115] Analysis of CPU utilization shows that as the number of execution nodes increases, the utilization rate of the traditional architecture rises to 91.6%, while the integrated system of this invention has a utilization rate of only 12.4% under the most complex operating conditions. This is mainly attributed to the hardware offloading mechanism of the sending module 50. The traditional architecture relies on a general-purpose computing core to perform encrypted computation and network card pop operations. This solution utilizes an encryption encapsulation unit to pass the physical base address of a giant physical memory page to an encryption acceleration card to complete the computation, and a bypass sending unit takes over the underlying network card queue for transmission. At the same time, the traffic shaping unit uses an independent state machine to perform rate limiting control. These designs transfer the heavy workload of data encryption and network protocol layer computation to dedicated hardware units, freeing up the computing resources of the general-purpose processor.

[0116] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A software-hardware integrated regulatory reporting system, running in a hardware environment configured with a multi-core processor, a data stream accelerator, a network interface card, and an encryption acceleration card, characterized in that, include: The compilation module is used to parse the regulatory specifications into a fixed-width compliance status bit string and bind it to the multi-core processor, establishing a hardware verification topology path; The access module is used to write business flow data into the physical memory pool and allocate data physical pointers and compliance status bitmaps according to the fixed-width compliance status bit string. The scheduling module is used to flow the data physical pointer along the hardware verification topology path to execute compliance verification logic, and update the compliance status bitmap when the compliance verification logic is successfully executed. The aggregation module is used to schedule the data stream accelerator to reassemble the business flow data into a giant physical memory page when the updated compliance status bitmap meets the mask conditions. The sending module is used to trigger the encryption acceleration card to generate ciphertext data based on the starting address of the giant physical memory page and send it through the network interface card; The compilation module includes: The specification parsing unit is used to receive and analyze externally loaded regulatory specification documents, and decompose the macro-level verification logic into multiple basic verification operators; The graph construction unit is used to map multiple basic verification operators to execution nodes in a graph structure, analyze the data dependencies between the basic verification operators, generate directed edges between the execution nodes with dependencies, and generate a fixed-width compliant state bit string with execution order constraints based on the combination of the execution nodes and the directed edges. The weight evaluation unit is used to identify mutually independent connected subgraphs in the fixed-width compliant state bit string, and accumulate the estimated execution clock cycles of each basic check operator in the subgraph to obtain the computational complexity weight of each connected subgraph. The topology binding unit is used to allocate resources according to the computational complexity weight, set the processor mask, bind the execution logic of each connected subgraph to the physical core specified in the multi-core processor, and determine the physical memory area in the same hardware bus control domain as the physical core as the corresponding local memory node, so as to establish the hardware verification topology path of the system. The access module includes: The bypass receiving unit is used to bypass the operating system kernel network stack through the direct memory access engine of the network interface card and receive the externally input service pipeline data body. A memory pool partitioning unit is used to pre-allocate contiguous physical space in the local memory nodes corresponding to the multi-core processor in order to construct a physical memory pool. The pipeline construction unit is used to construct a non-consistent memory access aware memory pipeline in the local memory node and divide the non-consistent memory access aware memory pipeline into a business data payload area and a metadata control area. The metadata allocation unit is used to store the business flow data body in the business data payload area in an append-only manner, and to continuously allocate the corresponding data physical pointer and the compliance status bitmap in the metadata control area.

2. The integrated regulatory reporting system based on hardware and software integration as described in claim 1, characterized in that, The metadata allocation unit is also used to dynamically determine the bit width length of the compliance status bitmap based on the number of execution nodes of the fixed-width compliance status bit string.

3. The integrated regulatory reporting system based on hardware and software integration as described in claim 2, characterized in that, The scheduling module includes: The pointer transfer unit is used to establish a lock-free circular queue between adjacent physical cores, and transfer the data physical pointers through the lock-free circular queue; The rule-addressing unit is used to read the business flow data according to the data physical pointer and use the business flow data to control the current physical core to execute the compliance verification logic.

4. The integrated regulatory reporting system based on hardware and software integration as described in claim 3, characterized in that, The scheduling module further includes a state reconstruction unit, used for: When the compliance verification logic passes, the hardware bus locking atomic instruction of the multi-core processor is invoked to update the compliance status bitmap in situ. Before performing the logical shift operation, the topology index value of the execution node mapped in the fixed-width compliance state bit string of the currently executed compliance verification logic is checked for boundary legality. After the boundary validity verification is passed, logical shift and bitwise OR operations are performed on the compliance status bitmap based on the topology index value to obtain and retain the updated compliance status bitmap.

5. The integrated regulatory reporting system based on hardware and software as described in claim 4, characterized in that, The aggregation module includes: The status monitoring unit, hard-bound to an idle physical core, is used to read the updated compliance status bitmap; The mask matching unit is used to perform a bitwise AND operation between the updated compliance status bitmap and the preset signature mask, and determine whether the mask conditions are met.

6. The integrated regulatory reporting system based on hardware and software as described in claim 5, characterized in that, The aggregation module also includes: The descriptor construction unit is used to generate a memory block copy descriptor after determining that the mask condition is met; A hardware coordination unit is used to submit the memory block copy descriptor to the data stream accelerator to trigger the data stream accelerator to complete the reassembly to a giant physical memory page.

7. The integrated regulatory reporting system based on hardware and software as described in claim 6, characterized in that, The sending module includes: An encryption and encapsulation unit is used to trigger the encryption acceleration card to read the business flow data and perform pipeline encryption, generate ciphertext data and write it to an isolated secure memory page; The traffic shaping unit is used to maintain the rate-limiting queue state machine based on the token bucket mechanism, dynamically calculate the currently available data transmission quota, and issue an admission signal when the data transmission quota meets the transmission conditions. The bypass transmission unit is used to directly transmit encrypted data through the network interface card based on the admission signal.

8. The integrated regulatory reporting system based on hardware and software as described in claim 7, characterized in that, The sending conditions include that the currently available data sending quota is greater than the actual byte length of the encrypted data, and that the physical link is in a hardware connectivity state and the hardware sending descriptor margin is greater than the preset security level threshold.

Images