Data warehouse modeling method, device and system, medium and data warehouse

Abstract

The invention discloses a photovoltaic cell production and operation-oriented data warehouse modeling method, device and system, a storage medium, a computer product and a data warehouse. The method comprises the following steps: determining an associated system and equipment related to the whole process of photovoltaic cell production and operation; constructing a data source layer, an access layer, a model layer and an application layer for the associated system and equipment; wherein the model layer adopts a layered design; and forming the data warehouse by using the data source layer, the access layer, the model layer and the application layer. According to the method, the data integration efficiency is improved, and the processing performance of the multi-source data is improved, so that the service agility and the decision-making capability are optimized.

Description

Technical Field

[0001] This application relates to the field of industrial data processing, and in particular to a data warehouse modeling method, apparatus, system, storage medium, computer product, and data warehouse for photovoltaic cell production and operation. Background Technology

[0002] Driven by the global energy structure transformation and the "dual-carbon" strategic goal, the photovoltaic industry continues to expand in scale and accelerate technological iteration, making the photovoltaic cell manufacturing process increasingly complex and sophisticated. Massive amounts of multi-source, heterogeneous, and high-concurrency data are generated during production and operation, including structured and unstructured data from MES (Manufacturing Execution System), SCADA (Supervisory and Data Acquisition System), ERP (Enterprise Resource Planning), QMS (Quality Management System), and various IoT sensing devices. However, the photovoltaic industry currently faces severe challenges in data management, mainly manifested in: Severe data silos: Production data, equipment status data, process parameters, and quality inspection results are scattered across multiple independent systems, lacking effective data integration and sharing mechanisms, leading to difficulties in cross-system data analysis and making it difficult for management to obtain a unified global data view. Insufficient real-time data processing: Traditional relational database-based data warehouse architectures are ill-suited to handle the high-frequency, real-time time-series data generated during photovoltaic cell production, resulting in significant data integration and processing delays that fail to meet the timeliness requirements of real-time production monitoring, dynamic adjustment of process parameters, and immediate early warning of quality anomalies. Slow response to business needs: Photovoltaic cell production indicators are diverse, and the calculation logic often changes dynamically with customer needs, product models, and process routes. Existing systems mostly adopt customized development methods to meet new requirements, resulting in long development cycles, high labor costs, and difficulty in supporting rapid business iteration and agile analysis. Weak advanced analysis capabilities: Traditional data warehouses have significant bottlenecks in computing performance and model flexibility, lacking effective support for complex analysis scenarios (such as predictive equipment maintenance, process parameter optimization, and root cause analysis). Data value is not fully explored, making it difficult to support intelligent decision-making. Furthermore, lack of operational indicator control: There is a lack of a systematic operational indicator management mechanism, data standards are inconsistent, and continuous, automatic tracking of indicators is impossible, making it impossible to proactively detect anomalies at the first sign of trouble. Summary of the Invention

[0003] To address at least one of the aforementioned technical problems, this application discloses a data warehouse modeling method, apparatus, system, storage medium, computer product, and data warehouse for photovoltaic cell production and operation. The constructed data warehouse enables unified data management, improves data real-time performance, and optimizes data processing efficiency. On the business side, it allows for flexible responses to changing demands and enhances the efficient analysis of production and operational indicators.

[0004] The first aspect of this application provides a data warehouse modeling method for photovoltaic cell production and operation. The method may include: identifying the associated systems and equipment related to the entire process of photovoltaic cell production and operation; constructing, for the associated systems and equipment, a data source layer for obtaining end-to-end data from the associated systems and equipment, an access layer for integrating the end-to-end data, a model layer with a layered design for generating data processing results based on the integrated end-to-end data, and an application layer for displaying the data processing results and / or the analysis results of the data processing results; and using the data source layer, the access layer, the model layer, and the application layer to form the data warehouse.

[0005] According to some embodiments of this application, the end-to-end data may include at least production business data, process and equipment data, and quality inspection data; the data source layer is communicatively connected to the associated systems and equipment to obtain the end-to-end data.

[0006] According to some embodiments of this application, the end-to-end data may include first data transmitted to the access layer in real time based on a high-performance distributed message queue, and second data transmitted to the access layer intermittently based on a preset time period.

[0007] According to some embodiments of this application, the high-performance distributed message queue may include Kafka; the second data may be acquired based on the data synchronization tool DataX at preset time intervals.

[0008] According to some embodiments of this application, the data integration may include at least extraction, transformation, and loading ELT processing, and the end-to-end data can be written into the model layer after the data integration.

[0009] According to some embodiments of this application, the calculation results obtained by performing aggregation calculations on the end-to-end data after data integration are written into the model layer.

[0010] According to some embodiments of this application, the data integration can be performed using a framework and distributed processing engine Flink or a scheduling system DolphinScheduler. The end-to-end data after the data integration and the calculation results can be written to the model layer through a high-performance distributed message queue, including Kafka, or an HTTP interface.

[0011] According to some embodiments of this application, the model layer with a layered design can be built based on ClickHouse, including a data storage layer (ODS), a detailed data layer (DWD), a summary data layer (DWS), and an application data layer (ADS). The ODS layer receives and stores cleaned end-to-end data, the DWD layer constructs consistent dimensions and fact tables based on the integrated end-to-end data, the DWS layer constructs a wide table model based on the calculation results, and the ADS layer forms a table structure for data querying and display.

[0012] According to some embodiments of this application, generating the data processing result may include: calling data stored in two or more of the ODS layer, the DWD layer, the DWS layer, and the ADS layer, performing data analysis to obtain the data processing result; the data processing result includes at least the capacity analysis result, work-in-process analysis result, warehousing analysis result, incoming material analysis result, energy consumption analysis result, screen printing plate analysis result, slurry analysis result, yield analysis result, quality analysis result, and equipment analysis result.

[0013] According to some embodiments of this application, the method may further include: obtaining a configuration table, the configuration table including changeable calculation rules that constrain the data analysis; and performing data analysis on the layer data based on the configuration table to obtain the data processing result.

[0014] According to some embodiments of this application, the data warehouse can be encapsulated as a data service interface using SQL scripts; the data service structure is configured to receive indicator filtering instructions and output target indicators determined from the layer data based on the indicator filtering instructions.

[0015] According to some embodiments of this application, the analysis results of displaying the data processing results may include: determining abnormal indicators contained in the data processing results; performing correlation analysis based on the abnormal indicators to determine the abnormal factors that cause the abnormal indicators; displaying the abnormal indicators and / or the abnormal factors; the display includes at least an alarm.

[0016] A second aspect of this application provides a data warehouse modeling apparatus for photovoltaic cell production and operation. The modeling apparatus may include: a determination module configured to determine the associated systems and equipment related to the entire process of photovoltaic cell production and operation; a construction module configured to construct, for the associated systems and equipment, a data source layer for obtaining end-to-end data from the associated systems and equipment, an access layer for integrating the end-to-end data, a model layer for storing the integrated end-to-end data, a layered model layer for generating data processing results based on the integrated end-to-end data, and an application layer for displaying the data processing results and / or the analysis results of the data processing results; and a composition module configured to compose the data warehouse using the data source layer, the access layer, the model layer, and the application layer.

[0017] A third aspect of this application provides a data warehouse for photovoltaic cell production and operation, which can be obtained based on the data warehouse modeling method described above.

