Automobile software component configuration generation and version management method, device and equipment

Abstract

The application provides a vehicle software component configuration generation and version management method, device and equipment, which comprises the following steps: obtaining unified structured requirement description data containing interface definition data and software component configuration data; performing format compliance verification on the unified structured requirement description data to obtain target data that passes the verification; generating a standard configuration document that meets the vehicle open system architecture specification according to the target data; obtaining historical configuration documents from a version management platform; comparing the historical configuration documents with the standard configuration document to obtain a corresponding comparison result; storing the standard configuration document as a plurality of mutually independent physical files according to the software component dimension; and entering each physical file and the comparison result into the version management platform and performing a version archiving operation; thereby achieving the technical effect of improving the management efficiency of vehicle software component configuration.

Description

Technical Field

[0001] This application relates to the field of automotive embedded software development and software configuration management, and in particular to a method, apparatus and device for generating and managing automotive software component configurations and versions. Background Technology

[0002] In automotive embedded software development based on the AUTOSAR Classic Platform (AUTOSAR CP), software component interface definition and configuration management are typically accomplished through Interface Definition Language (IDL), design documents, and AUTOSAR XML (ARXML) configuration files.

[0003] However, design documents, IDL and ARXML usually rely on manual interpretation and conversion, and interface data and component configurations need to be repeatedly maintained across multiple carriers, which is prone to semantic deviations and synchronization omissions. When requirements change and multiple people collaborate on development, configuration difference identification, version verification and conflict handling also rely heavily on manual processes, which limits development efficiency and consistency assurance capabilities.

[0004] Therefore, how to improve the management efficiency of automotive software component configuration in complex automotive software configuration scenarios has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a method, apparatus, and device for generating and managing automotive software component configurations to address the aforementioned technical problems. This solution addresses the integrated management needs of automotive software components throughout the processes of requirement description, configuration generation, difference identification, and version archiving. It unifies and ensures consistency between interface definition information and component configuration information, and links configuration output with version evolution. This achieves continuous connection from design requirements to configuration results and then to version control, improving the management efficiency of automotive software component configurations in complex automotive software configuration scenarios.

[0006] Firstly, this application provides a method for generating and managing the configuration of automotive software components, including:

[0007] Obtain unified structured requirement description data that includes interface definition data and software component configuration data;

[0008] Perform format compliance validation on the unified structured requirements description data to obtain the validated target data, where the target data inherits the entity information of the software components carried by the unified structured requirements description data;

[0009] Based on the target data, generate a standard configuration document that conforms to the automotive open system architecture specification;

[0010] Retrieve historical configuration documents from the version management platform, which stores multiple versions of the configuration documents;

[0011] Compare the historical configuration documents with the standard configuration documents to obtain the corresponding comparison results;

[0012] The standard configuration document is stored as multiple independent physical files, categorized by software component.

[0013] Each physical file and the comparison results are entered into the version management platform and the version archiving operation is performed.

[0014] In one possible implementation, a format compliance check is performed on the unified structured requirements description data to obtain the target data that passes the check, including:

[0015] Based on the built-in judgment criteria of the interface definition data, the character sequence of the interface definition data is read segment by segment, the data type identifier is checked against the interface field definition, and the interface syntax and field matching detection is performed to obtain the interface exception content. The interface exception content is a set of data that records interface syntax errors and interface field identifier mismatches.

[0016] Based on the built-in form constraints of the software component configuration data, the data entries in the form that carries the software component configuration data are traversed, the filling status of required fields and the category of field stored data are checked, the integrity and type matching of form fields are checked, and the abnormal content of the form is obtained. The abnormal content of the form is a set of data that records missing required fields or mismatched form data categories.

[0017] Based on the interface exception content and the form exception content, determine the format exception data within the unified structured requirement description data;

[0018] Remove any data with abnormal formatting from the unified structured requirements description data to obtain the target data that has passed the validation.

[0019] In one possible implementation, based on the target data, a standard configuration document conforming to the automotive open system architecture specification is generated, including:

[0020] Extract the configuration information corresponding to the software components within the target data;

[0021] Write the configuration information into separate component configuration sub-documents;

[0022] Extract the port connection relationships between each software component within the target data;

[0023] Based on the port connection relationship, obtain the corresponding port association information;

[0024] Write the port association information into a separate port association sub-document;

[0025] Based on the component configuration sub-document and port association sub-document, a standard configuration document conforming to the automotive open system architecture specification is generated.

[0026] In one possible implementation, each physical file and the comparison results are entered into the version management platform and a version archiving operation is performed, including:

[0027] Multiple independent physical files are entered into the version management platform. The physical files include component configuration sub-documents and port association sub-documents.

[0028] Enter the comparison results into the version management platform;

[0029] Based on the branch isolation mechanism preset by the version management platform, establish binding mapping relationships between component configuration sub-documents, port association sub-documents and their respective working branches;

[0030] Based on the binding mapping relationship, perform version archiving operations on the component configuration sub-document and the port association sub-document.

[0031] In one possible implementation, the historical configuration document is compared with the standard configuration document to obtain the corresponding comparison results, including:

[0032] Extract historical configuration entries contained within the historical configuration document;

[0033] Extract the standard configuration entries contained within the standard configuration document;

[0034] Compare historical configuration entries with standard configuration entries field by field to determine the corresponding configuration differences;

[0035] Based on the configuration differences, determine the structured change records of the standard configuration items and historical configuration items, and use the structured change records as the comparison results.

[0036] In one possible implementation, each physical file and the comparison results are entered into the version management platform and a version archiving operation is performed, including:

[0037] Enter each physical file and its structured change record into the version management platform;

[0038] Get the platform submission identifier and branch identifier corresponding to the current data entry operation;

[0039] Establish a binding relationship between the structured change record and the platform submission identifier and branch identifier to obtain the bound structured change record;

[0040] The bound structured change records are associated and stored in the archive location of each physical file.

[0041] In one possible implementation, after entering each physical file and the comparison results into the version management platform and performing version archiving, the method further includes:

[0042] Retrieve the archived standard configuration documents within the version management platform;

[0043] Based on the archived standard configuration documents, determine the corresponding original interface definition data and original software component configuration data;

[0044] Perform interface syntax and field matching checks on the original interface definition data to obtain the corresponding first detection result;

