Vehicle risk management procedures and servers for them

Abstract

Vehicle risk management procedure, performed by a server, wherein the procedure comprises the following steps: identifying a multitude of interrelated functional elements of the vehicle, deriving a target hazard scenario, which is the subject of a risk assessment, based on at least one operational situation element, determining a safety level based on exposure, severity, and controllability of a hazardous situation for the target hazard scenario, and setting a safety objective based on the target hazard scenario and the safety level.

Description

CROSS-REFERENCE TO A RELATED REGISTRATION

[0001] This application claims the benefits of Korean patent applications No. 10-2024-0180767, filed on December 6, 2024, and 10-2025-0187543, filed on December 1, 2025, with the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference. BACKGROUND 1. Technical field

[0002] The present invention relates to a vehicle risk management method and a server for carrying out the same. 2. Description of the state of the art

[0003] Among the various sectors of the automotive industry, electrical and electronic systems have been the most innovative and rapidly evolving since the 2000s. In particular, control devices that regulate vehicle behavior have significantly contributed to road safety, enabling more stable driving through more precise control made possible by advancements in semiconductors and embedded software. Furthermore, the marketability of vehicles has been enhanced by the provision of comfort features for drivers. Beyond controlling engines and brakes, vehicles today feature smart keys, navigation systems, and various infotainment systems. Consequently, multiple control devices within a vehicle communicate and exchange information via the onboard network.

[0004] In parallel with these advances, the complexity of vehicle systems and the importance of safety continue to increase, but dangerous accidents are repeatedly reported that are caused by compound failures of electrical and electronic components designed to ensure the invisibility and availability of the software.

[0005] To prevent such incidents, ISO 26262 was first published in 2011, revised in 2018 and has been widely used ever since.

[0006] ISO 26262 is an international standard that deals with the functional safety of electrical and electronic systems in a vehicle and prescribes a development process that is intended to prevent failures or malfunctions in such systems from leading to accidents.

[0007] Furthermore, ISO 26262 focuses on quality assurance by enabling more accurate system design, more precise analysis, and thorough verification and validation to ensure the security of the defined data, systems, and subsystems.

[0008] ISO 26262 requires a systematic approach that identifies safety requirements in the early stages of vehicle system development and ensures that these safety requirements are met throughout the design, verification, and maintenance phases.

[0009] For example, ISO standard 26262 requires the performance of a Hazard Analysis and Risk Assessment (HARA) to identify and assess hazards at the vehicle level resulting from product defects.

[0010] In the case of HARA, many companies have traditionally created and managed documents using Excel forms, but to date no specific software tool has been developed for HARA.

[0011] HARA derives hazard events taking into account operational situations and / or malfunctions, and with an increasing number of hazard events, the processing time for Excel VBA (Visual Basic for Applications) increases, which is a disadvantage. DEMOLITION

[0012] The problem to be solved by the present invention is to provide a vehicle risk management method and a server for it that are capable of integrating hazard analysis and risk assessment (HARA) and fail-safe management (FSM).

[0013] The problem to be solved by the present invention is to provide a vehicle risk management method and a server for it that are capable of integrating hazard analysis and risk assessment (HARA) and fail-safe management (FSM).

[0014] Another problem to be solved by the present invention is to provide a vehicle risk management method and a server for it that improve the integrated management and reusability of data generated and used during the HARA analysis process and manage the common data required for hazard analysis in a standardized format.

[0015] Another problem to be solved by the present invention is to provide a vehicle risk management method and a server for it that automatically output the results of the HARA execution as different types of reports or documents depending on the intended purpose.

[0016] The technical problem that the present invention seeks to solve is to provide a method for vehicle risk management and a server capable of outputting results that conform to the formats proposed by the ISO for DTC (Diagnostic Trouble Code), such as GMRDB, or OEM-specific templates when required, by using an integrated database to generate an output that conforms to the required template.

[0017] According to one aspect of the disclosed invention, a vehicle risk management method may comprise: identifying a plurality of interrelated functional elements of the vehicle; deriving a target hazard scenario, which serves as the subject of a risk assessment, based on at least one operating situation element; determining a safety level based on the exposure, severity, and controllability of a hazardous situation for the target hazard scenario; and setting a safety objective based on the target hazard scenario and the safety level.

[0018] The multitude of functional elements can include at least one function of the vehicle, a malfunction of the function, and a hazardous condition that may arise due to the malfunction.

[0019] The target hazard scenario can be derived on the basis of a driving situation obtained by combining at least one operating situation element relating to an operating mode of the vehicle, a driving situation and an environmental condition, and excluding contradictory combinations among the combined operating situation elements.

[0020] The target hazard scenario is defined as a hazardous event that is formed by a combination of the operating situation and the hazardous condition.

[0021] The level of safety can be determined by assessing the exposure, severity, and controllability of the hazardous situation according to predetermined assessment criteria and by combining the assessment results of exposure, severity, and controllability.

[0022] The procedure may further include defining safety mechanisms to achieve the vehicle's safety objective, wherein defining the safety mechanisms includes: determining a failure condition of a vehicle function, setting parameters used to determine the failure of the function, and storing the parameters in a database; and extracting diagnostic and response-related information used to determine whether the function failure occurs, based on the parameters, and storing the diagnostic and response-related information in the database as input data for risk assessment.

[0023] As a technical means of achieving the technical objectives described above, a computer program according to one aspect of the present invention is stored on a medium to execute the vehicle risk management method described above using a computing device.

[0024] A server according to one aspect of the disclosed invention can comprise a database in which a variety of data for vehicle risk management are stored, a communication module configured for communication with an external device, and a processor that is electrically or communicatively connected to the database and the communication module. The processor can be configured to identify a variety of interrelated functional elements of the vehicle, derive a target hazard scenario which is subjected to a risk assessment based on at least one operating situation element, determine a safety level based on the exposure, severity, and controllability of a hazardous situation for the target hazard scenario, and define a safety target based on the target hazard scenario and the safety level.

[0025] The multitude of functional elements can include at least one function of the vehicle, a malfunction of the function, and a hazardous condition that may arise due to the malfunction.

[0026] The target hazard scenario can be derived by combining at least one operating situation element with respect to an operating mode, a driving situation and an environmental condition of the vehicle, whereby contradictory combinations among the combined operating situation elements are excluded.

[0027] The target hazard scenario can be defined as a hazardous event resulting from the combination of the operating situation and the hazardous state.

