Automatic SOA service code generation system and method based on AUTOSAR XML

Abstract

The invention discloses an automatic SOA service code generation system and method based on AUTOSAR XML, and relates to the technical field of automobile electronic software development, and the system comprises a signal analysis module, a module search module, a code generation module and a code insertion module. The signal analysis module constructs a document object model by using XPath and extracts a service context associated with a signal; the module searching module traverses a directory to position a target source file; the code generation module constructs communication code snippets adapted to different hierarchies based on a preset template; and the code insertion module writes the generated code into a target file through anchor point search. By means of the method and device, automatic conversion from architecture description to code implementation is achieved, type mapping errors caused by manual analysis of ARXML are eliminated, strict consistency of bottom-layer implementation and upper-layer architecture definition is ensured, incremental updating of existing engineering is supported, and SOA software development efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic software development technology, specifically to an automatic SOA service code generation system and method based on AUTOSAR XML. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards centralization and intelligence, service-oriented architectures are gradually replacing traditional signal-based communication architectures, becoming the core design concept for next-generation automotive software platforms. Under the AUTOSAR (Automotive Open System Architecture) standard, system description files (ARXML) are widely used to define service interfaces, data types, and communication behaviors, forming the cornerstone of interaction between software components.

[0003] However, in actual engineering practice, the transformation from architecture design to code implementation still faces challenges. Existing development models rely on developers manually interpreting complex ARXML documents and then manually writing communication code across different software layers, including interface definition language files, client proxy code, server stub code, and middleware adaptation logic. This manual intervention-dependent development approach not only consumes significant engineering resources and struggles to meet the rapid iteration and delivery requirements of in-vehicle software functions, but also, due to the deeply nested node structure and complex data type references in ARXML files, the manual translation process is highly susceptible to data type mapping errors, namespace definition confusion, or parameter passing errors.

[0004] Furthermore, in distributed systems involving multi-module collaboration, when the upper-level architecture design changes, manually synchronizing and updating multiple scattered related code files makes it difficult to guarantee strict consistency. This leads to a disconnect between interface definitions and underlying implementation logic, thereby increasing debugging costs and system maintenance risks during the software integration phase. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides an automatic SOA service code generation system and method based on AUTOSAR XML, which solves the problems of low development efficiency, error-prone data type mapping, and inconsistency between code implementation and architecture definition caused by manually parsing architecture description files and writing cross-level communication code in the existing automotive electronic software development process.

[0006] The first aspect of this invention provides an automatic SOA service code generation system based on AUTOSAR XML. The system includes a computing device, a storage medium, and a communication bus. The storage medium is connected to the computing device via the communication bus and is configured to store computer program instructions. The computing device is configured to execute the computer program instructions stored in the storage medium to implement the functions of the code generation system. Logically, the code generation system is divided into a signal analysis module, a module lookup module, a code generation module, and a code insertion module.

[0007] In the specific system architecture, the signal parsing module is configured to read the automotive open system architecture XML file in the storage medium and perform structured extraction of the file content to obtain signal parsing data. The module lookup module is configured to traverse the file system to locate the physical path of the target file based on preset directory path information. The code generation module is configured to construct code snippets according to the signal parsing data and a preset string template. The code insertion module is configured to write the code snippets into the target file.

[0008] Furthermore, the storage medium is divided into an ARXML storage directory, a service implementation directory, and an interface definition directory at the logical file system level. The storage medium also stores configuration files, which record the paths of the ARXML storage directory, the service implementation directory, and the interface definition directory within the file system. The ARXML storage directory is configured to store the automotive open system architecture XML files. The service implementation directory is configured to store server-side implementation files, including C++ source files and header files. The interface definition directory is configured to store interface definition language files and C++ code files.

[0009] In the specific implementation of signal parsing, the signal parsing module includes a file loading unit, a node positioning unit, and an attribute extraction unit. The file loading unit is configured to load the automotive open system architecture XML file into memory using an XML parser that supports XPath query syntax to construct a document object model tree. The node positioning unit is configured to receive a signal name string, construct an XPath query expression based on the signal name string, and execute the XPath query expression to find data element nodes in the document object model tree whose attribute values ​​match the signal name string. The attribute extraction unit is configured to traverse upwards along the hierarchical structure of the document object model tree, starting from the data element node, to find ancestor nodes, extract service names from the ancestor nodes, parse the data type reference paths associated with the data element nodes to obtain data type names, and parse the NAMESPACES node set to extract namespace strings. Specifically, the attribute extraction unit identifies the ancestor node of the node type SERVICE-INTERFACE and extracts its attribute value as the service name; extracts the data type reference path associated with the data element node, parses the type definition node pointed to by the path to obtain the data type name; parses the NAMESPACES node set to extract the SYMBOL attribute value of each level of namespace and concatenates it into the namespace string.

[0010] In the specific implementation of module lookup, the module lookup module includes a path traversal unit and a file matching unit. The path traversal unit is configured to use a recursive directory traversal algorithm to scan preset service implementation directories and interface definition directories and their subdirectories to obtain file name attributes and path attributes of the file system. The file matching unit is configured to construct a target file name pattern according to preset file naming rules based on the service name and service namespace output by the signal parsing module, compare the scanned file name with the target file name pattern, and record the absolute path of the file as the target file path when the comparison matches. The target file name pattern includes using the service name as a prefix and adding a specific suffix, such as ClientProxy.cpp, ServerManager.cpp, or IListener.h.

