Vehicle window control system, vehicle and vehicle window control method

Abstract

The invention relates to the technical field of vehicle control, in particular to a vehicle window control system, a vehicle and a vehicle window control method.The system comprises a first vehicle body area controller and a second vehicle body area controller, and an application service layer, an atomic service layer and an equipment abstraction layer are deployed in the first vehicle body area controller and the second vehicle body area controller; transmission and calling of car window control information are realized among the layers through CS interfaces, and accurate reporting and control of car window states are ensured; the vehicle body area controller is provided with an application service layer and an enhanced service layer, different vehicle window APPs are deployed on the application service layers on different controllers, and the enhanced service layer is responsible for arbitrating control request priorities of the APPs; the whole system realizes communication between each controller and the whole vehicle calculation unit through the Ethernet. Therefore, the problem of function instability caused by Ethernet instability of vehicle window control is solved, and the problems that software transportability is poor, domain control advantages cannot be fully played and the like are solved.

Description

Technical Field

[0001] The present application relates to the field of vehicle control technology, and in particular to a vehicle window control system, a vehicle and a vehicle window control method. Background Art

[0002] With the rapid development of pure electric vehicle technology, the electronic and electrical architecture is undergoing an evolution from distributed to domain-centralized and even centralized in the future. This evolution aims to improve the integration, efficiency and reliability of the system, while promoting service-oriented and modularization at the software level to facilitate the reuse, expansion and upgrading of functions.

[0003] However, in the actual application of related technologies, the integration and deployment of functions such as window control face many challenges. For example, the electronic and electrical architecture evolves from distributed to domain-centralized, but the integration and deployment of functions such as window control are affected by the instability of Ethernet communication, resulting in unstable functions. If all application software is deployed in one controller, neither the advantages of domain control nor software-level service are achieved. The solution based on layered deployment of service-oriented software faces high Ethernet load and communication problems, which also affect the window control function and stability. Summary of the invention

[0004] The present application provides a vehicle window control system, a vehicle and a vehicle window control method, which solve the problem of functional instability of vehicle window control due to unstable Ethernet, as well as the problems of poor software portability and failure to give full play to the advantages of domain control.

[0005] A first aspect of the present application provides a window control system, including: a first body area controller, a second body area controller, a body area controller and a whole vehicle computing unit, wherein the first body area controller and the second body area controller are deployed with an application service layer, an atomic service layer and a device abstraction layer, the device abstraction layer reports the switch status and the switch fault status to the corresponding atomic service layer, and provides a window control CS interface for the atomic service layer to call; the atomic service layer reports the switch status and the switch fault status to the corresponding application service layer, and provides a window control CS interface for the application service layer and the enhanced service layer to call; the application service layer calls the enhanced service layer and the atomic service layer according to the triggering scenario, and decides the call of the atomic service layer according to the switch status and the switch fault status; the body area controller is deployed with an application service layer and an enhanced service layer, the first body area controller, the second body area controller and the body area controller have different window APPs deployed on their respective application service layers, the enhanced service layer arbitrates the priorities of different window APP control requests, and provides a window control CS interface for external devices to call; wherein the body area controller communicates with the whole vehicle computing unit via Ethernet.

[0006] Optionally, in one embodiment of the present application, the first vehicle body area controller, the second vehicle body area controller and the vehicle body area controller communicate with each other via Ethernet.

[0007] Optionally, in one embodiment of the present application, the window APP deployed on the first body area controller includes a main driver's switch window APP and a right front switch window APP, the window APP deployed on the second body area controller includes a right front switch window APP and a right rear switch window APP, and the body area controller includes a car locking and window raising APP and a rainy day window closing APP.

[0008] Optionally, in one embodiment of the present application, the atomic service layer includes a driving atomic service and a switching atomic service, wherein the driving atomic service and the switching atomic service of the first body area controller and the second body area controller are different.

[0009] Optionally, in one embodiment of the present application, the external device includes a cockpit domain and an OTA, wherein the body area controller communicates with the cockpit domain and the OTA via Ethernet.

