System State-Based Software Monitoring Method, Apparatus, and System

Abstract

The present invention relates to a technology for monitoring software, and provides a system state-based software monitoring method, apparatus, and system comprising a configuration that classifies whether a process of a monitored vehicle control system is a critical process, determines whether it is normal based on a preset threshold, and collects state data and adjusts the threshold based on the data when it is determined to be abnormal, in order to prevent functional safety violations caused by process delays and overruns occurring in a multi-core and multi-threaded environment in a control system of an autonomous or automated vehicle, and to improve the monitoring accuracy and recovery efficiency of the software by reflecting internal and external state changes of the system in real time.

Description

Technology Field

[0001] The present invention relates to a technology for monitoring software. Background Technology

[0002] The vehicle's electronic control unit processes multiple processes in parallel based on multi-core and multi-threading, and each process must execute normally within a set cycle. However, process execution may be delayed or overrun due to various factors, such as changes in system load or external communication delays, which directly affects the vehicle's control stability.

[0003] Traditionally, AUTOSAR PHM (Process Health Monitoring) was commonly used to monitor the alive and deadline status of processes. However, this method relied on fixed thresholds and failed to reflect internal system load or changes in the external environment; furthermore, because it monitored all processes using the same criteria, it suffered from issues such as false positives, missed detections, and reduced efficiency. The problem to be solved

[0004] The present invention is proposed to solve the aforementioned problems and aims to provide a system state-based software health monitoring method and apparatus that prevent functional safety violations caused by process delays and overruns resulting from multi-core and multi-threaded environments in control systems of autonomous or automated vehicles, and improve software monitoring accuracy and recovery efficiency by reflecting internal and external state changes of the system in real time.

[0005] More specifically, the objectives of the present invention are as follows.

[0006] First, it ensures functional safety by applying monitoring standards differentially according to importance.

[0007] Second, it is to prevent false positives and missed detections.

[0008] Third, it is to simultaneously ensure the stability of vehicle control and resource efficiency.

[0009] Accordingly, the present invention aims to provide software health monitoring technology for autonomous or automated vehicles that adaptively responds to changes in system state to improve the monitoring reliability and recovery control efficiency of the process. means of solving the problem

[0010] A software health monitoring method according to one embodiment of the present invention may include a process classification step for classifying whether a process of a monitored vehicle control system is a pre-set critical process; a normality determination step for monitoring the process and determining whether it is normal based on a pre-set threshold; a state collection step for collecting internal and external state data of the vehicle control system when the process is determined to be abnormal and not classified as a critical process; and a determination condition adjustment step for adjusting the threshold for a process not classified as a critical process based on the collected state data.

[0011] In one embodiment, the process may further include a recovery execution step for performing recovery when the process is classified as a critical process and determined to be abnormal.

[0012] In one embodiment, the recovery execution step may perform one or more of the following: process restart, switching to fail-safe mode, and resource reallocation.

[0013] In one embodiment, the process classification step may set processes related to vehicle driving stability and control safety as important processes.

[0014] In one embodiment, the normality determination step can determine normality based on a threshold, which is a preset fixed value, for a process classified as an important process.

[0015] In one embodiment, the state collection step may collect state data including one or more of an internal load rate and an external communication throughput when the process is not classified as a critical process and the measured value of the process exceeds a preset threshold.

[0016] In one embodiment, the determination condition adjustment step may be set to 100% or more and 200% or less of the existing threshold when the threshold is adjusted.

[0017] In one embodiment, the determination condition adjustment step may set a different threshold when performing an Over-The-Air (OTA) update and set it to return to the existing threshold after the update is completed.

[0018] A software health monitoring device according to one embodiment of the present invention may include a monitoring unit that determines the signal generation period and response status of a process running in a vehicle system based on a preset threshold and monitors it at a preset time interval; a process classification unit that classifies whether the process is a preset important process; a state collection unit that collects internal and external state data of the vehicle system when the process is not classified as an important process and is determined to be abnormal; and a threshold adjustment unit that performs a determination condition adjustment to adjust the threshold for a process not classified as an important process based on the state data.

[0019] In one embodiment, the device may further include an execution management unit that controls one or more of the execution, restart, and termination of a process and determines the execution time of a probe application.

[0020] In one embodiment, the execution management unit hierarchically classifies the degree of abnormality of a process and, when the degree of abnormality is the highest, controls the system by rebooting the ECU or entering Fail-Operational mode, when the degree of abnormality is the second highest, restarts the corresponding process, and when the degree of abnormality is the lowest, records a log and performs QoS adjustment.

[0021] A software health monitoring system according to one embodiment of the present invention may include a vehicle that performs autonomous driving functions and executes various control applications in an AUTOSAR Adaptive platform environment, a processor on which a process based on an AUTOSAR Adaptive Application (AA) executed in the vehicle control system operates, and a health monitoring device that monitors the process.

[0022] In one embodiment, the health monitoring device may include a monitoring unit that determines the signal generation period and response status of a process running in a vehicle system based on a preset threshold and monitors it at a preset time interval; a process classification unit that classifies whether the process is a preset important process; a state collection unit that collects internal and external state data of the vehicle system when the process is determined to be abnormal and not classified as an important process; and a threshold adjustment unit that performs a determination condition adjustment to adjust the threshold for a process not classified as an important process based on the collected state data. Effects of the invention

[0023] According to the present invention, process delay or overrun problems caused by multi-core and multi-thread environments in a control system of an autonomous or automated vehicle can be minimized, and functional safety and adaptability of the software can be simultaneously secured through dynamic threshold adjustment reflecting the internal and external state of the system.

[0024] First, safety can be enhanced by securing a dual monitoring system. It ensures the stability of driving control and safety-related functions, and secures adaptability to changes in system state by applying variable threshold-based monitoring.

[0025] Second, adaptability is enhanced. It enables real-time recovery and can reduce unnecessary false positives and false negatives by reflecting internal and external conditions such as CPU load, memory usage, and network throughput.

[0026] Third, efficient utilization of system resources is possible. The present invention automatically adjusts monitoring conditions for processes of relatively low importance according to the system load status, thereby minimizing unnecessary fault reporting and recovery operations, preventing resource waste, and improving the operational efficiency of the overall system.

[0027] Fourth, it has excellent standard compatibility. It can be easily applied to existing AUTOSAR Adaptive platforms without separate structural changes, and can be extended to various vehicle control systems and ECU environments through standardized interfaces.

[0028] The effects of the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description below. Brief explanation of the drawing

