XCP configuration system and method based on AUTOSAR architecture, storage medium and computer program product

Abstract

The invention provides an XCP configuration system and method based on an AUTOSAR architecture, a storage medium and a computer program product, and the method comprises the steps: automatically analyzing an A2L file and AUTOSAR description of a target ECU, obtaining XCP configuration basic data, analyzing access characteristics and resource demands of calibration signals or parameters in the XCP configuration basic data, and pre-judging dynamic extension demands, an AUTOSAR parameter configuration file based on ECU resource constraint is generated; and constructing a virtual resource pool according to the AUTOSAR parameter configuration file, receiving a DAQ list configuration request sent by an upper computer based on the virtual resource pool, executing dynamic resource allocation based on XCP configuration basic data, responding to a preset trigger event, and completing data acquisition and transmission preparation by utilizing pre-established direct memory mapping. According to the dynamic adaptive allocation method, the ECU resource utilization rate is improved, configuration errors and conflicts are reduced through hierarchical verification, and the real-time performance of collection and transmission is improved through direct memory mapping.

Description

Technical Field

[0001] This invention belongs to the field of automotive electronics development and testing technology, specifically relating to an XCP configuration system, method, storage medium, and computer program product based on the AUTOSAR architecture. Background Technology

[0002] With the increasing complexity of automotive electronic control systems, traditional calibration methods can no longer meet the demands for efficient and accurate calibration. AUTOSAR (AUTomotive Open System Architecture), as an open automotive electronic system architecture, provides a standardized platform for the development of automotive electronic control systems. XCP (Universal Measurement and Calibration Protocol) is a widely used protocol for calibrating automotive electronic control systems, supporting multiple transmission layers such as CAN and Ethernet. However, existing XCP solutions based on the AUTOSAR architecture cannot meet the requirements, mainly due to: cumbersome and inefficient configuration, serious resource waste, inadequate real-time performance, and significant security risks. For example, manual modification of AUTOSAR parameters often relies on manual operation, resulting in long configuration times, high error rates, and poor consistency. The traditional polling mode introduces latency, affecting calibration accuracy and vehicle safety. Plaintext data transmission is vulnerable to unauthorized access such as bus eavesdropping and OTA injection attacks. In summary, the shortcomings of existing solutions have become a bottleneck in the development of automotive electronic calibration technology and urgently need optimization. Summary of the Invention

[0003] To address the problems of cumbersome and inefficient configuration, severe resource waste, inadequate real-time performance, and significant security risks mentioned in the background art, this invention proposes an XCP configuration system, method, storage medium, and computer program product based on the AUTOSAR architecture.

[0004] An XCP configuration system based on the AUTOSAR architecture, which achieves one of the objectives of this invention, includes: The intelligent configuration engine module automatically parses the A2L (ASAM MCD-2 Measurement and Calibration Data) file and the AUTOSAR description of the target ECU to obtain basic XCP configuration data. It analyzes the access characteristics and resource requirements of calibration signals or parameters in the basic XCP configuration data and predicts dynamic expansion needs, generating an AUTOSAR parameter configuration file. The basic XCP configuration data includes signal definitions, calibration values, XCP-specific configurations, and memory mapping parameters. The signal definitions are extracted from the MEASUREMENT section of the A2L file, including signal ID, data type, sampling rate, accuracy, and continuity or event-based characteristics. The calibration values ​​are extracted from the CHARACTERISTIC section of the A2L file, including parameter ID, physical range, and storage address. The XCP-specific configurations are extracted from the IF_DATAXCP section of the A2L file, including protocol version and maximum DAQ list length. The memory mapping parameters are extracted from the MODULE / MEMORYSEGMENT field of the A2L file, including RAM or ROM address range and access permissions. The target ECU refers to the electronic control unit (ECU) that requires XCP protocol configuration and data acquisition. Dynamic DAQ resource pool configuration module: used to construct a virtualized resource pool according to the AUTOSAR parameter configuration file. When a DAQ list configuration request is received from the host computer, the module processes the request based on the virtualized resource pool. This includes: obtaining the resource requirements of the acquired signal from the XCP configuration base data according to the acquired signal ID in the DAQ list configuration request; allocating an appropriate Slot unit in the virtualized resource pool according to the resource requirements; and binding the Slot unit to the trigger event type in the DAQ list configuration request. When the bound trigger event is detected, data acquisition and transmission preparation are completed using a pre-established memory mapping representing the Slot unit and the corresponding signal variable.

[0005] Furthermore, the method of preparing for data acquisition and transmission by utilizing a pre-established memory mapping representing slot units and corresponding signal variables includes: By using the memory mapping relationship between the Slot unit and the corresponding variable of the signal, the real-time value of the variable corresponding to the signal can be directly read and written into the Slot unit; After the Slot unit is written, it is marked as ready. The ready state is used to trigger the transport layer to send the data in the Slot unit to the host computer.

