Service-oriented architecture (SOA) key service scheduling method and system

Abstract

The invention provides a key service scheduling method and system for a service oriented architecture (SOA), and relates to the technical field of automobile SOA service, and the method comprises the steps: introducing unified AP / CP cross-platform priority mapping, special resource allocation and an elastic resource pool mechanism, and combining the real-time monitoring of a high-key service execution state and dynamic resource preemption. The problems that in traditional static scheduling, high-key services are prone to being blocked by low-key services, the resource utilization rate is low, and cross-platform scheduling is inconsistent are effectively solved. According to the method, idle computing resources are fully utilized to process QM-level low-key services while ensuring that ASIL-B and above-level safety key services always meet strict real-time requirements, and the resources are quickly recycled at key moments to guarantee high-quality tasks; therefore, collaborative optimization of scheduling flexibility, system reliability and hardware resource efficiency is realized under the function security constraint.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of automobile SOA service, in particular to a key service scheduling method and system for a service-oriented architecture SOA. BACKGROUND

[0002] In the automobile service-oriented architecture (SOA), with the AUTOSAR adaptive platform (A) and the classic platform CP mixed deployment becoming mainstream, how to efficiently schedule services with different functional safety criticality levels has become a core challenge. The existing technologies mainly include two types of schemes: static priority scheduling and partition scheduling. The former guarantees the response of high criticality services through preset priority, but the resource allocation is fixed and cannot be dynamically preempted, which easily leads to the delay of ASIL-D level high critical services such as brake control being blocked by low critical services (such as entertainment update); the latter realizes resource isolation through platform partitioning, but causes low utilization of computing resources, which is difficult to adapt to the environment of limited resources of vehicle-mounted systems. In addition, there is a lack of unified priority mapping mechanism between the AP and CP platforms, and the inconsistent priority strategies often cause the breaking of cross-platform service call chains, affecting the collaborative reliability of the system. These defects collectively show that the high criticality service response delay risk is high, the hardware resource waste is serious, and the cross-platform service collaboration fails, which is difficult to balance the comprehensive needs of functional safety, real-time performance and resource efficiency. SUMMARY

[0003] The application aims to solve the technical problems in the related art, and provides a key service scheduling method and system for a service-oriented architecture SOA, which can significantly improve the system resource utilization and ensure the reliable collaboration of cross-platform service call chains by dynamically preempting resources, managing elastic resource pools and using a unified AP / CP priority mapping mechanism, while guaranteeing the real-time performance and functional safety of high criticality services.

[0004] The solution to the technical problem of the application is as follows: the application provides a key service scheduling method for a service-oriented architecture SOA, which is applied to a vehicle-mounted electronic system supporting the mixed deployment of an AUTOSAR adaptive platform AP and a classic platform CP, and includes the following steps: receiving a service request from the AP platform or the CP platform, the service request being associated with a functional safety criticality level; mapping the criticality level of the service request to a unified scheduling priority according to a preset AP / CP cross-platform priority mapping table, wherein high criticality services correspond to ASIL-B or a higher level, and low criticality services correspond to the QM level; Based on the unified scheduling priority, dedicated physical computing resources are allocated to high-critical services or they are scheduled to high-priority execution threads, while low-critical services are placed in an elastic resource pool to run. The resources in the elastic resource pool come from computing resources not occupied by high-critical services. The execution status of highly critical services is monitored in real time. When the response time of a service is detected to be close to a preset deadline threshold, resource preemption is performed, including: reclaiming resources from the elastic resource pool, interrupting the execution of low-critical services, and reallocating the reclaimed resources to the highly critical services.

[0005] Furthermore, the dedicated physical computing resource is an independent CPU physical core, used to bind highly critical services to prevent them from being blocked by other services.

[0006] Furthermore, the computing resources in the elastic resource pool are idle when high-criticality services are not in use and are dynamically allocated to low-criticality services; when high-criticality services need resources, the idle resources can be immediately reclaimed.

[0007] Furthermore, the resource preemption is only allowed to proceed unidirectionally from high-criticality services to low-criticality services, and low-criticality services are prohibited from initiating any form of preemption of resources from high-criticality services, in order to meet functional safety isolation constraints and ensure that functional safety objectives are not violated in pursuit of resource efficiency.

[0008] Furthermore, the AP / CP cross-platform priority mapping table is loaded and solidified during the initialization phase to ensure that the priority of the same service remains consistent regardless of whether it is called on the AP platform or the CP platform.

[0009] Furthermore, when a low-criticality service is interrupted, its execution context is saved, and the execution of the low-criticality service is resumed after the high-criticality service has finished executing.

[0010] Furthermore, the preset deadline threshold is set according to the ASIL level of the highly critical service. The higher the ASIL level, the stricter the corresponding deadline threshold.

