End-to-end software configuration method and device, equipment, medium and program product

Abstract

The invention relates to the technical field of automotive electronics, in particular to an end-to-end software configuration method and device, equipment, a medium and a program product.The method comprises the steps that end-to-end protection information of a target application programming interface is obtained; performing parameter configuration on a communication port of the target application programming interface based on a preset requirement of an application layer software component, and generating an ARXML file according to the configured target application programming interface; and obtaining end-to-end verification software based on the ARXML file, the end-to-end protection information and a preset configuration tool. Therefore, by means of end-to-end protection information labeling, communication port parameter setting, code generation and independent verification process automation, the problems that in traditional E2E protection implementation, configuration is tedious, manual code integration is prone to errors, function verification is not visual, and efficiency is low are solved, and development efficiency and reliability are improved.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, and in particular to a method, apparatus, device, medium and program product for configuring end-to-end software. Background Technology

[0002] In recent years, with the development of software-defined vehicles, intelligent vehicle software architecture is transforming and upgrading towards SOA (Service-Oriented Architecture). Decomposing the sub-functions of the entire vehicle system as services allows for greater flexibility in ECU version iterations and code updates. For this highly software-based new architecture, ensuring the integrity and reliability of communication data is paramount when it comes to critical data transmission between internal vehicle components or external ECUs. E2E (End-to-End Protection), as a fundamental component of the AUTOSAR architecture, follows a layered principle and protects data communication between components through standardized interfaces.

[0003] In related technologies, based on the interface functions and E2E Profile definitions under the AUTOSAR standard, the protected data transfer functions between SWC (Software Components) and the reverse verification of CRC (Cyclic Redundancy Check) are performed using conventional handwritten code. The OEM (Original Equipment Manufacturer) can impose constraints on the data arrangement and E2E (End-to-End) algorithm for communication protection.

[0004] However, when identifying APIs (Application Programming Interfaces) requiring E2E protection between ECUs, inconsistencies arise in the use of E2E protection for the same interface between different ECUs and even different SWCs within the same ECU. Therefore, for SOA architectures, which decouple the application layer from the underlying layer, accurately defining the E2EPW_Read interface function requiring E2E protection through hand-written code, and ensuring its seamless application-layer compatibility, is particularly difficult. This leads to a challenging early development and integration process, resulting in unsatisfactory SOA implementation. Secondly, when testing and verifying end-to-end communication using protected APIs, the E2E profiles used vary across projects, and there may be multiple E2E algorithms. Verifying the correctness of data headers using conventional code (CRC-8, CRC-16, CRC-32, etc.) has poor universality and urgently needs to be addressed. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and program product for configuring end-to-end software to solve problems such as cumbersome configuration, error-prone manual code integration, and unintuitive and inefficient functional verification in traditional E2E protection implementation.

[0006] The first aspect of this application provides a method for configuring end-to-end software, including the following steps: Obtain end-to-end protection information for the target application's programming interface; Based on the requirements of the preset application layer software components, the communication port of the target application programming interface is configured with parameters, and an ARXML file is generated according to the configured target application programming interface. Based on the ARXML file, the end-to-end protection information, and the preset configuration tools, end-to-end verification software is obtained.

[0007] Optionally, the end-to-end protection information includes at least one of the following: service name, service ID, event name, timeout information, and end-to-end configuration file type.

[0008] Optionally, when configuring the communication port parameters of the target application programming interface based on the requirements of preset application layer software components, the method further includes: When the communication port of the target application programming interface meets the preset communication conditions, the end-to-end protection attribute of the communication port is set to enabled.

[0009] Optionally, after obtaining the end-to-end verification software based on the ARXML file, the end-to-end protection information, and the preset configuration tool, the software further includes: Use an Ethernet packet capture tool to obtain communication messages from the target application's programming interface. Based on the communication message of the target application programming interface, the CRC check calculation sequence is extracted, and the CRC check calculation sequence is calculated based on the preset CRC algorithm, polynomial and initial value to obtain the local CRC check value; The local CRC checksum is compared with the CRC field value in the target application programming interface (API) communication message. When the local CRC checksum matches the CRC field value in the target API communication message, the end-to-end protection information is determined to be configured correctly.

