Equipment time calibration methods, devices, equipment, storage media and program products

Abstract

This application discloses a device time correction method, apparatus, device, storage medium, and program product, relating to the field of embedded technology. The method, applied to embedded devices, includes: starting a time correction service via a local configuration file when the device boots up, and setting it as a prerequisite service for business services to ensure that business services start subsequently; calling the time correction service to perform corresponding time correction operations: if the hardware detection information of the real-time clock module indicates a hardware fault or absence, then performing anomaly detection on the current system time; if the current system time is abnormal, correcting the system time using a target time generated and pre-configured based on device batch information. This time correction scheme does not rely on an external network, is automated and timing-controllable, and based on a local time source, enables embedded devices to achieve time self-correction in offline deployment environments, ensuring time consistency and the reliability of business functions even without a network.

Description

Technical Field

[0001] This application relates to the field of embedded technology, and in particular to a device time correction method, apparatus, device, storage medium, and program product. Background Technology

[0002] In the field of embedded hardware, to effectively control costs, reduce device size, and achieve low-power operation, a large number of Linux devices, such as industrial control boards and IoT modules, without equipped with real-time clock (RTC) hardware modules, have been widely used. After these devices are powered on and started, the system time will revert to the operating system's factory default value (e.g., 1970), which will lead to a series of problems such as incorrect device operation log time, failure of mass production test cases due to time anomalies, and applications that rely on timers failing to start normally. Therefore, it is necessary to correct the system time of the devices.

[0003] Currently, most time correction solutions for devices without RTC focus on multi-device synchronization scenarios in network environments, implemented through general script patterns. However, these solutions are difficult to meet the needs of industrial-grade embedded devices, especially in offline deployment scenarios without network connectivity. They suffer from numerous defects, such as lack of a reliable time source; inability to accurately distinguish whether the device is not equipped with an RTC module or whether the RTC module has a hardware failure, which can easily lead to misjudgments and increase maintenance costs; and disconnection between business programs and time correction timing, resulting in program abnormalities or invalid test data.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a device time correction method, apparatus, device, storage medium, and program product, which aims to solve the technical problem that existing time correction schemes cannot meet the time correction requirements of industrial-grade embedded devices in offline deployment scenarios without network connectivity.

[0006] To achieve the above objectives, this application proposes a device time correction method applied to embedded devices, the device time correction method comprising:

[0007] When the device starts up, the time correction service is started using a local configuration file;

[0008] Configure the time correction service as a prerequisite service for the business service; the business service starts after the time correction service is executed.

[0009] Invoke the time correction service and perform the corresponding time correction operation;

[0010] The time correction operation includes:

[0011] Obtain hardware detection information from the real-time clock module;

[0012] If the hardware detection information indicates that the real-time clock module is missing or in a faulty state, an anomaly detection is performed on the current system time.

[0013] If the current system time is determined to be abnormal, the current system time is corrected by a pre-configured target time; the target time is generated based on the batch information of the embedded device.

[0014] In one embodiment, the step of configuring the time correction service as a prerequisite service for the business service includes:

[0015] The service configuration file is identified from the local configuration file; the service configuration file includes at least the configuration file for the time correction service and the configuration file for the business service;

[0016] By using the operating system's process management mechanism, dependency configuration information for the time correction service is added to the configuration file of the business service, configuring the dependency relationship between the time correction service and the business service; the dependency relationship indicates that the time correction service is a prerequisite service for the business service.

[0017] The dependency configuration information includes at least mandatory dependency parameters and sequence control parameters; the mandatory dependency parameters are used to prevent the business service from entering the startup process if the time correction service is not started or fails to start; the sequence control parameters are used to restrict the business service from triggering the startup process after the one-time execution task of the time correction service is completed.

[0018] In one embodiment, before the step of invoking the time correction service and performing the corresponding time correction operation, the method further includes:

[0019] Configure read and write permissions for the configuration file of the time correction service;

[0020] The user who owns the configuration file for the time correction service and the execution permission are granted to the highest-privilege user of the operating system.

[0021] In one embodiment, the step of detecting anomalies in the current system time includes:

[0022] Extract the year information of the current system time;

[0023] The year information is compared with a preset judgment threshold to detect anomalies in the current system time.

[0024] In one embodiment, after the step of correcting the current system time using a pre-configured target time, the method further includes:

[0025] The corrected target system time is obtained, and anomaly detection is performed on the target system time to verify the time correction result.

[0026] If the verification is successful, a prompt message indicating successful correction will be output, and if the hardware detection information indicates that the real-time clock module exists, the target system time will be synchronized to the real-time clock module.

[0027] If the verification fails, a correction failure message will be output, the time correction service will be exited with a preset error code, and a correction failure record will be generated.

[0028] In one embodiment, the device time correction method further includes:

[0029] During the execution of the time correction operation, log information is generated in a preset format at each execution stage; the log information includes at least the device identifier of the embedded device, the execution stage, the execution timestamp, and the execution result; the execution stage includes a hardware detection stage, a time detection stage, and a time correction stage.

[0030] The log information is written to a local log file to form a traceable record.

[0031] Furthermore, to achieve the above objectives, this application also proposes a device time correction device for use in embedded devices, the device time correction device comprising:

[0032] The service startup module is used to start the time correction service using a local configuration file when the device starts up;

[0033] The dependency configuration module is used to configure the time correction service as a prerequisite service for the business service; the business service is started after the time correction service is executed.

[0034] The time correction module is used to call the time correction service and perform the corresponding time correction operation;

[0035] The time correction module is specifically used for:

[0036] Obtain hardware detection information from the real-time clock module;

[0037] If the hardware detection information indicates that the real-time clock module is missing or in a faulty state, an anomaly detection is performed on the current system time.

[0038] If the current system time is determined to be abnormal, the current system time is corrected by a pre-configured target time; the target time is generated based on the batch information of the embedded device.

[0039] In addition, to achieve the above objectives, this application also proposes an embedded device, the embedded device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the device time correction method as described above.

[0040] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the device time correction method described above.

[0041] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the device time correction method described above.

[0042] One or more technical solutions proposed in this application have at least the following technical effects:

[0043] When the device starts, a time correction service is initiated via a local configuration file. This ensures that time correction is an automated, built-in step in the device startup process, requiring no manual intervention or external triggering, thus laying the foundation for the deployment and operation of embedded devices in offline scenarios. The time correction service is configured as a prerequisite service for business services, forcing business services to start only after the time correction service has completed its execution. This enforces the sequential order of time correction and business program startup at the system service management level, ensuring that the system time has been corrected when business services start. This avoids business logic errors, test failures, or invalid logs caused by time discrepancies, guaranteeing the reliability of device functionality in offline scenarios.

