Supply chain management system for research and development of electronic materials

Abstract

The invention discloses a supply chain management system for research and development of electronic materials, and belongs to the technical field of supply chain management systems. Internet-of-things equipment data is acquired through sensors deployed in a raw material production link, a warehouse storage area and a transport vehicle, external interface data is from a supplier system, enterprise internal system data comprises PLM, ERP and MES system data, and the data processing layer performs real-time cleaning, conversion and stream batch fusion processing on the acquired data based on a stream calculation engine and performs data processing on the acquired data. The data storage layer adopts a hybrid storage architecture and comprises a Kafka cluster used for storing real-time data, an InfluxDB used for storing time sequence data, an HBase used for storing unstructured data and a MySQL cluster used for storing dimension data.

Description

Technical Field

[0001] The present invention relates to a supply chain management system, in particular to a supply chain management system for electronic material research and development, and belongs to the technical field of supply chain management systems. Background Art

[0002] Electronic materials R&D involves a complex supply chain system, encompassing heterogeneous systems such as multi-tiered supplier production systems, internal product lifecycle management (PLM), enterprise resource planning (ERP), and manufacturing execution systems (MES). Supply chain management faces multiple challenges, including data integration, real-time monitoring, intelligent decision-making, collaborative efficiency, and safety and compliance. These challenges are as follows: System data heterogeneity and sharing barriers; The electronic materials supply chain involves numerous participants. Suppliers often use proprietary communication standards like custom TCP protocols, while internal enterprise systems primarily rely on RESTful APIs. This leads to inconsistent data standards and heterogeneous interface protocols. For example, raw material inventory data is recorded in tons in supplier systems but in kilograms in enterprise ERP. Production progress information is structured in PLM tables but unstructured logs in supplier systems. These discrepancies make it difficult to share key data such as raw material inventory, production progress, and R&D needs in real time, creating data silos and hindering supply chain collaboration efficiency.

[0003] Electronic materials are highly sensitive to storage environments (temperature, humidity, and light) and transportation conditions (vibration and shock). Their quality and performance directly depend on the stability of the entire supply chain. However, existing systems often rely on manual data entry or periodic data collection (such as hourly recording of warehouse temperature and humidity), failing to track the dynamic changes of raw materials throughout production, storage, and transportation. When risks arise, such as reactor temperatures exceeding standards, abnormal vibrations in transport vehicles, or delivery delays due to extreme weather, the system struggles to provide timely warnings. Companies often react passively to issues after they occur, leading to interruptions in R&D testing, scrapped materials, and project delays.

[0004] The demand for electronic material R&D changes dynamically with the adjustment of technological routes, but the existing system lacks accurate predictions of market demand and supply capacity. When a core raw material (such as photoresist) is in short supply, the system cannot automatically analyze the performance matching, cost impact and supplier capabilities of alternative materials, and must rely on manual investigation by purchasing personnel. The decision-making efficiency is low and prone to errors. In the face of scenarios such as a sudden increase in order volume, it is also difficult to quickly assess the impact on production scheduling and R&D plans, resulting in delayed resource allocation and inability to adapt to the R&D rhythm. Summary of the Invention

[0005] The main purpose of the present invention is to provide a supply chain management system for electronic material research and development.

[0006] The purpose of the present invention can be achieved by adopting the following technical solutions: A supply chain management system for electronic materials R&D, with a data collection layer that integrates IoT device data, external interface data, and internal enterprise system data. IoT device data is collected through sensors deployed in raw material production processes, warehouse storage areas, and transportation vehicles. External interface data comes from supplier systems. Internal enterprise system data includes data from PLM, ERP, and MES systems. The data processing layer performs real-time cleaning, conversion, and stream-batch fusion processing on the collected data based on the stream computing engine to generate standardized data and derived indicators; The data storage layer adopts a hybrid storage architecture, including a Kafka cluster for storing real-time data, InfluxDB for storing time series data, HBase for storing unstructured data, and a MySQL cluster for storing dimensional data; The algorithm analysis layer deploys a machine learning model library, including market demand forecasting models, raw material supply delay risk prediction models, and R&D material matching recommendation models, to extract trend and risk information from data; The application service layer includes report generation services, warning push services, and data query services, which are used to provide customized analysis reports and decision support for different user roles; The visual monitoring layer displays the status of each link in the supply chain in real time through web and mobile dashboards, and highlights abnormal information based on color coding and dynamic reminders.

[0007] Preferably, the data acquisition layer includes an Internet of Things device access module, which receives data from vibration sensors, temperature sensors, pressure sensors, flow sensors, RFID readers, GPS positioning modules and temperature and humidity sensors through the MQTT protocol. The sensors are respectively deployed in electronic material production equipment, warehouse shelves, transport vehicles and carriages; The external interface adapter module connects to the supplier system through RESTful API or EDIFACT messages to obtain production plans, inventory information and delivery status data. The interface adapter module supports protocol conversion and incremental data synchronization; The internal system integration module captures change data from PLM, ERP, and MES systems through CDC tools and synchronizes them to the data processing layer.

[0008] Preferably, the data processing layer includes a real-time cleaning module for filtering outliers and completing missing fields, wherein the outliers include sensor data that exceeds a preset range; A data conversion module, used to unify data formats and calculate derivative indicators, including inventory health and transportation risk index; The stream-batch fusion module uses FlinkSQL to simultaneously process real-time stream data and offline batch data, and calculates trend features based on historical data.

[0009] Preferably, the algorithm analysis layer includes a market demand forecasting model, a deep learning model based on the LSTM+attention mechanism, which inputs the historical order data of the past 90 days, the order increment of the current day and the market dynamic data, and outputs the daily demand forecast value for the next 7 days; The raw material supply delay risk prediction model, based on the gradient boosting tree algorithm, inputs supplier production data, transportation data, and weather conditions, and outputs delay probability and confidence level; The R&D material matching recommendation model is based on the similarity matching model of the knowledge graph. It outputs the top 5 matching alternative materials according to the material specifications and performance parameters in the R&D BOM.

[0010] Preferably, the application service layer further includes an intelligent decision-making module, which includes an alternative material analysis unit for screening candidate alternative materials and evaluating them from the perspectives of supplier capabilities, costs, and performance impact when raw materials are in short supply, and generating procurement strategy recommendations; The demand mutation response unit is used to evaluate the impact of sudden market demand changes on R&D plans and production schedules, and provide solutions for adjusting R&D project priorities and optimizing production schedules. The automated rules engine automatically triggers business process adjustments based on preset rules, including emergency purchases, production plan adjustments, and inventory transfers.

[0011] Preferably, the automated rule engine supports user-defined rules, wherein the rules include trigger conditions, execution actions and priorities, and the execution actions include pushing expedited orders to the supplier system, adjusting the MES production schedule and pushing early warning information to relevant roles.

[0012] Preferably, the visual monitoring layer includes a raw material supply dashboard, which uses a dashboard and a heat map to display the supplier's inventory ratio and material inventory status. When the inventory is below the safety threshold, the corresponding area flashes red to remind; The market demand dashboard uses bar charts and trend lines to display changes in order quantity and year-on-year growth rates. When the order volume suddenly increases by more than 50%, it is highlighted with dynamic animation. The production progress dashboard uses Gantt charts and 3D digital twin models to display the progress of R&D projects and the status of production equipment. When equipment fails, the corresponding position on the model flashes red and automatically jumps to the details page.

[0013] Preferably, it also includes a supply chain collaboration module, which includes a real-time communication platform, realizes instant messaging and file transfer between supply chain members based on the WebSocket protocol, and supports one-to-one chat and group conversation; The emergency response process management unit stores standardized emergency process documents, clarifies the response time limits and responsibilities of each member in different scenarios, and automatically creates a collaboration group and pushes process documents when an emergency event is detected; The joint exercise unit is used to simulate market demand and supply change scenarios, record response time and collaboration efficiency, and generate evaluation reports to optimize the collaboration mechanism.