[0011] In the specific implementation of code generation, the code generation module includes a name normalization unit and a template rendering unit. The name normalization unit is configured to receive a signal name string, convert the first letter of the signal name string to uppercase, and add an action prefix to the beginning of the string to generate a method name. The template rendering unit is configured to store code templates, which include a static text portion and a dynamic placeholder portion. The template rendering unit fills the dynamic placeholders with the service name, data type, namespace extracted by the signal parsing module, and the method name, generating a source code snippet containing function declarations, function definitions, variable declarations, and lambda expressions. Specifically, the code templates include AIDL interface templates, listener callback templates, manager distribution templates, and proxy monitoring templates.

[0012] In the specific implementation of code insertion, the code insertion module includes a content buffer unit, an anchor point search unit, and a data writing unit. The content buffer unit is configured to open the target file and read its content into a memory buffer. The anchor point search unit is configured to retrieve a predefined insertion identifier string from the memory buffer; the insertion identifier string is a comment line. The data writing unit is configured to determine the byte offset of the insertion position, insert the code snippet at the corresponding offset in the memory buffer, and write the updated content of the memory buffer back to the target file.

[0013] A second aspect of this invention provides a method for automatically generating SOA service code based on AUTOSAR XML, the method being implemented based on the system described in the first aspect. The method includes: reading and parsing a configuration file to obtain the root path for searching ARXML source files, the root path for searching service implementation files, and the root path for searching interface definition files.

[0014] The method further includes: obtaining the signal name string to be processed, and retrieving the matching automotive open system architecture XML file under the root path of the ARXML source file search. The automotive open system architecture XML file is parsed, signal nodes are located using XPath query, and the service name, data type name, and namespace information are extracted by traversing the document object model tree upwards.

[0015] The method further includes: locating the physical path of the target code file by comparing filename features based on the service name, the root path of the service implementation file search, and the root path of the interface definition file search; generating source code fragments adapted to different software levels by calling a template engine based on the extracted service name, data type name, and namespace information; reading the content of the target code file into a memory buffer; searching for a pre-defined anchor identifier string; inserting the source code fragment into the byte position following the anchor identifier string; and writing the modified content back to the target code file.

[0016] The above solution achieves the following beneficial technical effects:

[0017] This application constructs a document object model tree through a signal parsing module and uses XPath query syntax to locate data element nodes. Then, it traverses upward along the hierarchical structure to extract service names and namespaces. This context parsing mechanism based on structured documents can identify the service interface definition and data type reference to which the signal belongs, eliminating the misunderstanding and input errors caused by manually translating ARXML files, and ensuring a high degree of consistency between the underlying code logic and the upper-level architecture design description file.

[0018] This application utilizes the multi-dimensional template rendering mechanism of the code generation module to synchronously construct cross-level code fragments such as AIDL interfaces, listener callbacks, manager distribution, and agent monitoring based on a single signal parsing data. This ensures strict correspondence between different software levels in terms of method naming, parameter types, and scope definitions, avoiding integration failures caused by interface definition mismatches in distributed development, and improving the development efficiency and maintenance convenience of communication middleware under the SOA architecture.

[0019] This application retrieves predefined anchor identifiers in the memory buffer through a code insertion module, and realizes fixed-point injection and write-back of code fragments by calculating byte offsets. This incremental update strategy changes the traditional operation mode of code generators that fully cover the target file, allowing new signal processing logic to be added to the existing project while retaining the original business logic code and file structure, and supports the continuous iterative software development process. Attached Figure Description

[0020] Figure 1 This is a system logic architecture diagram of the present invention;

[0021] Figure 2 This is a flowchart illustrating the overall process of the method of the present invention.

[0022] The components include: 10. Computing device; 20. Storage medium; 30. Communication bus; 21. ARXML storage directory; 22. Service implementation directory; 23. Interface definition directory; 24. Configuration file; 100. Signal parsing module; 200. Module search module; 300. Code generation module; 400. Code insertion module; 101. File loading unit; 102. Node positioning unit; 103. Attribute extraction unit; 201. Path traversal unit; 202. File matching unit; 301. Name normalization unit; 302. Template rendering unit; 401. Content buffering unit; 402. Anchor point search unit; 403. Data writing unit. Detailed Implementation

[0023] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] This invention provides an automatic SOA service code generation system based on AUTOSAR XML, comprising: a computing device 10, a storage medium 20, and a communication bus 30.

[0025] Computing device 10 is configured as the core processing unit for executing code generation logic. Physically, computing device 10 includes at least one central processing unit (CPU) capable of executing instruction sets of x86 or ARM architectures. Computing device 10 runs an operating system, including Linux, Windows, or macOS. A C++ compiler is installed in computing device 10, supporting the C++11 or later language standard. Computing device 10 is configured with build tools, including make or CMake, for managing the compilation process of the project.

[0026] Storage medium 20 is configured to store the data and program instructions required for system operation. Storage medium 20 is connected to computing device 10 via communication bus 30. Storage medium 20 includes non-volatile memory, such as a hard disk drive or solid-state drive. Source code management libraries and configuration data are stored in storage medium 20.

[0027] The storage medium 20 is divided into three preset directories at the logical file system level: ARXML storage directory 21, service implementation directory 22, and interface definition directory 23.

[0028] ARXML storage directory 21 is configured to store pending automotive open system architecture XML files. These XML files conform to the AUTOSAR standard format and include service interface definitions, data type definitions, and communication matrix information.

