A traffic control terminal operating system component automatic tailoring method and system

Abstract

The application discloses a traffic control terminal operating system component automatic cutting method and system, and belongs to the technical fields of embedded operating systems and intelligent traffic. In view of the problems that the general declaration dependency is inconsistent with the actual necessary dependency of a target terminal, direct recursive expansion leads to excessive reservation, and the required components are mistakenly deleted and recovered, candidate cross-layer relationships are established from operating system source code and construction information, the current necessary relationship is determined in combination with target terminal function requirements, hardware conditions and hard constraints, and a target component set is solved, product, construction, drive, kernel, startup, security and image configuration are generated together, construction, startup, business and abnormal recovery verification are executed, when verification fails, a to-be-confirmed correction item is formed, necessary relationships or hard constraints are locked after reproduction confirmation, and re-solving is performed, when correction content cannot be determined, a failure scheme is recorded to continue trying other schemes, excessive reservation is reduced, and the risk of mistakenly cutting necessary components is reduced. The method is used for traffic control terminal operating system component automatic cutting.

Description

Technical Field

[0001] This invention belongs to the field of embedded operating systems and intelligent transportation technology, and in particular relates to a method and system for automatically tailoring operating system components for traffic control terminals. Background Technology

[0002] General-purpose operating systems, designed to adapt to different hardware platforms and application scenarios, typically include numerous subsystems, services, drivers, and optional functions. For dedicated terminals with limited resources and relatively fixed functions, directly deploying a complete system would retain many components unrelated to the target task, increasing image size, resource consumption, and unnecessary services and interfaces. Traffic control terminals are highly industry-specific, with significant differences in hardware and functional combinations among different terminals. Traffic signal controllers primarily utilize serial ports, CAN (Controller Area Network), time synchronization, and watchdog capabilities, while electronic police systems focus on image acquisition, encoding, storage, and network transmission. Integrated radar and video surveillance systems also involve radar, GPU (Graphics Processing Unit) / NPU (Neural Processing Unit), and high-precision time synchronization. Therefore, the baseline source code for the same operating system needs to be specifically configured and tailored for each terminal.

[0003] Existing component-based operating systems can already configure, expand dependencies, and build systems based on preset component relationships. However, when automatically tailoring for specific traffic control terminals, the general declared dependencies are not entirely consistent with the actual necessary dependencies of the target terminal. The declared dependencies in component metadata or build files may be affected by hardware conditions and optional functions. If all declared relationships are directly expanded recursively, it is easy to introduce components unrelated to the target task, resulting in excessive retention. Deleting components based solely on static relationships or normal operating paths may lead to incorrect deletion. Although some components are not called in daily operations, they may still be necessary during startup, dynamic loading, exception handling, fault degradation, or recovery. Deleting them may cause startup, operation, or recovery failures.

[0004] The lack of an automatic closed loop between the trimming results and the actual configuration and verification results means that adding or removing components simultaneously affects the build target, driver, kernel, startup, security, and image configurations. When anomalies occur, manual component restoration, dependency investigation, and modification of multiple configurations are typically required. Furthermore, verification results are difficult to directly use for the next round of solving. In actual engineering, trimming criteria are scattered across hardware documentation, source code, component and build configurations, driver and kernel configurations, startup configurations, and the runtime environment. Existing component dependencies and build relationships primarily target general source code baselines or general products and cannot be directly considered as the actual necessary relationships for specific terminals. Therefore, a method is needed that targets specific terminals, determining the actual necessary relationships from candidate dependencies in general source code and the build system. This method should reduce the retention of irrelevant components while avoiding the omission of components required for build, runtime, and anomaly recovery, and then re-solve the problem using the verification results to correct the dependency model. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention proposes a method and system for automatically trimming operating system components for traffic control terminals, thereby resolving the issues present in the prior art.

[0006] In a first aspect, to achieve the above objectives, the present invention provides a method for automatically trimming components of a traffic control terminal operating system, comprising the following steps: S1. Extract candidate cross-layer relationships from operating system source code, component metadata, and build configuration; S2. Based on the functional requirements, hardware conditions, and established deployment conditions of the target terminal, determine the relationship applicable to the target terminal among the candidate cross-layer relationships as the current necessary relationship, and determine the candidate component set; S3. Within the candidate component set, the target component set is obtained from feasible solutions that satisfy all hard constraints; S4. Generate system configuration based on the target component set; S5. Construct the target system according to the system configuration, and perform startup verification, business verification, and anomaly recovery verification; S6. When verification fails, a correction item to be confirmed is generated. After reproduction and verification, the necessary relationship or hard constraint is updated and the solution is transferred to S2. If the correction content cannot be determined and there are other feasible solutions, the current solution is recorded as a failed solution and the solution is transferred to S3. The solution ends when the termination condition is met.

[0007] Optionally, in S1, the candidate cross-layer relationship extraction process is performed as follows: a cross-layer dependency graph is established by taking functional requirements, target system capabilities, operating system components or services, device drivers, kernel capabilities, and hardware resources as nodes; the requirements, implementations, dependencies, or support relationships between the nodes are extracted from business capability mapping, component metadata, product and build configurations, link results, driver and kernel configurations, and target terminal running information, and the relationship type, applicable conditions, and necessity status are recorded.