[0028] The level of safety can be determined by assessing the exposure, severity, and controllability of the hazardous situation based on predetermined assessment criteria and by combining the results of the assessments of exposure, severity, and controllability.

[0029] The processor can be configured to establish a safety mechanism to achieve the vehicle's safety objective, define a vehicle failure condition, set a parameter used to determine the failure, store the parameter in the database, extract diagnostic and response-related information used to determine, based on the parameter, whether a vehicle failure has occurred, and store the diagnostic and response-related information in the database as risk assessment input data, thereby establishing the safety mechanism.

[0030] The processor can be configured in such a way that, for identical or similar target threat scenarios, the results of the application of the security mechanism are compared and linked or managed in the database.

[0031] Certain embodiments of the present invention aim to address, mitigate, or at least partially solve at least one of the problems and / or disadvantages associated with the prior art. Certain embodiments are intended to offer at least one of the advantages described below.

[0032] In one aspect, a vehicle risk management procedure and a server according to the disclosed embodiments enable a more systematic and efficient management of risks caused by malfunctions by performing a hazard analysis and risk assessment (HARA) procedure for the vehicle.

[0033] According to the present invention, a number of processes, such as the identification of hazards, the derivation of hazardous events, the setting of safety objectives and the determination of safety levels, can be automated by a software tool that supports the execution of the HARA procedure and thereby ensures the consistency and reliability of the HARA results.

[0034] According to the present invention, the common data generated during the execution of HARA can be managed in a standardized, integrated database format, which improves the reusability and traceability of the data required for hazard analysis.

[0035] According to the present invention, HARA result data can be output in different templates depending on the intended use, thereby enabling the creation of result reports including safety objectives, hazardous events, safety mechanisms and the like. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] These and / or other aspects of the revelation will become clearer and more easily understood from the following description of the exemplary embodiments in conjunction with the accompanying drawings: Fig. Figure 1 is a representation showing a vehicle risk management system according to one embodiment; Fig. 2 is a diagram illustrating a procedure and relational flow of security risk analysis and risk assessment according to one embodiment; Fig.3 is a representation that exemplifies the analysis of security risks and data for risk assessment according to the embodiment of Fig. 2 represents; Fig. 4 is a block diagram of a vehicle risk management system according to one embodiment; Fig. 5 is a flowchart representing a control operation of a server according to one embodiment; and Fig. Figure 6 is a flowchart illustrating a server control procedure for achieving a vehicle safety objective according to one embodiment. DETAILED DESCRIPTION

[0037] Throughout the patent application, the same reference numerals refer to the same components. The description does not detail every element of the embodiments, and general or overlapping content within the technical scope of the disclosed invention is omitted. The terms "unit, module, element, block" used in the specification may be implemented in software or hardware. Depending on the embodiment, several "units, modules, elements, blocks" may be implemented as a single component, or a "unit, module, element, block" may comprise several components.

[0038] When, in this description, one part is referred to as being “connected” to another part, this includes not only cases where they are directly connected, but also cases where they are indirectly connected, with the indirect connection including connection via a wireless communication network.

[0039] When a part is described as “inclusive” of an element, this means that, unless explicitly stated otherwise, the part may contain additional elements rather than excluding other elements.

[0040] The terms "first", "second", etc. are only used to distinguish the individual components and do not restrict the components.

[0041] Singular expressions include plural forms unless the context clearly indicates otherwise.

[0042] The numbers for the individual steps are for ease of description and do not indicate the order of the steps. Unless the context explicitly prescribes a specific order, the steps can also be performed in a different order than described.

[0043] Hazard Analysis and Risk Assessment (HARA) is a method for systematically identifying hazardous situations that may arise due to malfunctions in a vehicle system and for assessing the severity, exposure, and controllability of each hazard in order to establish safety objectives. The HARA method according to the present invention focuses on proactively analyzing potential hazards at the system level and ensuring safety by comprehensively considering the structural features of the vehicle system, the operating environment, and the interactions between its functions.

[0044] As a preparatory step for conducting HARA, an element definition can be created. The element definition specifies the functional and physical properties of the vehicle system to be analyzed, as well as the system's boundary conditions, and serves as fundamental reference material throughout the entire HARA process. The element definition can contain the following elements.

[0045] The element's boundary can, for example, define the area affected by the system and the interface regions with other systems. The operating environment can include external environmental factors such as road conditions, climate conditions, and driving modes in which the system actually operates. Regulatory requirements can describe safety standards and legal regulations that the system must meet. The functional description can specify the system's main functions and their operating conditions.

[0046] A clear definition of system boundaries and interfaces is essential for the HARA method. This allows for the analysis of the potential impact of a malfunction in a specific function and the identification of cascading hazards that can arise from interactions with other functions. In a vehicle system where braking and steering functions are linked, a malfunction in one function can directly affect the safety of the other. Therefore, the boundaries and data flow between these functions must be clearly defined.

[0047] Furthermore, different vehicle operating modes and environmental conditions significantly influence both the probability and severity of hazard occurrences. For example, a malfunction occurring during highway driving can have far more serious consequences than the same malfunction occurring at low speed. Similarly, adverse weather conditions such as snow, rain, or ice can impair the normal functionality of the braking, steering, and acceleration systems. Therefore, HARA must quantitatively assess the frequency of hazard occurrence and their controllability, taking such environmental conditions into account.

[0048] The core method of HARA consists of deriving hazardous events from system malfunctions and assessing the impact of such events on the vehicle, its occupants, and surrounding objects when they actually occur. To this end, it is essential to clearly understand the product's design intent, the intended behavior of each function (normal operation of the function), the means of implementing the function (hardware and software components), and the performance targets required for the function's operation.

[0049] Furthermore, HARA is a method for assessing hazards that can arise at the vehicle level from malfunctions, regardless of the underlying causes of those malfunctions. Therefore, if malfunctions occur in various functions, including cybersecurity functions, leading to symptoms such as the failure of control signal transmission or a deterioration of communication, such malfunctions can be defined as independent hazardous events within HARA. The subsequent identification of the specific causes of the malfunctions and the establishment of appropriate corrective actions can then be carried out using separate analysis methods such as TARA.

[0050] The HARA method according to the invention thus makes it possible to systematically identify risks caused by malfunctions of the vehicle system in advance, to assess their scope and controllability, and thereby to create a basis for defining the safety objective.

