Starting method and starting device of embedded system, storage medium and vehicle

Abstract

The invention discloses a starting method and a starting device of an embedded system, a storage medium and a vehicle, and relates to the technical field of vehicles, the method comprises the following steps: receiving and responding to a starting instruction sent by a parallel scheduler so as to send a registration service to a message bus; the method comprises the following steps: acquiring state information of a service provided by a target function module on which a current function module depends, performing initialization configuration under the condition that the service of the target function module is successfully registered and the service is determined to be ready based on the state information, and sending a state synchronization request signal to the target function module after the initialization configuration is completed, the target function module sends the state information to the message bus based on the state synchronization request signal; and after receiving the state information sent by the target function module based on the message bus, entering a main event cycle, and executing a target function and a target task. According to the starting method, the starting efficiency of the system can be improved, and the problem of starting failure or blockage caused by unready dependence is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of embedded systems, and particularly relates to a starting method of an embedded system, a computer readable storage medium, a vehicle and a starting device of an embedded system. BACKGROUND

[0002] In embedded systems such as vehicle T-Box, software functions are increasingly complex, and a multi-process micro-service architecture is often used. A parallel scheduler daemon process is responsible for dynamically managing (starting, monitoring, restarting) multiple function modules, and there are complex initialization dependency relationships between these modules.

[0003] The related technical solution currently adopts strict serial starting when processing these dependencies. The scheduler pulls up the modules in order according to a global dependency graph. Although this method can avoid missing dependencies, the total starting time is the cumulative initialization time of all modules, which is inefficient. Either a simple parallel start is used, in which all modules are pulled up at the same time, but due to the lack of fine dependency management, dependent modules may attempt to access before the dependent services are ready, resulting in call failures, blocking or initialization errors.

[0004] In addition, a publish-subscribe model is usually used between modules. If a state producer publishes a state event (such as a power state) before the consumer completes initialization and subscribes to the topic, the event will be lost because no one subscribes. When the consumer subscribes later, the system state it obtains may be outdated, resulting in inconsistent states. SUMMARY

[0005] The present application aims to at least solve one of the technical problems in the related art. To this end, the first purpose of the present application is to propose a starting method of an embedded system, which receives and responds to an opening instruction sent by a parallel scheduler, sends a registration service to a message bus, obtains state information of a service provided by a target function module on which a current function module depends, performs initialization configuration in the case that the target function module service registration is successful and the service is determined to be ready based on the state information, and sends a state synchronization request signal to the target function module after the initialization configuration is completed, so that the target function module sends the state information to the message bus based on the state synchronization request signal. After receiving the state information sent by the target function module based on the message bus, the main event loop is entered, the target function and the target task are executed, so that the starting efficiency of the system can be improved, the system reliability is enhanced, and the problem of starting failure or blocking due to unready dependencies is avoided.

[0006] The second purpose of the present application is to propose a computer readable storage medium.

[0007] The third purpose of the present application is to propose a vehicle.

[0008] The fourth objective of this application is to provide a startup device for an embedded system.

[0009] To achieve the above objectives, a first aspect of this application proposes a startup method for an embedded system. The embedded system includes a parallel scheduler, multiple functional modules, and a message bus. The method is applied to the functional modules and includes: receiving and responding to a startup command sent by the parallel scheduler to send a service registration to the message bus; obtaining status information of a service provided by a target functional module on which the current functional module depends; performing initialization configuration when the target functional module service registration is successful and the service is determined to be ready based on the status information; and sending a status synchronization request signal to the target functional module after the initialization configuration is completed, so that the target functional module sends the status information to the message bus based on the status synchronization request signal; and entering a main event loop after receiving the status information sent by the target functional module based on the message bus to execute a target function and a target task.

[0010] The embedded system startup method according to the embodiments of this application can improve the startup efficiency of the system, enhance the system reliability, and avoid startup failure or blocking caused by incomplete dependencies.

[0011] In addition, the startup method of the embedded system according to the above embodiments of this application may also have the following additional technical features: According to one embodiment of this application, the services provided by the target functional module include optional dependency services and critical dependency services. The optional dependency services represent services that are not essential for the current functional module to run, and the critical dependency services represent services that are essential for the current functional module to run. The method further includes: determining the readiness status of the optional dependency services and the critical dependency services; and, if the critical dependency services are ready but the optional dependency services are not ready within a first preset time period, controlling the target functional module to enter a degraded mode.

[0012] According to one embodiment of this application, controlling the target functional module to enter a degraded mode includes: executing the critical dependent service and disabling the optional dependent service, and sending a disabling message to the log system.

[0013] According to one embodiment of this application, the method further includes: if it is determined based on the status information that the service is not ready, waiting for a second preset time period, and re-acquiring the status information of the service provided by the target functional module on which the current functional module depends.

[0014] According to one embodiment of this application, the method further includes: sending an alarm message to the cloud platform if the critical dependent service fails to be ready after a predetermined number of consecutive tests.

[0015] According to one embodiment of this application, the functional module includes a dependency list, which includes service-level dependencies and hardware-level dependencies. The service-level dependencies and hardware-level dependencies are used to represent the status information of the services provided by the target functional modules that the current functional module depends on. The dependency list is set inside each functional module code file, in a metadata file outside each functional module code file, or in a server.