[0010] Optionally, in one embodiment of the present application, the software architecture of the vehicle window control system is from top to bottom an application service layer, an enhanced service layer, an atomic service layer, and a device abstraction layer, and the four-layer service allows top-down calls.

[0011] Optionally, in one embodiment of the present application, the control request includes at least one request of button control of windows, voice control of windows, remote control of windows, locking the car and raising windows, closing windows in rainy days, and locking rear windows.

[0012] A second aspect of the present application provides a vehicle, comprising any one of the above-mentioned vehicle control systems.

[0013] A third aspect of the present application provides a window control method, which performs window control based on any of the above-mentioned window control systems, wherein the method includes the following steps: obtaining at least one window APP control request; determining a target window to be controlled based on at least one window APP control request, and obtaining a switch state and a switch fault state of the target window; deciding a response to the control request based on the switch state and the switch fault state, and controlling the target window to perform a corresponding window action according to the control request after the response.

[0014] Therefore, this application has at least the following beneficial effects:

[0015] The embodiment of the present application realizes the modularization and service-oriented operation of the window control function by using Ethernet for communication between the first body area controller, the second body area controller, the body area controller and the whole vehicle computing unit, and constructing a layered service architecture. This architecture ensures that even if the Ethernet communication is interrupted or delayed at certain times, the basic functions of the window control are not affected through independent operation and redundant design between each layer, thereby improving the reliability of the system. The window control system adopts a service-oriented development approach, splitting the window control function into multiple independent service modules. This modular design makes the function development of the application layer more flexible and not restricted by a specific controller or hardware platform. Therefore, when it is necessary to replace the window motor, the area controller chip or upgrade the system, it is only necessary to make adaptive adjustments to the device abstraction layer without large-scale reconstruction or redevelopment of the entire control system, which greatly reduces development time and cost. In the window control system, by driving the atomic Priority arbitration within the service and arbitration of enhanced services ensure the priority of physical window switches, and can ensure timely response and accurate execution of physical switch control even when other control methods exist at the same time, effectively avoiding functional conflicts or response delays caused by the coexistence of multiple control methods; the window control system adopts a highly modular and scalable design. By deploying different window APPs on different application service layers and performing priority arbitration of window control requests on the enhanced service layer, flexible expansion of the full function of the windows can be achieved; by splitting the window control function into multiple independent service modules and clarifying the interfaces and calling relationships between modules, the window control system greatly simplifies the software development and maintenance process. Developers can focus more on the development and testing of a single module without considering the complexity of the entire system. At the same time, due to the strong independence between modules, local modifications and optimizations can be made more conveniently during system upgrades or maintenance.

[0016] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0018] Figure 1 A schematic diagram of the architecture of a vehicle window control system provided according to an embodiment of the present application;

[0019] Figure 2 A block diagram of a vehicle window control system provided according to an embodiment of the present application;

[0020] Figure 3A schematic diagram of a vehicle window control architecture provided according to an embodiment of the present application;

[0021] Figure 4 A block diagram of a window control service deployment provided according to an embodiment of the present application;

[0022] Figure 5 The present invention is a flowchart of a vehicle window control method provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0024] The current electronic and electrical architecture of pure electric vehicles has evolved from a distributed architecture to a domain-centralized architecture. The window control has been integrated from the original single controller into the domain controller, but the window control function is unstable due to the influence of Ethernet communication. If all application software is deployed in one controller, the control of the window on one side will increase the wiring harness of the whole vehicle, but the advantages of domain control will not be realized, and the service-oriented software level will not be realized. Domain centralization is only realized in the physical architecture, which is not helpful for the future central centralized architecture, and the software portability is poor. If the software decision-making layers such as the application service layer and the enhanced service layer are deployed in the vehicle computing center based on the existing service-oriented software, and the execution layers such as atomic services and device abstraction services are deployed on the regional controller, then the Ethernet load will be high and communication problems will affect the stability of the window control function.