[0010] Optionally, the process of obtaining end-to-end verification software based on the ARXML file, the end-to-end protection information, and a preset configuration tool includes: Import the ARXMIL file into the application layer; The application layer updates the runtime environment layer code and the basic software layer code based on the ARXMIL file, the end-to-end protection information, and the preset configuration tool. The updated runtime environment layer code and basic software layer code are integrated and compiled with the application layer code to obtain the end-to-end verification software.

[0011] A second aspect of this application provides an end-to-end software configuration apparatus, comprising: The acquisition module is used to acquire end-to-end protection information of the target application's programming interface; The configuration module is used to configure the communication port of the target application programming interface based on the requirements of the preset application layer software components, and generate an ARXML file according to the configured target application programming interface. The determination module is used to obtain end-to-end verification software based on the ARXML file, the end-to-end protection information, and the preset configuration tools.

[0012] Optionally, the end-to-end protection information includes at least one of the following: service name, service ID, event name, timeout information, and end-to-end configuration file type.

[0013] Optionally, when configuring the communication port parameters of the target application programming interface based on the requirements of preset application layer software components, the configuration module is further configured to: When the communication port of the target application programming interface meets the preset communication conditions, the end-to-end protection attribute of the communication port is set to enabled.

[0014] Optionally, after obtaining the end-to-end verification software based on the ARXML file, the end-to-end protection information, and the preset configuration tool, the determining module is further configured to: Use an Ethernet packet capture tool to obtain communication messages from the target application's programming interface. Based on the communication message of the target application programming interface, the CRC check calculation sequence is extracted, and the CRC check calculation sequence is calculated based on the preset CRC algorithm, polynomial and initial value to obtain the local CRC check value; The local CRC checksum is compared with the CRC field value in the target application programming interface (API) communication message. When the local CRC checksum matches the CRC field value in the target API communication message, the end-to-end protection information is determined to be configured correctly.

[0015] Optionally, the determining module is specifically used for: Import the ARXMIL file into the application layer; The application layer updates the runtime environment layer code and the basic software layer code based on the ARXMIL file, the end-to-end protection information, and the preset configuration tool. The updated runtime environment layer code and basic software layer code are integrated and compiled with the application layer code to obtain the end-to-end verification software.

[0016] A third aspect of this application provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform an end-to-end software configuration method as described in the above embodiments.

[0017] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the end-to-end software configuration method as described in the above embodiments.

[0018] A fifth aspect of this application provides a computer program product storing a computer program that, when executed by a processor, implements the end-to-end software configuration method as described in the above embodiments.

[0019] Therefore, this application embodiment obtains end-to-end protection information of the target application programming interface; based on the requirements of the preset application layer software components, it configures the communication port parameters of the target application programming interface and generates an ARXML file according to the configured target application programming interface; based on the ARXML file, the end-to-end protection information, and the preset configuration tool, it obtains end-to-end verification software. Thus, by automating the end-to-end protection information annotation, communication port parameter setting, code generation, and independent verification process, it solves the problems of cumbersome configuration, error-prone manual code integration, and unintuitive and inefficient functional verification in traditional E2E protection implementation, thereby improving development efficiency and reliability.

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

[0021] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating an end-to-end software configuration method according to an embodiment of this application; Figure 2 A flowchart illustrating the addition of E2E protection to an API under an SOA architecture for an end-to-end software configuration method according to an embodiment of this application; Figure 3 This is a schematic diagram of the header layout provided in Profile 4, which illustrates a configuration method for end-to-end software according to an embodiment of this application. Figure 4 This is a schematic diagram of the program interface for performing multiple CRC test verification of an end-to-end software configuration method according to an embodiment of this application; Figure 5 This is a schematic diagram of an end-to-end software configuration apparatus provided according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

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