[0016] According to one embodiment of this application, the activation instruction is a hierarchical activation instruction, which is used to determine the activation order of the current functional modules based on the priority of the functional modules, so that the functional modules can be started in parallel based on the activation order.

[0017] To achieve the above objectives, a second aspect of this application provides a computer-readable storage medium storing a program that, when executed by a processor, implements the aforementioned startup method for an embedded system.

[0018] The computer-readable storage medium according to the embodiments of this application implements the above-described embedded system startup method during execution, which can improve the startup efficiency of the system, enhance the system reliability, and avoid startup failure or blocking caused by unread dependencies.

[0019] To achieve the above objectives, a vehicle is provided in a third aspect of this application, including a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described startup method for an embedded system.

[0020] The vehicle according to the embodiments of this application can improve the system startup efficiency and enhance system reliability by executing the above-described embedded system startup method, thus avoiding startup failure or blocking caused by incomplete dependencies.

[0021] To achieve the above objectives, a fourth aspect of this application provides a startup device for an embedded system. The embedded system includes a parallel scheduler, multiple functional modules, and a message bus. The device is applied to the functional modules and includes: a receiving module for receiving and responding to a startup command sent by the parallel scheduler to send a registration service to the message bus; an acquisition module for acquiring status information of services provided by a target functional module on which the current functional module depends; a configuration module for performing initialization configuration when the target functional module service registration is successful and the service is determined to be ready based on the status information, and sending a status synchronization request signal to the target functional module after the initialization configuration is completed, so that the target functional module sends the status information to the message bus based on the status synchronization request signal; and an execution module for entering a main event loop and executing a target function and a target task after receiving the status information sent by the target functional module based on the message bus.

[0022] The startup device for the embedded system according to the embodiments of this application can improve the startup efficiency of the system, enhance the system reliability, and avoid startup failure or blocking caused by unready dependencies.

[0023] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0024] Figure 1 This is a flowchart of a startup method for an embedded system according to an embodiment of this application.

[0025] Figure 2 This is a schematic diagram of the system architecture for internal communication of an embedded system according to an embodiment of this application.

[0026] Figure 3 This is a schematic diagram illustrating the interaction of a functional module in an embedded system according to an embodiment of this application to obtain the latest status information.

[0027] Figure 4 This is a schematic diagram illustrating the interaction between various parts of an embedded system according to an embodiment of this application during communication.

[0028] Figure 5 This is a flowchart illustrating a startup method for an embedded system according to a specific example of this application.

[0029] Figure 6 This is a block diagram of a vehicle according to an embodiment of this application.

[0030] Figure 7 This is a block diagram of a startup device for an embedded system according to an embodiment of this application. Detailed Implementation

[0031] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0032] The following description, with reference to the accompanying drawings, outlines an embedded system startup method, a computer-readable storage medium, a vehicle, and a startup device for an embedded system, as proposed in embodiments of this application.

[0033] Figure 1 This is a flowchart of a startup method for an embedded system according to an embodiment of this application.

[0034] like Figure 1 As shown, the startup method of the embedded system in this application embodiment may include the following steps: S1 receives and responds to the start command sent by the parallel scheduler to send the registration service to the message bus.

[0035] S2, obtain the status information of the services provided by the target functional module that the current functional module depends on. If the target functional module service is successfully registered and the service is ready based on the status information, perform initialization configuration, and send a status synchronization request signal to the target functional module after the initialization configuration is completed, so that the target functional module sends the status information to the message bus based on the status synchronization request signal.

[0036] S3, after receiving the status information sent by the target function module based on the message bus, enters the main event loop to execute the target function and target task.

[0037] Specifically, in one embodiment of this application, the embedded system includes a parallel scheduler, multiple functional modules, and a message bus. The parallel scheduler (Monitor) is a system-level component responsible for managing and scheduling the startup and operation of various functional modules within the system. The parallel scheduler starts multiple functional modules at extremely short time intervals (e.g., 10ms), achieving a near-parallel startup process, thereby improving system startup efficiency. It also monitors the operating status of each functional module, including process creation, destruction, and status monitoring, and is responsible for heartbeat detection and fault restart, ensuring that functional modules can automatically recover in the event of a fault. Functional modules are software components in the embedded system that perform specific tasks, such as Config Module, Power Module, and Net Module. Each functional module provides specific services, such as configuration management, power control, and network communication. Furthermore, after startup, each functional module obtains the status information of other modules by sending a status synchronization request signal, ensuring status consistency.

[0038] A message bus (such as D-Bus (Desktop Bus, message bus system) / ZMQ (Zero Message Queue, asynchronous message library)) is a communication mechanism that allows different components (functional modules) in a system to exchange messages and data. Functional modules register the services they provide through the message bus, enabling other modules to discover and use these services. Functional modules send and receive status information through the message bus to achieve state synchronization and consistency. The message bus is also used to transmit event notifications, such as service status changes and error reports.

[0039] The functional modules first receive and respond to the start command sent by the parallel scheduler to register services with the message bus. In other words, the parallel scheduler sends start commands to each functional module, and once a functional module receives the start command, it sends a registration request to the message bus, declaring the services it provides, which may include information such as the service name, interface description, and service provider identifier. Thus, by registering services, other modules can discover and understand the available services, enabling them to request and use them. Service registration allows the system to dynamically add, modify, or delete services at runtime, improving the system's flexibility and scalability.