[0051] The following describes the functional principles and exemplary embodiments of the disclosed invention with reference to the accompanying drawings. Fig. Figure 1 is a representation showing a vehicle risk management system according to one embodiment.

[0052] As in Fig. As shown in Figure 1, the integrated vehicle risk management system 1 can include a server 10 and one or more clients 30, e.g. the first to fifth electronic devices 31, 32, 33, 34 and 35.

[0053] Server 10 can manage HARA documents and provide a web-based service that enables an assessment of the hazard elements associated with the vehicle risk.

[0054] Server 10 can store predefined and registered systems, functions, system elements of a vehicle and interface information (also known as connection information).

[0055] Server 10 can contain a database 20, and database 20 can store vehicle systems, functions, system elements and interface information.

[0056] The systems can be one or more and can include hardware and software configurations of the vehicle. They can also be registered or deleted. Examples of systems can include vehicle data systems, communication systems, control systems, hardware systems, software systems, authentication and security systems, and user interface systems.

[0057] It may involve one or more functions that are made available to the user by the vehicle or its configuration (hardware and / or software).

[0058] The system elements can be one or more and can include hardware and / or software components of the vehicle.

[0059] The interface information may contain information that represents the connection relationships between the vehicle's systems and / or functions and the system elements.

[0060] Server 10 can structure text-based data and link the individual data (also referred to as information) together, organizing the relationships and structured information of the linked data into viewsets. The server can then transmit the resulting data to electronic devices 31, 32, 33, 34, and 35.

[0061] For example, server 10 can structure each text-based data element with respect to facilities, functions and / or system elements, and organize the relationships and structured information of each text-based data element in a viewset based on interface information, and then transfer it to electronic devices 31, 32, 33, 34 and 35.

[0062] Server 10 can generate and output HARA output data based on plant information, functional element information, system element information and / or interface information in response to information (also referred to as data) received from electronic devices 31, 32, 33, 34 and 35.

[0063] For example, in response to receiving plant or function information together with additional user input data (also referred to as user input data) from an electronic device 31, 32, 33, 34 and 35 that has received data provided by a viewset, the server 10 can generate HARA output data corresponding to the plant or function in question and transmit the generated HARA output data to the appropriate electronic device 31, 32, 33, 34 and 35.

[0064] HARA serves to ensure the functional safety of a vehicle, to assess potential hazards that may occur under various operating conditions, to define top-level safety objectives, and to determine the Automotive Safety Integrity Level (ASIL) based on these objectives. Various operating conditions can be parameterized and used when determining the ASIL.

[0065] The FSM document may contain information on security mechanisms identified by HARA and derived through several subsequent processes.

[0066] In the meantime, Server 10 can predefine and store the following data usage conditions to ensure the integrity of the work data. <Conditions> 1. General users among the predefined users cannot enter data. 2. General users cannot write any data other than the data already entered. 3. Only a master user with write permission can enter data.

[0067] Server 10 can pre-store data connection information. Accordingly, if a specific piece of information is selected by an electronic device 31, 32, 33, 34, or 35, the associated information can be automatically provided and displayed on that electronic device. Alternatively, all the properties in the table that are linked to the selected information can be provided and displayed on the electronic device 31, 32, 33, 34, or 35, and the user of that electronic device can select the properties directly.

[0068] Furthermore, the server can store 10 pieces of information that require calculation, as well as formulas to be associated with this information. For information requiring calculation, the server can automatically calculate the result using the stored formulas and provide and display the result on the electronic devices 31, 32, 33, 34, and 35.

[0069] Server 10 can offer an approval service.

[0070] For example, Server 10 can provide an approval service to confirm that the completed information has no further changes after review and control by a general user and a master user.

[0071] Once the approval process is complete, the relevant information (e.g., an approved viewset) can no longer be changed. If changes are necessary, a data release request must be submitted.

[0072] Server 10 can offer a mail delivery service.

[0073] As a notification function, a mail delivery service for at least one piece of information can be predefined in Server 10, and the server can provide the mail delivery service by communicating with a predefined mail server.

[0074] Server 10 can perform data visualization. Server 10 can display analytical information, such as functional and fault analysis, in a structure tree and make it available to electronic devices 31, 32, 33, 34, and 35.

[0075] Server 10 can set and save different user permissions for each user.

[0076] Users can include, for example, administrators, master users, general users, and associated users. Each user can be distinguished by a user ID (identifier).

[0077] The administrator can have permissions that allow all possible user activities. For example, the administrator can register or delete users, change user rights, and manage data changes. On the administrator page, the administrator can also enter, edit, and delete bulk data. Furthermore, the administrator can perform a rollback operation, which cancels ongoing transactions and reverts modified data to its original state. The administrator can also modify the dashboard that appears as the first screen upon login.

[0078] A master user can configure permissions to allow reading or modifying data within their assigned project. Depending on the project, the master user's rights to view or edit data may be restricted, and they may not have delete permissions. The master user can also be granted separate permissions to review views created by general users.

[0079] A general user may have permission to view and modify data within their assigned project. However, for projects where no permissions are granted, the general user's ability to view or modify data may be restricted, and they may not be granted delete permissions. The general user may also be granted separate permissions to review views created by the master user.

[0080] An associated user may only have permission to read and export viewsets. For example, the associated user may only be allowed to read and export views and may not perform any other functions.

[0081] For example, Server 10 can set and save a predefined permission configuration for each user type, as shown in Table 1. [Table 1] User type User permissions Administrator Read, write, modify, delete, import, export, submit and approve Master User Read, modify (limited to the master database), export and approve General User Read, modify, export and approve Associate User Read and export

[0082] In Table 1, “Read” means that the user can read data from projects for which they have been granted permission.

[0083] "Write" means that the user can add new entries to the data of a project for which write permissions have been granted. However, according to the predefined settings, data can only be added to the "supergroup".

[0084] “Modify” means that the user can change existing data in a project for which change approval has been granted. For example, the user can select and change data via a drop-down list among the graphical user interface (GUI) elements displayed on the screen of electronic devices 31, 32, 33, 34, and 35.

[0085] "Delete" means that the user can delete data, including cases where data is deleted within a supergroup project.

[0086] “Importing” means that data can be loaded into the supergroup project via a file in a predefined format, such as an Excel file or a CSV file.

[0087] “Exporting” means that the content of a viewset of a project for which permission has been granted can be output or saved in a predefined format, e.g. Excel, Word or PDF.