[0045] Perform form field integrity and category matching checks on the original software component configuration data to obtain the corresponding second check result;

[0046] Based on the first and second test results, identify and remove any format-abnormal data within the archived standard configuration documents to obtain the verified standard configuration documents.

[0047] Retrieve component configuration information from the validated standard configuration document;

[0048] Based on the component configuration information, generate corresponding reusable interface definition data and reusable software component configuration data.

[0049] Secondly, this application provides an automotive software component configuration generation and version control device, comprising:

[0050] The first acquisition module is used to acquire unified structured requirement description data that includes interface definition data and software component configuration data;

[0051] The validation module is used to perform format compliance validation on the unified structured requirement description data to obtain the target data that passes the validation.

[0052] The generation module is used to generate standard configuration documents that conform to the automotive open system architecture specification based on the target data;

[0053] The second acquisition module is used to retrieve historical configuration documents from the version management platform, where the version management platform stores multiple versions of configuration documents;

[0054] The comparison module is used to compare historical configuration documents with standard configuration documents and obtain the corresponding comparison results.

[0055] The storage module is used to store standard configuration documents as multiple independent physical files according to the software component dimension;

[0056] The processing module is used to input each physical file and the comparison results into the version management platform and perform version archiving operations.

[0057] In one possible implementation, the verification module is further configured to:

[0058] Based on the built-in judgment criteria of the interface definition data, the character sequence of the interface definition data is read segment by segment, the data type identifier is checked against the interface field definition, and the interface syntax and field matching detection is performed to obtain the interface exception content. The interface exception content is a set of data that records interface syntax errors and interface field identifier mismatches.

[0059] Based on the built-in form constraints of the software component configuration data, the data entries in the form that carries the software component configuration data are traversed, the filling status of required fields and the category of field stored data are checked, the integrity and type matching of form fields are checked, and the abnormal content of the form is obtained. The abnormal content of the form is a set of data that records missing required fields or mismatched form data categories.

[0060] Based on the interface exception content and the form exception content, determine the format exception data within the unified structured requirement description data;

[0061] Remove any data with abnormal formatting from the unified structured requirements description data to obtain the target data that has passed the validation.

[0062] In one possible implementation, the generation module is further configured to:

[0063] Extract the configuration information corresponding to the software components within the target data;

[0064] Write the configuration information into separate component configuration sub-documents;

[0065] Extract the port connection relationships between each software component within the target data;

[0066] Based on the port connection relationship, obtain the corresponding port association information;

[0067] Write the port association information into a separate port association sub-document;

[0068] Based on the component configuration sub-document and port association sub-document, a standard configuration document conforming to the automotive open system architecture specification is generated.

[0069] In one possible implementation, the processing module is further configured to:

[0070] Multiple independent physical files are entered into the version management platform. The physical files include component configuration sub-documents and port association sub-documents.

[0071] Enter the comparison results into the version management platform;

[0072] Based on the branch isolation mechanism preset by the version management platform, establish binding mapping relationships between component configuration sub-documents, port association sub-documents and their respective working branches;

[0073] Based on the binding mapping relationship, perform version archiving operations on the component configuration sub-document and the port association sub-document.

[0074] In one possible implementation, the comparison module is further used for:

[0075] Extract historical configuration entries contained within the historical configuration document;

[0076] Extract the standard configuration entries contained within the standard configuration document;

[0077] Compare historical configuration entries with standard configuration entries field by field to determine the corresponding configuration differences;

[0078] Based on the configuration differences, determine the structured change records of the standard configuration items and historical configuration items, and use the structured change records as the comparison results.

[0079] In one possible implementation, the processing module is further configured to:

[0080] Enter each physical file and its structured change record into the version management platform;

[0081] Get the platform submission identifier and branch identifier corresponding to the current data entry operation;

[0082] Establish a binding relationship between the structured change record and the platform submission identifier and branch identifier to obtain the bound structured change record;

[0083] The bound structured change records are associated and stored in the archive location of each physical file.

[0084] In one possible implementation, the processing module is further configured to:

[0085] Retrieve the archived standard configuration documents within the version management platform;

[0086] Based on the archived standard configuration documents, determine the corresponding original interface definition data and original software component configuration data;

[0087] Perform interface syntax and field matching checks on the original interface definition data to obtain the corresponding first detection result;

[0088] Perform form field integrity and category matching checks on the original software component configuration data to obtain the corresponding second check result;

[0089] Based on the first and second test results, identify and remove any format-abnormal data within the archived standard configuration documents to obtain the verified standard configuration documents.

[0090] Retrieve component configuration information from the validated standard configuration document;

[0091] Based on the component configuration information, generate corresponding reusable interface definition data and reusable software component configuration data.

[0092] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0093] The memory stores the instructions that the computer executes;

[0094] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0095] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible embodiments of the first aspect.

[0096] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0097] This application provides a method, apparatus, and device for generating and managing automotive software component configurations. By acquiring unified structured requirement description data containing interface definition data and software component configuration data, and generating a standard configuration document that conforms to the automotive open system architecture specification based on the target data after passing format compliance verification, it can reduce semantic deviations and synchronization omissions caused by repeated maintenance across multiple carriers between design requirements and implementation configurations. By obtaining historical configuration documents from the version management platform and comparing them with the standard configuration document, clear configuration difference results can be generated, thereby improving the efficiency of version verification and conflict identification in scenarios of requirement changes and multi-person collaborative development. By storing the standard configuration document as multiple independent physical files according to the software component dimension, and recording each physical file and the comparison results into the version management platform to perform version archiving operations, the independence, automation, and traceability of configuration management can be enhanced, thereby achieving the technical effect of improving the management efficiency of automotive software component configurations. Attached Figure Description

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

[0099] Figure 1 This application provides a schematic diagram of an application data processing system architecture.

[0100] Figure 2 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 1 ;

[0101] Figure 3 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 2 ;

[0102] Figure 4 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 3 ;

[0103] Figure 5 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 4 ;

[0104] Figure 6 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 5 ;

[0105] Figure 7 A schematic diagram of the structure of the automotive software component configuration generation and version control device provided in the embodiments of this application;