[0008] Optionally, in S2, the process of determining the current necessary relationship is performed as follows: the target capability set is determined according to the mapping rules between functional requirements and target system capabilities; the candidate cross-layer relationship is determined according to the functional requirements, hardware conditions and determined deployment conditions to determine whether it is applicable to the target terminal, and the applicable relationship is taken as the current necessary relationship; for dependency relationships that are not yet determined to be effective, they are determined together when solving the component.

[0009] Optionally, in S2, the candidate component set determination process is performed as follows: determining components that can directly provide the target capabilities in the target capability set; obtaining the components required for dependency closure along the current necessary relationships; and filtering and supplementing the candidate component set by combining hardware compatibility conditions, prohibited items, security or recovery mandatory items, and alternative implementation relationships.

[0010] Optionally, in S3, the process of obtaining the target component set from feasible solutions that satisfy all hard constraints is performed by: screening feasible solutions from the candidate component set that satisfy the target capability coverage, necessary dependency closure, component conflict, hardware compatibility, security and recovery requirements, verification locking requirements, and resource boundaries; and selecting the target component set from the feasible solutions according to the number of components, image volume, or resource consumption index.

[0011] Optionally, in S4, the system configuration generation process is executed as follows: based on the target component set, the cross-layer dependency graph, and hardware conditions, the component selection results are implemented into product component and feature configuration, build and installation targets, device drivers and device trees, kernel configuration, system services and startup items, security configuration, and image installation list; when retaining components or capabilities, their required configurations are retained simultaneously, and when trimming, only configuration items specific to the trimmed object and no longer depended on by other retained objects are removed.

[0012] Optionally, in S5, the process of performing startup verification, business verification, and anomaly recovery verification uses a verification set, which covers the normal business path and the preset anomaly and recovery path. When verification fails, the failure type is determined based on the failure location and logs. The failure types are: missing construction target, link failure, dynamic library loading failure, missing system service or inter-process communication, missing startup item, inaccessible device node, business function failure, anomaly, downgrade, or recovery failure.

[0013] Optionally, in S6, the process verified by reproduction is executed as follows: keeping other conditions unchanged, the relationship or component related to this failure is restored and the verification is repeated; if the failure disappears, the corrected and valid relationship or hard constraint is added to the lock item set and the solution is resolved; if the failure still exists, the corrected item is not locked and the location continues; the locked items in the lock item set are not revoked in subsequent iterations; when the corrected content cannot be determined, the current solution is recorded as a failed solution, and the failed solution is not selected again in subsequent solutions.

[0014] Secondly, the present invention also provides an automatic trimming system for operating system components of a traffic control terminal, comprising: The candidate cross-layer relationship construction and determination module is used to extract candidate cross-layer relationships from operating system source code, component metadata and build configuration, determine the necessary relationships and determine the candidate component set based on the functional requirements, hardware conditions and determined deployment conditions of the target terminal; The target component solving module is used to obtain the target component set from the feasible solutions that satisfy all hard constraints within the candidate component set; A configuration generation module is used to generate system configuration based on the target component set; The verification feedback module is used to construct the target system according to the system configuration and perform startup verification, business verification and anomaly recovery verification. When the verification fails, a correction item to be confirmed is generated. After the necessary relationship or hard constraint is confirmed by reproduction verification, the necessary relationship or hard constraint is updated and the candidate cross-layer relationship construction and judgment module and the target component solving module are re-executed. When the correction content cannot be determined and there are other feasible solutions, the current solution is recorded as a failed solution and the target component solving module is triggered to continue solving.

[0015] Compared with the prior art, the present invention has the following advantages and technical effects: This invention provides an automatic component trimming method and system for a traffic control terminal operating system. It uses general declarative relationships as candidate relationships and determines the currently necessary relationships based on the target terminal's functions and hardware conditions. This reduces the expansion of irrelevant components caused by directly recursively declarative dependencies and minimizes excessive retention. Verification simultaneously covers normal business operations and necessary exception, degradation, and recovery paths, identifying components only needed during startup, fault handling, or recovery phases. This reduces the risk of deletion based solely on static analysis or normal operation observations and minimizes the risk of incorrect trimming of necessary components. The target component set is linked to the build, driver, kernel, startup, security, and image configurations, reducing build or runtime anomalies caused by inconsistencies between component decisions and actual system configurations, ensuring the trimming results are truly implemented. If verification fails, only confirmed necessary relationships or hard constraints are locked into subsequent models and re-solved. If new corrections cannot be determined temporarily, failed solutions can be skipped, and other solutions can be tried. Confirmed necessary items are not revoked, and failed solutions are not repeatedly selected, forming an iterative and terminateable automatic correction closed loop. Attached Figure Description

[0016] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart illustrating an automatic trimming method for a traffic control terminal operating system component according to an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the determination of candidate cross-layer relationships and current necessary relationships in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the verification feedback correction and re-solution in an embodiment of the present invention. Detailed Implementation

