Lin communication configuration generation method and related device

Abstract

This application discloses a LIN communication configuration generation method and related equipment, relating to the field of vehicle technology. The method includes: obtaining a first configuration file and a second configuration file; generating a Lin module configuration based on the first and second configuration files, the Lin module configuration including hardware parameters for each LIN channel and scheduling table information corresponding to each LIN channel; generating a Com module configuration and a PduR module configuration based on the second configuration file, the Com module configuration including signal mapping of IPdu corresponding to LIN messages and signals, and the PduR module configuration including routing information for LIN messages; and generating a LinSM module configuration and a BswM module configuration based on the Lin module configuration and the second configuration file. This application achieves unified automatic generation of configurations for multiple modules such as Lin, Com, PduR, LinSM, and BswM by automatically parsing configuration files, thereby improving configuration efficiency and accuracy and shortening the LIN communication protocol stack development cycle.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more specifically, to a LIN communication configuration generation method and related equipment. Background Technology

[0002] With the continuous development of automotive electronic and electrical architecture, the communication requirements between on-board controllers are increasing. Low-cost Local Interconnect Networks (LIN) are widely used in vehicle electronic systems due to their simple structure, low cost, and ease of implementation, such as door control, seat adjustment, air conditioning systems, and lighting control. To achieve stable and reliable data interaction between different controllers, LIN communication typically relies on the configuration and management of a basic software communication stack, including multiple modules such as the LIN driver module, LINIf interface module, communication module (COM), message routing module (PduR), network state management module (LinSM), and mode management module (BswM). These modules cooperate to schedule, transmit, map signals, and manage communication states of LIN messages, thereby ensuring the normal operation of the entire vehicle network communication system.

[0003] However, in related technologies, LIN communication configuration typically requires developers to manually configure multiple basic software modules separately. This includes configuring LIN channel hardware parameters and scheduling table information, establishing mapping relationships between messages and signals, configuring communication message routing paths, and setting network state management and mode control parameters. This decentralized manual configuration method is not only labor-intensive, but also involves a large amount of interrelated parameter information between different modules. Omissions or inconsistencies in parameters during configuration can easily lead to communication anomalies or system instability. When communication message or signal definitions change, developers often need to repeatedly modify related configurations in multiple modules, increasing development and maintenance costs and reducing configuration efficiency and accuracy. In other words, related technologies suffer from the technical problems of complex LIN communication configuration processes, high manual workload, and a high risk of configuration inconsistencies. Summary of the Invention

[0004] In the summary section of this application, the relevant technical solutions are described in general terms, and a series of simplified concepts are introduced. These concepts will be further elaborated in the detailed embodiments section. This summary section should not be construed as limiting the key or essential technical features of the claimed solutions, nor is it intended to limit the scope of protection of the claimed solutions.

[0005] The LIN communication configuration generation method and related equipment provided in this application can automatically generate configurations for multiple modules such as Lin, Com, PduR, LinSM, and BswM by automatically parsing configuration files, thereby improving configuration efficiency and accuracy and shortening the development cycle of the LIN communication protocol stack.

[0006] In a first aspect, this application provides a LIN communication configuration generation method, comprising: obtaining a first configuration file, wherein the first configuration file includes identification information of LIN channels supported by the controller and control module information corresponding to each LIN channel; obtaining a second configuration file, wherein the second configuration file includes LIN message information and definition information of signals contained in the LIN message; generating a configuration of a LIN module based on the first configuration file and the second configuration file, wherein the configuration of the LIN module includes hardware parameters of each LIN channel and scheduling table information corresponding to each LIN channel; generating a configuration of a COM module and a PduR module based on the second configuration file, wherein the configuration of the COM module includes signal mapping of IPdu corresponding to the LIN message and the signals, and the configuration of the PduR module includes routing information of the LIN message; and generating a configuration of a LinSM module and a BswM module based on the configuration of the LIN module and the second configuration file, wherein the configuration of the LinSM module includes state management parameters of each LIN channel, and the configuration of the BswM module includes interface configuration for upper-layer software components to control LIN communication.

[0007] In some implementations, the first configuration file is a CSV file, which contains a first preset line and a second preset line. The first preset line is used to identify the LIN channels supported by the controller, and the second preset line is used to identify the control module that can control each LIN channel.

[0008] In some implementations, generating the Lin module configuration based on the first configuration file and the second configuration file includes: creating a LinChannel configuration for each LIN channel based on the first configuration file, wherein the LinChannel configuration includes a channel identifier, baud rate, hardware channel identifier, disconnection length, disconnection delay length, and wake-up support parameters; and creating a LinIf global configuration based on the first configuration file and the second configuration file, wherein the LinIf global configuration includes a LinIf channel configuration corresponding to each LIN channel, the LinIf channel configuration is associated with scheduling table information, wherein the scheduling table information includes delay time, transmission sequence number, and operating mode, and the LinIf channel configuration is associated with LinIf message information, wherein the LinIf message information includes message direction, sending user identifier, protocol identifier, message length, message type, and checksum type.

[0009] In some implementations, the process of generating the configuration of the Com module based on the second configuration file includes: creating a ComIPdu group based on the second configuration file, the ComIPdu group including a receive-direction IPdu group and a send-direction IPdu group; creating a ComIPdu based on the LIN message information in the second configuration file, the ComIPdu including IPdu callback, IPdu direction, IPdu type, and signal information contained in the LIN message; and creating a signal configuration based on the signal attributes in the second configuration file, the signal configuration including bit position, bit size, notification function, byte order, initial value, and signal type.

[0010] In some implementations, the process of generating the configuration of the PduR module based on the second configuration file includes: creating a PduR routing path based on the configuration of the Com module and the LIN message information, wherein the PduR routing path is used to route the LIN message to the corresponding upper-layer module or lower-layer module.

[0011] In some implementations, the process of generating the LinSM module configuration based on the Lin module configuration and the second configuration file includes: creating a LinSM channel configuration corresponding to the LIN channel based on the hardware parameters of each LIN channel in the Lin module configuration, wherein the LinSM channel configuration includes scheduling table queue enable parameters, acknowledgment timeout parameters, sleep support parameters, and maximum queue size; configuring LinSM general parameters based on the LIN message information in the second configuration file and the scheduling table information in the Lin module configuration, wherein the LinSM general parameters include main processing cycle and reinitialization enable parameters; and associating the LinSM channel configuration with the LinIf module and the ComM channel.

[0012] In some implementations, the process of generating the configuration of the BswM module based on the configuration of the Lin module and the second configuration file includes: determining the control requirements of the upper-layer software components for LIN communication based on the scheduling table information in the configuration of the Lin module and the LIN message information in the second configuration file; and configuring the control interface of the BswM module based on the control requirements, wherein the control interface is used to provide the upper-layer software components with control functions for LIN communication.

[0013] Secondly, this application also provides a LIN communication configuration generation apparatus, comprising: a first acquisition unit, configured to acquire a first configuration file, wherein the first configuration file includes identification information of LIN channels supported by the controller and control module information corresponding to each LIN channel; a second acquisition unit, configured to acquire a second configuration file, wherein the second configuration file includes LIN message information and definition information of signals contained in the LIN message; and a first configuration unit, configured to generate a configuration of a LIN module based on the first configuration file and the second configuration file, wherein the configuration of the LIN module includes hardware parameters of each LIN channel and a control module configuration for each LIN channel. The configuration includes: a first configuration unit and a second configuration unit, configured to generate the configuration of the Com module and the PduR module based on the second configuration file, wherein the configuration of the Com module includes the signal mapping of the IPdu corresponding to the LIN message and the signal of the signal, and the configuration of the PduR module includes the routing information of the LIN message; and a third configuration unit, configured to generate the configuration of the LinSM module and the BswM module based on the configuration of the Lin module and the second configuration file, wherein the configuration of the LinSM module includes the status management parameters of each LIN channel, and the configuration of the BswM module includes the interface configuration for upper-layer software components to control LIN communication.

[0014] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to implement the steps of the LIN communication configuration generation method described in the first aspect when executing a computer program stored in the memory.

[0015] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, which, when executed by a processor, implement the steps of the LIN communication configuration generation method described in the first aspect.

[0016] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implement the steps of the LIN communication configuration generation method provided in the embodiments of this application.

[0017] In summary, this application automates the generation of configurations for multiple modules, including Lin, Com, PduR, LinSM, and BswM, by automatically parsing the first and second configuration files. This replaces the traditional manual input of parameters in different tools or interfaces, significantly shortening the development cycle of the LIN communication protocol stack. By unifying hardware identifiers, scheduling tables, signal definitions, and routing information from the two configuration files, it ensures high synchronization of parameters between modules from the underlying driver to the upper-layer protocol stack. This effectively avoids logical errors or signal bit definition deviations that may occur when manually configuring modules repeatedly, improving the accuracy of system configuration. Furthermore, it not only covers… Beyond basic message transmission and reception (Lin / Com / PduR), this method extends to state management (LinSM) and mode control (BswM) layers. This end-to-end configuration generation ensures seamless integration of the communication link from hardware initialization and signal mapping to communication state switching logic, enhancing system operational coordination. By automatically configuring the BswM module, it directly provides standardized control interfaces for upper-layer software components, reducing the complexity of application-layer calls. When communication requirements change, developers only need to update the original configuration file to achieve synchronous iteration of multiple modules, significantly reducing the later maintenance and upgrade costs of the system. In summary, the LIN communication configuration generation method provided in this application achieves unified automatic generation of configurations for multiple modules such as Lin, Com, PduR, LinSM, and BswM through automatic parsing of configuration files, thereby improving configuration efficiency and accuracy and shortening the LIN communication protocol stack development cycle. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a LIN communication configuration generation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the composition structure of a LIN communication configuration generation device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0020] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0021] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0022] Figure 1 This is a flowchart illustrating a LIN communication configuration generation method provided in an embodiment of this application. For example, see [link to example]. Figure 1 The LIN communication configuration generation method provided in this application embodiment may include the following steps 101 to 105: Step 101: Obtain the first configuration file.