[0011] Furthermore, the highly critical services include Automatic Emergency Braking (AEB), collision warning, or braking control services; the low-critical services include network message processing, in-vehicle entertainment, or air conditioning adjustment services.

[0012] On the other hand, this application provides a critical service scheduling system for Service-Oriented Architecture (SOA), the system including a service classification module, a priority mapping module, a resource allocation decision module, and an execution monitor; The service classification module is used to receive service requests from the AP platform or CP platform, and the service requests are associated with functional safety criticality levels. The priority mapping module is used to map the criticality level of the service request to a unified scheduling priority according to the preset AP / CP cross-platform priority mapping table, wherein high criticality services correspond to ASIL-B or higher, and low criticality services correspond to QM level. The resource allocation decision module is used to allocate dedicated physical computing resources or schedule high-priority execution threads to high-critical services based on the unified scheduling priority, while placing low-critical services in the elastic resource pool to run. The resources in the elastic resource pool come from computing resources not occupied by high-critical services. The execution monitor is used to monitor the execution status of highly critical services in real time. When it detects that the response time is close to a preset deadline threshold, it performs resource preemption, including: reclaiming resources from the elastic resource pool, interrupting the low-critical service that is being executed, and reallocating the reclaimed resources to the highly critical service.

[0013] Furthermore, the execution monitor continuously collects the response time and completion status of highly critical services and feeds the monitoring data back to the resource allocation decision module to trigger resource preemption decisions.

[0014] The beneficial effects of this invention are as follows: This application provides a critical service scheduling method for Service-Oriented Architecture (SOA). This method effectively solves the problems of high-criticality services being easily blocked by low-criticality services, low resource utilization, and inconsistent cross-platform scheduling in traditional static scheduling by introducing a unified AP / CP cross-platform priority mapping, dedicated resource allocation, and elastic resource pool mechanism, combined with real-time monitoring of the execution status of high-criticality services and dynamic resource preemption. While ensuring that ASIL-B and higher-level safety-critical services always meet strict real-time requirements, this method fully utilizes idle computing resources to process QM-level low-criticality services and quickly reclaims resources at critical moments to guarantee high-priority tasks, thereby achieving coordinated optimization of scheduling flexibility, system reliability, and hardware resource efficiency under functional safety constraints. This application also provides a corresponding system, the beneficial effects of which are the same as those of the above method, and will not be elaborated here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a flowchart of the key service scheduling method for Service-Oriented Architecture (SOA) provided in this application; Figure 2 This is a structural diagram of the key service scheduling system of Service-Oriented Architecture (SOA) provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] With the rapid development of intelligent connected vehicles and Advanced Driver Assistance Systems (ADAS), the complexity of in-vehicle electronic systems has increased significantly. Traditional signal-based communication architectures are no longer sufficient to meet the flexibility, scalability, and functional integration requirements of software-defined vehicles. Therefore, the automotive industry has widely adopted Service-Oriented Architecture (SOA) to decouple and coordinate different functional modules through service-oriented approaches. Against this backdrop, the AUTOSAR architecture has become a mainstream standard. AUTOSAR (Automotive Open System Architecture) is a standardized software architecture framework developed by automotive industry consortia, aiming to achieve modularity, reusability, and cross-platform compatibility of in-vehicle electronic control unit (ECU) software, supporting both classic platforms (CP) and adaptive platforms (AP) to meet diverse application needs ranging from hard real-time control to high-performance computing.

[0023] Among them, CP (Classic Platform) is designed for control applications with high real-time performance and high security (such as braking and steering), and typically runs on resource-constrained but deterministic microcontrollers, using static configuration and fixed priority scheduling; AP (Adaptive Platform) is designed for computationally intensive and dynamic applications (such as sensing, decision-making, and entertainment), and runs on high-performance multi-core processors, supporting POSIX operating systems and dynamic deployment.

[0024] In practical automotive systems, the Application Processor (AP) and Service Provider (CP) often coexist on the same hardware platform (such as a heterogeneous SoC), forming an "AP / CP hybrid deployment" architecture. While this architecture can balance performance and security, it also brings new challenges: how to efficiently, securely, and in real-time schedule service requests from both AP and CP with different functional safety levels (such as ASIL-D, ASIL-B, and QM) within a unified resource pool? ASIL (Automotive Safety Integrity Level) is a classification index defined in the ISO 26262 standard for measuring the functional safety risks of automotive electronic systems. It is divided into four levels (A, B, C, and D) based on the severity of the hazard, the probability of exposure, and the controllability (ASIL-D is the highest risk level). The higher the level, the more stringent the requirements for system safety mechanisms and development processes. QM (Quality Management) refers to functions that are assessed as having no safety risks or negligible risks in ISO 26262. They do not need to meet specific safety integrity requirements and only need to be developed and verified in accordance with routine quality management processes.

