Multi-source product specification display screen engineering quantity accounting and equipment selection method and system

Abstract

The application relates to the technical field of LED display screen engineering quantity accounting and equipment selection, and provides a display screen engineering quantity accounting and equipment selection method and system of multiple-source product specifications, compatibility relationship data structures between standardized product objects are constructed, multi-constraint filtering is performed on the standardized product objects of the product category of display units according to input engineering parameters of a user, the total number of display units is calculated according to physical size information of candidate display units and screen size, and the number of control devices and the number of power supplies are calculated according to the load capacity of the candidate control devices and the power supply capacity of the candidate power supplies, and project-level, box-level and module component-level layered bill of materials is output, so that the technical problems of low engineering quantity accounting accuracy and high equipment selection mismatch rate caused by heterogeneous product data formats of multiple manufacturers and compatibility dependence on manual judgment can be solved, the equipment selection mismatch rate is reduced, and the beneficial effects of making the output bill of materials consistent with actual demands are realized.

Description

Technical Field

[0001] This application relates to the technical field of LED display engineering quantity calculation and equipment selection, and in particular to a method and system for calculating the engineering quantity and selecting equipment for multi-source product specifications of LED display screens. Background Technology

[0002] In the LED display engineering industry, quantity calculations and equipment selection are primarily done manually. After receiving project requirements, engineering personnel consult multiple manufacturers' product manuals or data tables based on parameters such as screen size and pixel pitch to obtain parameter information for modules, power supplies, and receiver cards. Then, relying on engineering experience, they calculate the quantities of modules, receiver cards, and power supplies item by item, ultimately creating a bill of materials. The inconsistent data formats, field naming, and units of measurement across different manufacturers' product manuals force personnel to repeatedly convert and compare between different formats. Compatibility information regarding interface types, load capacities, and cascading methods across manufacturers' products is scattered across different documents, requiring judgment based on personal experience. Furthermore, there is a specific order to calculating the quantities of modules, receiver cards, and power supplies; subsequent equipment quantity calculations must be based on previous calculations, and any deviation in the calculations of earlier stages will be passed on to all subsequent stages.

[0003] Due to the varying data formats and fragmented storage of products from different manufacturers, manual review and cross-document comparison are inefficient. A chain dependency exists between the number of modules, receiver cards, and power supplies; a deviation in the calculation of the module quantity directly leads to subsequent calculations of the receiver card and power supply quantities deviating from actual requirements, rendering the entire bill of materials unusable. The lack of systematic expression and verification methods for interface compatibility and load-bearing matching between products from different manufacturers means that the accuracy of manual judgment heavily relies on individual experience, resulting in low accuracy in quantity calculations. The problem of mismatched receiver card selection is particularly prominent, ultimately leading to project rework and material waste. Summary of the Invention

[0004] Therefore, it is necessary to provide a method and system for calculating the engineering quantity of a display screen and automatically selecting equipment based on a multi-source product specification library, so as to solve the problems of low calculation accuracy and high equipment mismatch rate caused by the heterogeneous data formats of products from multiple manufacturers and the lack of compatible expression means, and the reliance on manual experience to deduce the engineering quantity item by item in the existing technology.

[0005] Firstly, a method for calculating the engineering quantity and selecting equipment for display screens with multi-source product specifications is provided. This method includes: acquiring original product parameters from heterogeneous data sources of at least two display screen manufacturers; performing standardization processing on each of the original product parameters to obtain standardized product objects in a unified format; the standardized product objects include physical size information and load capacity information, and also include product category, parent-child assembly relationship, component specifications, unit usage rules, version information, and source traceability information; constructing a compatibility relationship data structure between different standardized product objects, the compatibility relationship data structure including at least two relationship types; receiving engineering parameters input by the user, the engineering parameters including screen size; performing multi-constraint filtering on the standardized product objects whose product category is display unit according to the engineering parameters to obtain a candidate display unit set; calculating the total number of display units based on the physical size information of the candidate display units in the candidate display unit set and the screen size; calculating the number of control devices and the number of power supplies based on the total number of display units, the single-device load capacity of candidate control devices, and the power supply capacity of candidate power supplies; and outputting project-level, cabinet-level, and module component-level bills of materials based on the candidate cabinet and component BOM relationships.

[0006] Secondly, a system for calculating the engineering quantities and selecting equipment for display screens with multiple product specifications is provided. The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the above-mentioned method for calculating the engineering quantities and selecting equipment for display screens with multiple product specifications.

[0007] Thirdly, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for calculating the engineering quantity of the display screen and selecting equipment for multi-source product specifications.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described method for calculating the engineering quantity of a display screen and selecting equipment for multi-source product specifications.