[0017] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0018] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0019] like Figure 1 As shown, this embodiment provides a method for automatically trimming operating system components of a traffic control terminal, including: S1. Extract candidate cross-layer relationships from operating system source code, component metadata, and build configuration; S2. Based on the functional requirements, hardware conditions, and established deployment conditions of the target terminal, determine the relationship applicable to the target terminal among the candidate cross-layer relationships as the current necessary relationship, and determine the candidate component set; S3. Within the candidate component set, the target component set is obtained from feasible solutions that satisfy all hard constraints; S4. Generate system configuration based on the target component set; S5. Construct the target system according to the system configuration, and perform startup verification, business verification, and anomaly recovery verification; S6. When verification fails, a correction item to be confirmed is generated. After reproduction and verification, the necessary relationship or hard constraint is updated and the solution is transferred to S2. If the correction content cannot be determined and there are other feasible solutions, the current solution is recorded as a failed solution and the solution is transferred to S3. The solution ends when the termination condition is met.

[0020] Furthermore, in S1, the candidate cross-layer relationship extraction process is performed as follows: functional requirements, target system capabilities, operating system components or services, device drivers, kernel capabilities, and hardware resources are used as nodes to establish a cross-layer dependency graph; the requirements, implementation, dependency, or support relationships between the nodes are extracted from business capability mapping, component metadata, product and build configuration, linking results, driver and kernel configuration, and target terminal running information, and the relationship type, applicable conditions, and necessity status are recorded.

[0021] Specifically, the implementation process of this embodiment includes: The core inputs in this embodiment include three types: Hardware requirements Describe the actual processor architecture, memory, storage, network interface, UART (Universal Asynchronous Receiver / Transmitter) / RS485 (Recommended Standard 485), CAN (Controller Area Network), RTC (Real-Time Clock), PTP (Precision Time Protocol) / PPS (Pulse Per Second), GPU (Graphics Processing Unit) / NPU (Neural Processing Unit), camera, radar, display, audio, watchdog timer, security chip, and other peripherals of the target terminal. Functional requirements : Describe the business functions that the target terminal needs to perform, such as signal control, status acquisition, platform communication, time synchronization, local caching, fault recovery, device authentication, and log auditing; Initial hard constraints : Describes the resource, performance, security, reliability, and compatibility conditions that component trimming must meet and cannot be compensated for by general optimization goals, such as image size limits, memory limits, latency limits, security retention requirements, and recovery requirements.

[0022] When compatibility with existing business applications is required, the existing software runtime environment R can be further obtained, including shared libraries, system services, application programming interfaces (APIs), inter-process communication (IPC) interfaces, device nodes, configuration files, and startup items that the business applications depend on. This item is optional input.

[0023] Establish a set of rules for mapping functional requirements to system capabilities For each functional requirement The mapping rules determine one or more system capabilities required to form a target capability set: ; in, For the set of target capabilities; This is a set operation that takes the union of the mapping results of each functional requirement f in F; A set of rules for mapping functional requirements to system capabilities; A set of functional requirements; For any functional requirement in F; This can be established based on business interface specifications, product capability catalogs, and existing project configurations. The mapping between functional requirements and target capabilities constitutes the first layer of the cross-layer dependency model; functional requirements It is a fixed input for the target terminal and is not used as a decision variable for component selection.

[0024] Taking traffic signal controllers as an example, the function-capability mapping is shown in Table 1.

[0025] Table 1 Furthermore, in S2, the process of determining the current necessary relationship is executed as follows: the target capability set is determined according to the mapping rules between functional requirements and target system capabilities; the candidate cross-layer relationship is determined according to the functional requirements, hardware conditions and determined deployment conditions to determine whether it is applicable to the target terminal, and the applicable relationship is taken as the current necessary relationship; for dependency relationships that are not yet determined to be effective, they are determined together during component solving.

[0026] Specifically, such as Figure 2 As shown, the implementation process of this embodiment includes: Suppose that the operating system can select the following set of components: ; in, A collection of optional components for the operating system; This is the first optional component; This is the nth optional component; This represents the total number of optional components.

[0027] Each component records attributes such as component identifier, provided system capabilities, and necessary resource overhead; the relationships between components and other components, drivers, kernel capabilities, and hardware are uniformly described by a cross-layer dependency model.

[0028] Establish a cross-layer dependency graph: ; Where G is the cross-layer dependency graph; V is the set of nodes; and E is the set of edges. It is a set of relation attributes used to record relation type, applicable conditions, and necessity status.

[0029] The node set is represented as: ; in, , , , , , These respectively represent functional requirements, target system capabilities, operating system components or services, device drivers, kernel capabilities, and hardware resource nodes; This indicates the needs, implementations, dependencies, or support relationships between the aforementioned objects.

[0030] Typical cross-layer relationships include: platform communication → network communication capabilities → network system components → Ethernet driver → kernel network capabilities → Ethernet hardware.