[0088] "Submit" means that after completing the assessment for HARA, the user can submit the corresponding viewset to request approval. For example, once a functional safety activity is completed, the viewset for that activity can be submitted for approval.

[0089] “Approve” means that the evaluated HARA viewset can be reviewed and approved.

[0090] Each of the electronic devices 31, 32, 33, 34 and 35 can receive web-based services from server 10. A web browser 311, 321, 331, 341 and 351 can be installed on each electronic device, through which the user can access and use the web-based services of server 10.

[0091] Each of the electronic devices 31, 32, 33, 34 and 35 can display screens corresponding to the web-based services of Server 10 and, by user input, select elements for the creation of HARA or FSM documents corresponding to the systems or functions of the vehicle and transmit the selected data to Server 10.

[0092] Additionally, each of the electronic devices 31, 32, 33, 34 and 35 can receive HARA and / or FSM output data relating to systems or functions of the vehicle from server 10 and display it on the screen or output HARA, TARA and / or FSM as output data.

[0093] In one embodiment of the present invention, the individual steps of HARA are related to each other as described in Fig. 2 is shown, and this allows the vehicle system to simultaneously consider both safety and hazard prevention.

[0094] Furthermore, HARA includes procedures for evaluating individual information and data elements based on the interconnected information and data.

[0095] Furthermore, HARA can, as in Fig. 2 and Fig. 3. Information and / or data that can be generally applied and generalized between HARA and TARA are classified into general information and / or data that are specialized for HARA, and such classification may be predefined.

[0096] Fig. Figure 2 is a representation illustrating a procedure and a relational flow of security risk analysis and risk assessment according to one embodiment.

[0097] As in Fig.As shown in Figure 2, the method for analyzing vehicle risk according to one embodiment comprises a data flow structure for defining a safety target based on the analysis results of the vehicle's functional safety (HARA; Hazard Analysis and Risk Assessment).

[0098] In Fig. 2. The data flow shown on the left corresponds to the functional safety analysis (HARA) procedure, and the data analysis flow is divided into common data and hazard data, which can form mutual reference and linking relationships.

[0099] In HARA, data relating to vehicle function, malfunctions, and hazardous conditions that can arise from malfunctions are defined as hazard data. HARA performs a hazard assessment based on the causal relationships between these elements. The vehicle functions can correspond to the plant functions used in the TARA procedure described later.

[0100] For example, one of a vehicle's most important functions, the "acceleration request" function, is configured to control the vehicle's drive torque based on the driver's pedal input signal. However, if the function malfunctions and instead requests excessive acceleration torque beyond what is required, the vehicle can experience unintended longitudinal acceleration, regardless of the driver's intention.

[0101] Such a malfunction directly affects the vehicle's driving stability and can be classified as a hazardous condition that endangers the safety of the occupants. Accordingly, the HARA procedure analyzes the causal relationships between the functions and the process of hazard propagation to provide the fundamental data for the hazard assessment carried out in the subsequent phases.

[0102] A target hazard scenario, to be used as the objective for hazard assessment, can be derived based on at least one operating situation element. The target hazard scenario can be generated by modeling representative operating situations that may occur while the vehicle is in motion and can be created by combining at least one operating situation element relating to a vehicle operating mode, a driving situation, and an environmental condition. The target hazard scenario can be derived by combining the vehicle's operating mode, operating situation, and environmental condition, excluding combinations that are mutually contradictory or unrealistic.For example, if the vehicle's operating mode is "highway driving", the driving situation is "accelerating while the vehicle in front maintains the same speed", and the environmental condition is "flat, paved, dry asphalt road", such a combination of elements can be derived as a realistic target hazard scenario for hazard assessment.

[0103] As in Fig. As shown in Figure 2, at least two of the factors operating mode (O), driving situation (S), and environmental condition (E) can be combined to create a hazardous situation. For example, the general operating situation can be derived by combining the operating mode (O) and the driving situation (S). The general operating situation can also be derived by combining the driving situation (S) and the environmental condition (E).

[0104] The vehicle's operating mode (O), driving situation (S) and environmental condition (E) can each act as an independent risk factor; however, in an actual driving environment, these elements can influence each other, and only certain combinations can represent a realistic hazard scenario.

[0105] Accordingly, the mutual controllability relationships between the operational situation elements, as in Fig. 2 is represented as a controllability relationship between operating mode and driving situation (Contr OS), as a controllability relationship between operating mode and environmental state (Contr OE) and as a controllability relationship between driving situation and environmental state (Contr SE).

[0106] Contr OS is a relationship used to check the compatibility between the vehicle's operating mode and the driving situation. For example, if an "autonomous driving mode on the highway" is combined with "acceleration of the vehicle ahead," this combination can be excluded from a hazard scenario because it does not pose an actual danger, even if it occurs.

[0107] Contr OE is a relationship used to assess the controllability between the vehicle's operating mode and the environmental conditions. For example, if the vehicle is in a situation where it is "decelerating due to sudden braking at 1g" while an "icy road surface" is detected, the combination may be determined to be contradictory and unlikely to occur simultaneously, and thus excluded from the hazard scenario.

[0108] Contr SE is a relationship used to assess the controllability between the driving situation and the environmental conditions. For example, if the vehicle is on a "highway" and a "pedestrian crossing the road" is detected, the combination can be determined as unrealistic and therefore excluded from the hazard scenario.

[0109] Based on these relationships of mutual controllability (Contr OS, Contr OE, Contr SE), only combinations that can realistically occur in a real driving environment are selected as operating situations, and the target hazard scenario can be derived by combining the selected operating situation with the vehicle's hazard state. This procedure excludes combinations that are contradictory or unrealistic in a real environment, thus enabling a more reliable hazard assessment.

[0110] For example, if a vehicle is traveling straight ahead at 80 km / h on a motorway, the vehicle in front maintains a constant speed, and the driver intends to accelerate, such conditions can be defined as a hazardous event where unintended longitudinal acceleration may occur due to a malfunction of the acceleration request function. Consequently, contradictory combinations of operating situation elements are excluded from the general operating situations, such as selecting the "motorway" operating mode when the road surface is unpaved, or unintended acceleration when the driver intends to decelerate.By excluding combinations that have a very low probability of occurrence under real-world conditions, realistic selected operating situations and target hazard scenarios can be derived and reliably evaluated.

