Road vehicle safety analysis generation method and system, electronic equipment and storage medium

Abstract

The invention provides a road vehicle safety analysis generation method and system, electronic equipment and a storage medium, and the method comprises the steps: obtaining a related item definition document and an HARA analysis document of a road vehicle, and extracting basic information and key parameters related to the construction of a fault tree analysis event, so as to construct structured data; according to the structured data, establishing an association reasoning instruction through Prompt engineering, establishing multi-level association mapping, reasoning and generating a preliminary event level of fault tree analysis based on an association mapping result, and outputting a preliminary reasoning result; based on the preliminary reasoning result, constructing a complete structured fault tree according to a preset process; and performing result verification according to the structured fault tree, and outputting a fault tree analysis document in a standard format. The method can quickly complete fault tree analysis, effectively reduces personal errors, and can adapt to various road vehicle systems such as braking, steering, power control and the like.

Description

Technical Field

[0001] This application belongs to the field of automotive electronics and test automation technology, and in particular relates to a method, system, electronic device and storage medium for generating road vehicle safety analysis. Background Technology

[0002] In the field of road vehicle safety, Fault Tree Analysis (FTA) is a core analytical method in safety systems engineering. Using an inverted tree-like logical causal diagram as its framework, it clearly depicts the causal relationships between various events within a system through event symbols and logic gate symbols. Following a top-down analytical path, it starts with the entire vehicle system, disassembling it layer by layer to components and parts. Based on the tree-like branching diagram constructed from logic symbols, it accurately calculates the probability of occurrence of fault events (top events). Simultaneously, it can incorporate variables such as human factors and environmental conditions to analyze the cascading impact of component, component, or subsystem failures on overall vehicle safety, providing crucial support for vehicle safety risk prevention and control. However, traditional FTA analysis relies on manual logical modeling, data calculation, and result derivation. Faced with the increasingly complex system structures of current road vehicles upgrading towards intelligence and electrification (such as multi-domain controllers and autonomous driving perception systems), it presents several problems: (1) Low analysis efficiency: It is difficult to adapt to the modeling needs of complex systems. Traditional FTA requires manual sorting of system hierarchy and disassembly of fault causal chain (such as tracing back from "autonomous driving function failure" to "LiDAR failure" "algorithm decision error" and other basic events), and requires one-to-one communication with the technical documents of mechanical, electronic and software teams, which consumes a lot of time and is difficult to match the rapid development pace of vehicles.

[0003] (2) Human error is difficult to avoid: affecting the reliability of analysis results. Manual modeling is prone to logical loopholes due to cognitive biases of complex systems. For example, when analyzing "failure of intelligent braking system", the human may ignore the coupling relationship between "CAN bus communication delay" and "mechanical jamming of brake actuator", resulting in the FTA logic tree missing key bottom events.

[0004] (3) Difficult to adapt to design changes: Changing one part affects the whole system. The functional safety concept stage often iterates the system design, such as adding functions and replacing components. However, traditional FTAs ​​are extremely inflexible and have low efficiency in modification. Taking the system change from "single radar" to "radar + lidar fusion" as an example, traditional FTAs ​​need to re-sort out the top event of "perception failure", delete old logic, add new logic, and even overturn and redraw the fault tree, which is very time-consuming and labor-intensive. Summary of the Invention

[0005] In view of this, this application aims to provide a method, system, electronic device and storage medium for generating road vehicle safety analysis, in order to solve at least one of the above problems.

[0006] To achieve the above objectives, the technical solution of this application is implemented as follows: Firstly, this application provides a method for generating road vehicle safety analysis, including: Obtain relevant item definition documents and HARA analysis documents for road vehicles, and extract basic information and key parameters about the events for constructing fault tree analysis to build structured data; Based on the structured data, and by constructing association reasoning instructions through the Prompt project, a multi-level association mapping is established. Based on the association mapping results, a preliminary event hierarchy for fault tree analysis is generated, and a preliminary reasoning result containing event name and association source is output. Based on the preliminary reasoning results, a complete structured fault tree is constructed according to a preset process, wherein the preset process includes top event definition, intermediate event standardization and decomposition, bottom event refinement and ASIL level allocation and logic gate allocation; The results are verified based on the structured fault tree, and a fault tree analysis document in a standard format is output.