[0031] Candidate cross-layer relationships can be extracted from business capability mappings, component metadata, product and build configurations, link results, driver and kernel configurations, and target terminal runtime information. Product configurations, build files, startup configurations, security policies, and image installation manifests primarily serve as relationship sources or configuration generation objects and are generally not used as graph nodes. All of the above relationships are considered candidate relationships upon their first acquisition and are not directly used as the basis for mandatory retention.

[0032] Based on the target terminal's functional requirements, hardware conditions, and established deployment conditions, determine whether candidate relationships are applicable to the current terminal. Applicable relationships are included as necessary relationships in the solution process; for dependencies whose effectiveness is not yet determined, they are assessed during component solving.

[0033] The necessity of candidate relationships can be revised based on the results of subsequent construction, linking, operation, and anomaly recovery verification. Relationships, capability requirements, or hard constraints that are verified to be essential to the current target system are added to the lockout set. When the target terminal conditions remain unchanged, subsequent iterations must not revoke confirmed locks, therefore... The absence of a relevant call during a single normal operation does not automatically mean that a relationship or component can be deleted. Here, k represents the iteration round. Let k be the set of locked items in round k. This is the set of locked items in the (k+1)th round.

[0034] Furthermore, in S2, the candidate component set determination process is performed as follows: determining components that can directly provide the target capabilities in the target capability set; obtaining the components required for dependency closure along the current necessary relationships; and filtering and supplementing the candidate component set by combining hardware compatibility conditions, prohibited items, security or recovery mandatory items, and alternative implementation relationships.

[0035] Specifically, the implementation process of this embodiment includes: The candidate component set is determined based on the target capability, current necessary relationships, hardware conditions, and hard constraints, thus narrowing the scope of subsequent solutions.

[0036] First, identify the components that can directly provide the target capabilities: ; in, A collection of components that directly provide the target capabilities; Let C be the i-th optional component; C is the set of optional components; For components The set of system capabilities that can be provided; A is the target set of capabilities; i is the component number.

[0037] Then, obtain the components required for dependency closure by following the current necessity relationship: ; in, The set of components obtained after completing dependency closure along the current necessity relationship; It depends on closure operations; A collection of components that directly provide the target capabilities; This represents the set of currently necessary relations for component solving in round k; k is the iteration round. "Dependency closure" means including lower-level components necessary for the operation of a known component in the candidate scope. For dependencies whose necessity is not yet determined, the components they may involve are retained and their selection is decided during the solution process.

[0038] By further filtering and supplementing based on hardware compatibility, prohibited items, security or recovery requirements, and alternative implementation relationships, a set of candidate components is obtained: ; in, Let k be the set of candidate components. To perform filtering and supplementary processing according to hardware conditions and hard constraints; A collection of components that directly provide the target capabilities; H represents the set of components obtained after dependency closure; H represents the hardware conditions. Let k be the set of hard constraints that must be satisfied in the kth round; k is the iteration round.

[0039] Component branches that do not meet the necessary hardware requirements and have no alternative implementations can be directly excluded; components that are irrelevant to the target capability and are no longer depended on by retained components will not be included in the current candidate set.

[0040] Furthermore, in S3, the process of obtaining the target component set from feasible solutions that satisfy all hard constraints is performed by: screening feasible solutions from the candidate component set that satisfy the target capability coverage, necessary dependency closure, component conflict, hardware compatibility, security and recovery requirements, verification locking requirements, and resource boundaries; and selecting the target component set from the feasible solutions according to the number of components, image volume, or resource consumption index.

[0041] Specifically, the implementation process of this embodiment includes: In the candidate component set Internally, the current constraints are divided into hard constraints that must be satisfied. The optimization objective used to compare feasible solutions .

[0042] First, select feasible solutions that satisfy all hard constraints, and then determine the target component set from them: ; in, The set of target components selected in the kth round; X is any subset of candidate components; Let k be the set of candidate components. Let X be the optimization objective value for candidate solution X; This represents the solution that minimizes J among the candidate solutions that meet the feasibility conditions; k is the iteration round.

[0043] satisfy: ; in, Here, A represents the feasibility determination function; H represents the target capability set; and H represents the hardware conditions. This is the cross-layer dependency graph for the k-th round; Let X be the set of hard constraints in the k-th round; True indicates that candidate solution X satisfies all hard constraints.

[0044] Hard constraints may include target capability coverage, necessary dependency closure, component conflicts, hardware compatibility, security and anomaly recovery requirements, verification locking requirements, and explicit resource boundaries.

[0045] For dependencies with enable conditions, dependent components should only be retained if the conditions are met. Verified and confirmed necessities cannot be undone in subsequent solves; if the confirmed requirement is a capability rather than a specific component, it can be reselected from components that can provide that capability.

[0046] When multiple feasible implementations satisfy the hard constraints exist, the target solution can be selected based on indicators such as the number of components, image size, or resource consumption.

[0047] Furthermore, in S4, the system configuration generation process is executed as follows: based on the target component set, the cross-layer dependency graph, and hardware conditions, the component selection results are implemented in the product component and feature configuration, build and installation targets, device drivers and device trees, kernel configuration, system services and startup items, security configuration, and image installation list; when retaining components or capabilities, their required configurations are retained simultaneously, and when trimming, only configuration items specific to the trimmed object and no longer depended on by other retained objects are removed.