[0029] Service implementation directory 22 is configured to store the server-side implementation files for a service-oriented architecture. These server-side implementation files include C++ source files and header files, used to implement specific business logic.

[0030] The interface definition directory 23 is configured to store Android interface definition language files and related generated C++ code files. The related generated C++ code files include proxy files, stub files, and listener interface files.

[0031] Storage medium 20 also stores configuration file 24. Configuration file 24 is a text file that records the absolute or relative paths of ARXML storage directory 21, service implementation directory 22 and interface definition directory 23 in the file system.

[0032] When computing device 10 reads and executes computer program instructions from storage medium 20, it implements the function of the code generation system. The code generation system is logically divided into four functional modules: signal parsing module 100, module lookup module 200, code generation module 300, and code insertion module 400.

[0033] The signal parsing module 100 is configured to read XML files in the ARXML storage directory 21 and use an XML parsing library to extract the structured content of the files.

[0034] The module lookup module 200 is configured to traverse the file system to locate the physical path of the target file based on the path information of the service implementation directory 22 and the interface definition directory 23.

[0035] The code generation module 300 is configured to construct code snippets based on the data extracted by the signal parsing module 100 and according to a preset string template.

[0036] The code insertion module 400 is configured to write the code snippets generated by the code generation module 300 into the target file located by the module lookup module 200.

[0037] The modules communicate with each other through function calls or memory data sharing. When the system is running, the computing device 10 first loads the configuration file 24, initializes the directory path parameters, and then receives externally input signal identifiers. It then sequentially calls the signal parsing module 100, the module lookup module 200, the code generation module 300, and the code insertion module 400 to complete the code generation task.

[0038] See attached document Figure 1 The system's logical architecture includes a signal parsing module 100, a module lookup module 200, a code generation module 300, and a code insertion module 400. These modules work together to achieve automated conversion from configuration descriptions to executable code.

[0039] The signal parsing module 100 includes a file loading unit 101, a node positioning unit 102, and an attribute extraction unit 103.

[0040] File loading unit 101 is configured to load ARXML files into memory using an XML parser to construct a document object model tree. The XML parser employs a document object model-based parsing method and supports XPath 1.0 query syntax.

[0041] Node localization unit 102 is configured to receive an externally input signal name string and construct an XPath query expression based on the signal name string. Node localization unit 102 executes the XPath query expression, traversing the document object model tree to find data element nodes whose attribute values ​​match the signal name string. Data element nodes include XML nodes of type VARIABLE-DATA-PROTOTYPE.

[0042] The attribute extraction unit 103 is configured to traverse upwards along the hierarchical structure of the document object model tree, starting from the data element node, to find parent or ancestor nodes. The attribute extraction unit 103 identifies ancestor nodes of type SERVICE-INTERFACE and extracts the SHORT-NAME attribute value of this ancestor node as the service name. The attribute extraction unit 103 further extracts the data type reference path associated with the data element node, parses the type definition node pointed to by the reference path, and obtains the data type name. The attribute extraction unit 103 is also configured to parse the NAMESPACES node set in the ARXML file, extract the SYMBOL attribute values ​​of each level of namespace, and concatenate the multi-level namespaces into a namespace string according to the hierarchical order.

[0043] The module lookup module 200 includes a path traversal unit 201 and a file matching unit 202.

[0044] The path traversal unit 201 is configured to use a recursive directory traversal algorithm to scan the preset service implementation directory 22 and interface definition directory 23 and all their subdirectories. The path traversal unit 201 obtains the name attributes and path attributes of files in the file system.

[0045] The file matching unit 202 is configured to construct a target filename pattern according to a preset file naming rule based on the service name and service namespace output by the attribute extraction unit 103. The file naming rule includes using the service name as a prefix and adding a specific suffix, such as ClientProxy.cpp, ServerManager.cpp, or IListener.h. The file matching unit 202 compares the scanned filenames with the target filename pattern; when a match is found, the absolute path of the file is recorded as the target file path. The file matching unit 202 is also configured to identify existing code structures and determine whether the current service contains listener interface definitions or callback management logic by analyzing the file content.

[0046] The code generation module 300 includes a name normalization unit 301 and a template rendering unit 302.

[0047] The name normalization unit 301 is configured to receive signal name strings and performs format conversion on them. The format conversion includes converting the first letter to uppercase and adding a specific action prefix to the beginning of the string to generate a method name.

[0048] The template rendering unit 302 is configured to store various types of code templates, including AIDL interface templates, listener callback templates, manager distribution templates, and agent monitoring templates. Each code template contains static text and dynamic placeholders. The template rendering unit 302 fills the dynamic placeholders with the service name, data type, namespace extracted by the attribute extraction unit 103, and the method name generated by the name normalization unit 301, generating a complete source code fragment. The source code fragment generated by the template rendering unit 302 includes C++ function declarations, function definitions, variable declarations, and lambda expressions.

[0049] The code insertion module 400 includes a content buffer unit 401, an anchor search unit 402, and a data writing unit 403.

[0050] Content buffer unit 401 is configured to open the target file located by module lookup module 200 and read the file content completely into the memory buffer.

[0051] Anchor point search unit 402 is configured to retrieve a predefined insertion identifier string from a memory buffer. The insertion identifier string is a specific comment line used to indicate the physical location where the code is inserted.