[0111] For the derived target hazard scenario, an Advanced Safety Integrity Level (ASIL) can be determined based on the exposure (E), severity (S), and controllability (C) of the hazardous situation. The ASIL can be derived by assessing the exposure, severity, and controllability of the hazard according to predefined assessment criteria and combining the assessment results.

[0112] In particular, in one embodiment of the present invention, the determination of the safety level can be carried out based on the functional safety assessment procedure defined in ISO 26262. Exposure (E) is an indicator of the probability that a specific hazardous situation will occur in an actual driving environment and can be calculated by comprehensively considering factors such as the vehicle's driving frequency, road conditions, climatic conditions, and the driver's driving habits. For example, if the vehicle is driving on a motorway in clear weather and on a dry road surface, such conditions can be considered a frequently occurring situation in real-world traffic and classified in exposure class E4 (high probability situation).

[0113] The severity level (S) is an indicator used to assess the potential extent of damage to occupants, the vehicle, and surrounding objects should a hazardous situation actually occur. The severity level can be determined by considering physical parameters such as impact type, impact speed, side of impact, initial distance, and acceleration. For example, if a vehicle traveling at the same speed as a vehicle ahead receives a signal from behind to accelerate excessively, and the distance between the vehicles rapidly decreases, a collision may occur resulting in minor injuries to the occupants. Such a situation can be classified as severity level S1 (minor injuries).

[0114] Controllability (C) is an indicator used to assess the driver's ability to perceive and avoid or control a hazardous situation. For example, if the driver perceives the decreasing distance to the vehicle in front and immediately releases the accelerator pedal or applies the brakes, the situation can be considered easily controllable by the driver and assigned to controllability class C1 (easily controllable).

[0115] By combining the assessment results of exposure (E), severity (S), and controllability (C), derived as described above, an ASIL corresponding to the hazardous situation can be determined in one embodiment of the present invention. For example, if the situation is assessed as E4 (high probability), S1 (low severity), and C1 (easily controllable), it can be considered relatively low-risk and classified as QM (quality management). The safety level thus determined can be used as a reference point for defining the strength and scope of functional safety measures when setting a safety objective.

[0116] According to one embodiment, a vehicle safety objective can be defined based on the target hazard scenario and the safety level. Specifically, according to this embodiment, the safety objective can be defined as a criterion to prevent hazardous situations that may arise due to a malfunction of a vehicle function, or to minimize injuries and system damage, even if such a hazard occurs.

[0117] The safety objective can be defined based on the ASIL level determined for each target hazard scenario, with stricter requirements for safety control and diagnostics possible as the ASIL level increases. For example, if the vehicle's "acceleration request function" malfunctions and generates excessive acceleration torque unintended by the driver, the corresponding target hazard scenario can be defined as "unintended longitudinal acceleration." In this case, safety objectives such as the following can be defined based on the specific ASIL level. For instance, if unintended acceleration is detected, the safety objective might require that the acceleration control signal be immediately shut down within 500 ms.Additionally, in the same situation, a notification function can be included in the safety objective to immediately inform the driver and the relevant vehicle control modules (e.g., an ECU) about the occurrence of the hazard. If unintended acceleration is detected, the vehicle can automatically enter a deceleration mode, in which deceleration or function limitation occurs, and the safety objective can prescribe that additional evasive control measures be taken, such as pressure limitation, the deactivation of related functions, or alternative control.

[0118] To achieve the safety objective, a fault tolerance time interval and a safe state can be defined for each vehicle function. For example, the fault tolerance time interval for acceleration control can be set to 500 ms. In this case, if abnormal torque is detected within the defined time, the system can immediately issue a warning signal to the driver and deactivate the acceleration control signal via the vehicle control module, thus bringing the vehicle into a safe state.

[0119] The safety objective defined above can serve as the primary requirement for ensuring the functional safety of the vehicle control system and form the basis for the design of detailed diagnostic logic, fault detection algorithms, and fail-safe mechanisms in subsequent development phases. In the system according to one embodiment of the present invention, the common data serve as important reference data for linking the functional safety analysis (HARA) with the cybersecurity analysis (TARA) and ensure data consistency and analytical continuity between the two assessment frameworks.

[0120] Shared data can include information such as the vehicle's function, malfunctions of that function, equipment, equipment functions, and equipment properties. Such shared data can be used as input for hazard assessment at the functional level within the HARA framework. This means that the same system component can be defined as a function in HARA and assessed as an element capable of causing a hazardous event, while in TARA the same element can be defined as an equipment and analyzed as a target exposed to external threats. For example, a malfunction defined in HARA and a threat to an equipment defined in TARA can be linked based on the same functional element via shared data.

[0121] In this way, the shared data acts as a data bridge, linking the analysis results of functional safety and cybersecurity, thus enabling cross-references and an integrated evaluation between the two analysis methods.

[0122] Fig. 3 is a representation that exemplifies the analysis of security risks and data for risk assessment according to the embodiment of Fig. 2 represents.

[0123] In Fig. Section 3 presents the information and / or data required to define a safety target for the vehicle risk. Fig. 3. The data used to define the security objective can be referred to as hazard data, which may be HARA-specific data. Furthermore, the threat and vulnerability data, i.e., the data to which both HARA and TARA refer, can be referred to as common data.

[0124] The hazard data referenced only in HARA can contain information about the numerous functional elements. These functional elements can contain sub-data relating to vehicle functions, malfunctions of those functions, and hazardous conditions that may arise as a result of those malfunctions. In this case, the data relating to vehicle functions, malfunctions, and hazardous conditions can be the common data referenced by both HARA and TARA.

[0125] The common data regarding the target hazard scenario can be derived as hazard data, which are referenced in HARA and are based on a combination of data relating to the operating situation elements, the vehicle's operating mode, the driving situation, and the environmental conditions. For example, the operating situation element defines the type of hazard that can occur in the event of a vehicle malfunction, the vehicle's operating mode distinguishes the driving condition in which the function is performed, and the driving situation and environmental conditions determine the level of risk depending on external environmental factors. From the combination of these factors, a target hazard scenario can be derived that can occur under specific operating conditions.

[0126] The common data on the safety level can correspond to the data on the ASIL (Automotive Safety Integrity Level). The safety level can be determined, for example, based on data on exposure to the hazardous situation, the severity of the hazardous situation, and the controllability of the hazardous situation. Here, the data on exposure, severity, and controllability can correspond to the hazard data referenced only in HARA. The safety objective can be derived based on the safety level data referenced jointly in HARA and TARA.