[0006] Furthermore, after the Slot unit is written and marked as ready, the process also includes adding the Slot unit's identification information to the transmission queue. The transmission queue sorts the ready data according to the first-in-first-out principle, so that the transmission layer can extract and send it to the host computer in sequence, thereby completing the entire process of data acquisition and transmission preparation.

[0007] Furthermore, it also includes an AUTOSAR configuration parameter verification module, used to verify whether the AUTOSAR parameter configuration file meets basic constraints and / or resource adaptability constraints. The basic constraints refer to constraints that ensure the AUTOSAR parameter configuration file conforms to the AUTOSAR specification and the basic operating requirements of the ECU hardware / software, avoiding basic compatibility failures. The resource adaptability constraints refer to constraints that ensure the AUTOSAR parameter configuration file is compatible with the operating characteristics of the dynamic DAQ resource pool, avoiding resource allocation conflicts or low operating efficiency. Specific implementations of the basic constraints include, but are not limited to: PDU length not exceeding the maximum data field length of the transport layer (such as CAN, Ethernet) to avoid data fragmentation leading to transmission failure; memory alignment meeting the ECU processor architecture requirements, such as 4-byte alignment for ARM architecture and 8-byte alignment for X86 architecture, avoiding abnormal memory access; and XCP-related tasks having lower priority than safety monitoring tasks to ensure the real-time performance of functional safety-related tasks.

[0008] The specific implementation of the resource adaptability constraints includes, but is not limited to: matching the sampling rate of the signals in the configuration file with the slot unit reuse capability of the dynamic resource pool, such as ensuring that high-frequency sampling signals do not exceed the maximum reuse count of the slot unit to avoid data loss; matching the signal priority with the access permissions of the resource pool partitions to avoid high-priority signals being allocated to low-priority partitions, which would cause response delays; and ensuring that the total memory requirement of all signals does not exceed the reserved memory capacity of the virtualization resource pool to avoid memory overflow.

[0009] The safety monitoring tasks refer to high-priority tasks within the ECU used to ensure its safe operation. Their operation is unaffected by other tasks and includes: hardware-level monitoring such as anomaly detection of power supply voltage, chip temperature, and clock frequency; software-level monitoring such as task timeout monitoring, memory out-of-bounds detection, and critical signal validity verification; and safety mechanism triggering such as executing degradation strategies and triggering Diagnostic Trouble Code (DTC) storage upon detecting anomalies. These tasks typically have the highest priority and cannot be preempted by other tasks, otherwise, safety risks such as power interruption or brake failure may occur. XCP-related tasks refer to tasks that implement XCP protocol functions, such as DAQ list configuration parsing tasks and data acquisition and transmission tasks. Their priority is configured lower than that of safety monitoring tasks to avoid affecting the real-time performance of safety monitoring.

[0010] Furthermore, the intelligent configuration engine module also includes a demand analysis and resource pre-planning submodule, which is used to read the XCP configuration basic data, calculate the number of DAQ lists divided by signal sampling rate or trigger type and the memory requirements, and output analysis results including the number of DAQ lists, the total number of measurement channels and the memory requirements.

[0011] Furthermore, the intelligent configuration engine module also includes a configuration generation submodule, which is used to receive the analysis results output by the demand analysis and resource pre-planning submodule, generate an AUTOSAR parameter configuration file containing Xcp module parameters, XcpOnCan / XcpOnEth module parameters, Com module parameters, Os module parameters, Rte module parameters, and MemMap module parameters, and transmit the AUTOSAR parameter configuration file to the dynamic DAQ resource pool module.

[0012] Furthermore, the dynamic DAQ resource pool module includes an initialization submodule, used to initialize at least one virtualized resource pool containing fixed-size slot units based on the shared memory area of ​​XcpDaq_DynamicPoolMemory reserved in the AUTOSAR parameter configuration file and the memory requirements and number of DAQ lists in the analysis results; the total capacity of the virtualized resource pool is determined based on the memory requirements, and the total number of slot units is adapted based on the number of DAQ lists; the size of the slot unit is determined by the maximum byte length of the calibration signal (i.e., the measurement variable) to be collected in the A2L file and the AUTOSAR memory alignment requirements.