[0018] The fourth aspect of this application provides a data warehouse modeling system for photovoltaic cell production and operation. The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the data warehouse modeling method described above.

[0019] The fifth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the data warehouse modeling method described above.

[0020] The sixth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data warehouse modeling method described above.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] This application will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein: Figure 1 These are exemplary schematic diagrams of a data warehouse modeling system according to some embodiments of this application; Figure 2 This is a block diagram illustrating an exemplary computing device according to some embodiments of this application; Figure 3 This is an exemplary flowchart of a data warehouse modeling method for photovoltaic cell production and operation, as shown in some embodiments of this application; Figure 4 These are exemplary schematic diagrams illustrating data access and integration at the access layer according to some embodiments of this application; Figure 5 This is another exemplary schematic diagram illustrating data access and integration at the access layer according to some embodiments of this application; Figure 6 This is an exemplary schematic diagram illustrating the analysis of abnormal indicators according to some embodiments of this application; Figure 7 This is another exemplary schematic diagram illustrating the analysis of abnormal indicators according to some embodiments of this application; Figure 8 This is an exemplary block diagram of a processing system for implementing the data warehouse method for photovoltaic cell production and operation, according to some embodiments of this application. Detailed Implementation

[0023] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the specific embodiments of this application are described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of this application. Therefore, this application is not limited to the specific embodiments disclosed below.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein in the specification of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The terms “first,” “second,” and similar terms used herein do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as “comprising” or “including” mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as “upper,” “lower,” “left,” and “right” are used only to indicate relative positional relationships, which may change accordingly when the absolute position of the described object changes. The terms “and / or” or “and / or” as used herein include any and all combinations of one or more of the associated listed items.

[0025] The following description, with reference to the accompanying drawings, illustrates some preferred embodiments of the present application. It should be noted that the following description is for illustrative purposes only and is not intended to limit the scope of protection of the present application. The flowcharts used are for illustrating the operations performed by the system according to embodiments of the present application. It should be understood that the described operations are not necessarily performed precisely in sequence. Instead, various steps may be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more steps may be removed from these processes.

[0026] Figure 1 This is an exemplary schematic diagram of a data warehouse modeling system according to some embodiments of this application. In some embodiments, the data warehouse modeling system 100 can be used for automatic identification and automatic cutting of fabric to be cut. Figure 1 As shown, the data warehouse modeling system 100 may include processing equipment 110, storage equipment 120, terminal 130, network 140, and data source 150.

[0027] Processing device 110 can be used to process information and / or data related to photovoltaic cell production and operation to perform one or more functions disclosed in this application. For example, processing device 110 can identify associated systems and equipment related to the entire photovoltaic cell production and operation process. As another example, processing device 110 can construct, for the associated systems and equipment, a data source layer for acquiring end-to-end data from the associated systems and equipment, an access layer for integrating the end-to-end data, a layered model layer for storing the integrated end-to-end data, a layered model layer for generating data processing results based on the integrated end-to-end data, and an application layer for displaying the data processing results and / or the analysis results of the data processing results. As yet another example, processing device 110 can determine whether the detected feature is within the deviation range of a standard feature. Furthermore, processing device 110 can utilize the data source layer, the access layer, the model layer, and the application layer to form the data warehouse.

[0028] In some embodiments, the processing device 110 may be implemented by a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, the processing device 110 may be local or remote. For example, the processing device 110 may access information and / or data stored on storage device 120 via network 140, or receive information and / or data sent by data source 150. As another example, the processing device 110 may directly connect to storage device 120 to access stored information and / or data. In some embodiments, the processing device 110 may be implemented on a cloud platform. As merely an example, the cloud platform may include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, multi-cloud, etc., or any combination of the above examples. In some embodiments, the processing device 110 may be implemented in conjunction with this application. Figure 2 This is implemented on the computing device shown. For example, the processing device 110 can be implemented on a computing device such as... Figure 2 Implemented on a computing device 200, as shown, including one or more components in the computing device 200.

[0029] In some embodiments, the processing device 110 may include one or more processing engines (e.g., a single-core processing engine or a multi-core processor). By way of example only, the processing device 110 may include one or more combinations of a central processing unit (CPU), an application-specific integrated circuit (ASIC), a special-purpose instruction set processor (ASIP), a graphics processing unit (GPU), a physical processing unit (PPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic controller (PLC), a programmable logic device (PLD), a controller, a microcontroller unit (MCU), a reduced instruction set computer (RISC), a microprocessor, etc.

[0030] Storage device 120 can store data and / or instructions. In some embodiments, storage device 120 can store data and / or information related to photovoltaic cell production and operation obtained from data source 150. In some embodiments, storage device 120 can store data and / or instructions for execution or use by processing device 110, which can implement the exemplary methods in this application by executing or using the data and / or instructions. In some embodiments, storage device 120 can be part of processing device 110. In some embodiments, storage device 120 can include mass storage, removable storage, volatile read-write storage (RAM), read-only storage (ROM), etc., or any combination thereof. Exemplary mass storage can include disks, optical disks, solid-state drives, etc. Exemplary removable storage can include flash drives, floppy disks, optical disks, memory cards, compact disks, magnetic tapes, etc. Exemplary RAM can include dynamic RAM (DRAM), double-rate synchronous dynamic RAM (DDR SDRAM), static RAM (SRAM), thyristor RAM (T-RAM), and zero-capacitance RAM (Z-RAM), etc. Exemplary ROMs may include mask ROMs (MROMs), programmable ROMs (PROMs), erasable programmable ROMs (PEROMs), electronically erasable programmable ROMs (EEPROMs), optical disc ROMs (CD-ROMs), and digital universal disk ROMs (DVMs). In some embodiments, storage device 120 may be a distributed storage system. In some embodiments, storage device 120 may be implemented on a cloud platform. As an example only, the cloud platform may include private clouds, public clouds, hybrid clouds, community clouds, distributed clouds, internal clouds, multi-layered clouds, etc., or any combination thereof. For example, some algorithms or data in this application may be stored on a cloud platform and updated periodically. Processing device 110 accesses these algorithms or data via a network to achieve the unification and interaction of algorithms or data across the entire platform.

[0031] Terminal 130 can be the operating front end of processing device 110, and may include, but is not limited to, mobile devices 130-1, tablet computers 130-2, laptop computers 130-3, desktop computers 130-4, or any combination thereof. The operator can input control commands corresponding to operations that the data warehouse modeling system 100 can execute on terminal 130. For example, inputting index filtering commands to enable processing device 110 to filter relevant indicators in the production and operation process of photovoltaic cells. In some embodiments, terminal 130 can be integrated with processing device 110. For example, the computing power (e.g., CPU, GPU, etc.) of terminal 130 can be used to implement the functions of processing device 110. The input ports of terminal 130 (e.g., the touch virtual keyboard of mobile devices 130-1 and tablet computers 130-2, such as smartphones, and the mouse and keyboard of laptop computers 130-3 and desktop computers 130-4) can be used for inputting operation commands.

[0032] Network 140 can facilitate the exchange of information and / or data. In some embodiments, one or more components of the data warehouse modeling system 100 (e.g., processing device 110, storage device 120, terminal 130, and data source 150) can transmit information to other components of the data warehouse modeling system 100 via network 140. In some embodiments, network 140 can be any form of wired or wireless network, or any combination thereof. By way of example only, network 140 can be a wired network, fiber optic network, telematics network, internal network, Internet, fieldbus (e.g., PROFIBUS, MODBUS, DeviceNet, CANopen, etc.), Ethernet (e.g., EtherNet / IP, PROFINET, EtherCAT, Modbus). TCP, etc.), Local Area Network (LAN), Wide Area Network (WAN), Wireless Local Area Network (WLAN), Metropolitan Area Network (MAN), Public Switched Telephone Network (PSTN), Bluetooth Network, Purple Bee Network, Near Field Communication (NFC) Network, Global System for Mobile Communications (GSM) Network, Code Division Multiple Access (CDMA) Network, Time Division Multiple Access (TDMA) Network, General Packet Radio Service (GPRS) Network, Enhanced Data Rate GSM Evolution (EDGE) Network, Wideband Code Division Multiple Access (WCDMA) Network, High-Speed ​​Downlink Packet... The network 140 may include one or more combinations of the following: High-Speed ​​Access Network (HSDPA), Long Term Evolution (LTE) network, User Datagram Protocol (UDP) network, Transmission Control Protocol / Internet Protocol (TCP / IP) network, Short Message Service (SMS) network, Wireless Application Protocol (WAP) network, Ultra-Wideband (UWB) network, Mobile Communication (1G, 2G, 3G, 4G, 5G, 6G, etc.) network, Wi-Fi, Li-Fi, Narrowband Internet of Things (NB-IoT), Infrared Communication, Serial Communication (e.g., RS-232, RS-485, etc.), Parallel Communication, Fiber Optic Communication, OPC (OLE for Process Control), Internet of Things (IIoT) protocols (e.g., MQTT, AMQP, CoAP, etc.), Time-Sensitive Networking (TSN), etc. In some embodiments, network 140 may include one or more network access points. For example, network 140 may include wired or wireless network access points such as base stations and / or Internet exchange points. Through these network access points, one or more components of the data warehouse modeling system 100 may connect to network 140 to exchange information and / or data.