[0025] Functional safety standards (such as ISO 26262) impose stringent response time requirements on highly critical services (such as Automatic Emergency Braking, AEB) (e.g., they must be completed within tens of milliseconds). If the scheduling mechanism cannot guarantee the timely execution of such services, it will directly threaten driving safety. Therefore, designing a dynamic scheduling method that can both meet functional safety real-time constraints and efficiently utilize limited onboard computing resources has become a key technical bottleneck in current automotive SOA architectures. Currently, in automotive SOA architectures, service scheduling in AP / CP hybrid deployment environments mainly adopts the following two types of technical solutions.

[0026] First, static priority scheduling, which pre-sets fixed priorities based on the functional safety level (such as ASIL or QM) of services. In the event of resource contention, high-priority services can preempt the execution rights of low-priority services. This is suitable for control-type tasks with high real-time requirements. Second, partitioned scheduling, which divides the system into AP and CP platform areas and uses time-triggered scheduling (AP) and fixed-priority scheduling (CP) respectively. It also uses a priority mapping table to achieve cross-platform coordination, thereby isolating different critical services and ensuring the deterministic execution of high-security-level functions.

[0027] The above-mentioned solution has three major drawbacks: First, static priority scheduling cannot dynamically respond to changes in runtime load. Low-critical services may occupy resources for a long time, causing high-critical services (such as braking control) to time out due to the inability to obtain computing resources in time, making it difficult to meet the stringent real-time requirements of ISO 26262. Second, although partitioned scheduling can achieve isolation, the resource allocation is fixed, resulting in the inability to reuse hardware resources such as CPU when idle, leading to low overall utilization, which does not meet the reality of limited resources in vehicle systems. Finally, the lack of unified priority semantics between the AP and CP platforms can easily lead to the same service being incorrectly scheduled when called across platforms, causing service chain breaks and seriously affecting the reliability of system collaboration.

[0028] To address the shortcomings of existing technologies in terms of real-time performance, resource utilization, and cross-platform collaboration, this application proposes a critical service scheduling method and system for SOA architecture. Its main technical features include: implementing three core mechanisms—first, ensuring semantic consistency of priority for the same service across different platforms based on a unified AP / CP cross-platform priority mapping table; second, allocating dedicated physical cores or high-priority threads to high-critical services (ASIL-B and above), and organizing the remaining computing resources into an elastic resource pool for dynamic use by low-critical services (QM level); and third, introducing real-time execution monitoring and dynamic resource preemption mechanisms, immediately interrupting low-critical services and reclaiming their occupied elastic resources when the response time of a high-critical service approaches the deadline threshold, prioritizing the timely completion of safety-critical tasks. The entire solution achieves an organic unity of security, real-time performance, and resource efficiency while strictly adhering to functional safety isolation constraints.

[0029] First, the key service scheduling method of Service-Oriented Architecture (SOA) provided in this application will be described in detail below with reference to the accompanying drawings. This method is applied to an in-vehicle electronic system that is a hybrid deployment of an adaptive platform (AP) supporting AUTOSAR and a classic platform (CP). An in-vehicle electronic system refers to an integrated system of electronic hardware and software installed in a vehicle to realize functions such as vehicle control, driving assistance, infotainment, communication, and safety.

[0030] Reference Figure 1The implementation process of the key service scheduling method for Service-Oriented Architecture (SOA) provided in this application embodiment includes, but is not limited to, the following steps.

[0031] Step S110: Receive a service request from the AP platform or CP platform. The service request is associated with a functional safety criticality level.

[0032] Step S110 provides the entry point for the entire scheduling process, capturing service call requests initiated by the AUTOSAR adaptive platform (AP) or the classic platform (CP), and ensuring that each request carries explicit functional safety criticality level information. This criticality level is the basis for subsequent resource allocation and scheduling decisions, reflecting the importance of the service in the overall vehicle functional safety system, such as whether it belongs to a safety-critical function (e.g., braking control) or a non-safety-related function (e.g., the entertainment system). By binding safety attributes at the request source, the system can perform consistent processing of services generated by heterogeneous platforms within a unified framework, providing a prerequisite for cross-platform collaborative scheduling.

[0033] Step S120: Based on the preset AP / CP cross-platform priority mapping table, map the criticality level of service requests to a unified scheduling priority.

[0034] High-criticality services correspond to ASIL-B or higher, while low-criticality services correspond to QM level.

[0035] Step S120 addresses the inconsistency in priority semantics between the AP and CP platforms due to differences in their scheduling models. By introducing a predefined and fixed AP / CP cross-platform priority mapping table, service requests from different platforms but with the same functional safety level are converted into a unified scheduling priority identifier within the system. For example, regardless of whether an ASIL-C level service is initiated on the AP or CP, it corresponds to the same high priority value in the system's eyes after this mapping; while QM level services are uniformly considered low priority. This standardized mapping ensures the fairness and consistency of scheduling decisions, avoiding service link interruptions or scheduling misalignments caused by platform differences, and serves as a crucial bridge for achieving reliable end-to-end service calls.

