Virtual collaborative management and control system of battery swap station and control method thereof
Patent Information
- Application Number
- CN202611222958.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-12
- Publication Date
- 2026-10-30
AI Technical Summary
现有的换电站管控技术通常依赖于云端集中式处理或本地独立的工控系统,这种系统在实际应用中存在响应延迟高、数据隐私性差以及智能化程度不足等问题
[0017]本发明实施例所提供的一种换电站的虚拟协同管控系统及其控制方法具有以下优点:本发明将数据输入推理层进行边缘侧实时分析,有效解决了传统云端处理存在的高延迟与网络依赖问题,通过推理层对交互层与执行层的双向控制,建立了算力资源与安全管控的关联机制。当推理层识别到异常或特定交互需求时,能够及时调整交互界面的展示逻辑并同步触发执行层的防护动作,实现了在保障核心业务安全运行的前提下,对边缘计算资源的高效调度与灵活复用,有效解决了多模型并发场景下的资源冲突与系统卡顿问题。
Smart Images

Figure CN123010669A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of battery swapping station technology, specifically to a virtual collaborative management and control system and control method for battery swapping stations. Background Technology
[0002] In the operation and maintenance system of battery swapping stations, real-time monitoring of equipment status, fault diagnosis, and human-machine interaction are crucial for ensuring battery swapping efficiency and safety. Existing battery swapping station management and control technologies typically rely on centralized cloud processing or local independent industrial control systems. These systems suffer from high response latency, poor data privacy, and insufficient intelligence in practical applications. Because battery swapping stations involve high-voltage electrical operations and precision mechanical movements, the real-time requirements for safety control are high. Relying solely on cloud-based visual reasoning and fault diagnosis often fails to meet safety interlocking requirements. Furthermore, traditional local industrial control computers have limited computing power, making it difficult to simultaneously support real-time analysis of multiple high-definition video streams and complex deep learning model reasoning. This leads to system lag or missed detections when dealing with sudden faults or concurrent tasks.
[0003] Furthermore, existing technologies lack dynamic coordination mechanisms in terms of interactive experience and computing resource allocation. When performing equipment maintenance, station operations and maintenance personnel often face abstract data reports or scattered monitoring screens, lacking intuitive equipment status mapping and auxiliary guidance, leading to low maintenance efficiency and a high risk of misoperation. In self-service scenarios for car owners, only preset voice announcements or simple touch feedback are typically provided, failing to offer services based on the actual situation on-site. More critically, existing edge computing devices lack effective resource scheduling strategies when facing concurrent inference of multiple models. When visual recognition, fault diagnosis, and interactive rendering simultaneously compete for computing resources, it can easily cause inference delays in core security models, or even trigger system crashes, making it impossible to achieve intelligent and flexible management while ensuring basic security.
[0004] Therefore, how to overcome the shortcomings of existing technologies with effective methods has become an urgent technical problem to be solved. Summary of the Invention
[0005] The purpose of this invention is to address the above-mentioned problems by providing a virtual collaborative management and control system and its control method for battery swapping stations.
[0006] The technical solution of this invention is: a virtual collaborative management and control system for a battery swapping station, comprising:
[0007] The data acquisition layer is used to acquire programmable logic controller status data, multiple monitoring image streams, and on-site interactive data. The inference layer, running on edge computing devices, is used to build a multi-model cache pool using the inference engine to achieve adaptive hot-swappable inference of multi-scenario models, and to output diagnostic results for fault diagnosis based on an offline vector knowledge base. The interaction layer is used to respond to vehicle arrival signals or authorization commands, trigger the switching between station maintenance and vehicle owner self-service status, and reallocate system computing resources. In the station maintenance status, the status-aware interaction component performs anthropomorphic twin status mapping. The execution layer is used to automatically route safety alarms or vehicle owner requests for help into work orders, and to realize step-by-step synchronization of work instructions on handheld devices and step-by-step safety red line interlocking control based on the local area network. The data acquisition layer is communicatively connected to the inference layer and the interaction layer, and the inference layer is communicatively connected to the execution layer.
[0008] As an improvement to this embodiment of the invention, the multi-model cache pool includes a security control level model and an auxiliary job level model; the security control level model resides on computing resources; the auxiliary job level model is dynamically cached and managed according to its activity level and weight. When a new model needs to be loaded and the computing resource usage exceeds the warning level, the auxiliary job level model with the lowest weight is released; if the computing resources are still insufficient after releasing all auxiliary job level models, the occupation of security control level model resources is prohibited, a hard circuit breaker is triggered, and a security hover command is issued to the programmable logic controller.
[0009] As an improvement of this embodiment of the invention, the activity retention weight is obtained by normalizing and weighting the time difference factor from the last activation and the call frequency factor within the sliding time window.
[0010] As an improvement of this invention, the offline vector knowledge base is constructed based on the approximate nearest neighbor index algorithm; the fault diagnosis adopts a two-stage joint retrieval and reordering mechanism. In the first stage, candidate slices are recalled by cosine similarity through the approximate nearest neighbor index. In the second stage, the candidate slices and the triggered device fault code query are sent to the local cross encoder for deep semantic matching and reordering, and the diagnosis results are output.
[0011] As an improvement of this embodiment of the invention, when the interaction layer switches to the self-service customer service state for car owners, the heavy-load chart components and video streams are unloaded through the front-end routing and the background polling is paused, so that the released computing power is allocated to the local large model intelligent agent and speech synthesis.
[0012] As an improvement of this embodiment of the invention, the state-aware interaction component adopts a state mapping logic based on a finite state machine, with security blocking events, reasoning events and regular heartbeat events in descending order of priority, which trigger the interface transition between alarm state, thinking state and idle state respectively.
[0013] To achieve one of the above-mentioned objectives, an embodiment of the present invention provides a virtual collaborative management and control method for a battery swapping station. The method is used in the virtual collaborative management and control system for a battery swapping station as described in any of the preceding claims, and includes the following steps: S1: Acquires programmable logic controller status data, multiple monitoring image streams, and on-site interactive data; S2: Utilize the inference engine to build a multi-model cache pool for multi-scenario adaptive hot-swappable inference of models, perform fault diagnosis based on the offline vector knowledge base, and output the diagnosis results. S3: Based on the operating status, it switches between the station maintenance status and the vehicle owner self-service customer service status and reallocates computing resources, and performs human-like twin state mapping through the state-aware interaction component; S4: Automatically route safety alarms or vehicle owner requests for help into work orders, and realize step-by-step synchronization of work instructions on handheld devices and step-by-step safety red line interlocking control based on local area network.
[0014] As an improvement to this embodiment of the invention, step S4, which implements step-by-step synchronization of the work guidance on the handheld device and step-by-step safety red line interlocking control based on the local area network, specifically includes: S41: In response to reaching a preset critical security step, trigger the interface locking mechanism of the handheld device; S42: Receive and verify on-site physical status confirmation information from the handheld device and electrical status telemetry information from the underlying control device; S43: If both the physical status confirmation information and the electrical status telemetry information meet the preset safety conditions, an unlocking command is generated and sent to the handheld device to allow the process to proceed to the next maintenance step.
[0015] As an improvement to this embodiment of the invention, step S4, which automatically routes safety alarms or vehicle owner requests for assistance into work orders, specifically includes: S44: Based on preset event classification rules, analyze the collected multimodal data, determine the event type, and generate a work order of the corresponding level according to the event type; S45: Perform compliance audits at critical points in the work order process; if a work order status that does not comply with the preset security policy is detected, trigger the business interception mechanism and block the current operation process until an authorization revocation instruction is received.
[0016] As an improvement to this embodiment of the invention, it also includes network anomaly handling and data synchronization steps: monitoring the network connection status with the cloud management system; if a network outage occurs, performing local cache clearing and entering offline autonomous mode; in offline autonomous mode, using locally deployed intelligent diagnostic models and knowledge bases to maintain the operation of core business functions; if the network connection is restored, performing local and cloud data difference comparison, and completing bidirectional data synchronization and consistency verification based on preset strategies.
[0017] The virtual collaborative management and control system and method for a battery swapping station provided in this invention have the following advantages: This invention inputs data into the inference layer for real-time edge-side analysis, effectively solving the high latency and network dependency problems inherent in traditional cloud processing. Through bidirectional control of the interaction and execution layers by the inference layer, a correlation mechanism between computing resources and security management is established. When the inference layer identifies anomalies or specific interaction requirements, it can promptly adjust the display logic of the interactive interface and simultaneously trigger protective actions in the execution layer. This achieves efficient scheduling and flexible reuse of edge computing resources while ensuring the secure operation of core businesses, effectively solving resource conflicts and system lag issues in multi-model concurrent scenarios. Attached Figure Description
[0018] Figure 1 This is a schematic diagram of the virtual collaborative management and control system for the battery swapping station described in this invention; Figure 2 This is a schematic diagram of the camera deployment at the battery swapping station described in this invention; Figure 3 This is a schematic diagram of the virtual collaborative management and control method for the battery swapping station described in this invention; Figure 4 This is a schematic diagram of the work order interface of the virtual collaborative management and control method for battery swapping stations described in this invention; Figure 5 This is a schematic diagram of the state-aware interaction component of the virtual collaborative management and control method for battery swapping stations described in this invention; Figure 6 This is a schematic diagram of the alarm event interface of the virtual collaborative management and control method for battery swapping stations described in this invention. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0020] This invention provides a virtual collaborative management and control system for battery swapping stations, such as... Figure 1 As shown, it includes: The data acquisition layer is used to collect real-time status data of the programmable logic controllers of the battery swapping station, multiple monitoring image streams, and on-site interactive data. In practice, the data acquisition layer acquires programmable logic controller (PLC) status data in real time via industrial protocols. Specifically, the Modbus TCP protocol can be used as the physical communication standard, with the default port being 502. Since a single address in a Modbus register only supports 16-bit binary integers, a continuous double-register concatenation mechanism can be used for floating-point data. This mechanism involves reading two consecutive 16-bit registers, reassembling them into a 32-bit single-precision floating-point number in local memory according to the IEEE 754 standard, and adjusting the byte order based on the PLC hardware's big-endian or little-endian encoding format. The PLC status data includes, but is not limited to, battery locking mechanism status, lift position signal, battery swapping robotic arm motor enable signal, high-voltage circuit voltage telemetry value, and various sensor detection signals. The data acquisition layer is also used to acquire multiple monitoring image streams from multiple network cameras deployed inside and outside the battery swapping station. Specifically, such as... Figure 2 As shown, the battery swapping station is equipped with several monitoring cameras for the battery swapping channels. This invention includes six monitoring cameras for the battery swapping channels: a first camera 21, a second camera 22, a third camera 23, a fourth camera 25, a fifth camera 25, and a sixth camera 26. Each camera can be rotated to meet the monitoring needs of the battery compartment inside the station. The station is also equipped with several external monitoring cameras. This invention includes three external monitoring cameras: a seventh camera 11, an eighth camera 12, and a ninth camera 13. These cameras can be rotated to monitor the external environment of the station and can also perform biological intrusion detection around the station based on image recognition. It is understood that multiple cameras cover the battery swapping operation area, the equipment and instrument area, and the external environment area, forming a comprehensive visual perception coverage.
[0021] The data acquisition layer is also used to collect on-site interactive data through handheld terminals and interactive interfaces. The handheld terminal and the local industrial control computer communicate via a long-term connection using a bidirectional WebSocket over TLS v1.3 protocol based on local area network Wi-Fi, achieving low transmission latency and data anti-eavesdropping. All interactive data is encapsulated in standard JSON format, specifically including the following data types: on-site verification data containing fields such as verification identifier, operator identifier, site identifier, standard operating procedure identifier, step number, inspection item, pass / fail status, photo evidence, and timestamp; vehicle owner assistance data containing fields such as assistance identifier, license plate number, vehicle owner's phone number, and assistance category, where the assistance category may include fields such as card error, mechanical jamming, payment problem, and others, user description, and timestamp; personnel check-in data containing fields such as personnel identifier, shift identifier, equipment MAC address, and check-in time; and handover notes data containing fields such as handover identifier, shift identifier, outgoing shift identifier, incoming shift identifier, pending work order list, safety hazard notes, and timestamp.
[0022] In practice, the application interface of the handheld terminal can operate according to the following page flow: First, it starts and enters the login and on-duty sign-in page. After successful sign-in, it enters the main workbench page, which displays the current overall health of the battery swapping station and a list of pending work orders. Clicking on any pending work order leads to a rich text-based standard operating procedure (SOP) guide with step-by-step details. The maintenance worker operates step-by-step according to the step-by-step control and uploads photos. Finally, the handover is completed on the shift handover signature page. Data synchronization triggering conditions are divided into real-time event triggering, status change triggering, and reconnection triggering. Among them, real-time event triggering includes requests for help, sign-in, and confirmation of high-risk steps, which are reported immediately; status change triggering includes work order status changes, which are reconciled via local area network polling at preset intervals; reconnection triggering is when the network recovers from disconnection to online status, a full reconciliation and synchronization is automatically performed. Conflict handling follows an optimistic locking version stamp and state machine strong constraint mechanism. Data entities have an auto-incrementing version number and a last modification time. When a modification conflict occurs between the local and cloud, the version number is checked first. If the versions are inconsistent, the local data is rolled back and a conflict log is recorded. At the same time, if any work order has been marked as physically confirmed and closed, the state machine strong constraint prohibits its state from flowing backward to unprocessed, ensuring the irreversibility of business state and data consistency.
[0023] The inference layer, running on the edge computing device, is used to build a multi-model cache pool using the inference engine. Based on the multi-channel monitoring image stream and the multi-model cache pool, it realizes multi-scene model adaptive hot-swappable inference to obtain visual inference results. Based on the programmable logic controller status data, the visual inference results and the offline vector knowledge base, it realizes fault diagnosis and outputs diagnostic results and safety identification signals to the execution layer. In practice, the inference layer runs on the backend process of the local industrial control computer, utilizing the ONNX runtime to construct a multi-model cache pool. Specifically, in edge industrial control computers with limited video memory, a model session pool scheduling engine with hierarchical security locks is constructed to achieve adaptive hot-swappable inference of multi-scenario models. The multi-model cache pool includes two layers: a security control level model and an auxiliary job level model.
[0024] The security control-level model includes basic security models such as personnel intrusion detection, fire smoke detection, and fall detection. Upon startup, these models are allocated fixed resident GPU memory and subject to a strong, non-removable exclusive lock to prevent their computing resources from being monopolized under any computing power scheduling scenario. The auxiliary operation-level model includes scenario-assisted models that are invoked on demand, such as helmet wearing detection and physical dial reading. This level is dynamically managed by an activity-based cache pool. When a new model needs to be loaded and computing resource usage exceeds a warning level (e.g., total GPU memory usage exceeds 80%), the cache scheduling engine performs a traversal within the auxiliary operation-level model pool, hot-releasing the model handle with the lowest activity weight and performing garbage collection, thereby asynchronously mounting the new model's ONNX session with minimal latency. If computing resources are still insufficient after releasing all auxiliary operation-level models, the monopolization of security control-level model resources is prohibited. A hard circuit breaker is triggered, and a safety hover command is issued to the programmable logic controller (PLC) to forcibly stop physical mechanical actions and await station intervention, thus avoiding blind spots in local visual monitoring caused by improper computing power scheduling.
[0025] The activity retention weight of the auxiliary job-level model is obtained by normalizing and weighting the time difference factor from the last activation and the call frequency factor within the sliding time window. ,in, This is the time difference since the model was last activated. This represents the total frequency of calls within the sliding time window. The highest call frequency among all auxiliary models within the same time window. These are adjustable weighting coefficients with values ranging from (0,1). The time decay factor is then normalized. With frequency factor Unified to the (0,1] interval. In engineering, only a circular counting queue and timestamp need to be maintained in memory to achieve O(1) complexity calculation, which meets the low resource constraints of edge computing scenarios. It can be understood that, based on the activity retention weight, it is possible to identify auxiliary models that have not been called for a long time and release their resources first, so as to ensure the stable operation of the currently active scene model.
[0026] The inference layer also integrates a lightweight OCR character recognition engine for extracting physical instrument readings. To address environmental challenges such as high-brightness metallic reflections, dial stains, and oblique shooting within the battery swapping station, the OCR recognition engine has undergone algorithmic improvements. Specifically, these improvements include: suppressing large-area reflective noise in the input image using a contrast-limited adaptive histogram equalization algorithm; sharpening dial markings and digit edges by removing useless texture noise through Gaussian bilateral filtering; locating the circular outline of pointer-type instruments using Hough circle transform or extracting the boundary vertices of the LCD dial using Hough line transform; calculating the physical dial tilt angle and then using an affine transformation matrix to geometrically straighten the skewed image; and using a lightweight PP-OCRv4 model based on pruning and INT8 static quantization for OCR inference, compressing the model parameters by 75% without sacrificing accuracy.
[0027] The inference layer also utilizes an offline vector knowledge base to perform fault diagnosis, intent classification, and shift handover safety work order auditing. This offline vector knowledge base includes complete technical manuals for the battery swapping station, component manuals, PLC error code lookup dictionaries, standard operating procedure (SOP) maintenance guidelines (text and images), and historical typical fault Q&A pairs.
[0028] The construction process of the offline vector knowledge base can be specifically as follows: First, the physical maintenance document is segmented, and the mapping relationship between text and images is parsed; then, a sliding window with 20% overlap is used to slice the parsed text, with each slice limited to 500 characters; the text slices are converted into 384-dimensional high-dimensional floating-point feature vectors using a locally running BGE embedding model; a high-dimensional feature vector index space geometric tree is built in the industrial control computer memory based on the hierarchical navigation small-world HNSW algorithm, and persistently stored on the local disk to ensure high retrieval throughput. The offline vector knowledge base is constructed based on the approximate nearest neighbor index algorithm, that is, the hierarchical navigation small-world HNSW algorithm is used to achieve approximate nearest neighbor search.
[0029] The fault diagnosis employs a two-stage joint retrieval and reordering mechanism. The first stage is a coarse-grained recall stage, specifically using cosine similarity as a metric and HNSW indexing to quickly match the top-N candidate slices that are initially relevant in the offline vector knowledge base. The second stage is a fine-grained alignment stage, specifically, for the N candidate slices recalled in the coarse-grained stage, they are concatenated with the triggered device fault code query and fed into a locally deployed INT8 quantized cross-encoder. A deep self-attention mechanism is used to calculate the feature cross-matching score and reorder the slices, outputting the accurate top-K slices. It can be understood that this two-stage joint retrieval and reordering mechanism effectively filters out false alarms in the vector space that are literally similar but semantically contradictory. The retrieved top-K slices are fed into a local large model to complete inference and generate diagnostic results.
[0030] The inputs for the fault diagnosis include the currently triggered PLC fault code, real-time data, and the dial readings detected by the camera; the outputs include the fault probability distribution, potentially failed physical spare parts, and associated SOP index identifiers. The confidence score S of the diagnostic output belongs to the [0,1] interval, and the judgment threshold is set as follows: if S≥0.85, the automatic diverter is triggered to directly generate a work order and push the SOP; if 0.5≤S<0.85, it is judged as a suspected anomaly, the desktop floating component is switched to a yellow warning state, and a task is suspended on the handheld terminal to prompt on-site manual verification; if S<0.5, it is judged as a false alarm, and is filtered after being logged. It can be understood that through the above-mentioned graded judgment, it is possible to ensure that high-confidence faults are handled in a timely manner while avoiding interference from low-confidence false alarms to maintenance personnel.
[0031] The intent categories in the intent classification include: fault reporting, data query, equipment operation, vehicle owner assistance, staff handover, and system testing, etc. Intent classification accurately identifies the business type of interactive data, thereby triggering the corresponding processing flow.
[0032] The handover safety work order audit function is based on the following safety rules: there are no non-closed-loop equipment work orders with a priority of "urgent" or "critical" in the local safety database; the core steps of the high-risk SOP task being executed must include on-site video evidence; the incoming and outgoing shift personnel must complete two-way confirmation and account authentication via handheld terminal. If any of the above items fails the audit, a business process block is triggered, the sign-out instruction is intercepted, and a warning overlay is displayed on the front end, forcibly requiring the outgoing personnel to transfer the abnormal work order and make detailed notes; if unauthorized access is required, it must be unlocked by the cloud or the duty station manager through an authorization code, thereby preventing high-risk hazards from being blindly taken over.
[0033] The interaction layer is used to respond to vehicle arrival signals or authorization commands, triggering the switching between station maintenance and vehicle owner self-service modes. It reallocates system computing resources by unloading preset interface rendering components and pausing background data polling. In the station maintenance mode, it loads a state-aware interaction component to complete the anthropomorphic twin state mapping display of the station equipment. In the vehicle owner self-service mode, it releases graphics and video computing power to supply the local large model to realize vehicle owner self-diagnosis and natural language intelligent dialogue, and uploads the dialogue to the execution layer. In practice, the switching triggering methods between the station operation and maintenance status and the vehicle owner self-service customer service status include: automatic switching through business linkage, listening to the vehicle positioning status issued by the main control of the battery swapping station, and automatically switching to the vehicle owner self-service customer service status when the vehicle is detected to be in position or the front-end large screen is idle for a long time and triggers the screen protection mechanism; and manual switching by authorization, where maintenance personnel can switch back to the station operation and maintenance status by hiding the touch area on the screen or entering an authorization PIN code.
[0034] When the interaction layer switches to the owner self-service mode, the front-end router unloads heavy-load chart components and video streams and pauses background polling, freeing up computing power for the local large-scale intelligent agent and speech synthesis. Specifically, in the station maintenance mode, the front-end router loads a complex maintenance panel, consuming significant main thread resources to render data charts and maintaining high-frequency Web Socket or IPC data channels to display PLC operating conditions and multiple monitoring screens. After switching to the owner self-service mode, the front-end router unloads heavy-load large chart components and video streams and pauses unnecessary background polling. This effectively reduces the pressure on the user interface's main thread and frees up CPU usage, allowing computing power to be prioritized for the local large-scale intelligent agent and text-to-speech synthesis, resulting in smooth touch and voice playback when the owner engages in natural language conversations.
[0035] In station maintenance mode, the interaction layer loads a status-aware interaction component to complete the anthropomorphic twin status mapping display of the station equipment. This status-aware interaction component is a lightweight Web view component running on the top layer of the desktop, with adaptively adjustable transparency, built based on a borderless transparent window attribute. The interface layout includes: a central anthropomorphic dynamic image area, an outer ring of colored status indicator lights, and a scrolling bubble below displaying miniature text search or diagnostic information. The status information displayed by the status-aware interaction component includes the current battery swapping progress, search progress, current alarm rating, and communication heartbeat strength. In the current alarm rating, green indicates normal, yellow indicates moderate, and red indicates high risk. Regarding data binding, the front-end Web view directly subscribes to topics published by the local backend through an event listening mechanism, eliminating the overhead of traditional HTTP requests. When switching to the owner self-service customer service mode, the status-aware interaction component adaptively collapses, degenerating into a miniature persistent icon in the upper right corner, which can be clicked to call up a human agent.
[0036] The state-aware interactive component employs a state mapping logic based on a finite state machine to achieve multimodal anthropomorphic twin state mapping. It reduces the complex underlying operating conditions of the physical battery swapping station to specific expressions and actions of the front-end animated avatar. The finite state machine prioritizes events from highest to lowest as safety interruption events, inference events, and routine heartbeat events, triggering interface transitions between alarm, thinking, and idle states respectively. Specifically: safety interruption events have the highest priority, including fire alarms or intrusions triggered by the visual model, fatal fault reports from the PLC, or high-risk work orders with incomplete loops. If any of these conditions are met, the state-aware interactive component directly switches to alarm state, displaying an anxious animation and a high-frequency red breathing light, with an alarm message displayed in a bubble. Inference events have the next highest priority. When the component is retrieving information from the knowledge base or waiting for a response from a large model, it switches to thinking state, with a slow yellow flashing indicator light and a bubble indicating that the brain is working or retrieving information from the knowledge base. Regular heartbeat events have the default priority. If there are no alarms and no tasks are running, the front-end continues to listen for the back-end's 1Hz normal heartbeat packet, while the state-aware interactive component remains idle, playing random standby micro-effects. Understandably, through state mapping logic driven by a finite state machine, the operating status of the battery swapping station can be communicated to maintenance personnel in a real-time, intuitive, and human-like manner, improving human-machine interaction efficiency.
[0037] In the self-service customer service mode, the interaction layer releases graphics and video computing power to power the local large-scale model for owner self-diagnosis and natural language intelligent dialogue, and uploads the dialogue to the execution layer. The self-diagnosis covers fault types including vehicle parking misalignment, license plate damage recognition failure, incomplete payment deduction, battery locking mechanism failure, and battery swapping interruption. Diagnostic results are presented as full-screen red and green blocks and large-font fault cards, combined with voice synthesis from the central control panel to guide the owner. The intelligent dialogue is driven by the local large-scale model's intelligent agent engine, replacing the traditional intent parsing engine with the large-scale model's native tool calls and logical branching capabilities, enabling highly accurate natural language question answering and intent interception without requiring an internet connection. Regarding dialogue context maintenance, the conversation dictionary is permanently maintained with the vehicle's VIN code, owner account, vehicle model, and the current battery swapping step via a conversation token. In each interactive dialogue, this context is automatically injected into the system prompts of the local large-scale model, preventing the large-scale model from making ambiguous or hallucinatory responses due to being out of touch with the vehicle.
[0038] The execution layer is used to automatically generate corresponding level work orders based on the diagnostic results output by the inference layer, safety identification signals, and dialogues uploaded by the interaction layer, according to the hierarchical diversion rules; and to realize step-by-step synchronization of work instructions on handheld devices and step-by-step safety red line interlocking control based on the local area network. In practice, the execution layer automatically generates corresponding level work orders according to hierarchical routing rules. The system constructs a triangular decision tree to realize routing decisions. If the data source comes from the camera and the confidence level meets the danger category, such as detecting personnel intrusion into the action cabin, it is routed as a safety warning work order, with the level being emergency, triggering a full-screen flashing warning and vibration broadcast on the handheld device; if... Figure 4 As shown, if the data source is a PLC fault code, such as a motor overload fault code, it is routed as an equipment maintenance work order, classified as critical, and a rich text SOP is automatically generated and pushed down to the professional repairman's handheld terminal. If the data source is a vehicle owner's interactive help request on the large screen, it is routed as a customer service assistance work order, classified as medium, and pushed down to the duty station manager's mobile phone, triggering a call response. The handheld terminal displays the work order in a pop-up window in the form of a floating card, and the repairman can accept the order by swiping the card. After entering the repair state, the screen displays a standardized operation guide SOP with a physical disassembly schematic in a step-by-step wizard mode. Each operation requires physical checkmarking, and the repairman can directly click to take a photo at the corresponding step to upload evidence simultaneously.
[0039] Here, the Standard Operating Procedure (SOP) is based on a pre-processed Markdown offline knowledge base. It dynamically assembles rich text SOP cards suitable for mobile devices through an intelligent agent. Specifically, this includes: upon receiving a PLC fault code, a two-stage retrieval engine searches the knowledge base. Since the underlying maintenance manual has been pre-converted to Markdown format with image path anchors, it can recall maintenance paragraphs containing structural diagrams. The retrieved lengthy text blocks are then fed into a local large model. Structured prompts force the large model to filter irrelevant language, extracting a standardized JSON step array containing each troubleshooting action and its associated image path. The backend sends the generated JSON step flow to the handheld terminal, where the terminal framework automatically renders it into a single-column step-by-step guide card that fits the small screen width through responsive data binding. The standard card module includes: a fault phenomenon overview and red warning bar, a high-risk step safety interlock red line bar, a step-by-step operation process, and an area for evidence upload.
[0040] The execution layer uses a local area network (LAN) to implement step-by-step synchronization of work instructions on handheld devices and step-by-step safety red line interlocking control. Specifically, the host industrial control computer starts a WebSocket server that listens on the local LAN. After the handheld terminal scans the code to connect, it establishes a WebSocket subscription connection to synchronize the progress of the maintenance steps in real time. The specific safety conditions for the step-by-step safety red line interlocking control include: power safety red line, the high-voltage circuit voltage drops below 36V; anti-maloperation safety red line, the enable signals for the lifting machine and robotic arm motors returned by the PLC must be physically off; and personal intrusion prevention red line, the electromagnetic access control of the safety protection fence is in a locked state, and the signal returned by the infrared beam safety light curtain is in a continuously blocked trigger state.
[0041] The data acquisition layer is communicatively connected to the inference layer and the interaction layer, and the inference layer is communicatively connected to the execution layer.
[0042] This invention also provides a virtual collaborative management and control method for a battery swapping station, the method being used in the virtual collaborative management and control system for the battery swapping station described above, such as... Figure 4 As shown, it includes the following steps: Step S1: Collect programmable logic controller status data, multiple monitoring image streams, and on-site interactive data; In practice, the data acquisition layer can acquire PLC status data in real time via the Modbus TCP protocol and perform byte order adjustment according to the PLC hardware's end-to-end format. Simultaneously, multiple monitoring image streams are acquired through multiple network cameras deployed inside and outside the battery swapping station. A front-end Canvas pre-compression and downsampling mechanism can be used to scale and crop 1080P images to a standardized size before encoding them into Base64 byte streams for transmission, and a sliding time window circular queue is used for multi-frame synchronization. On-site interactive data, including on-site verification data, vehicle owner assistance data, personnel check-in data, and handover notes, can be collected via handheld terminals and interactive interfaces, encapsulated in JSON format and transmitted via WebSocket over TLS protocol.
[0043] Step S2: Utilize the inference engine to build a multi-model cache pool for multi-scenario adaptive hot-swappable inference, perform fault diagnosis based on the offline vector knowledge base, and output the diagnosis results; In practice, physical instrument readings can be extracted using adaptive histogram equalization with limited contrast, Gaussian bilateral filtering, Hough transform tilt correction, and a lightweight INT8 quantization model. The confidence score of the diagnostic results is graded according to a preset threshold: high confidence scores directly generate a work order and push a Standard Operating Procedure (SOP); medium confidence scores trigger manual verification prompts; and low confidence scores are judged as false alarms and logged.
[0044] Step S3: Switch between station maintenance status and vehicle owner self-service customer service status according to the running status and reallocate computing resources, and perform humanized twin status mapping through status-aware interaction components; Here, in the station maintenance state, a top-level persistent state-aware interaction component is loaded. Employing a finite state machine-based state mapping logic, events are prioritized from high to low as security blocking events, inference events, and regular heartbeat events. These trigger the interface transitions between alarm, thinking, and idle states, respectively, completing the anthropomorphic twin state mapping display of the station equipment. In the vehicle owner self-service state, the released computing power is supplied to the local large model to enable vehicle owner self-diagnosis and natural language intelligent dialogue. This dialogue is then uploaded to the execution layer, where a session token maintains the vehicle owner's identity and vehicle information context.
[0045] Step S4: Automatically route safety alarms or vehicle owner requests for help into work orders, and realize step-by-step synchronization of work instructions on handheld devices and step-by-step safety red line interlocking control based on the local area network.
[0046] In practice, the execution layer automatically generates work orders of corresponding levels according to the hierarchical routing rules. After the work order is generated, rich text SOP cards are dynamically assembled by an intelligent agent based on the pre-processed knowledge base and distributed to handheld terminals for step-by-step synchronous display.
[0047] In step S4, the step-by-step synchronization of the work instructions on the handheld device and the step-by-step safety red line interlocking control are realized based on the local area network, which specifically includes the following sub-steps: Step S41: In response to reaching a preset critical security step, trigger the interface locking mechanism of the handheld device; In practice, when maintenance reaches the safety red line step, such as physically disconnecting the main high-voltage power supply of the battery swapping station and hanging a warning sign, the next button on the handheld terminal is forcibly grayed out and locked to prevent the operator from bypassing the current safety step.
[0048] Step S42: Receive and verify the on-site physical status confirmation information from the handheld device and the electrical status telemetry information from the underlying control device; In practice, after physically disconnecting the power, the operator must use a handheld device to take a photo of the disconnected circuit breaker and confirm it on the device. The handheld device then transmits the confirmation command and photo data back to the host computer via the local area network. The host computer reads the PLC's telemetry status in real time via the Modbus TCP protocol, verifying whether the high-voltage circuit voltage in the corresponding register has dropped to the safe level of 36V. Simultaneously, it verifies whether the lift and robotic arm motor enable signals are physically off, whether the electromagnetic access control of the safety barrier is locked, and whether the infrared safety light curtain is in a continuously blocking trigger state.
[0049] Step S43: If both the physical status confirmation information and the electrical status telemetry information meet the preset security conditions, an unlocking command is generated and sent to the handheld device to allow the process to proceed to the next maintenance step.
[0050] In practice, once the on-site physical status confirmation information from the handheld device and the electrical status telemetry information from the host computer both pass verification, the host computer issues an access token via the local area network web server. Only then can the handheld device unlock and proceed to the next step. This is understandably designed to ensure the physical and electrical safety of maintenance personnel performing high-risk operations.
[0051] In step S4, the safety alarm or vehicle owner request for help is automatically routed into a work order task, which specifically includes the following sub-steps: Step S44: Based on preset event classification rules, analyze the collected multimodal data, determine the event type, and generate a work order of the corresponding level according to the event type; In practice, multimodal data from the data acquisition layer is analyzed, and event types are determined using a triangular decision tree: dangerous behaviors detected by cameras are routed as safety warning work orders, equipment anomalies triggered by PLC fault codes are routed as equipment maintenance work orders, and owner-interacted requests for help are routed as customer service assistance work orders. Different levels of work orders correspond to different response mechanisms and distribution channels, ensuring timely handling of various events.
[0052] Step S45: Perform compliance audit at key nodes in the work order flow; if a work order status that does not comply with the preset security policy is detected, trigger the business interception mechanism and block the current operation process until an authorization revocation instruction is received.
[0053] In practice, compliance audits cover key nodes in the work order flow, including work order creation, allocation, execution, and closure. Audit rules include: no unclosed emergency or critical equipment work orders; core safety red line steps for high-risk SOP tasks must include on-site photographic evidence; and shift handover requires two-way confirmation and account authentication. If a work order status that does not comply with the security policy is detected, the system triggers a business interception mechanism, blocking the current operation process, displaying a full-screen warning overlay on the front end, and requiring relevant personnel to handle the anomaly or remove the interception via an authorization code. The authorization removal command must be issued by the cloud or the on-duty station manager via an authorization code to ensure that the interception mechanism cannot be easily bypassed.
[0054] The virtual collaborative management and control method for the battery swapping station also includes network anomaly handling and data synchronization steps: monitoring the network connection status with the cloud management system; if a network outage occurs, local cache clearing is performed and the system enters offline autonomous mode; in offline autonomous mode, the operation of core business functions is maintained by utilizing the locally deployed intelligent diagnostic model and knowledge base; if the network connection is restored, a comparison of data differences between the local system and the cloud is performed, and bidirectional data synchronization and consistency verification are completed based on a preset strategy.
[0055] In practice, a lightweight background heartbeat detection system continuously monitors the connectivity of the cloud-based OMS. When the network is abnormally disconnected, it automatically switches to edge autonomous mode. In edge autonomous mode, all controls that heavily rely on real-time cloud data, such as real-time cloud spare parts inventory queries and global work order applications, are automatically grayed out on the front-end interface to prevent maintenance personnel from making incorrect maintenance decisions based on outdated cached data. For downlink data, the front-end forcibly clears the offline cache to avoid misoperation based on expired data. For uplink data, network interaction uses synchronous API calls, requests fail immediately, and a manual retry prompt is displayed. Locally generated large model diagnostic processes and fault handling records are preferentially written to the edge local data directory for archiving. It is understandable that, through the intelligent agent engine and offline vector knowledge base deployed locally at the edge, PLC fault self-diagnosis, SOP step-by-step maintenance wizard, and local work order records can still run even in a completely disconnected state. Once the network connection is restored, the front-end is unfurled, and the back-end incrementally synchronizes the work order logs and diagnostic records generated during the offline period to the cloud OMS through a silent queue. It also performs a comparison of data differences between the local and cloud environments, and completes bidirectional data synchronization and consistency verification based on a preset strategy to ensure data consistency.
[0056] To facilitate understanding of the technical solution of the present invention, the business process from multi-source data collection to work orders is described in detail below with a complete embodiment.
[0057] Example: PLC equipment fault alarm and linkage handling process.
[0058] In the daily operation of a certain battery swapping station, such as Figure 4 As shown, the PLC first reports an alarm indicating an abnormality detected by the bridge plate fully open detection sensor. The data acquisition layer captures this fault code in real time via the Modbus TCP protocol and transmits it to the inference layer. The inference layer initiates a two-stage joint retrieval based on an offline vector knowledge base, retrieving maintenance document slices associated with the fault code and generating diagnostic results by combining them with a local large model. If the diagnostic confidence score exceeds the 0.85 threshold, a work order is automatically triggered, generating an equipment maintenance work order and automatically assembling a rich text SOP card containing fault diagnosis suggestions and bridge plate limit sensor adjustment drawings.
[0059] At the same time, such as Figure 5 As shown, the state-aware interactive component of the interaction layer immediately responds to device-level abnormal events, switches the transparent floating state to an alarm animation, displays an anxious animation and a red high-frequency breathing light, and pops up a bubble and a voice synthesized broadcast to report alarm information.
[0060] During the preparation for maintenance and troubleshooting, such as Figure 6As shown, the station's camera captured footage of a worker attempting to cross a dangerous area on a bridge deck without a safety helmet. The safety control model in the inference layer, running at a high frame rate, instantly detected the suspected helmet-wearing anomaly. To prevent false alarms from traditional small visual models, the inference layer extracted the anomaly frame and verification prompts and fed them into a local multimodal large model for secondary cross-validation using deep semantics. After the large model confirmed the violation, the state-aware interaction component triggered a higher-priority safety blocking event to overlay a warning and broadcast a severe warning message.
[0061] After the on-duty personnel double-click the status awareness interactive component to open the draft work order, they add a colloquial description of the fault in the phenomenon supplement column based on on-site observations. Then, they click "One-click Improvement," and the local large model integrates the manual description with the underlying machine alarm data to generate more comprehensive and targeted troubleshooting suggestions, and outputs a structured and standardized ledger to compensate for the diagnostic blind spots caused by purely machine data.
[0062] After receiving an order on the handheld terminal, the maintenance operator enters the SOP guidance page in step-by-step wizard mode. When the maintenance reaches the step of physically disconnecting the main high-voltage power supply to the power swapping station and hanging the safety red line of the warning sign, the "Next" button on the handheld terminal is forcibly grayed out and locked. After physically disconnecting the power, the operator uses the handheld terminal to take a picture of the disconnected circuit breaker and check the confirmation box. The handheld terminal sends the confirmation command and photo back to the host computer via the local area network. The host computer reads the PLC telemetry status via the Modbus TCP protocol and verifies that the high-voltage circuit voltage has dropped below 36V. After both verifications pass, the host computer issues a pass token, the handheld terminal page unlocks, and the operator proceeds to the next maintenance step. After the maintenance is completed, a safety work order audit is performed during shift handover. When all critical work orders have been processed and high-risk steps have been documented, the shift handover and check-out can be completed.
[0063] This invention can be an apparatus, method, and / or computer program product. A computer program product may include a readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of the invention.
[0064] Storage media can be tangible devices that hold and store instructions for use by instruction execution devices. Storage media can include, but are not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof.
[0065] It should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This way of describing the specification is only for clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.
[0066] The detailed descriptions listed above are merely specific descriptions of feasible embodiments of the present invention, and are not intended to limit the scope of protection of the present invention. All equivalent embodiments or modifications made without departing from the spirit of the present invention should be included within the scope of protection of the present invention.
Claims
1. A virtual collaborative management and control system for a battery swapping station, characterized in that, include: The data acquisition layer is used to collect real-time status data of the programmable logic controllers of the battery swapping station, multiple monitoring image streams, and on-site interactive data. The inference layer, running on the edge computing device, is used to build a multi-model cache pool using the inference engine. Based on the multi-channel monitoring image stream and the multi-model cache pool, it realizes multi-scene model adaptive hot-swappable inference to obtain visual inference results. Based on the programmable logic controller status data, the visual inference results and the offline vector knowledge base, it realizes fault diagnosis and outputs diagnostic results and safety identification signals to the execution layer. The interaction layer is used to respond to vehicle positioning signals or authorization commands, triggering the switching between station maintenance and vehicle owner self-service status. It reallocates system computing resources by unloading preset interface rendering components and pausing background data polling. In the station maintenance status, it loads status-aware interaction components to complete the anthropomorphic twin status mapping display of the station equipment. In the self-service customer service mode for car owners, the computing power of graphics and video is released to supply the local large model to realize the self-diagnosis of car owners and natural language intelligent dialogue, and the dialogue is uploaded to the execution layer; The execution layer is used to automatically generate corresponding level work order tasks according to the hierarchical and diversion rules based on the diagnostic results output by the inference layer, security identification signals, and dialogues uploaded by the interaction layer. It also enables step-by-step synchronization of work instructions on handheld devices and step-by-step safety red line interlocking control based on the local area network; The data acquisition layer is communicatively connected to the inference layer and the interaction layer, and the inference layer is communicatively connected to the execution layer.
2. The virtual collaborative management and control system for a battery swapping station according to claim 1, characterized in that, The multi-model cache pool includes a security control level model and an auxiliary job level model. The security control level model resides on computing resources. The auxiliary job level model is dynamically cached based on its activity level and weight. When a new model needs to be loaded and the computing resource usage exceeds the warning level, the auxiliary job level model with the lowest weight is released. If the computing resources are still insufficient after releasing all auxiliary job level models, the use of security control level model resources is prohibited, a hard circuit breaker is triggered, and a safety hover command is issued to the programmable logic controller.
3. The virtual collaborative management and control system for a battery swapping station according to claim 2, characterized in that, The activity retention weight is obtained by normalizing and weighting the time difference factor from the last activation and the call frequency factor within the sliding time window.
4. The virtual collaborative management and control system for a battery swapping station according to claim 1, characterized in that, The offline vector knowledge base is constructed based on the approximate nearest neighbor index algorithm; the fault diagnosis adopts a two-stage joint retrieval and reordering mechanism. In the first stage, candidate slices are recalled by cosine similarity through the approximate nearest neighbor index. In the second stage, the candidate slices and the triggered device fault code query are sent to the local cross encoder for deep semantic matching and reordering, and the diagnosis results are output.
5. The virtual collaborative management and control system for a battery swapping station according to claim 1, characterized in that, When the interaction layer switches to the owner self-service customer service mode, the heavy-load chart components and video streams are unloaded through the front-end routing and the background polling is paused, so that the freed computing power is allocated to the local large model intelligent agent and speech synthesis.
6. The virtual collaborative management and control system for a battery swapping station according to claim 1, characterized in that, The state-aware interaction component adopts state mapping logic based on finite state machine, and the events are security blocking events, reasoning events and regular heartbeat events in order of priority from high to low, which trigger the interface transition between alarm state, thinking state and idle state respectively.
7. A virtual collaborative management and control method for a battery swapping station, the method being used in the virtual collaborative management and control system for a battery swapping station as described in any one of claims 1 to 6, characterized in that, Includes the following steps: S1: Acquires programmable logic controller status data, multiple monitoring image streams, and on-site interactive data; S2: Utilize the inference engine to build a multi-model cache pool for multi-scenario adaptive hot-swappable inference of models, perform fault diagnosis based on the offline vector knowledge base, and output the diagnosis results. S3: Based on the operating status, it switches between the station maintenance status and the vehicle owner self-service customer service status and reallocates computing resources, and performs human-like twin state mapping through the state-aware interaction component; S4: Automatically route safety alarms or vehicle owner requests for help into work orders, and realize step-by-step synchronization of work instructions on handheld devices and step-by-step safety red line interlocking control based on local area network.
8. The virtual collaborative management and control method for a battery swapping station according to claim 7, characterized in that, In step S4, the step-by-step synchronization of the work instructions on the handheld device and the step-by-step safety red line interlocking control are implemented based on the local area network, specifically including: S41: In response to reaching a preset critical security step, trigger the interface locking mechanism of the handheld device; S42: Receive and verify on-site physical status confirmation information from the handheld device and electrical status telemetry information from the underlying control device; S43: If both the physical status confirmation information and the electrical status telemetry information meet the preset safety conditions, an unlocking command is generated and sent to the handheld device to allow the process to proceed to the next maintenance step.
9. The virtual collaborative management and control method for a battery swapping station according to claim 7, characterized in that, In step S4, the safety alarm or vehicle owner request for help is automatically routed into a work order task, specifically including: S44: Based on preset event classification rules, analyze the collected multimodal data, determine the event type, and generate a work order of the corresponding level according to the event type; S45: Perform compliance audits at critical points in the work order process; if a work order status that does not comply with the preset security policy is detected, trigger the business interception mechanism and block the current operation process until an authorization revocation instruction is received.
10. The virtual collaborative management and control method for a battery swapping station according to claim 7, characterized in that, It also includes network anomaly handling and data synchronization steps: monitoring the network connection status with the cloud management system; if a network outage occurs, local cache is cleared and offline autonomous mode is entered; in offline autonomous mode, the operation of core business functions is maintained by utilizing locally deployed intelligent diagnostic models and knowledge bases; if the network connection is restored, data difference comparison between local and cloud is performed, and bidirectional data synchronization and consistency verification are completed based on preset strategies.