[0127] Fig. Figure 4 is a block diagram of a vehicle risk management system according to one embodiment.

[0128] As in Fig. As shown in Figure 4, the server 10 of the vehicle risk management system 1 can contain a database 20, a communication module 110 and / or a control device 340.

[0129] Database 20 can store information and / or data required to define a safety target for vehicle risk. The data used to define the safety target can be referred to, for example, as hazard data. This hazard data can be HARA-exclusive or data jointly referenced by both HARA and TARA.

[0130] Database 20 can store at least some of the predefined hazard data required for performing HARA during the vehicle risk management process. Database 20 can also store HARA-exclusive data. This data can consist of a variety of data elements, each representing a successive step of a predefined HARA procedure. The HARA-exclusive data can also include at least a subset of other data.

[0131] Database 20 can store a predefined set of common data that is frequently referenced in both the HARA and TARA procedures. For example, database 20 can contain the information contained in the Fig. 2 and Fig. The 3 common data shown are stored, which are referenced in both HARA and TARA.

[0132] In the meantime, at least some of the hazard data, its sub-data, and the common data may have a hierarchical structure in which the data are interdependent or linked, so that a change or update of certain data may trigger a corresponding update of the associated data.

[0133] Database 20 can store information about link relationships that define hierarchical relationships between the HARA-exclusive data, i.e., the hazard data according to the successive phases of HARA.

[0134] Database 20 can store information about connection relationships that represent the stepwise or hierarchical relationships between the common data referenced jointly in HARA and TARA.

[0135] Database 20 can store information that represents links between the hazard data and the common data.

[0136] Database 20, for example, can store linking information that allows at least some of the HARA-exclusive data and some of the common data referenced by both HARA and TARA to have a hierarchical reference relationship.

[0137] The communication unit 110 can establish a communication channel between the server 10 and external devices, e.g., the one in Fig. The communication unit 110 comprises the first to fifth electronic devices 31, 32, 33, 34 and 35 shown in Figure 1, and can send and receive data via the specified communication channel. The communication unit 110 can include a communication circuit and a control circuit configured to control the operation of the communication circuit to support such communication functions.

[0138] For example, the communication unit 110 can contain a wireless communication module such as a cellular module, a Wi-Fi communication module, a short-range wireless communication module or a global navigation satellite system communication module and / or a wired communication module and can send and receive data with external devices via the appropriate module.

[0139] The control device 120 can be electrically connected to any component of the server 10, e.g. the database 20 and the communication unit 110, and can control each component.

[0140] The control device 120 can control the HARA-exclusive data and the common data referenced by both HARA and TARA, which are to be stored in the database 20.

[0141] The control device 120 can be communicatively connected to the electronic devices 31, 32, 33, 34 and 45 via the communication unit 110. Although in Fig. 4 only a first electronic device 31 is shown, this serves only for explanation, and the possibility of communicating with several electronic devices does not limit the scope of the present invention.

[0142] The control device 120 can receive a user ID from the first electronic device 31 and, based on the received user ID, set and assign user rights for the electronic device 31.

[0143] The control device 120 can receive evaluation target information from the first electronic device 31 via the communication unit 110, which corresponds to a system or function of the vehicle.

[0144] The control device 120 can generate and output HARA result data for the evaluation target information in response to the receipt of the evaluation target information, based on the HARA-exclusive data and / or the common data to which both HARA and TARA refer.

[0145] The control device 120 can generate HARA result data for the evaluation target information based on user input data (also referred to as user data) for at least part of the HARA-exclusive data and / or the common data referenced by both HARA and TARA, the user input data being received via the communication unit 110. The user-entered information may, for example, include user-defined values, i.e., parameters for the relevant data. The control device 120 can generate the HARA result data corresponding to the evaluation target information based on a specific HARA template (e.g., a dynamic template) stored in memory 122. The generated HARA result data can be transmitted to the first electronic device 31 via the communication unit 110.

[0146] The control device 120 can identify data from the HARA output data that is destined to be included in an FSM document and can generate FSM document data based on a specific FSM template (e.g., a dynamic template) stored in memory 122. The generated FSM document data can also be transmitted to the electronic device 31 via the communication unit 110.

[0147] The control device 120 may contain a control circuit that is set up to control the execution of the above-mentioned functions.

[0148] The control device 120 can be implemented as a micro control unit (MCU) and contain the memory 122 and a processor 121.

[0149] Memory 122 can store programs and / or data for processing individual data (e.g., data from external devices such as those in Fig.1 shown first to fifth electronic devices 31, 32, 33, 34 and 35 were received) store.

[0150] Memory 122 can temporarily store individual data or temporarily store the processing result of the data processed by processor 121.

[0151] The memory 122 can contain both volatile memory such as S-RAM or D-RAM and non-volatile memory such as flash memory, ROM, EPROM and / or EEPROM.

[0152] The processor 121 can process any part of the received data and, based on the processing result, output signals to control the communication unit 110 and / or the database 20.

[0153] The first electronic device 31 can comprise a communication unit 310, an input unit 320, an output unit 330 and a control device 340.

[0154] The communication unit 310 can establish a communication channel between the first electronic device 31 and an external device, for example, the server 10, and send and receive data via the established communication channel. The communication unit 310 can include a communication circuit and a control circuit configured to control the operation of the communication circuit.

[0155] For example, the communication unit 310 can contain a wireless communication module, such as a cellular module, a Wi-Fi communication module, a wireless short-range communication module or a global navigation satellite system communication module, and / or a wired communication module, and can send and receive data with an external device via the appropriate communication module.

[0156] The input unit 320 can receive information according to user operation and pass the information on to a connected device such as the control device 340.

[0157] The 320 input unit can, for example, contain input devices such as buttons, switches, a touchscreen and / or a microphone.

[0158] The output unit 330 can output visual and / or acoustic information so that a user of the first electronic device 31 can perceive the information. The output unit 330 can, for example, include a display and / or a loudspeaker.

[0159] The control device 340 can be electrically connected to any component of the first electronic device 31, e.g., to the communication unit 310, the input unit 320 and / or the output unit 330, and can control the operation of the respective components.

[0160] The control device 340 can communicate with the server 10 via the communication unit 310. The control device 340 can receive a service for managing HARA documents from the server 10 via the communication unit 310.

[0161] For example, the control device 340 can receive at least some of the HARA-exclusive data and / or the common data to which both HARA and TARA refer from the server 10 and output the received data via the output unit 330, e.g. a display.