[0009] This application unifies heterogeneous data from multiple manufacturers into standardized product objects, transforming product parameters scattered across different documents into a system-recognizable data foundation, eliminating the need for manual cross-document comparison and conversion. Based on this, a compatibility relationship data structure is constructed, converting interface matching, load matching, and other adaptation rules that previously relied on personal experience into machine-queryable relational data, enabling the system to automatically identify compatibility between different products. Furthermore, multi-constraint filtering is performed in conjunction with user-input engineering parameters to automatically select candidate products that meet the criteria, replacing the manual process of comparing each product against the manual. On this basis, calculations are performed sequentially according to the dependency relationship from the number of display units to the number of control devices and then to the number of power supplies, automatically using the results of previous calculations in subsequent calculations. This avoids the problem of deviations propagating step-by-step during manual calculations, thereby reducing equipment mismatch rates and ensuring that the final output bill of materials matches actual requirements. In some implementations, the system also expands the module component-level and cabinet-level bill of materials based on the parent-child assembly relationship of selected modules and enclosures, and performs compatibility and source traceability verification on inherited or replaced components. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] in: Figure 1 This is a flowchart illustrating the method for calculating the engineering quantity of the display screen and selecting equipment for multi-source product specifications in this application embodiment; Figure 2 This is a schematic diagram of the module of the display screen quantity calculation and equipment selection system for multi-source product specifications in this application embodiment; Figure 3 This is a structural block diagram of the computer device in the embodiments of this application; Figure 4 This is a structural block diagram of the computer device in the embodiments of this application. Detailed Implementation

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

[0013] Please see Figure 1 As shown, Figure 1 The flowchart illustrating the method for calculating the engineering quantity and selecting equipment for multi-source product specifications of the display screen provided in this application embodiment includes the following steps: Step 01: Obtain the original product parameters from heterogeneous data sources of at least two display screen manufacturers, perform standardization processing on the original parameters of each product, and obtain a standardized product object in a unified format. The standardized product object contains physical size information and load capacity information. Step 02: Construct a compatibility relationship data structure between different standardized product objects. The compatibility relationship data structure should contain at least two relationship types. Step 03: Receive the engineering parameters input by the user. The engineering parameters include the screen size. Perform multi-constraint filtering on the standardized product objects whose product category is display unit according to the engineering parameters to obtain a set of candidate display units. Step 04: Calculate the total number of display units based on the physical size information of the candidate display units in the candidate display unit set and the screen size; Step 05: Calculate the number of control devices and power supplies based on the total number of display units, the single-device load capacity of candidate control devices, and the power supply capacity of candidate power supplies; divide the display units into load sub-regions corresponding to the number of control devices, and output project-level, cabinet-level, and module component-level bills of materials based on the BOM relationships of candidate display units, candidate control devices, candidate power supplies, candidate cabinets, and components.

[0014] Specifically, in step 01, raw product parameters are extracted from heterogeneous data sources from at least two display product manufacturers. These heterogeneous data sources include manufacturer product manuals in portable document format (PDF), spreadsheet documents, application programming interfaces (APIs), or web scraping data. Field mapping, unit conversion, and normalization are performed on the raw product parameters: field mapping maps field names from different manufacturers (e.g., "dot pitch" and "pixel pitch") to the same field; unit conversion unifies different units of measurement (e.g., millimeters and inches, amperes and milliamperes) to the same standard; and normalization converts different data structures (e.g., nested structures, flat structures, key-value pairs) into the same data pattern, resulting in a standardized product object with a unified format. The standardized product object contains physical size information and load capacity information. Physical size information includes the physical length values ​​of the display unit in the width and height directions, and load capacity information includes the maximum number of display units that a single control device can drive and the maximum number of display units that a single power supply can power. In one implementation, taking an indoor P2.5 module as an example, the physical dimensions of its standardized product object are recorded as 320 mm in width and 160 mm in height. In another implementation, the maximum number of pixels, number of ports, data group definition, and resolution boundaries of the candidate receiver card are determined by audited product specification data under the corresponding model, version, and firmware conditions.

[0015] In step 02, a compatibility relationship data structure is constructed between different standardized product objects. This compatibility relationship data structure is implemented in the form of a compatibility graph G=(V,E), where V is the vertex set, containing module nodes and receiver card nodes, and E is the edge set, containing compatibility relationship edges. Each compatibility relationship edge has the following attributes: source product identifier (source_product), target product identifier (target_product), relationship type (relation_type), and status (status). The relationship type must include at least two types, and the status includes audited, pending, and conflicted. This compatibility relationship data structure is persistently stored in the file system using JavaScript Object Notation (JSON) data transmission format. In one implementation, when querying the compatibility relationship between a HUB75 interface module and a HUB75 interface receiver card, the compatibility relationship data structure returns the interface compatibility relationship. In another implementation, when querying the compatibility relationship between the same module and a HUB320 interface receiver card, the compatibility relationship data structure returns a conflicted status. The compatibility relationship data structure can also record the assembly compatibility relationships between modules and housings, modules and components, and housings and components, which can be used for hierarchical bill of materials generation and component substitution verification.

[0016] In step 03, the user-inputted engineering parameters, including the screen size, are received. Based on these parameters, multi-constraint filtering is performed on standardized product objects categorized as display units. This multi-constraint filtering includes selection based on usage environment, pixel pitch, physical size, and interface type. A set of candidate display units that simultaneously meet all the aforementioned engineering constraints is filtered from the standardized product objects categorized as display units. In one embodiment, if the engineering parameters are a screen width of 6400 mm, a screen height of 3200 mm, a pixel pitch of P2.5, and an indoor usage environment, then a set of modules that meet indoor usage requirements and have a pixel pitch of 2.5 mm is filtered out.