[0014] Preferably, it further includes a security assurance module, which includes a data transmission encryption unit, uses the TLS1.3 protocol to encrypt the data link, and implements interface access control through OAuth2.0; A storage encryption unit that uses the AES-256 algorithm to encrypt and store sensitive fields, including supplier cost data; The operation audit unit records the user's key operation logs, including the operator, time and details. The log retention period is no less than 2 years.

[0015] Preferably, Kubernetes containerized deployment is adopted, which supports automatic expansion and contraction and multi-availability zone deployment. The data storage layer realizes cross-zone synchronization, ensuring RPO ≤ 5 minutes and RTO ≤ 30 minutes.

[0016] Beneficial technical effects of the present invention: The present invention provides a supply chain management system for electronic material research and development. Electronic material research and development involves multiple systems such as supplier production systems, enterprise internal PLM (product lifecycle management), ERP (enterprise resource planning), MES (manufacturing execution system), etc. However, the data standards of each system are not unified and the interface protocols are heterogeneous (suppliers mostly use custom TCP protocols, while enterprises mainly use RESTful APIs). As a result, key data such as raw material inventory, production progress, and R&D needs are difficult to share in real time.

[0017] Electronic materials are sensitive to storage environments (temperature, humidity, light) and transportation conditions (vibration, shock), but existing systems mostly rely on manual entry or periodic data collection, and are unable to track the status of raw materials throughout the entire production, warehousing, and transportation chain in real time. When risks such as sensor anomalies (reactor temperature exceeds the standard) and transportation delays (arrival delays due to weather) occur, the system is unable to issue timely warnings. Companies often respond passively after problems occur, resulting in interruptions to R&D tests or scrapping of materials.

[0018] The demand for electronic material R&D often changes dynamically with adjustments in technology routes, but the existing system lacks accurate predictions of market demand and supply capacity. When a certain raw material is in short supply, the system cannot automatically analyze the feasibility and cost impact of alternative materials and must rely on manual investigation by purchasing personnel. Decision-making is inefficient and prone to errors. Faced with scenarios such as a sudden increase in order volume, it is also difficult to quickly assess the impact on production scheduling and R&D plans, resulting in delayed resource allocation.

[0019] The electronic materials supply chain involves multiple tiers of suppliers, logistics providers, and multiple internal departments, but lacks standardized collaborative processes and real-time communication channels. When emergencies such as substandard raw material quality or shipping disruptions occur, information transmission between suppliers, procurement departments, and R&D teams relies on email or phone calls, with unclear response timelines and the risk of buck-passing. For example, when a batch of photoresist failed to meet purity standards, the supplier took 24 hours to submit an analysis report, far exceeding the R&D testing time window and causing project delays.

[0020] Supply chain data contains supplier trade secrets and sensitive information about company R&D parameters, but existing systems have security vulnerabilities in data transmission and storage, which can easily lead to information leaks. Furthermore, electronic materials R&D must comply with compliance requirements such as ISO 27001 and GDPR, but existing systems lack comprehensive operational auditing and data desensitization mechanisms, making it difficult to meet regulatory traceability requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a system diagram of a preferred embodiment of a supply chain management system for electronic material research and development according to the present invention. DETAILED DESCRIPTION

[0022] In order to make the technical solution of the present invention more clear and specific to those skilled in the art, the present invention is further described in detail below with reference to embodiments and drawings, but the embodiments of the present invention are not limited thereto.

[0023] Sensor deployment in raw material production, performance sensor selection and installation; For electronic material production equipment, wafer manufacturing equipment, and chemical synthesis reactors, high-precision industrial-grade sensors are selected, including vibration sensors with a measurement range of 0-200g and an accuracy of ±0.5%FS, temperature sensors with a measurement range of -50℃-300℃ and an accuracy of ±0.1℃, pressure sensors with an accuracy of 0-10MPa and an accuracy of ±0.25%FS, and flow sensors with an accuracy of 0-100L / min and an accuracy of ±0.5%.

[0024] The installation adopts a combination of non-invasive and embedded methods: the vibration sensor is fixed to the key parts of the equipment such as the motor and bearings through a magnetic base; the temperature sensor uses a thermocouple probe embedded in the inner wall of the reactor; the pressure sensor is integrated into the pipe flange interface; and the flow sensor is connected in series to the raw material conveying pipeline.

[0025] The sensor node is equipped with an edge computing module based on the edge gateway of ARMCortex-A53, which can pre-process and filter the raw data, eliminate outliers, and reduce the amount of data transmission.

[0026] For data collection and local storage, each production unit deploys an industrial IoT gateway that supports industrial protocols such as Modbus, Profinet, and OPC UA, and connects each sensor node via wired Ethernet Gigabit or wireless LoRa transmission with a distance of 1-3km.

[0027] The gateway has a built-in 128GB industrial-grade SD card that can cache 72 hours of raw data to avoid data loss caused by network interruptions. It also runs a lightweight MQTT broker to enable local data publishing and subscription.

[0028] Warehouse storage area sensor deployment, environmental and inventory sensor configuration; The temperature and humidity sensor uses the SHT35 series with a measurement range of -40℃~125℃, 0-100%RH, and an accuracy of ±0.3℃ / ±2%RH. It is wall-mounted and one is deployed for every 50㎡ of warehouse area to ensure that there is no blind spot in the monitoring coverage.

[0029] Inventory quantity monitoring uses UHF RFID technology. RFID readers are installed on the shelf beams with an identification distance of 0-8m and a read and write speed of ≥50 pages / second. Each pallet of electronic materials is affixed with an ultra-high frequency RFID tag with a memory of ≥512 bits and can be repeatedly erased and written 100,000 times. At the same time, it is combined with infrared counter-radiation sensors to realize shelf vacancy detection.

[0030] For special electronic material photosensitive components, additional light sensors with an accuracy of 0-100,000 lux and an accuracy of ±5% and gas sensors with an oxygen concentration of 0-25% VOL and an accuracy of ±0.5% are deployed.

[0031] The warehouse IoT network adopts the WiFi6802.11ax wireless mesh network architecture. High-performance APs supporting MU-MIMO are deployed at the warehouse entrances and exits, with a concurrent user capacity of ≥200. Sensor nodes are connected to the network through WiFi modules to achieve data aggregation.

[0032] Deploy an industrial-grade 8-port Gigabit PoE switch to power APs and fixed sensor nodes, ensuring stable equipment operation.

[0033] Deployment of IoT devices for transport vehicles, and selection of positioning and condition monitoring equipment; The GPS positioning module uses Beidou / GPS dual-mode positioning terminal with positioning accuracy ≤1m, cold start time ≤30s, supports BDSB1I and GPSL1 frequency bands, is integrated into the vehicle terminal, and obtains vehicle driving data speed, rotation speed, and brake status through the OBD interface.

[0034] The vibration sensor uses a three-axis accelerometer with a measurement range of ±16g and a sampling rate of 1000Hz. It is installed at the bottom of the cargo pallet to monitor the impact acceleration during transportation in real time.

[0035] Temperature and humidity sensors with a range of -40°C to 85°C, 0-100% RH, and door magnetic sensors are deployed inside the carriage to monitor the cargo storage environment and the carriage switch status.

[0036] The in-vehicle IoT terminal is integrated with an industrial-grade in-vehicle gateway that supports a wide voltage input of 9-36VDC, and integrates a 5G communication module, Bluetooth 5.0, and RS485 interface to achieve sensor data aggregation and transmission.

[0037] The terminal has a built-in backup lithium battery with a battery life of ≥4 hours to prevent data interruption after the vehicle is turned off. It is also equipped with an SD card with a capacity of 128GB for local data caching.

[0038] 5G communication technology implementation plan and 5G network architecture design; The network deployment model adopts a hybrid architecture of public and private networks: 5G enterprise private network SA independent networking mode is deployed in supplier factories and warehouse areas, and local data diversion is achieved through MEC multi-access edge computing servers, reducing transmission delay to ≤20ms end-to-end delay.

[0039] The transportation link uses the operator's public 5G network NSA non-independent networking to support wide-area coverage and ensure communication continuity during vehicle movement.