[0025] Therefore, this application proposes a window control system, which adopts a domain-centralized electronic and electrical architecture solution of a vehicle computing unit + two body area controllers + cockpit domain controller. The controllers communicate with each other using Ethernet. Based on Ethernet communication, the architecture diagram is as follows Figure 1 As shown in the figure, all application layer functions of the current mainstream car windows are developed in a service-oriented manner. According to the following layered logic, they are divided into application service layer, enhanced service layer, atomic service layer and device abstraction layer. The four layers of service allow top-down calls. Application services should distinguish services according to different trigger scenarios, call enhanced services and atomic services, and implement business logic. Enhanced services implement control arbitration of different request sources, and call the control interface of atomic services according to the arbitration results to achieve target control. At the same time, they implement common control logic, improve reusability, and simplify application software development. Atomic services should provide service interfaces with standard semantics to ensure the reusability of interfaces, and need to provide module status, fault status, and standard control methods to the outside world. The device abstraction layer is responsible for conversions directly related to load characteristics.

[0026] This ensures functional reliability and solves the problem of window control failure caused by Ethernet communication interruption under the domain controller architecture. The window function application layer development is portable through functional deployment, and two arbitrations guarantee the priority of physical switch functions. All window functions can be realized through this architecture, and subsequent new functions can be realized by adding APP. When replacing the window motor or regional controller chip, only the device abstraction layer software needs to be changed, which greatly reduces the development time.

[0027] The following describes the vehicle window control system, vehicle and vehicle window control method according to the embodiments of the present application with reference to the accompanying drawings. Specifically, Figure 2 A block diagram of a vehicle window control system provided in an embodiment of the present application.

[0028] like Figure 2 As shown, the vehicle window control system 100 includes: a first vehicle body area controller 10 , a second vehicle body area controller 20 , a vehicle body area controller 30 and a whole vehicle computing unit 40 .

[0029] Among them, the first body area controller 10 and the second body area controller 20 are deployed with an application service layer, an atomic service layer and a device abstraction layer. The device abstraction layer reports the switch status and the switch fault status to the corresponding atomic service layer, and provides a window control CS interface for the atomic service layer to call; the atomic service layer reports the switch status and the switch fault status to the corresponding application service layer, and provides a window control CS interface for the application service layer and the enhanced service layer to call; the application service layer calls the enhanced service layer and the atomic service layer according to the triggering scenario, and decides the call of the atomic service layer according to the switch status and the switch fault status; the body area controller 30 is deployed with an application service layer and an enhanced service layer, and the first body area controller 10, the second body area controller 20 and the body area controller 30 have different window APPs deployed on their respective application service layers. The enhanced service layer arbitrates the priorities of different window APP control requests, and provides a window control CS interface for external devices; the body area controller 30 communicates with the vehicle computing unit 40 via Ethernet.

[0030] It can be understood that the embodiment of the present application realizes a layered architecture of the window control function by deploying the application service layer, the atomic service layer and the device abstraction layer in the first body area controller and the second body area controller, thereby effectively improving the flexibility and portability of the system. The priority arbitration of the window control request is performed through the enhanced service layer of the body area controller, thereby realizing effective management of non-button control requests, avoiding control conflicts, and improving the stability of the system. It also provides a window control CS interface to the outside world, thereby enhancing the communication capability and response speed of the system. At the same time, the Ethernet communication between the body area controller and the vehicle computing unit ensures the data transmission efficiency and stability between the controllers, and ensures the reliability and safety of the window control function.

[0031] It should be noted that in the priority of different window APP control requests in the enhanced service layer window arbitration, button control is usually designed as the highest priority. Under the domain-centralized Ethernet communication architecture, a window control system with a clear structure and comprehensive functions is provided, which supports multiple control methods and ensures the priority of button control. The device abstraction layer is responsible for reporting status and faults, and integrates anti-pinch algorithms. The atomic service completes the learning status judgment and the anti-pinch reversal drive, which improves the safety of window control and prevents pinching accidents.