[0023] The following description, with reference to the accompanying drawings, describes a configuration method, apparatus, device, medium, and program product for end-to-end software according to embodiments of this application. Addressing the problems mentioned in the background art regarding cumbersome configuration, error-prone manual code integration, and unintuitive and inefficient functional verification in traditional E2E protection implementations, this application provides a configuration method for end-to-end software. In this method, embodiments of this application obtain end-to-end protection information of a target application programming interface (API); based on the requirements of preset application layer software components, configure the communication port parameters of the target API, and generate an ARXML file according to the configured target API; based on the ARXML file, end-to-end protection information, and preset configuration tools, obtain end-to-end verification software. Thus, by automating the end-to-end protection information annotation, communication port parameter setting, code generation, and independent verification process, the problems of cumbersome configuration, error-prone manual code integration, and unintuitive and inefficient functional verification in traditional E2E protection implementations are solved, improving development efficiency and reliability.

[0024] Specifically, Figure 1 This is a flowchart illustrating an end-to-end software configuration method provided in an embodiment of this application.

[0025] like Figure 1 As shown, the configuration method for this end-to-end software includes the following steps: In step S101, end-to-end protection information of the target application programming interface is obtained. Optionally, in some embodiments, the end-to-end protection information includes at least one of the following: service name, service ID, event name, timeout information, and end-to-end configuration file type.

[0026] End-to-end protection information is a set of metadata configured in service-based automotive Ethernet communication to ensure the integrity and timeliness of signals during transmission from the sender to the receiver.

[0027] Specifically, in the standardized API (Application Programming Interface) list, for ECUs or APIs (such as power domain torque commands, braking pressure parameters, etc.) that require E2E protection (end-to-end protection), add service name, service ID, event name, timeout information, and profile type to the E2E protection page in the standard format. If there are special requirements for the Ethernet signal transmission method, additional instructions can be provided.

[0028] In step S102, based on the requirements of the preset application layer software components, the communication port of the target application programming interface is configured with parameters, and an ARXML file is generated according to the configured target application programming interface.

[0029] Among them, ARXML file (AUTOSAR XML) is an engineering data exchange file based on XML format defined by the AUTOSAR (Automotive Open Systems Architecture) standard.

[0030] Specifically, the standardized tables above are exported as XML format using the Vector toolchain. This XML is then imported into the Developer toolchain for development. After import, the toolchain can be used to verify that the model framework will have a newly added import interface for the E2E receiver. E2E configurations are added to the corresponding interfaces according to the requirements of each Software Component (SWC) in the application layer; this step is performed in the Developer toolchain. This embodiment of the application requires subsequent configuration of the RTE to expose E2E information, complete E2E communication development, and provide the communication ports required by the application layer. The relevant content of the ARXML corresponding to the above configuration is shown below: <service-interface> <operation Name="BrakePressureSet" E2EProtection="true" Profile="P4" / > <data-element Type="uint32" Offset="0x20" CRC-Position="0x3C" / > < / service-interface> Further, after verifying that the project is correct, continue using Developer to export the ARXML file configured above. Import the ARXML into a development tool, such as Simulink modeling or hand-written code development. Taking Simulink as the development tool as an example, the model framework will add a new import interface to represent the E2E result. The application layer, from the perspective of the recipient, completes functional degradation design according to functional safety requirements, etc.

[0031] Optionally, in some embodiments, when configuring the parameters of the communication port of the target application programming interface based on the requirements of the preset application layer software components, the method further includes: when the communication port of the target application programming interface meets the preset communication conditions, setting the end-to-end protection attribute of the communication port to the enabled state.

[0032] Among them, the preset communication conditions are the prerequisite checks performed on the basic technical attributes that the target API communication port must meet before enabling the end-to-end protection function.

[0033] Understandably, from the receiver's perspective, the port for configuring the E2E API is selected (first confirming whether the port communication is satisfactory), and "End To End Protection" is checked as True. The purpose is to allow the application layer code to generate the E2EPW_Read function for calling.

[0034] In step S103, end-to-end verification software is obtained based on the ARXML file, end-to-end protection information, and preset configuration tools.

[0035] Optionally, in some embodiments, obtaining end-to-end verification software based on ARXML files, end-to-end protection information, and preset configuration tools includes: importing the ARXMIL file into the application layer; updating the runtime environment layer code and the basic software layer code in the application layer based on the ARXMIL file, end-to-end protection information, and preset configuration tools; and integrating and compiling the updated runtime environment layer code and basic software layer code with the application layer code to obtain the end-to-end verification software.