[0040] Next, the status information of the services provided by the target functional modules that the current functional module depends on is obtained. If the target functional module's service registration is successful and the service is ready based on the status information, initialization configuration is performed. After initialization configuration is complete, a status synchronization request signal is sent to the target functional module, so that the target functional module sends its status information to the message bus based on the status synchronization request signal. In other words, when a functional module (such as a TSP (Telematics Service Processing) module) starts, it first needs to confirm whether its dependent functional modules (target functional modules) have started and are ready to provide services. For example, the current functional module (such as the TSP module) discovers whether its dependent services have been registered by querying the service registry or directly querying the message bus (such as D-Bus or ZMQ). This usually involves checking metadata such as service name, service provider identifier, and interface description. Once it is confirmed that the service has been registered, the TSP module further queries the status information of these services to determine whether they have fully started and are ready to receive requests. The status information may include the service's running status, health check results, performance metrics, etc.

[0041] Based on the status information obtained from the target functional module, it is determined whether these services are ready to receive requests. If the target functional module service has successfully registered and its readiness is confirmed based on the status information, initialization configuration is performed. After initialization configuration is complete, a status synchronization request signal can be sent to the target functional module to request the latest status information. In other words, the functional module performs its own initialization configuration to ensure its internal state is stable before external interaction, avoiding signal processing anomalies due to incomplete initialization. For example, the current functional module listens to the message bus, waiting to receive status update messages from the target functional module. Once status information is received, the current functional module parses this information, extracting data useful for initialization configuration. For example, parsing may include decoding message content, verifying data format and integrity, and mapping the received data to the functional module's internal data structure. Using the parsed status information, necessary initialization configuration can be performed. For example, operating parameters such as thresholds, timeout settings, and resource allocation can be set based on the status information; resources required by the module, such as memory, file handles, and network connections, can be initialized or configured; and the interfaces provided by the module can be configured to ensure they can correctly respond to requests.

[0042] The current functional module (such as the TSP module) constructs a status synchronization request signal. This signal may contain the requester's identity information, the requested service list, and the required status information type. Through the message bus, the TSP module sends the status synchronization request signal to the target functional module. This message must adhere to the system's communication protocol to ensure correct transmission and processing. This signal triggers the target functional module to republish or update its status information, ensuring the module has the latest status data. When the target functional module receives the status synchronization request signal, it sends the latest status information back to the TSP module. For example, the target functional module constructs a status update message based on the request, containing all requested status information. The target functional module publishes the status update message through the message bus. Furthermore, this message needs to be correctly routed to the TSP module, for example, through message serialization, compression, and encryption techniques. Thus, by acquiring and updating status information in real time, the system can quickly respond to changes in service status, improving system response speed and reliability. This ensures that various functional modules in the embedded system can start up and work collaboratively efficiently and reliably, maintaining system stability and performance even in the face of dynamic service changes.

[0043] After receiving status information from the target functional module via the message bus, the system enters the main event loop to execute the target function and task. Within the main event loop, the functional module listens for and responds to various events, such as user input, system notifications, and timer triggers. It can also schedule tasks based on events and priorities, execute corresponding processing logic, and continuously monitor the system and its own status for adjustments or recovery when necessary. Furthermore, within the main event loop, the current functional module (such as the TSP module) begins executing its designed target functions and tasks. For example, it executes core business logic, such as data processing, decision-making, and control command sending. Thus, the functional module ensures that all necessary conditions and configurations are prepared before starting its main tasks. This status-based initialization and configuration method improves the system's flexibility and reliability, enabling it to adapt to constantly changing operating environments and requirements.

[0044] As a result, the parallel scheduler starts all functional modules almost simultaneously, significantly reducing system startup time. Furthermore, by checking the status information of dependent services, it ensures that functional modules are initialized only after all necessary dependencies are ready, enhancing reliability and completely avoiding startup failures or blocking caused by incomplete dependencies. The scheduler can enter the main event loop after the functional module receives the latest status information, ensuring that the functional module can respond to external events and changes in real time.

[0045] According to one embodiment of this application, the services provided by the target functional module include optional dependency services and critical dependency services. Optional dependency services represent services that are not essential for the current functional module to run, while critical dependency services represent services that are essential for the current functional module to run. The startup method of the embedded system further includes: determining the readiness status of the optional dependency services and critical dependency services; and controlling the target functional module to enter a degraded mode if the critical dependency services are ready but the optional dependency services are not ready within a first preset time period. The first preset time period can be determined according to actual conditions.

[0046] Specifically, the services provided by the target functional module include optional dependency services and critical dependency services. Optional dependency services are not absolutely essential for the operation of the current functional module; they are usually associated with enhanced functions or non-core business logic. Even if these services are unavailable, the module's basic functions can still be executed. For example, in a multimedia system, a service providing additional audio and video decoding format support or a location service can be considered an optional dependency. If this service is unavailable, basic video playback may not be affected, but some advanced functions may be unavailable. Critical dependency services are essential for the normal operation of the current functional module. Without these services, the functional module will be unable to perform its core functions. For example, the current functional module (TSP module) requires configuration information from the Config Module, power status from the Power Module, and network status from the Net Module before it can initialize correctly. Therefore, the configuration module, power module, and network module can be considered critical dependency services.