[0023] The first configuration file includes the identification information of the LIN channels supported by the controller and the control module information corresponding to each LIN channel.

[0024] In some examples, the first configuration file is a pre-compiled dedicated configuration file used to centrally store the identification information of the local interconnection network channels supported by the controller and the control module information corresponding to each local interconnection network channel. This file can be pre-written and generated according to the vehicle's communication network design requirements, the controller's hardware design specifications, and the module control logic of the vehicle's electronic architecture. For example, the first configuration file may store the identifiers of multiple local interconnection network channels supported by the intelligent power distribution control unit, as well as relevant information about the modules that can control each channel. The controller is an on-board electronic control unit in the vehicle's electronic architecture that implements specific vehicle functions and is the control carrier for vehicle local interconnection network communication. The on-board electronic control unit targeted by this local interconnection network communication configuration can be determined according to the overall functional design requirements of the vehicle. For example, the controller may include various on-board electronic control units such as the intelligent power distribution control unit, the body control unit, and the air conditioning control unit.

[0025] The LIN channel is a dedicated communication link between the controller and other onboard electronic devices in the vehicle, enabling data interaction based on the local interconnect network communication protocol. It serves as the physical carrier for local interconnect network communication data transmission. For example, the local interconnect network channel can be LIN1, LIN2, LIN3, or LIN4 channels supported by the controller hardware design, each corresponding to a communication link with different onboard devices in the vehicle. The identification information of the LIN channel is a unique feature used to identify each local interconnect network channel supported by the controller, and is a key basis for distinguishing different local interconnect network channels. For example, the local interconnect network channel identification information can be named LIN1, LIN2, etc., using an alphanumeric combination, or it can be a unique number such as 001, 002, etc., encoded purely numerically. The control module information corresponding to the LIN channel is related to the modules in the vehicle's electronic architecture that can perform control operations on the communication status and communication process of each local interconnect network channel. For example, the control module information can be related to the communication management user's local interconnect network module performing control operations on all LIN1, LIN2, LIN3, and LIN4 channels of the controller.

[0026] By implementing step 101, a first configuration file containing the LIN channel identifier information supported by the controller and the corresponding control module information is obtained. This allows for a unified description and centralized management of the LIN channel resources and their control relationships involved in the system, providing a basic data source for the subsequent configuration generation of each module. This avoids the repetitive work caused by manually configuring channel information in different modules and improves the standardization and consistency of LIN communication configuration.

[0027] Step 102: Obtain the second configuration file.

[0028] The second configuration file includes LIN message information and the definition information of the signals contained in the LIN message.

[0029] In some examples, the second configuration file is a dedicated configuration file used to centrally store local interconnection network message information and the definition information of the signals contained in the local interconnection network messages. It serves as one of the data bases for the subsequent automated configuration of various modules. It can be exported or pre-compiled using professional vehicle network design tools based on the local interconnection network communication data interaction requirements between various vehicle electronic devices and the design specifications and communication protocol requirements of the vehicle network. For example, the second configuration file can store all message information of local interconnection network communication between the controller and the vehicle heating equipment, vehicle ventilation equipment, and vehicle multimedia equipment, as well as the definition information of various data signals in each message.

[0030] LIN message information refers to the various characteristic information of messages transmitted when various on-board electronic devices in a vehicle conduct data interaction through the local interconnection network channel. It is the key content characterizing the attributes and transmission characteristics of the local interconnection network messages themselves. This information can be sorted and determined according to the functional interaction requirements of the on-board devices and the standard specifications of the local interconnection network communication protocol, and at the same time, the various related characteristic information of the messages can be sorted out. For example, the local interconnection network message information may include the transmission-related characteristics of the messages and the functional attribute characteristics of the messages, such as the various characteristic information corresponding to the messages of the controller sending operating mode control commands to the on-board air conditioning equipment.

[0031] The signal definition information contained in LIN messages is information that defines the attributes and describes the characteristics of various data signals carried in local interconnection network messages. It is the basis for realizing signal recognition, parsing, and data interaction. This information can determine the various data signals that need to be carried in the message according to the transmission purpose and functional objectives of each local interconnection network message, and define the various attributes of each signal according to the design specifications of the vehicle network, and organize them into corresponding definition information. For example, the signal definition information may include various information used to characterize the attributes of the signal itself, such as the attribute definition information corresponding to the vehicle air conditioning fan speed adjustment signal and temperature setting signal.

[0032] By implementing step 102, a second configuration file containing LIN message information and signal definition information in the message is obtained. This configuration file can centrally describe the message structure and signal parameters involved in LIN communication, giving the communication data structure a unified data source. This provides a basis for the subsequent automatic generation of communication-related module configurations, reduces the workload of manually configuring message and signal parameters one by one, and lowers the possibility of configuration errors.

[0033] Step 103: Generate the configuration of the Lin module based on the first configuration file and the second configuration file.

[0034] The configuration of the Lin module includes the hardware parameters of each LIN channel and the scheduling table information corresponding to each LIN channel.

[0035] In some examples, the LIN module is a fundamental software module in the automotive open system architecture. It is the underlying module that realizes the vehicle's local interconnect network communication function, and it is responsible for driving the LIN communication hardware and managing the scheduling of LIN channel message transmission. This module can follow the basic software design specifications of the automotive open system architecture to determine the functional framework and components of the LIN module, so as to adapt it to the LIN communication hardware and software interaction requirements of the controller in the vehicle's electronic architecture. For example, the LIN module is a module in the basic software of the vehicle's intelligent power distribution control unit that is specifically responsible for driving the LIN1, LIN2 and other channel hardware and scheduling messages. It is the underlying support module for the controller to realize LIN communication.

[0036] The configuration of the LIN module is a set of personalized settings for various operating parameters and management information within the LIN module, made to adapt the LIN module to the LIN communication requirements of the target controller, based on actual channel and message information. This is a prerequisite for the normal operation of the LIN module. The configuration can be based on the LIN channel information in the first configuration file and the LIN message information in the second configuration file, following the configuration specifications of the automotive open system architecture for LIN modules, and combined with the actual LIN communication requirements of the vehicle, to generate a set of LIN module parameters and information settings adapted to the target controller. For example, the LIN module configuration is a complete configuration set including the hardware parameters of the LIN1 and LIN2 channels of the intelligent power distribution control unit, as well as the message scheduling table information corresponding to each of the two channels, which can support the LIN module of the controller to drive each LIN channel to complete data interaction.

[0037] The hardware parameters of a LIN channel are various parameters that characterize the communication features of the LIN channel hardware and determine the communication rules of the LIN channel hardware layer. They are the key basis for the LIN module to drive the LIN channel hardware to achieve normal communication. These parameters can be determined based on the LIN channel identification information supported by the controller parsed from the first configuration file, matching the hardware design specifications of the target controller with the standard requirements of the local interconnection network communication protocol, to determine the hardware-level operating parameters corresponding to each LIN channel. For example, the hardware parameters of a LIN channel include transmission rate parameters that can support the operation of the LIN channel hardware, hardware-specific identification parameters, wake-up function support parameters, etc., which are the foundation for ensuring that the LIN channel hardware layer completes data transmission.

[0038] The scheduling table information corresponding to the LIN channel is a message scheduling information formulated to standardize the transmission timing and execution logic of messages on the LIN channel, combined with the communication requirements of the LIN channel. It serves as the basis for the LIN module to manage the transmission of LIN channel messages. This information can be based on the LIN channel information in the first configuration file, combined with the LIN message information in the second configuration file, and according to the LIN communication interaction requirements between various on-board devices in the vehicle, to formulate corresponding message scheduling information for each LIN channel. For example, the scheduling table information corresponding to the LIN channel contains scheduling information related to the sending and execution order, transmission time interval, and channel operation mode of various messages on the LIN1 channel, which can ensure the orderly and efficient transmission of LIN messages on this channel.

[0039] For example, firstly, based on the first configuration file, the identification information of all LIN channels supported by the controller can be parsed. Combining the controller hardware design specifications and the LIN communication protocol standard, the corresponding hardware parameters for each LIN channel are determined. Then, based on the LIN message information compiled in the second configuration file, and according to the communication requirements of the vehicle equipment corresponding to each LIN channel, the appropriate message scheduling table information is formulated for each LIN channel. Finally, the hardware parameters and corresponding scheduling table information of all LIN channels are integrated and standardized according to the configuration specifications of the LIN module in the automotive open system architecture, and finally, a complete configuration of the LIN module adapted to the target controller is generated.

