Driving platform system for vehicle-mounted electronic control unit and building method thereof

Abstract

This disclosure relates to a drive platform system for an on-board electronic control unit (OECU) and a method for building the same. A drive platform system for an OECU includes, from bottom to top: a microcontroller abstraction layer configured to provide the underlying drivers of the drive platform system, wherein the microcontroller abstraction layer can uniquely and directly access the registers and peripheral devices of the microcontroller of the OECU; a complex device driver layer configured to access complex device drivers; a basic software layer configured to provide system-level services; and an internal interface layer configured to provide data interaction between the basic software layer and an application layer located outside the drive platform system.

Description

Technical Field

[0001] This disclosure generally relates to the field of vehicle technology, and more specifically to a drive platform system for an on-board electronic control unit and a method for building the same, as well as an on-board electronic control unit including such a drive platform system and a vehicle including such an on-board electronic control unit. Background Technology

[0002] Thanks to the continuous development of electronic control units (also known as onboard electronic control units) in vehicles, vehicles are becoming increasingly automated and intelligent. To address the challenges posed by the rapid pace of vehicle upgrades and shorter time-to-market, many onboard electronic control units now employ the Automotive Open System Architecture (AUTOSAR) for software design. This underlying software architecture unifies interface standards and layered architectures for different component suppliers, facilitating the exchange and updates of embedded automotive software and providing a better solution for managing complex software.

[0003] Low-level software architectures like AUTOSAR have a complete framework that covers some chips, all hardware, all low-level software logic, and all application-layer business requirements. This comprehensive framework results in a vast number of configurable parameters. For example, the low-level software configuration parameters for a car's central electronic control unit (ECU) developed using AUTOSAR can reach tens of thousands. However, for lightweight automotive electronic control units that implement simpler functions (e.g., window controllers for raising and lowering windows, headlight controllers for controlling headlights, wiper controllers for controlling wiper switches, etc., typically with only one or a few functions), they are often implemented using controllers that are much cheaper than ECUs. The on-chip resources of such controllers cannot meet the application requirements of AUTOSAR. Therefore, these lightweight automotive electronic control units cannot be quickly developed using existing low-level software architectures like AUTOSAR and still follow traditional software development models. Summary of the Invention

[0004] According to a first aspect of this disclosure, a drive platform system for an on-board electronic control unit is provided, the drive platform system comprising, from bottom to top: a microcontroller abstraction layer configured to provide the underlying driver of the drive platform system, the microcontroller abstraction layer having unique direct access to the registers and peripheral devices of the microcontroller of the on-board electronic control unit; a complex device driver layer configured to access complex device drivers; a basic software layer configured to provide system-level services; and an internal interface layer configured to provide data interaction between the basic software layer and an application layer located outside the drive platform system.

[0005] In some embodiments, the first module in the basic software layer may interact with the first module in the application layer without going through the internal interface layer.

[0006] In some embodiments, the internal interface layer is further configured to provide data interaction between modules of the application layer, wherein the second module in the application layer cannot interact with the third module in the application layer without going through the internal interface layer.

[0007] In some embodiments, the microcontroller abstraction layer includes a digital input / output driver module, the base software layer includes a sensor module, and the application layer includes an application module, wherein: the digital input / output driver module of the microcontroller abstraction layer is configured to acquire an input signal and transmit the input signal to the sensor module of the base software layer in response to control at an application device associated with the application module of the application layer; the sensor module is configured to receive the input signal from the digital input / output driver module and transmit the input signal to the internal interface layer; and the internal interface layer is configured to transmit the input signal to the application module of the application layer.

[0008] In some embodiments, the base software layer further includes an actuator module, the complex device driver layer includes a complex device driver high-side driver module, and wherein: the application module of the application layer is configured to convert the input signal into an output signal and transmit the output signal to the internal interface layer; the internal interface layer is configured to invoke the actuator module of the base software layer to execute the output signal; the actuator module of the base software layer is configured to invoke the complex device driver high-side driver module of the complex device driver layer in response to being invoked by the internal interface layer; the complex device driver high-side driver module of the complex device driver layer is configured to adjust the output signal to an adjusted output signal suitable for execution by the application device in response to being invoked by the actuator module, and to invoke the digital input / output driver module of the microcontroller abstraction layer to execute the adjusted output signal; and the digital input / output driver module of the microcontroller abstraction layer is configured to drive the application device to perform an operation corresponding to the control based on the adjusted output signal.

[0009] In some embodiments, the basic software layer includes a sensor module and an actuator module, wherein: the sensor module is designed with a functional service interface, a fault diagnosis interface, and a hardwired input service interface, and the hardwired input service interface of the sensor module is encapsulated by the functional service interface and the fault diagnosis interface of the sensor module to provide a sensor abstract interface; and the actuator module is designed with a functional service interface, a fault diagnosis interface, a hardwired input service interface, and a hardwired output service interface, and the hardwired input service interface and the hardwired output service interface of the actuator module are encapsulated by the functional service interface and the fault diagnosis interface of the actuator module to provide an actuator abstract interface.