[0047] During system startup, each functional module needs to determine whether its dependent services (including optional and critical dependencies) are ready. For example, a functional module uses service discovery mechanisms (such as querying the service registry or using service discovery protocols) to check if its dependent services are registered and available. The module also checks the status of dependent services to confirm they are fully started and ready to receive requests. If critical dependencies are ready but optional dependencies are not ready within a first preset time period, the target functional module can be controlled to enter a degraded mode. The behavior of the module in degraded mode can be predefined, including which functions will be disabled or restricted, and how to notify users or system administrators of the service degradation. In degraded mode, resources may need to be reallocated to ensure critical functions are still supported, or the user interface may be adjusted, and functions related to unavailable services may be disabled or hidden, depending on the degraded service capabilities.

[0048] In one embodiment of this application, under degraded mode, the status of optional dependent services is continuously monitored, and an attempt is made to restore the service to normal mode when they become available. A monitoring mechanism is implemented to periodically check the status of optional dependent services or receive notifications when service status changes. Once the optional dependent services become available, necessary recovery operations are performed, such as reinitializing affected functions or notifying users that the service has been restored.

[0049] Therefore, by distinguishing between critical and non-critical dependencies and entering a degradation mode when necessary, the robustness and fault tolerance of the system are improved, enabling the embedded system to continue operating even when some services are unavailable, while ensuring that core functions are not affected. Even when some services are unavailable, users can still use the core functions, thereby optimizing the user experience.

[0050] According to one embodiment of this application, controlling a target functional module to enter a degraded mode includes: executing critical dependent services and disabling optional dependent services, and sending a disabling message to the log system.

[0051] Specifically, when a target functional module enters degrade mode, critical dependent services can be executed while optional dependent services are disabled, and a disabling message is sent to the logging system. In other words, if critical dependent services are ready, but optional dependent services are not ready within a preset time, the target functional module will disable these services. It also ensures that all critical dependent services are active and performs necessary initialization operations, such as initializing critical services and setting necessary parameters and configurations. Furthermore, information about disabling optional dependent services can be logged to the logging system. This logging mechanism records events, including timestamps, service names, and reasons for disabling, ensuring that log information can be accessed by monitoring systems and analysis tools for subsequent problem diagnosis and performance optimization.

[0052] Therefore, the embedded system can maintain its core functions even when some services are unavailable. Simultaneously, through logging and monitoring mechanisms, it provides system administrators with necessary information to manage and recover the system. This degradation mode design improves system robustness and user experience, ensuring continuous system availability.

[0053] According to one embodiment of this application, the startup method of the embedded system further includes: if it is determined based on status information that the service is not ready, waiting for a second preset time, and then re-acquiring the status information of the service provided by the target functional module on which the current functional module depends. The second preset time can be determined according to actual circumstances.

[0054] Specifically, after startup, the functional module determines whether the service is ready based on the status information received from the target functional module. If the service does not respond within the expected time or the status information indicates that the service is not ready, the functional module will consider the service not ready. If the status information indicates that the service is not ready, the module can wait for a second preset time period and re-acquire the status information of the service provided by the target functional module on which the current functional module depends. That is, the functional module implements a waiting mechanism, which may include busy waiting, polling checks, or timer-triggered checks. After the second preset time period, the functional module re-acquires the status information of the service provided by the target functional module on which it currently depends. In other words, the functional module sends a request to the target functional module again to obtain the latest status information, which can be received and parsed from the target functional module through a message bus or other communication mechanisms.

[0055] The functional module assesses whether the service is ready based on the reacquired status information. It compares the new status information with the previous information to determine if the service has entered a ready state. If the service is ready, the functional module continues with subsequent operations; if it is not yet ready, the functional module can wait for a second preset time and reacquire the status information of the service provided by the target functional module on which the current functional module depends. The second preset time can be set based on the service's normal startup time, the system's startup speed requirements, and considerations for system stability.

[0056] Therefore, embedded systems can handle problems more flexibly and robustly when faced with service startup delays or failures, ensuring system stability and reliability while minimizing the impact on user experience.

[0057] According to one embodiment of this application, the startup method of the embedded system further includes: sending an alarm message to the cloud platform if, after a preset number of consecutive attempts, it is determined that a critical dependent service has failed to be ready. The preset number of attempts can be determined based on actual circumstances.

[0058] Specifically, if a critical service fails to become ready within a preset number of consecutive attempts, the system can be configured to send an alert to the cloud platform. This mechanism helps to promptly notify system administrators or monitoring systems of problems, enabling rapid response and remedial measures. The system administrator or developer sets a preset number of attempts based on the system's specific needs and fault tolerance capabilities. This number defines how many times the system will attempt to check the service status before considering it a failure. The preset number of attempts can be set according to the service's importance, the system's complexity, and the requirements for system stability. For more critical services, the preset number of attempts can be set lower to trigger alerts more quickly. The preset number of attempts can be configured in the system's configuration file or management interface, allowing for easy adjustment based on actual needs.

[0059] During system startup and operation, the status of critical dependent services is continuously monitored. For example, the operational status of critical services is periodically checked through methods such as polling, event notifications, or heartbeat mechanisms. If a service fails to respond within the expected time or returns an error status, the system marks it as failed. Each time a critical dependent service fails to become ready, the system records a failed attempt. For example, the system maintains a counter; each time a service check fails, the counter is incremented. If the service succeeds in a check, the counter is reset to zero, indicating that the service has recovered. When the number of failed attempts reaches a preset number, the system triggers an alarm process, generating alarm information containing key information such as the service name, number of failures, and timestamp. This alarm information can then be sent to the cloud platform so that system administrators can receive and process it. For example, communication protocols (such as HTTP (Hypertext Transfer Protocol) or MQTT (Message Queuing Telemetry Transport)) can be used to send alarm information to the cloud platform, and the transmission of alarm information must be secure. This is achieved through data encryption and authentication mechanisms. The cloud platform can provide an interface to receive alarm information.