[0013] Furthermore, the initialization submodule is also used to partition the virtualized resource pool according to the signal priority, signal type, and total number of measurement channels in the AUTOSAR parameter configuration file. The signal priority partitioning includes a High-Prio Pool and a Low-Prio Pool, while the signal type partitioning includes a Time-Based Pool and an Event-Based Pool. The number of slot units in each partition is allocated based on the proportion of the total number of measurement channels in the analysis results output by the intelligent configuration engine module. For example, when the signal sampling rate in the analysis results is high-frequency sampling (e.g., ≥1kHz) or high priority, the resource pool type corresponding to that signal ID is determined to be a High-Prio Pool; when the sampling rate is low or the priority is normal, it corresponds to a Low-Prio Pool. When the signal trigger type in the analysis results is a timer, it corresponds to a Time-Based Pool; when the trigger type is a hardware event, it corresponds to an Event-Based Pool. The Pool is also used to construct an idle Slot linked list and add all Slot units to the list after initializing them to an idle state according to a preset strategy. The preset strategy includes sorting by memory address increment, sorting by Slot unit size, or sorting by priority associated with signal type.

[0014] Furthermore, the dynamic DAQ resource pool module also includes a DAQ configuration submodule, which is used to receive a DAQ list configuration request sent by the host computer, which includes signal ID, trigger event, and transmission mode; determine the resource pool type corresponding to the signal ID by combining the analysis results of the intelligent configuration engine module; select an idle Slot unit that meets the memory size and access permission requirements; establish a direct memory mapping between the Slot unit and the application layer variables to be collected in the ECU; and bind the Slot unit to the trigger event in the request.

[0015] Furthermore, the DAQ configuration submodule is also used to associate and store the DAQ list identifier, signal ID, trigger event, SlotID, and resource pool information into an internal mapping table, mark the Slot unit as occupied and remove it from the free Slot list, and feed back the Slot ID to the host computer.

[0016] Furthermore, the DAQ configuration submodule also includes a data transmission submodule, which is used to detect hardware events or software events bound to the Slot unit, match the corresponding Slot unit according to the internal mapping table, fill the real-time values ​​of the application layer variables to be collected in the ECU into the Slot unit using direct memory mapping, mark the data of the Slot unit as ready and set the transmission queue or status bit.

[0017] A second objective of this invention is an XCP configuration method based on the AUTOSAR architecture, comprising: Automatically parse the A2L file and the AUTOSAR description of the target ECU, obtain the XCP configuration basic data, analyze the access characteristics and resource requirements of the calibration signals or parameters in the XCP configuration basic data and predict dynamic expansion requirements, and generate an AUTOSAR parameter configuration file. A virtualized resource pool is constructed based on the AUTOSAR parameter configuration file. Based on this virtualized resource pool, the system receives DAQ list configuration requests sent by the host computer and performs dynamic resource allocation based on the XCP configuration base data. It responds to preset trigger events and completes data acquisition and transmission preparation using pre-established direct memory mapping.

[0018] A non-transitory computer-readable storage medium for achieving the third objective of the present invention, wherein a computer program is stored thereon, characterized in that the computer program, when executed by a processor, implements the steps of the XCP configuration method based on the AUTOSAR architecture.

[0019] A computer program product for achieving the fourth objective of the present invention includes a computer program / instruction that, when executed by a processor, implements the steps of the XCP configuration method based on the AUTOSAR architecture.

[0020] The beneficial effects of this invention include: 1. By combining the demand analysis of the intelligent configuration engine with the collaboration of the dynamic DAQ resource pool, the initialization and partitioning of the resource pool are optimized based on the analysis results, realizing dynamic adaptation and allocation of resources, improving ECU resource utilization and configuration flexibility, and meeting the acquisition needs of different signals.

[0021] 2. A hierarchical verification mechanism is adopted, which ensures the compliance of AUTOSAR parameter configuration files through basic constraints and ensures compatibility with dynamic resource pools through resource adaptability constraints, thereby reducing configuration errors and runtime resource conflicts and improving system stability.

[0022] 3. By leveraging direct memory mapping to achieve efficient data acquisition, combined with the closed-loop interaction between the Slot unit and the host computer, data transmission latency is reduced, the real-time performance of data acquisition and transmission under the XCP configuration is improved, and the stringent requirements of the AUTOSAR architecture are met. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the framework of an embodiment of the system described in this invention; Figure 2 This is a schematic diagram of the A2L file parsing framework; Figure 3 This is a flowchart illustrating the intelligent configuration engine process. Detailed Implementation

[0024] The following detailed embodiments are provided to explain the technical solutions of the present invention, so that those skilled in the art can understand the present invention. The scope of protection of the present invention is not limited to the following specific embodiments. Any modifications or improvements made by those skilled in the art that incorporate the technical solutions of the present invention but differ from the following detailed embodiments are also within the scope of protection of the present invention.