[0029] FIGS. 1a and FIGS. 1b are block diagrams illustrating a system state-based software health monitoring device according to an embodiment of the present invention. FIG. 2 is a flowchart illustrating the operation flow of a software health monitoring device according to an embodiment of the present invention. FIG. 3 is a flowchart showing the operating mechanism of a software health monitoring device according to an embodiment of the present invention. FIG. 4 is a flowchart showing a recovery operation procedure when a process abnormality occurs in a software health monitoring device according to an embodiment of the present invention. FIG. 5 is a flowchart illustrating the procedure of a recovery action policy of a software health monitoring device according to another embodiment of the present invention. FIG. 6 is a flowchart illustrating a procedure for correcting a threshold in a software health monitoring device according to another embodiment of the present invention. FIG. 7 is a flowchart illustrating a dynamic threshold prediction and adjustment procedure in a software health monitoring device according to another embodiment of the present invention. FIG. 8 is a flowchart illustrating a procedure for adjusting inspection criteria in a software health monitoring device according to another embodiment of the present invention. FIG. 9 is a flowchart illustrating a system state-based software health monitoring method according to an embodiment of the present invention. FIG. 10 is a block diagram showing a computer system for implementing a method according to an embodiment of the present invention. Specific details for implementing the invention

[0030] The aforementioned objectives of the present invention, as well as other objectives, advantages, and features, and the methods for achieving them, will become clear from the embodiments described in detail below together with the accompanying drawings.

[0031] However, the present invention is not limited to the embodiments disclosed below but can be implemented in various different forms, and the following embodiments are provided merely to easily inform those skilled in the art of the purpose, structure, and effects of the invention, and the scope of the rights of the present invention is defined by the description in the claims.

[0032] Meanwhile, the terms used in this specification are for describing the embodiments and are not intended to limit the invention. In this specification, the singular form includes the plural form unless specifically stated otherwise in the text. As used in this specification, "comprises" and / or "comprising" do not exclude the presence or addition of one or more other components, steps, actions, and / or elements to the mentioned components, steps, actions, and / or elements.

[0034] The present invention relates to a system state-based software health monitoring method and apparatus. It enables the simultaneous securing of functional safety and resource utilization efficiency by differentially managing Alive / Deadline thresholds according to the importance of processes in a multi-core and multi-threaded automotive control environment, and dynamically adjusting thresholds by reflecting the internal and external states of the system.

[0035] The software health monitoring device according to the present invention classifies processes into time-critical and non-time-critical processes and performs different recovery policies and threshold management policies according to each level of importance. Time-critical processes are those that directly affect driving safety and control stability; they must comply with fixed Alive / Deadline thresholds defined during design and perform immediate recovery operations when an anomaly is detected. At this time, the recovery operation is carried out by means such as restarting the process, switching to fail-safe mode in the event of a failure, or reallocating resources.

[0036] In contrast, non-time-critical processes are those that allow for relatively long delays, dynamically adjusting Alive / Deadline thresholds based on the system's internal state (CPU load, memory usage, task execution time, etc.) and external state (network bandwidth, communication throughput, etc.). Through this, non-time-critical processes can manage recovery and monitoring criteria in a flexible manner, such as extending cycles, adjusting priorities, and increasing delay tolerances.

[0037] In addition, the present invention measures the load rate and actual threshold in real time through a probe application. When the load rate of a non-time-critical process increases above a certain standard, the probe application is executed to measure the system's response time and resource consumption, and adjusts the Alive / Deadline threshold based on the measurement results. This enables the system to adapt to dynamic load conditions in the actual operating environment and minimizes unnecessary false positives and false negatives. Specific configurations and various embodiments will be described below with reference to the drawings.

[0038] FIGS. 1a and FIGS. 1b are block diagrams illustrating a system state-based software health monitoring device according to an embodiment of the present invention.

[0039] Referring to FIG. 1a, the system status-based software health monitoring device (100) includes a communication unit (110), a storage unit (120), a control unit (130), an output unit (140), and an interface (150). It is also configured to be connected to an external server (50) via an external network to enable data transmission and reception.

[0040] The communication unit (110) is responsible for communication with an external server (50) or an internal vehicle network and transmits and receives Alive / Deadline status data, recovery commands, or threshold update information. The communication unit (110) may include a wired / wireless communication module and exchanges external data and control signals in an internal vehicle communication network (e.g., CAN, Ethernet, LIN, etc.) and OTA (Over-The-Air) communication environment.

[0041] The storage unit (120) stores Alive / Deadline threshold setting values, process status data, system logs, and past load pattern data required for the operation of the control unit (130). The storage unit (120) includes non-volatile memory (ROM, Flash Memory, etc.) and volatile memory (RAM), and may be equipped with training data or a prediction model.

[0042] The output unit (140) is configured to display or transmit the judgment result or recovery operation status of the control unit (130), and transmits information such as monitoring results, abnormal occurrence notifications, and recovery status to a display device or vehicle network.

[0043] The interface (150) is an input means for a user to change system settings or control the state of the control unit (130), and is linked with sensor data, external diagnostic equipment, or driver input device.

[0044] Referring to FIG. 1b, the control unit (130) includes a monitoring unit (131), a process classification unit (133), a status collection unit (135), an execution management unit (137), and a threshold adjustment unit (139).

[0045] The monitoring unit (131) monitors the Alive signal generation cycle and Deadline response status of each process running in the system in real time. In the event of an anomaly, it calls a recovery procedure according to the importance (Time-Critical / Non-Time-Critical) of the process and records the monitoring results in the storage unit (120).

[0046] The process classification unit (133) classifies each process into a time-critical process or a non-time-critical process. In this case, the time-critical process includes functions that directly affect driving stability and control safety (e.g., braking control, steering control, etc.), and the non-time-critical process includes functions for which a relative delay is allowed (e.g., transmission of diagnostic logs, processing of infotainment data, etc.).

[0047] The state collection unit (135) collects internal and external states to generate reference data for dynamic threshold adjustment. The internal state includes CPU load rate, memory usage rate, task execution time, etc., and the external state includes communication status such as throughput relative to network bandwidth.

[0048] The execution management unit (137) controls the execution, restart, or termination of the process and determines the execution time of the probe application. Additionally, when a recovery action occurs, time-critical processes immediately restart or switch to fail-safe mode, and non-time-critical processes extend the Alive / Deadline period or adjust the priority.

[0049] The threshold adjustment unit (139) dynamically adjusts the Alive / Deadline threshold of a non-time-critical process based on internal and external status information input from the status collection unit (135). At this time, the threshold is corrected to match the actual load conditions by reflecting the measurement results of the probe application, and the adjusted threshold is transmitted to the monitoring unit (131) and applied as a monitoring standard for the platform health management unit.