[0036] Step S130: Based on a unified scheduling priority, allocate dedicated physical computing resources or schedule high-criticality services to high-priority execution threads, while placing low-criticality services in the elastic resource pool for operation. The resources in the elastic resource pool come from computing resources not occupied by high-criticality services.

[0037] In step S130, a differentiated resource allocation strategy is implemented based on the unified scheduling priority. For highly critical services (ASIL-B and above), the system allocates dedicated physical computing resources (such as exclusive CPU cores) or places them in high-priority execution threads of the operating system to maximize the isolation of interference and ensure their deterministic execution. For low-critical services (QM level), they are scheduled to run in a dynamically constructed "elastic resource pool." This resource pool is not statically partitioned but aggregates all idle computing resources (such as CPU time slices and memory bandwidth) not occupied by highly critical services in real time. This mechanism ensures the absolute priority of safety-critical tasks while avoiding resource idleness, achieving efficient resource utilization under security constraints.

[0038] Step S140: Monitor the execution status of high-critical services in real time. When the response time of a service is detected to be close to a preset deadline threshold, preempt resources, including: reclaiming resources from the elastic resource pool, interrupting the execution of low-critical services, and reallocating the reclaimed resources to high-critical services.

[0039] In step S140, runtime dynamic intervention capabilities are introduced to address load surge scenarios that static allocation cannot cover. By continuously monitoring the actual execution status (especially response time) of high-critical services, once it is detected that their execution progress is approaching a preset deadline threshold (which is related to their ASIL level), the system immediately triggers resource preemption: it proactively reclaims computing resources currently allocated to low-critical services from the elastic resource pool, interrupts the execution of these low-priority tasks, and quickly redirects the released resources to high-critical services that are about to time out. This mechanism achieves "on-demand dynamic assurance," strengthens support for safety-critical tasks at critical moments, effectively avoids functional safety risks caused by resource contention, and improves the overall robustness and real-time reliability of the system.

[0040] In some embodiments of this application, the dedicated physical computing resource is an independent CPU physical core, which is used to bind highly critical services to prevent them from being blocked by other services.

[0041] Specifically, dedicated physical computing resources are concretized into independent CPU physical cores. Their core function is to fundamentally eliminate the possibility of highly critical services being interfered with or blocked by other services during execution through hardware-level resource isolation. Because this CPU physical core is dedicated to a specific highly critical service (such as automatic emergency braking, brake control, or other ASIL-B or higher level functions), the operating system or other low-priority tasks cannot be scheduled to run on this core, thus ensuring that the service's execution environment has complete determinism and exclusivity. This "core binding" strategy ensures that the response time of highly critical services is limited only by their own computational load and hardware performance, no longer affected by fluctuations in the overall system load. It strictly meets the stringent requirements of the ISO 26262 functional safety standard for worst-case execution time (WCET) and real-time performance, significantly improving the safety and reliability of the vehicle system under extreme conditions.

[0042] In some embodiments of this application, computing resources in the elastic resource pool are idle when not occupied by high-criticality services and are dynamically allocated to low-criticality services. When a high-criticality service needs resources, the idle resources can be immediately reclaimed.

[0043] Specifically, the design of the elastic resource pool aims to achieve efficient and dynamic reuse of computing resources. Its core function is that when high-critical services do not occupy all system resources, computing resources not locked by dedicated physical cores or high-priority threads (such as CPU time slices and cache bandwidth) are not idle and wasted. Instead, they are organized into an "elastic resource pool" and dynamically allocated to low-critical services (such as in-vehicle entertainment, network packet processing, and other QM-level tasks), thereby improving overall hardware utilization. More importantly, the allocation of these resources is temporary and revocable—once a high-critical service requires more computing power due to increased load or response latency risks, the system can immediately reclaim the resources allocated to low-critical services from the elastic resource pool without waiting for them to complete naturally. This "borrow on demand, return immediately" mechanism maximizes the flexibility and efficiency of resource utilization without sacrificing functional safety, effectively solving the resource waste problem caused by traditional static partitioning or exclusive allocation.

[0044] In some embodiments of this application, resource preemption is only allowed to proceed unidirectionally from high-criticality services to low-criticality services, and low-criticality services are prohibited from initiating any form of preemption of resources from high-criticality services, in order to meet functional safety isolation constraints and ensure that functional safety objectives are not violated in pursuit of resource efficiency.