[0025] An XCP configuration method based on AUTOSAR architecture includes: S1, Intelligent Configuration Engine XCP AUTOSAR Configuration S1.1 Automatically parse A2L files like Figure 2 As shown, the engine performs deep parsing of the A2L file. Based on the MEASUREMENT section, signal definitions are obtained, including signal ID, data type, sampling rate, precision, and continuity / eventality. Calibration parameters are obtained from the CHARACTERISTIC section, including parameter ID, physical range, and storage address. XCP-specific configurations are obtained from the IF_DATA XCP section, including protocol version and maximum DAQ list length. Memory mapping parameters are obtained from the MODULE / MEMORY SEGMENT field, including RAM / ROM address range and access permissions. The A2L (ASAM MCD-2MC Language) file is a well-known standard document in the field of automotive electronics calibration and serves as the source of basic data required for XCP configuration in this invention.

[0026] By combining the AUTOSAR description (ECU Configuration Description, usually a part of a .arxml file) of the target ECU, available resource constraints are obtained, such as the starting address and size of the available RAM region, the communication controller type, and HSM capabilities. The .arxml (AUTOSAR XML File) file is a standardized description / configuration file under the AUTOSAR standard. Based on the general tree structure of XML, it uses the AUTOSAR standard's XSD (XML Schema Definition) to constrain the file content, ensuring consistent file parsing across different manufacturers and toolchains. In this invention, it is used to store key information throughout the entire process, from configuration planning to operational support.

[0027] S1.2 Demand Analysis and Resource Pre-planning The required access characteristics for each signal / parameter defined in the A2L file obtained from analysis step S1 are: sampling rate, accuracy, continuity / eventality.

[0028] The required number of DAQ lists, the total number of measurement channels, and their memory requirements are calculated. The number of DAQ lists is divided according to the signal sampling rate and trigger type; for example, a 10ms period signal is grouped into one DAQ list, and event-triggered signals are grouped into another DAQ list. The total number of measurement channels is equal to the number of valid signals in the MEASUREMENT field of the A2L file, excluding duplicates or signals marked as invalid. The memory requirement is equal to the product of the single-channel memory and the number of channels, multiplied by a redundancy factor greater than 1. Anticipate potential dynamic expansion needs, such as temporarily adding monitoring points during the diagnostic process. This is based on the list of diagnostic events defined in the DIAGNOSTIC_SEGMENT section of the A2L file, such as the need to add monitoring points when an ECU fault code is triggered.

[0029] S1.3 Configuring for Automated Constraint Generation: S1.3.1 Generating AUTOSAR parameters All relevant BSW (Basic Software) configuration parameters are automatically generated and stored in .arxml format files, thus precisely addressing configuration difficulties. The BSW is the foundational software layer of the AUTOSAR framework, comprising the following modules, each configuring parameters related to XCP communication functions: Xcp: XcpConfigSet module: used to configure XCP protocol parameters, including version and basic parameters; The XcpOnCan / XcpOnEth modules are used to adapt to the XCP transport layer, including configuring baud rate / address, frame format, and transport layer-related configurations such as TransportProtocol. COM module: Used to define the Communication Cluster (corresponding to the physical communication bus of the ECU) and PDU (protocol data unit, the data carrier carrying the XCP frame) containing the XCP frame, and to encapsulate the XCP frame communication.

[0030] The Os module is a core module of the BSW service layer, used to schedule XCP tasks and configure appropriate priorities and scheduling for necessary tasks / interrupts (such as ISR for Event Trigger).

[0031] The MemMap module is used to manage XCP memory mapping, including pre-allocating shared memory regions for the dynamic DAQ pool and configuring access attributes. The shared memory region comes from the MEMORY_AREA_PROTOTYPE attribute, the starting address comes from the free address of the available RAM region in the ECU, and the size = pre-planned memory requirement + 0.1 × pre-planned memory requirement. If PROTECTED protection is used, access is configured to allow only XCP-related authorized modules to access it.

[0032] In one embodiment, a separate Rte module is also included: used to connect the application layer and the BSW, including: automatically generating Data Mapping, and connecting application layer variables with XCP resource pool channels or C / S Interfaces. The application layer variable addresses come from the MODULE / MEMORY SEGMENT segment of A2L, and the connection relationship is stored in the Data Element configuration of the Rte; S1.3.2 Configuration Constraint Verification The automatic verification checks whether the generated configuration complies with AUTOSAR BSW constraints, such as the PDU length not exceeding the maximum data field length of the transport layer; memory alignment meets the ECU processor architecture requirements, such as 4-byte alignment for 32-bit processors; and task scheduling feasibility ensures that XCP does not preempt security monitoring tasks and generates error / warning reports.

[0033] This step outputs a directly usable and complete AUTOSAR ECU configuration description in .arxml format, which significantly solves the problems of tedious and error-prone manual configuration and lays the foundation for subsequent dynamic resources and efficient transmission.

