Microscopic interactive teaching terminal based on double-process isolation and control method thereof
By adopting a dual-process isolation architecture in the interactive microscopy teaching system, image acquisition and uploading are handled independently. Combined with shared memory and hardware layer switching, the stuttering and stability issues of the single-process architecture are solved, resulting in a highly stable and fast-switching microscopy teaching terminal suitable for embedded platforms.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HUNAN SANY HEZHONG TECHNOLOGY CO LTD
- Filing Date
- 2026-04-13
- Publication Date
- 2026-07-03
AI Technical Summary
In existing interactive microscopy teaching systems, the single-process architecture leads to interface lag, switching delays, screen flickering, poor stability, and resource contention issues, which affect the students' observation experience.
The system employs a dual-process isolation architecture, separating image acquisition and uploading into two independent processes. Through shared memory and hardware layer switching mechanisms, it ensures that the displayed content is not affected by the upload process. An independent daemon process monitoring and recovery mechanism is used to achieve system stability and fast switching.
It greatly enhances the student observation experience, has high system stability, fast switching, no black screen delay, supports multi-channel concurrent upload, and is suitable for interactive teaching terminals on various embedded platforms, especially for high real-time microscopy teaching scenarios.
Smart Images
Figure CN122332149A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of educational informatization and embedded systems technology, and more specifically, to a microscopic interactive teaching terminal based on dual-process isolation and its control method. Background Technology
[0002] With the development of educational informatization, digital interactive microscopy teaching systems have gradually become the mainstream equipment for laboratory teaching in biology, medicine, and other fields. A typical interactive microscopy system includes one teacher terminal and multiple student terminals. Teachers can broadcast their own microscope images to all students via the network and can also view the microscope images of any student, thus achieving interactive teaching.
[0003] Student-side devices typically employ a single-process architecture, meaning that image acquisition, encoding, network transmission, and screen display are all handled by the same process. This architecture has the following drawbacks: 1. Mutual interference: When teachers view students' screens, students need to simultaneously capture, encode, upload, and display images locally, which can easily lead to interface lag, switching delays, or even screen flickering or brief blackouts, affecting students' observation.
[0004] 2. Poor stability: An anomaly in a single module (such as network upload) may cause the entire system to crash and fail to display local images.
[0005] 3. Resource contention: Image acquisition and display share the same set of hardware encoding and decoding resources, which can easily lead to conflicts under high load (such as simultaneous broadcasting and uploading), causing screen tearing or frame drops.
[0006] Therefore, there is an urgent need for a microscopic interactive teaching terminal and its control method based on dual-process isolation to solve the above problems. Summary of the Invention
[0007] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a microscopic interactive teaching terminal and its control method based on dual-process isolation. The display and uploading processes are completely decoupled. Through dual-process isolation, the content displayed on the student screen is not affected by the teacher's access to the uploaded content, avoiding the stuttering and flickering problems of traditional single-process architectures, greatly improving the student's observation experience. The system of the present invention has high stability; the two processes run independently, and the crash of one process does not affect the other, and the daemon process can automatically recover, ensuring continuous system availability. The switching response of the present invention is rapid; based on hardware layer switching and shared memory mechanisms, the broadcast and local switching time is less than 200ms, with no black screen and no delay. The network resources of the present invention are optimized; the uploading process uses an independent process, which can be flexibly scheduled according to teacher instructions, supporting multi-channel concurrency without affecting the reception and display of the broadcast stream. The present invention has strong applicability and can be widely applied to various interactive teaching terminals based on embedded platforms, especially suitable for microscopic teaching scenarios with high real-time requirements, to solve the problems mentioned in the background art.
[0008] To achieve the above objectives, the present invention provides the following technical solution: a microscopic interactive teaching terminal based on dual-process isolation, comprising a hardware layer and a software layer: The hardware layer includes a main control chip, an image sensor, a display screen, a wireless communication module, a storage module, and a power management module. The main control chip is a Hisilicon Hi3516DV300 / 500, which integrates an ARM Cortex-A7 processor, an H.265 codec, a MIPI CSI interface, and a MIPI DSI interface. The image sensor is a Sony IMX335, connected to the main control chip via a MIPI CSI interface. The display screen is a 10.1-inch 1920×1200 IPS touchscreen, connected to the main control chip via a MIPI DSI interface. The wireless communication module is a Realtek RTL8852BS WiFi6 module, connected to the main control chip via an SDIO interface. The storage module is an eMMC 5.1 16GB. The storage module is used to store system firmware, user data, and calibration parameters; The power management module is used to provide a stable voltage supply; The software layer runs on top of the hardware layer. The software layer includes a first process and a second process that are independent of each other, as well as an optional daemon process. The first process is set as a data acquisition and uploading process, and the second process is set as a display control process. The acquisition and upload process is responsible for acquiring real-time image data from the image sensor, encoding and compressing it, and uploading the encoded image stream via the wireless network according to the teacher's instructions. The acquisition and upload process is independent of the display screen, and its running status does not affect the content displayed on the display screen. The display control process is responsible for receiving multicast streams broadcast from the teacher's end, decoding them, and displaying them on the display screen. At the same time, when there is no broadcast, it retrieves local preview images from the shared memory area for display. The display control process is independent of the upload behavior, and its display content is not affected by the upload task of the first process. The daemon process is used to monitor the running status of the first and second processes, and automatically restarts the process if either process exits abnormally, ensuring the continuous availability of the system.
[0009] In a preferred embodiment, the first process and the second process transfer local preview images through shared memory. Specifically, the first process writes the original image or thumbnail captured by the image sensor into the shared memory area, and the second process reads image data from the shared memory and displays it when there is no broadcast. The semaphore mechanism ensures mutual exclusion of the two processes' access to the shared memory and avoids data conflicts.
[0010] In a preferred embodiment, the second process automatically switches the display source according to the network reception status. When a multicast broadcast stream initiated by the teacher is detected, the second process immediately switches to the broadcast stream decoding display mode, and the display screen displays the teacher's image. When the broadcast stream stops or times out, the second process automatically switches back to the local preview mode, reads the image from the shared memory and displays it. The switching process is achieved through hardware layer switching, and the switching time is less than 200ms, ensuring no black screen and no flicker.
[0011] In a preferred embodiment, the uploading behavior of the first process is completely independent of the display behavior of the second process. The teacher controls the first process to start or stop uploading via instructions. During the uploading process, the first process continuously unicasts the encoded image stream to the teacher. Regardless of whether the first process is uploading, the second process displays the current content normally, which is either the teacher's screen or a local preview. The two do not interfere with each other. The first process supports multi-channel concurrent uploading. When the teacher simultaneously views multiple student screens, the first process of each student screen uploads independently without affecting each other.
[0012] In a preferred embodiment, the daemon periodically checks the heartbeat status of the first process and the second process. If the first process or the second process does not respond for more than a set threshold (the threshold is set to 5 seconds), the daemon forcibly terminates the process and restarts it. After restarting, the system automatically returns to the broadcast or local preview state without manual intervention.
[0013] A control method for a microscope interactive teaching terminal based on dual-process isolation, comprising the microscope interactive teaching terminal based on dual-process isolation as described above and the following steps: Step 1: The software system is built on the Linux 4.9 kernel and is divided into three independent processes. The first process is the acquisition and upload process. When the first process starts, it initializes the image sensor, sets the acquisition resolution to 2592×1944 (5 million pixels), and the frame rate to 15fps. It acquires the raw image data through the V4L2 framework and sends it to the hardware encoder for H.265 compression. The output bitrate is controlled between 2-4Mbps. The encoded image stream is written to a local circular buffer for storage (such as for photo and video recording functions) and uploaded via unicast through the network module according to the teacher's instructions. At the same time, the first process reduces the raw image to a 640×480 preview image and writes it to the shared memory area (allocated by mmap) for the second process to read. To ensure data consistency, a semaphore (sem_t) is used for synchronization. Step Two: The second process is the display control process. After starting, the second process creates two display layers: layer 0 for local preview and layer 1 for broadcast display. Layer 0 is displayed by default. The process also creates a UDP multicast receiving thread to listen for the teacher's broadcast address (e.g., 239.0.0.1:1234). When a multicast stream is received, the second process starts the hardware decoder, outputs the decoded image directly to layer 1, and switches to layer 1 for display via the display driver, thus displaying the teacher's image. At the same time, it stops reading the local preview from shared memory. If no broadcast keyframe is received for one second, the broadcast is considered to have ended, and the process switches back to layer 0 to display the local preview. During local preview, the second process periodically reads the preview image from shared memory and displays it via hardware overlay. The refresh rate is consistent with the frame rate captured by the first process (15fps). Step 3: The daemon process, as a child process of init, is responsible for monitoring the first and second processes. Each process periodically (e.g., every 2 seconds) sends a heartbeat message to the daemon process. If no heartbeat is received for 3 consecutive times, the daemon process first sends a SIGTERM signal to attempt normal termination. If there is still no response after 5 seconds, it forces SIGKILL and then re-forks and starts the process. The daemon process is also responsible for collecting exception logs and reporting them to the teacher's end over the network for remote diagnosis.
[0014] The technical effects and advantages of this invention are as follows: This invention completely decouples display and upload processes. Through dual-process isolation, the content displayed on the student screen is not affected by the teacher's access to the upload, avoiding the stuttering and flickering problems of traditional single-process architectures, greatly improving the student's observation experience. The system boasts high stability, with the two processes running independently; the crash of one process does not affect the other, and the daemon process can automatically recover, ensuring continuous system availability. Switching response is rapid; based on hardware layer switching and shared memory mechanisms, the broadcast and local switching time is less than 200ms, with no black screen and no delay. Network resources are optimized; the upload uses an independent process that can be flexibly scheduled according to teacher instructions, supporting multi-channel concurrency without affecting the reception and display of broadcast streams. This invention has strong applicability and can be widely applied to various interactive teaching terminals based on embedded platforms, especially suitable for microscopy teaching scenarios with high real-time requirements. Attached Figure Description
[0015] Figure 1 This is a hardware architecture block diagram of the student terminal of the present invention.
[0016] Figure 2 This is a software module architecture diagram of the student terminal of the present invention.
[0017] Figure 3 This is a schematic diagram of the dual-process communication and data flow of the present invention.
[0018] Figure 4 This is a flowchart of the display switching control of the present invention.
[0019] Figure 5 This is a flowchart of the daemon process monitoring process of the present invention. Detailed Implementation
[0020] 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, and 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.
[0021] As attached Figure 1 Appendix Figure 2 Appendix Figure 3 Appendix Figure 4 and attached Figure 5 As shown, this invention provides a microscopic interactive teaching terminal based on dual-process isolation, comprising a hardware layer and a software layer: The hardware layer includes a main control chip, an image sensor, a display screen, a wireless communication module, a storage module, and a power management module. The main control chip is a Hisilicon Hi3516DV300 / 500, which integrates an ARM Cortex-A7 processor, an H.265 codec, a MIPI CSI interface, and a MIPI DSI interface. The image sensor is a Sony IMX335, connected to the main control chip via a MIPI CSI interface. The display screen is a 10.1-inch 1920×1200 IPS touchscreen, connected to the main control chip via a MIPI DSI interface. The wireless communication module is a Realtek RTL8852BS WiFi6 module, connected to the main control chip via an SDIO interface. The storage module is an eMMC 5.1 16GB. The storage module is used to store system firmware, user data, and calibration parameters; The power management module is used to provide a stable voltage supply; The software layer runs on top of the hardware layer. The software layer includes a first process and a second process that are independent of each other, as well as an optional daemon process. The first process is set as a data acquisition and uploading process, and the second process is set as a display control process. The acquisition and upload process is responsible for acquiring real-time image data from the image sensor, encoding and compressing it, and uploading the encoded image stream via the wireless network according to the teacher's instructions. The acquisition and upload process is independent of the display screen, and its running status does not affect the content displayed on the display screen. The display control process is responsible for receiving multicast streams broadcast from the teacher's end, decoding them, and displaying them on the display screen. At the same time, when there is no broadcast, it retrieves local preview images from the shared memory area for display. The display control process is independent of the upload behavior, and its display content is not affected by the upload task of the first process. The daemon process is used to monitor the running status of the first and second processes, and automatically restarts the process if either process exits abnormally, ensuring the continuous availability of the system.
[0022] The first process and the second process transfer local preview images through shared memory. Specifically, the first process writes the original image or thumbnail captured by the image sensor into the shared memory area, and the second process reads the image data from the shared memory and displays it when there is no broadcast. The semaphore mechanism ensures that the two processes have mutually exclusive access to the shared memory and avoids data conflicts.
[0023] The second process automatically switches the display source according to the network reception status. When a multicast broadcast stream initiated by the teacher is detected, the second process immediately switches to the broadcast stream decoding display mode, and the display screen displays the teacher's image. When the broadcast stream stops or times out, the second process automatically switches back to the local preview mode, reads the image from the shared memory and displays it. The switching process is achieved through hardware layer switching, and the switching time is less than 200ms, ensuring no black screen and no flicker.
[0024] The uploading behavior of the first process is completely independent of the display behavior of the second process. The teacher controls the first process to start or stop uploading through commands. During the uploading process, the first process continuously unicasts the encoded image stream to the teacher. Regardless of whether the first process is uploading, the second process displays the current content normally, which is either the teacher's screen or a local preview. The two do not interfere with each other. The first process supports multi-channel concurrent uploading. When the teacher views multiple student screens at the same time, the first process of each student screen uploads independently without affecting each other.
[0025] The daemon process periodically checks the heartbeat status of the first and second processes. If the first or second process does not respond for more than a set threshold (set to 5 seconds), the daemon process forcibly terminates the process and restarts it. After restarting, the system automatically returns to the broadcast or local preview state without manual intervention.
[0026] A control method for a microscope interactive teaching terminal based on dual-process isolation, comprising the microscope interactive teaching terminal based on dual-process isolation as described above and the following steps: Step 1: The software system is built on the Linux 4.9 kernel and is divided into three independent processes. The first process is the acquisition and upload process. When the first process starts, it initializes the image sensor, sets the acquisition resolution to 2592×1944 (5 million pixels), and the frame rate to 15fps. It acquires the raw image data through the V4L2 framework and sends it to the hardware encoder for H.265 compression. The output bitrate is controlled between 2-4Mbps. The encoded image stream is written to a local circular buffer for storage (such as for photo and video recording functions) and uploaded via unicast through the network module according to the teacher's instructions. At the same time, the first process reduces the raw image to a 640×480 preview image and writes it to the shared memory area (allocated by mmap) for the second process to read. To ensure data consistency, a semaphore (sem_t) is used for synchronization. Step Two: The second process is the display control process. After starting, the second process creates two display layers: layer 0 for local preview and layer 1 for broadcast display. Layer 0 is displayed by default. The process also creates a UDP multicast receiving thread to listen for the teacher's broadcast address (e.g., 239.0.0.1:1234). When a multicast stream is received, the second process starts the hardware decoder, outputs the decoded image directly to layer 1, and switches to layer 1 for display via the display driver, thus displaying the teacher's image. At the same time, it stops reading the local preview from shared memory. If no broadcast keyframe is received for one second, the broadcast is considered to have ended, and the process switches back to layer 0 to display the local preview. During local preview, the second process periodically reads the preview image from shared memory and displays it via hardware overlay. The refresh rate is consistent with the frame rate captured by the first process (15fps). Step 3: The daemon process, as a child process of init, is responsible for monitoring the first and second processes. Each process periodically (e.g., every 2 seconds) sends a heartbeat message to the daemon process. If no heartbeat is received for 3 consecutive times, the daemon process first sends a SIGTERM signal to attempt normal termination. If there is still no response after 5 seconds, it forces SIGKILL and then re-forks and starts the process. The daemon process is also responsible for collecting exception logs and reporting them to the teacher's end over the network for remote diagnosis.
[0027] This invention's software system is built on the Linux 4.9 kernel and consists of three independent processes. The first process is the acquisition and upload process. When the first process starts, it initializes the image sensor, sets the acquisition resolution to 2592×1944 (5 megapixels), and the frame rate to 15fps. It acquires raw image data through the V4L2 framework, sends it to a hardware encoder for H.265 compression, and controls the output bitrate to 2-4Mbps. The encoded image stream is written to a local circular buffer for storage (e.g., for photo / video recording functions) and uploaded via unicast through the network module according to the teacher's instructions. Simultaneously, the first process reduces the original image to a 640×480 preview image and writes it to a shared memory area (allocated by mmap) for the second process to read. To ensure... Data consistency is achieved using semaphores (sem_t) for synchronization. The second process is the display control process. After starting, the second process creates two display layers: layer 0 for local preview and layer 1 for broadcast display. Layer 0 is displayed by default. The process simultaneously creates a UDP multicast receiving thread to listen for the teacher's broadcast address (e.g., 239.0.0.1:1234). When a multicast stream is received, the second process starts the hardware decoder, directly outputting the decoded image to layer 1. The display driver then switches to layer 1 for display, enabling the teacher's screen to be shown. Simultaneously, it stops reading the local preview from shared memory. If no broadcast keyframe is received for one second, the broadcast is considered complete, and the process switches back to layer 0 to display the local preview. During this process, the second process periodically reads preview images from shared memory and displays them via hardware overlay, maintaining a refresh rate consistent with the frame rate captured by the first process (15fps). The daemon process, a child process of init, monitors both the first and second processes. Each process periodically (e.g., every 2 seconds) sends a heartbeat message to the daemon process. If no heartbeat is received three times consecutively, the daemon process first sends a SIGTERM signal to attempt normal termination. If there is still no response after 5 seconds, it forces a SIGKILL and then re-forks and restarts the process. The daemon process is also responsible for collecting exception logs and reporting them to the teacher's end over the network for remote diagnosis. This invention completely decouples display and uploading; through dual-process isolation, the content displayed on the student screen is not subject to teacher access to the uploaded content. This invention avoids the stuttering and flickering issues of traditional single-process architectures, greatly improving the student observation experience. The system boasts high stability, with two processes running independently; a crash in one process does not affect the other, and the daemon process can automatically recover, ensuring continuous system availability. Switching response is rapid, based on hardware layer switching and shared memory mechanisms, with broadcast and local switching time less than 200ms, eliminating black screens and delays. Network resources are optimized; uploading uses an independent process that can be flexibly scheduled according to teacher instructions, supporting multi-channel concurrency without affecting broadcast stream reception and display. This invention is highly adaptable and can be widely applied to various interactive teaching terminals based on embedded platforms, especially suitable for microscopy teaching scenarios with high real-time requirements.
[0028] Example 1 The teacher began broadcasting. The teacher initiates a multicast broadcast stream. The multicast receiving thread of the second process detects the arrival of the stream and immediately switches to layer 1 to display the teacher's screen (e.g., ...). Figure 4 (As shown).
[0029] The first process remains unaffected; continue collecting, encoding, and uploading (if needed by teachers).
[0030] Example 2 Teachers stop broadcasting The teacher stops sending multicast streams, and the second process determines that the broadcast has ended after a 1-second timeout, switches back to layer 0, and displays the local preview.
[0031] Example 3 Teachers view student images The teacher sends a command to the first process, requesting that the upload be started. The first process unicasts the encoded H.265 stream to the teacher. At this time, the second process may be displaying the teacher's screen or a local preview, and is unaffected by the upload.
[0032] Example 4 The first process crashed abnormally. If the daemon process does not receive a heartbeat from the first process, it restarts the first process. The first process reinitializes the sensors and encoders and resumes shared memory writing. The second process is temporarily unable to obtain the preview image, displaying the last frame or a black screen. After the first process recovers, the local preview is displayed normally (e.g., ...). Figure 5 (As shown).
[0033] In other embodiments, the main control chip can adopt compatible solutions such as the Guoke GK7205V300 and Junzheng T31; the image sensor can adopt OV5640, SC5235, etc.; the wireless module can adopt MT7921, AP6275S, etc.; and the operating system can be other embedded Linux versions or RTOS. Any technical solution that uses dual-process isolation to decouple display and upload is within the scope of protection of this invention.
[0034] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A micro-interactive teaching terminal based on dual-process isolation, characterized in that, Includes hardware and software layers: The hardware layer includes a main control chip, an image sensor, a display screen, a wireless communication module, a storage module, and a power management module. The main control chip is a Hisilicon Hi3516DV300 / 500, which integrates an ARM Cortex-A7 processor, an H.265 codec, a MIPI CSI interface, and a MIPI DSI interface. The image sensor is a Sony IMX335, connected to the main control chip via a MIPI CSI interface. The display screen is a 10.1-inch 1920×1200 IPS touchscreen, connected to the main control chip via a MIPI DSI interface. The wireless communication module is a Realtek RTL8852BS WiFi6 module, connected to the main control chip via an SDIO interface. The storage module is an eMMC 5.1 16GB. The storage module is used to store system firmware, user data, and calibration parameters; The power management module is used to provide a stable voltage supply; The software layer runs on top of the hardware layer. The software layer includes a first process and a second process that are independent of each other, as well as an optional daemon process. The first process is set as a data acquisition and uploading process, and the second process is set as a display control process. The acquisition and upload process is responsible for acquiring real-time image data from the image sensor, encoding and compressing it, and uploading the encoded image stream via the wireless network according to the teacher's instructions. The acquisition and upload process is independent of the display screen, and its running status does not affect the content displayed on the display screen. The display control process is responsible for receiving multicast streams broadcast from the teacher's end, decoding them, and displaying them on the display screen. At the same time, when there is no broadcast, it retrieves local preview images from the shared memory area for display. The display control process is independent of the upload behavior, and its display content is not affected by the upload task of the first process. The daemon process is used to monitor the running status of the first and second processes, and automatically restarts the process if either process exits abnormally, ensuring the continuous availability of the system.
2. The microscopic interactive teaching terminal based on dual-process isolation according to claim 1, characterized in that: The first process and the second process exchange local preview images via shared memory.
3. The microscopic interactive teaching terminal based on dual-process isolation according to claim 1, characterized in that: The second process automatically switches the display source based on the network reception status.
4. The microscopic interactive teaching terminal based on dual-process isolation according to claim 1, characterized in that: The upload behavior of the first process is completely independent of the display behavior of the second process.
5. A microscope interactive teaching terminal based on dual-process isolation according to claim 1, characterized in that: The daemon periodically checks the heartbeat status of the first and second processes.
6. A control method for a microscopic interactive teaching terminal based on dual-process isolation, characterized in that, Includes a dual-process isolated interactive microscopy teaching terminal as described in any one of claims 1-5, and the following steps: Step 1: The software system is built on the Linux 4.9 kernel and is divided into three independent processes. The first process is the acquisition and upload process. When the first process starts, it initializes the image sensor, sets the acquisition resolution to 2592×1944, the frame rate to 15fps, acquires the raw image data through the V4L2 framework, sends it to the hardware encoder for H.265 compression, and controls the output bit rate to 2-4Mbps. The encoded image stream is written to the local circular buffer for storage and uploaded via unicast through the network module according to the teacher's instructions. At the same time, the first process reduces the raw image to a 640×480 preview image and writes it to the shared memory area for the second process to read. To ensure data consistency, semaphores are used for synchronization. Step Two: The second process is the display control process. After the second process starts, it creates two display layers: layer 0 for local preview and layer 1 for broadcast display. Layer 0 is displayed by default. The process also creates a UDP multicast receiving thread to listen for the teacher's broadcast address. When the multicast stream is received, the second process starts the hardware decoder and outputs the decoded image directly to layer 1. It then switches to layer 1 for display through the display driver to realize the teacher's screen display. At the same time, it stops reading the local preview from shared memory. If no broadcast keyframe is received for 1 second, it is considered that the broadcast has ended, and it switches back to layer 0 to display the local preview. During local preview, the second process periodically reads the preview image from shared memory and displays it through hardware overlay. The refresh rate is consistent with the frame rate of the first process. Step 3: The daemon process, as a child process of init, is responsible for monitoring the first and second processes. Each process periodically sends heartbeat messages to the daemon process. If no heartbeat is received for three consecutive times, the daemon process first sends a SIGTERM signal to attempt normal termination. If there is still no response after 5 seconds, it forces SIGKILL and then re-forks and starts the process. The daemon process is also responsible for collecting exception logs and reporting them to the teacher's end over the network for remote diagnosis.