[0017] In step 04, the total number of display units is calculated based on the physical size information of the candidate display units in the candidate display unit set and the screen size. The width and height values ​​of the candidate display units are obtained from the candidate display unit set, and the number of columns and rows of display units are calculated using the width and height values ​​from the screen size. The total number of display units is obtained by multiplying the number of columns and rows. In one embodiment, if the candidate module width is 320 mm and the candidate module height is 160 mm, and the screen width is 6400 mm and the screen height is 3200 mm, then the number of display unit columns is 6400 divided by 320, which equals 20 columns, and the number of display unit rows is 3200 divided by 160, which equals 20 rows. The total number of display units is 20 multiplied by 20, which equals 400.

[0018] In step 05, the number of control devices and power supplies are determined based on the total number of display units, the audited single-device load capacity of candidate control devices, and the power supply capacity of candidate power supplies. The display units are divided into load sub-regions corresponding to the number of control devices, and port, data group, pixel, and resolution constraints are calculated for each load sub-region. Project-level, cabinet-level, and module component-level bills of materials are output based on the selected display unit, cabinet, and component BOM relationships. The number of control devices depends on the correspondence between the total number of display units and the number of display units that a single control device can support, and the number of power supplies depends on the correspondence between the total number of display units and the number of display units that a single power supply can support. In one embodiment, if a single card can support 144 modules and the total number of display units is 400, then the number of control devices is 400 divided by 144, which equals 2.78, rounded up to 3. In another embodiment, if a single power supply can support 6 modules, then the number of power supplies is 400 divided by 6, which equals 66.67, rounded up to 67.

[0019] Through the above steps, heterogeneous product data from different manufacturers can be standardized and used in calculations in a unified format. The compatibility relationships between products are stored in the form of a compatibility map and are automatically read and judged during the calculation process.

[0020] The calculation result of the total number of display units is automatically used as the common basis for calculating the number of control devices and power supplies. Each calculation step forms a complete calculation chain based on the result of the previous step, avoiding the propagation of errors in the preceding calculations caused by human negligence to all subsequent steps. The execution of multi-constraint filtering ensures that all candidate products participating in the calculation have met all engineering constraints. The output bill of materials includes the number of display units, the number of control devices, and the number of power supplies, and there is a clear order of derivation among these quantities.

[0021] like Figure 2 As shown in the figure, this application also provides a display screen engineering quantity calculation and equipment selection system with multiple product specifications, including a data standardization module, a receiver card classification module, a product library module, a component BOM expansion module, a cabinet selection and calculation module, a compatibility map module, an engineering parameter receiving module, a multi-constraint matching engine, a chain derivation engine, a hierarchical load verification engine, a brand preference analysis module, an economic selection scoring module, a compatibility conflict detection module, a CAD block mapping module, a hypothesis log module, and a structured output module.

[0022] The data standardization module is used to convert heterogeneous product data into a unified data schema.

[0023] The receiver card classification module is used to standardize the classification of receiver cards based on interfaces and transfer relationships. The product library module is used to store the standardized product object collection, supporting querying and filtering by field.

[0024] The compatibility graph module is used to build and maintain a compatibility graph between the receiver card and the module. This compatibility graph is stored in the form G=(V,E), where V is the vertex set containing module nodes and receiver card nodes, and E is the edge set containing compatibility relationship edges. Each compatibility relationship edge has the following attributes: source product identifier (source_product), target product identifier (target_product), relationship type (relation_type), and status (status). Relationship types include interface compatibility, load compatibility, data group compatibility, and brand preference. Statuses include audited, pending, and conflicted. The compatibility graph module supports incremental updates and audit tracing.

[0025] The engineering parameter receiving module is used to receive engineering requirement parameters and brand preferences input by the user.

[0026] The multi-constraint matching engine is used to perform product matching based on engineering parameters.

[0027] The chain-driven derivation engine is used to calculate the number of modules, enclosures, receiver cards, and power supplies in sequence, and generate a hierarchical bill of materials.

[0028] The layered load verification engine is used to perform interface verification, port count verification, data group verification, single card pixel verification, and single card resolution boundary verification for load sub-regions.

[0029] The brand preference parsing module is used to switch between the neutral default mode and the specified brand mode based on user preferences.

[0030] The economic selection scoring module is used to perform weighted scoring on the candidate receiver card set.

[0031] The compatibility conflict detection module is used to detect conflicts when the candidate receiver card set is empty and output alternative suggestions.

[0032] The CAD block mapping module is used to return the corresponding CAD block resource path based on the selection results.

[0033] It is assumed that the log module is used to record all the assumptions made during the derivation process.

[0034] The structured output module is used to output a project specification object (ProjectSpec) that conforms to a preset data pattern. This object includes screen parameters, module parameters, control system parameters, power system parameters, structural system parameters, project-level BOM, enclosure-level BOM, module component-level BOM, assumption list, and data version information.