[0045] Specifically, the design explicitly stipulates that resource preemption is only permitted unidirectionally from high-critical services to low-critical services, a design with critical safety implications. Its core function is to strictly adhere to the fundamental principle of functional safety isolation, ensuring that the system, while pursuing resource scheduling efficiency, never sacrifices the protection of safety-critical functions. Specifically, high-critical services (such as braking control and collision warning at ASIL-B and above) must have absolute resource priority because they are directly related to personal safety; while low-critical services (QM level, such as entertainment or air conditioning control) are explicitly excluded from resource preemption and must not interrupt or interfere with the execution of high-critical services for any reason. This unidirectional preemption mechanism constructs a "safety firewall" at the scheduling strategy level, preventing high-safety-level functions from being delayed or even malfunctioning due to abnormal behavior of low-priority tasks or misjudgments in scheduling optimization logic. This ensures that the entire system always meets the mandatory requirements of functional safety objectives in standards such as ISO 26262, achieving a controllable balance between safety and efficiency.

[0046] In some embodiments of this application, the AP / CP cross-platform priority mapping table is loaded and solidified during the initialization phase to ensure that the priority of the same service remains consistent regardless of whether it is called on the AP platform or the CP platform.

[0047] Specifically, the AP / CP cross-platform priority mapping table is loaded and solidified during system initialization. The core function of this mechanism is to establish a unified, stable, and immutable scheduling semantic foundation from the very beginning of system startup, thereby completely eliminating priority ambiguity caused by platform differences. Since the AUTOSAR adaptive platform (AP) and the classic platform (CP) differ fundamentally in their scheduling models, task abstractions, and priority representations, dynamically resolving or converting priorities at runtime can easily introduce inconsistent or even erroneous scheduling behavior. By solidifying the mapping table during initialization (e.g., by writing it to read-only memory or a configuration partition), the system ensures that all services—regardless of whether they are initially initiated by AP or CP—are assigned a globally unique scheduling priority that strictly corresponds to their functional safety criticality level when entering the scheduling engine. This "one-time definition, consistent throughout" design guarantees the continuity and determinism of cross-platform service call chains at the scheduling level, avoiding task delays, resource allocation imbalances, or service chain breaks caused by priority mismatches. It is a crucial prerequisite for achieving end-to-end functional safety and reliable collaboration.

[0048] In some embodiments of this application, when a low-criticality service is interrupted, its execution context is saved, and the execution of the low-criticality service is resumed after the high-criticality service has been completed.

[0049] Specifically, the core function of this mechanism is to achieve "recoverability" and "non-destructiveness" during resource preemption, thereby ensuring the real-time performance of highly critical services while maintaining the functional integrity and user experience of less critical services. Specifically, when the system triggers resource preemption due to a highly critical service approaching its deadline, it does not simply terminate the less critical service (such as entertainment applications or background network tasks). Instead, the operating system or scheduling engine completely saves the service's current execution state (including program counter, register contents, stack information, and other context data) into memory. After the highly critical service completes and releases the preempted computing resources, the system can accurately restore the execution state of the less critical service, allowing it to continue running from the point of interruption, rather than restarting or discarding the task. This context saving and restoration mechanism avoids data loss, logical errors, or user-perceived lag caused by frequent preemption of less critical services, improving the overall robustness and service continuity of the system. It also reflects the comprehensive balance between efficiency and fairness, security and availability in dynamic scheduling presented in this application.

[0050] In some embodiments of this application, the preset deadline threshold is set according to the ASIL level of the highly critical service. The higher the ASIL level, the stricter the corresponding deadline threshold.

[0051] Specifically, the core function of this design is to directly map the risk classification principles in functional safety standards to the real-time monitoring mechanism of the scheduling system, achieving precise alignment between safety requirements and scheduling strategies. Specifically, the ISO 26262 standard classifies functions into different ASIL levels (A to D, with D being the highest risk) based on the severity, probability of exposure, and controllability of potential hazards. Different levels of safety functions have significantly different response time requirements—for example, ASIL-D level Automatic Emergency Braking (AEB) must complete the perception, decision-making, and execution loop within a very short time, otherwise it may directly lead to personal injury or death; while ASIL-B level functions allow for a relatively relaxed time window. Therefore, this application configures deadline thresholds matching the risk level of services at different ASIL levels (e.g., a 10ms warning threshold for ASIL-D and a 30ms threshold for ASIL-B), enabling the dynamic scheduling engine to intervene in resource preemption before the true "critical" point, thus avoiding resource fluctuations caused by premature preemption and preventing safety failures caused by delayed intervention. This mechanism, which sets thresholds based on ASIL levels, ensures that scheduling behavior always serves functional safety objectives and improves the system's adaptability and reliability in complex operating scenarios.

[0052] In some embodiments of this application, highly critical services include Automatic Emergency Braking (AEB), collision warning, or braking control services. Low-critical services include network packet processing, in-vehicle entertainment, or climate control services.