[0040] By implementing step 103, the hardware parameters and scheduling table information of the LIN channel can be automatically generated based on unified configuration data. This avoids developers manually configuring channel parameters and scheduling information, improves the efficiency of LIN driver layer configuration, and ensures consistency between LIN channel hardware configuration and communication scheduling information.

[0041] Step 104: Based on the second configuration file, generate the configuration for the Com module and the PduR module.

[0042] The configuration of the Com module includes the signal mapping of IPdu and signals corresponding to LIN messages, while the configuration of the PduR module includes the routing information of LIN messages.

[0043] In some examples, the Communication (Com) module, or COM module for short, is a fundamental software module in the automotive open system architecture. It is responsible for processing vehicle-mounted communication messages and signals, playing a crucial role in encapsulating signals into corresponding data units and parsing signals from these data units. It serves as a vital bridge connecting the underlying communication hardware and upper-level software components. For instance, the COM module, within the basic software of the vehicle's intelligent power distribution control unit, is specifically responsible for processing local interconnection network message encapsulation and signal parsing, enabling the association processing of various local interconnection network signals with their corresponding data units. The configuration of the COM module is a set of personalized settings for various operating parameters and data relationships within the COM module, combining local interconnection network message information and signal definition information, to adapt it to the message and signal processing requirements of the vehicle's local interconnection network communication. This is a prerequisite for the COM module to achieve normal message and signal processing. For example, the configuration of the COM module includes a complete set of configurations containing the interactive data unit information corresponding to all local interconnection network messages in the intelligent power distribution control unit's LIN1 and LIN2 channels, as well as the mapping relationship between signals in each message and their corresponding interactive data units.

[0044] Interaction Data Unit (IPdu) is the basic unit for data transmission in vehicle communication. It is the carrier for message processing and transmission in the open system architecture of the vehicle. The IPdu corresponding to the local interconnection network message is a dedicated IPdu matched for each local interconnection network message. Signal mapping is the establishment of a dedicated association between various signals in the local interconnection network message and the corresponding IPdu, realizing the encapsulation and parsing of signals in the IPdu. For example, this content is the dedicated IPdu matched for the local interconnection network message of vehicle air conditioning control, and the one-to-one signal mapping relationship established between the temperature setting signal, fan speed adjustment signal in the message and the IPdu.

[0045] The Protocol Data Unit Router (PduR) module is a fundamental software module in the automotive open system architecture. It is responsible for routing and forwarding various data units in vehicle-to-everything (V2X) communication. It plays a crucial role in forwarding data units to their corresponding underlying communication modules or upper-layer software components based on preset routing information, ensuring accurate transmission of V2X communication data. For example, in the basic software of the vehicle's intelligent power distribution control unit, the PduR module is specifically responsible for routing the PduR module corresponding to the local interconnection network message to the LIN module or upper-layer software components. The configuration of the PduR module is a set of personalized settings for various routing parameters and forwarding rules within the PduR module, tailored to the transmission requirements of the local interconnection network messages, to enable accurate routing and forwarding of these messages. This is a prerequisite for the PduR module to function properly. For example, the PduR module configuration includes a complete set of configurations for the routing and forwarding paths of messages from each local interconnection network channel of the intelligent power distribution control unit, as well as the target modules for forwarding.

[0046] The routing information of LIN messages represents the transmission path and forwarding target of the interactive data unit corresponding to the local interconnection network message in the vehicle's electronic architecture. It is the basis for the PduR module to achieve accurate routing and forwarding of local interconnection network messages. This information can be based on the local interconnection network message information in the second configuration file, combined with the module layout of the overall vehicle electronic architecture and the communication interaction logic between modules, to determine the transmission path and forwarding target of the interactive data unit corresponding to each local interconnection network message, and organize them into the corresponding routing information. For example, the routing information of local interconnection network messages is the transmission path and forwarding target information for routing the status feedback local interconnection network message of the in-vehicle multimedia device to the upper-layer multimedia control software component, and the local interconnection network message of the upper-layer air conditioning control command to the lower-layer LIN module.

[0047] For example, firstly, the local interconnection network message information and signal definition information in the second configuration file can be fully parsed to match the corresponding interactive data unit for each local interconnection network message, and establish the signal mapping relationship between various signals in the message and the corresponding interactive data unit, and integrate them into the configuration of the COM module according to the specification; then, based on the parsed local interconnection network message information in the second configuration file, combined with the module layout and communication logic of the vehicle electronic architecture, the transmission path and forwarding target corresponding to each local interconnection network message are determined, and the complete routing information of the local interconnection network message is organized; finally, following the configuration specification of the PduR module in the automotive open system architecture, the routing information is standardized and integrated to generate the configuration of the PduR module adapted to the controller communication requirements.

[0048] By implementing step 104, the IPdu and signal mapping relationship corresponding to the LIN message and the message routing information can be automatically established, enabling unified configuration of communication data across different modules. This reduces the complexity caused by manually configuring message and signal mapping relationships repeatedly across multiple modules and improves the accuracy and consistency of communication configuration.

[0049] Step 105: Based on the Lin module configuration and the second configuration file, generate the LinSM module configuration and the BswM module configuration.

[0050] The LinSM module configuration includes the status management parameters for each LIN channel, while the BswM module configuration includes the interface configuration for upper-layer software components to control LIN communication.

[0051] In some examples, the Local Interconnect NetworkState Manager (LinSM) module, or simply LinSM module, is a fundamental software module in the automotive open system architecture. It is responsible for managing the communication status of the vehicle's local interconnect network channels, playing a crucial role in monitoring and managing the operation, sleep, and wake-up states of each channel, ensuring the orderly and stable switching of these channels. For instance, the LinSM module is a core component of the vehicle's intelligent power distribution control unit, specifically responsible for managing the communication status switching of channels such as LIN1 and LIN2. It can adjust the status of each channel according to actual communication needs. The LinSM module configuration is a set of personalized settings for its internal operating parameters and management rules, combining the LIN module configuration and relevant information from the second configuration file, to adapt the LinSM module to the status management requirements of each local interconnect network channel of the controller. For example, the LinSM module configuration includes a complete set of configuration parameters for the status management of each channel from LIN1 to LIN4 of the intelligent power distribution control unit, supporting precise control of the communication status of each channel.

[0052] The LIN channel status management parameters are various parameters used by the LinSM module to manage the communication status of local interconnection network channels. They are key to defining channel status switching rules and control logic, and directly determine the specific method by which the LinSM module manages the status of each channel. These parameters can be determined based on the relevant information of each local interconnection network channel in the LIN module configuration, combined with the local interconnection network message information in the second configuration file, and according to the status management requirements of the vehicle's local interconnection network communication. For example, the status management parameters of a local interconnection network channel include channel sleep function support parameters, status switching confirmation timeout parameters, and operating mode management parameters, which are the basis for the LinSM module to regulate the channel communication status.

[0053] The Basic Software Manager (BswM) module, or BswM module for short, is a fundamental software module in the automotive open system architecture. It serves as a bridge between underlying local interconnect network communication-related basic software modules and upper-level software components, playing a crucial role in providing upper-level software components with an interactive channel to control the underlying local interconnect network communication, enabling the transmission of control commands and status information between the upper and lower layers. For example, in the basic software of the vehicle's intelligent power distribution control unit, the BswM module connects lower-level communication modules such as the LinSM module with upper-level body control software components, enabling upper-level components to issue commands to the underlying local interconnect network communication. The configuration of the BswM module is a set of personalized settings for various interface parameters and interaction rules within the BswM module, combining the configuration of the LIN module and relevant information in the second configuration file, to adapt the BswM module to the needs of upper-level software components controlling local interconnect network communication. This is a prerequisite for the BswM module to realize upper-lower-layer interaction functions. For example, the BswM module configuration includes a complete set of configurations for the local interconnect network communication control interfaces configured for upper-level air conditioning control software components, supporting effective control of the underlying local interconnect network communication by upper-level components.

[0054] The interface configuration used by upper-layer software components to control LIN communication is the interface-related settings built for upper-layer software components to issue control commands to the underlying basic software modules related to local interconnection network communication. It is the direct basis for upper-layer software components to implement local interconnection network communication control, determining the control method and interaction logic of upper-layer components over lower-layer communication. This configuration can be based on the relevant information of each local interconnection network channel in the LIN module configuration, combined with the local interconnection network message communication requirements in the second configuration file, to sort out the actual control requirements of the upper-layer software components for local interconnection network communication, and then configure the corresponding interface-related information accordingly. For example, this interface configuration is used to configure the relevant settings of the local interconnection network channel wake-up control interface and communication mode switching control interface for the upper-layer multimedia control software component, allowing the upper-layer component to directly issue relevant control commands to the lower layer.