[0048] Specifically, the implementation process of this embodiment includes: Establish mapping rules from target component sets to actual system configuration objects It is used to apply the component selection results to product configuration, build target, driver or device tree, kernel configuration, system service or startup item, security configuration and image installation item.

[0049] Based on the target component set Cross-layer dependency model and hardware conditions , generate the first Wheel system configuration: ; in, Configure the system for round k; Configure mapping rules for target component sets to actual system objects; Let k be the set of target components. Let H be the cross-layer dependency graph of the k-th round; H represents the hardware conditions; and k represents the iteration round.

[0050] System configuration may include product components and features, build and installation targets, device drivers and device trees, kernel configuration, system services and startup items, security configuration and image installation list.

[0051] When preserving a component or capability, retain the configuration required for its operation; when pruning, only remove configuration items specific to that object that are no longer depended on by other preserved objects.

[0052] For example, when the target terminal does not have display hardware and the functional requirements do not include a local graphical interface, the relevant graphics components, build target, display driver, kernel display configuration, graphics boot service, and image installation items can be cancelled at the same time.

[0053] Furthermore, in S5, the process of performing startup verification, business verification, and anomaly recovery verification uses a verification set, which covers the normal business path and the preset anomaly and recovery path. When verification fails, the failure type is determined based on the failure location and logs. The failure types are: missing construction target, link failure, dynamic library loading failure, missing system service or inter-process communication, missing startup item, inaccessible device node, business function failure, anomaly, downgrade, or recovery failure.

[0054] Specifically, such as Figure 3 As shown, the implementation process of this embodiment includes: According to configuration Execute the target system construction and, based on the validation set Continue executing startup, business functions, and necessary exception recovery, security, and performance verifications, resulting in: ; in, This represents the verification result of the kth round; Verify(·) is the verification process; The system configuration for the k-th round is given; T is the validation set; and k is the iteration round.

[0055] The verification set optimization covers both normal business paths and preset abnormal and recovery paths to discover the necessary components required for normal operation and the startup, fault degradation, exception handling and recovery stages, and avoids accidental deletion due to calls not observed during normal operation.

[0056] When verification fails, identify potentially missing or incorrect dependencies, components, or hard constraints based on the failure location and logs, and treat these as items to be confirmed and corrected. Typical processing includes: Missing build target, linking failure, or dynamic library loading failure: Supplement or correct necessary dependencies between components, build targets, or libraries; Missing system services (such as System Ability in OpenHarmony), IPC interfaces, or startup items: Supplement or correct the relationships between components and system services or startup items; Device node inaccessible: Supplement or correct the relationship between components, drivers, kernel capabilities and hardware, or hardware constraints; Business function failure and incomplete capability decomposition: Supplement the relationship between functional requirements and target capabilities, and between target capabilities and components; Anomalies, downgrades, or recovery tests fail: Supplement the located recovery relationships or corresponding recovery hard constraints.

[0057] For items requiring confirmation, it is preferable to restore only the relationships or components related to this failure, while keeping other conditions unchanged, and repeat the same verification. If the previous failure disappears, the correction is confirmed as effective and added to the locked items; if only a certain capability is confirmed to be indispensable, capability coverage is added or a replacement implementation of the hard constraint is implemented. If the failure still exists, the correction item is not locked, and other causes are investigated.

[0058] Therefore, we can conclude that: ; in, This represents the amount of new or modified cross-layer relationships confirmed based on the verification results in the k-th round; This indicates the amount of new or modified hard constraints confirmed in round k; Feedback(·) represents the amount of data based on the verification results. Cross-layer dependency graph and system configuration Feedback processing generates corrections to be confirmed and outputs the confirmed correction amounts; k is the iteration round. Correspondingly: ; ; in, This is the corrected cross-layer dependency graph for the (k+1)th round. For the k-th round cross-layer dependency graph, ⊕ indicates that... The addition or modification relationship in the middle is applied to ; For the (k+1)th round of hard constraints, Let be the set of hard constraints in the k-th round, and ∪ represent the set of new hard constraints to be added. Merge into the current set of hard constraints. Used to emphasize that the set is a hard constraint that must be satisfied, and The meanings are the same.

[0059] After the model is updated, the necessary relationships are re-determined, candidate components are identified, the target component set is solved, and the configuration is generated, and then verified again. Validated locking items cannot be revoked in subsequent iterations. If verification still fails, and the dependencies or hard constraints that need correction cannot be determined temporarily, but other feasible solutions still exist, then the component and configuration combination in this round is recorded as a failed solution, and will not be repeated in subsequent iterations; other solutions will continue to be solved. The system simultaneously records candidate relationships, hard constraints, locking items, and failed solutions to identify and avoid recurring states.

[0060] When the target system passes the scenarios covered by the validation set T and satisfies all hard constraints, the target component set and system configuration are output; when there is no feasible component set, or after the validation fails, it is impossible to determine new dependencies or hard constraint corrections, or there are no other solutions to try, or when a repetitive state occurs or the preset iteration limit is reached, the reason for failure is output and the process terminates.