[0052] The data writing unit 403 is configured to determine the byte offset of the insertion position and insert the source code fragment generated by the template rendering unit 302 into the corresponding offset in the memory buffer. The data writing unit 403 then writes the updated contents of the memory buffer back to the target file, overwriting the original file contents, thus completing the code injection operation.

[0053] This embodiment defines the core data structures for storing and transmitting signal parsing information, module lookup results, and code generation configuration, including the signal description structure Signal, the module finder structure ModuleFinder, and the code generator configuration structure CodeGeneratorConfig.

[0054] The Signal description structure is configured to encapsulate metadata extracted from an ARXML file in memory. The Signal structure contains the following member variables:

[0055] The member variable signalName, with a string data type, is configured to store the signal identifier extracted from the SHORT-NAME attribute of the ARXML node.

[0056] The member variable dataType is of string type and is configured to store the name of the basic or composite data type associated with the signal, such as uint8, float, or a custom structure name.

[0057] The member variable serviceName, with a data type of string, is configured as the name of the service interface to which the stored signal belongs. This name comes from the SHORT-NAME attribute of the SERVICE-INTERFACE node.

[0058] The member variable `category`, whose data type is an enumeration or string, is configured to identify the communication mode of the signal. Its values ​​include `EVENTS` or `FIELDS`, which are used to distinguish whether the signal is an event notification type or a field access type.

[0059] The member variable `signalNamespace`, whose data type is a string vector or a string concatenated by a delimiter, is configured to store the hierarchical namespace sequence in which the signal is defined.

[0060] The member variable serviceNamespace, whose data type is a string vector or a string concatenated by a delimiter, is configured as a hierarchical namespace sequence in which the storage service interface resides.

[0061] The ModuleFinder structure is configured to maintain file path mappings and component association information. The ModuleFinder structure contains the following member variables:

[0062] The member variable `searchPaths` is a list of strings and is configured to store the search root directories specified in configuration file 24, including the SOA service root directory path and the AIDL interface root directory path.

[0063] The member variable proxyFilePath, of type string, is configured to store the absolute path of the located client proxy implementation file (.cpp).

[0064] The member variable proxyHeaderPath, of type string, is configured to store the absolute path of the located client proxy header file (.h).

[0065] The member variable `managerFilePath`, of type string, is configured to store the absolute path of the located server-side manager implementation file (.cpp).

[0066] The member variable listenerHeaderPath, of type string, is configured to store the absolute path of the listener interface definition file (.h) that is located.

[0067] The member variable aidlFilePath, of type string, is configured to store the absolute path of the located Android interface definition language file (.aidl).

[0068] The CodeGeneratorConfig structure is used to define the formatting specifications and template parameters for code generation. The CodeGeneratorConfig structure contains the following member variables:

[0069] The member variable `methodPrefix` is of string data type and is configured to store the prefix rules for generating method names. Its default value is `on`.

[0070] The member variable `indentation` is of string data type and is configured to store code indentation characters, such as four spaces or one tab.

[0071] The member variable `namespaceSeparator`, of type string, is configured to store namespace separators, such as `::` or `.`.

[0072] The member variable `insertionMarkers` is a collection of key-value pairs configured to store the insertion anchor strings corresponding to different code types. The key-value pair collection includes: key `AIDL_MARKER` with the value ` / / INSERT AIDL CODE HERE`; key `LISTENER_MARKER` with the value ` / / INSERT LISTENER CODE HERE`; and key `PROXY_MARKER` with the value ` / / INSERT PROXY CODE HERE`.

[0073] During system runtime, the signal parsing module 100 instantiates a Signal structure and populates it with parsed data, then passes the populated Signal instance to the code generation module 300. The module lookup module 200 instantiates a ModuleFinder structure and populates it with path data, then passes the populated ModuleFinder instance to the code insertion module 400. The code generation module 300 reads the configuration parameters from the CodeGeneratorConfig structure and combines them with the data from the Signal instance to generate a code string.

[0074] See attached document Figure 2 The method includes the following steps:

[0075] Step S401: Read and parse the system configuration file 24. Upon system startup, the text configuration file 24 located in a preset path is loaded. The parsing logic reads the file content line by line, identifying configuration items that begin with specific keywords. The `arxmlDirectory` keyword is identified, and the following path string is stored as the root path for searching ARXML source files; the `soaPath` keyword is identified, and the following path string is stored as the root path for searching service implementation files; the `aidlPath` keyword is identified, and the following path string is stored as the root path for searching interface definition files. The system verifies the validity of the above paths; if a path does not exist, the process terminates and an error message is output.

[0076] Step S402: Obtain the signal identifier to be processed. The system receives the signal name string input by the user through the standard input stream or command-line parameter interface. Based on the signal name string, the system performs a file content search under the ARXML source file search root path obtained in step S401. The search logic opens each file with the .arxml extension under this path, reads the file content, and checks whether there is an XML tag attribute value that completely matches the signal name string. If a match is found, the complete path of the ARXML file is recorded and the process proceeds to step S403; if no match is found after traversing all files, the user is prompted to re-enter the information.

[0077] Step S403: Parse the ARXML file to extract signal metadata. The system loads the ARXML file located in step S402 and constructs a document object model. Using XPath, the system locates the target signal node and traverses the document tree upwards from it. During traversal, the system identifies the SERVICE-INTERFACE node in the hierarchical structure and extracts its name attribute as the service name; identifies the DATATYPE-DEFINITION node and extracts its name attribute as the data type name; and identifies the NAMESPACES container node and extracts the namespace hierarchy information. The system also determines the signal's category (Event or Field) based on the parent-child relationship of the signal node. The system encapsulates the extracted service name, data type name, namespace, and signal category into a signal description data object.