[0060] After receiving alarm information, the cloud platform can further process it, such as notifying administrators, logging, and triggering automated repair processes. For example, the cloud platform can notify administrators via email, SMS, or in-app notifications. Alarm events are also logged on the cloud platform for later analysis and auditing. Furthermore, based on preset rules, the cloud platform can automatically attempt to repair common problems, such as restarting services. Therefore, embedded systems can promptly notify relevant personnel when critical services fail consecutively, thereby quickly responding to potential system failures, reducing system downtime, and improving system reliability and maintenance efficiency.

[0061] According to one embodiment of this application, a functional module includes a dependency list, which includes service-level dependencies and hardware-level dependencies. The service-level dependencies and hardware-level dependencies are used to represent the status information of the services provided by the target functional modules that the current functional module depends on. The dependency list is set inside each functional module code file, or in a metadata file outside each functional module code file, or in a server.

[0062] Specifically, in embedded systems, the dependency list of functional modules is a key component defining the conditions required for a module to operate. These dependencies can be service-level or hardware-level, ensuring that the module performs its functions in the correct environment. Service-level dependencies involve software services provided by other modules in the system, such as database access, network communication, and file handling. Service-level dependencies represent the state information of services provided by other modules that the current functional module depends on; for example, a user interface module might rely on an authentication service to verify the user. Hardware-level dependencies are associated with interfaces provided by physical devices or the Hardware Abstraction Layer (HAL), such as sensor data, hardware interfaces, and drivers. Hardware-level dependencies ensure that resources are available and in the correct state before a module accesses specific hardware resources.

[0063] Dependency lists can be set within functional module code files, for example, directly defined in the module's source code files, such as in initialization functions or configuration files. This tightly integrates dependencies with the module code, facilitating development and understanding. Alternatively, dependency lists can be set in metadata files outside the functional module code files. Dependency information is stored in files such as XML, JSON, or specific formats, which the module reads at startup, providing flexibility and maintainability, allowing dependencies to be updated without modifying the code. Finally, dependency lists can be set in a centralized configuration server, where dependency information is stored in a database or configuration service on a remote server. Modules retrieve this information via network requests, centrally managing dependencies. This approach is suitable for distributed systems and allows for dynamic updates.

[0064] This helps developers and maintainers identify which services and hardware resources each module requires, optimize the system startup process based on the dependency list, and ensure that critical services and hardware resources are prioritized.

[0065] According to one embodiment of this application, the startup instruction is a hierarchical startup instruction, which is used to determine the startup order of the current functional modules based on the priority of the functional modules, so that the functional modules can be started in parallel based on the startup order.

[0066] Specifically, hierarchical startup instructions are a strategy for managing the startup order of functional modules in an embedded system. It determines the startup order based on the priority of the functional modules. This strategy ensures that critical functions of the system are started first, thereby optimizing the startup process and improving system responsiveness. First, a startup priority is assigned to each functional module in the system. Priorities can be categorized into several types, such as "high," "medium," and "low," or more specifically, a specific number can be assigned to each module. Furthermore, when assigning priorities, the dependencies between modules need to be considered to ensure that a functional module starts after all its dependent modules.

[0067] A hierarchical start instruction is generated based on the priority of the functional modules, specifying the startup order of the functional modules. The parallel scheduler generates start instructions based on the module priorities. This may involve constructing a startup order list containing modules sorted by priority. Additionally, in one embodiment of this application, the start instructions can be dynamically generated to adapt to changes in system operation, such as the addition or deletion of functional modules. Thus, the parallel scheduler starts the functional modules according to the generated hierarchical start instructions; that is, the scheduler can start functional modules within the same priority group in parallel to improve startup efficiency. For functional module groups of different priorities, the scheduler starts the functional modules in descending order of priority. During startup, the parallel scheduler can monitor the status of each functional module to ensure they start successfully in the predetermined order and time. Once all functional modules have successfully started according to the hierarchical start instructions, the system startup process is complete.

[0068] Therefore, by using hierarchical startup instructions, embedded systems can manage the startup order of modules more flexibly and efficiently, ensuring that critical services run first, while optimizing resource utilization and improving system responsiveness. This strategy is particularly important for embedded systems that require fast startup and high reliability.

[0069] In one embodiment of this application, such as Figure 2The diagram illustrates the parallel startup process of various functional modules in an embedded system and their interaction with the message bus (D-Bus / ZMQ). The parallel scheduler, Monitor, is responsible for starting all functional modules in parallel; that is, Monitor is the starting point of the startup process, sending startup commands to each functional module. The functional module cluster includes multiple functional modules, each providing a specific service: Config Module: handles system configuration information; Power Module: manages the system's power status; Net Module: handles network connections and communication; Signal Module: handles system signals or events; Others Module: represents other functional modules in the system besides those mentioned above; TSP Module: handles remote service requests. D-Bus / ZMQ (message bus) serves as the internal communication mechanism of the system, allowing modules to send and receive messages.