[0050] Accordingly, the system state-based software health monitoring device (100) of the present invention according to FIG. 1a and FIG. 1b has a communication unit (110), a storage unit (120), a control unit (130), an output unit (140), and an interface (150) that are organically linked, and the monitoring unit (131), process classification unit (133), state collection unit (135), execution management unit (137), and threshold adjustment unit (139) within the control unit (130) cooperate to monitor the system state and perform recovery and threshold adjustment according to process importance, thereby ensuring functional safety and adaptability simultaneously.

[0051] FIG. 2 is a flowchart illustrating the operation flow of a software health monitoring device according to one embodiment of the present invention.

[0052] Referring to FIG. 2, the software health monitoring device is composed of a first adaptive application (210), a second adaptive application (220), a probe application (230), a platform health management unit (240), a state management unit (250), and an execution management unit (260), and these components monitor the state of the system and perform recovery while transmitting and receiving data to and from each other.

[0053] The first adaptive application (210) and the second adaptive application (220) are application software implemented in an AUTOSAR adaptive platform environment, and each periodically generates an Alive / Deadline Trigger (hereinafter Alive / Deadline Trigger) for a process and transmits it to the platform health management unit (240). The Alive Trigger is a signal indicating that the process is periodically running normally, and the Deadline Trigger is used as a criterion indicating whether a specific task has been completed within a specified time. In addition, the first adaptive application (210) and the second adaptive application (220) perform a Time-Critical Check to determine whether the process is Time-Critical, determine whether the process is a Time-Critical process or a Non-Time-Critical process upon execution, and transmit the result to the Process Classification Module of the State Management Unit (250). At this time, the survival / delay trigger cycle, communication delay limit (Timeout) value, etc. are included and set as threshold items. The platform health management unit (240) monitors the trigger signals received from the first and second adaptive applications (210, 220) and detects an abnormal state of the process when the set survival cycle or deadline is exceeded.

[0054] The probe application (230) is application software that is executed when the threshold of a non-time-critical process reaches 50% or more of a set value, and measures internal and external system status to provide reference data for dynamic threshold adjustment. The probe application (230) transmits a decoy trigger to the platform health management unit (240) and experimentally verifies whether the system maintains Alive / Deadline under actual load conditions. It is also executed periodically according to a probe start command (hereinafter probe start) transmitted from the execution management unit (260), measures internal and external status data including CPU load rate, memory usage rate, and throughput relative to network bandwidth, and transmits the measured information to the status management unit (250). In the present invention, by using this probe application (230) to measure the system load rate in real time, the Alive / Deadline threshold can be dynamically corrected rather than statically maintained.

[0055] The platform health management unit (240) is configured to perform overall survival / deadline monitoring of the system by adopting the structure of the platform health management module (hereinafter PHM) defined in the AUTOSAR standard. The platform health management unit (240) manages survival / deadline triggers received from the first and second adaptive applications (210, 220) and decoy triggers received from the probe application (230). When an abnormal state exceeding the set Alive / Deadline threshold is detected, the platform health management unit (240) transmits a recovery action request (hereinafter recovery action) to the state management unit (250). At this time, while the PHM of the AUTOSAR standard includes logical supervision, the present invention adopts only the survival / deadline monitoring function, and uses only the recovery action signal transmission structure, rather than the internal logic of the PHM, for the system configuration description. In addition, the platform health management unit (240) generates threshold update (Update Threshold, hereinafter threshold update) data to update the survival / deadline threshold by reflecting internal and external status data received from the status management unit (250), and applies this to the Alive / Deadline monitoring module to correct the monitoring criteria in real time. That is, it performs some of the functions of the monitoring unit in FIG. 1.

[0056] The state management unit (250) performs different recovery procedures based on the importance of the process (time-critical or non-time-critical) according to the recovery operation command and threshold update data transmitted from the platform health management unit (240). The state management unit (250) internally includes a Process Classification Module, a State Collection Module, and a Dynamic Threshold Adjustment Module.

[0057] During initial setup, the process classification module categorizes each process into either a Time-Critical Process or a Non-Time-Critical Process. Time-critical processes are directly related to the vehicle's driving stability and control safety; examples include functions such as braking control and steering control. Conversely, non-time-critical processes are those where relative delays are permitted, such as functions not directly related to safety, like diagnostic log transmission and infotainment data processing.

[0058] The state collection module collects internal and external state data to provide reference information for dynamic threshold adjustment. Internal state includes CPU load, memory usage, and task execution time, while external state includes communication-related data such as throughput relative to network bandwidth.

[0059] The dynamic threshold adjustment module corrects the Alive / Deadline thresholds of non-time-critical processes based on data collected from the state collection module, and transmits the corrected thresholds to the platform health management unit (240) to update the monitoring criteria of PHM in real time. For time-critical processes, the fixed Alive / Deadline thresholds defined at the time of design must be strictly observed, and arbitrary adjustments are not allowed. For non-time-critical processes, the Alive / Deadline thresholds are dynamically changed according to system load or external network conditions.

[0060] Additionally, the state management unit (250) performs a recovery strategy according to the importance of the process when an anomaly occurs through the internally included Recovery Action Module. For time-critical processes, immediate responses such as immediate restart, switching to Fail-safe Mode in case of failure, and resource reallocation are performed. On the other hand, for non-time-critical processes, flexible recovery such as period extension, priority adjustment, and delay tolerance expansion is performed. In this process, the state management unit (250) controls the execution state by transmitting a probe start command or an application restart command to the execution management unit (260). That is, it performs some of the functions of the process classification unit, state collection unit, and threshold adjustment unit in FIG. 1.

[0061] The execution management unit (260) is configured by adopting the structure of the Execution Management module (EM) of the AUTOSAR standard and controls the execution, restart (Restart, hereinafter Restart), termination, and probe run (Probe Run, hereinafter Probe Run) of a process. The execution management unit (260) executes a probe application (230) according to a command transmitted from the state management unit (250) to measure system load data, and restarts the first or second adaptive application (210, 220) if necessary. In addition, it controls the entire system to return stably by verifying the execution status of each application after an anomaly recovery and transmitting a normal state signal to the state management unit (250). That is, it performs some of the functions of the threshold adjustment unit in FIG. 1.

[0062] Referring to FIG. 2, a software health monitoring system according to another embodiment of the present invention comprises a vehicle, a vehicle control system mounted on the vehicle, and a processor on which an AUTOSAR Adaptive Application (AA) based process executed in the vehicle control system is operated.

[0063] The health monitoring system is configured to simultaneously ensure the functional safety and resource utilization efficiency of the system by monitoring the Alive / Deadline status of each process during the operation of the vehicle control system and performing different recovery and threshold adjustment procedures according to the criticality (Time-Critical or Non-Time-Critical) of the process.

[0064] Specifically, the health monitoring system may be configured as a system that includes a software health monitoring device comprising a first adaptive application (210), a second adaptive application (220), a probe application (230), a platform health management unit (240), a state management unit (250), and an execution management unit (260), and includes all AUTOSAR Adaptive Application-based processes operating within a vehicle and a vehicle control system.