[0034] S2. Building and Running a Dynamic DAQ Resource Pool The initialization, configuration, and data transfer of the dynamic DAQ (Data Acquisition) resource pool all rely on the .arxml file generated by the intelligent configuration engine, which contains the configurations of the MemMap, Xcp, Os, and Rte modules; including the initialization phase, the DAQ configuration phase, and the data transfer phase. The initialization phase includes: One or more virtualized resource pools are initialized based on the shared memory area (XcpDaq_DynamicPoolMemory) reserved in the .arxml file generated by the intelligent configuration engine. Each pool contains a fixed-size slot unit; the slot size is determined by the intelligent configuration engine based on the maximum byte length of the measurement variables in the A2L file and the AUTOSAR memory alignment requirements.

[0035] Based on the signal characteristics analyzed from the A2L file by the intelligent configuration engine, initialize pool attributes, such as: partitioning by priority: High-Prio Pool, Low-Prio Pool; partitioning by signal type: Time-Based, Event-Based.

[0036] Construct a linked list, initialize all slots to an idle state, and add them to the linked list according to the pool strategy. The linked list rules are preset by the smart configuration engine in the .arxml file.

[0037] The DAQ configuration phase includes: The Xcp module parses the DAQ list configuration request sent by the host computer, which includes information such as signal ID, trigger event, and transmission mode. The signal ID must match the signal attributes parsed by the intelligent configuration engine from the MEASUREMENT section of the A2L file; trigger events include ADC completion interrupt and software diagnostic events; and transmission modes include continuous transmission and event-triggered transmission.

[0038] Based on the signal demand characteristics analyzed in the early stages by the intelligent engine, the dynamic allocator executes an optimized allocation algorithm, including: Based on the signal ID in the DAQ list configuration request, check the signal attributes, such as the HIGH_PRIORITY flag, fixed sampling rate, and event-driven, to determine the required resource pool type for the signal.

[0039] Based on the signal attributes in the request, select an idle slot from the resource pool of the corresponding priority, ensuring that the slot's memory size, access permissions, and other resource specifications meet the signal transmission requirements of the DAQ list configuration request.

[0040] Establish a direct mapping between the memory address of the selected slot and the address of the application variable. The mapping relationship must match the variable mapping rule corresponding to the signal ID in the DAQ list configuration request to avoid deep copying of the Rte layer, and ensure security through preset access attributes of MemMap.

[0041] Based on the trigger event information in the DAQ list configuration request, establish the binding relationship between the slot and the trigger event specified in the request. For example, EVENT_CHANNEL_1 corresponds to the completion interrupt of a certain ADC, ensuring that the slot can be accurately located when subsequent events are triggered.

[0042] The DAQ list identifier, signal ID, trigger event, allocated Slot ID, and resource pool information from the DAQ list configuration request are associated and stored in the internal mapping table DaqList_Slot_Table, forming a corresponding record between the request and the resource.

[0043] The allocated slot is marked as occupied and removed from the free list. The slot ID is then fed back to the host computer.

[0044] The data transmission phase is the direct follow-up execution of the DAQ configuration phase. All its operations are based on the slot resource allocation, trigger event binding, and direct memory mapping completed in the DAQ configuration phase. In the early stage, a dedicated slot has been defined for the signal to be collected, the trigger conditions have been specified, and the address association between variables and slots has been established. In this phase, it is only necessary to respond to the preset trigger events to complete the preparation for data collection and transmission.

[0045] After the DAQ resource pool is configured, the system will monitor in real time whether related events occur at the hardware or software level. The real-time monitoring process includes: 1. Event Triggering Detection When a hardware or software event occurs, the event must be consistent with the trigger event bound to a specific slot in the DAQ configuration phase. The binding relationship is determined in the DAQ configuration phase by establishing an association between the slot and the requested trigger event. The hardware event is such as the ADC completing sampling and triggering ECU_EVENT_ADC_DONE. When the slot data is marked as ready and enters the XCP transmission process, the security mechanism associated with the DAQ configuration phase will be automatically triggered. 2. Perform event correlation checks The OS interrupt service routine (ISR) or event task detects whether the event has been subscribed to by the XCP dynamic DAQ. The detection is based on the internal mapping table DaqList_Slot_Table updated during the DAQ configuration phase. This table records the correspondence between triggering events and slots, which can quickly match the slot to which the event belongs.

[0046] 3. Perform direct data collection and data filling. By utilizing the direct memory mapping pre-established for the slot during the DAQ configuration phase, the value of the target variable (such as the ADC sampling result) is immediately and without additional copying into the dynamic slot that has been bound to the event.

[0047] 4. Set the transmission preparation flag Mark the slot data as READY. You can set the send queue or status bit as needed to prepare for subsequent XCP protocol data transmission to the host computer.