[0070] The Monitor sends startup commands to all functional modules in parallel. After startup, each functional module registers its services with the message bus, enabling other modules to discover and invoke these services. Functional modules publish signals to the message bus indicating they are ready to provide services. Functional modules can send Alive signals (state synchronization request signals) to each other. The Alive signal is part of state synchronization, ensuring that functional modules have the latest state information before making service calls or data processing, thereby improving system reliability and data consistency. For each functional module, for example, the Config Module registers its services (such as configuration reading and writing) with the message bus after startup, and responds to calls: when other modules need to access configuration information, they call the services registered by the Config Module and respond with Alive: upon receiving an Alive signal, the Config Module republishes its current configuration state information to the message bus. The Power Module registers its services (such as power management and battery status query) and publishes signals: when the power state changes (such as charging complete or low battery), the Power Module publishes signals to notify other modules. Alive Response: Upon receiving an Alive signal, the Power Module sends a current power status update to the message bus. Net Module Registration Services: The Net Module registers services such as network connection and data transmission. Signal Publication: When the network status changes (e.g., successful connection, disconnection), the Net Module publishes a corresponding signal. Alive Response: Upon receiving an Alive signal, the Net Module sends a network status update to the message bus. Signal Module Registration Services: The Signal Module registers its services, such as signal processing and event distribution. Signal Publication: After processing a specific signal, the Signal Module publishes the processing result or event notification. Alive Response: The response to an Alive signal is to republish the currently processed signal or event status. Others Module Registration Services: Others Modules register corresponding services according to their functions. Signal Publication: When a specific task is completed or a status change occurs, the relevant signal is published. Sending and Responding to Alive: Sending an Alive signal to request a status update and sending current status information upon receiving an Alive signal. TSP Module (Remote Service Processing Module) Registration Services: The TSP Module registers its services, such as remote information processing and command execution.Respond to Invocations: Respond to invocation requests initiated by other modules and execute the corresponding remote service operations. Subscribe to Signals: Subscribe to relevant signals published by other modules for remote processing. Send Alive: After subscribing to the service, send an Alive signal to request the latest status information. In this way, the various modules collaborate within the embedded system, ensuring efficient system operation and real-time status updates. Each module clearly understands its role and responsibilities, communicating with other modules via the message bus to register services, publish signals, and synchronize status.

[0071] In one embodiment of this application, such as Figure 3 The diagram illustrates how the TSP module in an embedded system relies on and interacts with the Signal module to obtain the latest CAN (Controller Area Network) status signal update service. The TSP module first sends a subscription request to the D-Bus, indicating its desire to receive CAN status signal updates. This ensures that the TSP module can receive new CAN status information published by the Signal module. The TSP module then sends an Alive signal (state synchronization request signal) to the Signal module via the D-Bus, requesting the service signal. This signal confirms the Signal module's readiness and requests its latest status information. Upon receiving the Alive signal, the Signal module parses it and confirms the need to republish the status. The Signal module ensures the TSP module receives the latest status information by republishing its current CAN status signal update. The Signal module publishes the latest CAN status signal update via the D-Bus, ensuring that all modules subscribed to this status update, including the TSP module, receive the latest status information. The TSP module receives CAN status signal updates transmitted by the D-Bus, enabling it to perform necessary processing based on the latest status signal, such as status monitoring, data analysis, or other remote service functions.

[0072] This ensures that the TSP module has the latest CAN status information provided by the Signal module. Through the subscription and publish mechanism, multiple modules in the system are allowed to flexibly receive and provide status updates. The system reliability is enhanced and the consistency of status information is ensured through the Alive signal and status synchronization request.

[0073] In summary, as a comprehensive example, such as Figure 4As shown, in the first phase (parallel startup of all modules), the Monitor sends startup commands to all functional modules (D-Bus, Config, Power, Signal, Others, TSP). Each functional module, upon receiving the startup command, begins its startup process. In the second phase (parallel module initialization and registration), the Config module performs initialization operations and registers its services with the D-Bus; the Power module performs initialization operations and registers its services with the D-Bus; the Signal module performs initialization operations and registers its services with the D-Bus; the Others module performs initialization operations and registers its services with the D-Bus; and the TSP module begins its initialization operations and registers its services with the D-Bus.

[0074] In the third phase (TSP actively waits for dependencies), the TSP module checks whether its dependent services are ready. For example, the TSP module checks if the Config service is ready. If the Config service is ready, the TSP module checks if the Power service is ready. If the Power service is ready, the TSP module checks if the Net service (the service corresponding to the Net functional module (not shown in the diagram)) is ready. If the Net service is not ready, the TSP module waits for a period of time (e.g., 10ms) and then retryes. In the fourth phase (dependencies are ready, initialization is complete), once all dependent services are ready, the TSP module calls the GetConfig interface to obtain configuration information and the GetPowerStatus interface to obtain power status information. In the fifth phase (state synchronization), the TSP module subscribes to CAN signal status updates and sends an Alive signal to the Signal module, requesting the republication of status information. After receiving the Alive signal, the Signal module republishes the CAN signal status update, and the TSP module receives the latest CAN signal status update.