[0010] In some embodiments, the driving platform system includes a first type of module and a second type of module. The configuration parameters of each module in the first type of module are non-configurable, while one or more configuration parameters of each module in the second type of module are configurable and the remaining configuration parameters are non-configurable.

[0011] In some embodiments, the internal interface layer includes a stubbing interface for testing modules in the application layer, regardless of the presence or configuration of one or more of the microcontroller abstraction layer, the complex device driver layer, and the basic software layer.

[0012] In some embodiments, the microcontroller abstraction layer includes a microcontroller (MCU) interface, a port interface, a digital input / output (Dio) interface, a general-purpose timer (Gpt) interface, an interrupt service routine (Isr) interface, an electrically erasable programmable (Eep) interface, and a controller area network (CAN) interface; and the basic software layer includes a system base chip (Sbc) interface, a high-side driver (Hsd) interface, a non-volatile memory (NVM) interface, an operating system (OS) interface, a sensor interface, an actuator interface, and a controller area network (CANNetwork) interface.

[0013] In some embodiments, the drive platform system further includes one or more of the following: the watchdog (Wdg) interface, input capture unit (Icu) interface, pulse width modulation (PWM) interface, analog-to-digital converter (ADC) interface, serial peripheral interface (Spi) interface, and local interconnection network (Lin) interface in the microcontroller abstraction layer; and the watchdog manager (WdgM) interface, radio frequency (RF) interface, analog-to-digital converter manager (ADCM) interface, serial peripheral interface manager (SpiM) interface, and electronic control unit manager (EcuM) interface in the basic software layer.

[0014] According to a second aspect of this disclosure, an on-board electronic control unit is provided, including a drive platform system according to any embodiment of the first aspect of this disclosure and an application layer located outside the drive platform system.

[0015] According to a third aspect of this disclosure, a vehicle is provided, including an on-board electronic control unit as described in a second aspect of this disclosure.

[0016] According to a fourth aspect of this disclosure, a method for constructing a drive platform system for an on-board electronic control unit is provided, comprising: providing a microcontroller abstraction layer to provide the underlying driver of the drive platform system, the microcontroller abstraction layer being uniquely and directly accessible to the registers and peripheral devices of the microcontroller of the on-board electronic control unit; providing a complex device driver layer for accessing complex device drivers; providing a basic software layer for providing system-level services; and providing an internal interface layer for providing data interaction between the basic software layer and an application layer located outside the drive platform system.

[0017] Other features and advantages of this disclosure will become clearer from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0018] The foregoing and other features and advantages of this disclosure will become clear from the following description of embodiments illustrated in conjunction with the accompanying drawings. The drawings, incorporated herein and forming a part of the specification, are further used to explain the principles of this disclosure and to enable those skilled in the art to make and use it. Wherein:

[0019] Figure 1 This is a schematic block diagram illustrating a drive platform system for an on-board electronic control unit according to some embodiments of the present disclosure;

[0020] Figure 2 It is shown Figure 1 A schematic block diagram of an example architecture design for a driver platform system;

[0021] Figure 3 It is shown Figure 2 A schematic diagram illustrating the data flow of the module interfaces in an example driver platform system;

[0022] Figure 4 This is a flowchart illustrating a method for constructing a drive platform system for an on-board electronic control unit according to some embodiments of the present disclosure.

[0023] Note that in the embodiments described below, the same reference numerals are sometimes used across different figures to denote the same parts or parts with the same function, and repeated descriptions are omitted. In some cases, similar reference numerals and letters are used to denote similar items, so once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0024] For ease of understanding, the positions, dimensions, and extents of the structures shown in the accompanying drawings and other materials may not represent actual positions, dimensions, and extents. Therefore, this disclosure is not limited to the positions, dimensions, and extents disclosed in the accompanying drawings and other materials. Detailed Implementation

[0025] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

[0026] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the scope of this disclosure or its application or use. That is, the structures and methods herein are shown in an exemplary manner to illustrate different embodiments of the structures and methods in this disclosure. However, those skilled in the art will understand that they merely illustrate exemplary ways that can be used to implement this disclosure, and not exhaustive ways. Furthermore, the drawings are not necessarily drawn to scale, and some features may be enlarged to show details of specific components.

[0027] In addition, techniques, methods and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods and equipment should be considered part of the specification.

[0028] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0029] This disclosure proposes a drive platform system for vehicle-mounted electronic control units and a method for building it. It adopts a layered software architecture design based on functional dimensions, which can support different hardware platforms and is especially suitable for the rapid software development of lightweight vehicle-mounted electronic control units.