[0032] For example, according to the hierarchical architecture design adopted by the above system, the schematic diagram of the window control architecture is as follows: Figure 3 As shown, the right area controller is the same as the left one, and the window control system includes:

[0033] 1. Multiple application service layer software, each of which is responsible for different window control functions, such as: main driver's switch window control APP (WinSwt_MainFrntLeCrlAPP), right front switch window control APP (WinSwt_FrntRiCrlAPP), left rear switch window control APP (WinSwt_ReLeCrlAPP), right rear switch window control APP (WinSwt_ReRiCrlAPP), lock car window raising APP (LockCloseWinAPP), rainy day window closing APP (WinRainCrlAPP);

[0034] 2. The enhanced service layer (Enh_WinCtrlSrv) is an intermediate layer service responsible for arbitrating window control requests between different apps to ensure that only one control request is executed at the same time;

[0035] 3. Driving atomic services include: left front window driving atomic service (Atm_Window_FrntLe), right front window driving atomic service (Atm_Window_FrntRi), left rear window driving atomic service (Atm_Window_ReLe), right rear window driving atomic service (Atm_Window_ReRi);

[0036] 4. The switch atomic services include: right front window switch atomic service (Atm_WinSwt_FrntRi), main driver (left front) window switch atomic service (Atm_WinSwt_MainFrntLe), main driver controlled right front window switch atomic service (Atm_WinSwt_MainFrntRi), main driver controlled left rear window switch atomic service (Atm_WinSwt_MainReLe), main driver controlled right rear window switch atomic service (Atm_WinSwt_MainReRi), left rear window switch atomic service (Atm_WinSwt_ReLe), right rear window switch atomic service (Atm_WinSwt_ReRi);

[0037] 5. Device abstract service layer, device abstract service corresponds to each atomic service.

[0038] To ensure the stability of the button window control function, service deployment follows the principle that service calls do not cross cores within the same controller. The service deployment diagram is as follows: Figure 4 shown.

[0039] The LockCloseWinAPP and WinRainCrlAPP deployed in the VDC (Vehicle Domain Controller, vehicle computing unit) only determine whether the window control conditions are met based on the functional scenario. If they are met, they call Enh_WinCtrlSrv, which is also deployed in the VDC, using a synchronous call method with a timeout of 1ms. The enhanced service performs priority arbitration for window control requests such as closing windows in rainy days, locking the car and raising windows, voice control of windows, large screen control of windows, and OTA (Over-The-Air) remote control of windows. The window control CS interface provided by the enhanced service needs to be sent to the Ethernet for the cockpit domain and OTA calls. When calling, the function input parameters include the request ID (for priority arbitration), the target window and the target position. After receiving the request, the enhanced service arbitrates and calls the corresponding driver atomic service.

[0040] The main driver's four-window control APP is deployed in the left VIU (Vehicle Interface Unit body area controller). The switch status is collected by the bottom layer, and the switch status and fault status are reported to the switch atomic service after filtering by the device abstraction layer. The main driver's right front and right rear window switch device abstraction needs to be reported to the Ethernet and transmitted to the corresponding atomic service. The atomic service reports four-speed requests: automatic up, manual up, automatic down, and manual down. After receiving the switch request, the APP determines whether to call the corresponding drive atomic service based on the position, learning status, etc.

[0041] The atomic service driving the four windows executes the self-learning logic, reports the learning status and the current position of the window, completes the call to the device abstraction layer to drive the window, sends the input parameters including direction and duty cycle, exposes the CS interface for all button control window APPs and enhanced service calls, and performs call priority arbitration, receives the anti-pinch status reported by the device abstraction and reverses it according to the strategy. At the device abstraction layer, the switch device abstraction filters and reports the switch status and switch fault status to the corresponding atomic service. The driver device abstraction provides a CS interface for the atomic service to call, integrates the anti-pinch algorithm, and reports the current position and anti-pinch status.

[0042] In one embodiment of the present application, the first vehicle body area controller, the second vehicle body area controller and the vehicle body area controller communicate with each other via Ethernet.