[0035] The following describes the method for calculating the engineering quantity and selecting equipment for multi-source product specifications of the display screen provided in this application, with reference to specific embodiments: In some implementations, standardization processing includes field mapping, unit conversion, and normalization; standardized product objects also include product identifiers, pixel parameters, electrical parameters, interface information, business availability markers, and source traceability information.

[0036] Specifically, standardization processing includes field mapping, unit conversion, and normalization. Field mapping is the operation of mapping different field names in raw data from different manufacturers to standardized field names. Unit conversion is the operation of converting values ​​from different units of measurement to the same measurement standard. Normalization is the operation of converting different data structures into the same data schema.

[0037] Standardized product objects also include product identification, pixel parameters, electrical parameters, interface information, service availability markers and source traceability information, parent-child assembly relationships, unit usage rules, version information, and alternative group information. Product identification includes the manufacturer's name and product model. Pixel parameters include pixel pitch values ​​and the module's pixel resolution in the width and height directions. Electrical parameters include the module's operating voltage and maximum power consumption, the power supply's rated power, and the receiver card's power supply voltage requirements. Interface information includes the interface types on both the module and receiver card sides. Service availability markers indicate whether the product is eligible for automatic selection. Source traceability information includes the manufacturer's name, data file path, and data acquisition time.

[0038] In one implementation, the indoor P2.5 module, after standardization, has its product identification recorded as the manufacturer's name and specific model number, pixel parameters recorded as a pixel pitch of 2.5 mm and corresponding resolution data, electrical parameters recorded as an operating voltage of 5 volts and maximum power consumption, and interface information recorded as a HUB75 interface. Source traceability information records that the module data originates from the corresponding manufacturer's product manual in portable document format and the page number within that file. Using this information, the system can determine resolution matching based on pixel parameters, verify power supply sufficiency based on electrical parameters, assess interface compatibility between the module and the receiver card based on interface information, and filter products suitable for automatic selection based on service availability tags. Source traceability information ensures data traceability, allowing for correction by tracing the original source when data issues arise.

[0039] In some embodiments, the control device is a receiving card, and the method further includes: Based on the interface type and conversion relationship of the receiving card, the receiving cards are classified into general direct connection receiving cards, brand direct connection receiving cards, and special interface receiving cards. Each receiving card is categorized with a category identifier, an automatic selection flag, a neutral default flag, and a computer-aided design block resource path.

[0040] Specifically, receiver cards are classified based on their interface type and adapter relationship. General-purpose direct-connect receiver cards are those with HUB75 or HUB320 interfaces that can directly connect to modules without an adapter board. Branded direct-connect receiver cards are those belonging to a specific brand, with HUB75 or HUB320 interfaces, and can connect directly without an adapter board. Special interface receiver cards are those that require a HUB board or adapter board to indirectly connect to modules.

[0041] Each receiver card is categorized and marked with four fields: a category identifier recording the category to which the receiver card belongs; an automatic selection participation flag controlling whether the category participates in the automatic selection process; a neutral default flag indicating whether the category is selected by default when brand preference is neutral; and a computer-aided design block resource path recording the storage location of the computer-aided design block file corresponding to the category. In one implementation, the Carlette E80 and E120 receiver cards use the HUB75 interface and do not require an adapter board, belonging to brand direct connection receiver cards; the general HUB75 series receiver cards belong to general direct connection receiver cards; and the Nova MRV416 receiver card requires an adapter board to connect to the module, belonging to special interface receiver cards.

[0042] In some implementations, the relationship types in the compatibility relationship data structure include interface compatibility relationships, load compatibility relationships, data group compatibility relationships, and brand preference relationships; each compatibility relationship is marked with an audited flag, an unaudited flag, or a conflict flag; the compatibility relationship data structure can be incrementally updated and record update history.

[0043] Specifically, the compatibility relationship data structure includes relationship types such as interface compatibility, load compatibility, data group compatibility, and brand preference. Interface compatibility records whether the receiver card's interface type and the module's interface type belong to the same interface category. For example, a receiver card with a HUB75 interface establishes an interface compatibility relationship with a HUB75 interface module, but not with a module using a HUB320 interface. Load compatibility records whether, after load sub-region allocation, the receiver card's maximum load pixel count is greater than or equal to the corresponding load sub-region's pixel count, and whether the receiver card's maximum load width and maximum load height are respectively greater than or equal to the corresponding load sub-region's resolution width and height. Data group compatibility records whether the receiver card's data group definition matches the module's cascading count. Brand preference records the adaptation priority between receiver cards and modules of a specific brand when brand preference is set to that brand.

[0044] Each compatibility relationship is marked with an audited, pending, or conflict flag. An audited flag indicates that the compatibility relationship has been manually reviewed and confirmed, and can be used directly for selection. A pending audit flag indicates that the compatibility relationship has not yet been reviewed and requires manual confirmation before use. A conflict flag indicates that the compatibility relationship has been verified as invalid; for example, a module with a HUB75 interface and a receiver card with a HUB320 interface are marked as conflicting.