[0106] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0107] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0108] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0109] Automotive embedded software configuration management technology is widely used in the development of vehicle controllers, domain controllers, and in-vehicle communication systems based on AUTOSAR CP. These scenarios typically involve defining software component interfaces, configuring component behavior, and generating and maintaining configuration documentation. Especially in service-oriented communication and multi-component collaborative development environments, it is necessary to continuously transfer interface data and component configuration information between the design and implementation phases.

[0110] In existing development processes, systems engineers typically first describe the interface data and behavioral requirements of software components based on interface definition languages, design documents, or configuration tables. Developers then convert this content into configuration documents such as ARXML that conform to the AUTOSAR specification to support subsequent integration, compilation, and calibration. The basic principle of this technical solution is to rely on manual interpretation of information from various design carriers and to complete configuration mapping, version submission, and subsequent change maintenance between different tools and files.

[0111] However, in this approach, interface definition data and software component configuration data are scattered across different carriers, lacking a unified structured format. This makes it easy for design semantics to be missed, mismatched, or inconsistent during the conversion process. Especially when interface types, component entities, or connection relationships are adjusted, developers often need to repeatedly check multiple documents and manually modify configuration documents, which is not only inefficient but also makes it difficult to ensure that the configuration results are consistent with the original design in a timely manner.

[0112] Furthermore, in collaborative development involving multiple developers and frequent requirement iterations, the identification of differences between historical configuration documents typically relies on manual comparison. Version verification and archiving processes are also fragmented, making it difficult to quickly pinpoint the specific configuration impact of a change. This can easily lead to duplicate modifications to configuration files, incomplete difference tracking, and insufficient version documentation, thereby affecting consistency assurance, collaborative efficiency, and subsequent auditing capabilities in the automotive software development process.

[0113] Improving the management efficiency of automotive software component configuration in complex automotive software configuration scenarios has become an urgent problem to be solved.

[0114] To address the aforementioned issues, this paper provides a method, apparatus, and device for generating and managing automotive software component configurations. By acquiring unified structured requirement description data containing interface definition data and software component configuration data, and generating a standard configuration document conforming to automotive open system architecture specifications based on the target data after passing format compliance verification, this reduces semantic discrepancies and synchronization omissions caused by repeated maintenance across multiple platforms between design requirements and implemented configurations. By retrieving historical configuration documents from a version management platform and comparing them with the standard configuration document, clear configuration difference results can be generated, thereby improving the efficiency of version verification and conflict identification in scenarios involving requirement changes and multi-person collaborative development. Furthermore, by storing the standard configuration document as multiple independent physical files according to the software component dimension, and recording each physical file and the comparison results into the version management platform for version archiving, the independence, automation, and traceability of configuration management are enhanced, thus achieving the technical effect of improving the management efficiency of automotive software component configurations.

[0115] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0116] Figure 1 This is a schematic diagram of an application data processing system architecture provided in an embodiment of this application. The application data processing system is a computer device. Figure 1 As shown, the above architecture includes at least one of a data acquisition device 101, a processing device 102, and a display device 103.

[0117] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the architecture of the application data processing system. In other feasible embodiments of this application, the above architecture may include more or fewer components than illustrated, or combine some components, or split some components, or arrange different components, which can be determined according to the actual application scenario and is not limited here. Figure 1 The components shown can be implemented in hardware, software, or a combination of both.

[0118] In the specific implementation process, the data acquisition device 101 may include an input / output interface or a communication interface, and the data acquisition device 101 can be connected to the processing device through the input / output interface or the communication interface.

[0119] The processing device 102 can first obtain structured requirement data that carries interface and component configuration data and contains software component entity information, and complete the format verification to obtain target data. Then, based on the target data, it generates a standard configuration document that conforms to the automotive open system architecture specification, retrieves the platform's historical configuration documents to complete the content comparison and obtain the comparison results, splits the standard configuration document into independent physical files according to the component dimension, and finally uploads all physical files and comparison results to the version management platform to complete the archiving and management.

[0120] The display device 103 can also be a touch screen or the screen of a terminal device, used to receive user commands while displaying the above-mentioned content, so as to realize interaction with the user.

[0121] It should be understood that the aforementioned processing device can be implemented by a processor reading instructions from memory and executing those instructions, or it can be implemented by a chip circuit.

[0122] Furthermore, the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0123] Figure 2 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the automotive software component configuration generation and version control method provided in this embodiment includes:

[0124] S201. Obtain unified structured requirement description data that includes interface definition data and software component configuration data.

[0125] In this embodiment, a unified structured requirement description data serves as the input carrier, simultaneously carrying interface definition data and software component configuration data. This allows interface constraints, component entity information, behavioral information, and connection information to be read and processed within the same data structure. Interface definition data characterizes the interface constraints required for interaction between software components, while software component configuration data characterizes the entity information, behavioral information, or connection information of software components. Both are organized in a unified format to form a single input source.

[0126] For example, the executing entity can read raw content from a requirements management file, interface description file, or structured configuration table, and load it into unified structured requirements description data according to a preset data model. This data model may include relevant fields for describing software components, interfaces, and their corresponding relationships, and save the correspondence between interface definition data and software component configuration data through hierarchical nodes or key-value mapping.

[0127] Based on the above analysis, it can be seen that by carrying interface definition data and software component configuration data together in a unified structured requirement description data, the association between design information can be maintained at the starting point of configuration generation. In the subsequent verification, generation and comparison processes, there is no need to repeatedly map and convert between different documents, so that the semantics of requirements can be directly transmitted to the configuration document generation stage.

[0128] S202. Perform format compliance verification on the unified structured requirement description data to obtain the target data that passes the verification.

[0129] In this embodiment, the target data inherits the entity information of the software components carried by the unified structured requirements description data. The target data represents a set of data that can continue to be used to generate configuration files after passing the format compliance verification. The so-called inheritance of the entity information of the software components means that after the verification is passed, the content that directly describes the object of the software component, such as the component name, component type, component identifier, and port affiliation, is retained in the target data and continues to serve as the basis for subsequent configuration generation.

[0130] For example, the executing entity checks the unified structured requirement description data according to preset format compliance rules to confirm that its structure, fields, and interrelationships meet the requirements for subsequent processing. If format abnormalities, missing fields, duplicate definitions, or invalid references are found, the system records the exception information and terminates the subsequent standard configuration document generation process; if the verification passes, the target data is formed. This target data retains the entity semantics in the original requirements and maintains the correspondence between interface definition data and software component configuration data without being disrupted.