[0061] Candidate relations, candidate components, and discrete configuration items automatically selected by the algorithm are all taken from a finite set. Each iteration adds a confirmed lock item or records a new failed solution; confirmed lock items are not revoked, and failed solutions are not repeatedly selected, thus preventing repeated entry into the same state and allowing termination within a finite number of rounds. This termination only indicates that the algorithm will not loop infinitely; it does not guarantee that every input has a valid pruning solution.

[0062] Furthermore, in S6, the process verified through reproduction is executed as follows: keeping other conditions unchanged, the relationships or components related to this failure are restored and verified again; if the failure disappears, the corrected and valid relationships or hard constraints are added to the lock item set and the solution is resolved; if the failure still exists, the corrected items are not locked and the location continues; the locked items in the lock item set are not revoked in subsequent iterations; when the corrected content cannot be determined, the current solution is recorded as a failed solution, and the failed solution is not selected again in subsequent solutions.

[0063] Specifically, the implementation process of this embodiment includes: This invention does not limit the specific solver. For each component... Define a binary variable: ; in Representation Component Selected into the target component set Representation Component Not selected into the target component set; i is the component index.

[0064] Typical hard constraints include: Capability coverage constraints: ; Where a represents any target capability in the target capability set A; i represents the component index; For components The set of system capabilities provided; For components Binary choice variables; range of summation This represents the summation over all components that can provide capability a.

[0065] Necessary dependency constraints: If the current necessity relationship indicates that the target operation of a component requires another component, then: Validate locking constraints: Set of locked items has been added The necessary relationship or hard constraint must be satisfied in subsequent solutions; if the locked requirement is the target capability or alternative implementation requirement, then different components that satisfy the requirement can be selected.

[0066] ; in, For components with dependency requirements, The dependent components required to run for its target; , These are the binary selection variables for the two components; i and j are the component indices.

[0067] Conflict constraints: ; in, and As two conflicting components, , These are the binary selection variables for the two components; i and j are the component indices.

[0068] Hardware compatibility constraints: If component If the necessary hardware conditions do not exist in the target terminal, and there is no alternative implementation that satisfies the target capability, then the component is excluded from the current feasible set.

[0069] Hard constraints on resources: For resources that can be reliably measured by component or installation item, constraints can be directly established. For example, after eliminating duplicate measurement, the mirrored installation volume is expressed as: ; in, For components The installation size of the image is taken into account; For components Binary choice variables; The maximum allowed installation size for the target image; i is the component number.

[0070] For metrics such as RAM, startup time, and power consumption, which are significantly affected by operating load and shared resources, measurements can be taken as a whole system during the construction or board-side verification phase; when a reliable estimation model is available, these metrics can also be included in the solution constraints.

[0071] Among feasible solutions that satisfy all hard constraints, further optimization can be performed using metrics with clear measures, such as the number of components, image size, and resource consumption. Solutions can be obtained using integer linear programming, SAT (Boolean Satisfiability Problem) / SMT (Satisfiability Modulo Theories), constrained programming, or graph search, with the specific solver being the implementation method.

[0072] Based on the same general inventive concept, this invention also provides an automatic trimming system for traffic control terminal operating system components. The automatic trimming system for traffic control terminal operating system components provided by this invention is described below. The automatic trimming system described below can be referred to in conjunction with the automatic trimming method for traffic control terminal operating system components described above. The system includes: The candidate cross-layer relationship construction and determination module is used to extract candidate cross-layer relationships from operating system source code, component metadata and build configuration, determine the necessary relationships and determine the candidate component set based on the functional requirements, hardware conditions and determined deployment conditions of the target terminal; The target component solving module is used to obtain the target component set from the feasible solutions that satisfy all hard constraints within the candidate component set; A configuration generation module is used to generate system configuration based on the target component set; The verification feedback module is used to construct the target system according to the system configuration and perform startup verification, business verification and anomaly recovery verification. When the verification fails, a correction item to be confirmed is generated. After the necessary relationship or hard constraint is confirmed by reproduction verification, the necessary relationship or hard constraint is updated and the candidate cross-layer relationship construction and judgment module and the target component solving module are re-executed. When the correction content cannot be determined and there are other feasible solutions, the current solution is recorded as a failed solution and the target component solving module is triggered to continue solving.

[0073] The mapping between the general model and OpenHarmony project objects is shown in Table 2.

[0074] Table 2 The above objects can be used to extract or correct cross-layer dependencies, and can also be used to configure mapping rules. The engineering carrier will realize the target component set as the actual construction and deployment configuration of OpenHarmony.

[0075] Current source code scanning experiment: In the current OpenHarmony source code tree, using 23 basic components for signal controllers as seeds, scanning bundle.json yields 536 valid component metadata entries. If the transitive closure is recursively calculated directly along deps.components, the seed set expands to 297 components, including components such as Bluetooth, graphics, audio, video, and telephone, which are clearly mismatched with the target signal controller scenario.