[0030] Figure 1A drive platform system 100 for an on-board electronic control unit according to some embodiments of the present disclosure is illustrated. The drive platform system 100 includes, from bottom to top, a microprocessor abstraction layer (Mcal) 120, a complex device driver layer (Cdd) 140, a basic software layer (Bsw) 160, and an internal interface layer (Fgi) 180. The microprocessor abstraction layer 120 is located at the bottom layer of the overall architecture of the drive platform system 100, while the internal interface layer 180 is located at the top layer. The microprocessor abstraction layer (Mcal) 120, the complex device driver layer (Cdd) 140, the basic software layer (Bsw) 160, and the internal interface layer (Fgi) 180 remain relatively independent.

[0031] The microcontroller abstraction layer 120 is configured to provide the underlying driver for the drive platform system 100. The microcontroller abstraction layer 120 is uniquely (in other words, only the microcontroller abstraction layer 120 can) directly access the registers and peripheral devices of the microcontroller used in the vehicle electronic control unit within the drive platform system 100. The microcontroller abstraction layer 120 can abstract the characteristics of different microcontrollers and extract their common modules to summarize the interface calling methods, thus providing a unified interface compatible with different microcontrollers. In other words, providing the microcontroller abstraction layer 120 can shield the differences in microcontroller implementation methods, ensuring that the operation of the drive platform system 100 is not affected regardless of the microcontroller used on the hardware platform to which it is deployed.

[0032] The complex device driver layer 140 is configured to access complex device drivers, such as external ECU devices, system basis chips (SBCs), radio frequency (RF) chips, and high sidedrive (HSD) chips. The complex device driver layer 140 can call the microcontroller abstraction layer 120, and can also be called by the basic software layer 160 or the internal interface layer 180.

[0033] The basic software layer 160 is configured to provide system-level services, such as operating system services, memory services, communication services, sleep / wake-up services, sensor services, and actuator services. The basic software layer 160 can call the microcontroller abstraction layer 120; for example, it can indirectly access the registers and peripheral devices of the microcontroller in the vehicle's electronic control unit by calling the microcontroller abstraction layer 120. The basic software layer 160 can also call the complex device driver layer 140; for example, it can indirectly access complex device drivers by calling the basic software layer 160. The basic software layer 160 can also be called by the internal interface layer 180.

[0034] The internal interface layer 180 is configured to provide data interaction between the base software layer 160 and the application layer (App) located outside the driver platform system 100, for example, referencing Figure 2 and Figure 3 In some examples, the first module in the base software layer 160 cannot interact with the first module in the application layer without going through the internal interface layer 180. In some examples, each module in the base software layer 160 cannot interact with the modules in the application layer without going through the internal interface layer 180. In other words, the internal interface layer 180 provides the interaction interface between the entire driver platform system 100 and the external application layer, while shielding the differences in the underlying implementation of the driver platform system 100 below the internal interface layer 180. This facilitates the future integration of more modules into the layers below the internal interface layer 180 of the driver platform system 100, providing scalability to the architecture of the driver platform system 100. For example, the internal interface layer 180 may consist of a single file, which can maintain all communication relationships of the internal interface layer 180 in tabular form (e.g., an Excel spreadsheet). The internal interface layer 180 mainly proxies the data or functions output by each module and passes them through to other modules.

[0035] Through the internal interface layer 180, the application layer can collaborate with the drive platform system 100 to implement various control functions. For example, the digital input / output drive module of the microcontroller abstraction layer 120 can be configured to acquire input signals and transmit them to the sensor module of the base software layer 160 in response to control at the application device associated with the application module of the application layer. The sensor module can be configured to receive input signals from the digital input / output drive module and transmit them to the internal interface layer 180, which can then be configured to transmit the input signals to the application module of the application layer. Furthermore, the application module can be configured to convert the input signal into an output signal and transmit the output signal to the internal interface layer 180. The internal interface layer 180 can be configured to call the actuator module of the basic software layer 160 to execute the output signal. The actuator module can be configured to call the complex device driver high-side driver module of the complex device driver layer 140 in response to being called by the internal interface layer 180. The complex device driver high-side driver module can be configured to adjust the output signal to an adjusted output signal suitable for execution by the application device in response to being called by the actuator module, and call the digital input / output driver module of the microcontroller abstraction layer 120 to execute the adjusted output signal. The digital input / output driver module of the microcontroller abstraction layer 120 can be configured to drive the application device to perform an operation corresponding to the control according to the adjusted output signal.