[0044] During the time correction operation, by acquiring hardware detection information from the real-time clock module, the time correction processing logic is focused on scenarios where the real-time clock module is absent or in a faulty state. This solves the problem of the device lacking a reliable external time source in scenarios without network connectivity. Combined with anomaly detection of the current system time and correction of the system time using a pre-configured target time generated based on the device's batch information, the system can make and execute time correction decisions based solely on the device's own state, even with a network connection. This solves the problem of a lack of a reliable time source in offline scenarios, ensuring that the device can still obtain a unified, known, and relatively reasonable time benchmark in a network-isolated environment. This makes log timestamps readable and comparable, and allows the device's business programs to operate normally based on the corrected time.

[0045] By implementing an automated, timing-controllable time correction scheme based on a local preset time source that does not rely on external networks, embedded devices can achieve time self-correction in offline environments without network connectivity. This effectively solves a series of problems caused by the lack of a reliable time source, inability to distinguish clock hardware status, and timing chaos in existing solutions when deployed offline, enabling devices to ensure time consistency and business function reliability even without network conditions. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is one of the flowcharts provided for an embodiment of the device time correction method of this application;

[0049] Figure 2 This is the second flowchart illustrating an embodiment of the device time correction method of this application.

[0050] Figure 3 Another flowchart illustrating an embodiment of the device time correction method of this application;

[0051] Figure 4 This is a schematic diagram of the module structure of the device time correction device in an embodiment of this application;

[0052] Figure 5This is a schematic diagram of the hardware operating environment involved in the device time correction method in the embodiments of this application.

[0053] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0054] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0055] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0056] For existing time correction schemes, there are at least the following drawbacks for industrial scenarios with offline deployment and no network:

[0057] Hardware status misjudgment: The lack of hardware self-test and fault differentiation of the real-time clock module makes it impossible to effectively distinguish between the two situations: the device itself does not have a real-time clock module and the real-time clock module is faulty. This can easily lead to technicians misjudging hardware problems, thereby increasing maintenance costs.

[0058] Insufficient time synchronization stability: Lacking a reliable time source, and lacking mechanisms for permission verification, abnormal retry, and result verification, time synchronization has a high failure rate in complex industrial scenarios with low memory and small storage in embedded systems.

[0059] Lack of timing linkage: The lack of a mandatory dependency between timing correction and business / test programs can easily lead to timing misalignment issues where business / test programs start first and timing correction executes later, resulting in abnormal application operation or invalid test data.

[0060] The execution process is not traceable: There is a lack of traceable records of the entire process information of device hardware status and time correction, which makes it difficult to meet the standardized and traceable management requirements of mass production testing of embedded devices.

[0061] Based on this, this application provides a solution for industrial deployment scenarios of embedded devices without real-time clocks or network connections. Through the integrated design of trusted offline time source configuration, real-time clock hardware self-test, abnormal time closed-loop correction, strong service timing linkage, and full-link traceable logs, the solution achieves automatic time synchronization after the device is powered on, while ensuring lightweight and low resource consumption. This solves technical problems such as hardware status misjudgment, low time synchronization stability, timing discrepancies, and lack of traceability, while meeting the dual requirements of stand-alone offline operation and mass production testing.

[0062] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or embedded device capable of performing the above functions. The following description uses an embedded device as an example to illustrate this embodiment and the subsequent embodiments.

[0063] This application provides a device time correction method, applicable to embedded devices, particularly suitable for devices with embedded operating system kernels that lack network connectivity and real-time clock (RTC) hardware. By embedding a self-contained, highly reliable, and time-sensitive time correction mechanism into the device startup process, it ensures that all business services after device startup can start and run on a reliable time reference.

[0064] Specifically, refer to Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the device time correction method of this application.

[0065] In this embodiment, the device time correction method includes steps S10 to S30:

[0066] Step S10: When the device starts up, start the time correction service through the local configuration file;

[0067] Step S20: Configure the time correction service as a prerequisite service for the business service; the business service starts after the time correction service is executed.

[0068] Step S30: Invoke the time correction service and perform the corresponding time correction operation.

[0069] Furthermore, the time correction operation in step S30 includes steps S301 to S303:

[0070] Step S301: Obtain hardware detection information of the real-time clock module;

[0071] Step S302: If the hardware detection information indicates that the real-time clock module is missing or in a faulty state, perform anomaly detection on the current system time.

[0072] Step S303: If it is determined that the current system time is abnormal, the current system time is corrected by a pre-configured target time; the target time is generated based on the batch information of the embedded device.

[0073] First, during device startup, a time correction service is initiated via a local configuration file, establishing an automated time correction execution entry point that is activated during the operating system startup phase. The local configuration file refers to a system-level start / stop script or configuration document stored in the embedded device's non-volatile memory (such as Flash or eMMC). Its content typically includes the service's execution path, running permissions, and environment parameters, and can automatically initiate the time correction process during the device's power-on initialization phase.

[0074] In practice, for devices managed by systemd, automatic startup can be achieved by creating a .service file in the / etc / systemd / system directory.

[0075] As another feasible implementation, for older or minimalist embedded systems that do not have systemd installed (such as systems using SysVinit or BusyBox init), the initialization script mechanism of the embedded operating system can be utilized. The local configuration file can be specifically configured as the initialization script located in the initialization directory " / etc / init.d / ", and a very high startup priority can be given by setting a small numerical sequence number in the system's boot level configuration. Alternatively, when the device is pre-installed with process management tools such as Supervisor, the local configuration file can be configured as the conf.d configuration section of Supervisor, setting the parameters autostart=true and priority=1, thereby achieving the automatic wake-up of the time correction service at the initial stage of device startup without relying on systemd.

[0076] Specifically, an initialization script named "fix-time" can be created in the embedded device's initialization directory " / etc / init.d / ". This script contains standard functions such as start, stop, and status query. By creating a symbolic link pointing to this script in the runlevel directory " / etc / rcN.d / " (where N is the default runlevel, such as 3 or 5), and naming it S99fix-time (where S represents start and 99 specifies a higher start priority), the time correction script can be executed after the system enters multi-user mode and before other application services start. The local configuration file refers to the initialization script and its symbolic link in the runlevel directory. Its function is to define the service startup rules and priorities, ensuring that time correction occupies an appropriate and predictable timing position in the device startup sequence.