[0045] The compatibility relationship data structure can be incrementally updated and its update history recorded. Incremental updates mean that each update only modifies, adds, or deletes the compatibility relationships that have changed, without needing to rebuild all compatibility relationships. In one implementation, when a new receiver card model is added, only the compatibility relationship edges between that receiver card and each module need to be added; existing compatibility relationships of the receiver card do not need to be modified. Recording the update history means that each modification operation records the operation time, operation content, and operator information. In one implementation, when the status of a compatibility relationship changes from pending audit to audited, the system records the operator of the modification operation, the modification time, and the content before and after the status change.

[0046] In some implementations, engineering parameters also include usage environment, pixel pitch, and interface type; multi-constraint filtering includes environment matching, pixel pitch matching, physical size matching, and interface matching; multi-constraint filtering sorts the candidate display unit set according to service priority.

[0047] Specifically, the engineering parameters also include the usage environment, pixel pitch, and interface type. The usage environment includes two categories: indoor and outdoor. Pixel pitch refers to the center distance between two adjacent pixels, and interface type refers to the physical interface type on the module side.

[0048] Multi-constraint filtering includes four matching methods: environment matching (filtered by indoor or outdoor category), pixel spacing matching (filtered by pixel spacing value), physical size matching (filtered by module width and height values), and interface matching (filtered by interface type). After completing the four matching methods, the system sorts the modules according to their preset business priority values ​​from smallest to largest, placing the highest priority modules at the top.

[0049] In one implementation, the user inputs engineering parameters such as indoor, pixel pitch 2.5 mm, and interface type HUB75. The system sequentially performs four matching filters to select all modules that meet the conditions, and then outputs a set of candidate display units according to business priority.

[0050] In some implementations, the total number of display units is calculated based on the physical size information of the candidate display units in the candidate display unit set and the screen size, including: The number of display unit columns is calculated based on the screen width value in the screen size and the width value of the candidate display units in the candidate display unit set; The number of display unit rows is calculated based on the screen height value in the screen size and the height value of the candidate display units in the candidate display unit set. The total number of display cells is obtained by multiplying the number of columns of display cells by the number of rows of display cells.

[0051] Specifically, the number of display unit columns is obtained by dividing the screen width by the candidate module width and then rounding up. In one embodiment, the screen width is 6400 mm, the candidate module width is 320 mm, 6400 divided by 320 equals 20, and the number of display unit columns is 20. In another embodiment, the screen width is 6450 mm, the candidate module width is 320 mm, 6450 divided by 320 equals 20.15625, which is rounded up to 21 columns to cover the extra 50 mm margin in the width direction.

[0052] The number of display unit rows is obtained by dividing the screen height by the candidate module height and rounding up. In one embodiment, the screen height is 3200 mm, the candidate module height is 160 mm, 3200 divided by 160 equals 20, and the number of display unit rows is 20.

[0053] The total number of display units is equal to the product of the number of columns and the number of rows of display units. In one embodiment, 20 columns multiplied by 20 rows equals 400 modules. In another embodiment, 21 columns multiplied by 21 rows equals 441 modules. This total number of display units is the basis for subsequent calculations of the number of receiver cards and power supplies.

[0054] In some implementations, the system filters candidate display units based on their row and column arrangement, the number of display units per unit, maintenance direction, installation environment, interface type, and the installation space for control equipment and power supply. It then calculates the number of units and generates a unit-level bill of materials (BOM). The BOM includes at least one of the following: unit body, mounting or splicing connectors, power supply, control equipment, interface board, maintenance components, and corresponding auxiliary materials.

[0055] In some implementations, the user specifies the LED chip brand and driver IC brand for a selected P2.5 or other specification display unit. The component BOM expansion module selects the corresponding LED chips and driver ICs from a multi-source component specification library; for unspecified PCBs, connectors, masks, fasteners, and other components, the corresponding components are inherited from the audited historical BOM version associated with the display unit. The system performs package and pad, interface, channel count, scan method, electrical parameters, and version compatibility checks on the selected and inherited components; if the checks pass, it outputs the module component-level bill of materials, differences, alternative groups, source versions, and check results; if the checks fail, it outputs the reason for the conflict and alternative components.

[0056] In some implementations, the method further includes dividing the display unit into multiple loaded sub-regions based on the number of control devices, the number of candidate control device ports, and data group definitions, and performing multi-level verification on the candidate control devices corresponding to the loaded sub-regions: Verify whether the interface type of the candidate control device and the interface type of the display unit belong to the same interface category; Verify whether the number of ports of the candidate control devices can cover the cascading requirements of the display units in the corresponding loaded sub-regions; Verify whether the data group definition of the candidate control device matches the number of cascaded display units in the corresponding loaded sub-region; Check whether the number of pixels in each loaded sub-region is less than or equal to the maximum number of loaded pixels of the corresponding candidate control device; Check whether the resolution width value of each loaded sub-region is less than or equal to the maximum load width value of the corresponding candidate control device, and check whether the resolution height value of each loaded sub-region is less than or equal to the maximum load height value of the corresponding candidate control device. Recommended control devices are determined based on the candidate control devices that enable all loaded sub-regions to pass the above verification and their sub-region allocation schemes; candidate control devices that fail verification, verification layers that fail verification, and reasons for failure are recorded in the conflict log.