[0065] The vehicle is a vehicle that performs autonomous driving or advanced driver assistance (ADAS) functions, in which multiple electronic control units (ECUs) are interconnected via a network, and the vehicle control system consists of a computing platform that executes various control applications in an AUTOSAR Adaptive platform environment.

[0066] Vehicle control systems include time-critical processes directly related to driving stability and control safety, and non-time-critical processes where relative delays are permitted. Time-critical processes are applied to core vehicle control functions (e.g., braking control, steering control, body posture control, etc.), while non-time-critical processes perform auxiliary functions such as diagnostics, infotainment, communications management, and OTA updates.

[0067] The health monitoring system integrally manages these various processes, monitors the Alive / Deadline status of each process to determine if an anomaly has occurred, and performs immediate or flexible recovery measures based on the criticality of the process in the event of an anomaly. Furthermore, by dynamically adjusting the Alive / Deadline thresholds of non-time-critical processes based on internal system conditions (CPU load, memory usage, etc.) and external conditions (network bandwidth, communication delay, etc.), it enhances the stability and adaptability of the entire system.

[0068] FIG. 3 is a flowchart showing the operating mechanism of a software health monitoring device according to an embodiment of the present invention.

[0069] Referring to FIG. 3, the operating mechanism (300) of the software health monitoring device according to the present invention is composed of a process classification unit (310), a state collection unit (320), and a dynamic threshold adjustment unit (330) operating in conjunction with each other. In particular, the state collection unit (320) includes an internal state measurement unit (321) and an external state measurement unit (325) to analyze the overall load status of the system in real time, and each module performs the role of updating Alive / Deadline monitoring thresholds and determining recovery policies in conjunction with the platform health management unit and the state management unit.

[0070] The process classification unit (310) performs a step of determining whether a process is a time-critical process or a non-time-critical process at the time of execution of an adaptive application (hereinafter AA). If it is determined to be a time-critical process, it is recognized as a function directly related to driving stability and control safety, and must strictly adhere to the fixed Alive / Deadline Threshold (hereinafter Alive / Deadline Threshold) defined during the design. On the other hand, if it is determined to be a non-time-critical process, a certain level of delay is allowed, so the Alive / Deadline Threshold can be variably adjusted to reflect the system load situation or communication status. The process classification unit (310) transmits these determination results to the process classification module of the state management unit so that monitoring criteria for each process are dynamically set.

[0071] The state collection unit (320) periodically measures the internal and external states of the system and provides reference data for dynamic threshold adjustment. The state collection unit (320) consists of an internal state measurement unit (321) and an external state measurement unit (325). The internal state measurement unit (321) measures the load rate, memory usage rate, task execution time, etc. of the Central Processing Unit (hereinafter CPU) to calculate the internal load rate and measures the minimum occurrence period of the Process Health Monitoring (hereinafter PHM) trigger. If the internal load rate is 50% or higher, the trigger threshold is increased, and if it is less than 50%, the existing initial value is maintained.

[0072] The external state measurement unit (325) measures the bandwidth and throughput of the network, calculates the external load rate, and measures the minimum communication timeout time. If the external load rate is 50% or higher, the communication timeout threshold is increased, and if it is less than 50%, the existing threshold value is maintained. The state collection unit (320) integrates the data obtained through these internal and external measurement processes to determine the overall load level of the system, and if necessary, uses the execution management unit to execute a decoy application or a probe application to measure load data complementarily. The probe application is activated when the Alive / Deadline threshold of a non-time-critical process exceeds a set ratio, and performs the function of periodically measuring system response delay, CPU and memory usage, network throughput, etc.

[0073] The dynamic threshold adjustment unit (330) adjusts the survival / deadline threshold of non-time-critical processes based on internal and external status data collected by the status collection unit (320) and transmits it to the platform health management unit (PHM) to update the monitoring criteria in real time. The dynamic threshold adjustment unit (330) limits the threshold adjustment range to within 200% of the initial design value to maintain system stability. That is, by controlling the monitoring criteria of the PHM so that they are not excessively changed even if the system load state fluctuates rapidly, the system is prevented from falling into an unstable state.

[0074] The dynamic threshold adjustment unit (330) updates the PHM Trigger Threshold and the Communication Timeout Threshold, respectively, using the measurement results, and transmits the updated values ​​to the upper PHM module for use. The updated thresholds are applied as new reference values ​​in subsequent monitoring cycles, so that Alive / Deadline monitoring of non-time-critical processes responds adaptively to system load.

[0075] Accordingly, the software health monitoring device of the present invention according to FIG. 3 determines the importance of a process in the process classification unit (310), measures internal and external loads in the state collection unit (320), and updates thresholds in the dynamic threshold adjustment unit (330), thereby ensuring stability for time-critical processes based on fixed standards and flexibly adjusting monitoring standards for non-time-critical processes according to the system state. With this configuration, the system minimizes false positives and false negatives, and simultaneously secures the functional safety and adaptability of the entire control system. FIG. 3 is a flowchart illustrating the operation mechanism of a software health monitoring device according to an embodiment of the present invention.

[0076] Referring to FIG. 3, the operating mechanism (300) of the software health monitoring device according to the present invention is composed of a process classification unit (310), a state collection unit (320), and a dynamic threshold adjustment unit (330) operating in conjunction with each other. In particular, the state collection unit (320) includes an internal state measurement unit (321) and an external state measurement unit (325) to analyze the overall load status of the system in real time, and each module performs the role of updating Alive / Deadline monitoring thresholds and determining recovery policies in conjunction with the platform health management unit and the state management unit.

[0077] The process classification unit (310) performs a step of determining whether a process is a time-critical process or a non-time-critical process at the time of execution of an adaptive application (hereinafter AA). If it is determined to be a time-critical process, it is recognized as a function directly related to driving stability and control safety, and must strictly adhere to the fixed Alive / Deadline Threshold (hereinafter Alive / Deadline Threshold) defined during the design. On the other hand, if it is determined to be a non-time-critical process, a certain level of delay is allowed, so the Alive / Deadline Threshold can be variably adjusted to reflect the system load situation or communication status. The process classification unit (310) transmits these determination results to the process classification module of the state management unit so that monitoring criteria for each process are dynamically set.

[0078] The state collection unit (320) periodically measures the internal and external states of the system and provides reference data for dynamic threshold adjustment. The state collection unit (320) consists of an internal state measurement unit (321) and an external state measurement unit (325). The internal state measurement unit (321) measures the load rate, memory usage rate, task execution time, etc. of the Central Processing Unit (hereinafter CPU) to calculate the internal load rate and measures the minimum occurrence period of the Process Health Monitoring (hereinafter PHM) trigger. If the internal load rate is 50% or higher, the trigger threshold is increased, and if it is less than 50%, the existing initial value is maintained.