[0036] Specifically, the underlying layer updates the BSW (Runtime Environment) and RTE (Base Software) layer code based on the communication ARXMIL file containing E2E protection information and the Developer project configured with E2E information, and generates the header and source files for the empty function E2EPW_Read. A pre-defined configuration tool generates header files declaring protection strategies (Profile1 / 2 / ...), verification templates, and other key code structures based on ARXML. Then, the development code containing the E2E interface provided by the application layer is compiled with the underlying code to generate complete software (end-to-end verification software) with E2E communication and upper-layer functionality.

[0037] Therefore, this application embodiment utilizes configuration tools to implement E2E protection for the required API interfaces, and achieves the design requirements through upstream and downstream transmission by toolchain developers. By selecting the target configuration items, the corresponding main code framework and interface functions are generated, which is more streamlined and flexible compared to full code development.

[0038] Optionally, in some embodiments, after obtaining the end-to-end verification software based on the ARXML file, end-to-end protection information, and a preset configuration tool, the method further includes: acquiring the target application programming interface (API) communication message through an Ethernet packet capture tool; extracting the CRC checksum calculation sequence based on the API communication message, and calculating the CRC checksum calculation sequence based on a preset CRC algorithm, polynomial, and initial value to obtain a local CRC checksum value; comparing the local CRC checksum value with the CRC field value in the API communication message, and determining that the end-to-end protection information configuration is correct when the local CRC checksum value matches the CRC field value in the API communication message.

[0039] The preset CRC (Cyclic Redundancy Check) algorithm refers to a specific cyclic redundancy check algorithm that is predefined and embedded in the configuration information (such as ARXML files) during the end-to-end protection configuration phase.

[0040] It is understandable that capturing raw communication data (such as Ethernet frames) from a real network environment ensures that the verification is based on actual transmitted field data containing complete E2E protection fields (such as CRC). Based on the E2E protection information (such as Profile type) defined in the ARXML file, the original data sequence participating in the CRC calculation is accurately parsed from the captured message (e.g., extracting fields such as Length, Counter, and Data ID according to Profile 4 rules). Using a preset CRC algorithm, polynomial, and initial value, the extracted sequence is independently calculated. The locally calculated value is compared with the CRC field value in the message. If they match, it proves that the E2E protection configuration in the ARXML file is correct, the generated software correctly implements the configuration, the protection logic of the sending and receiving ends is strictly synchronized, and the data integrity was not compromised during this transmission. This application's embodiment effectively solves the problem of directly and independently verifying whether the E2E protection mechanism works correctly as designed in traditional testing.

[0041] Therefore, this application's embodiments relate to SOA communication reliability enhancement technology under the AUTOSAR CP platform, which is particularly suitable for intelligent vehicle scenarios where the EE architecture evolves into a region controller. This application's embodiments address the problems in related technologies where "E2E protection" implemented through handwritten code suffers from a lack of automated collaboration, cumbersome preliminary preparation work, high error rates in later integration, unsatisfactory SOA architecture implementation, and poor reusability of conventional CRC calculation applets when different projects have significant differences in E2E algorithms or multiple combinations. It achieves full-process standardization and automation of end-to-end protection, significantly improving development efficiency, reducing the risk of manual errors, and providing objective and traceable verification methods to effectively ensure the correctness and reliability of functional safety mechanism implementation.

[0042] To facilitate those skilled in the art to further understand the end-to-end software configuration method of the embodiments of this application, the following is combined with... Figures 2 to 4 The embodiments shown will be described in detail.

[0043] Specifically, such as Figure 2 As shown, Figure 2 The flowchart below illustrates an embodiment of the configuration method for end-to-end software under an SOA architecture for adding E2E protection to APIs. First, a list of service-oriented application programming interfaces (APIs) requiring end-to-end protection is compiled and determined. Based on this list, the corresponding project configuration is completed in a configuration tool, and an ARXML description file containing all configuration information is exported. Subsequently, an empty header file and source file framework containing the E2EPW_Read function are generated based on the ARXML file, and provided to the application layer for functional logic design. After software deployment and operation, actual communication packets are captured using a packet capture tool. The check sequence is extracted based on the frame header structure defined in the configuration, and the local check value is independently calculated according to a preset CRC algorithm, polynomial, and initial value. Finally, the calculation result is compared with the actual CRC field carried in the packet to verify whether the end-to-end protection function is correctly implemented.