[0131] Based on the above analysis, by performing format compliance verification and forming target data before generation, content that does not meet the constraints can be intercepted before configuration generation, making the content source of subsequent standard configuration documents clear and the structure stable.

[0132] S203. Based on the target data, generate a standard configuration document that conforms to the automotive open system architecture specification.

[0133] In this embodiment, the standard configuration document is used to carry the configuration results that conform to the automotive open system architecture specification, and serves as the basis for subsequent version comparison, split storage, and archiving.

[0134] For example, the executing entity generates a corresponding standard configuration document based on the software component entity information, interface definition data, and software component configuration data in the target data. This ensures that the interface definitions, component entities, and connection relationships in the target data are standardized configuration content according to the automotive open system architecture specification. After generation, a standard configuration document is obtained that can be used for subsequent processing.

[0135] Based on the above analysis, it can be seen that the standard configuration document is not a simple splicing of input data, but rather a conversion of the relevant content in the target data into a standardized configuration carrier in accordance with the automotive open system architecture specification, so that the design side expression can be directly converted into the implementation side configuration result.

[0136] In one possible implementation, based on the target data, a standard configuration document conforming to the automotive open system architecture specification is generated, including:

[0137] Extract the configuration information corresponding to the software components within the target data; write the configuration information into independent component configuration sub-documents; extract the port connection relationships between each software component within the target data; obtain the corresponding port association information based on the port connection relationships; write the port association information into an independent port association sub-document; and generate a standard configuration document that conforms to the automotive open system architecture specification based on the component configuration sub-document and the port association sub-document.

[0138] For example, the system reads the name, type, interface instance, and parameter configuration items of each software component from the target data, establishes corresponding configuration records according to the granularity of the software component, and then writes the configuration record of each software component into an independent component configuration sub-document. Subsequently, the system parses the port reference information between the software components, extracts the source component port, target component port, connection direction, and interface type, and merges the port reference relationships into port association information and writes it into an independent port association sub-document. Further, the system combines the component attributes in the component configuration sub-document with the connection relationships in the port association sub-document to form a data organization structure that meets the automotive open system architecture specification, and outputs it as a standard configuration document. This standard configuration document can fully express the configuration semantics and interconnection relationships of software components while maintaining the separate storage of software component configuration and port association.

[0139] Optionally, the standard configuration document can be generated using a modular configuration generation method, specifically including: generating component configuration sub-documents and port association sub-documents based on a preset modular template, wherein the template predefines field structures, data types, and format requirements that conform to the automotive open system architecture specification; assembling the overall configuration by referencing each sub-document in the main ARXML file, wherein the main file only contains the reference paths of each sub-document and the association relationships between modules, and does not store specific component configuration and port association details; when generating the final ARXML file, the configuration generation tool will automatically merge the contents of each sub-file into the main file and verify the integrity of the reference relationships between the main file and the sub-documents. If problems such as invalid references or incorrect paths are found, an exception prompt will be output in a timely manner and the merging operation will be terminated to ensure the validity of the overall configuration.

[0140] By separating software component configurations and port connection relationships into independent sub-documents and then assembling them uniformly, the structure of the standard configuration document can be kept consistent with the automotive open system architecture specification. This allows software component-level configurations and cross-component connection content to be generated and maintained independently. At the same time, the modular configuration generation method further improves the standardization and maintainability of the configuration document, reduces structural chaos caused by mixed configuration content, and improves the consistency and traceability of the standard configuration document generation.

[0141] S204. Obtain historical configuration documents from the version management platform.

[0142] In this embodiment, the version management platform stores multiple versions of configuration documents. The version management platform is used to store multiple versions of configuration documents and support version control. The historical configuration documents serve as the baseline for subsequent comparisons. They can be the previous version corresponding to the current standard configuration document or a specified version.

[0143] For example, after generating a standard configuration document, the executing entity initiates a retrieval request to the version management platform based on the project identifier, component identifier, target branch, commit tag, or preset version selection criteria to obtain the corresponding historical configuration document. The historical configuration document may contain the file itself and metadata related to that version, so that subsequent comparison results can be bound to a specific historical version. If no matching historical configuration document exists in the platform, the system marks the current standard configuration document as the initial archived version and generates an empty baseline difference result in subsequent comparison stages.

[0144] Based on the above analysis, it can be seen that extracting historical configuration documents from a version management platform that stores multiple versions of configuration documents enables the currently generated content to establish a correspondence with a clear historical baseline, thereby making change identification based on traceable version records.

[0145] S205. Compare the historical configuration documents with the standard configuration documents to obtain the corresponding comparison results.

[0146] In this embodiment, the comparison results are used to characterize the differences between historical configuration documents and standard configuration documents, serving as the basis for subsequent change tracking, structured recording, and version archiving.

[0147] For example, after obtaining the historical configuration document, the executing entity compares the historical configuration document with the standard configuration document to identify any added, deleted, or modified content and generate a corresponding comparison result. This comparison result can be a structured change record and can be further bound to historical version identifiers, current generation batch identifiers, and branch identifiers. In one possible embodiment, when the historical configuration document is an empty baseline, all content in the standard configuration document is marked as new items.

[0148] Optionally, after obtaining the comparison results, the process also includes: performing an automated dependency analysis step, specifically: the system parses the ARXML files corresponding to the historical configuration documents and the standard configuration documents, extracts the software component configuration dependencies, interface references, and port connection relationships recorded in the files, constructs a global dependency graph, and clearly marks the associations and dependency levels between each software component, interface, and port in the graph; based on this global dependency graph, the propagation path of the current configuration modification is analyzed, the software components affected by this modification and their corresponding configuration fields are accurately identified, and the scope of the modification's impact is clarified; a visual impact scope report is generated based on the analysis results, and the report details the affected modules, specific modification points, and the degree of impact, providing a basis for subsequent configuration review and version control.

[0149] Based on the above analysis, it can be seen that by comparing historical configuration documents with standard configuration documents, configuration changes caused by requirement iterations can be identified. Combined with automated dependency analysis, the scope of the impact of modifications can be further clarified, so that when archiving versions, not only the current results are saved, but also the source of changes, the scope of changes, and the affected modules are saved simultaneously, thereby improving the comprehensiveness and accuracy of version control.

[0150] In one possible implementation, the historical configuration document is compared with the standard configuration document to obtain the corresponding comparison results, including:

[0151] Extract historical configuration entries from the historical configuration document; extract standard configuration entries from the standard configuration document; compare historical configuration entries and standard configuration entries field by field to determine the corresponding configuration differences; based on the configuration differences, determine the structured change records of the standard configuration entries and historical configuration entries, and use the structured change records as the comparison results.

[0152] For example, both historical configuration documents and standard configuration documents are stored as parsable structured files. Configuration entries within these files are organized according to a preset field order, with each field containing at least identification information, attribute values, and association information corresponding to the configuration object. After obtaining the documents, the system first parses the historical configuration document to extract historical configuration entries, then parses the standard configuration document to extract standard configuration entries, and establishes a mapping relationship between entries corresponding to the same configuration object. Subsequently, the system compares the field values ​​of the two types of entries item by item based on the field identifier. When the field type, field content, or field existence is inconsistent, a corresponding configuration difference is generated, and this difference is written to the change record object.

[0153] If a field exists in a historical configuration entry but is deleted from a standard configuration entry, the change type is recorded as deletion; if a field is newly added to a standard configuration entry, the change type is recorded as addition; if the field values ​​are inconsistent, the change type is recorded as modification. The system can also associate and store entry-level comparison results with field-level differences, enabling structured change records to directly reflect the change trajectory of standard configuration entries relative to historical configuration entries.

[0154] In practice, the system first parses the document and extracts entries, then performs field-level difference identification, and converts the identified differences into structured change records. This comparison result can be used for record keeping during subsequent version archiving, and also for tracking the evolution of a configuration object across different versions, thus providing a searchable and verifiable structured representation of configuration document version changes.

[0155] By adopting the above comparison method, the differences between historical configuration documents and standard configuration documents are no longer retained in the form of unstructured text, but are organized into structured change records that are consistent at the field and object levels. Therefore, it can directly support version tracing, difference location and archiving management, improve the readability and traceability of configuration comparison results, and reduce omissions and mismatches when manually checking configuration content.

[0156] S206. Store the standard configuration document as multiple independent physical files according to the software component dimension.

[0157] In this embodiment, the physical file is a set of multiple independent files formed by splitting the standard configuration document. Each file corresponds to the configuration content of a software component and is independent of other component files at the storage level.

[0158] For example, after generating and comparing the standard configuration document, the executing entity reads the software component content from the standard configuration document and splits the document content according to the component identifier, forming multiple independent physical files. Each physical file uses an independent file path, an independent filename, and an independent version tracking unit. The file content maintains the corresponding configuration content that meets the automotive open system architecture specification, so that the individual file can be independently retrieved and submitted. After splitting, the executing entity writes the multiple independent physical files to the target storage directory.

[0159] Based on the above analysis, it can be seen that splitting the standard configuration documents into independent physical files according to the software component dimension isolates the configuration changes of each component at the file level, and subsequent version control can be carried out directly at the software component granularity.

[0160] S207. Enter each physical file and the comparison results into the version management platform and perform version archiving.

[0161] In this embodiment, the version archiving operation is used to save physical files and their corresponding change information in a versioned manner to form a traceable historical record.

[0162] For example, the executing entity traverses each physical file and, based on the comparison results, enters the physical files and their corresponding information into the version management platform. Subsequently, the system performs a version archiving operation to save the corresponding version records, archiving information, and relationships. After archiving is completed, the platform returns archiving result information; the executing entity updates its local records accordingly and outputs an archiving completion notification.

[0163] Based on the above analysis, it can be seen that after each physical file and the comparison results are entered into the version management platform and the version archiving operation is performed, the current configuration content, historical differences and commit context are uniformly saved in the same version chain, and the corresponding configuration changes can be directly retrieved by software component, version or branch in the future.

[0164] This application provides a method for generating and managing the configuration of automotive software components. By acquiring unified structured requirement description data containing interface definition data and software component configuration data, and generating a standard configuration document that conforms to the automotive open system architecture specification based on the target data after passing format compliance verification, it can reduce semantic deviations and synchronization omissions caused by repeated maintenance on multiple carriers between design requirements and implementation configurations. By obtaining historical configuration documents from the version management platform and comparing them with the standard configuration document, clear configuration difference results can be formed, thereby improving the efficiency of version verification and conflict identification in scenarios of requirement changes and multi-person collaborative development. By storing the standard configuration document as multiple independent physical files according to the software component dimension, and entering each physical file and the comparison results into the version management platform to perform version archiving operations, the independence, automation, and traceability of configuration management can be enhanced, thereby achieving the technical effect of improving the management efficiency of automotive software component configuration.

[0165] Figure 3 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 2 ,like Figure 3 As shown, this embodiment, based on the above embodiments, provides a detailed explanation of the specific process for obtaining the verified target data, including:

[0166] S301. Based on the built-in judgment criteria of the interface definition data, read the character sequence of the interface definition data segment by segment, check the data type identifier and the interface field definition, perform interface syntax and field matching detection, and obtain the interface exception content.

[0167] In this embodiment, the interface exception content is a data set that records interface syntax errors and interface field identifier mismatches.

[0168] For example, the system parses the unified structured requirement description data and extracts the internal interface definition data into a memory verification object. Based on the built-in judgment rules, it scans the character sequence segment by segment, compares the data type identifier, field definition and value range, identifies syntax missing, field order disorder, identifier mismatch and collects and generates interface exception content.

[0169] S302. Based on the program's built-in form constraints of the software component configuration data, traverse the data entries in the form that carries the software component configuration data, check the fill status of required fields and the category of data stored in the fields, perform form field integrity and type matching checks, and obtain the abnormal content of the form.

[0170] In this embodiment, the abnormal content of the form is a data set that records missing required fields or mismatched data categories.

[0171] For example, the system extracts the configuration data of the software components in memory, traverses the form entries one by one according to the preset form constraints, checks the filling status of the required fields and the category to which the field values ​​belong, and includes all empty value entries and entries whose categories do not meet the preset standards to form abnormal content.

[0172] S303. Based on the interface exception content and the form exception content, determine the format exception data within the unified structured requirement description data.

[0173] For example, the system performs association and summary mapping on interface exception content and form exception content, matches the original data fragments corresponding to the two types of exceptions, and locks all data segments with format defects in the unified structured requirement description data as format exception data.