[0043] It can be understood that the embodiments of the present application fully utilize the high-speed communication characteristics of Ethernet to achieve efficient data transmission and command effects between the controllers in the window control system, thereby effectively solving the problem of unstable window control function caused by the influence of Ethernet communication and improving the reliability and real-time performance of window control.

[0044] In one embodiment of the present application, the window APP deployed on the first body area controller includes the main driver's switch window APP and the right front switch window APP, the window APP deployed on the second body area controller includes the right front switch window APP and the right rear switch window APP, and the body area controller includes a car locking and window raising APP and a rainy day window closing APP.

[0045] It can be understood that by deploying targeted window APPs on different body area controllers in the embodiment of the present application, the system can more accurately respond to the switching instructions of windows in different positions to meet the personalized needs of different passengers. The modular software architecture makes the maintenance and calling of the system more intuitive and efficient. When a window APP fails, it can be repaired or updated individually without affecting the operation of the entire system. At the same time, by decomposing the window control function into multiple independent APPs, the system can manage resources more efficiently and avoid unnecessary waste of resources. This design also helps to improve the response speed and overall performance of the system.

[0046] In one embodiment of the present application, the atomic service layer includes a driving atomic service and a switching atomic service, wherein the driving atomic service and the switching atomic service of the first body area controller and the second body area controller are different.

[0047] Among them, the atomic service layer includes driving atomic services and switch atomic services. These services are deployed in the first body area controller and the second body area controller respectively according to their different functions, and the respective driving atomic services and switch atomic services are different to meet the control requirements of different windows; the driving atomic service is responsible for executing the driving logic of the window motor, including actions such as raising and lowering the window, and the switch atomic service is responsible for processing the trigger signal of the window switch, and converting it into corresponding control instructions and sending it to the driving atomic service.

[0048] It can be understood that the embodiment of the present application designs different drive atomic services and switch atomic services for the first body area controller and the second body area controller respectively, so that the system can more accurately match and control the windows in different areas. This customized service ensures the accuracy and stability of window lifting and lowering, and improves the user experience. Since each body area controller has independent drive and switch atomic services, system maintenance and debugging become easier. When a fault occurs, the problem can be checked layer by layer, and the specific atomic service can be quickly located and repaired. At the same time, different body area controllers may have different hardware resources and performance requirements. By providing them with their own unique drive and switch atomic services, the system can utilize resources more efficiently, ensure that each controller can operate in the best state, and help improve the overall performance and response speed of the system.

[0049] In one embodiment of the present application, the external device includes a cockpit domain and an OTA, wherein the body area controller communicates with the cockpit domain and the OTA via Ethernet.

[0050] It can be understood that when the cockpit domain or OTA system in the embodiment of the present application initiates a window control request, it will send a request message to the body area controller via Ethernet. By communicating through Ethernet, the data transmission speed between the body area controller and the cockpit domain and OTA is significantly improved, thereby speeding up the response speed of the window control request.

[0051] In one embodiment of the present application, the software architecture of the vehicle window control system is composed of an application service layer, an enhanced service layer, an atomic service layer, and a device abstraction layer from top to bottom, and the four-layer service allows top-down calls.

[0052] It can be understood that the embodiment of the present application adopts a layered design, and each layer assumes a specific function, which makes the functional division of the system clearer. The four-layer service architecture allows orderly calls from top to bottom, ensuring the correct execution of the window control function. At the same time, by enhancing the service layer for priority arbitration, the priority of the physical switch function is guaranteed, and problems such as window control failure caused by interference from other control methods are avoided. In addition, the layered design also makes system maintenance and debugging easier, and problems can be checked layer by layer, and faults can be quickly located and repaired. The window control system based on the domain centralized Ethernet communication architecture is highly portable. When replacing the window motor or the regional control chip, only one layer of software in the device abstraction layer needs to be changed, which greatly reduces development time and cost.