[0044] Therefore, this application embodiment achieves automatic generation of the E2EPW_Read function framework through an automated configuration toolchain. Compared with traditional development solutions, the automated toolchain configuration significantly shortens the development cycle and greatly improves the coverage of automatic code generation. In addition, the ARXML annotation mechanism unifies the E2E protection strategies among various ECUs, effectively reducing the integration error rate. Multiple E2E combination configurations increase the difficulty of encryption verification, fully meeting the functional safety requirements. At the same time, the dynamic CRC verification program can support multiple CRC algorithm combinations (CRC-8 / 16 / 32, etc.), adapting to the E2E profile requirements of different projects, and the verification tool can be used on various project platforms. Through polynomial parameter configuration, the ISO standard's conformance testing requirements for automotive Ethernet are met. The above automated configuration and testing verification methods for API E2E protection strongly support the evolution of the AUTOSAR architecture, realize dynamic discovery of service interfaces and automatic loading of protection strategies, improve the implementation efficiency of SOA architecture, and reduce OEM adaptation costs.

[0045] Furthermore, the embodiments of this application can also be used to briefly illustrate the configuration method of the end-to-end software of this application.

[0046] Specifically, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the header layout provided by Profile 4 for an end-to-end software configuration method according to an embodiment of this application. The invention illustrates a header layout using E2E Profile 4 as an example. This diagram serves as the basis for the detailed explanation of how to perform multiple CRC verifications, and corresponds to the structure of an Ethernet frame parsed using the Wireshark packet capture tool. If the Ethernet network defined in the project uses the Profile 4 algorithm, referring to AutoSAR_PRS_E2EProtocol, the algorithm elements include: Length, Counter, Data ID, and CRC Checksum. By applying and calculating the algorithm elements, embodiments of this application can identify communication errors that occur during data transmission. The specific byte size of each element is as follows... Figure 3 As shown, User Data does not affect the verification result and can be ignored during the verification process. Header has a fixed layout and is also an essential element for CRC calculation.

[0047] Furthermore, when E2E communication protection is combined with SOME / IP, the E2E CRC checksum calculation includes the following components: RequestID (ClientID / Session ID), Protocol Version, Interface Version, MessageType, Return Code, and Payload. These elements are serialized according to the algorithm's defined order, ultimately yielding a sequence used for CRC checksum calculation. Finally, a CRC database is called to calculate the CRC checksum value from this sequence.

[0048] Furthermore, such as Figure 4 As shown, Figure 4 This is a schematic diagram of the program interface for performing multiple CRC test verification in a configuration method for end-to-end software according to an embodiment of this application; the present invention provides a program interface for performing multiple CRC test verification. After capturing packets of the service with added E2E protection information, according to the algorithm description above, firstly, the RequestID (ClientID / Session ID), Protocol Version, etc., are serialized in sequence and filled into the "Data to be verified (hexadecimal)" window. Secondly, the parameter model, width, polynomial, initial value, and XOR value are filled in according to the specification definition. Among them, since the parameters for implementing multiple CRC algorithm protection have exceeded the range of the classic model, the parameter model is not mandatory. The remaining width (e.g., 32 for CRC32), polynomial (e.g., 0xFFFFFFF), initial value (e.g., 0xFFFFFFF), whether the input data and result data are reversed, and XOR value are filled in according to the specified CRC algorithm element requirements. Except for the "Data to be verified" item, which is variable, the others are fixed contents specified by the algorithm. Finally, click the "Calculate" button to get the checksum value. Compare this value with the CRC bit of the corresponding data in the Wireshark window. If they match, the frame is considered to have communicated normally.

[0049] It should be noted that during the development of this CRC algorithm, Check and MagicCheck can be used to verify the correctness of the program and to optimize and correct it in a timely manner. When the verification result does not match the actual result, the E2E interface function will return the corresponding error value. The application layer will trigger corresponding function degradation or security protection based on the error value until communication is restored to normal. At the communication level, the E2E receiver will receive data according to a specific period. When the difference exceeds the threshold, it will trigger an E2E state machine switch and respond to internal operational faults that may cause E2E protection failure.

