Vehicle state estimation-based application security mode switching system and method
The vehicle state estimation-based system autonomously adjusts security modes based on vehicle state, addressing resource inefficiencies and vulnerabilities by prioritizing critical functions during security-risk states, ensuring rapid response and optimized resource use.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- HYOLIMXE CO LTD
- Filing Date
- 2025-10-23
- Publication Date
- 2026-05-21
AI Technical Summary
Existing vehicle security mode switching systems consume unnecessary system resources, experience delays and reduced response speeds, and are susceptible to security vulnerabilities due to excessive operating system intervention and passive application state change notifications.
A vehicle state estimation-based system that includes a hypervisor managing high-security and low-security OSs, with a security mode switching logic module that autonomously adjusts application priorities and functions based on vehicle status, using a high-security OS to collect real-time data and a reactive API for applications to query and act on security states.
Enhances vehicle safety by rapidly switching to security modes in emergency situations, optimizing resource use, and reducing vulnerabilities by prioritizing critical functions during security-risk states.
Smart Images
Figure KR2025016948_21052026_PF_FP_ABST
Abstract
Description
Vehicle State Estimation-Based Application Security Mode Switching System and Method
[0001] The present invention relates to a security mode switching technology for a vehicle application, and more specifically, to a vehicle state estimation-based application security mode switching system that enables an application to autonomously switch security modes based on changes in the vehicle state.
[0002] The operating system (OS) of a connected car has a structure that manages tasks based on authority and priority when processing messages or requests to enhance vehicle security.
[0003] In particular, when application requests or messages within the vehicle system relate to hardware resources, processing is performed by considering hardware access safety, real-time performance, and priority-based policies. This structure ensures that requests directly related to vehicle safety are processed preferentially and is designed to guarantee safety in various situations that may occur during driving.
[0004] In this regard, AUTOSAR (AUTomotive Open System ARchitecture) defines standards for vehicle software architecture and presents structural requirements for real-time performance and priority processing. Through an architecture that enables applications to respond in real-time to vehicle conditions, AUTOSAR allows each application to enhance safety and security tailored to the vehicle state.
[0005] Furthermore, UNECE R155 and R156 regulations serve as standards for vehicle cybersecurity and software update management, providing guidelines to ensure security and priority in the process of request access and message delivery. These regulations require the establishment of a Cybersecurity Management System (CSMS) and a Software Update Management System (SUMS) to guarantee the safety of vehicle systems, and present criteria for distinguishing between functions directly related to vehicle safety—such as braking, steering, and collision avoidance systems—and other functions, enabling the switching of security modes as needed.
[0006] Various approaches have been taken to set priorities or permissions for in-vehicle messages and requests. Among these, a method has been applied in which the operating system transmits vehicle status information to applications to dynamically switch security modes depending on the situation, in order to prevent the system from becoming overloaded due to excessive requests from the operating system.
[0007] For example, as a real-time operating system, QNX provides a mechanism for applications to detect and respond to changes in the system's state. However, QNX also relies on the system directly notifying of state changes or on applications explicitly requesting the state and receiving a response.
[0008] Furthermore, the AUTOSAR Adaptive Platform presents a standard for vehicle software architecture and provides a structure that enables applications to recognize and respond to vehicle status; however, this is also primarily based on the method by which operating systems or systems notify applications of state changes.
[0009] The problems with these conventional technologies are as follows. First, system resources are unnecessarily consumed due to excessive intervention by the operating system. In a structure where applications passively accept state changes, the operating system must notify the status individually, which can increase the system load. Second, delays and reduced response speeds occur due to state transitions. Problems may arise where the operating system fails to respond quickly to emergency situations during the process of recognizing state changes and notifying applications. Third, the likelihood of security vulnerabilities increases. The operating system becomes more susceptible to malicious attacks as it handles frequent requests and responses, and vulnerabilities may occur during the communication process.
[0010] The present invention was developed to resolve the problems of the prior art and aims to provide a methodology that effectively performs the switching of a vehicle's security mode while simultaneously ensuring the autonomy of the application and the efficiency of system resources.
[0011] More specifically, the invention provides a method in which an application actively estimates the security status of a vehicle without excessive intervention by the operating system, switches security modes as needed to increase resource efficiency, and enables a rapid response in emergency situations.
[0012] To achieve the above objectives, the vehicle state estimation-based application security mode switching system according to the present invention comprises: a hypervisor that virtualizes and executes one or more operating systems; and a high-security OS and a low-security OS that execute on the hypervisor.
[0013] At this time, the hypervisor controls the switching of security modes of in-vehicle applications according to changes in the vehicle's security status, and a security mode switching logic module that sets a high priority for applications directly related to safety in a security-risk state; and
[0014] A security mode setting template module that stores predefined security mode switching rules according to vehicle status and provides a template for specifying application priority and function activation / deactivation in security-risk and non-risk states;
[0015] The above security mode switching logic module includes an application priority adjustment module that adjusts the operation priority of applications when switching to a security mode and sets the priority of applications directly related to safety high in a security-risk state; and an application function activation / deactivation module that activates functions directly related to safety and deactivates non-risk applications in a security-risk state when switching to a security mode.
[0016] The above-mentioned high-security OS collects vehicle status data in real time, periodically checks the security status, and transmits a security mode switching request to the security mode switching logic module of the above-mentioned hypervisor.
[0017] At this time, when the security state transitions to a security-risk state, the security mode switching logic module automatically sets the priority of applications directly related to safety in the high-security OS to the highest level and temporarily suspends or restricts the functions of non-risk applications.
[0018] At this time, the security mode setting template module manages the operation priority and activation status of each application according to predefined settings based on the security-risk state and non-risk state, and the security mode switching logic module automatically adjusts the priority and function of each application to match the vehicle's security state according to the settings.
[0019] Meanwhile, the aforementioned high-security OS provides the current security status in real time to applications that query the vehicle's status via a reactive API, allowing the applications to autonomously adjust their operations based on the security status.
[0020] Meanwhile, to achieve the above-mentioned purpose, the vehicle state estimation-based application security mode switching method according to the present invention comprises the step of a high-security OS collecting vehicle state data in real time and periodically evaluating the security state;
[0021] A step of collecting vehicle status data from a sensor interface through a vehicle status data collection module;
[0022] A step of verifying the validity of collected data and storing it;
[0023] A step in which the application calls a reactive API module to query the security status;
[0024] A step in which the reactive API module queries and returns the current security status;
[0025] A step of evaluating the security status into a secure-risk state or a non-risk state and returning it;
[0026] A step of periodically checking the current security status through a periodic status check module;
[0027] A step in which a periodic status check module checks whether there is a change in state;
[0028] A step of sending a security mode transition request to a security mode transition logic module when a state change is detected;
[0029] A step of determining the priority and whether to enable / disable functions of each application according to predefined security mode switching rules by referring to a security mode setting template module;
[0030] In a security-risk state, a step of setting high priority for applications directly related to security and disabling non-critical applications; and
[0031] It includes a step of optimizing the efficiency of system resources by enabling or disabling the functions of each application according to the security status upon switching the security mode.
[0032] At this time, when the security state transitions to a security-risk state, the security mode switching logic module automatically sets the priority of applications directly related to safety running on the high-security OS to the highest level, and temporarily suspends or restricts the functions of non-critical applications.
[0033] At this time, the security mode setting template module manages the operation priority and function activation status of each application according to predefined settings based on the security-risk state and non-risk state, and the security mode switching logic module automatically adjusts the priority and function of each application to match the vehicle's security state according to the settings.
[0034] At this time, the high-security OS includes a step of providing the security status in real time to an application that queries the current security status through a reactive API, and allowing the application to autonomously adjust its operation according to the security status.
[0035] According to the present invention, by autonomously switching the security mode of an in-vehicle application according to changes in the vehicle state, it is possible to simultaneously secure the safety and resource efficiency of the vehicle system.
[0036] In particular, the high-security OS collects vehicle status data in real time and periodically evaluates the security status, thereby rapidly switching the security mode through a security mode switching logic module as soon as a security-risk state of the vehicle is detected, which has the effect of improving vehicle safety.
[0037] Furthermore, the security mode switching logic module automatically raises the priority of applications directly related to safety and disables non-risk applications, thereby concentrating system resources on essential security-risk functions during security-risk states, which prevents resource waste and optimizes efficiency.
[0038] In particular, since the reactive API module allows applications to autonomously query the current security status and perform actions appropriate to that status, it ensures the independence and autonomy of the application and has the effect of improving the system's response speed.
[0039] FIG. 1 is a block diagram showing the hierarchical structure of a vehicle state estimation-based application security mode switching system according to the present invention.
[0040] FIG. 2 is a functional block diagram showing each component of the hypervisor, high-security OS, and low-security OS according to the present invention.
[0041] Figure 3 is a flowchart illustrating the process of collecting vehicle status data and checking security status.
[0042] Figure 4 is a flowchart illustrating the security mode switching process when a change in security status is detected.
[0043] Figure 5 is a block diagram showing the interaction between the security mode setting template module and the security mode switching logic module.
[0044] Explanation of symbols
[0045] 100 : Vehicle electrical length
[0046] 200 : Hypervisor
[0047] 210: Security Mode Settings Template Module
[0048] 220: Security Mode Switching Logic Module
[0049] 221: Application Priority Adjustment Module
[0050] 222 : Application feature enable / disable module
[0051] 230: Sensor interface for vehicle status data collection
[0052] 300: High-security OS
[0053] 310: Vehicle Status Data Collection Module
[0054] 320 : Reactive API Module
[0055] 330: Periodic status check module
[0056] 400: Low-security OS
[0057] Hereinafter, the present invention will be described in detail with reference to preferred embodiments of the invention and the accompanying drawings, under the premise that identical reference numerals in the drawings refer to identical components.
[0058] When a component is described as "comprising" another component in the detailed description of the invention or the claims, this shall not be interpreted as being limited to being composed solely of said component unless specifically stated otherwise, but shall be understood as potentially including additional components.
[0059] Additionally, components named as "~means," "~part," "~module," or "~block" in the detailed description of the invention or the claims refer to units that process at least one function or operation, and each of these may be implemented by software or hardware, or a combination thereof.
[0060] The vehicle state estimation-based application security mode switching system according to the present invention will be described below with reference to the attached drawings.
[0061] FIG. 1 is a block diagram showing the hierarchical structure of a vehicle state estimation-based application security mode switching system according to the present invention.
[0062] The vehicle electronics (100) is a high-level component that includes various electronic devices and systems within the vehicle and is responsible for the overall electronic control and communication of the vehicle. The vehicle electronics is directly connected to the hypervisor (200), and all data and commands within the vehicle are managed through the hypervisor (200).
[0063] The hypervisor (200) is a layer that virtualizes and runs a high-security OS (300) and a low-security OS (400) within the vehicle's electrical system (100). The hypervisor (200) coordinates resource allocation and communication between the two operating systems and dynamically manages the security state of the system through a security mode switching logic module (220).
[0064] The high-security OS (300) is an operating system responsible for functions directly related to the safety of the vehicle, and performs a core role of collecting vehicle status data and managing security modes. On the other hand, the low-security OS (400) is an operating system that runs applications with a low security level, such as entertainment and general communication, and operates independently from the high-security OS.
[0065] FIG. 2 is a functional block diagram showing each component of the hypervisor, high-security OS, and low-security OS according to the present invention.
[0066] The high-security OS (300) is equipped with a vehicle status data collection module (310), a reactive API module (320), and a periodic status check module (330).
[0067] The vehicle status data collection module (310) is implemented within the high-security OS (300) and collects vehicle status data in real time. This module collects and analyzes various data, such as the vehicle's speed, engine temperature, and brake status, through the sensor interface (230).
[0068] The reactive API module (320) provides an interface that allows the application to check the current security status of the vehicle. Through this, the application can check the security status at the necessary time and perform actions accordingly without excessive intervention by the operating system.
[0069] The periodic status check module (330) operates in the background within the high-security OS (300) and calls the reactive API module (320) at regular intervals to check the current status of the vehicle. When this module detects a change in status, it adjusts the security mode through the security mode switching logic module (220).
[0070] Meanwhile, the hypervisor (200) is equipped with a security mode setting template module (210), a security mode switching logic module (220), and a sensor interface (230) for collecting vehicle status data.
[0071] The security mode setting template module (210) provides a predefined security mode switching pattern for each application of each operating system. This module specifies the action to be taken when an application reaches a specific security state through a template file in XML or JSON format.
[0072] The security mode switching logic module (220) is located within the hypervisor (200) and performs the role of switching to an appropriate security mode according to the vehicle status. This module switches the security mode based on the settings provided by the security mode setting template module (210) through the application priority adjustment module (221) and the application function enable / disable module (222).
[0073] The application priority adjustment module (221) adjusts the operation priority of the application when switching to a security mode, increasing the priority of safety-related applications in a security-risk state and lowering the priority of applications in a non-risk state.
[0074] The application function enable / disable module (222) enables or disables the functions of specific applications when switching to a security mode, so that only the necessary functions are executed depending on the security state. For example, in a security-risk state, entertainment applications are disabled and safety-related applications are enabled.
[0075] The sensor interface (230) for collecting vehicle status data serves to collect data from various sensors within the vehicle's electrical system (100). This interface receives sensor data through a vehicle network such as a CAN bus or Ethernet and transmits it to a vehicle status data collection module (310).
[0076] In this context, a security-risk state refers to a condition in which an in-vehicle application or system is exposed to security risks from external or internal threats. In this state, there is a high likelihood that the vehicle's data integrity, confidentiality, and availability will be compromised, thereby requiring a transition to a security mode.
[0077] A non-risk state refers to a condition where in-vehicle applications or systems are not currently exposed to security threats or have a very low probability of exposure. In this state, switching to a security mode is not necessary, and normal operations can continue.
[0078] The operation of the system according to the present invention is performed as follows.
[0079] A virtualized high-security OS (300) and a low-security OS (400) are run on a hypervisor (100). A vehicle status data collection module (310), a reactive API module (320), and a periodic status check module (330) are implemented within the high-security OS (300), and the low-security OS (400) runs entertainment and general communication applications.
[0080] Referring to the functional block diagram illustrated in FIG. 2, the hypervisor (200) manages the security status of the system through a security mode setting template module (210) and a security mode switching logic module (220). Data collected through a sensor interface (230) for collecting vehicle status data is processed by a vehicle status data collection module (310), and an application can query the current security status through a reactive API module (320).
[0081] The periodic status check module (330) checks the vehicle status at regular intervals and transmits changes in the security status to the security mode switching logic module (220). The security mode switching logic module (220) switches the security mode based on the settings provided by the security mode setting template module (210) through the application priority adjustment module (221) and the application function enable / disable module (222).
[0082] Through this, the application can autonomously estimate the vehicle status without excessive intervention from the operating system, and switch security modes accordingly to increase the efficiency of system resources and respond quickly in emergency situations.
[0083] Hereinafter, with reference to FIGS. 3 to 5, we will examine a method for switching application security modes based on vehicle state estimation according to an example of the present invention.
[0084] Figure 3 is a flowchart illustrating the process of collecting vehicle status data and checking security status.
[0085] In the vehicle status data collection request step (S11), the vehicle status is collected through the hypervisor (200) via the vehicle status data collection module (310) of the high-security OS (300) within the vehicle. This request is a periodic operation performed by the high-security OS (300) to secure various status information of the vehicle and prepare basic data for subsequent security mode switching.
[0086] In the vehicle state data collection step (S12) through the sensor interface, the vehicle state data collection module (310) collects sensor data from the vehicle electrical system (100) through the sensor interface (230) of the hypervisor (200). The sensor interface (230) obtains data related to the state of the vehicle through an in-vehicle network such as a CAN bus or Ethernet. The data collected here includes information such as the vehicle's current speed, engine temperature, brake status, and fuel level, which serves as important basic data for determining the vehicle's driving condition and security status.
[0087] In the collected data verification and storage step (S13), the vehicle state data collection module (310) performs the task of verifying whether the collected data is valid. By evaluating the validity of the sensor data, data containing errors or noise is filtered out, or errors are corrected and stored. The verified data is stored within the high-security OS (300) and can be referenced when checking the security status thereafter.
[0088] In the application's security status inquiry request step (S14), after collecting vehicle status data, a specific application calls the reactive API module (320) when necessary to query the current security status. For example, an application directly related to safety during vehicle driving sends a security status inquiry request to the reactive API module (320) when it wants to check the vehicle's security status in a specific situation.
[0089] In the current security status check step (S15) via the reactive API, when the reactive API module (320) receives a request from the application, it determines the current security status by referring to the latest vehicle status data stored in the high-security OS (300). The reactive API module (320) can evaluate whether the current status is a secure-risk state or a non-risk state based on the vehicle's speed, engine temperature, and other status information.
[0090] In the security state evaluation and return step (S16), the reactive API module (320) evaluates the security state as a secure-risk state or a non-risk state based on the collected data. For example, when the vehicle is driving at high speed or the engine is overheated, it is evaluated as a secure-risk state, which allows the application to take appropriate security measures according to the current situation. The evaluated security state is returned to the calling application, enabling the application to perform actions according to the state.
[0091] In the state check step (S17) by the periodic state check module, the periodic state check module (330) calls the reactive API module (320) at regular intervals to check the current vehicle state. The periodic state check module (330) periodically checks the security state of the vehicle according to a set period and determines whether there is a change in the security state by comparing it with the previous state. Through this periodic check, it is possible to quickly detect minute changes in the vehicle state and evaluate the need to switch to a security mode.
[0092] In the state change verification step (S18), the periodic state verification module (330) verifies whether there is a state change by comparing the current security state with the previously stored security state. For example, if the previous state was a non-risk state but the current security state has changed to a security-risk state, it is determined that a security mode switch is necessary. When a state change is detected, a security mode switch request is sent to the security mode switch logic module (220). In this way, the system is prepared to immediately switch the security mode by reflecting the vehicle's state change in real time.
[0093] As a variation of the present invention, the security status can be predicted by utilizing the accumulation of vehicle status data and a machine learning algorithm.
[0094] The high-security OS (300) stores various sensor data collected through the vehicle status data collection module (310) and the history of past security status changes in a database, and this data includes various factors such as the vehicle's driving patterns, driver habits, and environmental conditions. The periodic status check module (330) is equipped with a security status prediction module to which a machine learning algorithm is applied, so as to be able to predict future security status changes based on the data collected to date.
[0095] This prediction model can detect in advance the possibility that a vehicle will transition to a security-risk state through learning from past data. When the security state prediction module predicts a probability of a security-risk state occurring above a certain level, the periodic state check module (330) sends a preemptive security mode switching request to the security mode switching logic module (220). This is intended to prepare for potential risks by switching the security mode in advance before an actual security-risk state occurs, and the security mode switching logic module (220) collaborates with the security mode setting template module (210) to apply a security mode suitable for the predicted security state.
[0096] In this process, machine learning algorithms improve the accuracy and efficiency of security mode switching through continuous learning. For example, if a security-risk state occurs repeatedly on a specific road section, the system can be optimized to switch the security mode in advance before entering that section. Furthermore, changes in security status and the results of security mode switching during actual vehicle operation are utilized as training data for the machine learning model, allowing the prediction model to be continuously updated and further enhancing the accuracy of security status predictions.
[0097] Referring to FIGS. 4 and 5 below, a process of automatically switching the security mode of an in-vehicle application when the security status of the vehicle changes, and controlling the operation of the application according to the security-risk state and non-risk state by referring to a predefined security mode setting template is described.
[0098] FIG. 4 is a flowchart showing the security mode switching process when a security state change is detected, and FIG. 5 is a block diagram showing the interaction between the security mode setting template module and the security mode switching logic module.
[0099] In the step (S21) of calling the security mode switching logic upon detection of a state change, if the periodic state check module (330) detects that a change in the vehicle's security state has occurred, the security mode switching logic module (220) is called. This step confirms that the security state has transitioned from a non-risk state to a security-risk state; for example, if the vehicle's speed exceeds a specific threshold or the engine temperature rises, it may be classified as a security-risk state. As illustrated in FIG. 5, the security mode switching logic module (220) then interacts with the security mode setting template module (210) to set the vehicle's security mode.
[0100] In the security mode setting template reference step (S22), the security mode switching logic module (220) refers to the security mode setting template module (210) located within the hypervisor (200) to check the operation priority and function activation status of each application in the security-risk state and non-risk state. As illustrated in FIG. 5, the security mode setting template module (210) includes a template in which necessary security mode switching rules are predefined according to the driving state of the vehicle or the security state of the vehicle.
[0101] In the security mode switching execution step (S23), based on the setting information provided by the security mode setting template module (210), the security mode switching logic module (220) switches the security mode of the system to a security-risk state. In this step, functions directly related to safety are configured to operate with the highest priority, and entertainment or general communication functions required only in a non-risk state are switched to a disabled state.
[0102] In the application priority adjustment step (S24), the security mode switching logic module (220) calls the application priority adjustment module (221) to increase the priority of applications performing functions directly related to safety in a security-risk state and to decrease the priority of applications performing non-critical functions. For example, the priority of vehicle control functions while driving is adjusted to the highest level, and entertainment functions are switched to a standby state.
[0103] In the application function activation / deactivation step (S25), the security mode switching logic module (220) adjusts the function of a specific application to the security state through the application function activation / deactivation module (222). As illustrated in FIG. 5, in the security-risk state, the vehicle control function is activated, and other non-risk applications are switched to a deactivated state.
[0104] In the new security mode application step (S26), the security mode switching logic module (220) applies the switched security mode to the entire system, causing in-vehicle applications to operate according to the new security mode. This maintains the stability and security of the vehicle in a security-risk state and enables real-time security response according to the vehicle driving situation.
[0105]
[0106] The technical concept of the present invention has been examined through the above examples.
[0107] It is obvious that a person skilled in the art to which the present invention pertains can make various modifications or changes to the embodiments described above from the description of the present invention. Furthermore, it is obvious that a person skilled in the art to which the present invention pertains can make various modifications including the technical concept according to the present invention from the description of the present invention, even if not explicitly illustrated or described, and such modifications still fall within the scope of the rights of the present invention. The embodiments described above with reference to the accompanying drawings are described for the purpose of explaining the present invention, and the scope of the rights of the present invention is not limited to these embodiments.
Claims
1. A hypervisor that virtualizes and executes one or more operating systems; and a high-security OS and a low-security OS that run on the hypervisor, wherein The above hypervisor controls the switching of security modes of in-vehicle applications according to changes in the vehicle's security status, and includes a security mode switching logic module that sets a high priority for applications directly related to safety in a security-risk state; and A security mode setting template module that stores predefined security mode switching rules according to vehicle status and provides a template for specifying application priority and function activation / deactivation in security-risk and non-risk states; The above security mode switching logic module includes an application priority adjustment module that adjusts the operation priority of applications when switching to a security mode and sets the priority of applications directly related to safety high in a security-risk state; and an application function activation / deactivation module that activates functions directly related to safety and deactivates non-risk applications in a security-risk state when switching to a security mode. A vehicle state estimation-based application security mode switching system characterized by the above-mentioned high-security OS collecting vehicle state data in real time, periodically checking the security state, and transmitting a security mode switching request to the security mode switching logic module of the above-mentioned hypervisor.
2. A method for executing on a hypervisor that virtualizes and executes one or more operating systems, including a high-security OS, wherein A step in which a high-security OS collects vehicle status data in real time and periodically evaluates the security status; A step of collecting vehicle status data from a sensor interface through a vehicle status data collection module; A step of verifying the validity of collected data and storing it; A step in which the application calls a reactive API module to query the security status; A step in which the reactive API module queries and returns the current security status; A step of evaluating the security status into a secure-risk state or a non-risk state and returning it; A step of periodically checking the current security status through a periodic status check module; A step in which a periodic status check module checks whether there is a change in state; A step of sending a security mode transition request to a security mode transition logic module when a state change is detected; A step of determining the priority and whether to enable / disable functions of each application according to predefined security mode switching rules by referring to a security mode setting template module; In a security-risk state, a step of setting high priority for applications directly related to security and disabling non-critical applications; and A method for switching application security modes based on vehicle state estimation, comprising the step of optimizing the efficiency of system resources by activating or deactivating the functions of each application according to the security state based on the security mode switching.
3. In Paragraph 2, A method for switching application security modes based on vehicle state estimation, characterized by including a step in which the above-mentioned high-security OS provides the security state in real time to an application that queries the current security state through a reactive API, and allows the application to autonomously adjust its operation according to the security state.