[0057] Specifically, after the chain-driven derivation engine outputs the total number of modules, the number of control devices, the load sub-region allocation scheme, and the candidate receiving card set, the hierarchical load verification engine performs five-layer verification on the candidate receiving cards. The five-layer verification is performed sequentially from the first layer to the fifth layer.

[0058] The first layer of verification (L1) is interface verification. The layered on-board verification engine checks whether the interface type of the candidate receiver card belongs to the same interface category as the module's interface type. For example, when the module's interface type is HUB75, receiver cards with the same HUB75 interface type can pass the interface verification; receiver cards with different interface types only pass this layer of verification if there is an audited switching or adaptation relationship in the compatibility relationship data structure.

[0059] The second layer of verification (L2) is a port count verification. The layered load verification engine checks whether the number of ports of the candidate receiving card can cover the display unit cascading requirements of the corresponding load sub-region. In one implementation, when the cascading direction of the load sub-region is horizontal, the number of ports of the receiving card must be greater than or equal to the number of rows of display units in that load sub-region; when the cascading direction of the load sub-region is vertical, the number of ports of the receiving card must be greater than or equal to the number of columns of display units in that load sub-region.

[0060] The third layer of verification (L3) is data group verification. The layered load verification engine checks whether the data group definition of the candidate receiver card matches the number of display units cascaded in the corresponding load sub-region. The data group definition of the receiver card specifies the number of data groups that each output port can carry, and the number of modules cascaded specifies the number of modules that each receiver card needs to drive in cascade. The layered load verification engine compares the two values ​​to confirm whether they match.

[0061] The fourth layer verification (L4) is a total pixel verification. The layered load capacity verification engine checks whether the number of pixels in each load capacity sub-region is less than or equal to the maximum load capacity of the corresponding candidate receiver card. The number of pixels in a load capacity sub-region is the product of the number of modules in that sub-region and the pixel resolution of a single module. The maximum load capacity is the upper limit of pixel load capacity specified by the receiver card in the datasheet.

[0062] The fifth layer check (L5) is a boundary check. The layered load check engine checks whether the width and height values ​​of each load sub-region resolution are less than or equal to the maximum load width and maximum load height values ​​of the corresponding candidate receiver card.

[0063] The layered load verification engine recommends candidate control devices that pass all five layers of verification. In one implementation, the system determines the number of control devices based on the audited load parameters of the candidate receiver cards and divides the project into multiple load sub-regions; it then performs layer 4 and layer 5 verification on each load sub-region. The layered load verification engine records candidate control devices that fail verification, along with the failed verification layers and reasons for failure, in a conflict log. The conflict log records information including the receiver card model, the number of the failed verification layer, and the reason for failure, such as L4 verification failure or the total number of pixels exceeding the maximum load pixel count. This conflict log is subsequently used to trigger the alternative matching process of the compatibility conflict detection module.

[0064] In some implementations, the method further includes receiving user selection input: When the selection input includes the receiver card model explicitly specified by the user, the receiver card corresponding to the receiver card model will be selected; When the selection input does not include the receiver card model explicitly specified by the user but includes a specified brand name, select the receiver card that has passed multi-level verification from the receiver cards corresponding to the brand name; When the selection input does not include the receiver card model explicitly specified by the user and the selection input is in neutral default mode, a receiver card that has passed multi-level verification will be selected from the general direct connection receiver cards.

[0065] Specifically, when the user's selection input includes an explicitly specified receiver card model, the brand preference resolution module prioritizes the receiver card corresponding to that model, and the layered load balancing engine performs a five-layer verification. If the verification fails, a conflict warning, a manual confirmation request, or an alternative solution is output. In one implementation, the user specifies the receiver card model as Nova MRV416-N in the engineering parameters, and the brand preference resolution module prioritizes the Nova MRV416-N receiver card and performs a five-layer verification.

[0066] When the user's selection input does not contain an explicitly specified receiver card model but includes a specified brand name, the brand preference resolution module limits the selection range to receiver cards corresponding to that brand name. The layered load balancing verification engine performs five layers of verification within this range, and the brand preference resolution module selects from receiver cards that have passed all five layers of verification. In one implementation, after the user specifies a brand name, the brand preference resolution module limits the selection range to receiver cards corresponding to that brand and selects from candidate receiver cards that have passed all five layers of verification based on audited product specification data and load balancing sub-region allocation scheme.

[0067] When the user's selection input does not include an explicitly specified receiver card model and the selection input is in neutral default mode, the brand preference parsing module limits the selection range to general direct-connect receiver cards. The layered load balancing verification engine performs five layers of verification within this range, and the brand preference parsing module selects from general direct-connect receiver cards that have passed all five layers of verification. In one implementation, if the user does not specify any brand and the selection input is in neutral default mode, the brand preference parameter (brand_preference) is set to neutral default, and the brand preference parsing module limits the selection range to general direct-connect receiver cards.