[0174] S304. Remove abnormal data from the unified structured requirements description data to obtain the target data that has passed the verification.

[0175] For example, the system removes locked data segments with abnormal formats from the original unified structured requirements description data, and retains the target data generated by the data that fully complies with the interface and form double-layer validation rules; the double-layer synchronous validation can uniformly filter multiple layers of format defects, ensure that the input data for the subsequent generation of standard configuration documents is uniform and standardized, and avoid configuration generation deviations caused by various field and syntax problems.

[0176] The automotive software component configuration generation and version control method provided in this application can accurately collect two types of independent abnormal content by carrying out two types of detection: interface syntax and form fields in a layered manner. The summary of abnormal information can completely locate all format defect data. After removing abnormal data, compliant and unified target data is generated. The standardized data input eliminates configuration generation deviations and provides a stable and reliable data foundation for the generation of standard configuration documents.

[0177] Figure 4 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 3 ,like Figure 4 As shown, this embodiment, based on the above embodiments, provides a detailed description of a specific process for entering each physical file and comparison results into the version management platform and performing version archiving operations, including:

[0178] S401. Import multiple independent physical files into the version management platform.

[0179] In this embodiment, the physical file includes a component configuration sub-document and a port association sub-document.

[0180] For example, the version management platform receives all physical files, generates a unique identifier for each file, synchronously binds the submission source and timestamp to build an entry record, and then writes the component configuration sub-document and port association sub-document into the platform's corresponding dedicated file repository directory to complete the storage entry.

[0181] S402. Enter the comparison results into the version management platform.

[0182] For example, the platform marks the comparison results as the corresponding difference record generated for this configuration and completes the entry operation, so that the difference record belongs to the same submission version context as all the aforementioned physical files, and realizes the synchronous binding and storage of files and difference data.

[0183] S403. Based on the branch isolation mechanism preset by the version management platform, establish the binding mapping relationship between the component configuration sub-document and the port association sub-document and their respective working branches.

[0184] For example, the platform retrieves the current working branch identifier from the built-in branch isolation rules, and generates a unique binding mapping relationship based on the two types of sub-documents: branch number, commit hash, and storage path matching. The mapping record limits each sub-document to belong only to the corresponding branch and is subject to the version control of that branch.

[0185] S404. Based on the binding mapping relationship, perform version archiving operations on the component configuration sub-document and the port association sub-document.

[0186] For example, the platform relies on the generated mapping relationship to perform archiving and submission, fix version numbers, and generate historical data snapshots for the two types of sub-documents respectively. Each sub-document and its corresponding comparison results are encapsulated as independent version objects for retention. The branch binding archive can unify the version context of files and difference records, support the traceability of changes by component, and completely retain the evolution record of each branch configuration, thereby improving the integrity of the archive and the ability to trace changes.

[0187] The automotive software component configuration generation and version control method provided in this application can completely retain the original configuration files by batch inputting physical files composed of component configuration sub-documents and port-related sub-documents and generating an entry identifier; synchronously inputting comparison results can unify the version context of files and difference records; establishing a mapping between sub-documents and working branches can define a dedicated version control link for each file; and archiving files separately to solidify version snapshots facilitates tracking changes by component, improving the integrity and traceability of the archive.

[0188] Figure 5 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 4 ,like Figure 5As shown, this embodiment, based on the above embodiments, provides a detailed description of another specific process for entering each physical file and comparison results into the version management platform and performing version archiving operations, including:

[0189] S501. Enter each physical file and structured change record into the version management platform.

[0190] For example, the system sequentially writes all physical files into the built-in file repository of the version management platform, simultaneously submits the corresponding structured change records, and simultaneously completes the storage operation of configuration files and version difference data.

[0191] S502. Obtain the platform submission identifier and branch identifier corresponding to the current input operation.

[0192] For example, this batch submission action triggers the platform to automatically generate a unique submission identifier. The system reads the working branch information to which the current operation belongs, extracts the corresponding exclusive branch identifier, and binds the two types of identifiers to all the data entered into the database this time.

[0193] S503. Establish the binding relationship between the structured change record and the platform submission identifier and branch identifier to obtain the bound structured change record.

[0194] For example, the system extracts the changed object, fields, difference values, and change direction information from the change record, adds commit hash, branch name, and timestamp fields and binds them with two types of identifiers, or stores them in the metadata index table to complete the two-way association, and generates a structured change record carrying the version context.

[0195] S504. Associate the bound structured change records with the archive location of each physical file.

[0196] For example, the change record with completed identifier binding is written to the corresponding physical file archive directory, version index or association list, so that the single file body, difference information and version source form unified data; this method allows the archived file to come with a complete version context, supporting multi-dimensional retrieval, auditing and change rollback.

[0197] The automotive software component configuration generation and version control method provided in this application realizes unified data entry into the database by synchronously entering files and change records, extracts operation identifiers to lock version ownership, binds the identifiers to change records to complete the version context, and stores the bound change records in the corresponding file archive location, thereby realizing the binding and retention of files and change information, and supporting multi-dimensional retrieval auditing and change traceability.

[0198] Figure 6 A flowchart illustrating the automotive software component configuration generation and version control method provided in this application embodiment. Figure 5 ,like Figure 6As shown, this embodiment, based on the above embodiment, provides supplementary explanations regarding the process after each physical file and comparison result are entered into the version management platform and the version archiving operation is performed, including:

[0199] S601. Obtain the archived standard configuration documents in the version management platform, and determine the corresponding original interface definition data and original software component configuration data based on the archived standard configuration documents.

[0200] For example, the system retrieves the target standard configuration document from the platform archive, reads the document's built-in index to complete the parsing, and separates and extracts the interface definition fragments and software component configuration fragments stored in the document as the original interface definition data and the original software component configuration data.

[0201] S602. Perform interface syntax and field matching detection on the original interface definition data to obtain the corresponding first detection result.

[0202] For example, the system parses the character sequence of the original interface definition data segment by segment, compares the internal field labels, interface names, data types and field reference relationships item by item, and collects and marks the content that does not match the syntax, identifiers and references, forming the first detection result that carries the interface class defect information.

[0203] S603. Perform form field integrity and category matching checks on the original software component configuration data to obtain the corresponding second check result.