[0033] Data source 150 can provide various types of data generated during the production and operation of photovoltaic cells, including real-time streaming data and batch data. For example, data source 150 can provide end-to-end data on photovoltaic cell production and operation, including but not limited to Manufacturing Execution System (MES), Enterprise Resource Planning System (ERP), Supervisory Control and Data Acquisition (SCADA) system, and various manufacturing / quality inspection equipment. After collection, this end-to-end data can be transmitted via network 140 to processing device 110 for data warehouse modeling.

[0034] Figure 2 This is a block diagram illustrating an exemplary computing device according to some embodiments of this application. The computing device 200 may include any components used to implement the system described in the embodiments of this application. For example, the computing device 200 may be implemented using hardware, software programs, firmware, or a combination thereof as the aforementioned processing device 110. For convenience, only one computing device is shown in the figure; however, the computing functions related to the data warehouse modeling system 100 described in the embodiments of this application may be implemented in a distributed manner by a set of similar platforms to distribute the system's processing load.

[0035] In some embodiments, computing device 200 may include processor 210, memory 220, input / output 230, and communication port 240. In some embodiments, the processor (e.g., CPU) 210 may execute program instructions as one or more processors. In some embodiments, the memory 220 may include different forms of program memory and data memory, such as hard disk, read-only memory (ROM), random access memory (RAM), etc., for storing various data files processed and / or transmitted by the computer. In some embodiments, the input / output 230 may be used to support input / output between computing device 200 and other components. In some embodiments, the communication port 240 may be connected to a network for data communication. Exemplary processing devices may include program instructions executed by processor 210 stored in read-only memory (ROM), random access memory (RAM), and / or other types of non-transitory storage media. The methods and / or processes of the embodiments of this application may be implemented as program instructions. Computing device 200 may also receive programs and data disclosed in this application via network communication.

[0036] For ease of understanding, Figure 2Only one processor is illustrated in the illustration. However, it should be noted that the computing device 200 in this embodiment may include multiple processors. Therefore, the operations and / or methods implemented by one processor as described in this embodiment may also be implemented jointly or independently by multiple processors. For example, if, in this application, the processor of computing device 200 executes operations A and B, it should be understood that operations A and B may also be executed jointly or independently by two different processors of computing device 200 (e.g., the first processor executes operation A, the second processor executes operation B, or the first and second processors jointly execute operations A and B).

[0037] Figure 3 This is an exemplary flowchart of a data warehouse modeling method for photovoltaic cell production and operation, according to some embodiments of this application. In some embodiments, process 300 can be executed by processing system 900. For example, process 300 can be stored in a storage device (such as the built-in storage unit of processing system 900 or an external storage device) in the form of a program or instructions, which, when executed, can implement process 300. Figure 3 As shown, process 300 may include the following operations.

[0038] Step 310: Identify the related systems and equipment involved in the entire photovoltaic cell production and operation process. This step can be performed by the identification module 810.

[0039] It is understood that the production and operation of photovoltaic cells involves multiple core stages, including silicon material preparation, silicon wafer processing, cell manufacturing, and module packaging, as well as operational stages related to production output and quality within these stages. Based on this, the associated systems and equipment may include, but are not limited to, Manufacturing Execution Systems (MES) / Enterprise Resource Planning (ERP) systems for recording work order information, work reports, material movement, and inventory status; Supervisory Control and Data Acquisition (SCADA) systems / equipment controllers (such as PLCs) for acquiring real-time process parameters (e.g., temperature, pressure, speed, gas flow), equipment status logs (e.g., operation, shutdown, fault), and alarm information; and testing equipment such as IV testing machines, electroluminescence (EL) testing equipment, photoluminescence (PL) testing equipment, and automated optical inspection (AOI) equipment for product quality testing (e.g., various electrical performance parameters such as Isc, Voc, FF, Eta). The determination module 810 can determine the associated systems and equipment based on the specific production and testing process of photovoltaic cells.

[0040] Step 320: For the associated systems and devices, construct the data source layer, access layer, model layer, and application layer. This step can be performed by the construction module 820.

[0041] In some embodiments, the data source layer can be used to acquire end-to-end data from the associated systems and devices, comprehensively integrating the raw data generated by various associated systems and devices throughout the entire photovoltaic cell production and operation process, serving as the data input source for the entire data warehouse. The access layer is used to integrate the end-to-end data after it has been accessed and buffered. The layered design of the model layer can be built based on ClickHouse, including a data storage layer (ODS), a detailed data layer (DWD), a summary data layer (DWS), and an application data layer (ADS). The model layer can be used to generate data processing results based on the integrated end-to-end data, which can be written by the aforementioned access layer. The application layer can be used to display the data processing results and / or the analysis results of the data processing results.

[0042] In some embodiments, the data source layer can be used to acquire end-to-end data from the associated systems and devices. For example, the data source layer can communicate with the associated systems and devices via various industry-standard protocols to collect relevant data. The construction module 820 can build the data source layer based on one or more tools such as Talend, DataStage, Kettle, Hive SQL, Flink, Spark Streaming, Kafka, Debezium, and DataX, thereby achieving comprehensive and efficient input of the end-to-end data.