[0036] Taking a vehicle lighting controller as an example, the application layer can deploy a vehicle lighting application module. When the vehicle lighting switch control is triggered at the vehicle lighting location (e.g., by activating / disabling the vehicle lighting switch), the digital input / output driver module of the microcontroller abstraction layer 120 acquires the switch input signal and transmits it to the sensor module of the basic software layer 160. This sensor module captures the switch input signal and transmits it to the internal interface layer 180. The internal interface layer 180 transmits the switch input signal to the vehicle lighting application module in the application layer. This vehicle lighting application module converts the switch input signal into a switch output signal and... The switch output signal is transmitted to the internal interface layer 180. The internal interface layer 180 calls the actuator module of the basic software layer 160 to execute the switch output signal. The actuator module calls the complex device driver high-side driver module of the complex device driver layer 140. The complex device driver high-side driver module adjusts the switch output signal to an adjusted switch output signal suitable for the vehicle light to execute, and calls the digital input / output driver module of the microcontroller abstraction layer 120 to execute the adjusted switch output signal. The digital input / output driver module drives the vehicle light to turn on or off according to the adjusted switch output signal.

[0037] Additionally, in some embodiments, the internal interface layer 180 is also configured to provide data interaction between modules in the application layer. In some examples, a second module in the application layer cannot interact with a third module in the application layer without going through the internal interface layer 180. In some examples, each module in the application layer cannot interact with another module in the application layer without going through the internal interface layer 180. In some embodiments, the internal interface layer 180 includes a stubbing interface that can be used to test modules in the application layer, regardless of the specific underlying implementation of the driver platform system 100 below the internal interface layer 180, such as the presence and, if present, configuration of one or more of the microcontroller abstraction layer 120, complex device driver layer 140, and basic software layer 160. That is, the internal interface layer 180 imparts testability to the architecture of the driver platform system 100. Even if the underlying implementation of the driver platform system 100 below the internal interface layer 180 may not be developed or not fully developed, it does not preclude the use of the internal interface layer 180 of the driver platform system 100 to test the already developed modules of the application layer. This greatly accelerated the development process and improved development efficiency.

[0038] As a non-restrictive example, Figure 2 The architecture of a driver platform system, from bottom to top, includes a microcontroller abstraction layer (Mcal), a complex device driver layer (Cdd), a basic software layer (Bsw), and an internal interface layer (Fgi). For example... Figure 2As shown, the Microcontroller Abstraction Layer (Mcal) may include a Controller Area Network (DrvCan) driver module, a driver (Drv) module, an analog-to-digital converter (DrvAdc) driver module, a digital input / output (DrvDio) driver module, a general-purpose timer (DrvGpt) driver module, an input capture unit (DrvIcu) driver module, an interrupt service routine (DrvIsr) driver module, a local interconnection network (DrvLin) driver module, a microcontroller driver (DrvMcu) module, a port driver (DrvPort) module, a pulse width modulation (DrvPwm) driver module, a serial peripheral interface (DrvSpi) driver module, a watchdog timer (DrvWdg) driver module, and an electrically erasable programmable (EEPROM) driver (DrvEE). The complex device driver layer (Cdd) may include an analog-to-digital converter manager (AdcM) module, a serial peripheral interface manager (SpiM) module, a watchdog manager (WdgM) module, a complex device driver system base chip (CddSbc) module, a complex device driver RF chip (CddRf) module, and a complex device driver high-side driver (CddHsd) module. The basic software layer (Bsw) may include a sensor module, an actuator module, a signal module, an electronic control unit manager (EcuM) module, a local interconnection network (Lin) module, an operating system (Os) module, a controller area network (CAN) module, and a non-volatile memory (Nvm) module. Figure 3 An example is shown Figure 2 The data flow between the interfaces of these modules. It should be understood that, depending on specific needs, each layer may include more or fewer modules than those shown in the diagram, or may include other modules, but these modules can be assigned to the corresponding layer according to their respective functions based on the layered architecture of the driver platform system 100.

[0039] The sensor and actuator modules of the basic software layer 160 can be designed based on a service-oriented architecture, which can facilitate the independence of these modules. In some embodiments, the sensor modules of the basic software layer 160 can be designed with functional service interfaces, fault diagnosis interfaces, and hardwired input service interfaces. The hardwired input service interfaces of the sensor modules are encapsulated by the functional service interfaces and fault diagnosis interfaces of the sensor modules to provide a sensor abstraction interface. That is, the functional service interfaces and fault diagnosis interfaces of the sensor modules can be designed to face the application layer, while the hardwired input service interfaces of the sensor modules are designed to face the microcontroller and are not exposed to the application layer. Although the application layer cannot directly access the hardwired input service interfaces of the sensor modules, it can indirectly access them by calling the hardwired input service interfaces of the sensor modules through the functional service interfaces and fault diagnosis interfaces. The sensor abstraction interface can provide interfaces corresponding to functions such as switch signal acquisition, temperature acquisition, speed acquisition, current acquisition, and sensor fault diagnosis. In some embodiments, the actuator module of the basic software layer 160 may be designed with functional service interfaces, fault diagnosis interfaces, hardwired input service interfaces, and hardwired output service interfaces. The hardwired input and hardwired output service interfaces of the actuator module are encapsulated by the functional service interfaces and fault diagnosis interfaces to provide an actuator abstract interface. That is, the functional service interfaces and fault diagnosis interfaces of the actuator module may be designed to face the application layer, while the hardwired input and hardwired output service interfaces of the actuator module are designed to face the microcontroller and are not exposed to the application layer. Although the application layer cannot directly access the hardwired input and hardwired output service interfaces of the actuator module, it can indirectly access them by calling the hardwired input and hardwired output service interfaces through the functional service interfaces and fault diagnosis interfaces. The actuator abstract interface may, for example, provide interfaces corresponding to high-side drive output, fault diagnosis functions, current acquisition functions, and input feedback functions.