[0204] For example, the system parses the form records corresponding to the configuration data of the software components one by one, checks the filling status of required fields and the field values ​​to match the preset enumeration categories, records empty fields, type conflicts, and category out-of-bounds entries in a unified manner, and generates a second detection result that carries form-type defect information.

[0205] S604. Based on the first and second test results, identify and remove any format-abnormal data within the archived standard configuration document to obtain the verified standard configuration document.

[0206] For example, the system associates all abnormal data fragments in two detection result location documents, removes abnormal fragments from the archived standard configuration document, retains only the content that fully meets the interface and form format constraints, and generates a standard configuration document that passes the verification.

[0207] S605. Obtain the component configuration information inside the verified standard configuration document.

[0208] For example, the system iterates through the verified document content and extracts complete component configuration information, which includes the component's unique identifier, port parameters, communication transmission direction, and the values ​​of various configuration parameters.

[0209] Specifically, the system parses the archived standard configuration documents and accurately extracts the configuration information corresponding to each software component in the standard configuration documents according to the field structure of the automotive open system architecture specification. This includes detailed information such as the component's unique identifier, component type, number of ports, port type, communication protocol, configuration parameter values, and parameter constraints, ensuring that the extracted component configuration information is complete, accurate, and meets the requirements for reuse.

[0210] S606. Based on the component configuration information, generate the corresponding reusable interface definition data and reusable software component configuration data.

[0211] For example, the system outputs two types of reusable data based on the extracted component configuration information. The reusable interface definition data can be used directly by new project components to follow the interface rules, and the reusable software component configuration data can be used as a template for subsequent configuration generation. The two types of data can be stored in independent document formats. The entire process can reuse valid configurations in the archive, and anomalies are removed before reuse, taking into account version retention, data consistency and configuration reuse efficiency.

[0212] Specifically, based on the extracted component configuration information, the system generates reusable interface definition data that conforms to the automotive open system architecture specification according to a preset reuse template. This data contains complete information such as interface name, data type, field definition, and interface constraints, and the interface constraints can be directly inherited in other projects or other components without redefining them. At the same time, reusable software component configuration data is generated. This data integrates the core configuration parameters and constraints of the components and can be called as a basic template during subsequent configuration generation, reducing the workload of repetitive configuration.

[0213] The automotive software component configuration generation and version control method provided in this application extracts original configuration data by retrieving archived documents and identifies anomalies in a layered manner. After removing anomalies to obtain compliant documents, component information is extracted to generate reusable configuration data. Format defects are filtered before reuse, historical versions are retained, and configuration content is reused twice, thereby improving data consistency and configuration reuse efficiency.

[0214] Figure 7 This is a schematic diagram of the structure of the automotive software component configuration generation and version control device provided in this embodiment. The device in this embodiment can be in the form of software and / or hardware. Figure 7 As shown in the embodiment of this application, the automotive software component configuration generation and version control device 700 includes: a first acquisition module 701, a verification module 702, a generation module 703, a second acquisition module 704, a comparison module 705, a storage module 706, and a processing module 707.

[0215] The first acquisition module 701 is used to acquire unified structured requirement description data containing interface definition data and software component configuration data;

[0216] The verification module 702 is used to perform format compliance verification on the unified structured requirement description data to obtain the target data that passes the verification.

[0217] The generation module 703 is used to generate a standard configuration document that conforms to the automotive open system architecture specification based on the target data.

[0218] The second acquisition module 704 is used to acquire historical configuration documents from the version management platform, wherein the version management platform stores multiple versions of configuration documents;

[0219] The comparison module 705 is used to compare the historical configuration document with the standard configuration document to obtain the corresponding comparison result.

[0220] Storage module 706 is used to store the standard configuration document as multiple independent physical files according to the software component dimension;

[0221] Processing module 707 is used to input each physical file and comparison results into the version management platform and perform version archiving operations.

[0222] In one possible implementation, the verification module 702 is further configured to:

[0223] Based on the built-in judgment criteria of the interface definition data, the character sequence of the interface definition data is read segment by segment, the data type identifier is checked against the interface field definition, and the interface syntax and field matching detection is performed to obtain the interface exception content. The interface exception content is a set of data that records interface syntax errors and interface field identifier mismatches.

[0224] Based on the built-in form constraints of the software component configuration data, the data entries in the form that carries the software component configuration data are traversed, the filling status of required fields and the category of field stored data are checked, the integrity and type matching of form fields are checked, and the abnormal content of the form is obtained. The abnormal content of the form is a set of data that records missing required fields or mismatched form data categories.

[0225] Based on the interface exception content and the form exception content, determine the format exception data within the unified structured requirement description data;

[0226] Remove any data with abnormal formatting from the unified structured requirements description data to obtain the target data that has passed the validation.

[0227] In one possible implementation, the generation module 703 is further configured to:

[0228] Extract the configuration information corresponding to the software components within the target data;

[0229] Write the configuration information into separate component configuration sub-documents;

[0230] Extract the port connection relationships between each software component within the target data;

[0231] Based on the port connection relationship, obtain the corresponding port association information;

[0232] Write the port association information into a separate port association sub-document;

[0233] Based on the component configuration sub-document and port association sub-document, a standard configuration document conforming to the automotive open system architecture specification is generated.

[0234] In one possible implementation, the processing module 707 is further configured to:

[0235] Multiple independent physical files are entered into the version management platform. The physical files include component configuration sub-documents and port association sub-documents.

[0236] Enter the comparison results into the version management platform;

[0237] Based on the branch isolation mechanism preset by the version management platform, establish binding mapping relationships between component configuration sub-documents, port association sub-documents and their respective working branches;

[0238] Based on the binding mapping relationship, perform version archiving operations on the component configuration sub-document and the port association sub-document.

[0239] In one possible implementation, the comparison module 705 is further configured to:

[0240] Extract historical configuration entries contained within the historical configuration document;

[0241] Extract the standard configuration entries contained within the standard configuration document;

[0242] Compare historical configuration entries with standard configuration entries field by field to determine the corresponding configuration differences;

[0243] Based on the configuration differences, determine the structured change records of the standard configuration items and historical configuration items, and use the structured change records as the comparison results.

[0244] In one possible implementation, the processing module 707 is further configured to:

[0245] Enter each physical file and its structured change record into the version management platform;

[0246] Get the platform submission identifier and branch identifier corresponding to the current data entry operation;