[0055] For example, firstly, the configuration and second configuration file of the LIN module can be fully analyzed to extract the hardware, scheduling information, and communication requirements of local interconnection network messages for each local interconnection network channel. Adaptive state management parameters are determined for each channel and integrated into the LinSM module configuration according to the automotive open system architecture specification. Then, based on the information obtained from the above analysis, various control requirements of upper-layer software components for local interconnection network communication are identified, and corresponding control interfaces are designed and configured accordingly. Finally, following the automotive open system architecture's configuration specifications for the BswM module, the designed interface configurations are standardized, integrated, and parameter-set, ultimately generating a complete BswM module configuration adapted to the controller's communication control requirements.

[0056] By implementing step 105, the LinSM module and BswM module configurations are generated based on the Lin module configuration and the second configuration file. This enables the automatic configuration of the LIN channel status management parameters and the interface for controlling LIN communication by the upper-layer software components. It also enables the complete connection of LIN communication from the underlying driver configuration to the upper-layer control interface, thereby improving the overall coordination of LIN communication management and control in the system.

[0057] In summary, this application's embodiments, by automatically parsing the first and second configuration files, achieve automated generation of configurations for multiple modules such as Lin, Com, PduR, LinSM, and BswM. This replaces the traditional manual input of parameters in different tools or interfaces, significantly shortening the development cycle of the LIN communication protocol stack. By unifying hardware identifiers, scheduling tables, signal definitions, and routing information from the two configuration files, it ensures a high degree of parameter synchronization between modules from the underlying driver to the upper-layer protocol stack, effectively avoiding logical errors or signal bit definition deviations that may occur when manually configuring modules repeatedly, thus improving the accuracy of system configuration. Furthermore... This approach covers basic message sending and receiving (Lin / Com / PduR) and extends to state management (LinSM) and mode control (BswM) levels. This full-path configuration generation ensures seamless connection of the communication link from hardware initialization and signal mapping to communication state switching logic, enhancing system operational coordination. By automatically configuring the BswM module, it directly provides standardized control interfaces for upper-layer software components, reducing the complexity of application-layer calls. When communication requirements change, developers only need to update the original configuration file to achieve synchronous iteration of multiple modules, significantly reducing the later maintenance and upgrade costs of the system. In summary, the LIN communication configuration generation method provided in this application achieves unified automatic generation of configurations for multiple modules such as Lin, Com, PduR, LinSM, and BswM by automatically parsing configuration files, thereby improving configuration efficiency and accuracy and shortening the LIN communication protocol stack development cycle.

[0058] In some embodiments, the first configuration file is a CSV file, which contains a first preset line and a second preset line. The first preset line is used to identify the LIN channels supported by the controller, and the second preset line is used to identify the control module that can control each LIN channel.

[0059] In some examples, comma-separated values ​​(CSV) files, or simply CSV files, are file formats that store tabular data in plain text. They separate data in different columns using specific delimiters and are characterized by ease of writing, convenient parsing, and strong compatibility. In this application, they serve as the carrier of the first configuration file, specifically used to store the identification information of the local interconnection network channels supported by the controller and the control module information corresponding to each channel. This file can be written and saved according to the format specifications of a CSV file using a general table editing tool or text editing tool, based on the vehicle's local interconnection network communication design requirements and the controller's LIN channel configuration rules. The first preset row is a dedicated row of data pre-defined in the CSV file. It is the row in the CSV file used to centrally identify all the local interconnection network channels supported by the controller and serves as the direct basis for obtaining the number and identification information of the controller's LIN channels during subsequent automated parsing. For example, the content of the first preset row is User;LIN1;LIN2;LIN3;LIN4, using semicolons as data delimiters, identifying the four local interconnection network channels supported by the controller by column. The User field at the beginning of the row is the identifier field of that row, used to distinguish it from other rows of data. The second preset row is a dedicated row of data pre-defined in the CSV file, corresponding one-to-one with the column order of the first preset row. It is a row in the CSV file used to centrally identify the control modules that can perform control operations on each local interconnection network channel. It is the direct basis for obtaining the control module information corresponding to each LIN channel during the subsequent automated parsing process. For example, the content of the second preset row is ComMUser_LIN;x;x;x;x, with semicolons as data separators. ComMUser_LIN at the beginning of the row is the control module identifier, and the identifier x in the subsequent columns indicates that the control module can perform control operations on the LIN1, LIN2, LIN3, and LIN4 channels in the corresponding columns of the first preset row.

[0060] Through the implementation of the above embodiments, the first configuration file is set as a CSV file, and the first preset row identifier identifies the LIN channels supported by the controller, and the second preset row identifier can control the control modules of each LIN channel. This allows the LIN channel information and control module information to be uniformly described in a structured manner, which is convenient for developers to quickly edit and maintain the configuration content. At the same time, the CSV file has the characteristics of simple format, strong readability and easy script parsing, which is conducive to the automatic program to quickly identify and process the LIN channel configuration relationship, further reducing the configuration complexity and improving the configuration generation efficiency.

[0061] In some embodiments, step 103 includes: creating a LinChannel configuration for each LIN channel based on a first configuration file. The LinChannel configuration includes a channel identifier (ChannelId), baud rate (BaudRate), hardware channel identifier (HardwareChannelId), break length (BreakLength), break delay length (BreakDelLength), and wakeup support parameters (WakeupSupport); and creating a LinIf global configuration based on the first configuration file and a second configuration file. The LinIf global configuration includes a LinIf channel configuration corresponding to each LIN channel. The LinIf channel configuration is associated with scheduling table information, which includes delay time (Delay), transmission sequence number (EntryIndex), and running mode (RunMode). The LinIf channel configuration is associated with LinIf message information, which includes message direction (PduDirection), sending user identifier (UserTxUL), protocol identifier (Pid), message length (Length), message type (FrameType), and checksum type (ChecksumType).

[0062] In some examples, the Local Interconnect Network Channel (LinChannel) configuration, or simply LinChannel configuration, is a set of dedicated hardware-level configurations customized for each LIN channel to adapt to its hardware communication characteristics. It serves as the basis for the LIN module to drive the LIN channel hardware to achieve normal communication and corresponds one-to-one with the LIN channels supported by the controller. This configuration can parse all the LIN channel identification information supported by the controller in the first configuration file, and, in conjunction with the controller's hardware design specifications and the standard requirements of the local interconnect network communication protocol, create a corresponding LinChannel configuration for each LIN channel and assign values ​​to various parameters. The channel identifier is a unique feature used to identify a single LIN channel. It is a key identifier that distinguishes different LinChannel configurations and corresponds one-to-one with the controller's LIN channel identifier. The baud rate is a parameter characterizing the data transmission rate of the LIN channel, determining the data transmission efficiency at the hardware level. The hardware channel identifier is a unique identifier for the LIN channel at the controller hardware level, used to associate the LinChannel configuration with the actual hardware communication link of the controller. The disconnect length is the length parameter of the LIN message disconnect bit specified in the local interconnect network communication protocol, a fundamental hardware parameter ensuring that the LIN message is correctly identified by the receiving end. The disconnect delay length is the length parameter of the delay bits after the LIN message disconnect bit, used to coordinate the timing matching of message transmission. The wake-up support parameter is a parameter used to identify whether the LIN channel has communication wake-up functionality, determining whether the channel can achieve hardware wake-up through message transmission.

[0063] The Local Interconnect Network Interface (LinIf) global configuration, or simply LinIf global configuration, is the top-level configuration set of the LinIf module. It integrates the LinIf channel configurations corresponding one-to-one with all LIN channels of the controller and is the basic configuration for the LinIf module to implement global message scheduling and management. This configuration can be created by integrating all LinIf channel configurations, based on the LIN channel information in the first configuration file and the LIN message information and signal definition information in the second configuration file, following the configuration specifications of the automotive open system architecture for the LinIf module. For example, the LinIf global configuration is a complete configuration set containing the LinIf channel configurations corresponding to the controller's LIN1 to LIN4 channels, which can support the LinIf module to perform global scheduling of messages from all LIN channels.

[0064] The LinIf channel configuration is a dedicated LinIf module configuration customized for each LIN channel, corresponding one-to-one with the LinChannel configuration. It serves as the basis for the LinIf module to perform packet scheduling and management for a single LIN channel. This configuration can parse the LIN channel identification information in the first configuration file, create an adapted LinIf channel configuration for each LIN channel, and then combine it with the relevant information in the second configuration file to associate it with scheduling table information and LinIf packet information. For example, the LinIf channel configuration is a dedicated LinIf configuration created for the LIN1 channel, and it is one of the components in the global LinIf configuration.

[0065] The LinIf channel configuration is associated with scheduling table information. This establishes a unique association between the configuration of a single LinIf channel and the message scheduling table information of the corresponding LIN channel. This allows the LinIf module to perform timing and logical control over message transmission on that LIN channel based on the scheduling table information. This is the key configuration logic for the LinIf module to achieve ordered message scheduling. The scheduling table information is a set of information defined for a single LIN channel, used to control the timing and execution logic of message transmission on that channel. It is the direct basis for the LinIf module to schedule messages on that channel. This information can be based on the LIN channel information in the first configuration file, combined with the message information of the corresponding LIN channel in the second configuration file, and formulated according to the LIN communication interaction requirements between vehicle onboard devices. The delay time is a parameter in the scheduling table information that represents the interval between adjacent message transmissions on the LIN channel. It is used to coordinate the timing of message transmission and avoid message transmission conflicts. The sequence number is a number parameter in the scheduling table information that represents the order in which messages are sent on the LIN channel. It is assigned according to the transmission priority of the messages. The operating mode is a parameter in the scheduling table information that represents the working mode of the LIN channel and determines the message scheduling execution rules of the channel.