[0040] Furthermore, in some embodiments, the modules of the driver platform system 100 can be divided into two categories, such as a first category of modules and a second category of modules. In the first category of modules, the configuration parameters of each module are non-configurable, while in the second category of modules, one or more configuration parameters are configurable, and the remaining configuration parameters are non-configurable. That is, the configuration parameters of the first category of modules are built-in and cannot be changed by the user; a large portion of the configuration parameters of the second category of modules may also be built-in and cannot be changed externally, while a small portion can be determined by the user through minimal configuration. This reduces the difficulty of using the driver platform system 100 for users.

[0041] As a non-restrictive example, the following settings can be made:

[0042] In the DrvCan module's configuration parameters, the baud rate is configurable, while the other configuration parameters are not.

[0043] In the DrvLin module's configuration parameters, the baud rate is configurable, while the other configuration parameters are not.

[0044] In the Nvm module's configuration parameters, the block start address and block length (which appear in pairs, and there can be multiple pairs) are configurable, while the other configuration parameters are not configurable.

[0045] In the configuration parameters of the DrvSpi module, the SPI hardware number is configurable, while the other configuration parameters are not configurable.

[0046] In the configuration parameters of the DrvAdc module, the ADC hardware number and ADC channel number (which appear in pairs, and there can be multiple pairs) are configurable, while the other configuration parameters are not configurable.

[0047] In the configuration parameters of the DrvPwm module, the FTM hardware number, FTM channel number, PWM output frequency, and duty cycle (which appear in pairs, and there can be multiple pairs) are configurable, while the other configuration parameters are not configurable.

[0048] In the DrvIcu module's configuration parameters, the FTM hardware number, FTM channel number, port, and edge signal detection mode (which appear in pairs, and there can be multiple pairs) are configurable, while the remaining configuration parameters are not configurable.

[0049] Among the configuration parameters of the DrvPort module, the following are configurable: Module, Signal Name, MCU Pin, (Multiplexed) Pin Name, Pin Configuration, Pin Type, Input Interrupt Type, Input Pull-up / Pull-down Configuration, Initial Output Value, Active Output Value, Output Stop Value, Software Features, and Hardware Features. The remaining configuration parameters are not configurable. (Since the DrvPort module has many configurable items, a parameter table as shown in Table 1 can be designed to standardize the parameter acquisition of the DrvPort module.)

[0050] Table 1

[0051]

[0052] Additionally, the following settings can be made for the CddHsd module:

[0053] In the configuration parameters of the single-channel CddHsd module, the server identifier (Server_ID), input channel pin configuration (INPUT0), and current acquisition pin configuration (Logic_CS) are configurable, while the other configuration parameters are not configurable (for example, a parameter table as shown in Table 2 can be designed to standardize the parameter acquisition of the single-channel CddHsd module. Each row in Table 2 can correspond to a specific high-side driver chip. Server_ID, INPUT0, and Logic_CS are used to define the hardware wiring relationship of the high-side driver chip. Thus, the corresponding configuration parameters of the single-channel CddHsd module for the corresponding high-side driver chip can be maintained by maintaining Table 2).

[0054] Table 2

[0055]

[0056]

[0057] In the configuration parameters of the dual-channel CddHsd module, the server identifier (Server_ID), first input channel pin configuration (INPUT0), second input channel pin configuration (INPUT1), first channel selection pin configuration (SEL0), second channel selection pin configuration (SEL1), current acquisition pin configuration (Logic_CS), first channel selection pin configuration truth table (SEL0_VAL), and second channel selection pin configuration truth table (SEL1_VAL) are configurable, while the remaining configuration parameters are not configurable. (For example, a parameter table as shown in Table 3 can be designed to standardize the parameter acquisition of the dual-channel CddHsd module. In Table 3, each two rows can correspond to a specific high-side driver chip. Server_ID, INPUT0, INPUT1, SEL0, SEL1, and Logic_CS are used to define the hardware wiring relationship of the high-side driver chip, and SEL0_VAL and SEL1_VAL are used to define the diagnostic truth table of the high-side driver chip. Thus, the corresponding configuration parameters of the dual-channel CddHsd module for the corresponding high-side driver chip can be maintained by maintaining Table 3.)