[0053] Specifically, highly critical services include Automatic Emergency Braking (AEB), collision warning, and braking control services, which are directly related to driving safety and personal protection. These services are typically rated at ASIL-B or higher functional safety levels, and their correct and timely execution directly affects whether traffic accidents can be avoided or mitigated. Therefore, they must receive the highest priority and strongest resource guarantees in dispatch strategies. By listing these typical highly critical functions, this application emphasizes the core objects that the dispatch method must prioritize protecting, and provides a clear service classification basis for subsequent resource allocation, preemption mechanisms, and deadline monitoring, making the technical solution more targeted and engineering feasible.

[0054] Meanwhile, low-critical services include network packet processing, in-vehicle entertainment, or air conditioning control services. These services can be delayed, interrupted, or flexibly scheduled when resources are scarce. These services fall under the QM (Quality Management) level, do not involve functional safety risks, and even brief interruptions will not endanger vehicle operation safety or occupant lives. Using them as the primary carriers in the elastic resource pool not only makes reasonable use of the system's idle computing power but also ensures unimpeded resource release when high-critical services are needed. This classification example based on actual in-vehicle functions not only enhances the understandability and feasibility of the technical solution but also demonstrates the application's consideration of both overall system efficiency and user experience under safety constraints.

[0055] Secondly, refer to Figure 2 This application provides a critical service scheduling system for Service-Oriented Architecture (SOA), including a service classification module, a priority mapping module, a resource allocation decision module, and an execution monitor.

[0056] The service classification module receives service requests from either the Adaptive Platform (AP) or the Classic Platform (CP), with each request associated with a functional safety criticality level. Its core function is to receive these requests and identify the associated functional safety criticality level (e.g., ASIL or QM) for each request. This module ensures that all services entering the scheduling process carry clear safety attribute labels, providing fundamental input for subsequent priority determination and resource allocation. By completing service classification in the early stages of the system, this module lays the data foundation for unified cross-platform scheduling, preventing service attribute loss or misjudgment due to platform heterogeneity.

[0057] The priority mapping module maps the criticality level of service requests to a unified scheduling priority based on a pre-defined AP / CP cross-platform priority mapping table. High-criticality services correspond to ASIL-B or higher, while low-criticality services correspond to QM. The module addresses the inconsistency in scheduling semantics between the AP and CP platforms. Using the AP / CP cross-platform priority mapping table pre-defined and fixed during system initialization, this module converts the functional safety criticality levels (such as ASIL-C, QM, etc.) of service requests from different sources into a unified numerical scheduling priority within the system. ASIL-B and above are mapped to high priority, while QM corresponds to low priority. This standardized mapping mechanism ensures that the same function has the same priority in scheduling decisions regardless of whether it originates on the AP or CP, thus guaranteeing the scheduling continuity and determinism of the end-to-end service chain and serving as a crucial bridge for achieving cross-platform collaborative scheduling.

[0058] The resource allocation decision module, based on a unified scheduling priority, allocates dedicated physical computing resources to high-critical services or schedules them to high-priority execution threads, while placing low-critical services in an elastic resource pool. The resources in the elastic resource pool are derived from computing resources not occupied by high-critical services. The module implements differentiated resource management strategies based on the unified scheduling priority. For high-critical services, this module allocates dedicated physical computing resources (such as exclusive CPU cores) or schedules them to high-priority execution threads in the operating system to achieve hardware-level isolation and deterministic execution. For low-critical services, they are included in the elastic resource pool, which dynamically aggregates all idle computing resources not occupied by high-critical services. The core significance of this module is to maximize the utilization of system resources while strictly ensuring functional safety, avoiding the resource waste caused by traditional static partitioning, and achieving synergistic optimization of security and efficiency.

[0059] The execution monitor is used to monitor the execution status of highly critical services in real time. When it detects that the response time of a service is approaching a preset deadline threshold, it performs resource preemption, including: reclaiming resources from the elastic resource pool, interrupting ongoing low-critical services, and reallocating the reclaimed resources to the highly critical services. The execution monitor is responsible for real-time tracking and risk warning of the operational status of highly critical services. Its main function is to continuously monitor the response time of highly critical services and, when it detects that the response time is approaching a preset deadline threshold, immediately trigger a resource preemption mechanism: interrupting ongoing low-critical services from the elastic resource pool, reclaiming the computing resources they occupy, and reallocating these resources to highly critical services facing timeout risks. This module gives the system dynamic intervention capabilities, enabling scheduling strategies to adapt to changes in runtime load, strengthening the protection of safety-critical tasks at critical moments, effectively preventing functional safety failures caused by resource contention, and significantly improving the real-time reliability and robustness of the system.

[0060] In some embodiments of this application, the execution monitor continuously collects the response time and completion status of highly critical services and feeds the monitoring data back to the resource allocation decision module to trigger resource preemption decisions.