[0053] Specifically, application services should differentiate services according to different triggering scenarios, call enhanced services and atomic services, and implement business logic; enhanced services implement control arbitration of different request sources, and call the control interface of atomic services according to the arbitration results to achieve target control, while implementing common control logic, improving reusability, and simplifying application software development; atomic services should provide service interfaces with standard semantics to the outside world to ensure the reusability of the interface, and need to provide the module status, fault status, and standard control methods to the outside world; the device abstraction layer is responsible for conversions directly related to load characteristics.

[0054] In one embodiment of the present application, the control request includes at least one request of button window control, voice window control, remote window control, locking the car and raising the windows, closing the windows in rainy days, and locking the rear windows.

[0055] It can be understood that the embodiments of the present application significantly improve the functional diversity of the window control system by integrating multiple control requests, meet the needs of different users in different scenarios, and improve user experience. The introduction of intelligent functions such as voice control and remote control makes window control more convenient and intelligent. Users can open and close the windows without manual operation, which improves the convenience and safety of use. The implementation of functions such as locking the car, raising the windows and closing the windows on rainy days enables the window control system to automatically respond to complex scenarios, effectively avoiding the inconvenience and loss caused by forgetting to close the windows or rainwater intruding into the car. The rear window locking function provides additional safety for family users, prevents children from accidentally operating the windows while driving, and ensures the safety of passengers. The embodiments of the present application realize the development portability of the window function application layer through functional deployment. At the same time, the integration of multiple control requests also greatly enhances the flexibility and scalability of the window control system.

[0056] It should be noted that the current mainstream window control functions include button control of windows, voice control of windows, remote control of windows, raising windows when locking the car, closing windows in rainy days, locking the rear windows, etc.

[0057] According to the vehicle control system proposed in the embodiment of the present application, at least one window control request is received by the window control APP deployed on different body area controllers, thereby improving the flexibility of the system and user experience. Each body area controller uses Ethernet communication to obtain the switch status and switch fault status of the target window. This information is reported from the device abstraction layer to the atomic service layer, and then further reported to the application service layer, ensuring high speed and stability of data transmission. At the same time, the layered architecture of the device abstraction layer, atomic service layer, application service layer and enhanced service layer realizes the clear division and efficient calling of the software architecture, and improves the portability and maintainability of the software. The application service layer calls the enhanced service layer according to the triggering scenario to perform priority arbitration of the window APP control request, and decides whether to respond and how to respond to these control requests, effectively solving the conflict problem between multiple window APP control requests and ensuring the accuracy and safety of window control.

[0058] An embodiment of the present application also provides a vehicle, comprising any of the above-mentioned window control systems.

[0059] Next, the vehicle window control method proposed according to the embodiment of the present application is described with reference to the accompanying drawings.

[0060] Figure 5 Schematic diagram of the window control method of the embodiment of the present application

[0061] like Figure 5 As shown, the vehicle window control method comprises the following steps:

[0062] In step S501, at least one vehicle window APP control request is obtained.

[0063] It can be understood that the embodiment of the present application receives window control requests from users or external devices through the window APP deployed on different body area controllers, thereby improving the flexibility of the system and the diversity of user interaction, and meeting the window control needs of different users in different scenarios.

[0064] In step S502, a target window to be controlled is determined according to at least one window APP control request, and a switch state and a switch fault state of the target window are obtained.

[0065] Among them, the target windows include the front window, rear window, left window, right window, etc.; the switch status includes open and closed; the switch fault status includes motor fault, sensor fault, etc.

[0066] It can be understood that the embodiment of the present application determines the target window to be controlled based on the received window APP control request, ensures the accuracy and safety of the window control, and obtains the current switch status and switch fault status of the target window through the device abstraction layer, and reports it to the atomic service layer, effectively avoiding the problem of inaccurate or delayed window status monitoring.

[0067] In step S503, a response to the control request is determined according to the switch state and the switch fault state, and after the response, the target window is controlled to perform a corresponding window action according to the control request.