[0066] The LinIf channel configuration is associated with LinIf message information. This establishes a unique association between a single LinIf channel configuration and all LinIf message information under the corresponding LIN channel. This allows the LinIf module to identify all message attributes under the LIN channel through the LinIf channel configuration, and is the key configuration logic for the LinIf module to implement message parsing and processing. This association can be performed for each LinIf channel configuration by extracting all LIN message information of the corresponding LIN channel from the second configuration file and converting it into LinIf message information. Then, according to the configuration specifications of the automotive open system architecture, the LinIf message information is bound to the LinIf channel configuration of LIN3 and the LinIf message information for air conditioning control and fan speed adjustment under that channel. The LinIf module can retrieve all associated message information through this configuration.

[0067] The message direction is a parameter in the LinIf message information that represents the transmission direction of the LIN message and is the basis for the LinIf module to identify the message's send and receive attributes. The sending user identifier is a unique identifier in the LinIf message information that represents the control module that initiated the LIN message sending operation and is used to associate the control subject of the message sending. The protocol identifier is a parameter in the LinIf message information that represents the unique protocol number of the LIN message, which is allocated according to the local interconnection network communication protocol specification and is the identifier for the LinIf module to identify different messages. The message length is a parameter in the LinIf message information that represents the length of the LIN message data bits and determines the amount of signal data that the message can carry. The message type is a parameter in the LinIf message information that classifies the message according to its function and purpose and is the basis for the LinIf module to process messages by type. The checksum type is a parameter in the LinIf message information that represents the LIN message data verification method and is used to ensure the accuracy of the data transmitted in the message.

[0068] For example, the first configuration file can be parsed to extract all LIN channel identifiers supported by the controller. Combining the controller hardware design specifications and the LIN communication protocol specifications, a LinChannel configuration is created for each LIN channel, and six hardware parameters, including channel identifier and baud rate, are assigned values. Then, combining the LIN channel information from the first configuration file and the LIN message information from the second configuration file, a corresponding LinIf channel configuration is created for each LIN channel. A scheduling table containing delay time, transmission sequence number, and operating mode is defined for each LinIf channel configuration, and an association is established. Simultaneously, the message information of the corresponding LIN channel is extracted from the second configuration file, converted into LinIf message information, and associated with the LinIf channel configuration. Finally, all configured LinIf channel configurations are integrated, and a global LinIf configuration is created following the automotive open system architecture specifications, completing all operations in step 103 for generating the local interconnect network module configuration.

[0069] Through the implementation of the above embodiments, a LinChannel configuration is created for each LIN channel based on the first configuration file, and a global LinIf configuration and corresponding scheduling table information are generated by combining the first and second configuration files. This enables the hardware parameters, communication scheduling, and message attributes of the LIN channel to be automatically established based on a unified data source, reducing the need for developers to configure channel parameters and scheduling tables separately in the LIN driver layer and interface layer. At the same time, by associating the LinIf channel configuration with message information, the consistency between the scheduling table, message attributes, and channel parameters can be guaranteed, thereby improving the accuracy and completeness of the underlying LIN communication configuration.

[0070] In some embodiments, the process of generating the configuration of the Com module based on the aforementioned second configuration file includes: creating a ComIPdu group based on the second configuration file, wherein the ComIPdu group includes a receive direction IPdu group (RxIPduGroup) and a transmit direction IPdu group (TxIPduGroup); creating a ComIPdu based on the LIN message information in the second configuration file, wherein the ComIPdu includes IPdu callback (IPduCallout), IPdu direction (IPduDirection), IPdu type (IPduType), and signal information contained in the LIN message; and creating a signal configuration based on the signal attributes in the second configuration file, wherein the signal configuration includes bit position (BitPosition), bit size (BitSize), notification function (Notification), byte order (Endianness), initial value (InitValue), and signal type (SignalType).

[0071] In some examples, the Communication Interaction Data Unit (ComIPdu) group, or simply ComIPdu group, is a configuration set in the Com module that categorizes and groups all ComIPdu according to the message transmission direction. It is the foundation for the Com module to systematically manage various types of interaction data units, enabling the classification, scheduling, and maintenance of ComIPdu in different transmission directions. This configuration can parse the transmission direction information of all LIN messages in the second configuration file, classify the LIN messages according to the two transmission directions of receiving and sending, and then create corresponding ComIPdu groups for the two types of messages in accordance with the configuration specifications of the automotive open system architecture for the Com module. The receive direction IPdu group and the transmit direction IPdu group are two sub-configuration sets of the ComIPdu group, divided according to the LIN message transmission direction. The receive direction IPdu group is used to collect all ComIPdu corresponding to LIN messages received by the controller from other vehicle electronic devices, while the transmit direction IPdu group is used to collect all ComIPdu corresponding to LIN messages sent by the controller to other vehicle electronic devices. The two are independent of each other and cover all ComIPdu corresponding to LIN messages of the controller. For example, the receive direction IPdu group is the configuration set for collecting ComIPdu corresponding to LIN messages such as vehicle air conditioning status feedback and vehicle multimedia device status reporting, while the transmit direction IPdu group is the configuration set for collecting ComIPdu corresponding to LIN messages such as air conditioning control commands and multimedia mode switching commands.

[0072] ComIPdu is a dedicated interactive data unit configuration in the Com module that corresponds one-to-one with a single LIN message. It serves as the carrier for signal encapsulation, parsing, and transmission of LIN messages within the Com module, with each LIN message corresponding to an independent ComIPdu. This configuration can parse the LIN message information in the second configuration file one by one, following the configuration specifications of the automotive open system architecture for the Com module, and creating a corresponding ComIPdu configuration for each LIN message. For example, ComIPdu is a dedicated interactive data unit configuration corresponding to the PTC control LIN message sent by the controller to the vehicle heating module, and it serves as the processing carrier for this message within the Com module. IPdu callback, IPdu direction, IPdu type, and the signal information contained in the LIN message are the four components of ComIPdu configuration, which together define the functional attributes, transmission characteristics, and data content carried by ComIPdu. IPdu callback is the identifier information of the callback function triggered after the LIN message transmission is completed, used to provide feedback on the message transmission status. IPdu direction is the parameter that represents the transmission direction of the corresponding LIN message for ComIPdu. IPdu type is the classification of ComIPdu according to the function and purpose of the LIN message. The signal information contained in the LIN message is the data content carried by ComIPdu.

[0073] The signal attributes in the second configuration file describe the inherent characteristics and parameters of each signal in the LIN message, and are the sole data basis for creating signal configurations. The signal configuration is a set of standardized settings for individual signals in the COM module, and is the basis for the COM module to implement signal parsing and encapsulation. Each signal corresponds to an independent signal configuration. This configuration can parse each signal attribute in the second configuration file one by one, following the standard requirements of the automotive open system architecture for COM module signal configuration, creating a corresponding signal configuration for each signal and assigning parameter values.

[0074] Bit position, bit size, notification function, byte order, initial value, and signal type are six parameters in signal configuration that collectively define the signal's storage location, data characteristics, triggering rules, and initial state within ComIPdu. Bit position is the parameter representing the signal's binary bit position within the ComIPdu data frame. The bit position attribute information for the corresponding signal can be extracted from the second configuration file and directly used as the bit position parameter in the signal configuration. Bit size is the parameter representing the number of binary bits occupied by the signal. The bit size attribute information for the corresponding signal can also be extracted from the second configuration file and directly used as the bit size parameter in the signal configuration. The notification function is the identifier information representing the notification processing function triggered when the signal value changes. It can follow the general design specifications for vehicle-mounted communications to match corresponding notification functions for different types of signals. Number identifier; byte order is a parameter representing the byte arrangement order of signal data during storage and transmission. The byte order attribute information of the corresponding signal can be extracted from the second configuration file and directly used as the byte order parameter of the signal configuration; initial value is a parameter representing the default value of the signal during system initialization. The initial value attribute information of the corresponding signal can be extracted from the second configuration file and directly used as the initial value parameter of the signal configuration; signal type is a classification of the signal based on its data characteristics. The type attribute information of the corresponding signal can be extracted from the second configuration file and directly used as the signal type parameter of the signal configuration; for example, these six parameters are: bit position is 3, bit size is 8, notification function is ComSignal_Notify, byte order is little endian, initial value is 0, and signal type is unsigned integer.

[0075] Through the implementation of the above embodiments, ComIPdu groups, ComIPdu, and corresponding signal configurations are created based on the second configuration file. This enables the mapping relationship between LIN messages and signals to be automatically established based on unified message and signal definition information, avoiding the need for developers to manually configure IPdu and signal parameters one by one in the communication module. At the same time, by uniformly generating IPdu groups for receiving and transmitting directions, the management of communication data in different directions can be made clearer, improving the consistency of communication configuration and reducing communication problems caused by incorrect signal bit definitions or mappings.