[0048] The beneficial effects of the above steps include: the flexibility and efficiency of the dynamic resource pool are based on the secure memory area pre-allocated by the intelligent configuration engine and the established direct mapping. Simultaneously, its on-demand allocation characteristic provides precise and low-overhead mount points for event-triggered transfers, avoiding polling overhead. After DAQ is configured, the data it collects is transmitted through a security chain that also builds an XCP communication security guarantee chain, providing end-to-end security for XCP communication and covering all aspects of configuration, resource management, and data transmission.

[0049] The XCP communication security chain includes: integrating an encryption engine AES-128 or AES-256 in the Xcp_TxProcessing stage of the Xcp module's data transmission path.

[0050] The core payloads, such as command parameters and measurement data, in the command packets (CMD) sent by the host computer and the data packets (DAQ, RESPONSE) sent by the ECU are encrypted / decrypted. The header information of the data packets is usually kept in plaintext to ensure normal communication.

[0051] When establishing a session, the current session key is obtained through a secure handshake protocol. The Xcp module maintains the session key state, such as the XCP seed key negotiation or the SecOC key.

[0052] In one embodiment, AUTOSAR layer security authentication is also included. The XCP module passes the XCP frame containing the encrypted payload, which is ready to be sent, to the SecOC module for processing. The SecOC module adds a Freshness Value (FV) to the XCP frame according to its configuration and calculates the Message Authentication Code (MAC), generating a protected frame that is then passed to the lower layer (PDUR->COM) for transmission. The SecOC module at the receiving end performs reverse processing to verify the FV and MAC.

[0053] In one embodiment, the method further includes configuring a bound SecOCJob for the PDU containing the XCP during the intelligent configuration engine phase.

[0054] In one embodiment, hardware-level key management is also included. When SecOC needs to generate or verify a MAC, the signature / verification key used is securely stored in the HSM (Hardware Security Module), and the HSM performs the relevant key operations. The HSM is the core component in the ECU that provides hardware-level security.

[0055] In one embodiment, the method also includes providing encryption and decryption keys for XCP protocol layer encryption and their lifecycle management, such as generation, storage, rotation, and destruction.

[0056] In one embodiment, during ECU startup or the initial phase of the Xcp session, i.e., during the connection handshake, the Xcp module requests the HSM to perform key operations or protocols related to the upper-layer security mechanism via the CryptoIf or KeyM module interface. The intelligent configuration engine has pre-set the key slots required by Crypto / KeyM and their association with the SecOC and Xcp modules. Data in the dynamic slots is protected by MemMap during population.

[0057] When data is retrieved from a slot and packaged, i.e., during the event-triggered phase, the protocol layer encrypts the transmitted content to ensure confidentiality. After the complete XCP frame is transmitted out of the Xcp module, the SecOC module adds authentication information to ensure integrity and authenticity. All keys required for encryption, decryption, and authentication are provided and managed by the HSM module.

[0058] The functional configurations for these three security levels were generated in a coordinated manner during the initial intelligent configuration engine phase (using .arxml parameters), ensuring their effective integration within the AUTOSAR BSW.

[0059] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0060] This invention also provides an XCP configuration system based on the AUTOSAR architecture, such as... Figure 1 As shown, it includes: Intelligent configuration engine module: used to parse A2L files and the AUTOSAR description of the target ECU, obtain XCP configuration basic data, analyze the access characteristics and resource requirements of calibration signals or parameters in the XCP configuration basic data, and generate AUTOSAR parameter configuration files. Dynamic DAQ resource pool configuration module: used to construct a virtualized resource pool according to the AUTOSAR parameter configuration file. When a DAQ list configuration request is received from the host computer, the module processes the request based on the virtualized resource pool. This includes: obtaining the resource requirements of the acquired signal from the XCP configuration base data according to the acquired signal ID in the DAQ list configuration request; allocating an appropriate Slot unit in the virtualized resource pool according to the resource requirements; and binding the Slot unit to the trigger event type in the DAQ list configuration request. When the bound trigger event is detected, data acquisition and transmission preparation are completed using a pre-established memory mapping representing the Slot unit and the corresponding signal variable.

[0061] In one embodiment, the system further includes an AUTOSAR configuration parameter verification module, used to verify whether the AUTOSAR parameter configuration file meets basic constraints and / or resource adaptability constraints. The basic constraints refer to constraints that ensure the AUTOSAR parameter configuration file conforms to the AUTOSAR specification and the basic operating requirements of the ECU hardware / software, and avoid basic compatibility failures. The resource adaptability constraints refer to constraints that ensure the AUTOSAR parameter configuration file is adapted to the operating characteristics of the dynamic DAQ resource pool, and avoid resource allocation conflicts or low operating efficiency.