[0007] Secondly, based on the same inventive concept, this application also provides a road vehicle safety analysis and generation system, comprising: The related item definition parsing module is configured to obtain the related item definition document of road vehicles and extract basic information about events for building fault tree analysis. The HARA parsing module is configured to acquire HARA analysis documents of road vehicles and extract key parameters about events that contribute to the construction of fault tree analysis. The AI ​​large model inference module is configured to receive the basic information output by the related item definition parsing module and the key parameters output by the HARA parsing module, construct the association inference instructions through the Prompt project, establish a multi-level association mapping, generate the preliminary event level of fault tree analysis based on the association mapping results, and output the preliminary inference results containing the event name and the association source. The FTA logic construction module is configured to receive the preliminary inference results output by the AI ​​large model inference module and construct a complete structured fault tree according to a preset process. The preset process includes top event definition, intermediate event standardization decomposition, bottom event refinement and ASIL level allocation, and logic gate allocation. The result verification and output module is configured to verify the results based on the structured fault tree constructed by the FTA logic construction module and output a fault tree analysis document in a standard format.

[0008] Thirdly, based on the same inventive concept, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect.

[0009] Fourthly, based on the same inventive concept, this application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the method as described in the first aspect.

[0010] Compared with existing technologies, the road vehicle safety analysis generation method, system, electronic device, and storage medium described in this application have the following advantages: (1) Significantly improved efficiency: Automatically completes document information extraction, cross-document association reasoning, fault tree analysis construction and verification, shortening the traditional manual fault tree analysis generation cycle of several days to several hours, greatly improving development efficiency; (2) Completeness is guaranteed: The bottom event is broken down into four dimensions: “input-output-itself-execution end” to ensure that no event is missed in the fault tree analysis and avoid the problem of missing dimensions in traditional manual analysis; (3) Strict and controllable compliance: ASIL level allocation and decomposition are completed based on GB / T 34590 standard, and compliance verification is combined to ensure that fault tree analysis complies with functional safety standards and reduce errors in manual compliance judgment; (4) Clear traceability: Each fault tree analysis event is marked with the document source and ASIL level basis, which facilitates functional safety audit and rectification in the later stage and reduces the difficulty of engineering verification; (5) High versatility: It is compatible with various road vehicle systems such as braking, steering, and power control. Only the relevant item definitions and HARA documents of the corresponding system need to be uploaded to generate a dedicated fault tree analysis. There is no need to repeatedly develop parsing logic for a single system. Attached Figure Description

[0011] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a road vehicle safety analysis generation method according to an embodiment of this application; Figure 2 This is a schematic diagram of the ABS function fault tree analysis in the braking system described in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of a road vehicle safety analysis and generation system according to an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of the electronic device described in an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0013] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0014] AI large-scale models have significant advantages in natural language understanding, logical reasoning, and knowledge integration. Applying them to road vehicle safety analysis can effectively improve the automation and accuracy of the analysis. Against this backdrop, this embodiment proposes a road vehicle safety analysis generation method based on AI large-scale models. Leveraging the deep learning and logical reasoning capabilities of AI large-scale models, this method revolutionizes the FTA analysis model, improves the efficiency and depth of road vehicle safety analysis, and ensures vehicle safety throughout its entire lifecycle.

[0015] The embodiments of this application are described in detail below with reference to the accompanying drawings.

[0016] Please see Figure 1 As shown, this embodiment provides a method for generating road vehicle safety analysis data, which includes the following steps: Step S10: Obtain the relevant item definition documents and HARA analysis documents for road vehicles, and extract basic information and key parameters about the events for constructing fault tree analysis to build structured data.