[0076] In some embodiments, the process of generating the configuration of the PduR module based on the second configuration file includes: creating a PduR routing path based on the configuration of the Com module and LIN message information, wherein the PduR routing path is used to route LIN messages to the corresponding upper-layer module or lower-layer module.

[0077] In some examples, the PduR routing path is a dedicated data transmission path configuration planned by the interactive data unit routing module for each ComIPdu corresponding to a LIN message. It is the basis for the PduR module to achieve accurate forwarding of LIN messages. It directly defines the transmission path of the ComIPdu corresponding to the LIN message from the source module to the target module in the vehicle electronic architecture, ensuring that the data can accurately reach the corresponding upper-layer module or lower-layer module. It can parse the LIN message information in the configuration of the Com module and the second configuration file, and combine the module layout of the overall vehicle electronic architecture and the communication interaction logic between the modules to plan and create a dedicated PduR routing path for each LIN message. For example, the PduR routing path is the routing path created for the vehicle air conditioning control command message of the controller LIN1 channel. This path defines the dedicated transmission path of the message from the Com module to the LIN. Another example is the routing path created for the air conditioning status feedback message of the LIN1 channel, which defines the dedicated transmission path of the message from the Com module to the upper-layer air conditioning control software component.

[0078] The process of creating a PduR routing path based on the configuration of the COM module and LIN message information involves first parsing the COM module configuration to extract the attributes, identifiers, and associated LIN message information of all ComIPdus. Then, it parses the LIN message information in the second configuration file to clarify the function and transmission requirements of each LIN message. Combining this with the functional positioning and interaction relationships of each module in the vehicle's electronic architecture, it determines whether the routing target for each LIN message is an upper-layer module or a lower-layer module. Finally, following the configuration specifications of the automotive open system architecture, it creates a dedicated PduR routing path for it. For example, this creation process involves parsing the ComIPdu configuration corresponding to the onboard PTC heating control message in the COM module, combining this with the control command transmission requirements of the message in the second configuration file, determining that its routing target is the lower-layer LIN module, and thus creating a PduR routing path from the COM module to the LIN module for that message.

[0079] For example, the complete configuration of the Com module and the LIN message information in the second configuration file can be collaboratively parsed first to extract the association between all ComIPdu and the corresponding LIN messages in the Com module, as well as the message attributes. Then, combined with the module layout of the vehicle's overall electronic architecture, the upper-layer or lower-layer module to which each LIN message needs to be routed can be determined according to its function and transmission requirements. Finally, following the configuration specifications of the PduR module in the automotive open system architecture, a dedicated PduR routing path is created for each LIN message, and all routing paths are integrated to form the configuration content of the PduR module.

[0080] Through the implementation of the above embodiments, PduR routing paths are created based on COM module configuration and LIN message information, enabling the automatic establishment of transmission paths for LIN messages between the underlying communication driver module and the upper-layer software module. This reduces the workload for developers to manually configure message forwarding relationships in the routing module. At the same time, since the routing path is generated based on unified message information, the mapping relationship of communication messages can be kept consistent when they are transmitted between different modules, reducing the risk of routing configuration errors.

[0081] In some embodiments, the process of generating the LinSM module configuration based on the Lin module configuration and the second configuration file includes: creating a LinSM channel configuration corresponding to the LIN channel based on the hardware parameters of each LIN channel in the Lin module configuration. The LinSM channel configuration includes the scheduletable queue enable parameter (ScheduleTableQueueEnable), the confirmation timeout parameter (ConfirmationTimeout), the sleep support parameter (SleepSupport), and the maximum queue size (MaxQueueSize); configuring LinSM general parameters based on the LIN message information in the second configuration file and the schedule table information in the Lin module configuration. The LinSM general parameters include the main processing period (MainProcessingPeriod) and the reinitialization enable parameter (DSMReInitEnabled), and associating the LinSM channel configuration with the LinIf module (LinIfModule) and the ComM channel (ComMChannel).

[0082] In some examples, the process of creating a corresponding LinSM channel configuration based on the hardware parameters of each LIN channel in the LIN module configuration involves first parsing the LIN module configuration, extracting the hardware parameters of each LIN channel, and then, following the configuration specifications of the automotive open system architecture for the LinSM module, and combining the hardware communication characteristics of the LIN channel, creating a dedicated LinSM channel configuration for each LIN channel. The LinSM channel configuration is a set of dedicated state management configurations customized by the LinSM module for a single LIN channel, corresponding one-to-one with the LIN channels supported by the controller. It serves as the basis for the LinSM module to perform communication state monitoring, switching, and control for a single LIN channel. For example, the LinSM channel configuration may be a dedicated configuration created for the controller's LIN2 and LIN3 channels respectively. Each configuration includes four parameters, such as scheduling table queue enable parameters and acknowledgment timeout parameters, which support the LinSM module in performing precise state management for each channel.

[0083] The scheduling table queue enable parameter, acknowledgment timeout parameter, sleep support parameter, and maximum queue size are four parameters in the LinSM channel configuration. These parameters collectively define the LinSM module's state management rules and functional support capabilities for a single LIN channel. The scheduling table queue enable parameter indicates whether the scheduling table queue function for the corresponding LIN channel is enabled. It can be assigned an enable or disable flag based on the hardware message transmission capabilities of the LIN channel in the LIN module configuration. For example, this parameter can be either 1 or 0, where 1 indicates the scheduling table queue function is enabled and 0 indicates it is disabled. The acknowledgment timeout parameter is the maximum duration for the LinSM module to wait for acknowledgment feedback regarding the communication state transition of the corresponding LIN channel. It can be combined with the hardware transmission rate, such as the baud rate, of the LIN channel in the LIN module configuration. Set the appropriate timeout duration; for example, 50 milliseconds or 100 milliseconds are timeout durations adapted to different transmission rates; the sleep support parameter is used to identify whether the sleep state management function is enabled for the corresponding LIN channel. It can be based on the hardware capability corresponding to the wake-up support parameter of the LIN channel in the LIN module configuration, and assigned a support or non-support flag; for example, the parameter is the number 1 or 0, where 1 indicates that sleep state management is supported and 0 indicates that it is not supported; the maximum queue size is the maximum number of packets that the scheduling table queue of the corresponding LIN channel can hold. It can be set to an appropriate queue capacity value based on the number of packets in the scheduling table information of the LIN channel in the LIN module configuration; for example, the parameter is 10 or 15, which means that the queue can hold 10 and 15 packets respectively.

[0084] The process of configuring LinSM general parameters based on the LIN message information in the second configuration file and the scheduling table information in the LIN module configuration involves first parsing the LIN message information in the second configuration file to extract the total number of messages, message types, transmission requirements, etc. for all LIN channels. Simultaneously, it involves parsing the scheduling table information in the LIN module configuration to extract the message scheduling frequency, timing rules, etc., for each LIN channel. Then, following the configuration specifications for the LinSM module in the automotive open system architecture and considering the actual needs of overall LIN communication, the LinSM general parameters are configured. For example, this configuration process involves parsing the number of control messages and transmission priorities for all LIN channels in the second configuration file, as well as the message scheduling interval for each channel in the LIN module configuration, and configuring the main processing cycle and re-initialization enable parameters for the LinSM general parameters accordingly. The main processing cycle and re-initialization enable parameter are two general parameters in LinSM, applicable to all LIN channels managed by the LinSM module. They are the basic rule parameters for the LinSM module to perform global state management of the entire LIN channel. The main processing cycle is a fixed time interval parameter for the LinSM module to monitor the communication status and check the schedule table execution of all LIN channels. It can be set to an appropriate global monitoring cycle by combining the message sending interval of the schedule table in the LIN module configuration and the real-time transmission requirements of LIN messages in the second configuration file. For example, this parameter is 10 milliseconds or 30 milliseconds, which means that global status monitoring is performed on all LIN channels every 10 milliseconds or 30 milliseconds, respectively. The re-initialization enable parameter is used to identify whether the LinSM module supports automatic re-initialization when a communication anomaly occurs in the LIN channel. It can be determined by combining the functional importance of LIN messages in the second configuration file to determine whether the automatic re-initialization function needs to be enabled and assign a value. For example, this parameter is the number 1 or 0, where 1 indicates that the automatic re-initialization function is enabled and 0 indicates that it is disabled.

[0085] The process of associating the LinSM channel configuration with the LinIf module and the ComM channel can follow the module interaction specifications of the automotive open system architecture, binding each LinSM channel configuration to the corresponding LinIf module configuration and ComM channel configuration of the LIN channel in a one-to-one manner. For example, this association process involves binding the LinSM channel configuration of the controller's LIN1 channel with the corresponding LinIf channel configuration and ComM1 channel, allowing the LinSM module's state management commands for the LIN1 channel to be synchronously transmitted to the LinIf module and the ComM channel.