[0077] sysfs is a unified view provided by the kernel to user space for viewing and managing devices, drivers, and modules within the kernel. The ` / sys / class / ` directory organizes all device categories in the system by device function. ` / etc / rcN.d / ` is the directory in SysVinit used to define system runlevels and service startup order. Each number N corresponds to a runlevel (e.g., 3 represents multi-user text mode, 5 represents multi-user graphical interface). Each ` / etc / rcN.d / ` directory contains symbolic links to the actual scripts in the ` / etc / init.d / ` directory. The ` / etc / init.d / ` directory stores SysVinit initialization scripts for system services. These scripts are typically called initialization scripts or service scripts and include standard commands such as `start`, `stop`, `restart`, and `status` for manually controlling or managing system background services. The control script for the time correction service is configured in this directory, simulating a system service that can be managed via the standard `service` command or by directly calling scripts.

[0078] Then, the time correction service is configured as a prerequisite service for the business service. This is key to resolving the timing discrepancy problem, aiming to enforce a startup order constraint from the system service management level. As a feasible implementation, a scripted lock file or signal file mechanism can be used to configure service dependencies.

[0079] Specifically, in the initialization script, after the time correction service completes its execution, it creates a specific flag file in a predefined directory (such as / var / run / ), for example, / var / run / fix-time.done. Simultaneously, all critical business service startup scripts (which can also be initialization scripts) check for the existence of this flag file at the start of their own startup logic. If the file does not exist, the business service script enters a loop waiting state, checking periodically (e.g., every second) until the file is detected as created, before continuing to execute its own business startup logic.

[0080] By configuring the dependencies between services, business services can be forced to wait for the time correction service to complete. The configuration is reflected in the check logic embedded in the business service startup script, without relying on the dependency declaration of the external service manager. Its purpose is to ensure that business logic that depends on the correct system time will not be triggered before the time correction action is completed.

[0081] The forced timing linkage between the pre-dependent services and the business services after the time correction is completed is to prevent the business applications or mass production test scripts in the embedded device from running prematurely in the event of a system time error, thereby avoiding invalid data or business logic chaos.

[0082] In systems using systemd, this dependency can be implemented using the Requires and After parameters. As an alternative implementation, when the system does not support advanced service dependency management, a "proactive polling blocking mechanism based on a state lock file" can be used to implement this forced timing. Specifically: after the time correction service completes all time synchronization operations, it proactively generates a specific status flag file (e.g., / tmp / time_fixed.lock) in the system's volatile directory (e.g., / tmp or / var / run / ); simultaneously, at the top of the startup script of the core business service, a piece of proactive polling code (e.g., using a while loop to periodically check if the lock file exists) is injected; if the file does not exist, the business startup script proactively suspends (Sleep) and enters a waiting state until the time correction process creates the lock file, at which point the business service breaks the loop and continues executing subsequent startup logic, thus achieving a completely equivalent forced decoupling and control of timing at the application level.

[0083] After the dependency relationship between the time correction service and the business service is configured, the time correction service is called to perform the corresponding time correction operation. The time correction operation includes multiple execution stages, specifically hardware detection, time detection and time correction.

[0084] Specifically, refer to Figure 2 The execution process of the time correction service, as shown, involves first acquiring hardware detection information from the real-time clock module. This accurately identifies the basic state of the device's clock hardware, providing a basis for subsequent correction strategies. Hardware detection information can be a query of the operating system's underlying hardware clock interface. For example, the `hwclock` command can be used to perform hardware clock status checks, clearly distinguishing between the absence of the real-time clock module and a hardware failure. In other words, the hardware detection information is from the operating system's underlying device driver node or kernel logs, including hardware device identifiers, presence status bits, or driver error codes. Its purpose is to accurately distinguish whether the device is currently "designed without a real-time clock module" or "has a module but has experienced a hardware failure."

[0085] In another implementation, the sysfs (system file system) interface exposed by the system kernel is read programmatically. For example, it can be checked whether the virtual file system directory " / sys / class / rtc / " exists and its content. It can be understood that if this directory is empty or does not exist, it usually indicates that no RTC hardware is detected; if there is a corresponding device directory under this directory, then the specific files (such as device node files) under this directory can be tried to be read to detect the hardware status; if an I / O error is returned during the read operation, it may indicate a hardware failure. The content of the hardware detection information is the comprehensive determination result of the "existence status", "accessibility status" and "health status" of the device RTC hardware, and its function is to distinguish the two subsequent processing different (such as whether to attempt synchronization) hardware statuses of "the device has no RTC hardware" and "the RTC hardware is damaged". This direct way of reading device nodes avoids the call overhead of heavy Shell commands, has higher execution efficiency, and is more suitable for embedded microcontroller devices with extremely limited resources.

[0086] Furthermore, if the hardware detection information indicates that the real-time clock module does not exist or is in a fault state, an anomaly detection is performed on the current system time to judge the credibility of the current software system time. As a feasible implementation, the method of verifying the rationality of the timestamp range is adopted. The system time can be the Unix timestamp of the operating system obtained by calling system programming APIs such as gettimeofday or time (for example, the number of seconds since January 1, 1970). An effective timestamp range can be preset. For example, the Unix timestamp corresponding to the device production date is used as the lower limit T_min, and the Unix timestamp corresponding to a reasonable period in the future (such as 10 years later) is used as the upper limit T_max. If the obtained current timestamp T_curr satisfies T_curr < T_min or T_curr > T_max, it is determined that the system time is abnormal. This method can more flexibly and accurately identify abnormal situations such as system clock reset (resulting in T_curr being much smaller than T_min) or serious jumps (resulting in T_curr being much larger than T_max). Or, an absolute timestamp corresponding to a calibrated time threshold is preset in advance (for example, setting January 1, 2020 as the threshold, corresponding to the timestamp 1577836800); the obtained current system timestamp is compared with this threshold timestamp in terms of numerical size; if the current system timestamp value is less than the threshold timestamp, it is accurately determined that the current system time is abnormal.

[0087] In the case of determining that the current system time is abnormal, the current system time is corrected by the pre-configured target time, and the pre-configured target time is generated based on the batch information of the embedded device, aiming to provide a reliable, consistent time reference for the device that does not rely on an external network.

[0088] One feasible implementation involves reading the target time from a read-only configuration file or metadata in a specific partition on the device. The target time can be obtained during device firmware building or mass production by writing a standardized time (e.g., 2025-06-01 00:00:00) to the device's ` / etc / factory_time.conf` configuration file or U-Boot environment variable based on the planned production / delivery date for that batch of devices. The time correction service reads this time string from this fixed location during execution. The target time is an absolute time point in the format "YYYY-MM-DD HH:MM:SS". Its purpose is to serve as a unified and predictable correction anchor point in offline scenarios when the device itself cannot obtain the correct time. This ensures that all devices in the same batch have the same or similar starting time after correction, which is crucial for log correlation analysis and batch device management. During correction, this pre-configured target time is written to the system kernel by calling the `settimeofday` or `date -s` command.