[0017] Specifically, in this embodiment, by receiving road vehicle-related item definition documents (such as braking system and steering system-related item documents), a fusion algorithm of "image parsing + text semantic analysis + table structuring" is used to selectively extract fault tree analysis (FTA, hereinafter referred to as FTA) to construct the necessary core information, as described below: By employing image recognition and feature matching algorithms, the core components (such as the IPB, wheel speed sensor, and brake controller of the braking system, and the steering angle sensor and EPS motor of the steering system) and component connection relationships in the system structure diagram of the relevant item definition document are extracted, and a "component-connection relationship" structured table is generated to provide hardware basis for failure analysis of the FTA execution end. By using semantic word segmentation and keyword recognition (such as "function", "sub-function", "effect", "purpose"), we extract the core functions (such as "anti-lock braking system (ABS)"), sub-function list and corresponding function description (such as "ABS function "prevents wheel lock-up by adjusting brake hydraulic pressure and improves steering stability") from the document, and establish a "function-sub-function-description" mapping table to provide functional basis for the definition of intermediate events in the FTA. The system boundary diagram in the document is analyzed to identify the interaction between relevant items and external systems (such as airbag controller, instrument panel, and vehicle controller). The sending end, receiving end, and signal type of key signals (such as the pulse signal sent by the wheel speed sensor to the brake controller and the CAN format longitudinal acceleration signal sent by the airbag controller to the brake controller) are extracted to generate a "signal-interaction relationship" table, providing signal basis for FTA input / output failure analysis. For each function, the function logic (such as "repeatedly adjusting hydraulic pressure when slip ratio exceeds threshold" in the ABS function), activation conditions (such as "slip ratio > X% and brake pedal depressed and system has no fault" in the ABS function), and exit conditions (such as "slip ratio < X% or pedal released" in the ABS function) are extracted through rule matching algorithms. The logical conditions are transformed into structured data of "function-activation condition-exit condition-control strategy" to provide a logical basis for the failure analysis of the FTA function itself.

[0018] By receiving HARA (Hazard Analysis and Risk Assessment) documents for road vehicles, and using a "table parsing + keyword filtering" algorithm, only the key parameters necessary for FTA construction are extracted, while redundant information such as scenario parameters is excluded. The specific extracted content is as follows: (1) Safety target extraction: Identify the content in the document marked with "safety target" or "SG-XX" (such as "SG-01: avoid unexpected reduction of braking force" and "SG-02: avoid unexpected vehicle lock-up during emergency braking"), generate a list of safety targets, and use it as the sole source of the top event of the FTA; (2) Safety status extraction: Extract the safety status corresponding to each safety target (such as "ABS function off + fault alarm prompt") to provide a basis for the fault response logic of FTA events; (3) Extraction of ASIL level (i.e., vehicle safety integrity level): Extract the ASIL level (e.g., ASIL B, ASIL D) corresponding to each safety target, associate it with the level determination criteria in the HARA document (e.g., hazard level, exposure rate, controllability), and generate the "Safety Target-ASIL Level-Determination Criteria" table to provide a standard basis for the allocation and decomposition of ASIL levels for FTA events.

[0019] Step S20: Based on the structured data, construct the association reasoning instructions through the Prompt project, establish a multi-level association mapping, generate the preliminary event hierarchy of fault tree analysis based on the association mapping results, and output the preliminary reasoning results containing event names and association sources.

[0020] Specifically, in this embodiment, this step utilizes a large AI model (such as DeepSeek, Doubao, Tencent Yuanbao, etc.) for inference. This model is pre-trained with a dedicated dataset for road vehicle functional safety, which covers the full text of the GB / T34590-2022 standard, FTA event association rules (such as "safety objectives must be associated with core functions, and core functions must be associated with implementing components"), and historical FTA cases for multiple systems such as braking and steering. This step is detailed below: After receiving the basic information and key parameters output in step S101, the associated reasoning instruction is constructed through the Prompt project (such as "associating safety target SG-01: avoid unexpected reduction of braking force to the corresponding function in the relevant item definition, and matching the core components and signals that implement this function"), and a multi-level associated mapping of "safety target → core function → functional logic → component / signal" is established. For example: SG-01 → ABS function → ABS activation condition → wheel speed sensor (component), wheel speed signal (signal). Based on the association mapping results, the preliminary event hierarchy of FTA is generated through reasoning, namely, top event (safety target) → intermediate events (input, output, itself, execution failure) → candidate bottom event (component / signal / logic failure, such as "wheel speed sensor failure", "wheel speed signal loss", "ABS activation condition not met"), and the preliminary reasoning results containing event name and association source (such as "wheel speed sensor failure comes from the list of related components") are output.

[0021] Step S30: Based on the preliminary reasoning results, construct a complete structured fault tree according to the preset process. The preset process includes top event definition, intermediate event standardization and decomposition, bottom event refinement and ASIL level allocation, and logic gate allocation.

[0022] Specifically, in this embodiment, the preliminary inference result output in step S102 is received, and a complete structured fault tree is constructed according to the four-step process of "top event definition → intermediate event standardization decomposition → bottom event refinement and ASIL level allocation → logic gate definition", which specifically includes the following steps: Step S301, Define the top event.

[0023] The extracted security objectives are mapped to FTA top events. The top event name adopts the standardized format of "violation + security objective description" (e.g., "violation SG-01: avoid unintended reduction of braking force") and inherits the ASIL level of the corresponding security objective (e.g., if SG-01 is ASIL B, then the top event ASIL level is B). At the same time, the security objective number and source are marked (e.g., "from HARA document SG-01").

[0024] Step S302: Standardized decomposition of intermediate events.

[0025] Based on the initial event hierarchy derived from AI large-scale model inference, the top event is broken down into several intermediate events. Each intermediate event must correspond to the failure of a core function in the relevant item definition document (such as "ABS function failure" or "basic braking function failure"), and must follow these rules: Intermediate events and top events must have a direct causal relationship (e.g., "ABS function failure" is the direct cause of "violation of SG-01"); each intermediate event must cover the entire failure scenario of the corresponding function (e.g., "ABS function failure" must cover the entire chain including signal processing, logic execution, and actuators); the ASIL level of the intermediate event must be consistent with that of the top event (e.g., ...). Figure 2 As shown, the top event is ASIL B, and all intermediate events below it are also ASIL B, ensuring the integrity of security level transmission.

[0026] Step S303: Detailed breakdown of underlying events and ASIL level allocation.

[0027] Using intermediate events as parent nodes, the underlying events are refined according to four dimensions: "input failure, output failure, function failure, and execution failure." These four dimensions are related by an "OR" relationship (meaning that the occurrence of an underlying event in any one dimension can directly lead to the occurrence of an intermediate event), as detailed below: Input failure corresponds to abnormal input signals in the "Signal Interaction" definition, including sensor signal loss and signal delay; output failure corresponds to abnormal output signals in the "Signal Interaction" definition, including instruction delay and instruction not being sent; functional failure corresponds to abnormalities in the "Functional Logic" definition, including failure to execute when activation conditions are met, premature exit when exit conditions are not met, and deviation in control strategy execution; execution failure corresponds to hardware failure of core execution components in the "System Layout" definition, including mechanical jamming, electrical faults, and performance degradation.

[0028] Step S304: Logic gate allocation.

[0029] Based on the causal relationships between events, logic gates are assigned to connect intermediate events and underlying events, with the following specific rules: An AND gate is used when an intermediate event requires multiple underlying events to be satisfied simultaneously. It typically corresponds to the "multi-condition constraint for function activation / execution" in the definition of related terms. For example, "ABS function not activated" requires the simultaneous satisfaction of three conditions: "slip ratio not exceeding the threshold," "brake pedal not depressed," and "system malfunction," hence an AND gate is used. An OR gate is used when an intermediate event only requires a single underlying event to occur. It typically corresponds to "multiple independent paths of functional failure". For example, the intermediate event of "ABS functional failure" can be triggered by any one of the underlying events: "input failure (loss of wheel speed signal)", "output failure (instruction delay)", "functional failure (strategy not executed)" or "execution failure (motor jamming)". Therefore, an OR gate is used to connect them.

[0030] The logic gate annotation requirement is that all logic gates must be annotated with the associated functional logic basis (such as "AND gate, corresponding to the three-condition constraint for ABS function activation in the related item definition document"), to ensure that the logical relationship can be traced back to the original document.

[0031] Step S40: Verify the results based on the structured fault tree and output a fault tree analysis document in a standard format.

[0032] Specifically, in this embodiment, this step involves dual verification through integrity checks and compliance checks to ensure that the FTA meets the requirements before outputting a standard document. The specific functions are as follows: (1) Completeness verification: ① Security target coverage check: Confirm that all security targets extracted by HARA have been converted into FTA top events without omission; ② Bottom event dimension check: Confirm that the bottom events decomposed from each intermediate event fully cover the four dimensions of "input-output-function itself-execution end" without any missing dimensions (e.g., the intermediate event "ABS function failure" must simultaneously include input, output, function itself, and execution end failure type bottom events).

[0033] (2) Compliance verification: Based on the GB / T 34590 standard and FTA construction specifications, three core checks are performed. ① ASIL level verification: Check whether the ASIL level allocation and decomposition of the top event, intermediate event and bottom event comply with the standard rules (e.g., whether the decomposed level combination meets the requirement of "single path does not reduce security level"), and whether the level labeling is complete; ② Logic gate verification: Check whether the logic gate allocation is consistent with the causal relationship of the event (e.g., whether the AND gate is correctly used for "multi-condition triggered" events), and whether the logic gate labeling is clear; ③ Event traceability verification: Check whether each event is labeled with the associated document source (e.g., the chapter of the relevant item definition document, the security target number of the HARA document), and whether the traceability information is complete.

[0034] (3) Document output: After verification, three types of standard format documents are output. ① Editable fault tree diagram: Visio format, including top event, intermediate event, bottom event, logic gate and the connection relationship between events, with ASIL level and source marked next to each event; ② Event list table: Excel format, classified by the fields "event level (top / intermediate / bottom) - event name - ASIL level - failure dimension (input / output / itself / execution end) - document source - remarks", which is convenient for engineers to trace and modify; ③ Compliance verification report: PDF format, including completeness verification results (such as "covering 3 security objectives in total, no omissions"), compliance verification results (such as "ASIL level allocation complies with GB / T 34590 standard, logic gate allocation has no errors") and rectification suggestions for items that fail verification.

[0035] The road vehicle safety analysis generation method described in this embodiment can quickly complete FTA analysis and effectively reduce human error. It can also be adapted to various road vehicle systems such as braking, steering, and power control.

[0036] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0037] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, embodiments of this application also provide a road vehicle safety analysis and generation system, such as... Figure 3As shown, the core of this system consists of five core units working together: a related item definition parsing module 11, a HARA parsing module 12, an AI large-scale model inference module 13, an FTA logic construction module 14, and a result verification and output module 15. Each module achieves a closed-loop chain of "definition input - HARA parsing - intelligent inference - FTA generation - compliant output" through standardized data interfaces. The specific modules are described below: The related item definition parsing module 11 is configured to obtain the related item definition document of road vehicles and extract basic information about the events for constructing fault tree analysis. HARA parsing module 12 is configured to acquire HARA analysis documents of road vehicles and extract key parameters about events that contribute to the construction of fault tree analysis. The AI ​​large model inference module 13 is configured to receive the basic information output by the related item definition parsing module 11 and the key parameters output by the HARA parsing module 12, construct the association inference instructions through the Prompt project, establish a multi-level association mapping, generate the preliminary event level of fault tree analysis based on the association mapping results, and output the preliminary inference results containing the event name and the association source. The FTA logic construction module 14 is configured to receive the preliminary inference results output by the AI ​​large model inference module 13 and construct a complete structured fault tree according to a preset process. The preset process includes top event definition, intermediate event standardization decomposition, bottom event refinement and ASIL level allocation, and logic gate allocation. The result verification and output module 15 is configured to verify the results based on the structured fault tree constructed by the FTA logic construction module 14 and output a fault tree analysis document in a standard format.