[0043] The end-to-end data may include, but is not limited to, production business data, process and equipment data, and quality inspection data. Exemplary production business data may include work order information, work reporting records, material movement, inventory status, etc., and may originate from the aforementioned MES / ERP system. After generation, this production business data may be stored in relational databases such as Oracle, MySQL, Microsoft SQL Server, PostgreSQL, DB2, etc. The data source layer can obtain production business data in real time from the aforementioned relational databases (or, newly added incremental data such as newly created work orders, production work reports, etc.) through Change Data Capture technology (such as Flink CDC). Exemplary process and equipment data may include real-time process parameters such as temperature, pressure, and gas flow rate, equipment status logs such as operation, shutdown, and fault status, and alarm information. This process and equipment data may originate from the aforementioned SCADA system and various equipment controllers. Exemplary quality inspection data may include various electrical performance parameters of the produced photovoltaic cells, such as Isc, Voc, FF, Eta, etc., as well as images generated by EL / PL / AOI inspection equipment and automatically identified defect results, manual re-inspection records, and sampling inspection reports. The data source layer can obtain the data from the aforementioned SCADA system and various detection devices through industrial protocols such as ModBus TCP, and buffer the real-time process data through message queues.

[0044] In some embodiments, the access layer can be used to integrate the end-to-end data to adapt to the timeliness and processing cost requirements of different business scenarios, and write the processing results of the end-to-end data into the model layer. For example, the end-to-end data can be divided into first data transmitted to the access layer in real time based on a high-performance distributed message queue, and second data transmitted to the access layer intermittently based on a preset time period. That is, the access layer can implement a hybrid data processing mode of "real-time + offline". The "real-time" first data can be buffered via a high-performance distributed message queue such as Kafka to achieve peak smoothing and prevent the entire system from being overwhelmed by traffic. The "offline" second data can be acquired using the data synchronization tool DataX every preset time period (e.g., 5 minutes, 10 minutes, etc.), thereby achieving near real-time data synchronization with minimal overhead. After acquisition, the first and second data can undergo data integration including at least extraction, transformation, and ETL / ELT loading processes, and the integrated data will be written into the model layer. In some embodiments, the integrated end-to-end data can be subjected to aggregation calculations, and the resulting calculations will also be written into the model layer. In some embodiments, the data integration can be performed using a framework and distributed processing engine Flink or a scheduling system DolphinScheduler. The end-to-end data after the data integration and the calculation results can be written to the model layer through a high-performance distributed message queue, including Kafka, or an HTTP interface.

[0045] refer to Figure 4 The diagram illustrates exemplary data access and integration of the access layer according to some embodiments of this application. Figure 4As shown, process and equipment data, as well as quality inspection data, can be acquired and accessed in real time from multiple heterogeneous sources. Through data acquisition gateways deployed at the factory site, real-time data acquisition from production equipment and sensors is supported using various industry standard protocols (such as OPC UA, Modbus, MQTT, etc.). The gateway uniformly converts the acquired data into a standard format (such as JSON) and publishes it to a high-performance distributed message queue (such as Kafka). This decouples the data sources, provides powerful buffering and peak-shaving capabilities, and prevents the backend system from being overwhelmed by traffic. For incremental data (such as work order creation, production reporting, etc.) generated in business databases (such as MySQL) that store production business data, Change DataCapture technology (such as Flink CDC) can be used to directly read the database's binary log (binlog) and synchronize it to the Kafka message queue in real time. This allows changes to the business system to be seamlessly integrated into the real-time data stream. These data streams will then be parsed and standardized. Flink can consume raw data streams from Kafka, performing operations such as data parsing (e.g., extracting specific fields from JSON), data cleaning (filtering invalid and outlier values), format conversion (unifying units and encoding), and data enrichment (associating basic dimensional information). The cleaned data is written in real-time to the ODS layer of the model layer (e.g., to maintain the original granularity, such as work report details) and the DWD layer (e.g., to form standardized detailed fact tables and dimension tables, such as production unit input and output records), and finally entered into ClickHouse via the Kafka engine. Another set of Flink jobs consumes standardized data streams, performing window aggregation calculations (e.g., calculating the average temperature per device per minute, or the total production capacity of the production line per hour). The calculation results are directly written to DWS (e.g., for light aggregation, such as hourly production line output) or ADS (e.g., for application data, such as daily production data), and entered into ClickHouse via the Kafka engine. This aggregated data can ultimately be used in the application layer for direct, low-latency querying, analysis, display, alerting, and other applications, and API interfaces are provided for querying.

[0046] refer to Figure 5 Another exemplary schematic diagram illustrating data access and integration of the access layer according to some embodiments of this application is shown. For example... Figure 5As shown, for the aforementioned "offline" data, such as applications with less stringent latency requirements (e.g., minutes or more), such as daily process reports, historical quality traceability analysis, and long-term trend statistics, incremental data synchronization can be achieved based on scheduling tools. Using the data synchronization tool DataX, the task scheduling platform (DataX_Web) triggers tasks at fixed intervals (e.g., every 5 or 10 minutes). These tasks extract incremental data that has changed within the previous period from the business database based on incremental fields (e.g., auto-incrementing ID or update timestamp update_time) and write it to the ODS layer (ClickHouse table) of the model layer. This achieves near real-time data synchronization for the business with minimal overhead. Simultaneously, scheduling systems such as DolphinScheduler can assemble subsequent ClickHouse SQL ETL tasks into a dependent workflow DAG (Directed Acyclic Graph). The system automatically triggers the entire workflow according to a preset interval (e.g., every 10 minutes), ensuring that data is continuously updated from the business system to each layer of the data warehouse (DWD->DWS->ADS) in near real-time via the ClickHouse HTTP interface.

[0047] In some embodiments, the model layer includes an ODS layer that can receive and store cleaned end-to-end data, a DWD layer that can construct consistent dimensions and fact tables based on the integrated end-to-end data, a wide table model based on the calculation results, and an ADS layer that can form a table structure for data querying and display. The ODS layer is a source-attached layer, preserving the original appearance of the data as much as possible, performing only necessary cleaning (removing nulls and formatting) before data storage. Data is partitioned by time and uses columnar storage (ClickHouse) to improve compression ratio and query efficiency. The DWD layer can construct a series of consistent dimensions and fact tables based on dimensional modeling theory, such as shifts, workshops, spans, product families, production lines, sub-production lines, production units, and equipment, as well as various fact tables (such as production work order fact tables and IV inspection fact tables). Data at this layer undergoes standardization, field unification, code value conversion, dimension degradation, abnormal data cleaning, and fine-grained fact association. The DWS layer can organize data by subject area (such as production, quality, and equipment), construct a wide table model, and pre-aggregate indicators of commonly used dimension combinations. For example, building hourly summary tables at the production line-product-shift granularity, with pre-calculated hourly output, yield, and average efficiency, greatly improves the response speed of frequently used queries. The ADS layer can provide highly aggregated datasets for specific application scenarios, with table structures optimized for specific query performance and business presentation. Examples include daily production capacity achievement rate reports, shift-by-shift silver paste consumption trend tables, and real-time equipment OEE dashboard results tables. This layer's data can be directly queried by applications, thus providing the best user experience.