[0058] Table 3

[0059] Server_ID INPUT0 INPUT1 SEL0 SEL1 Logic_CS SEL0_VAL SEL1_VAL VN7E010_1_CH0 PTB4 PTB5 PTA0 PTA1 ADC0_SE14 0 0 VN7E010_1_CH0 PTB4 PTB5 PTA0 PTA1 ADC0_SE11 0 1 VN7E010_2_CH0 PTC8 PTC9 PTA5 PTA6 ADC0_SE12 0 0 VN7E010_2_CH0 PTC8 PTC9 PTA5 PTA6 ADC0_SE12 0 1 …… …… …… …… …… …… …… ……

[0060] Among the configuration parameters of the four-channel CddHsd module, the server identifier (Server_ID), first input channel pin configuration (INPUT0), second input channel pin configuration (INPUT1), third input channel pin configuration (INPUT2), fourth input channel pin configuration (INPUT3), first channel selection pin configuration (SEL0), second channel selection pin configuration (SEL1), current acquisition pin configuration (Logic_CS), first channel selection pin configuration truth table (SEL0_VAL), and second channel selection pin configuration truth table (SEL1_VAL) are configurable, while the remaining configuration parameters are not configurable (parameter tables can also be designed similarly to the above to standardize the parameter acquisition of the four-channel CddHsd module).

[0061] Among the configuration parameters of the H-bridge full-bridge motor CddHsd module, the server identifier (Server_ID), full-bridge A-channel pin configuration (INA), full-bridge B-channel pin configuration (INB), pulse width modulation (PWM), first channel selection pin configuration (SEL0), second channel selection pin configuration (SEL1), current acquisition pin configuration (Logic_CS), full-bridge A-channel pin configuration truth table (INA_VAL), full-bridge B-channel pin configuration truth table (INB_VAL), pulse width modulation truth table (PWM_VAL), first channel selection pin configuration truth table (SEL0_VAL), and second channel selection pin configuration truth table (SEL1_VAL) are configurable. The remaining configuration parameters are not configurable (parameter tables can also be designed similarly to the above to standardize the parameter acquisition of the H-bridge full-bridge motor CddHsd module).

[0062] Therefore, regardless of the high-side driver chip used on the hardware platform to which the driver platform system 100 is deployed, the configuration of the CddHsd module can be completed quickly.

[0063] In the example above, by selecting specific configuration parameters of the module to be configurable and making the rest of the configuration parameters unconfigurable, the development difficulty of the driver platform system 100 can be reduced and the development efficiency improved, while ensuring the flexibility and applicability of the driver platform system 100.

[0064] To enable the driver platform system 100 to support different hardware platforms, the interfaces of each layer of the driver platform system 100 can be redesigned to a standard form. In some embodiments, the microcontroller abstraction layer 120 includes a microcontroller (MCU) interface, a port interface, a digital input / output (DIO) interface, a general-purpose timer (GPT) interface, an interrupt service routine (ISR) interface, an electrically erasable programmable (EEP) interface, and a controller area network (CAN) interface. The basic software layer 160 includes a system base chip (SBC) interface, a high-side driver (HSD) interface, a non-volatile memory (NVM) interface, an operating system (OS) interface, a sensor interface, an actuator interface, and a controller area network (CANNetwork) interface. In such embodiments, hard-wired input / output operations (pull-high or pull-low levels) of the load can be implemented, and OS polling of the operating system can also be included. In other embodiments, the drive platform system 100 may further include one or more of the following: a watchdog (Wdg) interface, an input capture unit (Icu) interface, a pulse width modulation (PWM) interface, an analog-to-digital converter (ADC) interface, a serial peripheral interface (Spi) interface, and a local interconnect network (Lin) interface in the microcontroller abstraction layer 120; and a watchdog manager (WdgM) interface, a radio frequency (RF) interface, an analog-to-digital converter manager (ADCM) interface, a serial peripheral interface manager (SpiM) interface, and an electronic control unit manager (EcuM) interface in the basic software layer 160. As a non-limiting example, these interfaces may be defined as follows.

[0065]

[0066]

[0067]

[0068] Figure 4 A method 200 for constructing a drive platform system for an on-board electronic control unit (OECU) according to some embodiments of the present disclosure is illustrated, comprising: at step S202, providing a microcontroller abstraction layer to provide the underlying drivers of the drive platform system, the microcontroller abstraction layer having unique direct access to the registers and peripheral devices of the microcontroller of the OECU; at step S204, providing a complex device driver layer for accessing complex device drivers; at step S206, providing a basic software layer for providing system-level services; and at step S208, providing an internal interface layer for providing data interaction between the basic software layer and an application layer located outside the drive platform system. Embodiments of method 200 can be similarly referred to in various embodiments of the aforementioned drive platform system 100, and will not be described again here.