[0038] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware.

[0039] The apparatus of the above embodiments is used to implement the corresponding method in any of the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0040] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the methods described in any of the above embodiments.

[0041] Figure 4This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0042] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0043] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0044] The input / output interface 1030 is used to connect input / output modules to realize information input and output. The input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0045] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0046] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0047] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0048] The electronic devices described above are used to implement the corresponding methods in any of the foregoing embodiments and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0049] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to perform the methods described in any of the above embodiments.

[0050] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0051] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to perform the methods described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0052] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.

[0053] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0054] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0055] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A road vehicle safety analysis generation method, characterized by, The method comprises the following steps: Obtain the relevant item definition document and the HARA analysis document of the road vehicle, extract the basic information and key parameters related to the construction of the fault tree analysis event, and construct the structured data; According to the structured data, and by constructing the correlation reasoning instruction through Prompt engineering, a multi-level correlation mapping is established, and a preliminary event level of the fault tree analysis is generated based on the correlation mapping result, and a preliminary reasoning result containing the event name and the correlation source is outputted; Based on the preliminary reasoning result, a complete structured fault tree is constructed according to a preset process, wherein the preset process includes top event definition, intermediate event standardization decomposition, bottom event refinement, ASIL level allocation and logic gate allocation; According to the structured fault tree, the result is checked, and a fault tree analysis document in a standard format is outputted.