[0040] The core network and edge nodes are configured, and the MEC nodes are deployed in the supplier's industrial park. They are equipped with computing resources of 8-core CPU, 32GB memory and storage resources of 1TB SSD, and run lightweight core network elements AMF, SMF, and UPF to realize local processing and forwarding of IoT data.

[0041] Establish an S1-AP interface connection with the operator's core network, support flexible scheduling of data locally and in the cloud, and prioritize local processing of data equipment failure alarms with high real-time requirements through MEC.

[0042] Data transmission protocols and security mechanisms, transmission protocol stack; The MQTT over 5G protocol is used between IoT devices and the supply chain management system. The client sensor node and the server supply chain system are connected via TCP, supporting QoS 2 level message transmission to ensure that messages are delivered only once.

[0043] For massive sensor data, the CoAP protocol is used for lightweight transmission, and the UDP protocol is used to reduce transmission overhead. It is suitable for reporting periodic data such as temperature and humidity.

[0044] To ensure data security, the device access layer adopts the 5GAKA authentication mechanism. Each IoT device is assigned a unique SUPI user permanent identifier, and identity authentication and key negotiation are achieved through the USIM card.

[0045] The data transmission layer uses the TLS1.3 encryption protocol to encrypt sensor data end-to-end to prevent eavesdropping or tampering during transmission.

[0046] Deploy firewalls and intrusion detection systems (IDS) to monitor abnormal traffic in the 5G network in real time and intercept malicious attacks such as DDoS attacks and port scans.

[0047] Data upload and system docking, data aggregation and preprocessing; After the sensor data is aggregated by the IoT gateway, it is converted into a unified JSON format, cleaned to remove outliers, and fill in missing values, and then sent to the MEC node or cloud platform via the 5G network.

[0048] The data compression algorithm LZ77 is used to compress the transmitted data, reducing the bandwidth usage of the 5G network, and the compression rate can reach 30%-50%.

[0049] Integration with supply chain management systems; The cloud-based supply chain management system deploys Kafka message queues to receive IoT data transmitted via the 5G network, and connects to the system database MySQL cluster through the RESTful API interface to achieve real-time data writing.

[0050] Develop data synchronization middleware to support incremental data synchronization and breakpoint resumption, ensuring that when the 5G network is interrupted and restored, the locally cached data can be resumed to the system to ensure data integrity.

[0051] QoS guarantee mechanism and service slice configuration; In the 5G network, dedicated service slices are configured for IoT data transmission, independent network resource bandwidth ≥ 10Mbps is allocated, and the slice priority is set higher than that of ordinary Internet services to ensure the stability of data transmission.

[0052] Differentiated QoS parameters are set for different types of data: equipment fault alarm data is carried using GBR guaranteed bit rate, with a rate ≥ 1Mbps; routine monitoring data is carried using Non-GBR, with a rate ≥ 512kbps.

[0053] Mobility management is optimized. The 5G terminals equipped in transport vehicles enable cell reselection and switching optimization functions, supporting fast cell switching with a delay of ≤50ms, avoiding communication interruptions at speeds of ≤120km / h during high-speed movement of vehicles.

[0054] It uses 5GNR dual connection technology EN-DC, connecting to 4G LTE and 5GNR networks at the same time, and automatically switches to 4G network when the 5G signal is weak to ensure data transmission continuity.

[0055] The construction of data interface standardization system includes interface types and protocol standards; RESTful API is uniformly adopted as the core interface type, compatible with SOAP API for legacy systems, with clear interface naming rules: / api / v1 / supplier / {supplierId} / production-plan, request methods: GET to obtain data, POST to submit changes, PUT to update status, DELETE to cancel records, and JSON return format, supporting application / json media type.

[0056] For daily inventory reports with batch data exchange, EDIFACT standard messages such as ORDERS and INVOIC are supplemented, and structured data is encapsulated in XML format to ensure cross-system compatibility.

[0057] Core data field specifications, formulate the "Supply Chain Data Exchange Field Manual", clarify the field definition, data type, format and verification rules of key data, as shown in the following table: Data Type Core fields Data Type Format Example Verification rules Production Planning Plan ID, material code, planned output, production date String / Int PLAN2023001 / MAT001 / 500kg Material coding must comply with industry standard IEC61360 Inventory Information Inventory ID, material code, current inventory, safety threshold String / Int INV001 / MAT001 / 300kg / 200kg The inventory value must be ≥0, and an alarm will be triggered if it is lower than the safety threshold. Shipping Status Order ID, delivery time, carrier, en route location String / Time PO2023001 / 2023-10-01T14:30 Location information needs to be associated with Beidou / GPS coordinate format Interface technology architecture design, distributed interface gateway deployment, deployment of API gateways Kong and Apigee at the network boundary between the enterprise and suppliers as a unified entry point for data interaction, and implementation of three core functions: Protocol conversion: Automatically convert the supplier's private protocol custom TCP protocol into RESTfulAPI / EDIFACT to adapt to system differences between different suppliers; Traffic control: Set a QPS threshold of 100 times / second for each supplier to prevent sudden traffic from impacting the supply chain management system; Version management: Supports interface version iteration v1 / v2, compatible with smooth transition of new and old supplier systems. Middleware adaptation layer realizes the development of supplier data adaptation middleware based on Apache Camel framework, and develops special adapters for different suppliers' system characteristics such as SAP, Oracle EBS, and UFIDA U8. For suppliers who support standard APIs: connect directly through RESTful APIs and pull / push data in real time; For suppliers that only support direct database connections: connecting to their database via JDBC requires the supplier to authorize a read-only account, and synchronize incremental data based on timestamps or log tables every 5 minutes; For small suppliers without digital systems: Provide lightweight web forms or Excel template upload interfaces, and convert unstructured data into standard JSON format through OCR recognition and format verification tools.

[0058] Data security and reliability assurance, interface access security mechanism; Identity authentication: Using the OAuth2.0 authorization framework, each supplier is assigned a unique ClientID / Secret, and interface access control is achieved through tokens. The token validity period is set to 2 hours and supports real-time revocation; Transmission encryption: All interface communications are encrypted using the TLS 1.3 protocol. Sensitive supplier cost data is encrypted at the field level using the AES-256 algorithm. Keys are dynamically distributed through the key management system (KMS). Granular permission control: Set data access permissions based on the RBAC model. For example, suppliers are only allowed to view their own inventory data and are prohibited from accessing other suppliers' information.

[0059] Data reliability is guaranteed, and breakpoint resuming is possible: data fragmentation transmission and verification based on CRC32 checksum are implemented at the middleware layer. When the network is interrupted, only the unsuccessful fragmented data is transmitted when the connection is restored. Data retransmission mechanism: Adopting the "three retries + exponential backoff" strategy, the first interval is 10 seconds, the second is 20 seconds, and the third is 40 seconds. Failed data is stored in the local message queue RabbitMQ and automatically retransmitted after the network is restored. Log audit: The interface gateway records all data interaction logs including request parameters, response results, and timestamps. The log retention period is ≥ 1 year, supporting the tracing of the entire data flow link.

[0060] Supplier system adaptation and access process, supplier tiered adaptation strategy; Core suppliers and core raw material manufacturers: their systems are required to be directly connected to the RESTful API, supporting real-time data push and synchronization of production plan changes within 10 minutes; Non-core suppliers: Daily batch data synchronization is performed via EDIFACT messages, with the daily inventory pushed at 2:00 AM, or scheduled data pull is performed via middleware. Temporary suppliers: Use Excel template upload + manual review mode, and enter the data into the supply chain system after format verification.

[0061] Access implementation process, sign the "Data Interface Access Agreement", clarify the data scope, update frequency, and division of responsibilities; The supplier system completes interface development or uses the adapter SDK provided by the enterprise, and verifies test cases including normal flow, abnormal flow, and concurrent flow through the interface gateway test environment; After the test is passed, the production environment is switched to a dual-track operation, with existing interface synchronization and manual verification. After one week without any abnormalities, the production environment is fully dependent on the interface data. Regularly conduct monthly interface performance reviews and optimize interface thresholds and bandwidth based on data volume growth.