[0076] This experiment shows that recursively expanding all declared dependencies in component metadata as necessary dependencies for the target terminal will result in a significant expansion of the candidate set. Therefore, relationships in general source code such as bundle.json are more suitable as sources of candidate relationships, and it is still necessary to consider the specific terminal's functionality, hardware, and actual build and execution results to determine whether they are currently necessary relationships.

[0077] The current experiment only demonstrates that direct recursive dependency declarations can cause set inflation; it does not prove that specific relationships such as Bluetooth, graphics, and audio can be deleted. Whether these relationships are necessary for building, linking, running, or abnormal recovery still needs to be determined through further verification.

[0078] Taking a traffic signal controller as an example, its hardware requirements include an ARM64 processor, 2GB of RAM, 8GB of storage, Ethernet, RS485, CAN, RTC, and a hardware watchdog, but it does not have Bluetooth, Wi-Fi, camera, audio, or local display.

[0079] Its functional requirements include: signal status acquisition; controlled command issuance; platform communication; PTP / NTP time synchronization; local status caching; device authentication and auditing; fault detection and recovery.

[0080] Hard constraints can be set according to the actual project, including resource limits, startup requirements, control link performance requirements, and security and recovery requirements; this embodiment does not use a fixed threshold as a necessary condition.

[0081] If the goal is to be compatible with existing signal controller service programs, you can further input the shared libraries, system services, interfaces, device nodes, and startup requirements that the service program actually depends on; if a newly developed service program is used, this input is not required.

[0082] According to the preset function-capability mapping rules, signal status acquisition and controlled command issuance can correspond to serial port / CAN communication capabilities, platform communication can correspond to network communication capabilities, PTP / NTP time synchronization can correspond to time synchronization capabilities, and fault detection and recovery can correspond to watchdog, startup recovery, and diagnostic capabilities.

[0083] Furthermore, serial / CAN communication capabilities can be associated with system I / O components or services, HDF (Hardware Driver Foundation) device drivers, kernel serial / CAN capabilities, and UART / CAN hardware and lighting control boards; network communication capabilities can be associated with network system components, Ethernet drivers, kernel network capabilities, and Ethernet controllers.

[0084] Based on the target capabilities, hardware conditions, and hard constraints, the candidate retained capabilities are shown in Table 3.

[0085] Table 3 Features and components to be removed include Bluetooth, Wi-Fi, graphical interface, window management, camera, audio, video, NFC, telephone, and testing tools. However, whether to remove them is determined by cross-layer dependencies, hard constraints, and verification results, not by a manual whitelist.

[0086] According to the configuration mapping rules, when the target terminal does not have a display device and the functional requirements do not include local display, the following can be simultaneously removed: graphics or window-related product components, build targets and function switches, display drivers, kernel display configurations, graphics and window services, as well as image files and exclusive policies that only serve the above-mentioned deleted objects.

[0087] Similarly, when the terminal does not have Bluetooth hardware and the functional requirements do not include Bluetooth communication, the Bluetooth components, drivers, protocol stack, services, permissions, and image installation items can be handled in a coordinated manner.

[0088] If the first round of pruning fails and it is found that a selected network component may be missing another build target, then that dependency is treated as a pending correction item. With other conditions unchanged, the build target is restored and the build is repeated. If the same failure disappears, the dependency is confirmed as necessary and locked, then the model is re-evaluated and solved based on the updated model. If the failure persists, the dependency is not locked, and other causes are investigated.

[0089] If normal business verification passes but fault recovery testing fails, and the missing recovery component or capability is identified, then the relevant component or service is recovered and the test is repeated. After verification, the corresponding relationships, capability requirements, or recovery hard constraints are added to the lock item set, and the complete component set is re-solved; if the specific component cannot be identified, only the corresponding capability requirements are locked.

[0090] The same method can also generate corresponding differentiated configurations and images based on the hardware conditions and functional requirements of terminals such as electronic police, radar-visual integrated machines, and intersection edge computing nodes.

[0091] This invention provides an automatic component trimming method and system for a traffic control terminal operating system. It uses general declarative relationships as candidate relationships and determines the currently necessary relationships based on the target terminal's functions and hardware conditions. This reduces the expansion of irrelevant components caused by directly recursively declarative dependencies and minimizes excessive retention. Verification simultaneously covers normal business operations and necessary exception, degradation, and recovery paths, identifying components only needed during startup, fault handling, or recovery phases. This reduces the risk of deletion based solely on static analysis or normal operation observations and minimizes the risk of incorrect trimming of necessary components. The target component set is linked to the build, driver, kernel, startup, security, and image configurations, reducing build or runtime anomalies caused by inconsistencies between component decisions and actual system configurations, ensuring the trimming results are truly implemented. If verification fails, only confirmed necessary relationships or hard constraints are locked into subsequent models and re-solved. If new corrections cannot be determined temporarily, failed solutions can be skipped, and other solutions can be tried. Confirmed necessary items are not revoked, and failed solutions are not repeatedly selected, forming an iterative and terminateable automatic correction closed loop.