[0089] The batch information for embedded devices can originate from the factory's Manufacturing Execution System (MES), including the expected production year, batch number, or preset deployment date for that batch of embedded devices. The target time is a fixed, formatted time data (such as "2026-01-01" or a corresponding second-level timestamp) derived from the batch information. This target time is pre-written as a read-only constant into the device image during the device's firmware flashing stage. This provides the system with the most reasonable baseline time point when the device is in an absolutely isolated state without any external network communication capabilities or hardware RTC assistance, ensuring that the logs generated by the device have a relatively reasonable order and traceability on the timeline.

[0090] When performing time calibration, another feasible implementation method is to use the `date -s` command. Alternatively, high-level programming languages ​​such as C, C++, or Python can be used to directly inject and overwrite the target time structure (such as a `timespec` structure) generated based on batch information into the kernel's system time memory pool by calling system kernel APIs such as `settimeofday` or `clock_settime(CLOCK_REALTIME, ×pec)`. This implementation method not only avoids strong dependence on the shell runtime environment, but also the modification process occurs in the system kernel mode, resulting in faster calibration speed, stronger atomicity, and significantly improved time calibration success rate of devices in industrial environments.

[0091] In this embodiment, a time correction service is started via a local configuration file during device startup. This ensures that time correction is an automated, built-in step in the device startup process, requiring no manual intervention or external triggering, thus laying the foundation for the deployment and operation of embedded devices in offline scenarios. Configuring the time correction service as a prerequisite service for business services forces business services to start only after the time correction service has completed its execution. This enforces the sequential order of time correction and business program startup at the system service management level, ensuring that the system time has been corrected when business services start. This avoids business logic errors, test failures, or invalid logs caused by time discrepancies, guaranteeing the reliability of device functionality in offline scenarios.

[0092] During the time correction operation, by acquiring hardware detection information from the real-time clock module, the time correction processing logic is focused on scenarios where the real-time clock module is absent or in a faulty state. This solves the problem of the device lacking a reliable external time source in scenarios without network connectivity. Combined with anomaly detection of the current system time and correction of the system time using a pre-configured target time generated based on the device's batch information, the system can make and execute time correction decisions based solely on the device's own state, even with a network connection. This solves the problem of a lack of a reliable time source in offline scenarios, ensuring that the device can still obtain a unified, known, and relatively reasonable time benchmark in a network-isolated environment. This makes log timestamps readable and comparable, and allows the device's business programs to operate normally based on the corrected time.

[0093] By implementing an automated, timing-controllable time correction scheme based on a local preset time source that does not rely on external networks, embedded devices can achieve time self-correction in offline environments without network connectivity. This effectively solves a series of problems caused by the lack of a reliable time source, inability to distinguish clock hardware status, and timing chaos in existing solutions when deployed offline, enabling devices to ensure time consistency and business function reliability even without network conditions.

[0094] In one feasible implementation, step S20 may include steps S201-S202:

[0095] Step S201: Identify the service configuration file from the local configuration file; the service configuration file includes at least the configuration file for the time correction service and the configuration file for the business service;

[0096] By using the operating system's process management mechanism, dependency configuration information for the time correction service is added to the configuration file of the business service, configuring the dependency relationship between the time correction service and the business service; the dependency relationship indicates that the time correction service is a prerequisite service for the business service.

[0097] The dependency configuration information includes at least mandatory dependency parameters and sequence control parameters; the mandatory dependency parameters are used to prevent the business service from entering the startup process if the time correction service is not started or fails to start; the sequence control parameters are used to restrict the business service from triggering the startup process after the one-time execution task of the time correction service is completed.

[0098] The configuration of the dependency relationship between the time correction service and the business service is specifically achieved by using the inherent service management framework of the operating system to statically and declaratively define the startup order and dependency rules between services at the system level, thereby fundamentally eliminating the timing risk of business services being started before time correction is completed.

[0099] First, the service configuration files are identified from the local configuration files. These local configuration files are service definition files recognized and loaded by the operating system's service management architecture. One feasible implementation is based on systemd, a configuration system for Linux system initialization and process management. Service configuration files are typically located in the ` / etc / systemd / system / ` or ` / usr / lib / systemd / system / ` directories. The configuration file for the time correction service can be named `fix-time.service`, which defines the service's execution command, type, and user attributes. The configuration files for business services might be `device-business.service` or `device-test.service`, etc. Identifying these files is a prerequisite for dependency configuration; their function is to locate the control entry point for the two services that need to establish a relationship. Business services include application-defined services and device mass production testing services.

[0100] Secondly, by leveraging the operating system's process management mechanism, dependency configuration information for the time correction service is added to the configuration file of the business service. The dependency relationship is declared using the syntax rules of the service configuration file itself, thereby achieving a strong dependency binding between business / test services and the time correction service.

[0101] In one feasible implementation, the configuration file of the business service (e.g., device-business.service) is edited, and a dependency directive pointing to the time correction service (fix-time.service) is added in its [Unit] configuration section. This encodes the logic that time correction must precede business startup into a rule that the service manager (systemd) can understand and enforce.

[0102] The dependency configuration information specifically includes mandatory dependency parameters and order control parameters. As an example, in the context of systemd implementation:

[0103] The mandatory dependency parameter corresponds to the configuration item `Requires=fix-time.service`, which establishes a strong dependency relationship. If the time correction service `fix-time.service` fails to start or is not successfully activated, the business service `device-business.service`, which depends on it, will not be started. Furthermore, if `fix-time.service` stops while the business service is running, the business service will also be stopped. This ensures that the business service will not run if the time correction service is unavailable, avoiding the risk of starting the business without a valid time base.

[0104] The sequence control parameter corresponds to the configuration item After=fix-time.service, which specifies the startup order of services. Even if both fix-time.service and device-business.service are set to start on boot, and fix-time.service is in the "started" state, the After parameter will force systemd to ensure that fix-time.service has fully started and completed execution before starting device-business.service. In one embodiment, the time correction service is configured as a one-time execution task with Type=oneshot (execute once and exit), ensuring that the business service will always wait for the time correction script to complete execution before starting, rather than simply waiting for the service unit to enter the "activated" state, thus solving the timing misalignment problem.

[0105] In this embodiment, by editing the configuration file of the business service and adding key dependency configuration parameters such as the mandatory dependency parameter Requires and the sequence control parameter After, the system service manager establishes a mandatory and unavoidable sequence checkpoint in the startup process, ensuring the absolute priority of time correction. This is the core guarantee mechanism for ensuring reliable operation of the business in an offline environment.