[0069] This disclosure also provides an on-board electronic control unit (OIC) comprising a drive platform system according to any of the foregoing embodiments and an application layer located outside the drive platform system. In particular, such an OIC may be a lightweight OIC, such as a window controller, headlight controller, wiper controller, etc.

[0070] In another aspect, this disclosure also provides a vehicle that includes the on-board electronic control unit as described above. It should be understood that the term "vehicle" as discussed herein is not limited to automobiles, but can also include motorcycles, trains, ships, airplanes, etc. In other words, the term "vehicle" as discussed herein can include any suitable means of transportation.

[0071] The terms “left,” “right,” “front,” “back,” “top,” “bottom,” “upper,” “lower,” “high,” “lower,” etc., used in the specification and claims, if present, are for descriptive purposes and not necessarily for describing unchanging relative positions. It should be understood that such terms are interchangeable where appropriate, enabling the embodiments of this disclosure described herein to operate, for example, in orientations different from those shown or otherwise described herein. For example, when the device in the drawings is reversed, a feature previously described as “above” other features may now be described as “below” other features. The device may also be oriented in other ways (rotated 90 degrees or in other orientations), in which case the relative spatial relationships will be interpreted accordingly.

[0072] In the specification and claims, when an element is described as being "on top of," "attached" to, "connected" to, "coupled" to, "coupled to," or "in contact with" another element, the element may be directly located on top of, directly attached to, directly connected to, directly coupled to, directly coupled to, or directly in contact with the other element, or one or more intermediate elements may be present. Conversely, when an element is described as being "directly" located on top of, directly attached to, directly connected to, directly coupled to, directly coupled to, or directly in contact with another element, no intermediate elements are present. In the specification and claims, when a feature is arranged "adjacent" to another feature, it may mean that a feature has a portion overlapping with the adjacent feature or a portion located above or below the adjacent feature.

[0073] As used herein, the term "exemplary" means "serving as an example, instance, or illustration," and not as a "model" to be precisely copied. Any implementation described herein by example is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, this disclosure is not limited to any theory expressed or implied as given in the art, background, summary of the invention, or detailed description.

[0074] As used herein, the term "substantially" means any minor variation resulting from design or manufacturing defects, device or component tolerances, environmental influences, and / or other factors. The term "substantially" also allows for differences from the perfect or ideal situation due to parasitic effects, noise, and other practical considerations that may exist in the actual implementation.

[0075] Additionally, terms such as “first,” “second,” etc., may be used in this document for reference purposes only and are not intended to be limiting. For example, unless the context clearly indicates otherwise, the words “first,” “second,” and other such numerical terms relating to structures or elements do not imply order or sequence.

[0076] It should also be understood that when the term “including / contains” is used herein, it indicates the presence of the indicated feature, whole, step, operation, unit and / or component, but does not preclude the presence or addition of one or more other features, wholes, steps, operations, units and / or components and / or combinations thereof.

[0077] In this disclosure, the term “provide” is used broadly to cover all ways of obtaining an object, and therefore “provide an object” includes, but is not limited to, “purchasing,” “preparing / manufacturing,” “arranging / setting up,” “installing / assembling,” and / or “ordering” an object.

[0078] As used herein, the term “and / or” includes any and all combinations of one or more of the listed items in association. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of this disclosure. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise.

[0079] Those skilled in the art will recognize that the boundaries between the above operations are merely illustrative. Multiple operations may be combined into a single operation, a single operation may be distributed among additional operations, and operations may be performed with at least partial overlap in time. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be changed in various other embodiments. However, other modifications, variations, and substitutions are equally possible. Aspects and elements of all the embodiments disclosed above may be combined in any way and / or in combination with aspects or elements of other embodiments to provide multiple additional embodiments. Therefore, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

[0080] While specific embodiments of this disclosure have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of this disclosure. The various embodiments disclosed herein can be combined in any way without departing from the spirit and scope of this disclosure. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of this disclosure. The scope of this disclosure is defined by the appended claims.

Claims

1. A drive platform system for an on-board electronic control unit, the drive platform system comprising, from bottom to top: The microcontroller abstraction layer is configured to provide the underlying driver for the drive platform system. The microcontroller abstraction layer has direct access to the registers and peripheral devices of the microcontroller of the vehicle electronic control unit. The complex device driver layer is configured to access complex device drivers; The basic software layer is configured to provide system-level services; as well as The internal interface layer is configured to provide data interaction between the underlying software layer and the application layer located outside the driver platform system. The microcontroller abstraction layer is configured to abstract the characteristics of multiple different microcontrollers and provide a unified interface to be compatible with the multiple different microcontrollers, which do not include the controller of the vehicle's electronic control unit.