[0078] Step S404: Locate the target code file. Based on the service name in the signal description data object, and combined with the root path for searching the service implementation file and the root path for searching the interface definition file obtained in step S401, the system deduces the target filename characteristics. The system performs a recursive directory scan and compares the filename characteristics. Specifically, it searches for files whose filenames begin with the service name and end with ClientProxy.cpp, recording their path as the proxy implementation file path; it searches for files whose filenames begin with the service name and end with ServerManager.cpp, recording their path as the manager implementation file path; and it searches for files whose filenames begin with 'I', contain the middle part of the service name, and end with Listener.h, recording their path as the listener interface file path.

[0079] Step S405: Generate multi-dimensional code snippets. The system invokes the code generation engine based on the signal description data object. For AIDL interfaces, it generates method declaration code containing signal names; for listener interfaces, it generates C++ code containing virtual function definitions; for manager implementations, it generates C++ function code containing callback dispatch logic; and for proxy implementations, it generates signal subscription and handling code containing lambda expressions. During the generation process, the system automatically adapts parameter types based on data type names and adds the correct scope qualifiers based on namespace information.

[0080] Step S406: Inject code into the target file. The system sequentially opens each target file located in step S404 and reads the file content into the memory buffer. It searches the buffer for a pre-defined anchor identifier string. If the anchor identifier is successfully located, the corresponding type of code fragment generated in step S405 is inserted into the byte position after the anchor identifier. If no anchor identifier is found in the target file, code is appended to the end of the file, or the insertion position is determined according to the file's syntax structure (such as before the closing curly brace of a class). After completing the memory modification, the buffer content is overwritten back to the original file, completing the automatic code generation process.

[0081] This embodiment details how the signal parsing module 100 uses XPath technology to locate signal definitions and extract contextual information.

[0082] The signal parsing process begins with the DOM tree construction phase. The system calls the XML parser's loading function to read the binary data stream of the ARXML file and build a complete Document Object Model (DOM) tree structure in memory. This DOM tree preserves all element nodes, attribute nodes, text nodes, and their hierarchical relationships from the original XML document.

[0083] After the DOM tree is constructed, the signal localization phase begins. The system constructs an XPath query expression based on the signal name (denoted as TargetSignalName) entered by the user. The XPath expression follows the XPath 1.0 standard syntax and is constructed as " / / SHORT-NAME[text()='TargetSignalName']". This expression instructs the parser to search for nodes with the tag name SHORT-NAME at any level depth in the document whose text content is strictly equal to TargetSignalName. The parser executes the query and returns the matching SHORT-NAME node object. Subsequently, the system obtains the parent node of this SHORT-NAME node through the DOM API; this parent node is the entity node defined by the target signal (e.g., the VARIABLE-DATA-PROTOTYPE node).

[0084] After obtaining the entity node, the system performs an upward traversal (Parent Traversal) phase to extract the service context. The system initializes a pointer to the target signal entity node and enters a loop: it checks if the current node's label name is "SERVICE-INTERFACE". If not, it moves the pointer to the current node's parent node and repeats the check; if yes, the loop terminates, and the current node is the service interface definition node. The system reads the text content of the SHORT-NAME child nodes under the SERVICE-INTERFACE and stores it as the service name. If the SERVICE-INTERFACE node is not found even after traversing to the document root node, the signal definition is considered invalid or orphaned, and the system throws an exception.

[0085] During the upward traversal, the system executes namespace extraction logic in parallel. Each time the pointer moves up one level, the system checks if the current node contains a child element structure named "NAMESPACES". If it exists, it traverses the "SYMBOL-PROPS" child nodes under that structure and extracts their "SYMBOL" attribute values. Since the traversal order is bottom-up, the system pushes the extracted SYMBOL values ​​onto a stack structure. After the traversal is complete, elements are popped from the stack and connected using a namespace separator (such as "::") to reconstruct the fully qualified name string from the root namespace to the local namespaces.

[0086] Finally, the type association resolution phase is executed. The system returns to the target signal entity node and searches for a child node named "TYPE-TREF". This node stores the reference path string for the data type (e.g., " / DataType / BaseTypes / uint8"). Based on this path string, the system performs secondary location in the DOM tree, jumps to the corresponding data type definition node (DATATYPE-DEFINITION), and extracts the SHORT-NAME of that node as the data type name of the signal. Through the above logic, the system completes the full resolution from a single signal name to complete service context and type information.

[0087] This embodiment details how the code generation module 300 uses data from a single signal source to synchronously construct code snippets adapted to different software levels.

[0088] The code generation process begins with the construction of the context environment. The system creates a context object and injects variables obtained during the signal resolution phase, such as SignalName, ServiceName, DataType, Namespace, and MethodPrefix from the configuration, into this object. Simultaneously, the system loads a pre-built template library containing structured string templates for four types of code: AIDL, Listener, Manager, and Proxy.

[0089] For generating AIDL interface code, the system calls the AIDL template engine. The template is defined in the form "void %s(%svalue);". The system first converts the SignalName to camelCase (e.g., converting "vehicle_speed" to "VehicleSpeed"), then concatenates a prefix to generate the method name MethodName (e.g., "onVehicleSpeedChanged"). Next, the MethodName is filled into the first placeholder, and the DataType is filled into the second placeholder. If the DataType is a composite type, the system automatically adds the in keyword modifier to conform to the AIDL parameter passing specification. Finally, a code string such as void onVehicleSpeedChanged(in float value); is generated.