[0079] The external state measurement unit (325) measures the bandwidth and throughput of the network, calculates the external load rate, and measures the minimum communication timeout time. If the external load rate is 50% or higher, the communication timeout threshold is increased, and if it is less than 50%, the existing threshold value is maintained. The state collection unit (320) integrates the data obtained through these internal and external measurement processes to determine the overall load level of the system, and if necessary, uses the execution management unit to execute a decoy application or a probe application to measure load data complementarily. The probe application is activated when the Alive / Deadline threshold of a non-time-critical process exceeds a set ratio, and performs the function of periodically measuring system response delay, CPU and memory usage, network throughput, etc.

[0080] The dynamic threshold adjustment unit (330) adjusts the survival / deadline threshold of non-time-critical processes based on internal and external status data collected by the status collection unit (320) and transmits it to the platform health management unit (PHM) to update the monitoring criteria in real time. The dynamic threshold adjustment unit (330) limits the threshold adjustment range to within 200% of the initial design value to maintain system stability. That is, by controlling the monitoring criteria of the PHM so that they are not excessively changed even if the system load state fluctuates rapidly, the system is prevented from falling into an unstable state.

[0081] The dynamic threshold adjustment unit (330) updates the PHM Trigger Threshold and the Communication Timeout Threshold, respectively, using the measurement results, and transmits the updated values ​​to the upper PHM module for use. The updated thresholds are applied as new reference values ​​in subsequent monitoring cycles, so that Alive / Deadline monitoring of non-time-critical processes responds adaptively to system load.

[0082] Accordingly, the software health monitoring device of the present invention according to FIG. 3 determines the importance of a process in the process classification unit (310), measures internal and external loads in the state collection unit (320), and updates the threshold in the dynamic threshold adjustment unit (330), thereby ensuring stability for time-critical processes based on fixed standards and allowing the monitoring standards for non-time-critical processes to be flexibly adjusted according to the system state. With this configuration, the system minimizes false positives and false negatives, and simultaneously ensures the functional safety and adaptability of the entire control system.

[0083] FIG. 4 is a flowchart showing a recovery operation procedure when a process abnormality occurs in a software health monitoring device according to an embodiment of the present invention.

[0084] FIG. 4 is a flowchart illustrating a recovery operation procedure when a process abnormality occurs in a software health monitoring device according to an embodiment of the present invention. Referring to FIG. 4, the recovery operation procedure when a process abnormality occurs in a software health monitoring device includes a recovery (410) for a time-critical process and a recovery (420) for a non-time-critical process.

[0085] The recovery procedure is initiated when an anomaly exceeding a set threshold is detected during the Alive / Deadline monitoring performed by the Platform Health Management (PHM). If the Alive signal of a monitored process does not occur within a specified period, or if there is no response after the Deadline time has expired, the PHM determines a Supervision Fault and calls a Recovery Action to the State Management (SM). This process is based on the monitoring and recovery call procedures defined in the AUTOSAR standard; however, the present invention excludes the standard monitoring logic of the PHM and focuses only on operations following the recovery execution.

[0086] Recovery (410) for a time-critical process is executed when the process is classified as time-critical after a recovery operation command is executed from the PHM. At this time, the system immediately restarts the process and restores the normal execution state prior to the occurrence of the anomaly. If immediate recovery is not possible or there is no normal response even after restarting, the process is switched to a fail-safe mode to maintain core functions at a minimum. Additionally, the stability of the entire system is ensured by recovering resources such as the Central Processing Unit (CPU), memory, and network bandwidth occupied by the problematic process and reallocating them to a process that is operating normally. In other words, recovery (410) for a time-critical process is performed in the order of "Process Restart → Fail-safe Switch → Resource Reallocation," which is an immediate response procedure to ensure the driving stability and control safety of the vehicle.

[0087] Recovery (420) for non-time-critical processes is executed after a recovery operation command is performed from the PHM and the process is classified as non-time-critical. At this time, the system first extends the Alive / Deadline cycle to prevent false positives caused by temporary load or communication delays. Subsequently, during the recovery (420) for non-time-critical processes, the scheduling priority is adjusted to avoid interfering with the execution of time-critical processes, and at the same time, the delay allowance is expanded to ensure normal monitoring is maintained even during periods of system load fluctuation. During this process, the recovery (420) for non-time-critical processes is not immediately interrupted but is flexibly restored according to changes in the system environment.

[0088] During normal operation, if no abnormalities occur, the "maintain normal operation" state is maintained. When an abnormality occurs, the system determines whether the process is a time-critical process and then performs a recovery procedure through each recovery path (410, 420). Once recovery is complete, the system returns to a normal state and resumes Alive / Deadline monitoring of the PHM.

[0089] Accordingly, the software health monitoring device of the present invention according to FIG. 4 calls a recovery action of the state management unit (SM) for an Alive / Deadline violation detected by the PHM, and applies different recovery policies according to the importance of the process, thereby ensuring safety through immediate restart and fail-safe transition in the case of recovery (410) for time-critical processes, and ensuring adaptability through extension of the Alive / Deadline period and priority adjustment in the case of recovery (420) for non-time-critical processes. With this configuration, the present invention can simultaneously achieve stable operation of the vehicle control system and prevent false positives and false negatives.

[0090] FIG. 5 is a flowchart illustrating the procedure of a recovery action policy of a software health monitoring device according to another embodiment of the present invention.

[0091] Referring to FIG. 5, the procedure of the hierarchical recovery policy includes a step of checking for abnormal occurrence, a step of determining the level of abnormality (520), a step of adjusting performance control (QoS) (530), a step of restarting the process, and a step of entering a fail-operational mode (540) when the electronic control unit (ECU) reboots or fails.

[0092] The recovery procedure is initiated when a process anomaly is detected during the Platform Health Management (PHM) process of performing Alive / Deadline monitoring. The PHM identifies an anomaly as a case where an Alive event does not occur within a set period or a response is delayed due to a Deadline timeout, and requests a Recovery Action from the State Management (SM). In this invention, the Recovery Action is not limited to a simple reset; instead, a hierarchical recovery policy is implemented to respond stepwise according to the level of the anomaly, thereby preventing unnecessary system shutdowns and improving functional safety.

[0093] First, in the abnormal occurrence verification step, the system determines whether an abnormality exists in the monitored process. If no abnormality is found, the system maintains normal operation, and if an abnormality is detected, it proceeds to the next step. Subsequently, in the abnormality level determination step (520), the detected abnormality is classified as a minor abnormality, a moderate abnormality, or a severe abnormality.