[0092] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for automatically trimming components of a traffic control terminal operating system, characterized in that, Includes the following steps: S1. Extract candidate cross-layer relationships from operating system source code, component metadata, and build configuration; S2. Based on the functional requirements, hardware conditions, and established deployment conditions of the target terminal, determine the relationship applicable to the target terminal among the candidate cross-layer relationships as the current necessary relationship, and determine the candidate component set; S3. Within the candidate component set, the target component set is obtained from feasible solutions that satisfy all hard constraints; S4. Generate system configuration based on the target component set; S5. Construct the target system according to the system configuration, and perform startup verification, business verification, and anomaly recovery verification; S6. When verification fails, a correction item to be confirmed is generated. After reproduction and verification, the necessary relationship or hard constraint is updated and the solution is transferred to S2. If the correction content cannot be determined and there are other feasible solutions, the current solution is recorded as a failed solution and the solution is transferred to S3. The solution ends when the termination condition is met.

2. The method according to claim 1, characterized in that, In S1, the candidate cross-layer relationship extraction process is performed by: using functional requirements, target system capabilities, operating system components or services, device drivers, kernel capabilities, and hardware resources as nodes to establish a cross-layer dependency graph; Extract the requirements, implementations, dependencies, or support relationships between the nodes from the business capability mapping, component metadata, product and build configuration, link results, driver and kernel configuration, and target terminal running information, and record the relationship type, applicable conditions, and necessity status.

3. The method according to claim 1, characterized in that, In S2, the process of determining the current necessary relationship is as follows: the target capability set is determined according to the mapping rules between functional requirements and target system capabilities; the candidate cross-layer relationship is determined according to the functional requirements, hardware conditions and the determined deployment conditions to determine whether it is applicable to the target terminal, and the applicable relationship is taken as the current necessary relationship. For dependencies whose effectiveness is not yet certain, they should be determined during component resolution.

4. The method according to claim 3, characterized in that, In S2, the candidate component set determination process is performed as follows: determining components that can directly provide the target capabilities in the target capability set; and obtaining the components required for dependency closure along the current necessity relationship. By combining hardware compatibility conditions, prohibited items, security or recovery requirements, and alternative implementation relationships, a set of candidate components is obtained through filtering and supplementation.

5. The method according to claim 1, characterized in that, In S3, the process of obtaining the target component set from feasible solutions that satisfy all hard constraints is performed as follows: feasible solutions that satisfy target capability coverage, necessary dependency closure, component conflict, hardware compatibility, security and recovery requirements, verification locking requirements, and resource boundaries are selected from the candidate component set; the target component set is selected from the feasible solutions according to the number of components, image volume, or resource consumption index.

6. The method according to claim 2, characterized in that, In S4, the system configuration generation process is executed as follows: based on the target component set, the cross-layer dependency graph, and hardware conditions, the component selection results are implemented in the product component and feature configuration, build and installation targets, device drivers and device trees, kernel configuration, system services and startup items, security configuration, and image installation list; when retaining components or capabilities, their required configurations are retained simultaneously, and when trimming, only configuration items that are specific to the trimmed object and are no longer depended on by other retained objects are removed.

7. The method according to claim 1, characterized in that, In S5, the process of performing startup verification, business verification, and anomaly recovery verification uses a verification set, which covers the normal business path and the preset anomaly and recovery path. When verification fails, the failure type is determined based on the failure location and logs. The failure types are: missing construction target, link failure, dynamic library loading failure, missing system service or inter-process communication, missing startup item, inaccessible device node, business function failure, anomaly, downgrade, or recovery failure.

8. The method according to claim 1, characterized in that, In S6, the process that has been reproduced and verified is executed as follows: keeping other conditions unchanged, the relationships or components related to this failure are restored and the verification is repeated; if the failure disappears, the valid relationships or hard constraints are corrected, added to the locked item set, and the solution is resolved. If failure still exists, the correction item is not locked and the positioning continues; the locked items in the locked item set are not revoked in subsequent iterations; when the correction content cannot be determined, the current solution is recorded as a failed solution, and the failed solution will not be selected again in subsequent solutions.

9. An automatic trimming system for operating system components of a traffic control terminal, characterized in that, The system for implementing the method of any one of claims 1-8 comprises: The candidate cross-layer relationship construction and determination module is used to extract candidate cross-layer relationships from operating system source code, component metadata and build configuration, determine the necessary relationships and determine the candidate component set based on the functional requirements, hardware conditions and determined deployment conditions of the target terminal; The target component solving module is used to obtain the target component set from the feasible solutions that satisfy all hard constraints within the candidate component set; A configuration generation module is used to generate system configuration based on the target component set; The verification feedback module is used to construct the target system according to the system configuration and perform startup verification, business verification and anomaly recovery verification. When the verification fails, a correction item to be confirmed is generated. After the necessary relationship or hard constraint is confirmed by reproduction verification, the necessary relationship or hard constraint is updated and the candidate cross-layer relationship construction and judgment module and the target component solving module are re-executed. When the correction content cannot be determined and there are other feasible solutions, the current solution is recorded as a failed solution and the target component solving module is triggered to continue solving.

Images