[0062] Deep integration solutions for internal business systems and formulation of enterprise-level data exchange standards; Unified data model construction, based on the product life cycle data design enterprise-level data model using UML class diagram definition, covering core links such as R&D, procurement, production, inventory, etc., to clearly define the "single data source" for cross-system shared data: Material master data: The PLM system is the sole source, including material codes, specifications, R&D parameters, etc., and is synchronized to ERP, MES, and supply chain systems; Demand data: Using the PLM R&D BOM / requirements list as the source, synchronize it to the supply chain system to generate a procurement plan; Supply data: Based on the inventory and in-transit data of the supply chain system, it is fed back to ERP for cost accounting and MES for production scheduling.

[0063] Data format and interaction specifications: Internal systems uniformly use the JSON-LD format, a semantic data format based on JSON. The data semantics are defined through the @context field "@context": "https: / / company.com / data-context / v1" to ensure that different systems have consistent understanding of the same data. Example of the JSON-LD format for R&D requirement changes: { "@context":"https: / / company.com / data-context / v1", "type":"DemandChange", "demandId":"DEM2023001", "materialId":"MAT001", "newQuantity":500, "changeReason":"Increase in R&D testing volume", "timestamp":"2023-10-01T09:30:00Z", "status":"confirmed"} Adopting a bus + middle platform hybrid architecture, we achieve real-time communication between systems through the enterprise service bus (ESB), and unified data governance through the data middle platform: ESB layer: Deploy Apache Service Mix as the service bus, encapsulate the functions of each system into standardized services such as the "demand change service" of PLM and the "purchase order creation service" of ERP, and support service registration, routing and orchestration. Data middle platform layer: Build HDFS storage and Hive data warehouse based on the Hadoop ecosystem to achieve cross-system data cleaning, fusion and modeling, and provide a unified data API for query by various systems. Real-time layer: Introduce Kafka message queue partition number = number of systems × 2 to handle high-real-time data R&D demand changes and production anomaly warnings, ensuring message delivery delay ≤ 1 second.

[0064] Integration of PLM and supply chain systems; Integration goal: Changes in R&D requirements are synchronized to the supply chain in real time, and the material supply status of the supply chain is fed back to the R&D team in real time.

[0065] Technical Implementation: The PLM system exposes the "R&D BOM Change Service" through the ESB. When R&D personnel modify the BOM to add new materials or adjust quantities, the service call is automatically triggered, generating a demand change message in JSON-LD format and sending it to the Kafka topic plm-demand-change. The supply chain system subscribes to this topic, automatically updates the procurement plan upon receiving the message, and uses the "Supply Status Service" to provide the PLM with feedback on the material's inventory / in-transit status, such as "MAT001 currently has 300 kg in stock, and 200 kg is expected to arrive on October 5th." Set linkage rules at key nodes: When the supply chain system detects that R&D demand exceeds existing supply capacity, it automatically pushes a "supply risk warning" to the PLM system, triggering an R&D plan review.

[0066] Integration of ERP and supply chain systems: The integration goal is to synchronize the procurement execution data of the supply chain to ERP for financial accounting, and the capital planning of ERP constrains the procurement strategy of the supply chain.

[0067] Technical implementation: After the supply chain system generates a purchase order, it calls the ERP's "Purchase Order Creation Interface" through the RESTful API to synchronize information such as order number, amount, and supplier; The ERP system uses database triggers to push any changes in the payment status of the payment order table to the supply chain system in real time to update the order's "paid" status; The CDCChangeDataCapture tool Debezium is used to monitor the material cost table of ERP. When the cost changes, it is automatically synchronized to the supply chain system for procurement price verification.

[0068] MES is integrated with the supply chain system. The integration goal is: the raw material arrival information of the supply chain drives the MES production scheduling, and the production consumption data of MES feeds back to the supply chain inventory management.

[0069] Technical Implementation: The supply chain system pushes arrival information, including material, quantity, and quality inspection results, to the MES through the "Raw Material Arrival Notification Service." Based on this information, the MES updates the availability of production materials and triggers scheduling adjustments. The MES sends production consumption data ("MAT001 consumes 50 kg on production line A") to the Kafka topic mes-material-consumption every hour. After the supply chain system subscribes to the data, it automatically deducts the corresponding inventory and updates the "available inventory"; When MES detects a shortage of raw materials and the inventory is lower than production demand, it calls the "emergency replenishment service" of the supply chain system through ESB, triggering the supplier's expedited delivery process.

[0070] 4. Real-time synchronization and consistency guarantee, real-time control strategy; High-priority data R&D requirement changes and production downtime warnings: Through Kafka synchronization, the "synchronous send + confirmation mechanism" is adopted. The producer waits for the consumer to confirm before returning, ensuring that the message is not lost. Daily inventory reports for medium-priority data: Synchronize every 30 minutes through an ESB scheduled task, using incremental synchronization to transmit only changed data. Low-priority data historical purchase records: synchronized in batches through the data center on a T+1 basis at 3:00 a.m. every day.

[0071] Data consistency assurance and distributed transactions: The key cross-system operation "purchase order creation + ERP financial accounting" uses the Saga model to achieve eventual consistency. This splits the transaction into steps from "order creation to ERP accounting to order confirmation." If any step fails, a compensating action is performed to cancel the order. Data reconciliation: Every morning, the data center performs cross-system reconciliation of PLM demand quantity vs. supply chain procurement quantity vs. MES consumption quantity. The difference data automatically generates a reconciliation list and pushes it to the corresponding system manager. Version control: All cross-system data carries the version number version: 3. When the recipient finds that the version is lower than the local version, it automatically requests a full synchronization to avoid data overwriting.

[0072] Interface testing: Use Postman / Newman to build an automated test suite, covering external interface vendor APIs and internal interface system services. Test scenarios include normal requests, abnormal input null values, out-of-range values, and high concurrency simulation of 1000 TPS; Integration testing: Building a simulation test environment to mirror the production system configuration, simulating the end-to-end process from PLM demand changes to supply chain procurement plans to ERP orders to MES production to supply chain inventory updates, verifying the accuracy and timeliness of data flow; Disaster recovery testing: Regularly simulate a single system outage every quarter, taking the PLM offline for 2 hours, to verify the degradation strategies of other systems. The supply chain system's temporary operation based on cached data and the data synchronization capabilities after recovery.

[0073] Real-time monitoring: Deploy the Prometheus + Grafana monitoring system to collect real-time data with a target interface call success rate of ≥ 99.9%, a target response time of ≤ 500ms, and a target message queue backlog of ≤ 1000 messages. Set a threshold alarm success rate of < 99% to trigger an SMS alert. Log management: We use the ELKElasticsearch+Logstash+Kibana stack to centrally manage cross-system logs. We use log association IDs to track the complete log chain from PLM requirement changes to supply chain procurement plans. Emergency response: Develop an "Interface Integration Failure Emergency Plan" to clearly define fault classification (P0: core interface interruption > 1 hour; P1: non-core interface interruption > 4 hours) and handling procedures, and deploy a 24 / 7 technical support team.

[0074] Adopting a "lightweight front-end + microservices back-end" architecture to ensure cross-end compatibility and real-time data processing capabilities: Front-end technology: Developed based on the React framework (supporting component reuse), combined with ECharts (chart visualization), Three.js (3D warehouse modeling) and Socket.IO (real-time data push), to build a responsive interface (compatible with Chrome / Firefox on PC and Safari / WeChat browser on mobile).

[0075] Backend services: Adopting the SpringCloud microservices architecture, the system is divided into "data collection service," "rule engine service," and "kanban configuration service." Real-time data from the supply chain system is received through Kafka message queues (seamlessly integrated with the 5G transmission architecture mentioned above). Hotspot data (current inventory and in-transit quantity) is cached in Redis, and response latency is controlled within 500ms.

[0076] Data storage: The time series database InfluxDB is used to store historical sensor data (supporting high write performance), the MySQL cluster stores static configuration data (dashboard layout, user permissions), and Elasticsearch stores log data (for exception tracing).