[0048] In some embodiments, the layer data stored in two or more of the aforementioned ODS, DWD, DWS, and ADS layers can be invoked for data analysis to obtain the data processing results. This layer data can be used to construct models such as capacity analysis, work-in-process analysis, warehousing analysis, incoming material analysis, energy consumption analysis, screen printing analysis, slurry analysis, yield analysis, quality analysis, and equipment analysis, to determine the results of capacity analysis, work-in-process analysis, warehousing analysis, incoming material analysis, energy consumption analysis, screen printing analysis, slurry analysis, yield analysis, quality analysis, and equipment analysis.

[0049] For example, for capacity analysis, the corresponding capacity analysis model can comprehensively evaluate the resource utilization efficiency, output quality, and capacity status of the production process through a comprehensive analysis of four dimensions: input, output, rework, and fragmentation. Input analysis focuses on the effectiveness of raw material use, aiming to optimize resource allocation, control costs, and predict demand; output analysis measures production efficiency and product quality, providing a basis for capacity planning and quality control. Rework analysis identifies process defects, promotes quality improvement, and reduces additional costs by quantifying the quantity and rate of rework; fragmentation analysis focuses on waste and defective products in the production process, achieving cost savings and environmental goals by reducing waste, while also promoting process optimization. Related indicators cover the input quantity, capacity completion rate, rework rate (including detailed breakdown of defect causes), and fragmentation rate (including fragmentation rate after opening boxes, etc.) at the process and machine levels, forming a multi-level monitoring system to jointly support refined capacity management and continuous improvement.

[0050] For work-in-process analysis, work-in-process management in photovoltaic cell production involves three statuses: in-process work-in-process, finished goods work-in-process, and rework work-in-process. The aim is to comprehensively monitor the production process, optimize resource allocation, and improve overall efficiency. In-process work-in-process refers to products that are in the process of production but not fully completed, used to track production progress, control costs, identify quality issues, and predict resource needs. Finished goods work-in-process refers to products that have completed major production steps but have not yet undergone final inspection or packaging; its management helps optimize production planning and scheduling, inventory control, cost accounting, quality improvement, and resource allocation. Rework work-in-process refers to products that do not meet quality standards and require reprocessing, used to ensure quality, reduce waste, and improve production efficiency. Relevant monitoring indicators include factory production work-in-process, machine work-in-process, inter-process work-in-process, finished goods work-in-process analysis, and rework work-in-process. Systematic analysis of these indicators enables refined management of the production process, ensuring an effective balance between capacity, quality, and cost.

[0051] For inventory inbound analysis, the corresponding inventory inbound analysis model is a core component of production and supply chain management. It refers to the quantity and corresponding indicators of photovoltaic cells that have been produced and entered into inventory. This model is primarily used to assess production efficiency, manage inventory levels, and support sales decisions. It optimizes production processes by monitoring actual output, rationally plans inventory to avoid capital tied up or supply disruptions, and flexibly adjusts sales strategies based on inventory levels to meet market demand. Key related indicators include inbound quantity, inbound power, A-grade inbound quantity, A-grade inbound rate, and average efficiency of A-grade inbound inventory. These data collectively provide quantitative basis for production planning, inventory control, and market response, ensuring operational efficiency and market supply and demand balance.

[0052] For incoming material analysis, in photovoltaic cell production, incoming material analysis (incoming material inspection or incoming material quality control) is a crucial step in ensuring stable production and the quality of the final product. This step, through strict quality control of silicon wafers (checking purity, thickness, flatness, and surface defects, etc.) and auxiliary materials (such as silver paste, aluminum paste, backsheets, EVA film, etc.), ensures the electrical performance and long-term reliability of the cells and provides inventory data support for sales strategy adjustments. Key related indicators include: incoming material quantity, qualified incoming material quantity, incoming material qualification rate, and identifying major quality issues through top-percentage analysis of incoming material defects, continuously optimizing supply chain and product quality management.

[0053] For energy consumption analysis, the corresponding photovoltaic cell energy consumption analysis model comprehensively evaluates multiple resource consumption indicators in the production process, covering four core categories: water, electricity, gas, and chemicals. The model not only focuses on the total consumption of various resources (including water, electricity, gas, and chemicals), but also further refines it to the unit production intensity, introducing the concept of "single-cell consumption" (i.e., water consumption, electricity consumption, gas consumption, and chemical consumption per cell). Through this dual perspective of "overall + individual," the model can comprehensively quantify the resource utilization efficiency and environmental impact of photovoltaic cell manufacturing, providing accurate data support and decision-making basis for production process optimization, cost control, and sustainability assessment.

[0054] For grid screen analysis, the core of the photovoltaic cell grid screen analysis model is to achieve comprehensive control over production quality and cost through correlation analysis of four key indicators: average grid screen lifespan, number of scrapped grid screens, number of compliant grid screens, and grid screen lifespan compliance rate. Average grid screen lifespan reflects the average usage time of the grid screen and is the core metric for its durability and economic efficiency. The number of scrapped grid screens is directly related to production losses and material costs and must be minimized. The number of compliant grid screens reflects the scale of products meeting the preset lifespan standards and is a direct reflection of output quality. Finally, the grid screen lifespan compliance rate, as a comprehensive indicator, is the ratio of the number of compliant grid screens to the total number of grid screens put into production, comprehensively reflecting the stability of the production process and the consistency of grid screen quality. By integrating these indicators, the model aims to optimize grid screen utilization efficiency, reduce scrap rates, and improve compliance rates, thereby ensuring the sustainability and economic benefits of photovoltaic cell production.

[0055] For paste analysis, the paste analysis model integrates four core indicators: paste consumption weight, paste consumption per cell, paste wet weight per cell, and paste loss rate. It aims to comprehensively evaluate the efficiency and cost of paste usage during photovoltaic cell production. Paste consumption weight measures the total amount used throughout the production process and is a primary target for cost control. Paste consumption per cell is standardized as the average consumption per cell, providing a benchmark for comparison between different production lines or processes. Paste wet weight per cell specifically refers to the weight of paste in a single cell area after printing but before baking and curing, directly related to the stability and consistency of the printing process. The paste loss rate quantifies the unavoidable losses during production (such as at the printing line end, equipment cleaning, and waste products), serving as a key basis for optimizing processes and reducing waste. By comprehensively analyzing these indicators, bottlenecks in paste usage can be accurately identified, printing parameters and equipment settings optimized, ultimately achieving the goal of reducing unit production costs and improving product efficiency.

[0056] For yield analysis, photovoltaic cell production yield is a core indicator for measuring the proportion of qualified products. Its calculation formula is: Yield = Quantity of Grade A Products / Total Production Quantity. Here, the quantity of Grade A products refers to the number of fully qualified cells, serving as the numerator in the yield calculation. The total production quantity is obtained by adding the quantity of Grade A products, the number of reported scraps (physical waste generated during production), and the number of defective cells reported as defective (confirmed defective products after inspection), i.e., Total Production Quantity = Quantity of Grade A Products + Quantity of Reported Scraps + Quantity of Reported Defective Cells. This indicator can be further refined through "offline yield," where the quantity of Grade A products is obtained by deducting defective products of various grades (such as A1, B1, B2, C1, C2, etc.) and packaging scraps from the printing output. The total production quantity then equals the sum of the printing output and the number of scraps. Yield analysis also relates to several sub-indicators: the overall yield reflects the overall production quality level; the first-pass yield reflects the initial sorting efficiency; and the quantity and proportion of defects in EL and appearance secondary re-inspections are used to track defects in the re-inspection process, thereby comprehensively evaluating the efficiency of the production process and the stability of product quality. A high yield rate indicates good production process control and high resource utilization.