[0090] For generating the Listener interface code, the system calls a C++ header file template. The template is defined as "virtual void %s(%s value) = 0;", used to declare a pure virtual function. The system reuses the generated MethodName and, according to C++ type mapping rules, converts the AIDL data type to the corresponding C++ type (e.g., converting String to std::string and adding const & reference modifiers). The system also generates a Javadoc-style comment block above the function declaration, automatically filling in @param value and signal description information.

[0091] For the generation of the Manager implementation code, the system constructs callback dispatch logic. The template contains conditional statements and iterator traversal logic. The system generates the following code snippet: First, a checking function is defined to determine whether the received signal ID matches the currently processed signal; if it matches, the list of all registered listeners is traversed; inside the traversal loop, the MethodName method of the listener object is called, and the unpacked data is passed as a parameter. This logic ensures that the server can correctly route the received underlying signal to the application layer.

[0092] For generating proxy monitoring code, the system constructs subscription logic in the form of a lambda expression. The template structure is "proxy->getEvent(%s).subscribe([this](const %s& value) { ...});". The system fills the getEvent parameter with the signal enumeration value and the lambda parameter list with the C++ data type. Inside the lambda function body, the system generates code stubs that call its own member functions or trigger business logic. In addition, the system also generates corresponding member variable declaration code to store smart pointers to the proxy object.

[0093] After all code snippets have been generated, the system formats the generated code. It adjusts the left margin of the code lines according to the configured indentation rules (e.g., 4 spaces) and checks the generated code for syntax conflicts (e.g., C++ keyword conflicts). Finally, the code snippets of each type are encapsulated in a result set and output to the code insertion module 400. This multi-dimensional synchronous generation mechanism ensures strict consistency in naming, parameter types, and calling semantics across interface definitions at different levels.

[0094] This embodiment details how the code insertion module 400 achieves precise code injection and incremental updates while maintaining the integrity of the original file structure.

[0095] The code insertion process begins with the memory mapping of the target file. The system uses the C++ standard library's file stream object (std::fstream) to open the target source code file in read-write mode. The system first moves the file pointer to the end of the file to obtain the total file length, then allocates a memory buffer of the corresponding size and reads the entire file content into that buffer at once. This full-read strategy avoids frequent disk I / O operations, improving performance when processing large files.

[0096] Upon entering the anchor point location phase, the system retrieves the corresponding anchor identifier string (Marker String) from the configuration based on the currently processed code type (such as AIDL, Proxy, or Manager), for example, " / / INSERT AIDL CODEHERE". The system then executes a string search algorithm (such as the KMP algorithm or Boyer-Moore algorithm) in the memory buffer to find the starting index of the anchor identifier.

[0097] If the search is successful, the system calculates the physical offset of the insertion point. To ensure code aesthetics and readability, the system detects the position of the newline character at the end of the anchor line and places the insertion point at the beginning of the next line after the anchor line. Simultaneously, the system analyzes the indentation level of the anchor line—the number of spaces or tabs before the anchor—and uses this as the base indentation for generated code, ensuring that the inserted code is aligned with surrounding code.

[0098] Before performing the insertion operation, the system executes a repetition check. The system scans the buffer for characteristics of the code segment to be inserted (such as method name signatures). If the method name already exists in the file, the system determines that the signal has already been processed. At this point, the system compares the existing code with the newly generated code. If the content matches, the insertion operation is skipped; if they do not match (e.g., parameter types have changed), the system executes a replacement logic, deleting the old code segment and writing the new one, thus updating the code.

[0099] If no duplicates occur, the system performs a data concatenation operation. The system creates a new output buffer, first copies the data from the beginning of the file to the insertion point in the original buffer into it, then writes the newly generated code snippet, and finally appends the data from the insertion point to the end of the file from the original buffer to the end.

[0100] If no predefined anchor identifier is found in the file, the system triggers a fallback strategy. For class definition files (.h / .cpp), the system searches for the closing curly brace}; of the class and positions the insertion point before that brace. For AIDL files, the system searches for the position before the closing curly brace}. The system will automatically add the corresponding anchor identifier comment above the insertion point so that subsequent operations can recognize the position, achieving adaptive insertion without an anchor.

[0101] Finally, the persistence phase is executed. The system clears the original file content, writes the concatenated output buffer data to the file, and performs a flush operation to ensure the data is written to disk. Through the above mechanism, the system achieves non-destructive editing of the source code, supporting both full writing of the initial generation and incremental appending in subsequent iterations.

[0102] This embodiment uses the specific VehicleSpeed ​​signal as an example to demonstrate the entire data flow process from input parsing to final code generation.

[0103] During the application scenario startup phase, the user enters the target signal name string "VehicleSpeed" through the command-line interface. Upon receiving this input, the system triggers the ARXML file retrieval process. The system scans the ARXML directory and locates the ChassisService.arxml file, which contains the signal definition.

[0104] During the parsing phase, the system loads ChassisService.arxml and locates the signal node using XPath query / / SHORT-NAME[text()='VehicleSpeed']. The parser traverses upwards and finds that its parent node, SERVICE-INTERFACE, is named ChassisService. It also extracts the data type reference, pointing to float32, and identifies it as belonging to the namespace com::automotive::chassis. The signal category is identified as EVENTS.