[0077] Real-time data from the supply chain system (inventory changes, order status) is pushed to the dashboard backend via the Kafka topic supply-chain-real-time. The backend data collection service consumes the message, converts the format (maps it to the standardized fields required by the dashboard), and pushes it to the frontend via WebSocket. After the front end receives the data, it triggers the status update of the corresponding component (inventory value refresh, dynamic redrawing of charts), and caches the data of the last 30 minutes locally (to avoid loss due to page refresh).

[0078] For historical data queries (demand trends over the past 7 days), the frontend calls the backend through the RESTful API, and the backend queries and returns aggregated results (hourly averages) from InfluxDB.

[0079] Visualization: A "dashboard + heat map" combination is used. The dashboard on the left shows the total inventory share of each core supplier (supplier A 35%, supplier B 25%), and the heat map on the right presents the specific material inventory status in a matrix format (the row dimension is the supplier, and the column dimension is the material code).

[0080] Data Dimensions: Real-time display of current inventory, safety threshold, and inventory health (= current inventory / safety threshold, green > 1.2, yellow 0.8-1.2, red < 0.8). Click a cell to drill through and view historical trends (line chart).

[0081] Abnormal reminder: When the inventory of a certain material is less than the safety threshold, the heat map cell flashes red, and a floating window pops up in the upper right corner (displaying "Material MAT001 inventory is insufficient, current 200kg / threshold 300kg, it is recommended to replenish within 48 hours").

[0082] Visualization: Logistics tracks are visualized based on the AutoNavi Map API. Goods in transit are marked with "dynamic icons" (different material types use different colors: red = chip raw materials, blue = chemical reagents). Hovering the mouse displays "estimated arrival time, transporter, current location (Beidou coordinate conversion)".

[0083] Exception handling: When transportation is delayed (actual transit time > 120% of planned time), the icon turns orange and jumps, and a "delay list" is generated below the map (including the reason for the delay, "heavy rain, expected delay of 6 hours").

[0084] Visualization: A "real-time bar chart + trend line" combination is used, with the X-axis representing the order date (the last 14 days), the left side of the Y-axis representing the order quantity (bar chart), and the right side representing the year-on-year growth rate (line chart, red indicates negative growth).

[0085] Dynamic effect: When a new order is generated, the column of the corresponding date increases in a "growth animation" manner (lasting 1 second). If the daily order volume increases by more than 50% compared to the previous day, the column flashes yellow and displays a "sudden increase reminder" label.

[0086] Visualization: A stacked area chart shows changes in demand for different product lines (power battery materials, semiconductor materials), supports switching the time granularity by "week / month", and clicks the legend to hide / show the corresponding product line data.

[0087] Forecasting function: Based on the LSTM neural network model, it automatically generates a demand forecast curve for the next 7 days (represented by a dotted line and the confidence interval is filled with shadows). When the forecast value exceeds the production capacity threshold, the curve turns red.

[0088] Visualization: A Gantt chart shows the planned vs. actual progress of each R&D project ("Project X: Planned 60% Complete, Actual 55% Complete"), with key milestones ("Sample Testing") marked with diamonds and delayed milestones highlighted in red.

[0089] Linked design: Click the project name, and the material consumption details (pie chart) of the project will automatically expand on the right, showing the proportion of consumed materials to total demand ("70% of silicon wafers have been consumed").

[0090] Visualization: The 3D digital twin model restores the layout of the production workshop. The color of the equipment icon indicates the operating status (green = normal, yellow = warning, red = shutdown). Click the device with the mouse to view the real-time parameters (reactor temperature 280℃ / set 300℃).

[0091] Abnormal linkage: When a device triggers a fault alarm (temperature exceeds the upper limit), the corresponding device in the 3D model flashes red and automatically jumps to the "Device Details Page" (displaying the fault code, historical fault records and maintenance suggestions).

[0092] Dynamic interface reminder: Use CSS animation to achieve visual impact (flashing red, zooming in and out), and combine with ElementUI's Notification component to pop up a prompt box (supports manual closing or automatic disappearance after 10 seconds).

[0093] Sound alarm: For serious abnormalities (production line shutdown), the front-end calls the WebAudioAPI to play the preset prompt tone ("ding dong-ding dong"), and the back-end sends a text message to the responsible person through the SMS gateway (based on Alibaba Cloud SMS service).

[0094] Mobile push: When the user is offline, the WebSocket connection status is determined and abnormal information is automatically pushed to the supporting app (based on Firebase Cloud Messaging / Huawei Push Service), including a "View Details" jump link.