[0061] Specifically, the execution monitor not only monitors the execution status of highly critical services in real time, but also continuously collects key operational metrics such as response time and task completion status, and proactively feeds this monitoring data back to the resource allocation decision module. The purpose of this mechanism is to construct a closed-loop dynamic scheduling control circuit: based on the real-time performance data provided by the execution monitor, the resource allocation decision module can accurately determine whether highly critical services are at risk of timeout, thereby triggering resource preemption decisions at the appropriate time, rather than relying on static thresholds or periodic polling. This data-driven feedback mechanism significantly improves the responsiveness and decision accuracy of the scheduling system, ensuring that resource preemption is neither too early (avoiding unnecessary interruption overhead) nor too late (preventing security function failure), thus achieving more refined and reliable real-time protection for highly critical services.

[0062] In some embodiments of this application, during the execution of the Automatic Emergency Braking (AEB) service chain, when the LiDAR sensing service is triggered, the service classification module receives the service request from the AP platform and identifies its associated high functional safety criticality level (such as ASIL-D). The priority mapping module maps it to a unified high scheduling priority within the system according to a preset AP / CP cross-platform priority mapping table. The resource allocation decision module then binds the service to a dedicated physical CPU core to ensure its immediate and uninterrupted execution. Subsequently, the planning decision service is invoked, and after service classification and priority mapping, it is scheduled to a high-priority execution thread by the resource allocation decision module. However, if a low-critical service (such as network packet processing) occupies shared computing resources, causing the planning decision service to respond slowly, the execution monitor will continuously collect its response time. When it detects that the time is close to the preset deadline threshold, it will feed back the monitoring data to the resource allocation decision module. The resource allocation decision module will then make a preemption decision, reclaim the resources occupied by the low-critical service that is currently executing from the elastic resource pool, interrupt its execution, and redistribute the reclaimed resources to the planning decision service. As a result, the planning service can quickly complete the calculation, trigger the braking actuator service in a timely manner, significantly shorten the end-to-end response latency, effectively avoid collisions, and fully demonstrate the technical advantages of this application in functional safety assurance and dynamic resource scheduling.

[0063] In summary, the key service scheduling method and system for Service-Oriented Architecture (SOA) provided in this application have the following technical effects.

[0064] The critical service scheduling method and system provided in this application for Service-Oriented Architecture (SOA) effectively solve core problems in existing technologies, such as the easy blocking of highly critical services, low resource utilization, and inconsistent scheduling between AP / CP platforms. By allocating dedicated physical computing resources or high-priority threads to highly critical services of ASIL-B and above (such as automatic emergency braking and braking control), and combining strict deadline thresholds based on ASIL levels with dynamic preemption mechanisms, it ensures that these services can be executed in a timely manner under any load conditions, meeting the stringent real-time requirements of functional safety. Simultaneously, by leveraging a unified AP / CP cross-platform priority mapping table, the system solidifies priority semantics during the initialization phase, ensuring that the same service has a consistent priority throughout the system regardless of whether it originates from the AP or CP platform, thereby avoiding service call chain breaks and improving the reliability of cross-platform collaboration.

[0065] Furthermore, this solution constructs an elastic resource pool to dynamically allocate computing resources not occupied by high-critical services to QM-level low-critical services (such as entertainment and network packet processing), and immediately reclaims them when needed by high-priority tasks, significantly improving the overall utilization of hardware resources. Resource preemption is strictly limited to a unidirectional flow from high-critical services to low-critical services, ensuring that functional safety isolation constraints are not violated; simultaneously, when low-critical services are interrupted, their execution context is preserved, and execution is resumed subsequently, balancing system efficiency and service integrity. Overall, this method, while strictly adhering to the ISO 26262 safety standard, achieves an organic unity of security, real-time performance, and resource efficiency, making it suitable for resource-constrained and safety-critical automotive electronic systems.

[0066] It should be noted that in all specific embodiments of this application, all data processing activities related to user identity or personal characteristics, such as user information, user behavior data, historical data, and location information, will be conducted in accordance with the principles of legality, legitimacy, and necessity. All data collection, use, storage, and processing will be subject to compliance with applicable national and regional laws, regulations, and industry standards, and informed consent from users will be obtained in a clear and explicit manner before processing. For the processing of sensitive personal information, separate consent from users will be obtained through prominent means such as pop-up prompts and independent confirmation pages. If any processing conflicts with laws and regulations, the laws and regulations will prevail, and necessary data processing will only be carried out within the scope permitted by laws and regulations, ensuring that all data-based applications, analyses, and technical implementations are conducted within the scope permitted by laws and regulations.

[0067] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0068] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0069] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0070] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0071] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), 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). Additionally, computer-readable media can even be paper or other suitable media on which programs can be printed, for example, by optically scanning the paper or other media, then editing, interpreting, or, if necessary, processing it in a suitable manner to obtain the program electronically, and then storing it in computer memory.

[0072] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program 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.