[0105] During the search phase, based on the service name ChassisService, the system located the following physical files in the source code directory: the client proxy file / src / proxy / ChassisServiceClientProxy.cpp, the server manager file / src / manager / ChassisServiceServerManager.cpp, and the listener header file / include / listener / IChassisServiceListener.h.

[0106] During the code generation phase, the system generates the following four sets of code snippets based on the extracted metadata:

[0107] AIDL interface code: Generates `void onVehicleSpeedChanged(in float value);`. The system automatically maps `float32` to the `float` type supported by AIDL and adds the `on...Changed` naming pattern.

[0108] Listener interface code: Generates a C++ virtual function declaration: virtual void onVehicleSpeedChanged(float value) = 0;, with the comment / ** Signal: VehicleSpeed ​​* / .

[0109] Proxy subscription code: Generate Lambda expression: proxy->getEvent(VehicleSpeed).subscribe([this](const float& value){ this->listener->onVehicleSpeedChanged(value);});.

[0110] Manager dispatch code: Branch generation logic if (signalId == VEHICLE_SPEED_ID) {listener->onVehicleSpeedChanged(data.get <float>());}.

[0111] During the code insertion phase, the system opens the IChassisServiceListener.h file, retrieves the / / INSERTLISTENER METHODS HERE anchor, and inserts the generated virtual function declaration code after it. Similarly, the system opens the proxy file and manager file respectively, finds the corresponding / / INSERT SUBSCRIPTIONS and / / INSERTDISPATCHER anchors, and injects the subscription code and dispatch code respectively.

[0112] Ultimately, developers only need to execute a single compilation command to directly implement the IChassisServiceListener interface in their business logic to handle vehicle speed change events, without having to manually write any low-level communication glue code. This example verifies the completeness and correctness of the system in handling specific automotive electronic signals.

[0113] This invention is not limited to the specific ARXML format or C++ language environment in the foregoing embodiments, but covers a variety of alternative technical solutions and application scenarios.

[0114] Regarding the input data format, although the aforementioned embodiments use Automotive Open System Architecture XML (ARXML) as an example, the signal parsing module 100 of this system is configured to support multiple structured description languages. These structured description languages ​​include JavaScript Object Notation (JSON), YAML (Yellow Article Classification) format, and Interface Definition Language (IDL) format. When the input file is in JSON format, the parsing module uses a JSON parser to construct a key-value pair tree structure and locates signal nodes using JSONPath query syntax. When the input file is in IDL format, the parsing module uses a lexical analyzer and a syntax analyzer to generate an abstract syntax tree and extracts service and method definition information from the tree nodes.

[0115] Regarding the parsing and location algorithms, in addition to XPath queries based on the Document Object Model (DOM), the signal parsing module 100 is also configured to employ streaming parsing technology. Streaming parsing technologies include the Simple XML API (SAX) or the XML Streaming API (StAX). When using SAX parsing, the system registers event handlers to trigger start and end element callback functions during the file stream reading process. The current context path is recorded through a state machine to identify the target signal, eliminating the need to load the complete document tree into memory, thus adapting to the processing requirements of ultra-large-scale configuration files 24. Furthermore, for simple text matching needs, the system is configured to use a regular expression engine to directly perform pattern matching on the file text to extract key attributes.

[0116] Regarding the target file lookup mechanism, in addition to recursive search based on naming conventions, the module lookup module 200 is also configured to use an explicit mapping index mechanism. The system maintains a global file index database or mapping table file (such as CSV or SQLite), which stores the direct correspondence between service names and physical file paths. The lookup module directly obtains the target path by querying this index table, without relying on real-time traversal of the file system. An alternative approach is to integrate the build system's metadata. The system parses the CMakeLists.txt or Android.bp build script and filters the file paths belonging to specific modules from the list of compiled source files.

[0117] Regarding the technical methods for code insertion, in addition to text concatenation based on comment anchors, the code insertion module 400 is also configured to use code injection technology based on abstract syntax trees (ASTs). The system introduces Clang LibTooling or a similar syntax analysis tool to parse the target source code into an AST. The system constructs an AST node representing the new function and attaches this node to the AST node corresponding to the target class definition. Then, the modified AST is serialized into source code text. This method does not rely on specific comment markers and can automatically determine the legal insertion position based on the syntax structure. An alternative approach is configuration insertion based on line numbers. The system reads the external diff configuration file 24 (Diff / Patch) and performs the insertion operation according to the line numbers specified in the file.

[0118] Regarding applicable fields and target languages, the code generation module 300 of this system is configured to support output in multiple programming languages, including Java, Python, Rust, and Go. For different languages, the template rendering unit 302 loads the corresponding syntax template library. The scope of supported communication middleware is not limited to Android Binder, but also includes gRPC, data distribution services, and IP-based scalable service-oriented middleware. Application scenarios extend to IoT device management, industrial automation control systems, and telecommunications network element management systems. Any scenario involving the conversion from interface description files to communication stub code falls within the protection scope of this system.

[0119] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.< / float>

Claims

1. An automatic SOA service code generation system based on AUTOSAR XML, characterized in that, include: The signal parsing module is configured to read the automotive open system architecture XML file in the storage medium and extract the signal parsing data by performing structured extraction on the file content. The module lookup module is configured to traverse the file system to locate the physical path of the target file based on preset directory path information. The code generation module is configured to construct code snippets based on the signal parsing data and according to a preset string template; The code insertion module is configured to write the code snippet into the target file.