[0094] If a minor anomaly is detected, the system records a log and enters the Quality of Service (QoS) adjustment stage (530). In the QoS adjustment stage (530), the scheduling priority, resource allocation, or Alive / Deadline threshold of the process is finely adjusted to alleviate system load and prevent unnecessary recovery operations. These measures are intended to respond to temporary anomalies caused by momentary network delays or increased CPU load while driving.

[0095] If the anomaly is determined to be at a moderate level, the system restarts the relevant process. During the process restart phase, the problematic application software is re-executed to restore it to a normal state, and Alive / Deadline monitoring is resumed. Since this process restart is performed without rebooting the entire ECU, partial recovery is possible while maintaining the system's real-time control functions.

[0096] If the abnormality is determined to be severe, the system proceeds to the Electronic Control Unit Rebooting or Fail-Operational Mode entry stage (540). ECU rebooting is performed when partial recovery is impossible due to severe software errors or conflicts between processes, and the entire system is initialized to return to a stable state. Meanwhile, Fail-Operational Mode is a mode that maintains core control functions even during ECU rebooting; for example, in the case of an autonomous vehicle, recovery is performed while maintaining essential safety functions, such as steering and braking, to a minimum level.

[0097] After passing through each recovery step, the system maintains a normal operating state or returns to a fully recovered state. At this point, the recovery completion signal is transmitted to the PHM via the State Management Unit (SM), and the PHM resumes Alive / Deadline monitoring.

[0098] Accordingly, the software health monitoring device of the present invention according to FIG. 5 performs a differentiated recovery policy based on the degree of abnormality after detecting a process abnormality, thereby responding to minor abnormalities with a log recording and performance control (QoS) adjustment step (530), performing a process unit restart for moderate abnormalities, and simultaneously ensuring the safety and continuity of the system through an ECU reboot or a Fail-Operational mode entry step (540) for severe abnormalities. Through this configuration, unnecessary interruption of the entire system can be prevented, and the functional safety of an autonomous or automated vehicle can be maintained.

[0099] FIG. 6 is a flowchart illustrating a procedure for correcting a threshold in a software health monitoring device according to another embodiment of the present invention.

[0100] Referring to FIG. 6, the procedure for correcting the threshold includes a normal process execution step (610), a probe task execution step (620), a resource consumption measurement step (630), a measurement result analysis step (640), an Alive / Deadline reset step (650), a delay tolerance adjustment step (660), and a normal operation step (670).

[0101] In the normal process execution phase (610), the Alive / Deadline monitoring of the currently running process is maintained while the system is running normally. All processes generate an Alive signal within a set period and monitor whether the response is completed within the Deadline.

[0102] In the probe task execution step (620), a probe task is executed periodically to test the system's response performance in an actual operating environment and to perform load simulation. This step predicts future load conditions by executing a separate probe application or task in addition to the normal process to respond to system loads that change in real time.

[0103] In the resource consumption measurement step (630), the system's response time and resource consumption are measured while performing a probe application or probe task. Specifically, CPU usage, memory occupancy, communication processing latency, network bandwidth usage, etc., are collected.

[0104] In the measurement result analysis step (640), the data obtained in the resource consumption measurement step (630) is analyzed to evaluate the current state of the system. The analysis results are expressed in the form of CPU and memory load rates, network throughput, Alive / Deadline response distributions, etc., and are subsequently used as a standard for Alive / Deadline threshold correction.

[0105] In the Alive / Deadline reset step (650), the Alive / Deadline thresholds of non-time-critical processes are dynamically reset based on the measured data. At this time, the Alive / Deadline thresholds of time-critical processes are maintained at a fixed value to ensure stability, and only the thresholds of non-time-critical processes are adjusted according to the system load status. This reset is used to update the monitoring criteria of the Platform Health Management (PHM) in real time.

[0106] In the delay tolerance adjustment step (660), the delay tolerance is adjusted by considering the status of the network communication module. For example, if the communication bandwidth is temporarily reduced or network congestion increases, the Alive / Deadline judgment criterion time is relaxed to prevent unnecessary false positives. Conversely, if the system load is low or the network environment is stable, the delay tolerance is reduced to increase monitoring sensitivity.

[0107] Finally, in the normal operation phase (670), the system continues to operate normally with the updated Alive / Deadline threshold reflected in the PHM monitoring criteria. In this phase, the normal process is executed with the threshold changed after the probe task execution applied, and the threshold correction procedure is repeated through periodic re-measurement if necessary.

[0108] Accordingly, the software health monitoring device of the present invention according to FIG. 6 can simulate future load conditions in advance by executing normal processes and probe tasks in parallel to measure system response time and resource consumption, analyzing the results to reset the Alive / Deadline thresholds of non-time-critical processes, and adjusting the latency tolerance range of network communication modules. Through this, system load can be predicted and thresholds corrected before actual problems occur, thereby ensuring system stability and adaptability simultaneously.

[0109] FIG. 7 is a flowchart illustrating a dynamic threshold prediction and adjustment procedure in a software health monitoring device according to another embodiment of the present invention.

[0110] Referring to FIG. 7, the dynamic threshold prediction and adjustment procedure includes a log record storage step (710), a usage rate measurement step (720), a history loading step (730), a model execution step (740), an anomaly detection step (750), a performance adjustment step (760), and a normal operation maintenance step (770).

[0111] The log record storage step (710) is performed by the State Collection Module and stores the system's internal state data in the form of a log. The data collected at this time includes items such as CPU load rate, memory usage rate, network processing latency, and task execution time, and is stored in a time-series format so that comparative analysis with past execution history is possible. The log record storage is utilized for training and verification of a machine learning (ML)-based prediction model performed in a subsequent step.

[0112] In the usage rate measurement step (720), the current CPU load rate and memory usage rate are measured. The measured data reflects the instantaneous load state of the system and is periodically updated by the state collection module. This step is not a simple static monitoring step, but reflects real-time load changes and is used as an input variable for the ML model.

[0113] In the history loading step (730), past execution history and pattern data are loaded. Based on the log data accumulated and stored by the state collection module, past resource usage patterns, Alive / Deadline response history, and communication delay occurrence periods are loaded. This data is used as a training dataset to define normal patterns in the ML model and to detect anomalies.

[0114] In the model execution step (740), a lightweight machine learning model (Lightweight ML Model) is executed. The model uses regression or anomaly detection techniques to predict the likelihood that the currently measured data will approach or deviate from a threshold level relative to past normal patterns. It predicts load increase trends through regression analysis or identifies abnormal load fluctuations using anomaly detection algorithms. Additionally, a lightweight ML model (e.g., regression, anomaly detection) may be incorporated and utilized.