[0086] For example, the configuration of the LIN module can be parsed first to extract the hardware parameters of each LIN channel. Following the LinSM module configuration specification, a dedicated LinSM channel configuration can be created for each LIN channel, and the four parameters, including the scheduling table queue enable parameter, can be assigned values. Then, the LIN message information in the second configuration file and the scheduling table information in the LIN module configuration can be parsed. The main processing cycle and re-initialization enable parameter of the LinSM general parameters can be configured in combination with the overall LIN communication requirements. Finally, following the module interaction specification of the automotive open system architecture, each LinSM channel configuration can be associated and bound with the LinIf module and ComM channel of the corresponding LIN channel. All LinSM channel configurations and LinSM general parameters can be integrated to form the complete configuration of the LinSM module.

[0087] Through the implementation of the above embodiments, a corresponding LinSM channel configuration is created based on the LIN channel hardware parameters in the Lin module configuration, and the LinSM general parameters are configured in combination with the LIN message information and scheduling table information in the second configuration file, so that the state management parameters of the LIN network can be automatically generated according to the actual communication configuration. At the same time, by associating the LinSM channel configuration with the LinIf module and the ComM channel, the effective association between the LIN communication channel and the communication interface layer can be realized, thereby helping to ensure the coordination of the LIN network during state switching processes such as startup, operation and hibernation.

[0088] In some embodiments, the process of generating the configuration of the BswM module based on the configuration of the Lin module and the second configuration file includes: determining the control requirements of the upper-layer software components for LIN communication based on the scheduling table information in the Lin module configuration and the LIN message information in the second configuration file; and configuring the control interface of the BswM module based on the control requirements, wherein the control interface is used to provide the upper-layer software components with control functions for LIN communication.

[0089] In some examples, control requirements are the various management and control requests made by upper-level software components in the vehicle electronic architecture to achieve their own functions regarding LIN communication. These requirements are the sole basis for configuring the BswM module control interface and cover management and control needs for aspects such as LIN channel communication status and message scheduling logic. They are highly consistent with the functional positioning of upper-level software components and the actual application scenarios of LIN communication. The scheduling table information in the LIN module configuration and the LIN message information in the second configuration file can be parsed, and combined with the functional positioning and business implementation logic of each upper-level software component in the vehicle electronic architecture, the corresponding LIN communication management and control requirements of each upper-level software component can be sorted out and derived. For example, control requirements include the wake-up control requirements of the vehicle air conditioning control software component for the LIN air conditioning communication channel, the communication mode switching requirements of the vehicle multimedia control software component for the LIN multimedia communication channel, and the sleep control requirements of the body control software component for idle LIN channels.

[0090] Based on the scheduling table information in the LIN module configuration and the LIN message information in the second configuration file, the process of determining the control requirements of upper-layer software components for LIN communication can be achieved by first parsing the scheduling table information in the LIN module configuration to extract the scheduling rules such as message scheduling order, operating mode, and transmission timing of each LIN channel. Then, the LIN message information in the second configuration file can be parsed to extract key characteristics such as the function, transmission direction, and associated devices of each LIN message. Finally, combined with the functional positioning of each upper-layer software component in the vehicle electronic architecture, the business objectives that each component needs to achieve through the management and control of LIN communication are clarified, and the corresponding control requirements are then identified. For example, this determination process involves parsing the scheduling table information of LIN1 channel in the LIN module configuration to find that the channel supports two scheduling modes: sleep and normal operation. Then, the message information of LIN1 channel in the second configuration file is parsed to find that the messages of this channel are all related to vehicle air conditioning interaction data. Combined with the functional positioning of the vehicle air conditioning control software component, it is determined that this component has control requirements for waking up, sleeping, and switching operating modes of LIN1 channel.

[0091] The control interface is a dedicated interactive channel built by the BswM module for upper-layer software components to issue control commands to the underlying LIN communication-related basic software modules. It is the direct carrier for upper-layer software components to implement LIN communication control. Its functions correspond one-to-one with the control requirements of the upper-layer software components. Each control interface is independent and can achieve precise transmission of commands. This interface can create a dedicated control interface for each control requirement according to the determined control requirements of the upper-layer software components for LIN communication, following the configuration specifications of the Automotive Open System Architecture (Autosar) for the BswM module. For example, the control interface is a LIN channel wake-up control interface configured for channel wake-up requirements, a LIN channel operation mode control interface configured for communication mode switching requirements, and a LIN channel sleep control interface configured for channel sleep requirements.

[0092] Based on control requirements, the control interface of the BswM module is configured. The control interface is used to provide control functions for LIN communication to upper-layer software components. First, the identified control requirements can be classified and sorted out to clarify the instruction transmission logic and control operation objectives of each type of control requirement. Then, following the configuration specifications of the BswM module in the automotive open system architecture, a dedicated control interface is configured for each type of control requirement. At the same time, the instruction transmission rules and data interaction format of the interface are defined so that the control interface can accurately transmit the control instructions of the upper-layer software components to the underlying LIN communication related basic software modules. For example, this configuration process is for the wake-up control requirement of the vehicle air conditioning control software component for the LIN1 channel. A dedicated LIN1 channel wake-up control interface is configured, and the instruction transmission format of the interface is defined so that the air conditioning control software component can issue a wake-up command through the interface. The underlying LIN module and the Local Interconnect Network StateManager (LinSM) module can receive and execute the command to complete the wake-up operation of the LIN1 channel.

[0093] For example, the scheduling table information in the LIN module configuration and the LIN message information in the second configuration file can be fully analyzed first to extract the scheduling rules of each LIN channel and the function and associated device information of each LIN message. Then, combined with the functional positioning of each upper-layer software component in the vehicle electronic architecture, the LIN communication control requirements corresponding to each upper-layer software component can be sorted out and determined, and the requirements can be classified and summarized. Finally, following the configuration specifications of the BswM module in the automotive open system architecture, a dedicated control interface can be configured for each type of control requirement and the interaction rules of the interface can be defined. After integrating all the control interface configurations, a complete configuration of the BswM module can be formed.

[0094] Through the implementation of the above embodiments, the control requirements of the upper-layer software components for LIN communication are determined based on the scheduling table information in the Lin module and the LIN message information in the second configuration file. The control interface of the BswM module is configured accordingly, enabling the upper-layer software components to control LIN communication through a unified interface. This reduces the complex configuration and calling relationships between the application layer and the underlying communication modules. At the same time, when the LIN communication requirements change, only the basic configuration file needs to be adjusted to automatically update the relevant control interface configuration, thereby reducing the complexity of subsequent system maintenance and functional expansion to a certain extent.

[0095] In the actual implementation of LIN communication configuration, the basic configuration file and the underlying modules are written and manually configured first, and the core data file is exported. A CSV file is first created to record the number of LIN communication channels for the controller, the control module's control permissions for each LIN channel, and other communication and caller information. Then, in the LIN interface file, a corresponding LinChannel is configured for each LIN channel, filling in hardware parameters such as channel identifier and baud rate. A LinGlobalConfig is created based on the User information in the CSV file, named according to the controller name + User rule. Subsequently, in the LinIf module file, the basic information of LinIfGeneral and LinIfGlobalConfig are manually configured, the LinIfChannel corresponding to the LIN channel is built, and the scheduling table and message-related information are configured. Similarly, LinIfGlobalConfig is named according to the controller name + User. Finally, an arxml file containing LIN communication transmission messages and message signal information is exported from SysW to provide a data foundation for subsequent automated configuration.

[0096] Based on the exported arxml file, the script can automate the configuration of the Com stack and LinSM module, replacing manual parameter-by-parameter configuration. The script parses the arxml file, creates ComIPduGroups for the receive and transmit directions based on the NetworkType value in the file, creates ComIPdu by the LINBus name and configures the relevant attributes, and configures the signal information based on the Signal attribute, thereby achieving automated configuration of the Comstack (Com / PduR). Then, the script configures the basic information of LinSMGeneral, creates the LinSMChannel corresponding to the LIN channel and configures parameters such as scheduling table queue enable and acknowledgment timeout, and associates the LinSMChannel with the LinIf module and ComMChannel to complete the automated configuration of the LinSM module, enabling the state management module and the communication interface module to work together.

[0097] After completing the configuration of the core communication and status management modules, the BswM module is automatically configured via scripts, establishing an interactive bridge between the underlying communication modules and upper-layer software components. Following the overall configuration logic of LIN communication, the BswM module is configured for compatibility via scripts, ultimately providing a dedicated interface for the upper-layer software component (SWC) to control LIN communication, enabling effective control of the underlying LIN communication by the upper-layer software component. This completes the entire LIN communication configuration process, from basic information writing and manual configuration of the underlying modules to automated script configuration of the core modules, and finally to the construction of the upper-layer control interface. This achieves a combination of manual basic configuration and automated script configuration, ensuring that the configurations of each module form a unified whole, conforming to the design specifications of the automotive open system architecture.