[0075] It should be noted that D-Bus and ZMQ in this application can be replaced by other IPC (Inter-Process Communication) mechanisms that support service discovery, publish-subscribe, and RPC (Remote Procedure Call), such as gRPC (Google Remote Procedure Call) or custom protocols based on TCP (Transmission Control Protocol) / UDP (User Datagram Protocol), as long as they can provide equivalent service registration, query, and message passing functions.

[0076] Thus, through these steps, the total startup time is reduced from the cumulative time in serial mode to the initialization time of the slowest functional module, significantly improving startup efficiency. This completely avoids startup failures or blockages caused by incomplete dependencies, enhancing system reliability. It also ensures that all functional modules can obtain the latest initial state of their dependencies, keeping the system state consistent. Furthermore, failures in a single module will not propagate, and the system can still start and run in degraded mode. Additionally, new modules only need to declare their dependencies and implement waiting logic within them, without needing to modify Monitor or other modules.

[0077] The following is combined Figure 5 This describes the initiation method of this application.

[0078] As a specific example, the startup method of the embedded system in this application may include the following steps: S101 receives and responds to the hierarchical start command sent by the parallel scheduler, so that the functional modules can start in parallel based on the start order, and send the registration service to the message bus.

[0079] S102, obtain the status information of the services provided by the target functional modules that the current functional module depends on through the dependency list.

[0080] S103, The target functional module service is successfully registered and the readiness status of the selected dependent services and key dependent services is determined based on the status information.

[0081] S104. Determine whether the critical dependent services are ready and whether the selectable dependent services are not ready within the first preset time period. If yes, proceed to step S105; if no, proceed to step S107.

[0082] S105, perform initialization configuration, and after the initialization configuration is completed, execute the key dependency service and disable the optional dependency service, send the disable information to the log system, and send a state synchronization request signal to the target functional module so that the target functional module sends the state information to the message bus based on the state synchronization request signal.

[0083] S106 After receiving the status information sent by the target function module based on the message bus, it enters the main event loop and executes the target function and target task.

[0084] S107, determine whether the critical dependent service has failed to prepare after a preset number of consecutive attempts. If yes, proceed to step S108; otherwise, proceed to step S103.

[0085] S108 sends alarm information to the cloud platform.

[0086] In summary, the embedded system startup method according to the embodiments of this application receives and responds to a startup command sent by a parallel scheduler to send a service registration message to the message bus, obtains the status information of the services provided by the target functional modules on which the current functional module depends, performs initialization configuration when the target functional module service registration is successful and the service is ready based on the status information, and sends a status synchronization request signal to the target functional module after the initialization configuration is completed, so that the target functional module sends its status information to the message bus based on the status synchronization request signal, and enters the main event loop after receiving the status information sent by the target functional module based on the message bus, executing the target function and target task. Therefore, this method can improve the system startup efficiency, enhance system reliability, and avoid startup failures or blocking caused by dependencies not being ready.

[0087] Corresponding to the above embodiments, this application also proposes a computer-readable storage medium.

[0088] The computer-readable storage medium of this application embodiment stores a program that, when executed by a processor, implements the above-described startup method of the embedded system.

[0089] According to the computer-readable storage medium of the present application embodiment, by executing the above-described embedded system startup method, the startup efficiency of the system can be improved, the system reliability can be enhanced, and the startup failure or blocking caused by unread dependencies can be avoided.

[0090] Corresponding to the above embodiments, this application also proposes a vehicle.

[0091] like Figure 6 As shown, the vehicle 200 in this embodiment may include: a memory 210, a processor 220, and a program stored in the memory 210 and executable on the processor 220. When the processor 220 executes the program, it implements the above-described embedded system startup method.

[0092] The vehicle according to the embodiments of this application can improve the system startup efficiency and enhance system reliability by executing the above-described embedded system startup method, thus avoiding startup failure or blocking caused by incomplete dependencies.

[0093] Corresponding to the above embodiments, this application also proposes a startup device for an embedded system, wherein the embedded system includes a parallel scheduler, multiple functional modules and a message bus, which are applied in the functional modules.

[0094] like Figure 7 As shown, the startup device 100 of the embedded system in this application embodiment includes: a receiving module 110, an acquisition module 120, a configuration module 130, and an execution module 140.

[0095] The receiving module 110 receives and responds to the start command sent by the parallel scheduler to send a service registration message to the message bus. The obtaining module 120 obtains the status information of the services provided by the target functional modules that the current functional module depends on. The configuration module 130 performs initialization configuration when the target functional module's service registration is successful and the service is ready based on the status information. After the initialization configuration is completed, it sends a status synchronization request signal to the target functional module so that the target functional module sends its status information to the message bus based on the status synchronization request signal. The execution module 140, after receiving the status information sent by the target functional module based on the message bus, enters the main event loop to execute the target function and target task.

[0096] According to one embodiment of this application, the services provided by the target functional module include optional dependent services and critical dependent services. Optional dependent services represent services that are not required for the current functional module to run, and critical dependent services represent services that are required for the current functional module to run. The execution module 140 is further configured to: determine the readiness status of the optional dependent services and critical dependent services; and control the target functional module to enter a degraded mode if the critical dependent services are ready but the optional dependent services are not ready within a first preset time period.

[0097] According to one embodiment of this application, the execution module 140 controls the target functional module to enter a degraded mode, specifically for: executing critical dependent services and disabling optional dependent services, and sending the disabling information to the log system.