[0057] For quality analysis, the photovoltaic cell quality analysis model integrates multi-dimensional data such as electrical performance (IV), automated optical inspection (AOI), electroluminescence (EL), and photoluminescence (PL) to construct a comprehensive production monitoring and evaluation system. Core electrical performance indicators (such as conversion efficiency Eta, open-circuit voltage Uoc, short-circuit current Isc, fill factor FF, series resistance Rs, parallel resistance Rsh, reverse current Irev2, and cell temperature Tcell) are monitored in real time to accurately evaluate the performance of each cell. By analyzing indicators such as efficiency level ratio, open-circuit voltage distribution, leakage rate, and low efficiency, the number of leaky and inefficient cells can be quickly identified, and the electrical performance yield and efficiency A-grade yield can be calculated, thereby effectively evaluating the overall effective output and quality status of the production line. The AOI system runs through the entire process chain (texturing, boron expansion, BSG removal, LPCVD, phosphorus expansion, PSG removal, ALD, front / back film deposition, screen printing, and testing and sorting), accurately monitoring the pass rate and defect rate of each stage (such as front / back film and screen printing AOI). It provides detailed statistics on defects, tracks trends, and correlates with cell color analysis (such as color percentage and dark color value) to control product appearance consistency and prevent process drift. EL inspection effectively identifies internal microcracks, broken grids, and other defects through first-pass yield, defect rate, and grayscale value analysis; PL testing further supplements the assessment of material quality and minority carrier lifetime. The EL grayscale range distribution and PL results together provide a deep insight into the internal quality of the battery. This quality analysis model, by correlating key indicators such as IV performance, AOI first-pass yield, and EL / PL yield, achieves comprehensive closed-loop quality management from appearance to internal performance, and from macroscopic efficiency to microscopic defects, providing data-driven and efficient decision support for process optimization and quality improvement.

[0058] For equipment analysis, the equipment analysis model comprehensively considers key indicators such as Overall Equipment Effectiveness (OEE), uptime, runtime, main unit cycle time (CT), automation CT, downtime, number of failures, mean time between failures (MTBF), mean time to repair (MTTR), as well as environmental indicators (temperature, humidity, cleanliness) and the number of times equipment jams occur. This aims to comprehensively evaluate equipment performance and production efficiency. OEE, as a core indicator, measures the ratio of actual to theoretical capacity and is determined by uptime, performance efficiency, and yield. Uptime reflects equipment time utilization and is closely related to runtime, downtime, and the number of failures. MTBF and MTTR are used to assess equipment reliability and maintenance efficiency; longer MTBF and shorter MTTR indicate stable and easily repairable equipment. Main unit CT and automation CT directly relate to production cycle time and automation level, affecting overall output capacity. Environmental factors (temperature, humidity, cleanliness) are key control parameters in photovoltaic cell production, directly affecting product yield and equipment operating status. The number of times equipment jams occurs, as an indicator of a specific failure type, further refines equipment operation issues. By integrating these indicators, the model enables real-time monitoring of equipment efficiency, fault warning, maintenance optimization, and environmental management, ultimately improving production efficiency and product quality.

[0059] In this application, the model layer is built on ClickHouse as the core storage component. On one hand, data can be accessed in real time via the Kafka table engine, building a real-time data ingestion channel through the Kafka table engine provided by ClickHouse. The Kafka engine table can directly subscribe to specified Kafka topics, enabling real-time consumption and extraction of streaming data. After data enters ClickHouse, it is automatically converted into an internal table structure, completing the initial write operation. This mechanism effectively reduces the latency of data ingestion, ensuring the continuity and integrity of the data stream, laying the foundation for subsequent data storage and processing. On the other hand, in terms of data storage, ClickHouse's MergeTree series engine is used as the core storage mechanism. This engine is particularly suitable for storing time-series data, supporting key functions such as time-based partitioning, data block merging, and background compression. By reasonably setting the sort key and partition key, the system achieves efficient organization and physical sorting during data writing, significantly improving the performance of range queries and filtering queries. Furthermore, utilizing the characteristics of columnar storage, the system only reads the columns involved in the query, reducing I / O overhead, making it particularly suitable for high-concurrency aggregation query scenarios.

[0060] Furthermore, to further optimize aggregation query performance, this solution also introduces materialized view functionality. Materialized views can predefine and calculate commonly used aggregation metrics (such as summation, mean, quantiles, etc.) and automatically update the results when data is written. During queries, aggregation values ​​can be quickly retrieved directly from the materialized view, avoiding a full table scan of the original detailed data, greatly reducing query response time, and meeting the urgent need for low-latency queries in real-time monitoring and analysis operations.

[0061] Furthermore, to address the issue of differing indicator definitions, this application introduces a dynamic configuration mechanism. Specifically, by introducing a configuration table that governs the changeable calculation rules for the aforementioned data analysis, the calculation rules for various indicators are centrally managed through this table. This enhances adaptability to different business needs, reduces code redundancy and maintenance costs caused by rule differences, and strengthens the flexibility and consistency of data processing. For example, the calculation rules for various indicators can be centrally managed through the configuration table. During ETL (Extract, Transform, Load) processing or application queries, the calculation parameters (such as thresholds) corresponding to the current context (such as product type) can be dynamically obtained by associating with this configuration table, enabling flexible and unified calculation of indicators.

[0062] In some embodiments, the application layer can provide diverse data services and analytical capabilities based on the underlying data. The application layer can provide unified data services, offering data externally through standardized APIs (such as RESTful), shielding the complexity of the underlying data, and integrating access control and auditing. That is, the data warehouse (e.g., the application layer) can be encapsulated as a data service interface using SQL scripts. The data service structure can be configured to receive indicator filtering instructions and output target indicators determined from the layer data based on these instructions. The unified data service can highly abstract the underlying data tables through SQL and script processing, encapsulating them into standardized data interfaces to achieve unified data access and efficient reuse. The application layer can automatically parse variables and user-defined functions in the SQL script, identifying and extracting the interface's input parameters. For example, the system will identify three input parameters: param1, param2, and param3. When the interface is called, the final SQL statement is dynamically concatenated and generated based on the input parameter values, enabling flexible condition combinations and query control. Furthermore, the return fields defined in the SELECT statement are automatically mapped to the interface's output parameters through syntax parsing. For example, if the output parameters include column1, column2, and column3, the interface response will be encapsulated and returned according to this structure, ensuring consistency and clarity of the output. Centralized processing is also possible, supporting the embedding of custom functions to enhance logical expressiveness and flexibly extending business functionality without modifying the underlying implementation. This mechanism effectively shields the underlying data storage and SQL details, promoting decoupling between business logic and data access, and significantly improving system maintainability and interface reusability. For instance, a special custom function can be defined where, when the input parameter is not empty, the text within the function is appended to the SQL statement.

[0063] The application layer also provides a unified indicator service: offering indicator registration, definition, calculation, and query services. It supports dynamic configuration and management of indicator logic. The unified indicator service can annotate the structured semantics of data service query results, enabling unified encapsulation and efficient aggregation of multiple indicators, significantly improving the manageability and reusability of complex business indicators.