[0098] Furthermore, as an implementation of the foregoing method embodiments, this application also provides a LIN communication configuration generation apparatus for implementing the foregoing method embodiments; this apparatus embodiment corresponds to the foregoing method embodiments. For ease of reading, this LIN communication configuration generation apparatus embodiment will not repeat the details of the foregoing method embodiments one by one, but it should be clear that the apparatus in this application embodiment can correspondingly implement all the contents of the foregoing method embodiments. Figure 2 As shown, the LIN communication configuration generation device 20 includes: a first acquisition unit 201, a second acquisition unit 202, a first configuration unit 203, a second configuration unit 204, and a third configuration unit 205. The first acquisition unit 201 is used to acquire a first configuration file, which may include identification information of the LIN channels supported by the controller and control module information corresponding to each LIN channel. The second acquisition unit 202 is used to acquire a second configuration file, which may include LIN message information and definition information of signals contained in the LIN messages. The first configuration unit 203 is used to generate the configuration of the LIN module based on the first and second configuration files. The configuration unit 204 can include hardware parameters for each LIN channel and scheduling table information corresponding to each LIN channel; the second configuration unit 204 is used to generate the configuration of the Com module and the configuration of the PduR module based on the second configuration file, wherein the configuration of the Com module can include the signal mapping of IPdu and signals corresponding to LIN messages, and the configuration of the PduR module can include the routing information of LIN messages; the third configuration unit 205 is used to generate the configuration of the LinSM module and the configuration of the BswM module based on the configuration of the Lin module and the second configuration file, wherein the configuration of the LinSM module can include the status management parameters of each LIN channel, and the configuration of the BswM module can include the interface configuration for upper-layer software components to control LIN communication.

[0099] In some embodiments, the first configuration file is a CSV file, which contains a first preset line and a second preset line. The first preset line is used to identify the LIN channels supported by the controller, and the second preset line is used to identify the control module that can control each LIN channel.

[0100] In some embodiments, the first configuration unit 203 is further configured to create a LinChannel configuration for each LIN channel based on a first configuration file. The LinChannel configuration includes a channel identifier, baud rate, hardware channel identifier, disconnection length, disconnection delay length, and wake-up support parameters. Based on the first configuration file and the second configuration file, a LinIf global configuration is created. The LinIf global configuration includes a LinIf channel configuration corresponding to each LIN channel. The LinIf channel configuration is associated with scheduling table information, which includes delay time, transmission sequence number, and operating mode. The LinIf channel configuration is associated with LinIf message information, which includes message direction, sending user identifier, protocol identifier, message length, message type, and checksum type.

[0101] In some embodiments, the second configuration unit 204 is further configured to: create a ComIPdu group based on the second configuration file, the ComIPdu group including a receive-direction IPdu group and a transmit-direction IPdu group; create a ComIPdu based on the LIN message information in the second configuration file, the ComIPdu including IPdu callback, IPdu direction, IPdu type and signal information contained in the LIN message; and create a signal configuration based on the signal attributes in the second configuration file, the signal configuration including bit position, bit size, notification function, byte order, initial value and signal type.

[0102] In some embodiments, the second configuration unit 204 is further configured to create a PduR routing path based on the configuration of the COM module and the LIN message information. The PduR routing path is used to route LIN messages to the corresponding upper-layer module or lower-layer module.

[0103] In some embodiments, the third configuration unit 205 is further configured to create a LinSM channel configuration corresponding to the LIN channel based on the hardware parameters of each LIN channel in the Lin module configuration. The LinSM channel configuration includes scheduling table queue enable parameters, acknowledgment timeout parameters, sleep support parameters, and maximum queue size. Based on the LIN message information in the second configuration file and the scheduling table information in the Lin module configuration, the LinSM general parameters are configured. The LinSM general parameters include the main processing cycle and reinitialization enable parameters. The LinSM channel configuration is then associated with the LinIf module and the ComM channel.

[0104] In some embodiments, the third configuration unit 205 is further configured to determine the control requirements of the upper-layer software components for LIN communication based on the scheduling table information in the configuration of the LIN module and the LIN message information in the second configuration file; and configure the control interface of the BswM module based on the control requirements, wherein the control interface is used to provide the upper-layer software components with control functions for LIN communication.

[0105] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs that, when executed by a processor, will cause the processor to perform any step of the LIN communication configuration generation method provided in this application.

[0106] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0107] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0108] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0109] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0110] like Figure 3As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described LIN communication configuration generation method.

[0111] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the LIN communication configuration generation method described above.

[0112] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for generating LIN communication configurations, characterized in that, include: Obtain a first configuration file, wherein the first configuration file includes the identification information of the LIN channels supported by the controller and the control module information corresponding to each LIN channel; Obtain the second configuration file, which includes LIN message information and the definition information of signals contained in the LIN message; Based on the first configuration file and the second configuration file, the configuration of the Lin module is generated, wherein the configuration of the Lin module includes the hardware parameters of each LIN channel and the scheduling table information corresponding to each LIN channel; Based on the second configuration file, the configuration of the Com module and the configuration of the PduR module are generated. The configuration of the Com module includes the signal mapping of the IPdu corresponding to the LIN message and the signal of the signal. The configuration of the PduR module includes the routing information of the LIN message. Based on the configuration of the Lin module and the second configuration file, the configuration of the LinSM module and the configuration of the BswM module are generated. The configuration of the LinSM module includes the status management parameters of each LIN channel, and the configuration of the BswM module includes the interface configuration for upper-layer software components to control LIN communication.

2. The LIN communication configuration generation method according to claim 1, characterized in that, The first configuration file is a CSV file, which contains a first preset line and a second preset line. The first preset line is used to identify the LIN channels supported by the controller, and the second preset line is used to identify the control module that can control each LIN channel.

3. The LIN communication configuration generation method according to claim 1, characterized in that, The step of generating the Lin module configuration based on the first configuration file and the second configuration file includes: Based on the first configuration file, a LinChannel configuration is created for each LIN channel. The LinChannel configuration includes channel identifier, baud rate, hardware channel identifier, disconnection length, disconnection delay length, and wake-up support parameters. Based on the first configuration file and the second configuration file, a global LinIf configuration is created. The global LinIf configuration includes a LinIf channel configuration corresponding to each LIN channel. The LinIf channel configuration is associated with scheduling table information, which includes delay time, transmission sequence number, and operating mode. The LinIf channel configuration is associated with LinIf message information, which includes message direction, sending user identifier, protocol identifier, message length, message type, and checksum type.

4. The LIN communication configuration generation method according to claim 1, characterized in that, The process of generating the COM module configuration based on the second configuration file includes: Based on the second configuration file, a ComIPdu group is created, which includes a receive-direction IPdu group and a transmit-direction IPdu group. Based on the LIN message information in the second configuration file, a ComIPdu is created. The ComIPdu includes IPdu callback, IPdu direction, IPdu type, and signal information contained in the LIN message. Based on the signal attributes in the second configuration file, a signal configuration is created, which includes bit position, bit size, notification function, byte order, initial value, and signal type.

5. The LIN communication configuration generation method according to claim 1, characterized in that, The process of generating the PduR module configuration based on the second configuration file includes: Based on the configuration of the Com module and the LIN message information, a PduR routing path is created. The PduR routing path is used to route the LIN message to the corresponding upper-layer module or lower-layer module.

6. The LIN communication configuration generation method according to claim 1, characterized in that, The process of generating the LinSM module configuration based on the Lin module configuration and the second configuration file includes: Based on the hardware parameters of each LIN channel in the configuration of the Lin module, a LinSM channel configuration corresponding to the LIN channel is created. The LinSM channel configuration includes scheduling table queue enable parameters, acknowledgment timeout parameters, sleep support parameters, and maximum queue size. Based on the LIN message information in the second configuration file and the scheduling table information in the configuration of the Lin module, configure the general parameters of LinSM. The general parameters of LinSM include the main processing cycle and the re-initialization enable parameters, and associate the LinSM channel configuration with the LinIf module and the ComM channel.

7. The LIN communication configuration generation method according to claim 1, characterized in that, The process of generating the BswM module configuration based on the Lin module configuration and the second configuration file includes: Based on the scheduling table information in the configuration of the Lin module and the LIN message information in the second configuration file, the control requirements of the upper-layer software components for LIN communication are determined. Based on the aforementioned control requirements, the control interface of the BswM module is configured, which is used to provide control functions for LIN communication to upper-layer software components.

8. A LIN communication configuration generation device, characterized in that, include: The first acquisition unit is used to acquire a first configuration file, wherein the first configuration file includes the identification information of the LIN channels supported by the controller and the control module information corresponding to each LIN channel; The second acquisition unit is used to acquire the second configuration file, wherein the second configuration file includes LIN message information and the definition information of signals contained in the LIN message; The first configuration unit is used to generate the configuration of the Lin module based on the first configuration file and the second configuration file, wherein the configuration of the Lin module includes the hardware parameters of each LIN channel and the scheduling table information corresponding to each LIN channel; The second configuration unit is used to generate the configuration of the Com module and the configuration of the PduR module based on the second configuration file. The configuration of the Com module includes the signal mapping of the IPdu corresponding to the LIN message and the signal of the signal. The configuration of the PduR module includes the routing information of the LIN message. The third configuration unit is used to generate the configuration of the LinSM module and the configuration of the BswM module based on the configuration of the Lin module and the second configuration file. The configuration of the LinSM module includes the status management parameters of each LIN channel, and the configuration of the BswM module includes the interface configuration for upper-layer software components to control LIN communication.

9. An electronic device, comprising: A memory and a processor, characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the LIN communication configuration generation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or the computer program are executed by a processor, the steps of the LIN communication configuration generation method as described in any one of claims 1 to 7 are implemented.

Images