[0095] Rule configuration: Trigger conditions are defined through the backend "rule engine service", which supports user-defined thresholds ("inventory < 80% of safety threshold" and "daily increase in order volume > 30%)). Rules are stored in JSON format: { "ruleId":"RULE001", "module":"inventory", "condition":"currentStock <safetyStock*0.8", "level":"warning", "notification": "Insufficient stock: {materialName} current stock {currentStock}, below the safety threshold of 80%", "recipients":["procurement@company.com","manager1@company.com"]} Real-time triggering: When real-time data flows in, the rule engine service matches rules one by one through the Apache Flink stream processing framework. If the conditions are met, an alert event is generated and sent to the Kafka topic alert-events. The dashboard backend consumes it and triggers an alert.

[0096] Priority classification: Exceptions are divided into three levels (info / warning / critical). The critical level (raw material supply outage) is forcibly displayed at the top and triggers a phone voice notification (implemented through the Twilio API).

[0097] PC: Adopts a three-column layout (navigation on the left, main dashboard in the middle, and details panel on the right), supports dragging and dropping to adjust the size of each section (based on the React-DnD library), and supports resolutions from 1920×1080 to 2560×1440.

[0098] Mobile: It uses a single-column scrolling layout, displays core indicators (abnormal quantity, key inventory) by default, switches between different sections through the tab at the bottom, and supports gesture zooming (zoom in with two fingers to view chart details).

[0099] Large-screen display: For the 4K large screen in the monitoring center, the layout is optimized to a "nine-square grid", the font and chart sizes are enlarged, interactive elements (buttons, input boxes) are disabled, and different perspectives are automatically rotated every 5 minutes.

[0100] Role-based permission control: Based on the RBAC model, the "R&D Manager", "Purchasing Manager" and "Production Supervisor" are assigned viewing / operation permissions for different sections (the Purchasing Manager can modify inventory thresholds, and the R&D Manager can only view production progress).

[0101] Personalized dashboard: supports user-defined dashboard layout (drag and drop panel positions, hide irrelevant modules), configuration preferences are stored in MySQL ("display supplier inventory + production progress by default"), and automatically loaded upon login.

[0102] Data export: Each chart supports one-click export (PDF / Excel format). The exported file contains data timestamp and exporter information to meet audit requirements.

[0103] Use code splitting to reduce the initial loading volume and prioritize loading core modules. Chart data is updated incrementally (only the changed parts are transmitted) to avoid full redrawing; Use WebWorker to handle complex calculations (trend forecasting) to avoid blocking the main thread.

[0104] Set a 10-second expiration time in Redis for frequently accessed data (real-time inventory) to reduce database queries; Kafka consumers use batch pull (batch.size=1000) to reduce IO times; Time series data queries use downsampling (automatic aggregation when the number exceeds 1000 points) to reduce the amount of returned data.

[0105] Data transmission security: All communications between the front-end and back-end are encrypted using HTTPS (TLS1.3), and WebSocket connections are authenticated by Token (bound to the user's login status and valid for 2 hours).

[0106] Operation audit: records key user operations (modifying alert thresholds, exporting data). The log includes the user name, IP address, operation time and details, and is retained for one year.

[0107] Anti-attack measures: Implement request frequency limit on the front end (≤60 requests per minute for a single IP address), and deploy WAF (Web Application Firewall) on the back end to intercept malicious requests such as SQL injection and XSS attacks.

[0108] A layered distributed architecture is used to implement full-link processing from data collection to decision support, which is specifically divided into five layers: Data collection layer: Integrates three types of data through multi-source access components (FlinkConnector, KafkaConnect): IoT device data: Receives sensor data (vibration, temperature and humidity, GPS positioning) from the 5G network and connects to the Kafka topic iot-real-time via the MQTT protocol; External interface data: RESTful API / EDIFACT messages connected to the supplier system are converted by the API gateway and written to the Kafka topic external-data; Internal enterprise data: Capture change data from systems such as PLM, ERP, and MES using the CDC tool (Debezium) and synchronize it to the Kafka topic internal-system-data.

[0109] Data processing layer: Build a stream computing engine based on Apache Flink and deploy 20 TaskManager nodes (each with 8 cores and 32GB of memory) to achieve: Real-time cleaning: filtering outliers (erroneous data with temperatures greater than 300°C) and filling missing fields (filling short-term missing inventory data with historical averages); Data conversion: standardize data formats (convert date formats from different suppliers to ISO8601), calculate derived indicators (inventory health = current inventory / safety threshold); Stream-batch fusion: FlinkSQL is used to simultaneously process real-time stream data and offline batch data (combining the past 30 days of historical data to calculate trends).

[0110] Data storage layer: adopts hybrid storage architecture: Real-time data: Kafka cluster (3 replicas, 100 partitions) stores the last 24 hours of data and supports high-throughput writes (≥100,000 records / second); Historical data: InfluxDB stores time series data (retained for one year for trend analysis), HBase stores unstructured data (sensor raw logs), and the MySQL cluster stores dimensional data (user roles, basic material information).

[0111] Algorithm analysis layer: Deploys a machine learning service cluster (10 GPU servers, NVIDIA A100 graphics cards), integrates the TensorFlow / PyTorch framework, and provides: Real-time inference interface: supports online model calling (demand forecasting, delay risk assessment); Model training platform: Schedules offline training tasks based on Airflow (executed at 2:00 AM daily) and automatically updates model parameters.

[0112] Application service layer: Provides three types of functions through SpringBoot microservices: Report generation service: Generate customized analysis reports based on user roles; Early warning push service: push notifications to the visual dashboard and mobile terminal when the early warning rules are triggered; Data query service: Provides RESTful API for front-end calls and supports complex conditional filtering (querying materials from supplier A with a delay risk greater than 80% in the past 7 days).

[0113] Based on Kubernetes containerized deployment, automatic scaling is achieved through HPA (Horizontal Pod Autoscaler): When the back pressure of Flink tasks exceeds 50%, TaskManager nodes are automatically added; Adopting multi-availability zone deployment (primary availability zone + disaster recovery availability zone), the data storage layer achieves cross-zone synchronization (RPO ≤ 5 minutes, RTO ≤ 30 minutes), ensuring that single point failures do not affect services. 30% computing resource redundancy is reserved to support smooth processing of business peaks (data volume increases by 50% during the peak period of new product development).

[0114] Data access and diversion: KafkaConnect diverts data from the iot-real-time topic by device type (vibration sensor data → iot-vibration, temperature and humidity → iot-env); FlinkJob1 consumes the diverted data, performs cleaning and transformation (eliminating abnormal data with vibration values ​​greater than 200g), and outputs it to the Kafka topic processed-iot-data.

[0115] Real-time indicator calculation: FlinkJob2 consumes processed-iot-data and internal-system-data to calculate core indicators: Supply chain health: This factor includes supplier delivery timeliness (weighted 40%), inventory turnover (30%), and production equipment availability (30%), updated every 5 minutes. Transportation Risk Index: Calculates a risk score from 0 to 100 (a score of 70 or higher triggers an alert) based on real-time location, road conditions (using the AutoNavi Map API), and historical delay data.

[0116] Data landing and indexing: Processed data is written to InfluxDB (time series data) and HBase (detailed data) in real time; Elasticsearch creates an index every 10 minutes and supports full-text search (finding warehouses where temperatures have exceeded the standard in the past 24 hours).

[0117] Input features of the short-term market demand forecast model: Historical data: order volume, demand type, and seasonal factors for the past 90 days; Real-time data: daily order growth, social media sentiment (using APIs to obtain the popularity of electronic materials-related topics), and competitor price changes; Model architecture: A deep learning model using LSTM+attention mechanism is used. The input layer contains 128 neurons and the hidden layer has 3 layers (64 neurons per layer). The output is the daily demand forecast for the next 7 days. Accuracy optimization: The model is updated through a sliding window (retraining every 7 days), and the prediction error is controlled within ±8% (a 15% improvement over the traditional ARIMA model).

[0118] Raw material supply delay risk prediction model: Input characteristics: Supplier data: production equipment failure rates, historical delivery delays, and raw material inventory levels; Transportation data: real-time in-transit location, estimated arrival time, weather conditions (using the Meteorological Bureau API); Model architecture: Gradient boosting tree (XGBoost), which performs binary classification (delay / no delay) on the delay probability (0-100%) and outputs the confidence score; Application scenario: When the predicted delay probability of a batch of materials is greater than 60%, the alternative supplier search process is automatically triggered.

[0119] R&D material matching recommendation model: Input features: material specifications in the R&D BOM (purity ≥ 99.99%), performance parameters (high temperature resistance > 200°C), and cost ceiling; Model architecture: Based on the knowledge graph similarity matching model, the material attributes are compared with the supplier's inventory materials, and the top 5 matching candidate materials are output; Value realization: Shortens the R&D material sourcing cycle (from an average of 3 days to 4 hours) and reduces trial and error costs.

[0120] Core report for purchasing managers: Daily Purchasing Strategy Analysis, including a list of material shortage warnings (sorted by urgency, with alternative plans); Supplier cost-effectiveness rating (comprehensive price, delivery timeliness, and quality compliance rate); Procurement cost optimization suggestions (bulk purchase discounts, joint purchasing opportunities).

[0121] Push frequency: Real-time warning (immediate push when delay risk > 70%) + daily summary report at 8:00 am.

[0122] R&D Person in Charge: Core Report: "Feasibility Analysis of R&D Material Supply" includes: The supply status of each material in the R&D BOM (sufficient / scarce / out of stock); Evaluation of new material alternatives (performance differences, cost impact, acquisition cycle); Simulate the impact of demand changes on the supply chain (assess supply capacity after a 50% increase in usage).

[0123] Push frequency: Real-time push notifications when R&D requirements change + trend analysis every Monday at 9:00 AM.

[0124] Production Supervisor Core Report: Production Material Assurance Report includes: The real-time consumption rate of production line materials and the duration of inventory support; Predict the impact of equipment failure on production schedule (a reactor shutdown will result in a 12% drop in daily output); Optimal production schedule suggestion (adjusting production sequence based on material arrival time).

[0125] Push frequency: Update production material status every 2 hours + real-time warning of abnormal events (material shortage).

[0126] Visual dashboard: Warning information is highlighted with a red flashing border. Click to view details (delay reason, impact range). Mobile app: Send message notifications via FCM / Huawei push notifications, including viewing details and one-click processing buttons (purchasing managers can directly trigger the emergency procurement process); Email / SMS: Critical-level warnings (risk of raw material supply interruption > 90%) will be sent via email and SMS simultaneously to ensure that the responsible person receives them in a timely manner.

[0127] Data processing optimization: Flink jobs use RocksDB as the state backend and enable incremental checkpoints (every 5 minutes) to reduce state storage overhead. For frequently queried indicators (real-time inventory), set a 5-second cache in Redis to reduce database pressure; Data skew processing (repartitioning by vendor ID) is used to ensure load balancing among TaskManagers (CPU utilization difference <10%).

[0128] Query response optimization: Elasticsearch uses sharded parallel query (8 shards per index), and the response time for complex queries is ≤ 2 seconds; Pre-calculate common aggregate indicators (supplier monthly delivery rate) and store them in MySQL to avoid real-time calculations; The front end uses data paging loading + lazy loading charts, and the first page loading time is ≤3 seconds.

[0129] Data transmission security and encryption: All data links are encrypted using TLS 1.3, and SASL authentication is enabled between Flink and Kafka. Storage encryption: InfluxDB / HBase data uses AES-256 encryption, and sensitive fields (supplier costs) are stored separately in encrypted form. Access control: Based on the RBAC model, each user role is assigned minimum permissions (the production supervisor has no right to view purchase prices).

[0130] Compliance audit: Deploy data desensitization services to mask sensitive information (mobile phone numbers, ID numbers) in logs; Record all operation logs (user ID, operation time, data content), retain them for 2 years, support audit traceability, comply with GDPR / ISO27001 requirements, and conduct regular (quarterly) security compliance checks.

[0131] Adopting a three-layer architecture of data-driven + model-based decision-making + closed-loop process, we achieve full-link intelligence from data perception to action implementation: Data layer: Integrates the real-time IoT data (Kafka topic processed-iot-data), external interface data (external-data), and internal enterprise system data (internal-system-data) mentioned above, standardizes them through the data center (unified field format, associated dimension tables), and stores them in InfluxDB (time series data) and MySQL cluster (business data).

[0132] Decision layer: consists of a rule engine, a machine learning model library, and a decision reasoning engine: Rule engine: Based on the Drools framework, it stores configurable business rules (when the inventory of raw material A is less than the safety threshold of 50%, it triggers the analysis of alternative materials); Model library: Deploy models for demand forecasting, supply delay risk, and alternative material matching (sharing model services with the big data real-time analysis platform); Decision reasoning engine: Uses knowledge graph (built with Neo4j) to store supply chain entity relationships (material-supplier-alternative material associations), combines real-time data with model output for logical reasoning, and generates decision recommendations.

[0133] Execution layer: Decisions are implemented through microservice calls, including procurement adjustment services, production scheduling services, and R&D planning services. It interacts with ERP, MES, and PLM systems in real time through the ESB bus to ensure the automatic execution of decision instructions.

[0134] Development framework: The backend uses SpringBoot+Drools, and the frontend is integrated with a visual monitoring dashboard (React framework), providing a visual display of decision recommendations and an entry point for manual intervention; Model deployment: Machine learning models are encapsulated as RESTful APIs through TensorFlow Serving, supporting online calls (response time ≤ 1 second). Model version management is implemented based on MLflow. High-availability deployment: Adopting a master-slave architecture (the master node processes decision requests, and the slave nodes synchronize data in real time), three replicas are deployed for the key decision-making process (alternative material analysis), and automatic fault switching is achieved through ZooKeeper to ensure service availability ≥ 99.9%.

[0135] Trigger condition: When the big data platform predicts that the supply gap of a certain raw material (silicon wafer MAT001) will be greater than 30% in the next 7 days, or the real-time inventory is less than 50% of the safety threshold, the rule engine automatically triggers the alternative analysis process.

[0136] Alternative material analysis process step 1: candidate material screening: Knowledge graph query: Based on the material attributes in the R&D BOM (purity 99.99%, high temperature resistance 200°C), related alternative materials ("silicon wafer MAT002" and "silicon wafer MAT003") are retrieved; Feasibility verification: Call the "Material Compatibility Interface" of the PLM system to verify the matching degree between the alternative material and the R&D formula (whether it affects the electrical performance of the product) and filter out candidates with a matching degree of less than 80%.

[0137] Step 2: Evaluate supplier capabilities from multiple dimensions: Obtain the candidate material suppliers' on-time delivery rate (≥95% in the past three months) and production capacity (whether they can meet incremental demand) from the external-data topic; Cost comparison: Calculate the difference between the procurement cost of the substitute material (including transportation and tariffs) and the raw material cost (MAT002 cost increases by 12%), and combine it with the R&D and trial production costs (using the ERP cost accounting interface) to generate a total cost assessment; Performance impact: Obtain historical trial production data through the PLM system to evaluate the impact of alternative materials on product yield (MAT003 causes a 3% drop in yield) and quantify performance losses.

[0138] Step 3: Decision recommendation generation: Comprehensive scoring: Use the analytic hierarchy process (AHP) to score candidate materials (supplier capability 40%, cost 30%, performance 30%) and generate a ranked list (MAT002 score 85 points, MAT003 score 72 points); Procurement strategy recommendations: For the optimal candidate, generate specific instructions such as emergency purchase quantity = shortfall quantity × 1.2 (redundancy), batch arrival plan, and cost cap for negotiation with suppliers.

[0139] Demand mutation detection: This system monitors order data in the Kafka topic external-data in real time. When the daily order volume increases by more than 50% (or decreases by more than 30%) compared to the seven-day average, the demand mutation response process is triggered. The demand forecasting model (LSTM) is called and combined with the mutated data to re-forecast the demand trend for the next 14 days and clarify the demand increment (the demand for power battery materials increases by 200kg / day).

[0140] Analyze the material requirements of current R&D projects (obtained from the R&D BOM in PLM) and identify projects that overlap with sudden demand (Project X also requires power battery materials). Generate priority adjustment suggestions: "Pause low-priority project Y (saving 50 kg / day) to prioritize sudden demand, or accelerate the trial production progress of project X to share production capacity."

[0141] Production scheduling optimization: Call the MES's "capacity simulation interface" to evaluate the maximum capacity of the existing production line ("Production Line A's current capacity is 150kg / day, and it can be increased to a maximum of 200kg / day"); Generate an adjustment plan: "Extend the working hours of production line A by 2 hours / day (increase production capacity by 25kg) + start the backup production line B (production capacity 50kg / day) to meet the 200kg / day demand", and calculate the increased labor and energy costs after the adjustment.

[0142] Feasibility verification of the solution: Simulate the impact of the adjustment plan on the supply chain (whether there are sufficient raw materials and whether the equipment load exceeds the limit). Use the Flink stream computing engine to verify the feasibility score of the solution (a score of ≥80 is considered feasible).

[0143] Rule configuration and management: Using a visual rule editor (integrated in the system management backend), business personnel can configure rules by "drag and drop". { "ruleId":"ORDER_SURGE_001", "trigger":"Order volume>historical average×1.5", "actions":[ {"service":"Emergency Procurement Service","params":{"Expedited Level":"P1","Supplier Screening Criteria":"On-time Delivery Rate ≥98%"}}, {"service":"Production Adjustment Service","params":{"Overtime":"2h","Backup Production Line":"B"}} ], "priority":"high"} Before a rule takes effect, it must undergo simulation testing (based on historical data verification) and will be automatically deployed to the Drools rule engine after passing the test.

[0144] Typical automation scenario implementation: Emergency procurement process: When the order volume exceeds expectations, the system automatically calls the "supplier evaluation model" to screen out three high-quality suppliers (with a delivery on-time rate of ≥98% and sufficient production capacity); Push expedited orders (using EDIFACT ORDERS messages) to the supplier system through the API gateway, and simultaneously update the ERP purchase order status to expedited; Track the order confirmation status in real time. If it is not confirmed within 1 hour, the alternative supplier switching process will be automatically triggered.

[0145] Raw material delay response: When the supply delay risk model predicts that the probability of a material delay is greater than 80%, the system automatically: Push "material delay warning" to the R&D department (PLM system) and recommend evaluating alternative solutions; Call the MES scheduling adjustment service to postpone the production tasks that depend on the material and prioritize other tasks; Start the inventory optimization algorithm to calculate the inventory that can be allocated from other warehouses ("allocate 50kg from warehouse B to the production base") to fill the delay gap.

[0146] A unique TraceID is generated for each automated process execution, and key nodes (rule trigger time, service call results, exception handling steps) are recorded through the ELK log system, supporting full-link traceability. Monitor the success rate of automated processes in real time (target ≥95%). When a process fails more than three times in a row, it will automatically pause and notify operation and maintenance personnel to intervene to avoid invalid operations.

[0147] Platform technology implementation: Develop an instant messaging module based on the WebSocket protocol, integrated into the web and mobile terminals of the supply chain management system, supporting: One-on-one chat (Purchasing Manager-Supplier A); Group conversation (quality issue handling group for "Supplier A + R&D + Production"); Functions such as message read status synchronization, file transfer (quality inspection report PDF), message recall, etc.

[0148] Integrated with WeChat / DingTalk, it supports cross-platform message push (synchronizing system alerts to suppliers' WeChat accounts).

[0149] Information sharing and collaboration: Build a shared document library (based on MinIO storage) to store documents such as supplier qualifications, quality inspection standards, and emergency plans, supporting version control and permission management ("suppliers can only view their own quality inspection reports"); Develop an online collaborative whiteboard (integrated with Tencent Docs API) to support real-time annotation by multiple parties (jointly marking the location of raw material quality issues).

[0150] Process definition and role responsibilities: Develop standardized process documents (stored in the system knowledge base) for typical emergency scenarios (raw material quality issues, transportation disruptions, sudden demand changes), and clearly define response timelines: Suppliers must submit analysis reports within 2 hours of discovering quality issues. Role responsibilities: Purchasing Department (lead coordination), R&D Department (provide alternative solutions), Production Department (adjust schedule), Suppliers (provide remedial measures); Communication node: Update progress every 4 hours until the problem is resolved.

[0151] Process automation drive: When the system detects an emergency event (the sensor detects that the raw material purity does not meet the standard), it automatically: Create an emergency group (including relevant role personnel) and send event details (the purity of material MAT001 is 99.9% less than the standard 99.99%); Push standardized process documents to the group to clarify the next steps ("the supplier must provide a cause analysis within 1 hour"); Regular reminders are given for unfinished tasks ("30 minutes left to submit the report"). If tasks are not completed within the deadline, an escalated notification will be sent (a text message will be sent to the supplier's responsible person's mobile phone).

[0152] Drill scenario design and execution: Each month, we select 1-2 typical scenarios, such as supply disruption from core suppliers or material damage during transportation, and generate drill plans (including scenario parameters and expected goals); Generate virtual events through the system simulation module, inject virtual data of supplier A's supply interruption into the system, trigger the emergency response process, and record the response time and collaboration efficiency of each link; Drill evaluation and optimization: After the drill, an evaluation report is automatically generated: the response time to quality issues is 20% shorter than the previous drill, but the matching of alternative materials takes too long; Optimize the system based on the evaluation results: increase the associated dimensions of the alternative material knowledge graph, shorten the matching time or adjust the responsibility allocation in the emergency process, and reduce the communication links.

[0153] The above are only further embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes based on the technical solutions and concepts of the present invention within the scope disclosed by the present invention, which fall within the scope of protection of the present invention.

Claims

1. A supply chain management system for electronic material R&D, characterized by: The data collection layer is used to integrate IoT device data, external interface data, and internal enterprise system data. IoT device data is collected through sensors deployed in raw material production links, warehouse storage areas, and transportation vehicles. External interface data comes from supplier systems. Internal enterprise system data includes PLM, ERP, and MES system data. The data processing layer performs real-time cleaning, conversion, and stream-batch fusion processing on the collected data based on the stream computing engine to generate standardized data and derived indicators; The data storage layer adopts a hybrid storage architecture, including a Kafka cluster for storing real-time data, InfluxDB for storing time series data, HBase for storing unstructured data, and a MySQL cluster for storing dimensional data; The algorithm analysis layer deploys a machine learning model library, including market demand forecasting models, raw material supply delay risk prediction models, and R&D material matching recommendation models, to extract trend and risk information from data; The application service layer includes report generation services, warning push services, and data query services, which are used to provide customized analysis reports and decision support for different user roles; A visual monitoring layer displays the status of each link in the supply chain in real time through web and mobile dashboards, and highlights abnormal information based on color coding and dynamic alerts; The algorithm analysis layer includes a market demand forecasting model, a deep learning model based on the LSTM+attention mechanism, which inputs the historical order data of the past 90 days, the order increment of the current day and market dynamic data, and outputs the daily demand forecast value for the next 7 days; The raw material supply delay risk prediction model, based on the gradient boosting tree algorithm, inputs supplier production data, transportation data, and weather conditions, and outputs delay probability and confidence level; The R&D material matching recommendation model is based on the similarity matching model of the knowledge graph. It outputs the top 5 matching alternative materials according to the material specifications and performance parameters in the R&D BOM.

2. A supply chain management system for electronic material R&D according to claim 1, characterized in that: The data acquisition layer includes an IoT device access module that receives data from vibration sensors, temperature sensors, pressure sensors, flow sensors, RFID readers, GPS positioning modules, and temperature and humidity sensors through the MQTT protocol. The sensors are deployed in electronic material production equipment, warehouse shelves, transport vehicles, and carriages. The external interface adapter module connects to the supplier system through RESTful API or EDIFACT messages to obtain production plans, inventory information and delivery status data. The interface adapter module supports protocol conversion and incremental data synchronization; The internal system integration module captures change data from PLM, ERP, and MES systems through CDC tools and synchronizes them to the data processing layer.

3. A supply chain management system for electronic material R&D according to claim 1, characterized in that: The data processing layer includes a real-time cleaning module for filtering outliers and completing missing fields. The outliers include sensor data that exceeds a preset range. A data conversion module, used to unify data formats and calculate derivative indicators, including inventory health and transportation risk index; The stream-batch fusion module uses FlinkSQL to simultaneously process real-time stream data and offline batch data, and calculates trend features based on historical data.

4. A supply chain management system for electronic material R&D according to claim 1, characterized in that: The application service layer also includes an intelligent decision-making module, which includes an alternative material analysis unit for screening candidate alternative materials and evaluating them from the perspectives of supplier capabilities, cost, and performance impact when raw materials are in short supply, and generating procurement strategy recommendations; The demand mutation response unit is used to evaluate the impact of sudden market demand changes on R&D plans and production schedules, and provide solutions for adjusting R&D project priorities and optimizing production schedules. The automated rules engine automatically triggers business process adjustments based on preset rules, including emergency purchases, production plan adjustments, and inventory transfers.

5. A supply chain management system for electronic material R&D according to claim 4, characterized in that: The automated rule engine supports user-defined rules, which include trigger conditions, execution actions and priorities. The execution actions include pushing expedited orders to supplier systems, adjusting MES production schedules and pushing early warning information to relevant roles.

6. A supply chain management system for electronic material R&D according to claim 5, characterized in that: The visual monitoring layer includes a raw material supply dashboard, which uses a dashboard and heat map to display the supplier's inventory ratio and material inventory status. When the inventory falls below the safety threshold, the corresponding area will flash red to remind you; The market demand dashboard uses bar charts and trend lines to display changes in order quantity and year-on-year growth rates. When the order volume suddenly increases by more than 50%, it is highlighted with dynamic animation. The production progress dashboard uses Gantt charts and 3D digital twin models to display the progress of R&D projects and the status of production equipment. When equipment fails, the corresponding position on the model flashes red and automatically jumps to the details page.

7. A supply chain management system for electronic material R&D according to claim 6, characterized in that: It also includes a supply chain collaboration module, which includes a real-time communication platform that enables instant messaging and file transfer between supply chain members based on the WebSocket protocol, supporting one-on-one chat and group conversations; The emergency response process management unit stores standardized emergency process documents, clarifies the response time limits and responsibilities of each member in different scenarios, and automatically creates a collaboration group and pushes process documents when an emergency event is detected; The joint exercise unit is used to simulate market demand and supply change scenarios, record response time and collaboration efficiency, and generate evaluation reports to optimize the collaboration mechanism.

8. A supply chain management system for electronic material R&D according to claim 7, characterized in that: It also includes a security assurance module, which includes a data transmission encryption unit, uses the TLS1.3 protocol to encrypt the data link, and implements interface access control through OAuth2.0; A storage encryption unit that uses the AES-256 algorithm to encrypt and store sensitive fields, including supplier cost data; The operation audit unit records the user's key operation logs, including the operator, time and details. The log retention period is no less than 2 years.

9. A supply chain management system for electronic material R&D according to claim 8, characterized in that: It adopts Kubernetes containerized deployment, supports automatic expansion and contraction and multi-availability zone deployment, and the data storage layer achieves cross-zone synchronization, ensuring RPO ≤ 5 minutes and RTO ≤ 30 minutes.

Images