[0115] In the abnormal sign determination step (750), the occurrence of an abnormal sign relative to the normal pattern is determined based on the prediction results of the ML model. If it is determined to be within the normal range, the system moves to the normal operation maintenance step (770), and if an abnormal sign is detected, it enters the performance adjustment step (760).

[0116] In the performance adjustment phase (760), a recovery action is performed faster than the existing threshold. In this phase, a recovery procedure is initiated at an earlier point than the existing Alive / Deadline monitoring standard in order to proactively respond to predicted abnormal situations. Specifically, a process restart, QoS adjustment, or a fail-safe mode transition is performed. Through this, stable operation of the system can be maintained even under repetitive or periodic overload situations.

[0117] The normal operation maintenance step (770) is performed when there are no abnormal signs or when the system returns to a normal state after recovery is complete. In this step, the ML model is periodically updated, and new log data is continuously received from the state collection module to improve the accuracy of threshold adjustment.

[0118] Accordingly, the software health monitoring device of the present invention according to FIG. 7 does not rely solely on simple CPU load or memory usage, but dynamically predicts and adjusts thresholds based on past execution history and pattern learning, thereby enabling stable operation even in repetitive or periodic overload situations. In addition, it improves the reliability and functional safety of the system by detecting abnormal signs early through an ML-based prediction algorithm and performing recovery operations at an earlier point than conventional threshold adjustments.

[0119] FIG. 8 is a flowchart illustrating a procedure for adjusting inspection criteria in a software health monitoring device according to another embodiment of the present invention.

[0120] Referring to FIG. 8, the procedure for adjusting the inspection criteria includes an OTA update start step (810), an Alive / Deadline inspection criteria relaxation step (820), a step for determining whether the update is complete (830), a threshold return step (840), an update maintenance step (850), and a monitoring continuation step (860).

[0121] The OTA update start step (810) is a step in which the Electronic Control Unit (ECU) or system software in the vehicle initiates an Over-The-Air (OTA) update process wirelessly. In this step, after verifying the network connection status, data integrity, and the validity of the update package, the software module update begins.

[0122] In the Alive / Deadline inspection standard relaxation stage (820), monitoring standards are relaxed to prevent false positives caused by system delays or temporary communication response degradation that may occur during the update process. Specifically, the Platform Health Management (PHM) temporarily increases the Alive / Deadline monitoring cycle or expands the Timeout standard so that response delays that may occur during the update are not judged as errors. This prevents abnormal recovery actions from occurring during the update process.

[0123] During the update execution phase, the system actually downloads and installs the software, and performs version updates and data migration for each application module. This phase takes a certain amount of time depending on the network environment and the status of ECU computational resources, and is carried out under relaxed Alive / Deadline monitoring standards.

[0124] In the update completion determination step (830), it is determined whether the update has been successfully completed. If the update is completed, the process proceeds to the threshold return step (840), and if it is still in progress, it moves to the update maintenance step (850).

[0125] The threshold return step (840) is a step in which, if the update is successfully completed, the relaxed Alive / Deadline monitoring standard is returned to the normal state standard value. After receiving the update completion signal, the PHM resets the monitoring period to the initial value and restores the Timeout limit value to the normal state.

[0126] The update maintenance phase (850) is performed while the update is still in progress and ensures that the system operates stably until the update process is terminated while maintaining relaxed monitoring standards. At this time, the PHM allows for a delay in the response of the Alive signal and prevents unnecessary restarts by temporarily disabling the Recovery Action call.

[0127] Finally, in the monitoring continuation phase (860), the normal process resumes after the update is completed, and the system is continuously monitored with the Alive / Deadline monitoring criteria applied as normal values. PHM returns to the normal monitoring loop to check the process status and verifies the stability after the update.

[0128] Accordingly, the software health monitoring device of the present invention according to FIG. 8 can simultaneously ensure system stability and continuity by temporarily relaxing the Alive / Deadline check criteria at the time of an OTA update to prevent abnormal recovery operations that may occur during the update process, and by returning to normal criteria after the update is completed. This provides the effect of suppressing unnecessary Recovery Actions while maintaining the health monitoring function of the system even during an OTA update.

[0129] FIG. 9 is a flowchart illustrating a system state-based software health monitoring method according to an embodiment of the present invention.

[0130] Referring to FIG. 9, the system state-based software health monitoring method includes a process classification step (S110), a normality determination step (S120), a state collection step (S130), and a process adjustment step (S140).

[0131] The process classification step (S110) monitors processes running within the system and classifies whether the process is a time-critical or non-time-critical process. The classification criteria are determined based on whether the process is a core function that directly affects vehicle safety, such as driving control, braking control, or steering control. Processes classified as time-critical are subject to fixed Alive / Deadline monitoring thresholds because they are directly linked to system safety, whereas non-time-critical processes allow for relative delays, so the thresholds are dynamically adjusted according to the system state.

[0132] The normality determination step (S120) is a step for determining whether each classified process is operating normally based on the Alive / Deadline monitoring results. In this step, abnormalities are detected by checking whether the Alive signal cycle has occurred and whether the response has been completed within the Deadline. If the process is in a normal state, it proceeds to the next monitoring cycle; if an abnormality is detected, a recovery procedure is applied differently depending on the importance of the process.

[0133] The state collection step (S130) is a step for collecting reference data to adjust dynamic thresholds. In this step, internal and external states are measured. Internal states include Central Processing Unit (CPU) load, memory usage, and task execution time, while external states include communication performance such as network bandwidth and throughput. The collected state information is used as a standard for adjusting the Alive / Deadline monitoring thresholds of non-time-critical processes.

[0134] The process adjustment step (S140) is a step of performing measures for time-critical processes and non-time-critical processes, respectively, based on the determination results and collected status information. In the case of time-critical processes, if an Alive / Deadline violation occurs, the process is immediately restarted, and stable recovery is performed by switching to Fail-safe mode or reallocating resources. This step of recovering time-critical processes may also be set as the recovery execution step. On the other hand, in the case of non-time-critical processes, flexible adjustment is performed by readjusting the Alive / Deadline thresholds based on internal and external status information, extending the cycle, or adjusting the priority.

[0135] Accordingly, the system state-based software health monitoring method of the present invention according to FIG. 9 classifies processes according to importance and dynamically adjusts Alive / Deadline monitoring thresholds by reflecting internal and external system states, thereby simultaneously ensuring the stability of time-critical processes and the adaptability of non-time-critical processes. Through this, the functional safety of vehicle software can be improved, and unnecessary recovery or false detection can be minimized.

[0136] FIG. 10 is a block diagram showing a computer system for implementing a method according to an embodiment of the present invention.