[0247] Establish a binding relationship between the structured change record and the platform submission identifier and branch identifier to obtain the bound structured change record;

[0248] The bound structured change records are associated and stored in the archive location of each physical file.

[0249] In one possible implementation, the processing module 707 is further configured to:

[0250] Retrieve the archived standard configuration documents within the version management platform;

[0251] Based on the archived standard configuration documents, determine the corresponding original interface definition data and original software component configuration data;

[0252] Perform interface syntax and field matching checks on the original interface definition data to obtain the corresponding first detection result;

[0253] Perform form field integrity and category matching checks on the original software component configuration data to obtain the corresponding second check result;

[0254] Based on the first and second test results, identify and remove any format-abnormal data within the archived standard configuration documents to obtain the verified standard configuration documents.

[0255] Retrieve component configuration information from the validated standard configuration document;

[0256] Based on the component configuration information, generate corresponding reusable interface definition data and reusable software component configuration data.

[0257] The automotive software component configuration generation and version control device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0258] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 800 provided in this embodiment includes at least one processor 801 and a memory 802. Optionally, the device 800 further includes a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus.

[0259] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to perform the above-described method.

[0260] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0261] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0262] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0263] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0264] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0265] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0266] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0267] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0268] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0269] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0270] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0271] 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 instructions 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.

[0272] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0273] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for generating and versioning automotive software component configurations, characterized in that, include: Obtain unified structured requirement description data that includes interface definition data and software component configuration data; Perform format compliance verification on the unified structured requirement description data to obtain target data that passes the verification, wherein the target data inherits the entity information of the software components carried by the unified structured requirement description data; Based on the target data, generate a standard configuration document that conforms to the automotive open system architecture specification; Retrieve historical configuration documents from the version management platform, wherein the version management platform stores multiple versions of configuration documents; The historical configuration document is compared with the standard configuration document to obtain the corresponding comparison results. The standard configuration document is stored as multiple independent physical files according to the software component dimension; Each physical file and the comparison results are entered into the version management platform and a version archiving operation is performed.

2. The method according to claim 1, characterized in that, The process of performing format compliance validation on the unified structured requirement description data to obtain the validated target data includes: According to the built-in judgment criteria of the interface definition data, the character sequence of the interface definition data is read segment by segment, the data type identifier is checked against the interface field definition, and the interface syntax and field matching detection is performed to obtain the interface abnormal content. The interface abnormal content is a data set that records interface syntax errors and interface field identifier mismatches. Based on the built-in form constraints of the software component configuration data, the data entries in the form carrying the software component configuration data are traversed, the filling status of required fields and the category of field stored data are checked, and the integrity and type matching of form fields are checked to obtain the abnormal content of the form. The abnormal content of the form is a set of data that records missing required fields or mismatched form data categories. Based on the interface error content and the form error content, determine the format error data within the unified structured requirement description data; The abnormal data in the unified structured requirement description data is removed to obtain the target data that has passed the verification.

3. The method according to claim 1, characterized in that, The step of generating a standard configuration document that conforms to the automotive open system architecture specification based on the target data includes: Extract the configuration information corresponding to the software components from the target data; Write the configuration information into separate component configuration sub-documents; Extract the port connection relationships between each software component within the target data; Based on the port connection relationship, the corresponding port association information is obtained; Write the port association information into a separate port association sub-document; Based on the component configuration sub-document and the port association sub-document, a standard configuration document conforming to the automotive open system architecture specification is generated.

4. The method according to claim 3, characterized in that, The step of recording each physical file and the comparison result into the version management platform and performing version archiving includes: The multiple independent physical files are entered into the version management platform, wherein the physical files include the component configuration sub-document and the port association sub-document; The comparison results are entered into the version management platform; Based on the branch isolation mechanism preset by the version management platform, establish the binding mapping relationship between the component configuration sub-document, the port association sub-document and their respective working branches; Based on the binding mapping relationship, the version archiving operation is performed on the component configuration sub-document and the port association sub-document.

5. The method according to claim 1, characterized in that, The step of comparing the historical configuration document with the standard configuration document to obtain the corresponding comparison result includes: Extract the historical configuration entries contained within the historical configuration document; Extract the standard configuration entries contained within the standard configuration document; Compare the historical configuration entries and the standard configuration entries field by field to determine the corresponding configuration differences; Based on the configuration differences, the structured change records of the standard configuration entry and the historical configuration entry are determined, and the structured change records are used as the comparison results.

6. The method according to claim 5, characterized in that, The step of recording each physical file and the comparison result into the version management platform and performing version archiving includes: Enter each physical file and the structured change record into the version management platform; Get the platform submission identifier and branch identifier corresponding to the current data entry operation; Establish a binding relationship between the structured change record and the platform submission identifier and the branch identifier to obtain the bound structured change record; The bound structured change records are associated and stored in the archive location of each physical file.

7. The method according to claim 1, characterized in that, After entering each physical file and the comparison result into the version management platform and performing the version archiving operation, the method further includes: Retrieve the archived standard configuration document from the version management platform; Based on the archived standard configuration document, determine the corresponding original interface definition data and original software component configuration data; Perform interface syntax and field matching detection on the original interface definition data to obtain the corresponding first detection result; Perform form field integrity and category matching checks on the original software component configuration data to obtain the corresponding second detection result; Based on the first detection result and the second detection result, identify and remove the format-abnormal data inside the archived standard configuration document to obtain the standard configuration document that has passed the verification. Obtain the component configuration information from the verified standard configuration document; Based on the component configuration information, generate corresponding reusable interface definition data and reusable software component configuration data.

8. A device for generating and managing the configuration of automotive software components, characterized in that, include: The first acquisition module is used to acquire unified structured requirement description data that includes interface definition data and software component configuration data; The verification module is used to perform format compliance verification on the unified structured requirement description data to obtain the target data that passes the verification. The generation module is used to generate a standard configuration document that conforms to the automotive open system architecture specification based on the target data. The second acquisition module is used to acquire historical configuration documents from the version management platform, wherein the version management platform stores multiple versions of configuration documents; The comparison module is used to compare the historical configuration document with the standard configuration document to obtain the corresponding comparison result; The storage module is used to store the standard configuration document as multiple independent physical files according to the software component dimension; The processing module is used to input each physical file and the comparison result into the version management platform and perform version archiving operations.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images