[0050] Furthermore, the following example (not complete code, for structural reference only) is provided for the program algorithm involved in the multiple CRC check of this invention: unsigned int CRC32(unsigned char *puchMsg, unsigned int usDataLen) {int i; unsigned int wCRCin = 0xFFFFFFFF; unsigned int wCPoly = 0x04C11DB7; unsigned int wChar = 0; while (usDataLen--) {wChar = *(puchMsg++); InvertUint8((unsigned char *)&wChar,(unsigned char *)&wChar); wCRCin ^= (wChar<<24); for(i = 0;i<8;i++) {if(wCRCin&0x80000000) wCRCin = (wCRCin<<1) ^ wCPoly; else wCRCin = wCRCin<<1; } } InvertUint32(&wCRCin,&wCRCin); return (wCRCin ^ 0xFFFFFFFF) ; } Therefore, for CRC32, other polynomials, initial values, and polynomials may be involved. Requirements such as whether the input data and result data need to be reversed can be supplemented and modified based on the above source code.

[0051] According to the end-to-end software configuration method proposed in this application, the end-to-end protection information of the target application programming interface is obtained; based on the requirements of the preset application layer software components, the communication port of the target application programming interface is parameter-configured, and an ARXML file is generated according to the configured target application programming interface; based on the ARXML file, the end-to-end protection information, and the preset configuration tool, end-to-end verification software is obtained. Thus, by automating the end-to-end protection information annotation, communication port parameter setting, code generation, and independent verification process, the problems of cumbersome configuration, error-prone manual code integration, and unintuitive and inefficient functional verification in traditional E2E protection implementation are solved, improving development efficiency and reliability.

[0052] Next, with reference to the accompanying drawings, a configuration apparatus for end-to-end software according to an embodiment of this application is described.

[0053] Figure 5 This is a block diagram of an end-to-end software configuration device according to an embodiment of this application.

[0054] like Figure 5 As shown, the configuration device 10 for the end-to-end software includes: an acquisition module 100, a configuration module 200, and a determination module 300.

[0055] The acquisition module 100 is used to acquire end-to-end protection information of the target application programming interface; The configuration module 200 is used to configure the communication port of the target application programming interface based on the requirements of the preset application layer software components, and generate an ARXML file according to the configured target application programming interface. Module 300 is used to obtain end-to-end verification software based on ARXML files, end-to-end protection information, and preset configuration tools.

[0056] Optionally, end-to-end protection information includes at least one of the following: service name, service ID, event name, timeout information, and end-to-end configuration file type.

[0057] Optionally, when configuring the communication port of the target application programming interface based on the requirements of the preset application layer software components, the configuration module 200 is further configured to: set the end-to-end protection attribute of the communication port to the enabled state when the communication of the communication port of the target application programming interface meets the preset communication conditions.

[0058] Optionally, after obtaining the end-to-end verification software based on the ARXML file, end-to-end protection information, and a preset configuration tool, module 300 is further configured to: acquire the target application programming interface (API) communication message through an Ethernet packet capture tool; extract the CRC checksum calculation sequence based on the API communication message, and calculate the CRC checksum calculation sequence based on a preset CRC algorithm, polynomial, and initial value to obtain a local CRC checksum value; compare the local CRC checksum value with the CRC field value in the API communication message, and determine that the end-to-end protection information configuration is correct when the local CRC checksum value matches the CRC field value in the API communication message.

[0059] Optionally, module 300 is specifically used for: importing the ARXMIL file into the application layer; the application layer updates the runtime environment layer code and the basic software layer code based on the ARXMIL file, end-to-end protection information, and preset configuration tools; and integrating and compiling the updated runtime environment layer code and basic software layer code with the application layer code to obtain end-to-end verification software.

[0060] It should be noted that the explanation of the above-described configuration method embodiment for end-to-end software also applies to the configuration device for end-to-end software in this embodiment, and will not be repeated here.