[0106] In one feasible implementation, for the time correction service, to avoid script execution failure due to embedded system permission restrictions, it is also necessary to configure corresponding execution permissions for its execution script. Execution permissions can also be called operation permissions, ensuring that the highest-privileged user (i.e., the system's root user) can execute and operate the script file. Based on this, after step S30, steps S401~S402 may also be included:

[0107] Step S401: Configure read and write operation execution permissions for the configuration file of the time correction service;

[0108] Step S402: Assign the user to whom the configuration file for the time correction service belongs and the execution permission to the highest-privilege user of the operating system.

[0109] Before executing the time correction service, strict permission and ownership configuration ensures that the time correction service can be correctly invoked by the operating system and run safely and reliably. This is a basic security measure to ensure that the entire time correction process has sufficient operating permissions to modify key system parameters (such as system time). Its core is to limit the access permissions of the execution carrier (configuration file / script) of the time correction service to the highest privilege user, thereby preventing execution failure or unauthorized tampering due to insufficient permissions.

[0110] Specifically, firstly, execute read and write permissions are configured for the time correction service's configuration file. In one specific embodiment, the time correction service's configuration file is manifested at the execution level as an executable script file carrying the time correction logic. For example, the path of this script file is configured as / usr / local / bin / fix-time.sh. Configuring execution permissions is achieved by executing the operating system's chmod command. For example, the specific command is: sudo chmod 700 / usr / local / bin / fix-time.sh.

[0111] In this configuration, permission mode 700 is an octal number. Its meaning and function are as follows: the first digit, 7 (binary 111), grants the file owner full read (r), write (w), and execute (x) permissions; the following two digits, 0 (binary 000), indicate that the owner's group and other users have no permissions, respectively. This permission configuration ensures that only the designated owner can view, modify, and run the corresponding script file, while no other user or process in the system can perform any operation on it. This effectively prevents unauthorized access, accidental modification, or malicious interference to the script file, improving the stability and security of the time correction process.

[0112] Secondly, by assigning the ownership and execution permissions of the time correction service configuration file to the highest-privileged user in the operating system, the identity of the user with script file permissions is clearly defined. As a feasible implementation, the command `sudo chown root:root / usr / local / bin / fix-time.sh` is executed. In this command, `chown` is used to change the file owner and group. The first `root` specifies the owner as the root user, and the second `root` specifies the file's group as the root group. In operating systems like Linux, the root user is the superuser with the highest system privileges. The core purpose of setting the ownership of the time correction service script file to root is to ensure that the script file has sufficient permissions to complete all necessary operations during execution. This is because critical operations such as correcting the system time (using the `date -s` command) and accessing the hardware clock (using the `hwclock` command) typically require root privileges. Assigning the script file itself to the root user creates a closed-loop permission model. That is, only the root user can execute the script file, and the script file inherently possesses root privileges during runtime, fundamentally solving the time correction failure problem caused by insufficient permissions and providing a strong guarantee for time correction stability.

[0113] In this embodiment, by configuring permissions for the time correction service, the time correction script is strictly protected and its execution is ensured to have the necessary permissions. This is a prerequisite for the smooth and secure execution of the time correction service and is the basis for the subsequent time correction logic to take effect.

[0114] In one feasible implementation, the anomaly detection of the current system time is based on a preset judgment threshold. Therefore, step S302 may further include steps A1 to A2:

[0115] Step A1: Extract the year information of the current system time;

[0116] Step A2: Compare the year information with a preset judgment threshold to detect anomalies in the current system time.

[0117] Anomaly detection of the current system time is performed by using lightweight and efficient decision logic to quickly determine whether the system time of the embedded device after power-on is in a obviously unreasonable state that needs to be corrected. The key is to avoid complex calculations in order to adapt to the resource-constrained embedded environment.

[0118] Specifically, firstly, the year information of the current system time is extracted. As a feasible implementation method, this is done by executing the shell command "date +%Y" to call the operating system's date and time interface. The data source is the system clock maintained by the Linux kernel. After the command is executed, a four-digit decimal year string will be output, such as "2025", "1999", or "1970". This year information is the basis for subsequent anomaly detection.

[0119] In another feasible implementation, the year information of the current system time can be obtained by calling standard library functions through a programming language (such as C). For example, the `time` function can be called sequentially to obtain the number of seconds since the Epoch (e.g., 1970-01-01 00:00:00 UTC), and then the `localtime` function can be used to convert the number of seconds into a local time structure containing a year field (`tm_year`, which needs to be incremented by 1900), thereby extracting the year value. This method of extracting year information does not rely on an external shell environment, resulting in higher execution efficiency and better integration.

[0120] Secondly, the extracted year information is compared with a preset judgment threshold to detect anomalies in the current system time. As a feasible implementation, a fixed anomaly judgment threshold year is set, such as 2000. The extracted current system year (CURRENT_YEAR) is compared with this threshold. If CURRENT_YEAR < 2000, the system time is judged to be abnormal; conversely, if CURRENT_YEAR >= 2000, the time is judged to be normal.

[0121] It's important to note that the threshold (2000 years) is a constant embedded in the program logic at the time of device manufacturing or software deployment. Its purpose is to serve as a clear dividing line: since many embedded operating systems, when lacking a reliable time source, default to a very early system time (e.g., January 1, 1970), setting the threshold to 2000 years effectively identifies such backtracking times caused by uninitialized system clocks or hardware clock (RTC) failures as abnormal states. This method makes a decision with a simple integer comparison, resulting in extremely low computational overhead and rapid response.

[0122] In this embodiment, by extracting the system year and comparing it with a pre-set, reasonable fixed threshold, it is determined whether the system time is in an abnormal state that needs correction. This provides an efficient and practical system time anomaly detection mechanism, avoiding complex network time synchronization or integrity verification. It is very suitable for quickly diagnosing the system time status during the startup phase of offline embedded devices without network or reliable RTC, and provides a clear basis for determining whether subsequent correction operations are needed.

[0123] In one feasible implementation, after time correction, a secondary verification of the corrected system time is required. Therefore, referring to... Figure 3 After step S303, steps S304 to S306 may also be included:

[0124] Step S304: Obtain the corrected target system time and perform anomaly detection on the target system time to verify the time correction result;

[0125] Step S305: If the verification is successful, output a prompt message indicating successful correction, and if the hardware detection information indicates that the real-time clock module exists, synchronize the target system time to the real-time clock module.

[0126] In step S306, if the verification fails, a prompt message indicating that the correction has failed is output, the time correction service is exited with a preset error code, and a correction failure record is generated.

[0127] Verification of the corrected system time is a subsequent processing step performed after the initial time correction to ensure its effectiveness and reliability. Its core lies in forming a complete closed-loop operation encompassing "execution-verification-feedback." Secondary verification confirms the time correction effect, and based on the verification results, it determines whether to complete time synchronization or exit with an error message. This significantly improves the success rate and traceability of time correction operations in resource-constrained or unstable environments of embedded devices.

[0128] Specifically, firstly, after correcting the system time using a pre-configured target time, the corrected target system time is obtained, and anomaly detection is performed on the obtained target system time to verify the time correction result. The anomaly detection method for the target system time is the same as that for the current system time, and will not be elaborated further here.

[0129] Verifying the target system time is to verify the execution result of the time correction operation. As another feasible implementation method, after the correction command (date -s “$TARGET_TIME”) is executed, the “date +%Y” command is executed again immediately to obtain the year of the corrected system time, denoted as NEW_YEAR. The year information extracted here is the new system clock that has just been written.

[0130] The specific verification logic is as follows: NEW_YEAR is compared with the pre-configured target time TARGET_TIME (e.g., 2026). If NEW_YEAR equals the target year, the verification is considered successful; otherwise, it is considered a failure. This mechanism of obtaining and comparing the system time twice forms a simple closed-loop feedback loop to verify whether the date -s command was actually executed successfully. It can effectively detect problems where time correction has not actually taken effect due to insufficient permissions, command syntax errors, or system anomalies.

[0131] Secondly, if the verification is successful, a success message is output, and if the hardware detection information indicates the presence of a real-time clock module, the target system time is synchronized to the real-time clock module. One implementation of the output message is to append a success record containing the format "[timestamp][device ID][INFO] System time corrected successfully to $TARGET_TIME" to a pre-defined log file (e.g., / var / log / fix-time.log), providing clear evidence of successful time correction for subsequent device maintenance and testing.

[0132] Furthermore, as a feasible implementation of time synchronization, after successful verification, if the hardware detection information obtained through hardware anomaly detection indicates that the device has a usable real-time clock (RTC) module (i.e., hwclock -show returns a normal time), then the hwclock --systohc command is executed to write back (systohc, system to hardware clock) the currently calibrated system time to the hardware clock module. The purpose is to ensure that the calibrated time is maintained through the hardware clock even after a complete power-off and restart of the device, avoiding the need for recalibration every time power is restored. If the hardware detection information indicates that the device does not have an RTC module, then time synchronization is unnecessary.

[0133] Finally, if the verification fails, a correction failure message is output, the time correction service exits with a preset error code, and a correction failure record is generated. As an example, the output message should include the specific context of the failure, such as recording "Failed to set system time. Expected year: 2026, but got: $NEW_YEAR" to the log file. Exiting with a preset error code is crucial for process control; for example, error code 1 can be set to represent "time synchronization failure". The script execution for exiting the time correction service is executed using the `exit 1` command. On one hand, this terminates the subsequent processes of the time correction service; on the other hand, the error code can be captured by the parent process (such as systemd) that called this script, serving as a result of the service's running status, which is essential for system-level service management. Generating a correction failure record is a natural result of the log output. The recorded content (including failure information, error code, timestamp, device ID, etc.) together constitutes a traceable chain of fault evidence, facilitating subsequent analysis to determine whether the correction failure was caused by configuration errors, permission issues, or system compatibility problems.

[0134] In this embodiment, the reliability and traceability of time correction results are increased through time correction verification and post-processing, ensuring that each correction attempt has clear status feedback and corresponding persistent operations, which is the key to achieving a dual improvement in time correction stability and traceability.

[0135] In one feasible implementation, the entire time correction operation process is logged to ensure that the time correction process is traceable, verifiable, and auditable. Based on this, the device time correction method in this embodiment may further include steps S501-S502:

[0136] Step S501: During the execution of the time correction operation, log information is generated in a preset format at each execution stage; the log information includes at least the device identifier of the embedded device, the execution stage, the execution timestamp, and the execution result; the execution stage includes a hardware detection stage, a time detection stage, and a time correction stage.

[0137] Step S502: Write the log information into a local log file to form a traceable record.

[0138] During the execution of time correction operations, key operation logs are generated and persisted to achieve process traceability. The core is to build a structured, continuous information recording mechanism, which transforms the originally "black box" internal execution process into "white box" data that can be queried and analyzed by time, equipment, and operation stage. This is the key to meeting the requirements of equipment maintainability and test verifiability in industrial scenarios.

[0139] Specifically, during the execution of the time correction operation, log information is generated in a preset format at each execution stage. That is, standardized record information is generated in real time at key decision points and status change points in the time correction process.

[0140] As a feasible implementation, a fixed log format is defined and followed in the shell script to generate corresponding record information. For example, the format is defined as: [Timestamp] [Device Unique Identifier] [Execution Phase] [Status / Information]. Under this format:

[0141] Execution timestamps are typically obtained by executing the command "date '+%Y-%m-%d %H:%M:%S'" to get the current system time, providing a precise time anchor for each record. Even before the time is corrected, the recorded time can help analyze the sequence of events in time correction issues.

[0142] A device's unique identifier can be a serial number or MAC address pre-written into the device firmware or configuration file, or a hardware identifier dynamically obtained through commands such as `cat / proc / cpuinfo` to get the CPU serial number. Its content is a globally unique string that identifies the device. Its purpose is to accurately locate the source device of logs in a batch deployment environment, enabling device-based log aggregation and filtering.

[0143] The execution phase includes a hardware detection phase, a time detection phase, and a time correction phase, and can be further subdivided into the hardware status self-check, abnormal time determination, time correction command execution, and result secondary verification phases described in steps S301 to S306. In specific implementation, the execution phase is usually a hard-coded string constant used to mark the flow step of the time correction operation to which the current log record belongs.

[0144] The execution results are the operational outcomes or status descriptions of each execution stage. For example, in the hardware detection stage, the result might be hardware detection information indicating "RTC_MODULE_NOT_FOUND" (real-time clock module not found) or "RTC_READ_ERROR: I / O error" (hardware failure); in the time detection stage, the result might be a time anomaly detection result indicating "CURRENT_YEAR=1999,ABNORMAL" (current year abnormal) or "CURRENT_YEAR=2026,NORMAL" (normal); in the time correction stage, the execution result might be a secondary verification result indicating "SET_TIME_SUCCESS" (setting successful) or "VERIFY_FAIL: expected 2026 got 1970" (verification failed). The purpose of the execution results is to directly reflect the success or failure of the corresponding execution stage's operation and its specific details.

[0145] Secondly, log information is written to a local log file to form a traceable record. This local log file then persistently stores the generated log information on the device's local non-volatile storage medium. As a feasible implementation, a log file path is defined during script initialization, for example, LOG_FILE=" / var / log / fix-time.log". Subsequently, at each execution point or stage where logging is required, the formatted complete log string is appended (using the >> operator) to this log file using commands such as echo or printf. For example: echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$DEVICE_ID][HARDWARE_CHECK] RTC module isfunctional.">>$LOG_FILE.

[0146] Furthermore, the purpose of the generated log files is:

[0147] Troubleshooting: When any time-related anomalies occur in the device, maintenance personnel can check this log to accurately know the entire time correction process at the last startup, including hardware status, judgment criteria, correction results, and possible error codes, thereby quickly locating whether it is a hardware problem, a configuration problem, or an execution anomaly.

[0148] Testing and Verification: During mass production testing, the testing program can read and parse this log file to automatically determine whether the time correction service of each device has been successfully executed as expected, without the need for manual intervention, thus meeting the requirements of standardized testing.

[0149] Operation auditing: Logs provide an immutable history of operations, meeting the industrial sector's requirements for traceability and auditability of critical system operations.

[0150] In this embodiment, by generating log information containing multiple elements (timestamp, device ID, stage, result) in a unified and structured format at each key execution stage and persistently writing it to a local log file, a complete link tracing and recording mechanism for time correction operations is constructed. This makes the internal time synchronization process of a single device in an offline environment transparent, traceable, and analyzable, and is the concrete carrier for realizing full-link traceable log recording and traceability.

[0151] This application embodiment constructs a fully closed-loop offline time automatic correction system specifically designed for embedded devices without a real-time clock (RTC) and network connection. It achieves technical effects that are significantly better than existing general solutions, specifically in multiple dimensions such as reliability, timing guarantee, maintainability, and adaptability.

[0152] Firstly, regarding the reliability and accuracy of time calibration, multiple safeguard mechanisms fundamentally improve the success rate of time calibration. Based on precise parsing of the hwclock command or sysfs interface, hardware status self-checks clearly distinguish between different hardware states: "device without RTC module" and "RTC module failure," effectively avoiding misjudgments during equipment maintenance. A pre-configured, fixed offline time source ensures a reliable and unified time calibration benchmark even in a completely network-free environment. A closed-loop "execution-verification" process promptly detects and identifies time calibration failures, preventing the system from running business programs at uncalibrated times. Permission configuration for service configuration files eliminates execution failures due to insufficient permissions. These measures work together to improve the success rate of offline time calibration and address the shortcomings of insufficient time calibration stability in existing solutions.

[0153] Secondly, regarding system startup sequence and business assurance, the startup order of services is strictly defined through operating system-level service dependency configuration (such as setting the After and Requires parameters in systemd, or using the "lock file" mechanism of the Init script): the business service can only start after the time correction service has successfully completed. This completely eliminates the risk of timing misalignment at the system level, where "the business program is already running at the wrong time, and the time is corrected later," ensuring that all applications, scheduled tasks, and test cases that depend on the correct system time can start and run on a reliable time benchmark, thus resolving the program exceptions and test data failures caused by this.

[0154] Furthermore, a full-chain, structured logging mechanism has been implemented to ensure operational traceability and mass production adaptability. Standardized logs containing unique device identifiers, timestamps, and execution results are generated at every critical stage, including hardware testing, time determination, calibration execution, and result verification. This makes the time calibration process at each device startup transparent, searchable, and auditable, greatly facilitating remote fault location and automated verification of batch device test results, meeting the standardization and traceability requirements of industrial scenarios.

[0155] Finally, in terms of lightweight design and scalability, time correction is implemented based on Shell scripts and native operating system mechanisms (such as systemd and cron), requiring no third-party software and consuming very few device computing and storage resources, demonstrating excellent lightweight characteristics. At the same time, the script-based design offers good scalability: for example, the correction script can be replaced with C or Python programs to adapt to different operating systems or programming environments; the time source can be changed from hard-coded scripts to reading configuration files; and timing control can also be adapted to other process managers such as SysVinit or Supervisor. This ensures that the time correction solution can be flexibly deployed in various embedded devices, from those with extremely limited resources to those with relatively rich functionality.

[0156] By integrating hardware status detection, trusted offline time source, closed-loop verification, forced timing dependency, and full-link log recording into a closed-loop process design, this solution provides a highly reliable, manageable, and business-coordinated offline time correction solution for embedded devices without RTC or network connectivity, effectively solving the time maintenance problem of embedded devices in industrial offline deployment scenarios.

[0157] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the device time correction method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0158] This application also provides a device time correction apparatus, please refer to... Figure 4 The device time correction device includes:

[0159] Service startup module 10 is used to start the time correction service through a local configuration file when the device starts up;

[0160] Dependency configuration module 20 is used to configure the time correction service as a prerequisite service for the business service; the business service is started after the time correction service is executed.

[0161] Time correction module 30 is used to call the time correction service and perform the corresponding time correction operation;

[0162] The time correction module 30 is specifically used for:

[0163] Obtain hardware detection information from the real-time clock module;

[0164] If the hardware detection information indicates that the real-time clock module is missing or in a faulty state, an anomaly detection is performed on the current system time.

[0165] If the current system time is determined to be abnormal, the current system time is corrected by a pre-configured target time; the target time is generated based on the batch information of the embedded device.

[0166] In one embodiment, the dependency configuration module 20 is further configured to:

[0167] The service configuration file is identified from the local configuration file; the service configuration file includes at least the configuration file for the time correction service and the configuration file for the business service;

[0168] By using the operating system's process management mechanism, dependency configuration information for the time correction service is added to the configuration file of the business service, configuring the dependency relationship between the time correction service and the business service; the dependency relationship indicates that the time correction service is a prerequisite service for the business service.

[0169] The dependency configuration information includes at least mandatory dependency parameters and sequence control parameters; the mandatory dependency parameters are used to prevent the business service from entering the startup process if the time correction service is not started or fails to start; the sequence control parameters are used to restrict the business service from triggering the startup process after the one-time execution task of the time correction service is completed.