2. The method of claim 1, wherein: extracting the core components and component connection relationships in the system structure block diagram in the relevant item definition document through image recognition and feature matching algorithm, and generating a "component-connection relationship" structured table; extracting each core function and corresponding function description in the relevant item definition document through semantic word segmentation and keyword recognition, and establishing a "function-subfunction-description" mapping table; parsing the "system boundary block diagram" content in the relevant item definition document, identifying the interaction relationship between the relevant item and the external system, extracting the sending end, receiving end and signal type of the key signal, and generating a "signal-interaction" table; for each function, extracting the function logic, activation condition and exit condition through a rule matching algorithm, and converting the logic condition into "function-activation condition-control strategy" structured data.

3. The method of claim 1, wherein: identifying the content with a specific identifier in the HARA analysis document to generate a safety target list; extracting the safety state and ASIL level corresponding to each safety target to generate a "safety target-ASIL level-judgment basis" table.

4. The method of claim 3, wherein: the top event definition includes mapping the extracted safety target to the fault analysis top event, inheriting the ASIL level corresponding to the safety target, and labeling the safety target number and source; the intermediate event standardization decomposition includes decomposing the top event into several intermediate events based on the preliminary event level, wherein the intermediate events correspond to the core function failure in the relevant item definition document and meet the preset rules; the bottom event refinement includes refining the bottom event with the intermediate event as the parent node in four dimensions of "input failure, output failure, function failure and execution failure", and the dimensions satisfy the "or" relationship.