[0162] The control device 340 can acquire evaluation target information via the input unit 320, which corresponds to a system or function of the vehicle according to a user operation.

[0163] The control device 340 can acquire user input data, such as parameters, via the input unit 320 for at least some of the HARA-exclusive data and / or the common data to which both HARA and TARA refer.

[0164] The control device 340 can transmit the user input data acquired via the input unit 320 for at least part of the HARA-exclusive data and / or the common data to which both HARA and TARA refer to the server 10 via the communication unit 310.

[0165] The control device 340 can receive HARA result data for the evaluation target information from the server 10 via the communication unit 310 and output the received result data to the user via the output unit 330, e.g. a display.

[0166] In addition, the control device 340 can receive result data for the FSM document from the server 10 via the communication unit 310 and output the data via the output unit 330, e.g. a display.

[0167] The control device 340 can also contain a control circuit.

[0168] The control device 340 can be designed as a micro control unit (MCU) and contain a memory 342 and / or a processor 341.

[0169] Memory 342 can store programs and / or data for processing individual data, e.g., data received from an external device such as server 10, or data corresponding to information entered via input unit 320.

[0170] Memory 342 can temporarily store received data or the results of data processed by processor 341.

[0171] The memory 342 can include volatile memory such as S-RAM and / or D-RAM and non-volatile memory such as flash memory, ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory) and / or EEPROM (Electrically Erasable Programmable Read Only Memory).

[0172] The processor 341 can process all received or input data and provide control signals for the respective components to control the communication unit 310, the input unit 320 and the output unit 330 based on the processing result.

[0173] Although in Fig. Not shown in section 4, the second electronic device 32, the third electronic device 33, the fourth electronic device 34 and the fifth electronic device 35 can be distinguished from Fig.1 comprising a communication unit, an input unit, an output unit and a control device similar to those of the first electronic device 31, and capable of performing operations similar to those of the first electronic device 31.

[0174] Fig. Figure 5 is a flowchart that illustrates a control process of a server according to one embodiment.

[0175] As in Fig. As shown in Figure 5, the server can identify a variety of functional elements of the vehicle that are related to each other (501).

[0176] According to one embodiment, the multiple functional elements can be HARA-related data concerning functional safety and include at least one vehicle function, a malfunction of the function, and a hazardous condition caused by the malfunction. Here, the data on the vehicle function, the malfunction, and the hazardous condition that can occur due to the malfunction can be data to which both HARA and TARA jointly refer.

[0177] Starting from at least one operating situation element (502), the server can derive a target hazard scenario that serves as an evaluation target for risk assessment. The target hazard scenario can be derived, for example, by modeling representative operating situations that can occur while driving a vehicle. In one embodiment, the target hazard scenario can be derived by combining at least one operational element relating to the vehicle's operating mode, driving situation, and environmental state, and by excluding contradictory combinations among the combined operating situation elements. The target hazard scenario is defined as a hazardous event formed by a combination of the operating situation and the hazard state. For the combinations and exclusion rules between operating mode, driving situation, and environmental state, reference is made to the description of Fig. 2 referred to above.

[0178] The server can determine a safety level based on the exposure, severity, and controllability of the hazard for the target hazard scenario (503). For the derived target hazard scenario, the safety level (ASIL) can be determined based on the exposure E, severity S, and controllability C of the hazard. In one embodiment, the safety level can be determined by evaluating the exposure, severity, and controllability of the hazard according to predefined evaluation criteria and combining the evaluation results.

[0179] The server can define a safety objective based on the target hazard scenario and the safety level (504). Specifically, in the present embodiment, the safety objective can be defined as a criterion to prevent hazardous situations that may arise from malfunctions of vehicle functions in advance, or to minimize personal injury and system damage even if such hazards occur.

[0180] Fig. Figure 6 is a flowchart illustrating a server control procedure for achieving a vehicle safety objective according to one embodiment.

[0181] The server can define a failure condition for a vehicle function and set parameters used to determine the function failure, storing these parameters in the database (601). For example, the server can set various diagnostic data such as sensor input values, control command signals, system response latency, temperature, and voltage as parameters to determine whether the function is operating normally.

[0182] The server can extract diagnostic and response-related information used to determine vehicle malfunctions based on the parameters used to determine the malfunction (602). The server can configure the diagnostic logic with reference to parameter thresholds, normal operating ranges, and fault conditions, and define response steps to be applied when a fault occurs, such as issuing a warning, restricting a function, or switching to a protective mode, thereby establishing the reference information required for managing vehicle malfunctions.

[0183] The server can store diagnostic and response-related information related to vehicle malfunctions in the database and use it as input data for risk assessment (603). The server can structure and store various forms of analysis data in the database, including fault detection results, fault onset time, frequency, condition information, response steps taken, and response effectiveness derived from the diagnostic information in step 602. Accordingly, the server can support the use of the analyzed data as reliable reference material for vehicle safety risk assessment. This means that information such as the cause of each malfunction, its frequency, and the effectiveness of the countermeasures applied can be incorporated into the risk assessment during a subsequent HARA analysis.

[0184] The server can define safety mechanisms to achieve the vehicle's safety goal (604). For example, the server can define a safety mechanism consisting of fault detection logic, rules for switching to a protection mode, a safety diagnostic cycle, and signal monitoring conditions, and deploy or update the safety mechanism in conjunction with a vehicle control device or a network gateway. Furthermore, the server can automatically adjust or refine the parameters of the safety mechanism based on real-time operational data and diagnostic information collected from the vehicle to ensure that the vehicle system maintains the safety goal consistently.

[0185] In one embodiment, the server can compare the application results of the security mechanisms for the same or similar target threat scenarios and manage them in an integrated manner within the database.

[0186] In the preceding embodiments, a unified procedure was presented for establishing a framework that enables risk management activities to be carried out without omitting any information. This framework avoids wasted resources and duplication of effort that can occur when functional safety assessments are performed and managed separately. The example of a vehicle braking system has confirmed that the efficiency of the risk management process can be improved.

[0187] Furthermore, the preceding discussion focuses on identifying the relationships between data based on HARA analysis and on standardizing risk mitigation measures through the identified safety mechanisms. However, the quality of the results of risk mitigation measures can vary depending on the level of detail in the planning and analysis. Therefore, the framework described in the preceding embodiments can be extended to include tools such as fault tree analysis and fault mode and effects analysis to further support functional safety analysis.