[0170] In one embodiment, the device time correction apparatus further includes a permission configuration module, used for:

[0171] Configure read and write permissions for the configuration file of the time correction service;

[0172] The user who owns the configuration file for the time correction service and the execution permission are granted to the highest-privilege user of the operating system.

[0173] In one embodiment, the time correction module 30 is further configured to:

[0174] Extract the year information of the current system time;

[0175] The year information is compared with a preset judgment threshold to detect anomalies in the current system time.

[0176] In one embodiment, the time correction module 30 is further configured to:

[0177] The corrected target system time is obtained, and anomaly detection is performed on the target system time to verify the time correction result.

[0178] If the verification is successful, a prompt message indicating successful correction will be output, and if the hardware detection information indicates that the real-time clock module exists, the target system time will be synchronized to the real-time clock module.

[0179] If the verification fails, a correction failure message will be output, the time correction service will be exited with a preset error code, and a correction failure record will be generated.

[0180] In one embodiment, the device time correction apparatus further includes a log recording module, used for:

[0181] During the execution of the time correction operation, log information is generated in a preset format at each execution stage; the log information includes at least the device identifier of the embedded device, the execution stage, the execution timestamp, and the execution result; the execution stage includes a hardware detection stage, a time detection stage, and a time correction stage.

[0182] The log information is written to a local log file to form a traceable record.