[0062] In one embodiment, the intelligent configuration engine module further includes a demand analysis and resource pre-planning submodule, which is used to read XCP configuration basic data, calculate the number of DAQ lists divided by signal sampling rate or trigger type and the memory requirements, and output analysis results including the number of DAQ lists, the total number of measurement channels and the memory requirements.

[0063] In one embodiment, the intelligent configuration engine module further includes a configuration generation submodule, which is used to receive the analysis results output by the demand analysis and resource pre-planning submodule, generate an AUTOSAR parameter configuration file containing Xcp module parameters, XcpOnCan / XcpOnEth module parameters, Com module parameters, Os module parameters, Rte module parameters, and MemMap module parameters, and transmit the AUTOSAR parameter configuration file to the dynamic DAQ resource pool module.

[0064] In one embodiment, the dynamic DAQ resource pool module includes an initialization submodule, which is used to initialize at least one virtualized resource pool containing fixed-size slot units based on the shared memory area reserved in the AUTOSAR parameter configuration file and the memory requirements and DAQ list number in the analysis results.

[0065] In one embodiment, the initialization submodule is further configured to partition the virtualized resource pool according to the signal priority, signal type and total number of measurement channels in the analysis results in the AUTOSAR parameter configuration file, and to construct an idle slot linked list and add all slot units to the linked list after initializing them to an idle state according to a preset strategy.

[0066] In one embodiment, the dynamic DAQ resource pool module further includes a DAQ configuration submodule, which is used to receive a DAQ list configuration request sent by the host computer, which includes a signal ID, a trigger event, and a transmission mode; determine the resource pool type corresponding to the signal ID by combining the analysis results of the intelligent configuration engine module; select an idle Slot unit that meets the memory size and access permission requirements; establish a direct memory mapping between the Slot unit and the application layer variables to be collected in the ECU; and bind the Slot unit to the trigger event in the request.

[0067] In one embodiment, the DAQ configuration submodule is further configured to associate and store the DAQ list identifier, signal ID, trigger event, Slot ID, and resource pool information into an internal mapping table, mark the Slot unit as occupied and remove it from the free Slot list, and report the Slot ID to the host computer.

[0068] In one embodiment, the DAQ configuration submodule further includes a data transmission submodule, which is used to detect hardware events or software events bound to the slot unit after the DAQ configuration submodule completes the slot unit allocation and trigger event binding, match the corresponding slot unit according to the internal mapping table, fill the real-time value of the application layer variable to be collected in the ECU into the slot unit using direct memory mapping, mark the data of the slot unit as ready and set the transmission queue or status bit.

[0069] This invention also provides an XCP configuration method based on the AUTOSAR architecture, including: Automatically parse the A2L file and the AUTOSAR description of the target ECU, obtain the XCP configuration basic data, analyze the access characteristics and resource requirements of the calibration signals or parameters in the XCP configuration basic data and predict dynamic expansion requirements, and generate an AUTOSAR parameter configuration file. A virtualized resource pool is constructed based on the AUTOSAR parameter configuration file. Based on this virtualized resource pool, the system receives DAQ list configuration requests sent by the host computer and performs dynamic resource allocation based on the XCP configuration base data. It responds to preset trigger events and completes data acquisition and transmission preparation using pre-established direct memory mapping.

[0070] This invention also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the various steps of the method described in this invention.

[0071] This invention also provides a non-transitory computer-readable storage medium storing a computer program. The computer program includes program instructions that, when executed by a processor, implement the various steps of the method described in this invention, which will not be elaborated further here.

[0072] The computer-readable storage medium can be the data transmission apparatus or the internal storage unit of a computer device provided in any of the foregoing embodiments, such as the hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device.

[0073] Furthermore, the computer-readable storage medium may include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that is to be output or has already been output.

[0074] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0075] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0076] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0077] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0078] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

Claims

1. An XCP configuration system based on AUTOSAR architecture, characterized in that, The application comprises: An intelligent configuration engine module: for parsing A2L files and AUTOSAR descriptions of target ECUs, obtaining XCP configuration basic data, analyzing access characteristics and resource requirements of calibration signals or parameters in the XCP configuration basic data, and generating an AUTOSAR parameter configuration file; A dynamic DAQ resource pool configuration module: for constructing a virtualized resource pool according to the AUTOSAR parameter configuration file, and processing a DAQ list configuration request sent by a host computer based on the virtualized resource pool when the request is received; the module comprises: obtaining resource requirements of a signal from the XCP configuration basic data according to a signal ID in the DAQ list configuration request, allocating an adaptive Slot unit in the virtualized resource pool according to the resource requirements, and binding the Slot unit with a trigger event type in the DAQ list configuration request; when the bound trigger event is detected, data acquisition and transmission preparation are completed by using a pre-established memory mapping representing a Slot unit and a signal corresponding variable.