[0098] According to one embodiment of this application, the acquisition module 120 is further configured to: wait for a second preset time period and reacquire the status information of the service provided by the target functional module on which the current functional module depends, if it is determined based on the status information that the service is not ready.

[0099] According to one embodiment of this application, the execution module 140 is further configured to: send an alarm message to the cloud platform if it is determined that the critical dependent service has failed to be ready after a preset number of consecutive attempts.

[0100] According to one embodiment of this application, a functional module includes a dependency list, which includes service-level dependencies and hardware-level dependencies. The service-level dependencies and hardware-level dependencies are used to represent the status information of the services provided by the target functional modules that the current functional module depends on. The dependency list is set inside each functional module code file, or in a metadata file outside each functional module code file, or in a server.

[0101] According to one embodiment of this application, the startup instruction is a hierarchical startup instruction, which is used to determine the startup order of the current functional modules based on the priority of the functional modules, so that the functional modules can be started in parallel based on the startup order.

[0102] It should be noted that for details not disclosed in the startup device of the embedded system in the embodiments of this application, please refer to the details disclosed in the startup method of the embedded system in the embodiments of this application, which will not be repeated here.

[0103] According to the embedded system startup apparatus of this application embodiment, the receiving module is used to receive and respond to the start command sent by the parallel scheduler to send a registration service to the message bus; the acquisition module is used to acquire the status information of the service provided by the target functional module on which the current functional module depends; the configuration module is used to perform initialization configuration when the target functional module service registration is successful and the service is ready based on the status information, and sends a status synchronization request signal to the target functional module after the initialization configuration is completed, so that the target functional module sends the status information to the message bus based on the status synchronization request signal; and the execution module is used to enter the main event loop and execute the target function and target task after receiving the status information sent by the target functional module based on the message bus. Therefore, this apparatus can improve the system startup efficiency, enhance system reliability, and avoid startup failure or blocking caused by dependencies not being ready.

[0104] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0105] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0106] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0107] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0108] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "joining," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0109] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method of starting an embedded system, characterized by, The embedded system comprises a parallel scheduler, a plurality of function modules and a message bus, the method is applied to the function modules, and the method comprises the following steps of: receiving and responding to an opening instruction sent by the parallel scheduler to send a registration service to the message bus; obtaining state information of a service provided by a target function module relied on by a current function module, and when the target function module service registration is successful and the service is determined to be ready based on the state information, performing initialization configuration, and after the initialization configuration is completed, sending a state synchronization request signal to the target function module to enable the target function module to send the state information to the message bus based on the state synchronization request signal; after the state information sent by the target function module is received based on the message bus, entering a main event loop to execute a target function and a target task.

2. The method of Claim 1, wherein, The service provided by the target function module comprises a selectable dependent service and a key dependent service, the selectable dependent service represents a non-mandatory service relied on by the current function module at runtime, and the key dependent service represents a mandatory service relied on by the current function module at runtime, and the method further comprises the following steps of: determining the preparation of the selectable dependent service and the key dependent service; in a case where the key dependent service is ready and the selectable dependent service is not ready within a first preset time length, controlling the target function module to enter a degraded mode.

3. The method of Claim 2, wherein, The control of the target function module entering the degraded mode comprises the following steps of: executing the key dependent service and disabling the selectable dependent service, and sending disabling information to a log system.

4. The method of Claim 1, wherein, The method further comprises the following steps of: in a case where the service is determined to be not ready based on the state information, waiting for a second preset time length, and re-obtaining the state information of the service provided by the target function module relied on by the current function module.

5. The method of Claim 2, wherein, The method further comprises the following steps of: in a case where the key dependent service is determined to be not ready for a continuous preset number of times, sending alarm information to a cloud platform.

6. The method of Claim 1, wherein, The function module comprises a dependency list, the dependency list comprises service-level dependency and hardware-level dependency, the service-level dependency and the hardware-level dependency are used to represent the state information of the service provided by the target function module relied on by the current function module, and the dependency list is arranged in each function module code file or in a metadata file outside each function module code file or in a server.

7. The method of Claim 1, wherein, The opening instruction is a hierarchical opening instruction, the hierarchical opening instruction is used to determine an opening sequence of the current function module based on the priority of the function module, so that the function module is started in parallel based on the opening sequence.

8. A computer-readable storage medium, characterized in that, A storage medium having an embedded system startup program stored thereon, the embedded system startup program is executed by a processor to implement the embedded system startup method according to any one of claims 1-7.

9. A vehicle characterized by comprising: Comprise: a memory, a processor and a program stored on the memory and executable on the processor, when the processor executes the program, the embedded system startup method according to any one of claims 1-7 is implemented.

10. An apparatus for starting an embedded system, characterized by The embedded system comprises a parallel scheduler, a plurality of function modules and a message bus, the device is applied to the function modules, and the device comprises: a receiving module, configured to receive and respond to an opening instruction sent by the parallel scheduler to send a registration service to the message bus; an obtaining module, configured to obtain state information of a service provided by a target function module relied on by a current function module; a configuring module, configured to, in a case where the target function module service registration is successful and the service is determined to be ready based on the state information, perform initialization configuration, and send a state synchronization request signal to the target function module after the initialization configuration is completed, so that the target function module sends the state information to the message bus based on the state synchronization request signal; an executing module, configured to, after the state information sent by the target function module is received based on the message bus, enter a main event loop to execute a target function and a target task.

Images