2. The drive platform system according to claim 1, wherein, The first module in the basic software layer must interact with the first module in the application layer without going through the internal interface layer.

3. The drive platform system according to claim 1, wherein, The internal interface layer is also configured to provide data interaction between modules of the application layer. The second module in the application layer must interact with the third module in the application layer without going through the internal interface layer.

4. The drive platform system according to claim 1, wherein, The microcontroller abstraction layer includes a digital input / output driver module, the basic software layer includes a sensor module, and the application layer includes an application module, wherein: The digital input / output driver module of the microcontroller abstraction layer is configured to acquire an input signal and transmit the input signal to the sensor module of the basic software layer in response to control at an application device associated with the application module of the application layer. The sensor module is configured to receive the input signal from the digital input / output driver module and transmit the input signal to the internal interface layer; and The internal interface layer is configured to transmit the input signal to the application module of the application layer.

5. The drive platform system according to claim 4, wherein, The basic software layer also includes an actuator module, and the complex device driver layer includes a complex device driver high-side driver module, wherein: The application module of the application layer is configured to convert the input signal into an output signal and transmit the output signal to the internal interface layer; The internal interface layer is configured to invoke the actuator module of the underlying software layer to execute the output signal; The actuator module of the basic software layer is configured to invoke the complex device driver high-side driver module of the complex device driver layer in response to being invoked by the internal interface layer. The complex device driver high-side driver module of the complex device driver layer is configured to adjust the output signal to an adjusted output signal suitable for execution by the application device in response to being invoked by the actuator module, and to invoke the digital input / output driver module of the microcontroller abstraction layer to execute the adjusted output signal; and The digital input / output driver module of the microcontroller abstraction layer is configured to drive the application device to perform an operation corresponding to the control based on the adjusted output signal.

6. The drive platform system according to claim 1, wherein, The basic software layer includes a sensor module and an actuator module, wherein: The sensor module is designed with a functional service interface, a fault diagnosis interface, and a hard-wired input service interface. The hard-wired input service interface of the sensor module is encapsulated by the functional service interface and the fault diagnosis interface to provide a sensor abstraction interface; and The actuator module is designed with a functional service interface, a fault diagnosis interface, a hard-wired input service interface, and a hard-wired output service interface. The hard-wired input service interface and the hard-wired output service interface of the actuator module are encapsulated by the functional service interface and the fault diagnosis interface of the actuator module to provide an actuator abstract interface.

7. The drive platform system according to claim 1, wherein, The driving platform system includes a first type of module and a second type of module. The configuration parameters of each module in the first type of module are non-configurable, while one or more configuration parameters of each module in the second type of module are configurable and the rest are non-configurable.

8. The drive platform system according to claim 1, wherein, The internal interface layer includes a stubbing interface for testing modules in the application layer, regardless of the presence or configuration of one or more of the microcontroller abstraction layer, the complex device driver layer, and the basic software layer.

9. The drive platform system according to claim 1, wherein, The microcontroller abstraction layer includes a microcontroller interface, a port interface, a digital input / output interface, a general-purpose timer interface, an interrupt service routine interface, an electrically erasable programmable interface, and a controller area network interface. The basic software layer includes a system base chip interface, a high-side driver interface, a non-volatile memory interface, an operating system interface, a sensor interface, an actuator interface, and a controller area network interface.

10. The drive platform system according to claim 9, further comprising one or more of the following: The microcontroller abstraction layer includes a watchdog interface, input capture unit interface, pulse width modulation interface, analog-to-digital converter interface, serial peripheral interface, and local interconnection network interface; the basic software layer includes a watchdog manager interface, radio frequency interface, analog-to-digital converter manager interface, serial peripheral interface manager interface, and electronic control unit manager interface.

11. An on-board electronic control unit, comprising a drive platform system according to any one of claims 1 to 10 and an application layer located outside the drive platform system.

12. A vehicle comprising the on-board electronic control unit according to claim 11.

13. A method for constructing a drive platform system for an on-board electronic control unit, comprising: A microcontroller abstraction layer is provided to provide the underlying driver for the drive platform system. The microcontroller abstraction layer can directly access the registers and peripheral devices of the microcontroller of the vehicle electronic control unit. Provides a complex device driver layer for accessing complex device drivers; Provides a basic software layer for delivering system-level services; as well as An internal interface layer is provided to facilitate data interaction between the underlying software layer and the application layer located outside the driver platform system. The microcontroller abstraction layer abstracts the characteristics of multiple different microcontrollers and provides a unified interface to ensure compatibility with these multiple different microcontrollers. These multiple different microcontrollers do not include the controller of the vehicle's electronic control unit.

Images