5. The method of claim 4, wherein: the input failure corresponds to the input signal abnormality of "signal interaction" in the relevant item definition; the output failure corresponds to the output signal abnormality of "signal interaction" in the relevant item definition; the function failure corresponds to the abnormality of "function logic" in the relevant item definition; the execution failure corresponds to the hardware failure of the core execution component in the "system layout" in the relevant item definition.

6. The method of claim 3, wherein: According to the causal relationship between each event, logical gates are assigned to the connection between intermediate events and bottom events, including: When the occurrence of an intermediate event requires multiple bottom events to be satisfied at the same time, an AND gate is used; When the occurrence of an intermediate event only requires a single bottom event to be satisfied, an OR gate is used.

7. The method of claim 1, wherein: the result verification includes integrity verification and compliance verification; wherein the integrity verification includes security target coverage checking and bottom event dimension checking; the compliance verification includes ASIL level checking, logical gate checking and event traceability checking.

8. A road vehicle safety analysis generation system characterized by, including: a related item definition analysis module configured to obtain a related item definition document of a road vehicle, and extract basic information about constructing fault tree analysis events; a HARA analysis module configured to obtain a HARA analysis document of a road vehicle, and extract key parameters about constructing fault tree analysis events; an AI large model inference module configured to receive the basic information output by the related item definition analysis module and the key parameters output by the HARA analysis module, construct an associated inference instruction through Prompt engineering, establish a multi-level association mapping, and generate a preliminary event level of fault tree analysis based on the association mapping result, and output a preliminary inference result containing event names and associated sources; an FTA logic construction module configured to receive the preliminary inference result output by the AI large model inference module and construct a complete structured fault tree according to a preset process, wherein the preset process includes top event definition, intermediate event standardization decomposition, bottom event refinement and ASIL level allocation, and logical gate allocation; a result verification and output module configured to perform result verification according to the structured fault tree constructed by the FTA logic construction module, and output a standard format fault tree analysis document.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium, comprising: wherein, the non-transitory computer readable storage medium stores computer instructions for causing a computer to execute the method of any one of claims 1-7.

Images