[0068] User-specified receiver card model takes precedence over brand name, which in turn takes precedence over the neutral default mode. When a user specifies both receiver card model and brand name, the brand preference resolution module prioritizes the user-specified receiver card model as a candidate and performs a five-layer verification. If a user specifies a brand name but no receiver card under that brand name passes all five-layer verifications, the brand preference resolution module triggers the alternative matching process of the compatibility conflict detection module.

[0069] In some implementations, the method further includes performing an economic selection score on candidate control devices that have passed all multi-level verifications: Obtain the unit cost score, load utilization score, inventory availability score and after-sales stability score for each candidate control device. The load utilization rate is the ratio of the number of allocated pixels in the load sub-region to the maximum load pixel count of the corresponding candidate control device. The total score is calculated by weighting the unit cost score, load utilization rate score, inventory availability score and after-sales stability score, and the candidate control device with the highest total score is selected.

[0070] Specifically, after the layered load verification engine outputs a set of candidate receiver cards that have passed all five layers of verification, the economic selection scoring module performs multi-dimensional weighted scoring on each candidate receiver card in the set to select the optimal recommended solution.

[0071] The unit cost score is calculated based on the purchase price of each candidate receiver card; the lower the purchase price, the higher the score.

[0072] The load utilization rate score is the ratio of the number of pixels allocated to each load sub-region to the maximum load pixel count of the corresponding candidate receiver card. The number of pixels allocated to each load sub-region is the product of the number of modules in that load sub-region and the pixel resolution of a single module. The closer this ratio is to 1, the more fully the load capacity of the corresponding receiver card is utilized, while not exceeding its audited load limit. In one implementation, the system calculates the load utilization rate for each candidate control device number and load sub-region allocation scheme, and only performs an economic score on schemes where all sub-regions meet the load limit.

[0073] Inventory availability score is calculated based on the current inventory of the receiving card in the warehouse; the higher the inventory, the higher the score. After-sales stability score is calculated based on the supply stability of the receiving card and the level of after-sales support.

[0074] The unit cost score, load utilization score, inventory availability score, and after-sales stability score are each multiplied by their corresponding weighting coefficients, and the four products are summed to obtain the total score. The weighting coefficients are pre-set according to project requirements; for example, the weighting coefficient for the unit cost score is increased in cost-sensitive projects, and the weighting coefficient for the inventory availability score is increased in projects with tight deadlines. The economic selection scoring module selects the candidate control device with the highest total score as the recommended solution. In one implementation, both the candidate general-purpose HUB75-12 port receiver card and the general-purpose HUB75-16 port receiver card pass all five layers of verification. The general-purpose HUB75-12 port receiver card has a higher total score than the general-purpose HUB75-16 port receiver card. The economic selection scoring module selects the general-purpose HUB75-12 port receiver card as the recommended solution, and the selection reason field records the basis for the higher load utilization score of the general-purpose HUB75-12 port receiver card compared to the general-purpose HUB75-16 port receiver card.

[0075] like Figure 3 As shown, in one embodiment, a computer device is provided, which may be a server. The computer device includes a processor, a memory, a network interface, and a database connected via a system bus; when the computer program is executed by the processor, it implements the functions or steps of the aforementioned multi-source product specification display screen engineering quantity calculation and equipment selection method on the server side.

[0076] like Figure 4 As shown, in one embodiment, a computer device is provided, which can be a client. The computer device includes a processor, memory, network interface, display screen, and input device connected via a system bus; when the computer program is executed by the processor, it implements the functions or steps of the aforementioned multi-source product specification display screen engineering quantity calculation and equipment selection method on the client side.

[0077] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0078] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0079] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0080] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for calculating the engineering quantity and selecting equipment for display screens with multiple product specifications, characterized in that, Includes the following steps: Obtain the original product parameters from heterogeneous data sources of at least two display screen manufacturers, perform standardization processing on each of the original product parameters, and obtain a standardized product object in a unified format. The standardized product object includes physical size information and load capacity information, and also includes product category, parent-child assembly relationship, component specifications, unit usage rules, version information and source traceability information. Construct a compatibility relationship data structure between different standardized product objects, wherein the compatibility relationship data structure contains at least two relationship types; The system receives engineering parameters input by the user, including screen size. Based on these engineering parameters, it performs multi-constraint filtering on the standardized product object whose product category is display unit, to obtain a set of candidate display units. The total number of display units is calculated based on the physical size information of the candidate display units in the candidate display unit set and the screen size; Based on the total number of display units, the single-device load capacity of candidate control devices, and the power supply capacity of candidate power supplies, calculate the number of control devices and the number of power supplies; divide the display units into load sub-regions corresponding to the number of control devices; based on the candidate display units, candidate control devices, candidate power supplies, candidate cabinets, and the component bill of materials relationships associated with the candidate display units or candidate cabinets, output project-level, cabinet-level, and module component-level bills of materials, wherein the module component-level bill of materials includes at least LEDs, driver chips, circuit boards, and other related components.