[0064] Based on the unified metrics service, this application can integrate metrics anomaly detection algorithms to achieve multi-dimensional and configurable anomaly monitoring and alerting for service metrics, significantly improving the accuracy, real-time performance, and coverage of metrics monitoring. In this application, the application layer can analyze the metrics and perform attribution to determine the anomaly metrics in the data processing results obtained by the aforementioned model layer, and display the anomaly metrics, such as issuing alerts. The above metrics anomaly detection algorithm can have a threshold alerting mechanism based on statistics, supporting two strategies: static threshold detection and dynamic threshold detection. For example, static threshold detection can set fixed alert upper and lower limits for metrics, and once the metric value exceeds this range, an alert is triggered. Dynamic threshold detection can dynamically calculate a reasonable fluctuation range based on the historical data of the metrics, adapting to scenarios where data changes over time or business cycles. For example, based on the number of fragments in the same period of the past 30 days, calculate its mean and standard deviation dynamically. If the number of fragments at the current moment deviates from the mean by more than 3 standard deviations, it is determined as an anomaly. The above metrics anomaly detection algorithm can also have a volatility detection mechanism based on time series, detecting its abnormal fluctuation behavior through automatic identification and modeling of the patterns of the metrics time series. One way is to perform month-over-month (MoM) detection: calculate the change rate of the metrics between the current period and the previous period (such as yesterday, the same time last week), and alert for situations that exceed the expected fluctuation range. For example, if the production output of a process today has decreased by 50% compared to yesterday, and the system sets the fluctuation threshold to ±30%, an anomaly alert is triggered. Another way is to perform year-over-year (YoY) detection: compare the data of the current period with the same period in history (such as the same month, the same week last year), and identify abnormal deviations that cannot be explained by seasonal, cyclical, and trend changes. For example, if the production output of a process this week has decreased by 40% compared to the same week last year, and the normal fluctuation range is [-10%, 20%], it is determined as an abnormal situation.

[0065] In some embodiments, when an anomaly metric is determined, this application can also perform attribution analysis on the anomaly metric to determine the anomaly factors that cause the anomaly metric, facilitating quick problem location. Exemplarily, referring to Figure 6 the exemplary schematic diagram of anomaly metric analysis according to some embodiments of this application shown in Figure 6 as shown, when production capacity anomaly is detected, dimension drilling can be performed, going down to multiple dimensions such as product, region, process, etc., to identify the specific links that cause the anomaly. Moreover, correlation analysis can also be performed, linking other metrics associated with the anomaly metric, performing cross-comparison and impact analysis, and identifying whether there are collaborative anomalies or hidden correlation factors. Referring to Figure 7 the another exemplary schematic diagram of anomaly metric analysis according to some embodiments of this application shown in Figure 7As shown, when the yield fluctuates abnormally, related indicators such as EL defects and appearance defects are analyzed simultaneously to determine whether multiple factors are at play.

[0066] Step 330: The data warehouse is constructed using the data source layer, the access layer, the model layer, and the application layer. This step can be executed by the component module 830.

[0067] In some embodiments, after the data source layer, the access layer, the model layer, and the application layer are constructed, the component module 830 can integrate the data communication and physical connection between the above layers to combine them into the data warehouse.

[0068] The data warehouse modeling method provided in this application has the following advantages: 1> Deep Industry Integration: For the first time, a layered data warehouse model optimized for photovoltaic cell production and operation scenarios is proposed and constructed. It closely integrates with the industry characteristics of multi-source heterogeneity, high frequency, real-time operation, and constantly changing indicators, solving the problem of general solutions being incompatible with local conditions. 2> Innovative Hybrid Architecture: An innovative access layer architecture seamlessly integrates real-time stream processing and offline batch processing, cleverly balancing the requirements of different business scenarios for data timeliness and processing costs, achieving end-to-end data support from real-time monitoring to historical traceability. 3> Dynamic Model Construction: A dynamic configuration-based indicator management method is proposed. Through a rule configuration table, the volatile business logic is decoupled from fixed ETL code, greatly enhancing the model's flexibility and adaptability, and effectively responding to frequent changes in the photovoltaic industry's needs. 4. **Technology Combination Optimization:** Creatively combining and deeply optimizing modern big data technology stacks (such as Flink, Kafka, ClickHouse, and DolphinScheduler) for application in the photovoltaic manufacturing field. Particularly noteworthy is the successful practice and innovation in utilizing ClickHouse features (Kafka engine, materialized views) to process industrial time-series data. 5. **Service-Oriented and Intelligent Applications:** Exposing data warehouse capabilities through unified services and APIs lowers the barrier to entry. Integrating anomaly detection and analysis methods upgrades the data warehouse from a traditional "data storage and reporting center" to a "data service and intelligent decision-making center," directly empowering business value-added services.

[0069] It should be noted that the above-mentioned Figure 3 The descriptions of the various steps in this application are merely for illustrative purposes and do not limit the scope of this application. Those skilled in the art can learn from the guidance of this application. Figure 3 Various modifications and changes have been made to the various steps in the process. However, these modifications and changes are still within the scope of this application.

[0070] This application also provides a processing system for implementing the aforementioned data warehouse method for photovoltaic cell production and operation. (Reference) Figure 8 The diagram shown is an exemplary block diagram of a processing system implementing the data warehouse method for photovoltaic cell production and operation according to some embodiments of this application, such as... Figure 8 As shown, the processing system 800 may include a determining module 810, a building module 820, and a composition module 830.

[0071] The determination module 810 can be configured to identify the associated systems and equipment related to the entire process of photovoltaic cell production and operation. The determination module 810 can identify the associated systems and equipment based on the specific production and testing process of photovoltaic cells, including but not limited to Manufacturing Execution System (MES) / Enterprise Resource Planning System (ERP), Supervisory Control and Data Acquisition (SCADA) System / Equipment Controller (such as PLC), product quality testing equipment, etc.

[0072] The construction module 820 can be configured to construct, for the associated system and device, a data source layer for obtaining end-to-end data from the associated system and device, an access layer for integrating the end-to-end data, a model layer with a layered design for storing the integrated end-to-end data, a model layer with a layered design for generating data processing results based on the integrated end-to-end data, and an application layer for displaying the data processing results and / or the analysis results of the data processing results.

[0073] The component module 830 can be configured to form the data warehouse using the data source layer, the access layer, the model layer, and the application layer.

[0074] Further descriptions of the aforementioned components can be found in this application. Figures 3-7 part.

[0075] It should be understood that Figure 8The systems and modules shown can be implemented in various ways. For example, in some embodiments, the systems and modules can be implemented by hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the methods and systems described above can be implemented using computer-executable instructions and / or included in processor control code, for example, on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The systems and modules of this application can be implemented not only by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., but also by software executed by various types of processors, or by a combination of the aforementioned hardware circuits and software (e.g., firmware).

[0076] It should be noted that the above description of the modules is for ease of description only and should not be construed as limiting this application to the scope of the embodiments described. It is understood that those skilled in the art, after understanding the principle of the system, may arbitrarily combine the modules or construct subsystems connected to other modules without departing from this principle. For example, the modules may share a single storage module, or each module may have its own separate storage module. Such modifications are all within the scope of protection of this application.

[0077] This application has described the basic concepts. Obviously, for those skilled in the art, the above detailed disclosure is merely illustrative and does not constitute a limitation of this application. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this application. Such modifications, improvements, and corrections are suggested in this application, and therefore such modifications, improvements, and corrections still fall within the spirit and scope of the exemplary embodiments of this application.