[0188] In the meantime, common elements between TARA and HARA have been identified in the aforementioned embodiments to enable the identification of foreseeable risks related to functional safety and the protection of systems during vehicle operation, and to support the implementation of measures to mitigate such risks. Furthermore, a unified procedure has been presented to ensure that risk management can be carried out without omitting any information. This framework avoids wasted resources and duplication of effort that can occur when functional safety activities are performed and managed independently. Using a vehicle braking system as an example, it has been demonstrated that the efficiency of the risk management procedure can be increased. In particular, in the embodiment of Fig.In section 6, a fundamental recursive analysis was applied starting from the element definition, thereby establishing a basis for defining optimization strategies for risk management throughout the entire vehicle lifecycle. The use of such a framework is expected to reduce development costs and improve quality, which in turn can lead to a reduction in quality-related costs. Ultimately, this can contribute to improved business productivity and increased long-term sustainability.

[0189] Furthermore, the preceding embodiments illustrate the sequence of procedures within the HARA process and emphasize the standardization of risk reduction activities through the identified new safety controls and mechanisms. However, the quality of the risk reduction results depends on the level of detail in the planning and analysis. Accordingly, the framework described in the preceding embodiments can be extended to include tools such as fault tree analysis and failure mode and effects analysis for diagnosing functional safety.

[0190] Another aspect is that the disclosed embodiments can be implemented in the form of a recording medium that stores instructions which can be executed by a computer. The instructions can be stored as program code and, when executed by a processor, generate program modules that perform the operations of the disclosed embodiments. The recording medium can be implemented as a computer-readable recording medium.

[0191] Computer-readable recording media encompasses any type of medium on which instructions are stored that can be interpreted by a computer. Examples include read-only memory (ROM), random-access memory (RAM), magnetic tapes, magnetic disks, flash memory, and optical data storage.

[0192] The machine-readable storage medium can be provided as a non-transferable storage medium. The term "non-transient" simply means that the storage medium is a tangible device that does not contain signals such as electromagnetic waves, and does not distinguish whether the data is stored permanently or temporarily. A non-transferable storage medium can, for example, contain a buffer in which data is temporarily stored.

[0193] The disclosed embodiments have been described above with reference to the accompanying drawings. Those skilled in the art will understand that various modifications and other embodiments are possible without departing from the technical spirit or the essential features of the present invention. The embodiments shown are therefore to be considered illustrative and not restrictive. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] KR 10-2024-0180767

[0001] KR 10-2025-0187543

[0001] Cited non-patent literature

[0000] ISO 26262

[0006]

Claims

[1] Vehicle risk management procedures, comprehensive: Identifying a multitude of functional elements of the vehicle that are interrelated; Deriving a target hazard scenario, which serves as the subject of risk assessment, based on at least one operational situation element; Determining a safety level based on the exposure, severity, and controllability of a hazardous situation for the target hazard scenario; and Defining a security objective based on the target threat scenario and the security level. [2] Method according to claim 1, wherein the plurality of functional elements comprise at least one function of the vehicle, a malfunction of the function and a hazardous condition that may occur due to the malfunction. [3] Method according to claim 1 or 2, wherein the target hazard scenario is derived on the basis of a driving situation obtained by combining the at least one operating situation element relating to an operating mode of the vehicle, a driving situation and an environmental condition, and excluding contradictory combinations among the combined operating situation elements. [4] Method according to any one of claims 1 to 3, wherein the target hazard scenario is defined as a hazardous event formed by a combination of the operating situation and the hazardous state. [5] Method according to any one of claims 1 to 4, wherein the level of safety is determined by assessing the exposure, severity and controllability of the hazardous situation according to predetermined assessment criteria and combining assessment results of the exposure, severity and controllability. [6] Method according to any one of claims 1 to 5, further comprising defining safety mechanisms to achieve the safety objective of the vehicle, wherein defining the safety mechanisms comprises: Determining a failure condition of a function of the vehicle, setting parameters used to determine the failure of the function, and storing the parameters in a database (20); and Extracting diagnostic and response-related information that is used to determine whether the failure occurs based on the parameters, and storing the diagnostic and response-related information in the database (20) as input data for the risk assessment. [7] Method according to claim 6, wherein for identical or similar target-hazard scenarios the results of the application of the safety mechanisms are compared with each other and linked or managed in the database. [8] Computer program stored on a medium to cause a computer device to perform the method according to any one of claims 1 to 7. [9] Server (10), comprising: a database (20) in which a large amount of data for vehicle risk management is stored; a communication module (110) configured to communicate with an external device; and a processor (121) that is electrically or communicatively connected to the database (20) and the communication module (110), where the processor (121) is configured to: Identifying a multitude of functional elements of the vehicle that are interrelated; Deriving a target hazard scenario, which is the subject of the risk assessment, based on at least one operational situation element; Determining a safety level based on the exposure, severity, and controllability of a hazardous situation for the target hazard scenario; and Defining a security objective based on the target threat scenario and the security level. [10] Server (10) according to claim 9, wherein the plurality of functional elements comprise at least one function of the vehicle, a malfunction of the function and a hazardous condition that may occur due to the malfunction. [11] Server (10) according to claim 9 or 10, wherein the target hazard scenario is derived by combining the at least one operating situation element relating to an operating mode of the vehicle, a driving situation and an environmental state, and excluding contradictory combinations among the combined operating situation elements. [12] Server (10) according to one of claims 9 to 11, wherein the target hazard scenario is defined as a hazardous event formed by combining the operating situation and the hazardous state. [13] Server (10) according to any one of claims 9 to 12, wherein the level of safety is determined by assessing the exposure, severity and controllability of the hazardous situation on the basis of predetermined assessment criteria and combining the results of the assessments of exposure, severity and controllability. [14] Server (10) according to any one of claims 9 to 13, wherein the processor (121) is configured to establish a safety mechanism to achieve the vehicle's safety objective, and to define a vehicle failure condition, to set a parameter used to determine the failure, to store the parameter in the database, to extract diagnostic information and response-related information which are used to determine, on the basis of the parameter, whether a vehicle failure has occurred, and to store the diagnostic information and response-related information in the database (20) as risk assessment input data, thereby establishing the safety mechanism. [15] Server (10) according to claim 14, wherein the processor (121) is configured such that for identical or similar target hazard scenarios the results of the application of the security mechanism are compared and linked or managed in the database (20).

Images