2. The XCP configuration system based on AUTOSAR architecture of claim 1, wherein, The application further comprises an AUTOSAR configuration parameter verification module for verifying whether the AUTOSAR parameter configuration file meets basic constraints and / or resource adaptability constraints; the basic constraints refer to constraints for ensuring that the AUTOSAR parameter configuration file conforms to AUTOSAR specifications and basic requirements for ECU hardware / software operation, and avoiding basic compatibility faults; the resource adaptability constraints refer to constraints for ensuring that the AUTOSAR parameter configuration file is adapted to operating characteristics of the dynamic DAQ resource pool, and avoiding resource allocation conflicts or low operating efficiency.

3. The XCP configuration system based on AUTOSAR architecture according to claim 1 or 2, characterized in that, The intelligent configuration engine module further comprises a requirement analysis and resource pre-planning submodule for reading XCP configuration basic data, dividing DAQ lists according to signal sampling rates or trigger types, and calculating memory requirements, and outputting analysis results containing DAQ list quantities, total measurement channel numbers, and memory requirements.

4. The XCP configuration system based on AUTOSAR architecture of claim 3, wherein, The intelligent configuration engine module further comprises a configuration generation submodule for receiving analysis results output by the requirement analysis and resource pre-planning submodule, generating an AUTOSAR parameter configuration file containing Xcp module parameters, XcpOnCan / XcpOnEth module parameters, Com module parameters, Os module parameters, Rte module parameters, and MemMap module parameters, and transmitting the AUTOSAR parameter configuration file to the dynamic DAQ resource pool module.

5. The XCP configuration system based on AUTOSAR architecture of claim 3, wherein, The dynamic DAQ resource pool module comprises an initialization submodule for initializing at least one virtualized resource pool containing Slot units of a fixed size according to a shared memory area reserved in the AUTOSAR parameter configuration file and memory requirements and DAQ list quantities in the analysis results.

6. The XCP configuration system based on AUTOSAR architecture of claim 5, wherein, The initialization submodule is further configured to partition the virtualized resource pool according to signal priorities, signal types in the AUTOSAR parameter configuration file, and total measurement channel numbers in the analysis results, and to construct an idle Slot linked list and initialize all Slot units to an idle state and then add the Slot units to the linked list according to a preset strategy.

7. The XCP configuration system based on AUTOSAR architecture of claim 5, wherein, The dynamic DAQ resource pool module further comprises a DAQ configuration submodule, configured to receive a DAQ list configuration request sent by the host computer, the request comprising a signal ID, a trigger event, and a transmission mode, determine the resource pool type corresponding to the signal ID in combination with the analysis result of the intelligent configuration engine module, select an idle Slot unit meeting the requirements of memory size and access authority, establish a direct memory mapping between the Slot unit and an application layer variable to be collected in the ECU, and bind the Slot unit with the trigger event in the request.

8. The XCP configuration system based on AUTOSAR architecture of claim 7, wherein, The DAQ configuration submodule is further configured to store the DAQ list identification, signal ID, trigger event, Slot ID, and resource pool information in an internal mapping table, mark the Slot unit as occupied and remove it from the idle Slot linked list, and feed back the Slot ID to the host computer.

9. The XCP configuration system based on AUTOSAR architecture of claim 8, wherein, The DAQ configuration submodule further comprises a data transmission submodule, configured to, after the DAQ configuration submodule completes the allocation of the Slot unit and the binding of the trigger event, detect a hardware event or a software event bound with the Slot unit, match the corresponding Slot unit according to the internal mapping table, fill the real-time value of the application layer variable to be collected in the ECU into the Slot unit by using the direct memory mapping, mark the data of the Slot unit as ready and set a sending queue or a status bit.

10. A method for XCP configuration based on AUTOSAR architecture of the system as claimed in claim 1, wherein, The method comprises: automatically parsing an A2L file and AUTOSAR description of a target ECU, obtaining XCP configuration basic data, analyzing the access characteristics and resource requirements of calibration signals or parameters in the XCP configuration basic data and predicting dynamic expansion requirements, and generating an AUTOSAR parameter configuration file; constructing a virtualized resource pool according to the AUTOSAR parameter configuration file, receiving a DAQ list configuration request sent by the host computer based on the virtualized resource pool, and performing dynamic resource allocation based on the XCP configuration basic data, responding to a preset trigger event, and completing data collection and transmission preparation by using a pre-established direct memory mapping. 11.A non-transitory computer-readable storage medium having stored thereon a computer program. The computer program is executed by a processor to implement the steps of the XCP configuration method based on the AUTOSAR architecture according to claim 10.

12. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instructions are executed by a processor to implement the steps of the XCP configuration method based on the AUTOSAR architecture according to claim 10.

Images