[0068] It can be understood that the embodiment of the present application determines whether it can respond to the current control request based on the switch state and switch fault state of the target window. If it can respond, the target window is controlled to perform corresponding actions according to the control request (such as raising, lowering, locking, etc.). If it cannot respond (such as due to a fault), a warning may be issued to the user or other safety measures may be implemented, which effectively improves the response speed of the system, ensures the timeliness and effectiveness of the window control, and avoids the problems of slow response speed and unstable control caused by complex system architecture. At the same time, the safety and reliability of the system are improved through fault detection and early warning mechanisms.

[0069] According to the window control method proposed in the embodiment of the present application, accurate, fast and safe control of the window is achieved by receiving control requests, determining the target window, obtaining the window status, making decisions and executing control actions in steps. This not only improves the user experience and system flexibility, but also avoids problems such as a single control method, inaccurate window status monitoring, slow response speed and unstable control.

[0070] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

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

[0072] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0073] A person of ordinary skill in the art may understand that all or part of the steps of the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one of the steps of the method embodiment or a combination thereof.

[0074] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A vehicle window control system, characterized in that: include: A first body area controller, a second body area controller and a body area controller, wherein, An application service layer, an atomic service layer and a device abstraction layer are deployed in the first vehicle body area controller and the second vehicle body area controller. The device abstraction layer reports the switch status and the switch fault status to the corresponding atomic service layer, and provides a window control CS interface for the atomic service layer to call; the atomic service layer reports the switch status and the switch fault status to the corresponding application service layer, and provides a window control CS interface for the application service layer and the enhanced service layer to call; the application service layer calls the enhanced service layer and the atomic service layer according to the triggering scenario, and decides the call of the atomic service layer according to the switch status and the switch fault status; The vehicle body area controller is deployed with an application service layer and the enhanced service layer. The first vehicle body area controller, the second vehicle body area controller and the vehicle body area controller respectively have different window APPs deployed on their application service layers. The enhanced service layer arbitrates the priorities of different window APP control requests and provides a window control CS interface for external devices to call.

2. The vehicle window control system according to claim 1, characterized in that: The first vehicle body area controller, the second vehicle body area controller and the vehicle body area controller communicate with each other via Ethernet.

3. The vehicle window control system according to claim 1, characterized in that: The window APPs deployed on the first body area controller include the main driver's switch window APP and the right front switch window APP, the window APPs deployed on the second body area controller include the right front switch window APP and the right rear switch window APP, and the body area controller includes a car locking and window raising APP and a rainy day window closing APP.

4. The vehicle window control system according to claim 1, characterized in that: The atomic service layer includes a driving atomic service and a switching atomic service, wherein the driving atomic service and the switching atomic service of the first body area controller and the second body area controller are different.

5. The vehicle window control system according to claim 1, characterized in that: Also includes: The whole vehicle computing unit, wherein the body area controller communicates with the whole vehicle computing unit via Ethernet.

6. The vehicle window control system according to claim 1, characterized in that: The external device includes a cockpit domain and an OTA, wherein the body area controller communicates with the cockpit domain and the OTA via Ethernet.

7. The vehicle window control system according to claim 1, characterized in that: The software architecture of the vehicle window control system is composed of an application service layer, an enhanced service layer, an atomic service layer and a device abstraction layer from top to bottom, and the four-layer service allows for top-down calls.

8. The vehicle window control system according to claim 1, characterized in that: The control request includes at least one request of key window control, voice window control, remote window control, locking the car and raising the windows, closing the windows in rainy days, and locking the rear windows.

9. A vehicle, characterized in that: A vehicle window control system as claimed in any one of claims 1 to 8.

10. A vehicle window control method, characterized in that: The method performs window control based on the window control system according to any one of claims 1 to 8, wherein the method comprises the following steps: Get at least one window APP control request; Determine a target window to be controlled according to the at least one window APP control request, and obtain a switch state and a switch fault state of the target window; A response to the control request is determined according to the switch state and the switch fault state, and after the response, the target window is controlled to perform a corresponding window action according to the control request.

Images