[0061] According to the end-to-end software configuration device proposed in this application embodiment, the end-to-end protection information of the target application programming interface is obtained; based on the requirements of the preset application layer software components, the communication port of the target application programming interface is parameter-configured, and an ARXML file is generated according to the configured target application programming interface; based on the ARXML file, the end-to-end protection information, and the preset configuration tool, end-to-end verification software is obtained. Thus, by automating the end-to-end protection information annotation, communication port parameter setting, code generation, and independent verification process, the problems of cumbersome configuration, error-prone manual code integration, and unintuitive and inefficient functional verification in traditional E2E protection implementation are solved, improving development efficiency and reliability.

[0062] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 601, the processor 602, and the computer program stored on the memory 601 and capable of running on the processor 602.

[0063] When the processor 602 executes the program, it implements the end-to-end software configuration method provided in the above embodiments.

[0064] Furthermore, electronic devices also include: Communication interface 603 is used for communication between memory 601 and processor 602.

[0065] The memory 601 is used to store computer programs that can run on the processor 602.

[0066] The memory 601 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0067] If the memory 601, processor 602, and communication interface 603 are implemented independently, then the communication interface 603, memory 601, and processor 602 can be interconnected via a bus to complete communication between them. 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 representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0068] Optionally, in a specific implementation, if the memory 601, processor 602, and communication interface 603 are integrated on a single chip, then the memory 601, processor 602, and communication interface 603 can communicate with each other through an internal interface.

[0069] The processor 602 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0070] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described end-to-end software configuration method.

[0071] This application also provides a computer program product that stores a computer program that, when executed by a processor, implements the above-described end-to-end software configuration method.

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

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

[0074] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

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

[0076] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

Claims

1. A method for configuring end-to-end software, characterized in that, Includes the following steps: Obtain end-to-end protection information for the target application's programming interface; Based on the requirements of the preset application layer software components, the communication port of the target application programming interface is configured with parameters, and an ARXML file is generated according to the configured target application programming interface. Based on the ARXML file, the end-to-end protection information, and the preset configuration tools, end-to-end verification software is obtained.

2. The method according to claim 1, characterized in that, The end-to-end protection information includes at least one of the following: service name, service ID, event name, timeout information, and end-to-end configuration file type.

3. The method according to claim 1, characterized in that, When configuring the communication port parameters of the target application programming interface based on the requirements of the preset application layer software components, the following is also included: When the communication port of the target application programming interface meets the preset communication conditions, the end-to-end protection attribute of the communication port is set to enabled.

4. The method according to claim 1, characterized in that, After obtaining the end-to-end verification software based on the ARXML file, the end-to-end protection information, and the preset configuration tool, the software further includes: Use an Ethernet packet capture tool to obtain communication messages from the target application's programming interface. Based on the communication message of the target application programming interface, the CRC check calculation sequence is extracted, and the CRC check calculation sequence is calculated based on the preset CRC algorithm, polynomial and initial value to obtain the local CRC check value; The local CRC checksum is compared with the CRC field value in the target application programming interface (API) communication message. When the local CRC checksum matches the CRC field value in the target API communication message, the end-to-end protection information is determined to be configured correctly.

5. The method according to claim 1, characterized in that, The end-to-end verification software, derived from the ARXML file, the end-to-end protection information, and the preset configuration tool, includes: Import the ARXMIL file into the application layer; The application layer updates the runtime environment layer code and the basic software layer code based on the ARXMIL file, the end-to-end protection information, and the preset configuration tool. The updated runtime environment layer code and basic software layer code are integrated and compiled with the application layer code to obtain the end-to-end verification software.

6. A configuration apparatus for end-to-end software, characterized in that, include: The acquisition module is used to acquire end-to-end protection information of the target application's programming interface; The configuration module is used to configure the communication port of the target application programming interface based on the requirements of the preset application layer software components, and generate an ARXML file according to the configured target application programming interface. The determination module is used to obtain end-to-end verification software based on the ARXML file, the end-to-end protection information, and the preset configuration tools.

7. The apparatus according to claim 6, characterized in that, The end-to-end protection information includes at least one of the following: service name, service ID, event name, timeout information, and end-to-end configuration file type.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the SOA-based Ethernet end-to-end configuration and verification method as described in any one of claims 1-5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the end-to-end software configuration method as described in any one of claims 1-5.

10. A computer program product, said computer program product storing a computer program, characterized in that, When executed by the processor, the program implements the configuration method for end-to-end software as described in any one of claims 1-5.

Images