2. The method according to claim 1, characterized in that, The standardization process includes field mapping, unit conversion, and normalization; the standardized product object also includes product identifier, pixel parameters, electrical parameters, interface information, business availability markers, and source traceability information.

3. The method according to claim 1, characterized in that, The control device is a receiving card, and the method further includes: Based on the interface type and conversion relationship of the receiving card, the receiving cards are classified into general direct connection receiving cards, brand direct connection receiving cards, and special interface receiving cards. Each receiving card is categorized with a category identifier, an automatic selection tag, a neutral default tag, and a computer-aided design block resource path.

4. The method according to claim 1, characterized in that, The relationship types in the compatibility relationship data structure include interface compatibility relationships, load compatibility relationships, data group compatibility relationships, brand preference relationships, and component assembly compatibility relationships; Each compatibility relationship is marked with an audited flag, an unaudited flag, or a conflict flag; the compatibility relationship data structure can be incrementally updated and record the update history.

5. The method according to claim 1, characterized in that, The engineering parameters also include the usage environment, pixel pitch, and interface type; the multi-constraint filtering includes environment matching, pixel pitch matching, physical size matching, and interface matching; the multi-constraint filtering sorts the candidate display unit set according to business priority.

6. The method according to claim 1, characterized in that, The step of calculating the total number of display units based on the physical size information of the candidate display units in the candidate display unit set and the screen size includes: The number of display unit columns is calculated based on the screen width value in the screen size and the width value of the candidate display units in the candidate display unit set; The number of display unit rows is calculated based on the screen height value in the screen size and the height value of the candidate display unit in the candidate display unit set. The total number of display units is obtained by multiplying the number of columns of the display units by the number of rows of the display units.

7. The method according to claim 1, characterized in that, The method further includes dividing the display unit into multiple loaded sub-regions based on the number of control devices, the number of ports of the candidate control devices, and the data group definition, and performing multi-layer verification on the candidate control devices corresponding to the loaded sub-regions: Verify whether the interface type of the candidate control device and the interface type of the display unit belong to the same interface category; Verify whether the number of ports of the candidate control devices can cover the cascading requirements of the display units in the corresponding loaded sub-regions; Verify whether the data group definition of the candidate control device matches the number of cascaded display units in the corresponding loaded sub-region; Check whether the number of pixels in each loaded sub-region is less than or equal to the maximum number of loaded pixels of the corresponding candidate control device; Check whether the resolution width value of each loaded sub-region is less than or equal to the maximum load width value of the corresponding candidate control device, and check whether the resolution height value of each loaded sub-region is less than or equal to the maximum load height value of the corresponding candidate control device. Recommended control devices are determined based on the candidate control devices that enable all loaded sub-regions to pass the above verification and their sub-region allocation schemes; candidate control devices that fail verification, verification layers that fail verification, and reasons for failure are recorded in the conflict log.

8. The method according to claim 7, characterized in that, The method also includes receiving user selection input: When the selection input includes a receiver card model explicitly specified by the user, the receiver card corresponding to the receiver card model is taken as the priority candidate, and the multi-layer verification is performed on it; When the selection input does not contain the receiver card model explicitly specified by the user and the selection input contains a specified brand name, a receiver card that has passed the multi-level verification is selected from the receiver cards corresponding to the brand name. When the selection input does not include the receiver card model explicitly specified by the user and the selection input is in neutral default mode, a receiver card that has passed the multi-layer verification is selected from the general direct connection receiver cards.

9. The method according to claim 7, characterized in that, The method further includes performing an economic selection score on candidate control devices that have passed all multi-level verifications: The unit cost score, load utilization score, inventory availability score, and after-sales stability score of each candidate control device are obtained. The load utilization rate is the ratio of the number of allocated pixels in the load sub-region to the maximum number of load pixels of the corresponding candidate control device. The total score is calculated by weighting the unit cost score, the load utilization rate score, the inventory availability score, and the after-sales stability score, and the candidate control device with the highest total score is selected.

10. The method according to claim 1, characterized in that, The candidate cabinets are selected and their quantities are calculated based on at least one of the following: the row and column arrangement of the candidate display units, the number of display units that can be accommodated in a single cabinet, the maintenance direction, the installation environment, the interface type, and the installation space for the control equipment and power supply; the cabinet-level bill of materials includes at least one of the following: cabinet body, installation or splicing connectors, power supply, control equipment, interface board, maintenance parts, and corresponding auxiliary materials.

11. The method according to claim 1, characterized in that, The generation of the module component-level bill of materials includes: selecting the corresponding LED and / or driver chip from a multi-source component specification library according to the LED brand and / or driver chip brand specified by the user; for unspecified components, inheriting the corresponding components from the audited historical bill of materials version associated with the candidate display unit; performing at least one of the following checks on the selected and inherited components: package, pads, interface, number of channels, scanning method, electrical parameters, or version compatibility, and outputting the quantity, alternative group, source version, and check results of each component.

12. A system for calculating the engineering quantity and selecting equipment for display screens with multiple product specifications, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 11.

Images