[0137] Referring to FIG. 10, a computer system (1300) may include at least one of a processor (1310), memory (1330), an input interface device (1350), an output interface device (1360), and a storage device (1340) that communicate via a bus (1370). The computer system (1300) may also include a communication device (1320) coupled to a network. The processor (1310) may be a central processing unit (CPU) or a semiconductor device that executes instructions stored in memory (1330) or storage device (1340). Memory (1330) and storage device (1340) may include various forms of volatile or non-volatile storage media. For example, memory may include read-only memory (ROM) and random access memory (RAM). In the embodiments of this description, memory may be located inside or outside the processor, and memory may be connected to the processor through various known means. Memory is a volatile or non-volatile storage medium of various forms, and for example, memory may include read-only memory (ROM) or random access memory (RAM).

[0138] Accordingly, embodiments of the present invention may be implemented as a method implemented on a computer or as a non-transient computer-readable medium storing computer-executable instructions. In one embodiment, when executed by a processor, the computer-readable instructions may perform a method according to at least one aspect of the present description.

[0139] The communication device (1320) can transmit or receive wired or wireless signals.

[0140] In addition, the method according to an embodiment of the present invention may be implemented in the form of program instructions that can be executed through various computer means and may be recorded on a computer-readable medium.

[0141] A computer-readable medium may include program instructions, data files, data structures, etc., either individually or in combination. Program instructions recorded on a computer-readable medium may be specially designed and configured for embodiments of the present invention, or they may be known and available to those skilled in the art of computer software. A computer-readable recording medium may include a hardware device configured to store and execute program instructions. For example, a computer-readable recording medium may be a magnetic medium such as a hard disk, floppy disk, and magnetic tape; an optical recording medium such as a CD-ROM or DVD; a magneto-optical medium such as a floptical disk; a ROM; a RAM; a flash memory, etc. Program instructions may include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer through an interpreter, etc.

[0142] Although embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements by those skilled in the art using the basic concept of the present invention as defined in the following claims also fall within the scope of the present invention.

Claims

Claim 1 A software health monitoring method comprising: a process classification step for classifying whether a process of a monitored vehicle control system is a pre-set critical process, wherein processes related to the driving stability and control safety of the vehicle are classified as said critical processes, and processes not classified as said critical processes are classified as said non-time-critical processes; a normality determination step for monitoring said processes and determining whether they are normal based on a pre-set threshold; a state collection step for collecting internal and external state data of said vehicle control system when said processes are classified as said non-time-critical processes and determined to be abnormal; and a determination condition adjustment step for correcting an Alive / Deadline threshold of said non-time-critical processes based on said state data, updating a PHM trigger threshold based on said internal state data, updating a communication timeout threshold based on said external state data, and applying the updated said PHM trigger threshold and said communication timeout threshold as new reference values ​​for a subsequent monitoring cycle. Claim 2 A software health monitoring method according to claim 1, further comprising a recovery execution step for performing recovery when the process is classified as a critical process and determined to be abnormal. Claim 3 A software health monitoring method according to paragraph 2, wherein the recovery execution step performs one or more of the following: process restart, switching to fail-safe mode, and resource reallocation. Claim 4 A software health monitoring method according to claim 1, wherein the process classification step is to set a process related to the driving stability and control safety of a vehicle as a critical process when setting the critical process. Claim 5 A software health monitoring method according to claim 1, wherein the normality determination step determines whether the process is normal based on the threshold value, which is a preset fixed value, when the process is classified as a critical process. Claim 6 A software health monitoring method according to claim 1, wherein the state collection step collects state data including one or more of an internal load rate and an external communication throughput when the process is not classified as a critical process and the measured value of the process exceeds a preset threshold. Claim 7 A software health monitoring method according to claim 1, wherein the determination condition adjustment step is such that when the threshold is adjusted, it becomes 100% or more and 200% or less of the existing threshold. Claim 8 A software health monitoring method according to claim 1, wherein the determination condition adjustment step sets the threshold differently when performing an OTA update and returns to the existing threshold when the update is completed. Claim 9 A software health monitoring device comprising: a monitoring unit that determines the signal generation period and response status of a process running within a vehicle system based on a preset threshold and monitors it at a preset time period; a process classification unit that classifies whether the process is a preset critical process, classifies processes related to the driving stability and control safety of the vehicle as critical processes, and classifies processes not classified as critical processes as non-critical processes; a state collection unit that collects internal and external state data of the vehicle system when the process is classified as a non-critical process and determined to be abnormal; and a threshold adjustment unit that corrects the Alive / Deadline threshold of the non-critical process based on the state data, updates the PHM trigger threshold based on the internal state data, updates the communication timeout threshold based on the external state data, and applies the updated PHM trigger threshold and the communication timeout threshold as new reference values ​​for a subsequent monitoring period. Claim 10 A software health monitoring device according to claim 9, further comprising an execution management unit that controls one or more of the execution, restart, and termination of the above process and determines the execution time of a probe application. Claim 11 A software health monitoring device according to claim 10, wherein the execution management unit classifies the degree of abnormality of a process hierarchically, controls the system by rebooting the ECU or entering Fail-Operational mode when the degree of abnormality is the greatest, restarts the corresponding process when the degree of abnormality is the second greatest, and records a log and performs QoS adjustment when the degree of abnormality is the lowest. Claim 12 A vehicle equipped with a vehicle control system that performs autonomous driving functions and executes various control applications in an AUTOSAR Adaptive platform environment; a processor on which a process based on an AUTOSAR Adaptive Application (AA) executed in the vehicle control system operates; and a health monitoring device for monitoring the process, wherein the health monitoring device comprises: a monitoring unit that determines the signal generation period and response status of the process running in the vehicle system based on a preset threshold and monitors it at a preset time interval; a process classification unit that classifies whether the process is a preset critical process, classifying processes related to the vehicle's driving stability and control safety as critical processes, and classifying processes not classified as critical processes as non-time-critical processes; and a state collection unit that collects internal and external state data of the vehicle system when the process is classified as a non-time-critical process and determined to be abnormal. A software health monitoring system comprising a threshold adjustment unit that corrects the Alive / Deadline threshold of the non-time-critical process based on the above state data, updates the PHM trigger threshold based on the above internal state data, updates the communication timeout threshold based on the above external state data, and applies the updated PHM trigger threshold and the communication timeout threshold as new reference values ​​for a subsequent monitoring cycle. Claim 13 In claim 12, the health monitoring device comprises: a monitoring unit that determines the signal generation period and response status of a process running within a vehicle system based on a preset threshold and monitors it at a preset time interval; a process classification unit that classifies whether the process is a preset important process; a state collection unit that collects internal and external state data of the vehicle system when the process is not classified as an important process and is determined to be abnormal; and a threshold adjustment unit that performs a determination condition adjustment to adjust the threshold for the process not classified as an important process based on the state data.

Images