2. The AUTOSAR XML-based SOA service code automatic generation system according to claim 1, characterized in that, The storage medium is divided into an ARXML storage directory, a service implementation directory, and an interface definition directory at the logical file system level. The storage medium also stores a configuration file, which records the paths of the ARXML storage directory, the service implementation directory, and the interface definition directory in the file system. The ARXML storage directory is configured to store the automotive open system architecture XML files; The service implementation directory is configured to store server-side implementation files, which include C++ source files and header files. The interface definition directory is configured to store interface definition language files and C++ code files.

3. The AUTOSAR XML-based SOA service code automatic generation system according to claim 1, characterized in that, The signal analysis module includes: File loading unit, node positioning unit, and attribute extraction unit; The file loading unit is configured to load the automotive open system architecture XML file into memory to build a document object model tree using an XML parser, wherein the XML parser supports XPath query syntax; The node positioning unit is configured to receive a signal name string, construct an XPath query expression based on the signal name string, and execute the XPath query expression to find data element nodes in the document object model tree whose attribute values ​​match the signal name string. The attribute extraction unit is configured to traverse upwards along the hierarchical structure of the document object model tree, starting from the data element node, to find ancestor nodes, extract the service name from the ancestor nodes, parse the data type reference path associated with the data element node to obtain the data type name, and parse the NAMESPACES node set to extract the namespace string.

4. The AUTOSAR XML-based SOA service code automatic generation system according to claim 1, characterized in that, The module lookup module includes: Path traversal unit and file matching unit; The path traversal unit is configured to use a recursive directory traversal algorithm to scan the preset service implementation directory and interface definition directory and their subdirectories to obtain the file name attribute and path attribute of the file system. The file matching unit is configured to construct a target file name pattern according to a preset file naming rule based on the service name and service namespace output by the signal parsing module, compare the scanned file name with the target file name pattern, and record the absolute path of the file as the target file path when the comparison is consistent.

5. The AUTOSAR XML-based SOA service code automatic generation system according to claim 1, characterized in that, The code generation module includes: Name normalization unit and template rendering unit; The name normalization unit is configured to receive a signal name string, convert the first letter of the signal name string to uppercase and add an action prefix to the beginning of the string to generate a method name; The template rendering unit is configured to store code templates. The code templates include static text and dynamic placeholders. The template rendering unit fills the dynamic placeholders with the service name, data type, namespace, and method name extracted by the signal parsing module, generating source code fragments containing function declarations, function definitions, variable declarations, and lambda expressions.

6. The AUTOSAR XML-based SOA service code automatic generation system according to claim 1, characterized in that, The code insertion module includes: Content buffering unit, anchor search unit, and data writing unit; The content buffer unit is configured to open the target file and read the file content into the memory buffer; The anchor search unit is configured to retrieve a predefined insertion identifier string from the memory buffer, wherein the insertion identifier string is a comment line; The data writing unit is configured to determine the byte offset of the insertion position, insert the code fragment into the corresponding offset of the memory buffer, and write back the updated memory buffer content to the target file.

7. The AUTOSAR XML-based SOA service code automatic generation system according to claim 3, characterized in that, The attribute extraction unit is specifically configured as follows when performing upward traversal: Identify the ancestor node whose node type is SERVICE-INTERFACE, and extract the SHORT-NAME attribute value of the ancestor node as the service name; Extract the data type reference path associated with the data element node, parse the type definition node pointed to by the data type reference path, and obtain the SHORT-NAME of the type definition node as the data type name; The NAMESPACES node set in the automotive open system architecture XML file is parsed, the SYMBOL attribute values ​​of each level of namespace are extracted, and the multi-level namespaces are concatenated into the namespace string in hierarchical order.

8. The AUTOSAR XML-based SOA service code automatic generation system according to claim 4, characterized in that, The target file name pattern constructed by the file matching unit includes using the service name as a prefix and adding a specific suffix, wherein the specific suffix is ​​selected from the following group: ClientProxy.cpp, ServerManager.cpp, IListener.h.

9. The AUTOSAR XML-based SOA service code automatic generation system according to claim 5, characterized in that, The code templates stored in the template rendering unit include: AIDL interface template, configured to generate method declaration code containing signal names; Listener callback template, configured to generate C++ code containing virtual function definitions; The manager dispatch template is configured to generate C++ function code containing callback dispatch logic; The proxy monitoring template is configured to generate signal subscription and processing code containing lambda expressions.

10. A method for automatically generating SOA service code based on AUTOSAR XML, based on the system described in any one of claims 1 to 9, characterized in that, The method includes the following steps: Read and parse the configuration file to obtain the root path for searching ARXML source files, the root path for searching service implementation files, and the root path for searching interface definition files; Obtain the signal name string to be processed, and retrieve the matching automotive open system architecture XML file under the ARXML source file search root path; The automotive open system architecture XML file is parsed, signal nodes are located using XPath queries, and the document object model tree is traversed upwards to extract service names, data type names, and namespace information. Based on the service name, combined with the service implementation file search root path and the interface definition file search root path, the physical path of the target code file is located by comparing file name features. Based on the extracted service name, data type name, and namespace information, the template engine is invoked to generate source code fragments adapted to different software levels; The contents of the target code file are read into the memory buffer, a preset anchor identifier string is searched, the source code fragment is inserted into the byte position after the anchor identifier string, and the modified content is written back to the target code file.

Images