[0073] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. 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.

[0074] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0075] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A key service scheduling method for a service-oriented architecture (SOA), applied to a vehicle-mounted electronic system in a mixed deployment of an adaptive platform (AP) supporting AUTOSAR and a classic platform (CP), characterized in that, The method comprises the following steps: receiving a service request from an AP platform or a CP platform, the service request being associated with a functional safety criticality level; mapping the criticality level of the service request to a unified scheduling priority according to a preset AP / CP cross-platform priority mapping table, wherein a high criticality service corresponds to an ASIL-B or higher level, and a low criticality service corresponds to a QM level; allocating a dedicated physical computing resource for the high criticality service or scheduling the high criticality service to a high-priority execution thread based on the unified scheduling priority, and running the low criticality service in an elastic resource pool, the resource of the elastic resource pool being derived from a computing resource that is not occupied by the high criticality service; monitoring the execution state of the high criticality service in real time, and when detecting that the response time of the high criticality service approaches a preset deadline threshold, performing resource preemption, including: recycling resources from the elastic resource pool, interrupting the execution of the low criticality service, and reallocating the recycled resources to the high criticality service.

2. The method of claim 1, wherein the key service of the service-oriented architecture (SOA) is scheduled. The dedicated physical computing resource is an independent CPU physical core, which is used to bind the high criticality service to prevent the high criticality service from being blocked by other services.

3. The method of claim 1, wherein the key service of the service oriented architecture (SOA) is scheduled by, The computing resource in the elastic resource pool is in an idle state when the high criticality service does not occupy the computing resource, and is dynamically allocated to the low criticality service; when the high criticality service needs resources, the idle resource can be immediately recycled.

4. The method of claim 1, wherein the key service of the service oriented architecture (SOA) is scheduled by, The resource preemption is allowed to be performed only from the high criticality service to the low criticality service in one direction, and any form of preemption of resources of the high criticality service by the low criticality service is prohibited, so as to meet the functional safety isolation constraint and ensure that the functional safety target is not violated due to pursuit of resource efficiency.

5. The method of claim 1, wherein the key service of the service oriented architecture (SOA) is scheduled by, The AP / CP cross-platform priority mapping table is loaded and solidified in an initialization stage, so that the priority of the same service remains consistent whether the service is called in the AP platform or the CP platform.

6. The method of claim 1, wherein the key service of the service oriented architecture (SOA) is scheduled by, When the low criticality service is interrupted, the execution context of the low criticality service is saved, and the execution of the low criticality service is restored after the execution of the high criticality service is completed.

7. The method of claim 1, wherein the key service of a service-oriented architecture (SOA) is scheduled. The preset deadline threshold is set according to the ASIL level to which the high criticality service belongs, and the higher the ASIL level, the stricter the corresponding deadline threshold.

8. The method of claim 1, wherein the key service of the service oriented architecture (SOA) is scheduled. The high criticality service includes an automatic emergency braking (AEB) service, a collision warning service, or a braking control service; and the low criticality service includes a network message processing service, a vehicle entertainment service, or an air conditioning adjustment service.

9. A critical service dispatch system for a service oriented architecture (SOA), the system comprising: a service broker configured to: receive a request for a critical service; determine a service provider for the critical service; and dispatch the critical service to the service provider. The system comprises a service grading module, a priority mapping module, a resource allocation decision module, and an execution monitor. The service grading module is configured to receive a service request from an AP platform or a CP platform, the service request being associated with a functional safety criticality level. The priority mapping module is configured to map the criticality level of the service request to a unified scheduling priority according to a preset AP / CP cross-platform priority mapping table, wherein a high criticality service corresponds to an ASIL-B or higher level, and a low criticality service corresponds to a QM level. The resource allocation decision module is configured to allocate a dedicated physical computing resource for the high criticality service or schedule the high criticality service to a high-priority execution thread based on the unified scheduling priority, and run the low criticality service in an elastic resource pool, the resource of the elastic resource pool being derived from a computing resource that is not occupied by the high criticality service. The resource allocation decision module is configured to allocate dedicated physical computing resources or schedule to high-priority execution threads for high-criticality services based on the unified scheduling priority, while placing low-criticality services in an elastic resource pool for running, the resources of the elastic resource pool being derived from computing resources not occupied by high-criticality services. The execution monitor is configured to monitor the execution state of high-criticality services in real time, and when detecting that the response time of a high-criticality service approaches a preset deadline threshold, perform resource preemption, including: recovering resources from the elastic resource pool, interrupting the execution of low-criticality services, and reallocating the recovered resources to the high-criticality service.

10. The critical service dispatch system for service-oriented architecture (SOA) according to claim 9, wherein, The execution monitor continuously collects the response time and completion of high-criticality services, and feeds back the monitoring data to the resource allocation decision module to trigger resource preemption decisions.

Images