[0078] Furthermore, this application uses specific terms to describe its embodiments. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of this application. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this application do not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics in one or more embodiments of this application can be appropriately combined.

[0079] Furthermore, those skilled in the art will understand that aspects of this application can be described and illustrated through several patentable types or situations, including any new and useful combination of processes, machines, products, or substances, or any new and useful improvements thereof. Accordingly, aspects of this application can be implemented entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. All of the above hardware or software may be referred to as a “data block,” “module,” “engine,” “unit,” “component,” or “system.” Furthermore, aspects of this application may manifest as a computer product located on one or more computer-readable media, the product including computer-readable program code.

[0080] Computer storage media may contain a propagated data signal containing computer program code, for example, on baseband or as part of a carrier wave. This propagated signal may take various forms, including electromagnetic, optical, or suitable combinations thereof. Computer storage media can be any computer-readable medium other than a computer-readable storage medium, which can be used to communicate, propagate, or transmit a program for use by being connected to an instruction control system, apparatus, or device. The program code located on the computer storage medium can be propagated through any suitable medium, including radio, cable, fiber optic cable, RF, or similar media, or any combination of the above media.

[0081] The computer program code required for the operation of each part of this application can be written in any one or more programming languages, including object-oriented programming languages ​​such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET, Python, etc., conventional procedural programming languages ​​such as C, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, dynamic programming languages ​​such as Python, Ruby, and Groovy, or other programming languages. This program code can run entirely on the user's computer, or as a standalone software package on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any network, such as a local area network (LAN) or wide area network (WAN), or connected to an external computer (e.g., via the Internet), or in a cloud computing environment, or used as a service such as Software as a Service (SaaS).

[0082] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this application are not intended to limit the order of the processes and methods of this application. Although the foregoing disclosure has discussed some currently considered useful embodiments of the invention through various examples, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the substance and scope of the embodiments of this application. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely through software solutions, such as installing the described system on existing servers or mobile devices.

[0083] Similarly, it should be noted that, in order to simplify the description of the present application and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of the embodiments of the present application sometimes combines multiple features into a single embodiment, drawing, or description thereof. However, this disclosure method does not imply that the subject matter of the application requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of the single embodiments disclosed above.

[0084] Finally, it should be understood that the embodiments described in this application are merely illustrative of the principles of the embodiments of this application. Other modifications may also fall within the scope of this application. Therefore, alternative configurations of the embodiments of this application are considered as examples and not limitations, and are regarded as consistent with the teachings of this application. Accordingly, the embodiments of this application are not limited to the embodiments explicitly described and illustrated in this application.

Claims

1. A data warehouse modeling method for photovoltaic cell production and operation, characterized in that, The method includes: Identify the related systems and equipment involved in the entire process of photovoltaic cell production and operation; For the associated systems and devices, a data source layer is constructed for obtaining end-to-end data from the associated systems and devices, an access layer is constructed for integrating the end-to-end data, an access layer is constructed for storing the integrated end-to-end data, a layered model layer is constructed for generating data processing results based on the integrated end-to-end data, and an application layer is constructed for displaying the data processing results and / or the analysis results of the data processing results. The data warehouse is composed of the data source layer, the access layer, the model layer, and the application layer.

2. The data warehouse modeling method according to claim 1, characterized in that, The end-to-end data includes at least production business data, process and equipment data, and quality inspection data; The data source layer communicates with the associated systems and devices to obtain the end-to-end data.

3. The data warehouse modeling method according to claim 1, characterized in that, The end-to-end data includes first data transmitted to the access layer in real time based on a high-performance distributed message queue, and second data transmitted to the access layer intermittently based on a preset time period.

4. The data warehouse modeling method according to claim 3, characterized in that, The high-performance distributed message queue includes Kafka; the second data is acquired based on the data synchronization tool DataX at preset time intervals.

5. The data warehouse modeling method according to claim 1, characterized in that, The data integration includes at least extraction, transformation, and loading ELT processing, and the end-to-end data is written into the model layer after the data integration.

6. The data warehouse modeling method according to claim 5, characterized in that, The calculation results obtained by performing aggregation calculations on the end-to-end data after data integration are written into the model layer.

7. The data warehouse modeling method according to claim 6, characterized in that, The data is integrated using a framework and distributed processing engine Flink or a scheduling system DolphinScheduler. The integrated end-to-end data and the calculation results are written to the model layer via a high-performance distributed message queue, including Kafka, or an HTTP interface.

8. The data warehouse modeling method according to claim 1, characterized in that, The model layer, designed with a hierarchical structure, is built on ClickHouse and includes a data storage layer (ODS), a detailed data layer (DWD), a summary data layer (DWS), and an application data layer (ADS). The ODS layer receives and stores cleaned end-to-end data. The DWD layer constructs consistent dimensions and fact tables based on the integrated end-to-end data. The DWS layer constructs a wide table model based on the calculation results. The ADS layer forms a table structure for data querying and display.

9. The data warehouse modeling method according to claim 8, characterized in that, The output of the data processing result includes: Data is analyzed by calling the data stored in two or more of the ODS layer, the DWD layer, the DWS layer, and the ADS layer to obtain the data processing result. The data processing results include at least the following: capacity analysis results, work-in-process analysis results, warehousing analysis results, incoming material analysis results, energy consumption analysis results, screen printing plate analysis results, slurry analysis results, yield analysis results, quality analysis results, and equipment analysis results.

10. The data warehouse modeling method according to claim 9, characterized in that, The method further includes: Obtain a configuration table, which includes changeable calculation rules that constrain the data analysis; The layer data is analyzed based on the configuration table to obtain the data processing results.

11. The data warehouse modeling method according to claim 9, characterized in that, The data warehouse is encapsulated as a data service interface using SQL scripts; the data service structure is configured to receive indicator filtering instructions and output target indicators determined from the layer data based on the indicator filtering instructions.

12. The data warehouse modeling method according to claim 9, characterized in that, The analysis results that display the data processing results include: Identify any abnormal indicators contained in the data processing results; Correlation analysis is performed based on the aforementioned abnormal indicators to identify the abnormal factors that cause them. Display the abnormal indicators and / or the abnormal factors; the display shall include at least alarms.

13. A data warehouse modeling device for photovoltaic cell production and operation, characterized in that, The modeling device includes: The module is configured to identify the associated systems and equipment related to the entire process of photovoltaic cell production and operation. The building module is configured to build, for the associated system and device, a data source layer for obtaining end-to-end data from the associated system and device, an access layer for integrating the end-to-end data, an access layer for storing the integrated end-to-end data, a layered model layer for generating data processing results based on the integrated end-to-end data, and an application layer for displaying the data processing results and / or the analysis results of the data processing results. The component modules are configured to form the data warehouse using the data source layer, the access layer, the model layer, and the application layer.

14. A data warehouse for photovoltaic cell production and operation, characterized in that, The data warehouse is obtained based on the data warehouse modeling method as described in any one of claims 1-12.

15. A data warehouse modeling system for photovoltaic cell production and operation, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the data warehouse modeling method as described in any one of claims 1-14.

16. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the data warehouse modeling method as described in any one of claims 1-14.

17. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the steps of the data warehouse modeling method as described in any one of claims 1-14.

Images