[0183] The device time correction device provided in this application, employing the device time correction method described in the above embodiments, can solve the technical problem that existing time correction schemes cannot meet the time correction requirements of industrial-grade embedded devices in offline deployment scenarios without network connectivity. Compared with the prior art, the beneficial effects of the device time correction device provided in this application are the same as those of the device time correction method described in the above embodiments, and other technical features in the device time correction device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0184] This application provides an embedded device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the device time correction method in Embodiment 1 above.

[0185] The following is for reference. Figure 5This document illustrates a structural diagram of an embedded device suitable for implementing embodiments of this application. The embedded device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The embedded device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0186] like Figure 5 As shown, the embedded device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the embedded device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the embedded device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show embedded devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0187] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0188] The embedded device provided in this application, employing the device time correction method described in the above embodiments, solves the technical problem that existing time correction schemes cannot meet the time correction requirements of industrial-grade embedded devices in offline deployment scenarios without network connectivity. Compared with the prior art, the beneficial effects of the embedded device provided in this application are the same as those of the device time correction method described in the above embodiments, and other technical features of this embedded device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0189] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0190] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0191] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the device time correction method in the above embodiments.

[0192] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0193] The aforementioned computer-readable storage medium may be included in an embedded device or may exist independently without being assembled into an embedded device.

[0194] The aforementioned computer-readable storage medium carries one or more programs that, when executed by an embedded device, cause the embedded device to:

[0195] When the device starts up, the time correction service is started using a local configuration file;

[0196] Configure the time correction service as a prerequisite service for the business service; the business service starts after the time correction service is executed.

[0197] Invoke the time correction service and perform the corresponding time correction operation;

[0198] The time correction operation includes:

[0199] Obtain hardware detection information from the real-time clock module;

[0200] If the hardware detection information indicates that the real-time clock module is missing or in a faulty state, an anomaly detection is performed on the current system time.

[0201] If the current system time is determined to be abnormal, the current system time is corrected by a pre-configured target time; the target time is generated based on the batch information of the embedded device.

[0202] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0203] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0204] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0205] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described device time correction method. This solves the technical problem that existing time correction schemes cannot meet the time correction requirements of industrial-grade embedded devices in offline deployment scenarios without network connectivity. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the device time correction method provided in the above embodiments, and will not be repeated here.

[0206] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the device time correction method described above.

[0207] The computer program product provided in this application solves the technical problem that existing time correction schemes cannot meet the time correction requirements of industrial-grade embedded devices in offline deployment scenarios without network connectivity. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the device time correction method provided in the above embodiments, and will not be repeated here.

[0208] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method of device time correction, characterized by, The device time correction method, applied to embedded devices without network connectivity, includes: When the device starts up, the time correction service is started through a local configuration file; the local configuration file is a system-level start / stop script or configuration document stored in the embedded device, which is used to define the service's startup rules and priorities. Configure the time correction service as a prerequisite service for the business service to force the business service to start after the time correction service is executed; Invoke the time correction service and perform the corresponding time correction operation; The time correction operation includes: Obtain hardware detection information from the real-time clock module; If the hardware detection information indicates that the real-time clock module is missing or in a faulty state, an anomaly detection is performed on the current system time. If the current system time is determined to be abnormal, the current system time is corrected by a pre-configured target time; the target time is generated based on the batch information of the embedded device.

2. The device time correction method as described in claim 1, characterized in that, The step of configuring the time correction service as a prerequisite service for the business service includes: The service configuration file is identified from the local configuration file; the service configuration file includes at least the configuration file for the time correction service and the configuration file for the business service; By using the operating system's process management mechanism, dependency configuration information for the time correction service is added to the configuration file of the business service, configuring the dependency relationship between the time correction service and the business service; the dependency relationship indicates that the time correction service is a prerequisite service for the business service. The dependency configuration information includes at least mandatory dependency parameters and sequence control parameters; the mandatory dependency parameters are used to prevent the business service from entering the startup process if the time correction service is not started or fails to start; the sequence control parameters are used to restrict the business service from triggering the startup process after the one-time execution task of the time correction service is completed.

3. The device time correction method as described in claim 2, characterized in that, Before the step of invoking the time correction service and performing the corresponding time correction operation, the method further includes: Configure read and write permissions for the configuration file of the time correction service; The user who owns the configuration file for the time correction service and the execution permission are granted to the highest-privilege user of the operating system.

4. The device time correction method as described in claim 1, characterized in that, The steps for detecting anomalies in the current system time include: Extract the year information of the current system time; The year information is compared with a preset judgment threshold to detect anomalies in the current system time.

5. The equipment time correction method according to any one of claims 1 to 4, characterized in that, After the step of correcting the current system time using a pre-configured target time, the method further includes: The corrected target system time is obtained, and anomaly detection is performed on the target system time to verify the time correction result. If the verification is successful, a prompt message indicating successful correction will be output, and if the hardware detection information indicates that the real-time clock module exists, the target system time will be synchronized to the real-time clock module. If the verification fails, a correction failure message will be output, the time correction service will be exited with a preset error code, and a correction failure record will be generated.

6. The equipment time correction method according to any one of claims 1 to 4, characterized in that, The device time correction method further includes: During the execution of the time correction operation, log information is generated in a preset format at each execution stage; the log information includes at least the device identifier of the embedded device, the execution stage, the execution timestamp, and the execution result; the execution stage includes a hardware detection stage, a time detection stage, and a time correction stage. The log information is written to a local log file to form a traceable record.

7. A device time correction device, characterized in that, The time correction device, applicable to embedded devices without network connectivity, includes: The service startup module is used to start the service time correction service through a local configuration file when the device starts up; the local configuration file is a system-level start / stop script or configuration document stored in the embedded device, which is used to define the service startup rules and priorities. The dependency configuration module is used to configure the time correction service as a prerequisite service for the business service, so as to force the business service to start after the time correction service is executed; The time correction module is used to call the time correction service and perform the corresponding time correction operation; The time correction module is specifically used for: Obtain hardware detection information from the real-time clock module; If the hardware detection information indicates that the real-time clock module is missing or in a faulty state, an anomaly detection is performed on the current system time. If the current system time is determined to be abnormal, the current system time is corrected by a pre-configured target time; the target time is generated based on the batch information of the embedded device.

8. An embedded device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the device time correction method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the device time correction method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the device time correction method as described in any one of claims 1 to 6.

Images