Control method and apparatus
By introducing management and observation modules into the smart cockpit, the system detects user operation characteristics and compares them with preset rules, ensuring that vehicle control functions are only executed when the user actually operates the system. This solves the problem of attackers abusing vehicle control after the smart cockpit is compromised, and achieves the effect of improving vehicle safety performance and protecting user safety.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- YINWANG INTELLIGENT TECHNOLOGIES CO LTD
- Filing Date
- 2024-10-30
- Publication Date
- 2026-05-07
AI Technical Summary
Once the smart cockpit is compromised, attackers can impersonate users and abuse the vehicle's control functions, endangering users' personal safety and privacy.
By deploying management and observation modules in the smart cockpit, the characteristic states of user input operations are detected and compared with preset rules to ensure that the vehicle control function is only executed when the user actually operates it, thus preventing attackers from impersonating the user.
It effectively prevents attackers from abusing vehicle control functions, improves vehicle safety performance, and protects users' personal safety and privacy.
Smart Images

Figure CN2024128426_07052026_PF_FP_ABST
Abstract
Description
A control method and apparatus Technical Field
[0001] This application relates to the field of intelligent vehicles, and more particularly to a control method and apparatus. Background Technology
[0002] The vehicle's smart cockpit has a rich ecosystem, which can not only run the factory-installed applications, but also third-party applications (i.e., applications from parties other than the car manufacturer and the user). This results in a large amount of interaction between the smart cockpit and the outside of the vehicle, making it vulnerable to attacks.
[0003] The smart cockpit is responsible for the interaction between the vehicle and the user. Most of the user's control over the vehicle is achieved through the smart cockpit. Once the smart cockpit is compromised, all the functions that control the vehicle through the smart cockpit may be abused by attackers, thereby endangering the user's personal safety and privacy.
[0004] How to ensure vehicle safety performance after the smart cockpit has been compromised is a technical problem that urgently needs to be solved.
[0005] Summary of the Invention
[0006] This application provides a control method and apparatus that can effectively prevent attackers from using the vehicle body control functions of the smart cockpit after it has been compromised, thereby improving vehicle safety performance and protecting the personal and privacy safety of users.
[0007] In a first aspect, a control method is provided, applied to a first device in a vehicle, the first device being, for example, a smart cockpit, the first device having a human-machine interface, the human-machine interface including but not limited to a central control screen, microphone, buttons, etc., and an application deployed in the first device, such as an application deployed in the central control screen, the method comprising: detecting a first instruction, the first instruction being used to instruct a second device of the vehicle to perform a first operation, the second device including but not limited to an intelligent driving system, a light controller, a window controller, an air conditioner, etc.; obtaining first information according to the first instruction, the first information being associated with the state of at least one feature of the first device; and determining whether the second device performs the first operation according to the first information.
[0008] This application embodiment considers that the state of at least one feature when the first instruction is triggered by user input may differ from the state of at least one feature when the first instruction is triggered by an attacker impersonating a user. It designs a method to determine whether the second device executes the first operation based on the first information. This allows for determining that the second device executes the first operation when the first instruction is triggered by a user, and determining that the second device does not execute the first operation when the first instruction is triggered by an attacker impersonating a user. This application embodiment can effectively prevent attackers from using the vehicle control functions of the smart cockpit after it has been compromised, thereby improving vehicle safety and protecting user personal and privacy security.
[0009] In one possible design, at least one feature includes one or more of the following: hardware, interrupt, message, file, memory, and program. Of course, the above features are just examples and are not limited to these.
[0010] In one possible design, the first information includes the state of at least one feature. Accordingly, determining whether the second device performs the first operation based on the first information includes: if the state of at least one feature satisfies a preset rule, then determining that the second device performs the first operation; if the state of at least one feature does not satisfy the preset rule, then determining that the second device does not perform the first operation.
[0011] Alternatively, the first information may be used to instruct the second device whether to perform the first operation. Accordingly, determining whether the second device performs the first operation based on the first information includes: if the first information instructs the second device to perform the first operation, then determining that the second device performs the first operation; if the first information instructs the second device not to perform the first operation, then determining that the second device does not perform the first operation; wherein, when the state of at least one feature satisfies a preset rule, the first information instructs the second device to perform the first operation; when the state of at least one feature does not satisfy the preset rule, the first information instructs the second device not to perform the first operation.
[0012] When the first instruction is triggered by user input, the state of at least one feature satisfies a preset rule. When the first instruction is triggered by user input, the state of at least one feature does not satisfy the preset rule. The above design determines whether the second device should perform the first operation based on whether the state of at least one feature satisfies the preset rule, which can ensure that the second device does not perform the first operation after the smart cockpit is compromised.
[0013] In one possible design, the state of at least one feature is related to the triggering method of the first instruction.
[0014] Since there are multiple ways for a user to perform input operations, meaning there can be multiple ways to trigger the first instruction, different triggering methods can cause different feature states to change, or different triggering methods can cause the same feature to change its state in different ways. Therefore, different triggering methods can correspond to different features or different combinations of features, and correspondingly, the preset rules that the states of these features need to satisfy can also be different.
[0015] The following are some of the possible triggering methods:
[0016] 1. Screen tap trigger. Screen tap trigger refers to the method where the user touches the electronic screen (such as the central control screen) to trigger the first command.
[0017] Accordingly, the state of at least one feature includes, but is not limited to, at least one of the following: the pixel state of the display screen, the interrupt state of the touch screen, and the file state of the system log.
[0018] Accordingly, the preset rules include, but are not limited to, at least one of the following:
[0019] The pixel state of the display screen satisfies the first characteristic;
[0020] The touchscreen experienced an interruption during the initial time period;
[0021] The system log contains screen input records related to the first operation during the second time period.
[0022] 2. Voice triggering. Voice triggering refers to the method by which the user inputs voice commands into the smart cockpit to trigger the first instruction.
[0023] Accordingly, the state of at least one feature includes, but is not limited to, at least one of the following: the pixel state of the display screen, the interruption state of the microphone, the file state of the system log, and the running state of the first program.
[0024] Accordingly, the preset rules include, but are not limited to, at least one of the following:
[0025] The display screen shows pixels related to voice display;
[0026] The microphone was interrupted during the third time period;
[0027] The system log contains voice input records related to the first operation during the fourth time period;
[0028] The first program has traffic communicating with the speech parsing server during the fifth time period.
[0029] 3. Button triggering. Button triggering refers to the method by which the user touches a physical button in the smart cockpit to trigger the first command.
[0030] Accordingly, the state of at least one feature includes, but is not limited to, at least one of the following: the interrupt state of the key press, and the file state of the system log.
[0031] Accordingly, the preset rules include, but are not limited to, at least one of the following:
[0032] The button press was interrupted during the sixth time period;
[0033] The system log contains key input records for the seventh time period.
[0034] 4. Communication Trigger. Communication trigger refers to the method by which the user uses a mobile phone, key, wearable device, or other means to communicate with the smart cockpit and trigger the first command.
[0035] Accordingly, the status of at least one feature includes, but is not limited to, at least one of the following: the communication status of the vehicle's telematics box (T-Box) and the file status of the system log.
[0036] Accordingly, the preset rules include, but are not limited to, at least one of the following:
[0037] The T-BOX has data showing active communication with the cockpit domain controller (CDC) during the eighth time period;
[0038] The system log contains records of business execution related to the first operation during the ninth time period.
[0039] Of course, the above triggering methods are just examples, and are not limited to these in practice.
[0040] In one possible design, the first device may include a management module that can receive a first instruction, obtain first information based on the first instruction, and determine whether the second device should perform the first operation based on the first information.
[0041] In one possible design, the first device may also include a business module, in which the application is deployed. The business module and the management module run in different domains, and the management module can receive first instructions from the business module.
[0042] The domain where the business module resides is a vulnerable domain. Since the business module and the management module run in different domains, the management module's operations, such as determining whether the second device should perform the first operation, are less susceptible to interference from attackers. This ensures the accuracy of the judgment results, further improves the vehicle's safety performance, and protects the personal and privacy safety of users.
[0043] In one possible design, the first device may further include an observation module, which has permission to view the resources of the business module. The management module can obtain first information from the observation module according to a first instruction.
[0044] For example, the management module can send a first request to the observation module according to a first instruction, the first request being used to request first information from the observation module; the observation module collects the status of at least one feature from the business module according to the first request, and sends the first information to the management module according to the status of at least one feature; the management module receives the first information from the observation module.
[0045] Understandably, in practical applications, the observation module and the management module can be integrated into the same module.
[0046] Through the above design, the management module can obtain the first information from the observation module, which has the permission to view the resources of the business module, thus ensuring the reliability of the first information.
[0047] In a second aspect, a control method is provided, applied to a first device in a vehicle, the first device being, for example, a smart cockpit, the first device having a human-machine interface, the human-machine interface including but not limited to a central control screen, microphone, buttons, etc., and an application deployed in the first device, such as an application deployed in the central control screen, the method comprising: receiving a first request, the first request being used to request first information, the first information being associated with the state of at least one feature of the first device; obtaining the state of at least one feature according to the first request; and sending the first information according to the state of at least one feature, the first information being used to determine whether a second device of the vehicle performs a first operation.
[0048] This application embodiment takes into account that the state of at least one feature when the first instruction is triggered by user input operation is different from the state of at least one feature when the first instruction is triggered by an attacker impersonating a user operation. It designs a method to send first information based on the state of at least one feature, so that the first information can be used to determine whether the second device of the vehicle performs the first operation. This provides support for effectively preventing attackers from using the vehicle body control function of the smart cockpit after the smart cockpit is compromised. It can help improve the safety performance of the vehicle and protect the personal and privacy safety of users.
[0049] In one possible design, at least one feature includes one or more of the following: hardware, interrupt, message, file, memory, and program. Of course, the above features are just examples and are not limited to these.
[0050] In one possible design, the first information includes the state of at least one feature. Alternatively, the first information is used to indicate whether the second device performs a first operation. Specifically, if the state of at least one feature satisfies a preset rule, the first information instructs the second device to perform the first operation; if the state of at least one feature does not satisfy the preset rule, the first information instructs the second device not to perform the first operation.
[0051] For the specific design of the state, preset rules, etc. of at least one feature, please refer to the corresponding design in the first aspect, which will not be repeated here.
[0052] In one possible design, the first device may include an observation module that can receive a first request, acquire the state of at least one feature based on the first request, and send first information based on the state of at least one feature.
[0053] In one possible design, the first device may further include a business module, in which the application is deployed, and an observation module has permission to view the business module. The observation module can collect the status of at least one feature from the business module based on a first request.
[0054] In one possible design, the first device may further include a management module. The management module can detect a first instruction, which instructs the second device to perform a first operation, and send a first request to an observation module based on the first instruction. Correspondingly, the observation module can receive the first request from the management module and send first information to the management module based on the status of at least one feature; the management module receives the first information from the observation module and determines whether the second device performs the first operation based on the first information.
[0055] The beneficial effects of the above-mentioned design methods can be referred to the beneficial effects of the corresponding designs in the first aspect, and will not be repeated here.
[0056] Thirdly, a control device is provided, comprising modules for implementing the method as described in the first aspect or any possible design of the first aspect.
[0057] For example, the device may include:
[0058] The transceiver module is used to detect a first instruction, which instructs a second device of the vehicle to perform a first operation; and to acquire first information based on the first instruction, the first information being associated with the state of at least one feature of the first device.
[0059] The processing module is also used to determine whether the second device should perform the first operation based on the first information.
[0060] In one possible design, at least one feature includes one or more of the following: hardware, interrupt, message, file, memory, and program. Of course, the above are just examples, and the actual design is not limited to these.
[0061] In one possible design, the first information includes the state of at least one feature. The processing module is configured to: if the state of at least one feature satisfies a preset rule, determine that the second device performs the first operation; if the state of at least one feature does not satisfy the preset rule, determine that the second device does not perform the first operation.
[0062] In one possible design, the first information is used to indicate whether the second device performs the first operation. The processing module is configured to: if the first information indicates that the second device performs the first operation, then determine that the second device performs the first operation; if the first information indicates that the second device does not perform the first operation, then determine that the second device does not perform the first operation. Specifically, the first information indicates that the second device performs the first operation when the state of at least one feature satisfies a preset rule; the first information indicates that the second device does not perform the first operation when the state of at least one feature does not satisfy the preset rule.
[0063] In one possible design, the state of at least one feature is related to the triggering method of the first instruction. For specific designs regarding the state of at least one feature, preset rules, etc., please refer to the corresponding design in the first aspect; further details will not be provided here.
[0064] In one possible design, the transceiver module is used to receive the first instruction from the business module.
[0065] In one possible design, the transceiver module is used to obtain first information from the observation module according to the first instruction.
[0066] In one possible design, the transceiver module is used to: send a first request to the observation module according to a first instruction, the first request being used to request first information from the observation module; and receive the first information from the observation module.
[0067] Fourthly, a control device is provided, comprising modules for implementing methods as described in the second aspect or any possible design of the second aspect.
[0068] For example, the device may include:
[0069] The transceiver module is configured to: receive a first request, the first request being for requesting first information, the first information being associated with the state of at least one feature of the first device;
[0070] The processing module is used to obtain the status of at least one feature based on the first request;
[0071] The transceiver module is also configured to send first information based on the state of at least one feature, the first information being used to determine whether the second device of the vehicle performs the first operation.
[0072] For the specific design of the state, preset rules, etc. of at least one feature, please refer to the corresponding design in the first aspect, which will not be repeated here.
[0073] In one possible design, the processing module is used to collect the status of at least one feature from the business module based on a first request.
[0074] In one possible design, the transceiver module is used to: receive a first request from the management module; and send the first information to the management module based on the status of at least one feature.
[0075] Fifthly, a control device is provided, comprising a processor connected to a memory for storing a computer program, the processor for executing the computer program stored in the memory to cause the method as described in the first aspect or any possible design of the first aspect to be performed, or the method as described in the second aspect or any possible design of the second aspect to be performed.
[0076] A sixth aspect provides a computer-readable storage medium storing a computer program or instructions that, when executed by a control device, cause the method described in the first aspect or any possible design of the first aspect to be performed, or cause the method described in the second aspect or any possible design of the second aspect to be performed.
[0077] In a seventh aspect, a computer program product is provided, the computer program product comprising a computer program or instructions that, when executed by a control device, cause the method described in the first aspect or any possible design of the first aspect to be performed, or cause the method described in the second aspect or any possible design of the second aspect to be performed. Attached Figure Description
[0078] Figures 1A to 1D are schematic diagrams of several possible application scenarios provided in this application;
[0079] Figure 2 is a schematic diagram of the hardware architecture of an intelligent cockpit provided in an embodiment of this application;
[0080] Figures 3A, 3B, 4A, and 4B illustrate the software architecture of several smart cockpits provided in the embodiments of this application.
[0081] Figure 5 is a flowchart of a control method provided in an embodiment of this application;
[0082] Figure 6 is a schematic diagram of a scenario where a user performs an input operation to trigger the first instruction;
[0083] Figure 7 is a schematic diagram of a scenario where an external attack triggers the first command;
[0084] Figure 8 is a flowchart illustrating the interaction between modules in a smart cockpit;
[0085] Figure 9 is a schematic diagram of a control device provided in an embodiment of this application;
[0086] Figure 10 is a schematic diagram of another control device provided in an embodiment of this application. Detailed Implementation
[0087] The following explanations will clarify some of the terms used in this application to facilitate understanding by those skilled in the art.
[0088] 1. Intelligent Cockpit:
[0089] A smart cockpit is a general term for intelligent and connected airborne products installed within the cockpit, enabling the cockpit to have intelligent interactive functions. Taking a vehicle's smart cockpit as an example, products in a smart cockpit include, but are not limited to, head-up display (HUD), driver monitor system (DMS), cabin monitor system (CMS), panoramic imaging system, in-vehicle infotainment system, and telematics box (T-Box). A smart cockpit has a human-machine interface for interaction between people and the vehicle, and between the vehicle and the outside world (e.g., vehicle-to-vehicle interaction), providing a more intelligent driving experience for vehicle users (such as drivers) and promoting driving safety. The smart cockpit can serve as the control center of the vehicle body, allowing users to control the vehicle body by interacting with it. In some embodiments, a smart cockpit may also be referred to as a cockpit or driver's cabin.
[0090] 2. Human-computer interaction interface:
[0091] Human-computer interaction (HCI) refers to the interface of input / output devices that establish communication and exchange information between a human and a computer system. For example, in a vehicle's smart cockpit, the center console typically includes a central control screen, physical buttons, a microphone, and other devices. Users can interact with the built-in computer system of the smart cockpit by touching the central control screen, inputting voice into the microphone, or touching the buttons. In this case, the screen, microphone, and buttons can be considered HCI interfaces. In some embodiments, HCI interfaces may also be referred to as HCI devices.
[0092] In one possible example, users can also interact with the smart cockpit using a terminal device that has established a communication connection with it. In this case, the terminal device can be considered the human-machine interface of the smart cockpit, or the communication module of the smart cockpit (such as T-BOX) can also be considered the human-machine interface. The communication connection methods between the terminal device and the smart cockpit include, but are not limited to, cellular, Bluetooth, ultra-wideband (UWB), and Wi-Fi. Types of terminal devices include, but are not limited to, keys, mobile phones, tablets, and wearable devices with communication functions (such as watches, wristbands, helmets, and headphones).
[0093] 3. Domain:
[0094] In one possible interpretation, "domain" refers to a "functional domain." In a vehicle, the entire vehicle can be divided into multiple different functional domains (referred to as "domains") according to the functions provided by each part of the vehicle, and different domains can perform different functions.
[0095] For example, in some implementations, the entire vehicle can be divided into an intelligent driving domain (for providing intelligent driving functions), an intelligent cockpit domain (for providing intelligent cockpit functions), a chassis domain (for providing chassis control functions), a powertrain domain (for providing powertrain control functions), and a body domain (for providing body control functions). Understandably, different manufacturers may use different domains based on their own concepts. Controllers in each domain can utilize stronger processing power to centrally control their respective domains, integrating the onboard computing required for multiple functions.
[0096] In practice, the function corresponding to a domain can be implemented by combining multiple sub-functions. Therefore, the aforementioned domain can be further subdivided. For example, the intelligent cockpit domain can further include an entertainment domain and an instrument domain, where the entertainment domain is responsible for providing users with entertainment functions (such as radio, music playback, map navigation, telephone, etc.), and the instrument domain is responsible for providing users with instrument panel functions (such as speedometer, tachometer, oil pressure gauge, water temperature gauge, fuel gauge, charging gauge, etc.).
[0097] In another possible interpretation, "domain" refers to a "region." Regions include hardware regions and / or software regions, etc. Hardware regions refer to actual physical regions, such as chips deployed in different locations in a vehicle (e.g., intelligent driving controllers and body controllers), which occupy different physical regions; software regions refer to isolated software modules, such as two operating systems created through virtualization technology, which run on the same chip but are isolated from each other (i.e., run independently).
[0098] The technical solution provided in this application is described below with reference to the accompanying drawings.
[0099] The vehicle's smart cockpit boasts a rich ecosystem, allowing users to control most aspects of the vehicle through interaction with it, such as setting driving modes, precisely controlling lights, and adjusting regenerative braking intensity. The smart cockpit can run a wide variety of applications, including those pre-installed with the vehicle and third-party applications. This results in extensive interaction between the smart cockpit and external systems (such as third-party servers), making it more vulnerable to attacks. Once compromised, attackers can impersonate users, abuse the vehicle's control functions, and ultimately endanger user safety and privacy.
[0100] In view of this, the technical solution provided in this application can identify and prevent attackers from impersonating users to abuse the vehicle control functions of the smart cockpit, thereby improving vehicle safety performance and protecting user personal and privacy safety.
[0101] The following describes the application scenarios of the embodiments of this application.
[0102] In one possible application scenario, embodiments of this application can be applied to vehicles, for example, integrated into the cockpit of a vehicle. The vehicles may include, but are not limited to, vehicles, ships, airplanes, trains, subways, maglev trains, submarines, spacecraft, or fighter jets. Taking a smart cockpit applied to a vehicle as an example:
[0103] Please refer to Figure 1A, which shows a possible application scenario diagram provided by this application. Users can control the vehicle (such as turning the air conditioner on and off, changing songs, etc.) by touching the central control screen of the smart cockpit.
[0104] Please refer to Figure 1B, which illustrates another possible application scenario provided by this application. Users input voice commands into the smart cockpit by speaking to control the vehicle (such as answering phone calls, adjusting volume, etc.).
[0105] Please refer to Figure 1C, which shows another possible application scenario provided by this application. The user touches the physical buttons in the smart cockpit to control the vehicle (such as setting the driving mode, adjusting the lights, etc.).
[0106] The user can communicate with the smart cockpit remotely using their mobile phone to control the vehicle (such as remotely closing windows and remotely parking).
[0107] Please refer to Figure 1D, which illustrates another possible application scenario provided by this application. Users can use a remote mobile phone to communicate with the smart cockpit to control the vehicle (such as remotely closing windows, remote parking, etc.).
[0108] It should be understood that the various possible application scenarios given above are merely examples, and the embodiments of this application can also be applied to other possible scenarios, and are not limited to the scenarios exemplified above. It should be noted that the application scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application.
[0109] The hardware architecture of the smart cockpit in this application embodiment is described below.
[0110] Referring to Figure 2, which is a schematic diagram of the hardware architecture of an intelligent cockpit provided in an embodiment of this application, it includes one or more processors and at least one human-machine interface.
[0111] The processor can run software systems. In one specific example, the processor can be an electronic control unit (ECU) of a smart cockpit, such as a cockpit domain controller (CDC).
[0112] The human-computer interaction interface is the interface between the smart cockpit and the user. Examples include the central control screen, microphone, buttons, and communication modules (such as cellular / Bluetooth / UWB / Wi-Fi) shown in Figure 2. Of course, the actual types of human-computer interaction interfaces are not limited to the examples mentioned above.
[0113] It should be understood that the hardware architecture shown in Figure 2 only illustrates the components related to the embodiments of this application. Other components may also be included in actual applications, and the embodiments of this application do not impose any limitations.
[0114] The following describes the software architecture of the smart cockpit in the embodiments of this application.
[0115] Referring to Figure 3A, which illustrates a software architecture for an intelligent cockpit according to an embodiment of this application, the system includes a business module, a management module, and an observation module. These modules can be deployed in the processor shown in Figure 2. It is understood that the business module, management module, and observation module can be integrated onto one processor or deployed on multiple processors; there is no limitation.
[0116] The business module is used for user interaction, and applications are deployed within it; in other words, the business module itself is an application. These applications are, for example, applications that interact with the user in a smart cockpit, specifically including but not limited to applications deployed in the in-vehicle infotainment system on the central control screen. These applications can receive information or instructions triggered by user input, thereby causing the applications to perform corresponding operations. For example, the application generates instructions to direct components on the vehicle to perform relevant operations (such as the first instruction described later). In this embodiment, after generating the instruction, the business module can forward the instruction to the management module.
[0117] The management module is independent of the business module, or isolated from it, meaning the operation of the program in the management module is unaffected by the operation of the program in the business module. Specifically, this could be achieved by the business module and the management module running in different domains. The management module and the business module can have a communication channel (i.e., they can communicate with each other). In this embodiment, after receiving an instruction from the business module, the management module can identify whether the instruction was generated by an attacker impersonating a user. If it was, the second device does not execute the first operation; only after determining that the first instruction was generated by a user operation will the second device execute the first operation. For example, the management module can obtain first information from the observation module based on the first instruction. This first information is related to the state of at least one feature, and the management module can then determine whether the second device should execute the first operation based on this first information.
[0118] The observation module has permission to view the resources of the business module. Resources include hardware resources and / or software resources. For example, the observation module can collect the status of at least one feature from the business module, and then send initial information to the management module based on the status of at least one feature. The status of at least one feature will be described in detail later.
[0119] Optionally, the observation module and the management module can also be integrated into one module, as shown in Figure 3B. That is, the same module can perform multiple functions such as detecting the first instruction, obtaining the first information, and determining whether the second device performs the first operation.
[0120] In one possible design, the software architecture of the smart cockpit can be divided into multiple layers, such as an application layer and a hardware management layer. The application layer can deploy applications, while the hardware management layer acts as the layer between the application layer and the underlying hardware. The hardware management layer can interact with applications in the application layer (e.g., accessing their resources) and with the underlying hardware (e.g., receiving interrupts from the hardware and invoking hardware to perform operations). Optionally, the hardware management layer can have higher privileges than the application layer; for example, it can not only directly view the resources of the application layer but also control the operation of applications within it.
[0121] Of course, the above are just examples, and there may be other possibilities for the layer division of actual software architecture.
[0122] In one possible example, the observation module is located in the hardware management layer, the business module and the management module are located in the application layer, and the business module and the management module run in different domains.
[0123] Figure 4A illustrates a specific example of a software architecture, where the application layer includes an entertainment domain and an instrumentation domain. The entertainment domain and instrumentation domain are isolated from each other but can communicate with each other; for example, virtualization technology can be used to enable independent execution of programs in the entertainment domain and the instrumentation domain.
[0124] The business module is located in the entertainment domain or is part of the entertainment domain. For example, the business module is an application related to vehicle control (hereinafter referred to as vehicle control application) in the entertainment domain, specifically including but not limited to music, maps, and air conditioning settings. Optionally, in addition to the application (business module), the entertainment domain may also include other modules, such as an input management module and a vehicle control agent module. The input management module is used to trigger the corresponding vehicle control application to perform corresponding operations based on interrupts received from the hardware management layer (such as triggering the vehicle control application to generate instructions). The vehicle control agent module is used to forward the instructions received from the vehicle control application to the instrument cluster domain.
[0125] The management module may reside in the instrument cluster domain or may be a process deployed within the instrument cluster domain. Optionally, in addition to the management module, the instrument cluster domain may also include other modules, such as a vehicle control service module, which provides vehicle control-related services, such as receiving instructions from the entertainment domain and forwarding them to the management module.
[0126] The observation module resides within the hardware management layer, or it may be a process within the hardware management layer itself. Specifically, the observation module could be a process within the micro-hypervisor (microvisor) of the hardware management layer. The micro-hypervisor can run multiple virtual machines on a single physical machine and manage these virtual machines. For example, the domain where the business module runs and the domain where the management module runs can be two virtual machines running on the same hardware chip. Optionally, in addition to the observation module, the micro-hypervisor may also include other modules, such as an interrupt management module, which receives interrupts generated by the underlying hardware and distributes these interrupts to the application layer's input management module.
[0127] Figure 4B shows another specific example of software architecture. Unlike Figure 4A, the management module and the observation module are both located in the hardware management layer. For example, they are two processes in the Microvisor, or the management module and the observation module are integrated into one process of the Microvisor.
[0128] It is understood that Figures 4A and 4B are only examples, and the actual division of layers and modules in software architecture is not limited to these, nor is the specific location of each module limited to the examples given in Figures 4A and 4B.
[0129] It can be understood that the software architecture shown in Figures 3A, 3B, 4A, and 4B can be specifically deployed in the processor shown in Figure 2.
[0130] Referring to Figure 5, a control method provided in an embodiment of this application is applied to a first device in a vehicle. The first device has a human-machine interface and an application program is deployed in the first device. Taking the first device as an example of a smart cockpit or the first device being deployed in a smart cockpit as described above, the method may include the following steps S502 to S503:
[0131] S501, Detect the first instruction, the first instruction being used to instruct the second device of the vehicle to perform the first operation.
[0132] The second device is a device deployed on the vehicle. It can correspond to all devices in a domain or some devices in a domain, without limitation. The second device can be a software device or a hardware device, without limitation. The second device can be located in the intelligent cockpit domain or in other domains (such as the chassis domain, powertrain domain, body domain, etc.), without limitation. For example, the first instruction is used to instruct the intelligent driving system to set the driving mode, or the first instruction is used to adjust the headlights by the indicator light controller, or the first instruction is used to instruct the window controller to open / close the window, or the first instruction is used to instruct the air conditioning to adjust the fan speed or temperature, and so on.
[0133] In a specific example, taking the hardware architecture shown in Figure 2 as an example, detecting the first instruction may include: the processor detecting the first instruction.
[0134] In a specific example, taking the software architecture shown in Figure 3A, Figure 3B, Figure 4A, or Figure 4B as an example, detecting the first instruction may include: the business module sending the first instruction and the management module receiving the first instruction.
[0135] In this embodiment of the application, the first instruction may be an instruction triggered by the user performing an input operation, or it may be an instruction triggered by an attacker impersonating the user's operation.
[0136] Taking the software architecture shown in Figure 4A above as an example, Figures 6 and 7 are schematic diagrams of the scenario where the user performs an input operation to trigger the first instruction and the scenario where an external attack triggers the first instruction, respectively.
[0137] As shown in Figure 6, the process of a user performing an input operation to trigger the first instruction is illustrated below:
[0138] S601. When a user clicks on the central control screen and clicks on the corresponding control (or icon) for the air conditioning temperature adjustment function, the user is instructed to adjust the temperature to 24℃.
[0139] S602, the central control screen responds to the user's click operation, generates an interrupt, and passes the interrupt to the interrupt management module of the hardware management layer (e.g., reporting the air conditioner turning on event);
[0140] S603, The interrupt management module distributes interrupts to the input management module in the application layer;
[0141] S604. The input management module triggers the corresponding application (i.e., the business module) to perform an operation, such as instructing the air conditioning application to adjust the temperature to 24°C;
[0142] S605, The air conditioning application generates a first instruction and sends the first instruction to the vehicle control agent module. The first instruction is used to instruct the air conditioning (i.e. the second device) to adjust the temperature to 24°C.
[0143] S606, the vehicle control agent module forwards the first instruction to the instrument domain, for example, the vehicle control service module in the instrument domain receives the first instruction;
[0144] It is understandable that the vehicle control agent module can directly forward the first instruction received to the vehicle control service module, or it can process the first instruction received before forwarding it to the vehicle control service module. For example, it can convert the first instruction into a second instruction before forwarding it to the vehicle control service module. The second instruction is used to instruct the air conditioner to adjust the temperature to 24℃.
[0145] S607, the vehicle control service module forwards the first instruction (or the second instruction) to the management module, and the management module receives the first instruction (or the second instruction).
[0146] It is understandable that the vehicle control service module can directly forward the received first instruction (or second instruction) to the management module, or it can process the received first instruction (or second instruction) before forwarding it to the vehicle control service module. For example, the first instruction (or second instruction) can be converted into a third instruction before being forwarded to the vehicle control service module. The third instruction is used to instruct the air conditioner to adjust the temperature to 24°C.
[0147] As shown in Figure 7, the process of an external attack triggering the first instruction is illustrated below:
[0148] S701. An attacker attacks a program in the application layer, such as an air conditioning application (i.e., a business module), and instructs the air conditioning application to adjust the temperature to 24°C.
[0149] S702, The air conditioning application generates a first instruction, which is used to instruct the air conditioner (i.e. the second device) to adjust the temperature to 24°C;
[0150] S703, the vehicle control agent module forwards the first instruction to the instrument cluster domain, for example, the vehicle control service module in the instrument cluster domain receives the first instruction.
[0151] S704, the vehicle control service module forwards the first instruction to the management module, and the management module receives the first instruction.
[0152] For the specific implementations of S702 to S704, please refer to the specific implementations of S605 to S607.
[0153] It should be understood that Figure 7 is an example of an attack business module, but in reality it could also be an attack input management module or a vehicle control agent module, etc.
[0154] It should be understood that the way the business module forwards the first instruction to the management module as shown in Figures 6 and 7 is just an example, and there may be other forwarding methods in practice.
[0155] As can be seen from Figures 6 and 7, the generation process of the first instruction in the external attack scenario is different from that in the user input operation scenario. The generation process of the first instruction in the external attack scenario lacks steps S601 to S603.
[0156] S502. Obtain first information according to the first instruction, wherein the first information is associated with the state of at least one feature of the first device.
[0157] In one possible implementation, the first information is associated with the state of at least one feature of the first device in the form that the first information includes (or) the state of the at least one feature.
[0158] In another possible implementation, the first information is associated with the state of at least one feature of the first device in the following specific form: the first information is used to indicate whether the second device performs a first operation. Here, the first information is determined based on the state of at least one feature of the first device. For example, if the state of at least one feature satisfies a preset rule, the first information instructs the second device to perform the first operation; if the state of at least one feature does not satisfy the preset rule, the first information instructs the second device not to perform the first operation.
[0159] If the first command is triggered by user input, then the user's input will cause the state of at least one feature of the smart cockpit to change, and the changed state of at least one feature can satisfy a preset rule. If the first command is triggered by an attacker impersonating a user, then the state of at least one feature of the smart cockpit will not change, and the preset rule will not be satisfied. Therefore, the state of at least one feature can be obtained to verify whether the first command was triggered by a user.
[0160] In this application embodiment, the feature type can be various, including but not limited to one or more of the following types: hardware, interrupt, message, file, memory, and program. The following describes each of these types of features:
[0161] 1. Hardware refers to the hardware devices deployed in the smart cockpit, such as human-machine interface or devices related to human-machine interface, including but not limited to microphone, display screen, touch screen, buttons, knobs, T-Box, etc.
[0162] The status of the hardware, such as the pixel status of the display screen, the communication status of the T-Box, etc.
[0163] 2. Interrupts include hardware interrupts (or hard interrupts) and / or software interrupts (or soft interrupts).
[0164] Hardware interrupts include, for example, interrupts generated when a touchscreen is touched by a user, interrupts generated when a microphone receives voice input, interrupts generated when a button is touched, and so on.
[0165] Software interrupts include, for example, interrupts triggered by specific interrupt instructions (such as INT 3, INT 8, INTO, etc.) generated by applications in the smart cockpit (such as vehicle control applications in the entertainment domain).
[0166] 3. Messages may include messages sent by the smart cockpit to other components inside the vehicle or to the outside of the vehicle (such as controller area network (CAN) messages), or messages received from other components inside the vehicle or from the outside of the vehicle (such as Ethernet messages).
[0167] 4. The files include system files in the smart cockpit or files generated by third-party applications.
[0168] Files such as system logs. File types such as cache, log, etc.
[0169] 5. Memory refers to the internal storage of the intelligent cockpit, or the data stored in the internal storage of the intelligent cockpit.
[0170] The memory status, such as whether SELinux (a mandatory access control security system) is disabled.
[0171] 6. Programs refer to the programs running in the smart cockpit, such as applications running in the entertainment domain.
[0172] The program's state includes, for example, the application's running state and the communication status between the application and the server.
[0173] The above types of features are merely examples and are not limited to these in practice.
[0174] In a specific example, taking the hardware architecture shown in Figure 2 as an example, obtaining the first information according to the first instruction may include: the processor obtaining the first information according to the first instruction.
[0175] In a specific example, taking the software architecture shown in Figure 3A, Figure 3B, Figure 4A, or Figure 4B as an example, obtaining the first information according to the first instruction may include: the management module obtaining the first information according to the first instruction.
[0176] For example, if the management module and the observation module are two separate modules, the process by which the management module obtains the first information according to the first instruction can be shown in S608-S609 of Figure 6 or S705-S706 of Figure 7:
[0177] S608. The management module can send a first request to the observation module according to the first instruction. The first request is used to request first information from the observation module.
[0178] S609. The observation module collects the status of at least one feature from the business module according to the first request, and sends first information to the management module according to the status of at least one feature. The management module receives the first information.
[0179] For example, the first request may carry indication information of at least one feature, the observation module obtains the status of at least one feature based on the indication information, and sends the first information to the management module based on the status of at least one feature.
[0180] For example, the first request may include a preset rule corresponding to the first instruction. The observation module obtains the status of at least one feature according to the preset rule and sends the first information to the management module according to the status of at least one feature.
[0181] For example, the first request may include a first instruction, the observation module determines a preset rule based on the first instruction, the observation module obtains the status of at least one feature based on the preset rule, and sends first information to the management module based on the status of at least one feature.
[0182] The specific implementations of S705 to S706 in Figure 7 can be referenced from the specific implementations of S608 to S609.
[0183] If the management module and the observation module are the same module, the management module can collect the status of at least one feature from the business module according to the first instruction, and then send the first information to the management module according to the status of the at least one feature.
[0184] In one possible design, before executing S502, it may also include: determining that the first instruction is a high-risk instruction, or cutting off the first operation indicated by the first instruction as a high-risk operation.
[0185] In other words, the first device acquires the first information only when the first instruction is a high-risk instruction, and then determines whether the second device should execute the first operation based on the first information. If the first instruction is a low-risk instruction, the second device can directly execute the first operation.
[0186] For example, commands such as adjusting lights, opening windows, opening doors, or changing driving modes have a significant impact on vehicle safety and can therefore be classified as high-risk commands. Commands such as adjusting volume or changing songs have a smaller impact on vehicle safety and can therefore be classified as low-risk commands. Of course, these are just examples, and the actual classification of high-risk and low-risk commands is not limited to these examples.
[0187] In a specific example, taking the hardware architecture shown in Figure 2 as an example, the processor obtains the first information only when it determines that the first instruction is a high-risk instruction.
[0188] In a specific example, taking the software architecture shown in Figure 3A, Figure 3B, Figure 4A, or Figure 4B as an example: when the management module determines that the first instruction is a high-risk instruction, it sends a first request to the observation module to obtain the first information; when the management module determines that the first instruction is a low-risk instruction, it can directly send the first instruction to the second device.
[0189] This design approach takes into account the large variety of commands in a smart cockpit and the frequent triggering of these commands. Therefore, it only performs verification on high-risk commands, which can save computing resources and reduce device power consumption while ensuring vehicle safety performance.
[0190] S503. Determine whether the second device should perform the first operation based on the first information.
[0191] In one specific implementation, if the first information includes (or is) the state of at least one feature, then determining whether the second device performs the first operation based on the first information may include: if the state of at least one feature satisfies a preset rule, then determining that the second device performs the first operation; if the state of at least one feature does not satisfy the preset rule, then determining that the second device does not perform the first operation.
[0192] In another specific implementation, if the first information is used to indicate whether the second device performs the first operation, then determining whether the second device performs the first operation based on the first information may include: if the first information indicates that the second device performs the first operation, then determining that the second device performs the first operation; if the first information indicates that the second device does not perform the first operation, then determining that the second device does not perform the first operation.
[0193] In a specific example, taking the hardware architecture shown in Figure 2 as an example, determining whether the second device performs the first operation based on the first information may include: the processor determining whether the second device performs the first operation based on the first information.
[0194] In a specific example, taking the software architecture shown in Figure 3A, Figure 3B, Figure 4A, or Figure 4B as an example, determining whether the second device performs the first operation based on the first information may include: the management module determining whether the second device performs the first operation based on the first information.
[0195] In a specific example, taking the software architecture shown in Figure 4A as an example, determining whether the second device performs the first operation based on the first information may include: the vehicle control agent module determining whether the second device performs the first operation based on the first information. For example, after receiving the first information, the management module forwards the first information to the vehicle control service module, and the vehicle control service module determines whether the second device performs the first operation.
[0196] Optionally, if it is determined that the second device performs the first operation, information instructing the second device to perform the first operation can be sent to the second device.
[0197] For example, the management module or vehicle control service module sends the first instruction to the second device, causing the second device to perform the first operation. For example, step S610 in the example given in Figure 6: The management module sends the first instruction to the second device.
[0198] For example, the management module or vehicle control service module signs the first instruction and sends the first instruction carrying the signature to the vehicle control application in the entertainment domain, so that the vehicle control application sends the first instruction carrying the signature to the second device (the specific sending path is not limited), so that the second device executes the first operation.
[0199] To better understand the above solution, taking the software architecture shown in Figure 4A as an example, Figure 8 illustrates a specific interaction process between modules, including the following steps:
[0200] S801: After receiving the first instruction from the entertainment domain, the vehicle control service module forwards the first instruction to the management module.
[0201] S802. The management module determines whether the first example is a high-risk instruction. If it is a high-risk instruction, then execute S803.
[0202] If it is not a high-risk instruction, the management module or vehicle control agent module can send the first instruction directly to the second device, so that the second device can perform the first operation;
[0203] S803, The management module sends a first request to the observation module to request first information, and the observation module receives the first request;
[0204] The content of the first request and the first information is described above and will not be repeated here.
[0205] S804. The observation module collects the status of at least one feature and feeds back first information to the management module based on the status of at least one feature. The management module receives the first information.
[0206] The state of at least one feature is described above and will not be repeated here.
[0207] S805. The management module determines whether the second device performs the first operation based on the first information. If yes, then S806 is executed.
[0208] S806, The management module sends the first instruction to the second device, causing the second device to perform the first operation.
[0209] Optionally, S805 to S806 can be replaced by S807 to S809:
[0210] S807, The management module forwards the first information to the vehicle control service module, and the vehicle control service module receives the first information;
[0211] S808, The vehicle control service module determines whether the second device performs the first operation based on the first information. If yes, then S809 is executed.
[0212] S809, the vehicle control service module sends the first instruction to the second device, causing the second device to perform the first operation.
[0213] If the management module (or vehicle control service module) determines that the second device will not perform the first operation, the management module (or vehicle control service module) may choose not to perform any operation, and the process will end. Optionally, the management module (or vehicle control service module) may discard the first instruction.
[0214] Optionally, the management module (or vehicle control service module) can also send alerts to the business modules, enabling the business modules (and vehicle control applications) in the entertainment domain to notify the user that the smart cockpit has been attacked through the human-machine interface. Specific alert formats include, but are not limited to, displaying images or text prompts on the screen, and broadcasting voice prompts through the speaker.
[0215] In the above scheme, after detecting a first instruction used to instruct a second device of the vehicle to perform a first operation, the first device (such as a smart cockpit) can acquire first information and determine whether the second device performs the first operation based on the first information. Since the first information is related to the state of at least one feature of the first device, the state of at least one feature when the first instruction is triggered by user input will be different from the state of at least one feature when the first instruction is triggered by an attacker impersonating a user. Therefore, based on the first information, it is possible to verify whether the first instruction is triggered by user input, thereby identifying whether the smart cockpit has been attacked, and effectively preventing attackers from using the smart cockpit's body control functions after the smart cockpit has been compromised. This can improve vehicle safety performance and protect the personal and privacy safety of users.
[0216] In one possible design, the state of at least one feature is related to the triggering method of the first instruction.
[0217] Specifically, there can be multiple ways for a user to perform an input operation, meaning there can be multiple ways to trigger the first instruction. Different triggering methods can cause different feature states to change, or different triggering methods can cause the same feature to change its state in different ways. Therefore, different triggering methods can correspond to different features or different combinations of features, and correspondingly, the preset rules that the states of these features need to satisfy can also be different.
[0218] Here are some possible examples:
[0219] 1. The first instruction is triggered by clicking the screen.
[0220] Touch-to-touch triggering refers to the method by which a user touches an electronic screen (such as a central control screen) to trigger the first command. The state of at least one feature includes, but is not limited to, at least one of the following:
[0221] 1) Pixel status of the display screen. Pixel status can refer to pixel characteristics, such as pixel values.
[0222] Accordingly, the preset rules may include the pixel state of the display screen satisfying the first feature.
[0223] Taking the example of a user clicking a corresponding control on the central control screen, the central control screen includes a display screen and a touch screen. The touch screen is used to receive user operations (such as clicking a control) and generate an interrupt, while the display screen is used to display pixels (such as displaying the control). After the user clicks a control, the pixels within a preset range at the location of the clicked control will change. Therefore, the value of the pixel at the control's location on the display screen is detected to determine whether the value is within the preset range. If it is within the preset range, it indicates that a real user has performed a click operation on the central control screen.
[0224] 2) Touchscreen interruption status. The touchscreen interruption status can refer to whether the touchscreen is interrupted or not.
[0225] Correspondingly, the preset rules may include whether the touchscreen was interrupted within the first time period.
[0226] Taking the user clicking the corresponding control on the central control screen as an example, after the user clicks the control, the touch screen on the central control screen will generate a hardware interrupt. The first instruction should be detected within a certain period of time after the touch screen generates the interrupt. Therefore, it is possible to detect whether the touch screen has been interrupted in the first time period (such as the past 1 second). If the touch screen has been interrupted in the first time period, it can indicate that a real user has performed a click operation on the central control screen.
[0227] 3) System log file status. The system log file status can refer to the screen input records documented in the system log.
[0228] Accordingly, the preset rules may include screen input records related to the first operation in the system log during the second time period.
[0229] Generally, user actions on the central control screen are recorded in the system log. Therefore, it's possible to check if the system log contains screen input records related to the first action within a second time period (e.g., the past second). If so, it indicates that a real user performed a click operation on the central control screen.
[0230] 2. The first command is triggered by voice.
[0231] Voice triggering refers to the method by which a user inputs voice commands into the smart cockpit to trigger the first instruction. The state of at least one feature includes, but is not limited to, at least one of the following:
[0232] 1) Pixel status of the display screen. Pixel status can refer to pixel characteristics, such as pixel values.
[0233] Accordingly, preset rules may include displaying pixels related to voice display on the screen.
[0234] 2) Microphone interruption status. Microphone interruption status can refer to whether the microphone is interrupted or not.
[0235] Correspondingly, the preset rules may include the microphone being interrupted during the third time period.
[0236] 3) System log file status. The system log file status can refer to the voice input records stored in the system log.
[0237] Accordingly, the preset rules may include voice input records related to the first operation in the system log during the fourth time period.
[0238] 4) The running status of the first program. The first program can be a program related to speech parsing, and the running status of the first program can refer to the communication records between the first program and the speech parsing server.
[0239] Accordingly, the preset rules may include the traffic of the first program communicating with the speech parsing server during the fifth time period.
[0240] 3. The first instruction is triggered by a key press.
[0241] Button triggering refers to the method by which a user touches a physical button within the smart cockpit to trigger the first command. The state of at least one feature includes, but is not limited to, at least one of the following:
[0242] 1) Interruption status of a button. The interruption status of a button can refer to whether an interruption occurs or not.
[0243] Correspondingly, the preset rules may include whether the key press was interrupted within the sixth time period.
[0244] 2) System log file status. The system log file status refers to the input record of that key in the system log.
[0245] Accordingly, the preset rules may include system log entries containing key inputs within the seventh time period.
[0246] 4. The first instruction is triggered by communication.
[0247] Communication triggering refers to the method by which a user communicates with the smart cockpit using a mobile phone, key, wearable device, or other means to trigger the first command. The state of at least one characteristic includes, but is not limited to, at least one of the following:
[0248] 1) Communication status of the vehicle's T-BOX. The communication status of the T-BOX can refer to the communication data (or communication records) between the T-BOX and the CDC.
[0249] Correspondingly, the preset rules may include data from T-BOX actively communicating with CDC during the eighth time period.
[0250] 2) System log file status. The system log file status can be the business execution record related to the first operation.
[0251] Accordingly, the preset rules may include system logs containing business execution records related to the first operation within the ninth time period.
[0252] Of course, the above triggering methods and corresponding feature states are just examples, and are not limited to these in practice.
[0253] In practical applications, an instruction can have one or more possible triggering methods.
[0254] For example, users can adjust the volume by tapping controls on the screen or by speaking.
[0255] For example, users can close car windows by clicking on controls on the screen, by speaking to control the windows, or by using mobile phones, keys, or other terminal devices to remotely close the windows.
[0256] In one possible implementation, the first instruction carries indication information of the triggering method, and the state of at least one feature corresponding to the first instruction is related to the triggering method indicated by the indication information.
[0257] In another possible implementation, the state of at least one feature corresponding to the first instruction is related to all possible triggering methods of the first instruction. For example, all possible triggering methods of the first instruction are determined based on the type of the first instruction.
[0258] When the state of at least one feature is the state of multiple features, it can be determined that the first instruction was triggered by the user and the second device performs the first operation when some of the multiple features satisfy the corresponding preset rules or when the states of all the multiple features satisfy the corresponding preset rules.
[0259] For example, in conjunction with the software architecture shown in Figure 3A or Figure 3B, Table 1 provides a specific example of the operations performed by the management module and the observation module:
[0260] Table 1
[0261] Of course, Table 1 is only one possible example, and the actual situation is not limited to this.
[0262] Through the above design, the state of at least one feature can be obtained based on the triggering method of the first instruction, which can improve the accuracy of information collection, improve the reliability of the verification result of the first instruction, and further improve the safety performance of the vehicle.
[0263] The above design methods can be implemented individually or in combination without restriction.
[0264] Based on the above content and the same concept, this application embodiment also provides a control device 900. The control device 900 can be used to implement the functions of the management module or observation module in the above method embodiment, and thus can also achieve the beneficial effects of the above method embodiment.
[0265] As shown in Figure 9, the control device 900 includes a processing module 901 and a transceiver module 902.
[0266] When the control device 900 is used for the function of the management module in the above method embodiment:
[0267] The transceiver module 902 is used to detect a first instruction, which instructs a second device of the vehicle to perform a first operation; and to obtain first information based on the first instruction, wherein the first information is associated with the state of at least one feature of the first device.
[0268] The processing module 901 is also used to determine whether the second device should perform the first operation based on the first information.
[0269] In one possible design, at least one feature includes one or more of the following: hardware, interrupt, message, file, memory, and program. Of course, the above are just examples, and the actual design is not limited to these.
[0270] In one possible design, the first information includes the state of at least one feature. The processing module 901 is configured to: if the state of at least one feature satisfies a preset rule, determine that the second device performs the first operation; if the state of at least one feature does not satisfy the preset rule, determine that the second device does not perform the first operation.
[0271] In one possible design, the first information is used to indicate whether the second device performs the first operation. The processing module 901 is configured to: if the first information indicates that the second device performs the first operation, then determine that the second device performs the first operation; if the first information indicates that the second device does not perform the first operation, then determine that the second device does not perform the first operation. Specifically, the first information indicates that the second device performs the first operation when the state of at least one feature satisfies a preset rule; the first information indicates that the second device does not perform the first operation when the state of at least one feature does not satisfy the preset rule.
[0272] In one possible design, the state of at least one feature is related to the triggering method of the first instruction. For details regarding the specific design of the state of at least one feature, preset rules, etc., please refer to the relevant descriptions above; they will not be repeated here.
[0273] In one possible design, the transceiver module 902 is used to receive the first instruction from the service module.
[0274] In one possible design, the transceiver module 902 is used to obtain first information from the observation module according to the first instruction.
[0275] In one possible design, the transceiver module 902 is used to: send a first request to the observation module according to a first instruction, the first request being used to request first information from the observation module; and receive the first information from the observation module.
[0276] When the control device 900 is used to function as the observation module in the above method embodiment:
[0277] Transceiver module 902 is configured to: receive a first request, the first request being used to request first information, the first information being associated with the state of at least one feature of the first device;
[0278] Processing module 901 is used to obtain the status of at least one feature according to the first request;
[0279] The transceiver module 902 is also configured to send first information based on the state of at least one feature, the first information being used to determine whether the second device of the vehicle performs the first operation.
[0280] For details on the specific design of the state, preset rules, etc. of at least one feature, please refer to the relevant description above, which will not be repeated here.
[0281] In one possible design, the processing module 901 is used to collect the status of at least one feature from the business module according to the first request.
[0282] In one possible design, the transceiver module 902 is used to: receive a first request from the management module; and send the first information to the management module based on the status of at least one feature.
[0283] More detailed descriptions of the above-mentioned processing module 901 and transceiver module 902 can be obtained directly from the relevant descriptions in the above method embodiments, and will not be repeated here.
[0284] Based on the above content and the same concept, as shown in FIG10, this application also provides a control device 1000. The control device 1000 may include a processor 1001 and a communication interface 1002. The processor 1001 and the communication interface 1002 are coupled to each other. It is understood that the communication interface 1002 may be an interface circuit or an input / output interface. Optionally, the control device 1000 may further include a memory 1003 for storing instructions executed by the processor 1001, or storing input data required by the processor 1001 to execute instructions, or storing data generated after the processor 1001 executes instructions.
[0285] It should be understood that the processor mentioned in the embodiments of this application can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.
[0286] For example, the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.
[0287] It should be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).
[0288] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) can be integrated into the processor.
[0289] It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memories.
[0290] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium, including a program or instructions, which, when run on a computer, cause the method steps in the above method embodiments to be executed.
[0291] Based on the same technical concept, this application also provides a computer program product containing instructions, which stores instructions that, when run on a computer, cause the method steps in the above method embodiments to be executed.
[0292] Based on the foregoing and the same concept, this application provides a chip. The chip may include a processor and interface circuitry. Further, in an optional implementation, the chip may also include a memory, wherein the processor executes computer programs or instructions stored in the memory, causing the chip to perform the method steps described in the above method embodiments.
[0293] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer programs or instructions. When a computer program or instruction is loaded and executed on a computer, the processes or functions of the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).
[0294] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.
[0295] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple. In the textual description of this application, the character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the formulas of this application, the character " / " indicates that the preceding and following related objects are in a "division" relationship. Additionally, in this application, the word "exemplarily" is used to indicate an example, illustration, or explanation. Any embodiment or design described as "example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Alternatively, it can be understood that the use of the word "example" is intended to present concepts in a specific manner and does not constitute a limitation of this application.
[0296] It is understood that the various numerical designations used in this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and inherent logic. Terms such as "first," "second," and similar expressions are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, such as including a series of steps or units. A method, system, product, or device is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.
[0297] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made therein without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely illustrative examples of the solutions defined by the appended claims and are to be considered as covering any and all modifications, variations, combinations, or equivalents within the scope of this application.
[0298] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of the invention. Therefore, if these modifications and variations of the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.
Claims
1. A control method, characterized in that, A first device applied in a vehicle, the first device having a human-machine interface, the first device having an application deployed thereon, the method comprising: A first instruction is detected, the first instruction being used to instruct a second device of the vehicle to perform a first operation; First information is obtained according to the first instruction, and the first information is associated with the state of at least one feature of the first device; Based on the first information, determine whether the second device performs the first operation.
2. The method as described in claim 1, characterized in that, The at least one feature includes one or more of the following: hardware, interrupt, message, file, memory, program.
3. The method as described in claim 1 or 2, characterized in that, The first information includes the state of at least one feature; Determining whether the second device performs the first operation based on the first information includes: If the state of at least one feature satisfies a preset rule, then it is determined that the second device performs the first operation; If the state of at least one feature does not satisfy the preset rule, then it is determined that the second device will not perform the first operation.
4. The method as described in claim 1 or 2, characterized in that, The first information is used to indicate whether the second device performs the first operation; Determining whether the second device performs the first operation based on the first information includes: If the first information instructs the second device to perform the first operation, then it is determined that the second device performs the first operation; If the first information indicates that the second device does not perform the first operation, then it is determined that the second device does not perform the first operation; Wherein, when the state of at least one feature satisfies the preset rule, the first information instructs the second device to perform the first operation; when the state of at least one feature does not satisfy the preset rule, the first information instructs the second device not to perform the first operation.
5. The method as described in claim 3 or 4, characterized in that, The state of at least one feature is related to the triggering method of the first instruction.
6. The method as described in claim 5, characterized in that, The first instruction is triggered by tapping the screen; The state of at least one feature includes at least one of the following: the pixel state of the display screen, the interruption state of the touch screen, and the file state of the system log.
7. The method as described in claim 6, characterized in that, The preset rules include at least one of the following: The pixel state of the display screen satisfies the first feature; The touchscreen was interrupted during the first time period; The system log contains screen input records related to the first operation during the second time period.
8. The method as described in claim 5, characterized in that, The first instruction can be triggered by voice. The state of at least one feature includes at least one of the following: the pixel state of the display screen, the interruption state of the microphone, the file state of the system log, and the running state of the first program.
9. The method as described in claim 8, characterized in that, The preset rules include at least one of the following: The display screen shows pixels related to voice display; The microphone was interrupted during the third time period; The system log contains voice input records related to the first operation during the fourth time period; The first program has traffic communicating with the speech parsing server during the fifth time period.
10. The method as described in claim 5, characterized in that, The first instruction is triggered by a key press; The state of at least one feature includes at least one of the following: the interrupt state of the key, and the file state of the system log.
11. The method as described in claim 10, characterized in that, The preset rules include at least one of the following: The button was interrupted during the sixth time period; The system log contains input records for the key during the seventh time period.
12. The method as described in claim 5, characterized in that, The first instruction is triggered via communication. The state of at least one feature includes at least one of the following: the communication state of the vehicle's communication device T-BOX, and the file state of the system log.
13. The method as described in claim 12, characterized in that, The preset rules include at least one of the following: The T-BOX contains data that actively communicates with the cockpit domain controller CDC during the eighth time period; The system log contains business execution records related to the first operation during the ninth time period.
14. The method according to any one of claims 1-13, characterized in that, The first device includes a management module; The detection first instruction includes: the management module receiving the first instruction; The step of obtaining the first information according to the first instruction includes: the management module obtaining the first information according to the first instruction; Determining whether the second device performs the first operation based on the first information includes: The management module determines whether the second device should perform the first operation based on the first information.
15. The method as described in claim 14, characterized in that, The first device further includes a business module, in which the application is deployed, and the business module and the management module run in different domains; The management module receives a first instruction, including: The management module receives the first instruction from the business module.
16. The method as described in claim 15, characterized in that, The first device further includes an observation module, which has the authority to view the resources of the business module; The management module obtains the first information, including: The management module obtains the first information from the observation module according to the first instruction.
17. The method as described in claim 16, characterized in that, The management module obtains the first information from the observation module according to the first instruction, including: The management module sends a first request to the observation module according to the first instruction, and the first request is used to request the first information from the observation module; The observation module collects the status of at least one feature from the business module according to the first request; and sends the first information to the management module according to the status of the at least one feature. The management module receives the first information from the observation module.
18. A control method, characterized in that, A first device applied in a vehicle, the first device having a human-machine interface, the first device having an application deployed thereon, the method comprising: Receive a first request, the first request being used to request first information, the first information being associated with the state of at least one feature of the first device; The status of at least one feature is obtained according to the first request, and the first information is sent according to the status of the at least one feature. The first information is used to determine whether the second device of the vehicle performs the first operation.
19. The method as described in claim 18, characterized in that, The at least one feature includes one or more of the following: hardware, interrupt, message, file, memory, program.
20. The method as described in claim 18 or 19, characterized in that, The first information includes the state of the at least one feature; or, the first information is used to indicate whether the second device performs the first operation; Wherein, when the state of at least one feature satisfies the preset rule, the second device performs the first operation; when the state of at least one feature does not satisfy the preset rule, the second device does not perform the first operation.
21. The method as described in claim 20, characterized in that, The state of at least one feature includes at least one of the following: the pixel state of the display screen, the interruption state of the touch screen, and the file state of the system log.
22. The method as described in claim 21, characterized in that, The preset rules include at least one of the following: The pixel state of the display screen satisfies the first feature; The touchscreen was interrupted during the first time period; The system log contains screen input records related to the first operation during the second time period.
23. The method as described in claim 20, characterized in that, The state of at least one feature includes at least one of the following: the pixel state of the display screen, the interruption state of the microphone, the file state of the system log, and the running state of the first program.
24. The method as described in claim 23, characterized in that, The preset rules include at least one of the following: The display screen shows pixels related to voice display; The microphone was interrupted during the third time period; The system log contains voice input records related to the first operation during the fourth time period; The first program has traffic communicating with the speech parsing server during the fifth time period.
25. The method as described in claim 20, characterized in that, The state of at least one feature includes at least one of the following: the interrupt state of the key, and the file state of the system log.
26. The method as described in claim 25, characterized in that, The preset rules include at least one of the following: The button was interrupted during the sixth time period; The system log contains input records for the key during the seventh time period.
27. The method as described in claim 20, characterized in that, The state of at least one feature includes at least one of the following: the communication state of the vehicle's communication device T-BOX, and the file state of the system log.
28. The method as described in claim 27, characterized in that, The preset rules include at least one of the following: The T-BOX contains data that actively communicates with the cockpit domain controller CDC during the eighth time period; The system log contains business execution records related to the first operation during the ninth time period.
29. The method according to any one of claims 18-28, characterized in that, The first device includes an observation module; Receiving the first request includes: the observation module receiving the first request; The step of obtaining the status of at least one feature according to the first request and sending the first information according to the status of at least one feature includes: the observation module obtaining the status of at least one feature according to the first request, and the observation module sending the first information according to the status of at least one feature.
30. The method as described in claim 29, characterized in that, The first device further includes a business module, the application is deployed in the business module, and the observation module has permission to view the business module; The observation module obtains the state of at least one feature according to the first request, including: The observation module collects the status of at least one feature from the business module according to the first request.
31. The method as described in claim 29 or 30, characterized in that, The first device also includes a management module; The method further includes: the management module detecting a first instruction, the first instruction being used to instruct the second device to perform the first operation; and sending the first request to the observation module according to the first instruction; The observation module receiving the first request includes: the observation module receiving the first request from the management module; The observation module sends the first information according to the state of at least one feature, including: the observation module sends the first information to the management module according to the state of at least one feature; The method further includes: the management module receiving the first information from the observation module, and determining whether the second device performs the first operation based on the first information.
32. A control device, characterized in that, It includes modules for implementing the method as described in any one of claims 1-17, or modules for implementing the method as described in any one of claims 18-31.
33. A control device, characterized in that, The device includes a processor connected to a memory for storing a computer program, the processor for executing the computer program stored in the memory such that the method as claimed in any one of claims 1-17 is performed, or the method as claimed in any one of claims 18-31 is performed.
34. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions that, when executed by a control device, cause the method as described in any one of claims 1-17 to be performed, or cause the method as described in any one of claims 18-31 to be performed.
35. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a control device, cause the method as described in any one of claims 1-17 to be performed, or cause the method as described in any one of claims 18-31 to be performed.
Citation Information
Patent Citations
Method and device for controlling intelligent space based on vehicle cabin
CN113525266A
Intelligent cabin control method, device, equipment and medium
CN115285139A
Automobile rest mode control method and device, vehicle and storage medium
CN115447515A
Permission management method, smart cabin, vehicle, and storage medium
WO2024031971A1