Abstract: This paper analyzes the specific requirements for simulation of well logging robot operations and designs a method combining virtual well database and well logging signals to achieve virtual simulation of the well logging environment. Depth signals are selected as the driving signals for the simulation system, and an embedded processor system is used as the core to construct the overall structure of the simulation system and design the virtual simulation workflow. Based on this, a specific implementation scheme for the virtual simulation system is proposed, focusing on the design and implementation of key modules. Keywords: Virtual Real-Time Simulation, Robot, ARM9, FPGA Abstract: This paper analyzes the requirements of oil well robot simulation and combines the suppositional well database with the oil well logging signal in the design to achieve the simulation of the oil well environment. The depth signal is chosen as the drive signal of the simulation system. Through analyzing the signal transmission mechanism of the simulation system, the ensemble architecture of the simulation system is constructed, with the embedded processor as the coin. The working process of the simulation system is designed. Based on this, the realization scheme of the virtual reality simulation system is proposed. The system hardware is also provided in this paper. Keywords: Virtual real-time simulation, robot, ARM9, FPGA 1 Introduction Well logging is a high-risk and highly technical field operation, requiring highly skilled operators who must undergo rigorous training and be certified before starting work. Traditional operator training only involves theoretical learning and on-site observation during well operations, resulting in long training times and poor effectiveness. Therefore, developing a virtual simulation system for logging robots is of great significance for promoting the application of logging robots, enabling functional and performance analysis of the entire surface system indoors, solving the training problem for operating engineers, and allowing surface system commissioning and operation personnel to have an immersive experience in the laboratory. This also has good economic and social benefits. 2. Introduction to the Simulation System's Working Process A logging robot system consists of a surface system, a cable telemetry system, a depth measurement system, and downhole instruments. The surface system is the core of the entire system for data processing and control. Under the operation and control of the operating engineer, the surface system receives measurement data from the downhole instruments transmitted by the cable telemetry system and depth signals from the depth system, processes this information, and displays and records the logging data and results. Simultaneously, the operator's operating instructions and system commands are transmitted to the downhole instruments via the telemetry system for control. Every simulation study should begin with a description of the system under study. Only with a deep understanding of the system, a clear understanding of the problems to be solved and the goals to be achieved, and consensus reached with decision-makers on these issues, can a reliable foundation be provided for simulation modeling and simulation operation. In actual logging operations, the operator controls the surface system and first configures a service table consistent with the selected downhole instrument. This service table configuration initializes the downhole instrument and initiates the isochronous logging process. At this point, both the cable telemetry system and the downhole instrument are lowered into the wellbore and rapidly descend within the wellbore. At regular intervals, the surface system's DSP acquisition module automatically sends acquisition commands to the downhole instrument. The downhole instrument acquires and stores a set of logging data. After a short, fixed interval, the DSP acquisition module automatically sends a data upload command to the downhole instrument. The downhole instrument and telemetry system then transmit the stored logging data back to the surface logging system. The surface system uses this logging data to determine if the downhole instrument's descent is obstructed. Once the downhole instrument is at the bottom of the well, the operator controls the surface winch to slowly raise the cable and initiates the isochronous logging process on the surface system. During isobathing logging, at regular depth intervals, the DSP acquisition module of the surface system automatically sends acquisition commands to the downhole instrument. The downhole instrument acquires and stores a set of logging data. After a short, fixed interval, the DSP acquisition module automatically sends a data upload command to the downhole instrument. The downhole instrument and the remote transmission system then transmit the stored logging data back to the surface logging system. During isobathing logging, a large amount of logging data reflecting the physical properties of the formation rocks is acquired and processed by the surface system to obtain the corresponding logging results. 3 System Overall Design Scheme Logging operations are all related to the actual depth at which the downhole instrument is located during logging. All logging signals are logging information at that depth; therefore, the entire simulation system should be synchronized under the drive of the depth signal. In the logging system, the depth signal is generated by a depth measuring device called a "Martindike," which works by using a measuring wheel to drive an optical encoder, which generates 1280 pulses per meter. By measuring these pulses, the depth of the instrument and the speed of its movement can be determined. Therefore, it is necessary to design a depth signal generation circuit similar to this depth signal. The 1280 m/meter depth signal output by this circuit drives the surface system and simultaneously drives the simulation system to output logging signals at the corresponding depth of the virtual well. The logging signals received by the surface system are logging signals transmitted via cable from the cable telemetry system. Each telemetry system has its own encoding scheme. The robot system simulated in this paper adopts the LDT telemetry system scheme, which includes WTS bus and 3506 and 3508 modes. Based on the above analysis, the simulation system must have interfaces for the depth system and the LDT cable telemetry system, a virtual downhole data database, and be controlled and processed by a control core. Since there are some auxiliary signals in addition to the logging signals mentioned above, such as cable tension and magnetic symbols, the overall structure of the simulation system is shown in Figure 1. [align=center]Figure 1: System Structure Diagram[/align] Different logging projects have different logging data and organization formats. At the start of the simulation, the surface system configures a service table, and the simulation equipment receives the corresponding command, determines the type of logging project, and selects the project if the storage device contains data for that project, sends a depth signal, and immediately enters the isochronous logging working state. If the project data is not available, a report should be output to notify the operation engineer to download the corresponding data. When downloading data, the operator needs to connect the communication interface to the host computer and download the required data into the simulation equipment's storage system through the host computer. If the simulation equipment determines that the data is logging data, it automatically receives it and saves it as the corresponding file. The storage device supports power-off save functionality and can store logging data for a long time. After the simulation equipment enters the isochronous logging working state, the operator can simulate logging operations. The operator can simulate cable car operation through the human-machine interface, select the logging speed, and the simulation equipment outputs the corresponding depth pulse signal. The depth pulse is output to the surface processing system, which sends acquisition and upload commands based on this pulse, and the simulation equipment sends the isochronous logging data according to the commands. Upon reaching the appropriate depth, the operator controls the simulation instrument to slowly raise the cable and operates the SL-6000 surface processing equipment to begin isobathing logging operations. The simulation equipment receives commands from the surface processing system and responds in real time, outputting simulated logging signals. The operator can change the logging speed at any time via the human-machine interface until the surface processing equipment stops logging operations. Under the influence of the simulated signal source, the surface system, like actual logging, can record, display, store, and output logging results. Its logging data can be compared with standard data, which can determine the performance of the surface processing system and evaluate the operator's operation. 4 Implementation of Key Modules 4.1 Design of Control Module The maximum data rate transmitted by the logging robot is 230Kb/s. The simulation equipment must not only provide such a large amount of data but also simultaneously support human-machine interaction devices (such as displays, touch screens, keyboards, etc.) and store data. This requires the selected controller to meet the overall performance requirements in terms of speed, memory management unit (MMU), cache, pipeline, etc. When the depth pulses in the simulation system reach the counting requirement, all relevant logging signals must be generated promptly to ensure consistency between the logging signals and the corresponding depths of the downhole instruments. Otherwise, errors will occur in the simulation experiment, and excessive errors will lead to the failure of the entire simulation process. This requires the system to provide strong real-time performance assurance, which places demands on the selection of the control module. Designing the control module using a CPU chip is time-consuming and labor-intensive, increasing the design difficulty and extending the design cycle. Therefore, the existing ARM general-purpose control module board was adopted. The ARM general-purpose board uses the S3C2410X processor, which integrates an ARM920T core, implementing an MMU, a five-stage integer pipeline, an AMBA bus, and a Harvard Cache architecture. It has a maximum frequency of 203MHz, adopts a low-power design, and, in conjunction with a real-time operating system, can effectively ensure the real-time performance of the system. The chip integrates general-purpose peripherals such as an SD card interface, a USB interface, a touch screen interface, and an LCD controller, greatly reducing the need for external components, the board area, and the design workload. On the other hand, Samsung provides relatively complete documentation, including schematics of the minimum system and basic peripherals, and test programs for various peripherals for reference, facilitating software and hardware development. Debugging can be performed using a JTAG-based debugging system, allowing access to system and kernel states without running the corresponding program on the target system. Breakpoints can also be set in RAM and ROM programs, making debugging convenient. The ARM general-purpose board is only the size of a business card, using only low-power devices, significantly reducing the power consumption and size of the instrument, while also simplifying structural design. 4.2 Implementation of the Communication Module Currently, competitive communication interfaces include USB, Ethernet, and 1394. The 1394 interface offers the best performance but has a high hardware cost, currently only used in high-end applications. USB and Ethernet are widely used, low-cost, and reliable. Based on the selection of the ARM general-purpose board, available communication methods include UART (Universal Asynchronous Receiver/Transmitter), Ethernet, and USB 1.1 (Universal Serial Bus). UART technology is simple, mature, and reliable, but the UART controller has poor performance. Ethernet connections offer high reliability and transmission speeds up to 10Mbps and 100Mbps, making them suitable for large data transfers. They also boast long communication distances; a standard twisted-pair network can achieve a connection range of 150m, and with repeaters, even greater distances can be achieved, making them an indispensable part of the underlying links in today's internet. Furthermore, the USB bus offers advantages such as low cost, good compatibility, powerful functionality, ease of use, easy expansion, and plug-and-play support, and is widely adopted, although its communication distance should not exceed 3m. Based on the above analysis, the simulation equipment employs both Ethernet and USB communication methods. The Ethernet interface facilitates communication between the simulation equipment and the ground processing system. The simulation robot internally uses a 10/100M adaptive switch, with a communication rate of 100Mbps with the host computer. Therefore, the network interface of the simulation equipment also utilizes a 100M network controller, the DM9000, which can download 500MB of data in just tens of seconds, meeting the speed requirements. The DAVICOM DM9000 network controller is a 10/100M adaptive single-chip Ethernet controller. It integrates a MAC layer controller, a PHY layer controller, and an on-chip 4K dword SRAM cache. It supports 8-bit, 16-bit, and 32-bit microprocessor interfaces, as well as an MII interface. It features a low-power design, an operating temperature range of 0–85°C, and 5V withstand voltage on its I/O pins. It is packaged in an LQFP100 surface-mount package. The DM9000 has three different configuration modes: default mode, I/O pin-limited mode, and EEPROM mode. The priority of the three modes is as follows: EEPROM mode has the highest priority, followed by I/O pin-limited mode, and default mode has the lowest priority. In EEPROM mode, the DM9000's configuration information is stored in an external serial EEPROM. Upon system power-on reset, the DM9000 automatically reads the configuration information via the SPI interface. In IO pin-defined mode, the DM9000's configuration information (including bus width, IO base address, interrupt polarity, etc.) is determined by the level of specific pins, completed during system power-on reset. Each specific pin has a built-in 60KΩ pull-down resistor, defaulting to a low potential (default mode). In this project, the default mode is chosen to facilitate the initialization configuration process, eliminating the need for a dedicated ROM and reducing design complexity. This design uses the default configuration mode, a 16-bit data bus, assigns address 0x86000000 for accessing the address port, assigns address 0x86000004 for accessing the data port, and assigns INT9 as the DM9000 interrupt input port. Figure 2 shows the DM9000 hardware interface circuit. [align=center]Figure 2: DM9000 Interface Schematic[/align] 4.3 Implementation of the Human-Machine Interface Module The human-machine interface module needs to have command reception and status display functions. For ease of operation, keyboard, mouse, and other input methods were not selected in the design. Knob, button, and other operation methods have poor flexibility and are not conducive to functional expansion, so they were not used in the design. The human-machine interface composed of an LCD and a touch screen has a compact structure and reliable performance, making it a more suitable choice. The S3C2410 integrates a touch screen interface and an LCD controller, which greatly simplifies the hardware design, enhances reliability, and reduces the instrument size. The LCD screen includes three types: customized display, character display, and full-image display. For flexible display, a full-image display LCD screen was selected. The integrated LCD controller supports STN LCD and TFT LCD, and supports LCD screens of various sizes. Considering LCD performance and equipment appearance and assembly, a TFT LCD screen V16C6448AC manufactured by E Ink Holdings Co., Ltd. of Taiwan was selected. It is 6.4 inches, full-color, with viewing angles of 15/35 (L/R), 55/55 (U/D), and a resolution of 640×480. The touchscreen is a popular four-wire resistive touchscreen, known for its reliable performance and 6.4-inch size, matching the LCD screen. The LCD controller sends video data and generates necessary control signals, primarily including REGBANK, LCDCDMA, TIMEGEN, and VIDPRCS. REGBANK configures the controller to match the LCD panel. TIMEGEN generates LCD control signals such as VSYNC, HSYNC, VCLK, and VDEN. LCDCDMA is a dedicated DMA that automatically transfers video data from the frame storage area to the LCD driver, independent of CPU intervention. VIDPRCS receives data from LCDCDMA, converts it to a suitable format, and sends it to the LCD driver. 5. Summary The innovation of this paper is that a physical-based real-time simulation mechanism was adopted, successfully building a hardware simulation platform using the ARM9 S3C2410 processor and FPGA as the core. The writing and debugging of the low-level driver and upper-level software programs were implemented, enabling virtual simulation experiments for well logging projects. After testing, the system can comprehensively simulate and model the performance of the ground system according to the actual engineering operation process of the robot. References: [1] Ma Zhongmei, Xu Yinghui. ARM Embedded Processor Architecture and Application Fundamentals. Beijing: Beijing University of Aeronautics and Astronautics Press [2] Zeng Fantai, Chen Meijin. VHDL Programming. Beijing: Tsinghua University Press, 2003 [3] Hao Liguo, Wang Yudong et al. Research on Service Robots Based on CPLD and MCU Networks. Beijing, Microcomputer Information, 2005. No. 10-2 [4] Huang Tianmiao. Embedded System Design and Example Development. Beijing: Tsinghua University Press, 2002