Method for processing vehicle functional safety standard data and electronic device

Abstract

This application discloses a method and electronic device for processing vehicle functional safety standard data. The method includes: generating standardized hazard scenario information based on vehicle functional data, and assessing the hazard scenario information using risk parameters to obtain preliminary safety level information, whereby risk parameters include exposure rate, severity, and controllability; performing dual-benchmark cross-validation on the preliminary safety level information to obtain validated target safety level information and corresponding functional safety objectives; extracting vehicle system architecture information based on the functional safety objectives, and generating fault tree analysis information by combining the functional safety objectives and vehicle system architecture information; calling a functional safety requirement generation model, generating functional safety requirement information based on the fault tree analysis information, and performing compliance verification on the functional safety requirement information to obtain the vehicle's target functional safety requirement information. The technical solution provided in this application can improve the processing efficiency of vehicle functional safety standard data.

Description

Technical Field

[0001] This application belongs to the field of vehicle functional safety technology, and in particular relates to a method for processing vehicle functional safety standard data and an electronic device. Background Technology

[0002] As the automotive industry enters the era of software-defined vehicles, the complexity of vehicle electronic and electrical systems continues to increase. Functional safety development has become a core part of vehicle research and development, and the processing of vehicle functional safety standard (i.e., ISO26262 standard) data is a key foundation for functional safety development. Its processing efficiency and accuracy directly determine the compliance and development progress of vehicle functional safety design.

[0003] However, current vehicle functional safety standard data processing relies heavily on manual intervention. Core tasks such as hazard scenario analysis, risk level assessment, fault tree construction, and functional safety requirement generation must be completed manually. This not only consumes significant manpower and time but is also prone to data processing errors due to manual operation. Furthermore, processing data using a single model can easily lead to distorted results, causing safety level determinations to deviate from the logic of functional safety standards. The traceability of each stage of data processing is also poor; changes in requirements necessitate manual updates of all related data across the entire chain, and historical project data cannot be effectively reused. The overall processing flow is slow and difficult to keep pace with the agile development of vehicles.

[0004] Therefore, how to improve the processing efficiency of vehicle functional safety standard data while ensuring the accuracy and compliance of data processing has become an urgent technical problem to be solved. Summary of the Invention

[0005] The embodiments of this application provide a method, apparatus, computer program product, computer-readable storage medium, and electronic device for processing vehicle functional safety standard data, which can at least improve the processing efficiency of vehicle functional safety standard data to a certain extent.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to a first aspect of the embodiments of this application, a method for processing vehicle functional safety standard data is provided. The method includes: generating standardized hazard scenario information based on vehicle functional data, and assessing the hazard scenario information for risk parameters to obtain preliminary safety level information, wherein the risk parameters include exposure rate, severity, and controllability; performing dual-benchmark cross-validation on the preliminary safety level information to obtain verified target safety level information and corresponding functional safety targets; extracting vehicle system architecture information based on the functional safety targets, and generating fault tree analysis information by combining the functional safety targets and the vehicle system architecture information; calling a functional safety requirement generation model, generating functional safety requirement information based on the fault tree analysis information, and performing compliance verification on the functional safety requirement information to obtain target functional safety requirement information for the vehicle.

[0008] In some embodiments of this application, based on the aforementioned scheme, the step of evaluating the risk parameters of the hazard scenario information to obtain preliminary safety level information includes: based on the core features in the hazard scenario information, calling a pre-trained student model to score each risk parameter and generating a score description corresponding to each risk parameter; calculating the preliminary safety level information according to the algorithm of the vehicle functional safety standard, combined with the score results of each risk parameter, wherein the preliminary safety level information also includes the safety target and safety status corresponding to the hazard scenario information.

[0009] In some embodiments of this application, based on the aforementioned scheme, the step of performing dual-benchmark cross-validation on the preliminary safety level information to obtain the validated target safety level information and the corresponding functional safety target includes: calling two pre-trained, independent teacher models as validation benchmarks, and performing parallel evaluations on each risk parameter and the preliminary safety level in the preliminary safety level information to obtain evaluation results of the two validation benchmarks; performing deviation sign quantization on the two evaluation results, and assigning dynamic weights to each risk parameter according to the deviation sign quantization results; calculating the safety level difference between the two evaluation results under the dynamic weights, and determining whether the safety level difference is within a preset compliance range; if the safety level difference is within the preset compliance range, determining the preliminary safety level information as the target safety level information, and extracting the corresponding functional safety target; if the safety level difference exceeds the preset compliance range, regenerating the hazard scenario information and performing risk parameter evaluation, while updating the evaluation benchmark of the teacher model.

[0010] In some embodiments of this application, based on the aforementioned scheme, the step of quantifying the deviation sign of the two evaluation results and assigning dynamic weights to each risk parameter according to the deviation sign quantification result includes: quantifying the degree of deviation of the two evaluation results using multi-level deviation signs, wherein the multi-level deviation signs include maximum positive deviation, slight positive deviation, no deviation, slight negative deviation, and maximum negative deviation; increasing the weight ratio of risk parameters corresponding to no deviation and slight deviation, and decreasing the weight ratio of risk parameters corresponding to maximum positive deviation and maximum negative deviation.

[0011] In some embodiments of this application, based on the foregoing scheme, the step of extracting vehicle system architecture information based on the functional safety objective includes: obtaining vehicle function definition specification documents, system controller and key component description documents; and performing structured parsing of the vehicle function definition specification documents, the system controller and the key component description documents using the functional safety objective call parsing model to extract and generate vehicle system architecture information containing architecture element descriptions, system function descriptions, static architecture descriptions and dynamic architecture descriptions, wherein the static architecture descriptions are the physical connection relationships of the architecture elements and the dynamic architecture descriptions are the signal transmission methods of the architecture elements.

[0012] In some embodiments of this application, based on the foregoing scheme, the step of generating fault tree analysis information by combining the functional safety objective and the vehicle system architecture information includes: taking the vehicle-level hazard event corresponding to the functional safety objective as the top-level event, performing hierarchical decomposition on the top-level event to obtain intermediate events and basic events, and recording the logical relationships between each event; using a recursive traversal algorithm to detect the decomposed events, and determining whether the events cover all controller nodes in the vehicle system architecture information; if the events cover all controller nodes, generating fault tree analysis information containing the top-level event, intermediate events, basic events, and the logical relationships between each event; if the events do not cover all controller nodes, re-decomposing the top-level event hierarchically and detecting the events.

[0013] In some embodiments of this application, based on the foregoing scheme, the step of generating functional safety requirement information based on the fault tree analysis information includes: obtaining functional safety requirement reference information by means of model prompt word input or vector library retrieval based on vehicle functional safety standards and the fault tree analysis information; generating functional safety requirement basic information including expected functional description, fault diagnosis mechanism, and fault handling mechanism for each basic event in the fault tree analysis information based on the functional safety requirement reference information; assigning a corresponding safety level to the functional safety requirement basic information, designing a corresponding redundancy mechanism according to the assigned safety level, and assigning time constraints to the functional safety requirement basic information in combination with the fault tolerance interval time of the vehicle functional safety target; and formatting the functional safety requirement basic information after adding safety level, redundancy mechanism, and time constraints based on the functional safety requirement reference information to generate functional safety requirement information including unique identifier, name, description, time constraint, safety level, software component, controller, event identifier, and signal code.

[0014] In some embodiments of this application, based on the foregoing scheme, the step of performing compliance verification on the functional safety requirement information to obtain the target functional safety requirement information of the vehicle includes:

[0015] The functional safety requirement information is checked item by item using a pre-created script to verify the completeness of the fields and the consistency of the upstream and downstream traceability chains. The coverage of the functional safety requirement information to the fault tree analysis information and the description coverage to the vehicle system controller are calculated. If the functional safety requirement information has complete fields, a consistent traceability chain, and coverage reaches a preset threshold, the functional safety requirement information is identified as the target functional safety requirement information. If the preset requirements are not met, the functional safety requirement information is regenerated and compliance verification is performed.

[0016] In some embodiments of this application, based on the aforementioned scheme, after obtaining the target functional safety requirements information of the vehicle, the method further includes: storing hazard scenario information, risk parameter assessment data, safety level verification data, vehicle system architecture information, fault tree analysis information, functional safety requirements information, and verification data of each stage in an itemized manner, and setting a unique association identifier for the data of each stage to achieve traceability of the entire process data; classifying and labeling the itemized processed data according to valid data and invalid data, and labeling the deviation reasons and correction schemes of invalid data; constructing a continuous learning model based on the labeled processed data, and fine-tuning and optimizing the student model for assessing risk parameters, the teacher model for verifying safety levels, and the functional safety requirements generation model through the continuous learning model; and reusing historical knowledge by retrieving the itemized processed data in subsequent data processing to improve data processing efficiency.

[0017] According to a second aspect of the embodiments of this application, a processing apparatus for vehicle functional safety standard data is provided. The apparatus includes: an evaluation unit, configured to generate standardized hazard scenario information based on vehicle functional data, and to evaluate the hazard scenario information for risk parameters to obtain preliminary safety level information, wherein the risk parameters include exposure rate, severity, and controllability; a verification unit, configured to perform dual-benchmark cross-validation on the preliminary safety level information to obtain verified target safety level information and corresponding functional safety targets; a first generation unit, configured to extract vehicle system architecture information based on the functional safety targets, and to generate fault tree analysis information by combining the functional safety targets and the vehicle system architecture information; and a second generation unit, configured to invoke a functional safety requirement generation model, generate functional safety requirement information based on the fault tree analysis information, and to perform compliance verification on the functional safety requirement information to obtain target functional safety requirement information for the vehicle.

[0018] According to a third aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor to cause a computer device having the processor to perform an operation as described in any of the first aspects above.

[0019] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by a processor to perform the operation as described in any of the first aspects above.

[0020] According to a fifth aspect of the present application, an electronic device is provided, the electronic device including one or more processors and one or more memories, the one or more memories storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the one or more processors to perform the operation as described in any of the first aspects above.

[0021] Based on the technical solution proposed in this application, by automating the processing of vehicle functional safety standard data in stages, the deviation and human time costs caused by manual operation can be reduced. At the same time, the standardized process design ensures that the data format of each link is unified, which solves the problem of poor data traceability in the traditional processing process, realizes the effective association of data in the whole chain, and can also significantly shorten the processing time of functional safety standard data, thereby greatly improving the processing efficiency of vehicle functional safety standard data and adapting to the pace of agile vehicle development. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating a method for processing vehicle functional safety standard data according to an embodiment of this application is shown; Figure 2 A block diagram of a vehicle functional safety standard data processing device according to an embodiment of this application is shown; Figure 3 A schematic diagram of the vehicle structure in an embodiment of this application is shown. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0025] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices. It should also be noted that, for the sake of simplicity, certain components in the drawings that do not affect the interpretation of the technical solution of this application have been appropriately omitted.

[0026] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined. Therefore, the actual execution order may change depending on the actual situation.

[0027] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0028] This application proposes a processing scheme for vehicle functional safety standard data, which aims to solve the problems of high manual dependence, low efficiency, poor accuracy and poor traceability in the processing of vehicle functional safety standard data in the prior art. It aims to realize the automated and standardized processing of functional safety standard data, improve processing efficiency and accuracy, and at the same time ensure the compliance and traceability of the entire data processing process.

[0029] Next, this application will elaborate on the proposed data processing scheme for vehicle functional safety standards. (Refer to...) Figure 1 The flowchart illustrates a method for processing vehicle functional safety standard data according to an embodiment of this application. This method can be executed by a device with computational processing capabilities, such as... Figure 1 As shown, the method includes at least steps 110 to 140, which are described in detail below: In step 110, standardized hazard scenario information is generated based on vehicle function data, and risk parameters are assessed on the hazard scenario information to obtain preliminary safety level information. The risk parameters include exposure rate, severity, and controllability.

[0030] In this application, standardized hazard scenario information can be generated based on vehicle function data. Standardized hazard scenario information refers to relevant information that is organized in a unified format and contains possible vehicle function failures and corresponding hazards. Its format and content must comply with the requirements of the ISO26262 functional safety standard. It can unify the data format and provide a standardized and consistent input basis for subsequent risk parameter assessment.

[0031] Specifically, in such Figure 1 In step 110, the generation of standardized hazard scenario information based on vehicle function data can be performed according to steps 111 to 112 as follows: Step 111: Obtain the vehicle function checklist as the vehicle function data.

[0032] Step 112: The model is invoked using a few-shot learning approach. Based on the vehicle function checklist, the failure modes of the vehicle functions are analyzed item by item to generate standardized hazard scenario information, which includes hazard identification, function failure description, failure impact, vehicle-level hazard, scenario description, and hazard event description.

[0033] In this application, when generating standardized hazard scenario information based on vehicle functional data, the first step is to obtain a vehicle functional checklist as the core vehicle functional data. This checklist forms the basis for organizing the various functional modules of the vehicle and defining the scope of fault analysis, covering all functional items that require functional safety analysis and clarifying the object and scope of functional safety standard data processing. Subsequently, a few-shot learning approach is used to invoke the model. This approach allows the model to master the standardized generation logic through only a small number of hazard scenario examples. Based on the vehicle functional checklist, the model analyzes the fault modes of vehicle functions item by item, generating standardized hazard scenario information according to fixed field requirements. This information includes hazard identification, functional fault description, failure impact, vehicle-level hazard, scenario description, and hazard event description. Each field is interconnected, forming a complete hazard scenario description system. The hazard identification assigns a unique identification code to each hazard scenario, facilitating data traceability in subsequent stages. The functional fault description clarifies the specific fault type of the vehicle function; the failure impact explains the effect of the fault on the function itself; the vehicle-level hazard defines the degree of harm to the overall vehicle safety after the fault escalates; the scenario description recreates the specific vehicle operating scenario in which the fault occurred; and the hazard event description summarizes the complete event process of the fault occurrence.

[0034] For example, taking the electric brake assist function of a car as an example, the first step is to obtain a list of vehicle function points for the electric brake assist function. This list clarifies the analysis items such as the actuator, sensor, and control module of the electric brake assist. Then, a small-sample learning approach is used to call a large model, inputting a few hazardous scenario examples such as brake assist sensor failure and assist motor jamming into the model. The model analyzes the failure modes of the electric brake assist function item by item based on this list, generating standardized hazardous scenario information. One such scenario is marked with a hazard label of E01, describing the functional failure as a signal acquisition failure of the electric brake assist sensor, the impact of which is a deviation in the calculation of brake assist magnitude, and the vehicle-level hazard as an increased braking distance leading to a vehicle collision. The scenario description is that when a vehicle is traveling at 40 km / h on an urban road, the brake assist sensor suddenly experiences a signal acquisition failure. The hazardous event description is that during vehicle operation, the electric brake assist sensor signal acquisition failure leads to a deviation in brake assist calculation, resulting in a longer braking distance and increasing the risk of a vehicle collision.

[0035] In this application, by using a vehicle function checklist as a basis and combining it with few-shot learning to generate standardized hazard scenario information, the model can quickly adapt to the fault analysis needs of different vehicle functions without retraining the model for each function, thus improving the efficiency of hazard scenario information generation. At the same time, the standardized field design ensures that all hazard scenario information has a unified format, avoiding the problems of format chaos and missing information in traditional manual sorting. This provides standardized and complete input data for subsequent risk parameter assessment. Furthermore, the unique hazard identifier enables accurate correlation between hazard scenario information and data in subsequent stages, laying the foundation for full-process data traceability and solving the problem of scattered and disordered data in traditional processing.

[0036] In this application, a risk parameter assessment is performed on the aforementioned hazard scenario information (i.e., an assessment of three core risk parameters: exposure rate, severity, and controllability). Preliminary safety level information can be obtained through quantitative risk parameter analysis, providing a preliminary quantitative assessment of the safety risks of vehicle functions. It should be noted that the exposure rate refers to the probability of vehicle functional failure occurring, the severity refers to the potential harm caused after the failure occurs, and the controllability refers to the driver's or vehicle system's ability to control the harm caused by the failure. These three parameters are the core basis for assessing the vehicle's functional safety level. The preliminary safety level information refers to the unverified vehicle functional safety level obtained based on the risk parameter assessment.

[0037] Specifically, in this application, the risk parameter assessment of the hazardous scenario information to obtain preliminary safety level information can be performed according to the following steps 113 to 114: Step 113: Based on the core features in the hazard scenario information, call the pre-trained student model to score each risk parameter and generate a score description corresponding to each risk parameter.

[0038] Step 114: Calculate preliminary safety level information according to the algorithm of the vehicle functional safety standard and the scoring results of each risk parameter. The preliminary safety level information also includes the safety target and safety status corresponding to the hazard scenario information.

[0039] In this application, the core features of the hazard scenario information can include key information reflecting the magnitude of risk, such as fault type, vehicle operating scenario, and overall vehicle hazard level. The pre-trained student model is a model trained on data related to vehicle functional safety standards. It has mastered the scoring logic of three types of risk parameters: exposure rate, severity, and controllability. It can accurately quantify and score each risk parameter based on the core features, and simultaneously generate corresponding scoring explanations for each risk parameter. The scoring explanations can explain in detail the basis and rationale for the scoring, making the scoring results of the risk parameters interpretable and verifiable, avoiding unfounded subjective scoring. Subsequently, preliminary safety level information is calculated according to the algorithm of vehicle functional safety standards, combined with the scoring results of each risk parameter.

[0040] In this application, the algorithm for the vehicle functional safety standard is based on the ISO26262 functional safety standard, which can convert quantified risk parameter scores into corresponding safety levels. This preliminary safety level information also includes safety objectives and safety states corresponding to the hazard scenario information. The safety objectives clarify the safety control effects that need to be achieved for the hazard scenario, while the safety states define the safe operating states that the vehicle functions need to enter after a failure occurs. The two correspond to the safety level information, providing a clear direction for subsequent safety level verification and functional safety design.

[0041] For example, taking the assessment of hazardous scenarios related to power steering in automobiles as an example, the hazardous scenario of "power steering motor jamming" is selected. Its core characteristics are that the fault occurs in a high-speed driving scenario, the overall vehicle hazard is loss of vehicle control, and the fault cannot be manually resolved by the driver. A pre-trained student model is used to score the risk parameters of this scenario. The exposure rate score is 3, indicating that the probability of this fault occurring when the vehicle is driving at high speed is 5% to 10%. The severity score is 4, indicating that the fault will lead to loss of vehicle control and cause serious personal injury. The controllability score is 1, indicating that the driver cannot resolve the impact of the fault through manual operation. Subsequently, according to the ISO26262 algorithm, combined with the scores of 3, 4, and 1, the preliminary safety level of this hazardous scenario is calculated as ASILC. At the same time, the corresponding safety objective is to avoid power steering motor jamming causing loss of vehicle control, and the safety state is that the power steering function immediately stops working, maintaining the basic mechanical steering state.

[0042] In this application, by calling a pre-trained student model and combining it with the core features of the hazard scenario to score risk parameters and generate scoring instructions, the risk parameter assessment process can be standardized and automated, reducing the subjective bias of manual assessment and making the scoring results more objective and verifiable. At the same time, the preliminary safety level information is calculated according to the algorithm of the vehicle functional safety standard, and safety targets and safety status are generated simultaneously. This allows the preliminary safety level information to be directly linked to the subsequent functional safety design requirements, avoiding the need to re-examine safety requirements in later stages, improving the overall processing efficiency. Furthermore, the quantitative risk parameter scoring makes the determination of safety level more scientific, solving the problems of vague and unclear safety level determination in traditional manual assessment.

[0043] Continue to refer to Figure 1 In step 120, the preliminary security level information is subjected to dual-benchmark cross-validation to obtain the verified target security level information and the corresponding functional safety target.

[0044] In this application, the step of performing dual-benchmark cross-validation on the preliminary security level information to obtain the validated target security level information and the corresponding functional safety target can be performed according to the following steps 121 to 124: Step 121: Call two pre-trained, independent teacher models as validation benchmarks to evaluate each risk parameter and the preliminary security level in the preliminary security level information in parallel, and obtain the evaluation results of the two validation benchmarks.

[0045] Step 122: Perform deviation sign quantification on the two evaluation results, and assign dynamic weights to each risk parameter based on the deviation sign quantification results.

[0046] Step 123: Calculate the security level difference between the two evaluation results under the dynamic weight, and determine whether the security level difference is within the preset compliance range.

[0047] Step 124: If the safety level difference is within a preset compliance range, the preliminary safety level information is determined as the target safety level information, and the corresponding functional safety target is extracted. If the safety level difference exceeds the preset compliance range, the hazard scenario information is regenerated and risk parameters are assessed, while the evaluation benchmark of the teacher model is updated.

[0048] In this application, both teacher models can be deeply trained according to vehicle functional safety standards, and the training benchmarks are different. The independent settings allow the two models to evaluate the preliminary safety level information from different perspectives, avoiding the evaluation bias of a single model. The risk parameters and preliminary safety level in the preliminary safety level information are evaluated in parallel to obtain the evaluation results of two verification benchmarks. The parallel evaluation method can improve the verification efficiency and allow the evaluation work of the two models to be carried out simultaneously without having to be performed sequentially.

[0049] In this application, the deviation sign of the two assessment results is quantified. The difference between the assessments of the two models is presented intuitively through quantification. Then, dynamic weights are assigned to each risk parameter based on the deviation sign quantification results. The allocation of dynamic weights allows the weight ratio of risk parameters to be adjusted according to the assessment differences, which is more in line with the actual safety risk assessment logic.

[0050] In this application, the safety level difference between two assessment results under dynamic weights is calculated. It is then determined whether this safety level difference falls within a preset compliance range. This preset compliance range, which can be set according to the ISO 26262 functional safety standard, is the core basis for determining the validity of the safety level assessment results. If the safety level difference is within the preset compliance range, it indicates that the preliminary safety level information meets the standard requirements, and it is identified as the target safety level information, with the corresponding functional safety objective extracted. If the safety level difference exceeds the preset compliance range, it indicates that the preliminary safety level information has a deviation. In this case, hazard scenario information needs to be regenerated and risk parameters assessed. Simultaneously, the teacher model's assessment benchmark needs to be updated so that the teacher model can avoid this deviation in subsequent assessments, improving assessment accuracy.

[0051] For example, taking the initial safety level verification of an adaptive cruise control function as an example, the initial safety level of this function is ASILB. Two pre-trained, independent teacher models, BaseA and BaseB, are used as verification benchmarks. BaseA uses Q / M as the evaluation benchmark, and BaseB uses A / B as the evaluation benchmark. The two models perform parallel evaluations of the function's exposure rate, severity, controllability, and initial safety level ASILB. BaseA's evaluation result is ASILB+, and BaseB's evaluation result is ASILC--. Subsequently, the deviation sign of the two evaluation results is quantified, and the deviation sign of each risk parameter is found to be slightly negative. Based on this result, the weighting of severity is increased, and the weighting of exposure rate is decreased. Next, the safety level difference between the two evaluation results under dynamic weights is calculated. It is determined that this difference is within the preset compliance range; therefore, the initial safety level ASILB is determined as the target safety level information, and the corresponding functional safety objective is extracted as avoiding abnormal following distance caused by adaptive cruise control function malfunctions. If the safety level difference calculated this time exceeds the preset compliance range, it is necessary to re-examine the hazard scenario information of the adaptive cruise function and conduct risk parameter assessment. At the same time, the assessment benchmarks of BaseA and BaseB should be updated to QM and A to make the subsequent assessments of the model more accurate.

[0052] In this application, by employing two independent teacher models for dual-benchmark cross-validation, the distortion of results when processing data with a single model can be effectively eliminated. This ensures that the safety level determination results comply with the logical requirements of the ISO 26262 functional safety standard, resolving the illusion problem of large models in functional safety analysis. Furthermore, through deviation sign quantification and dynamic weight allocation, the safety level verification process is made more aligned with the actual logic of safety risk assessment, improving the accuracy of the verification results. Moreover, by reprocessing unqualified results and updating the teacher model evaluation benchmarks, the model possesses self-optimization capabilities, continuously improving accuracy in subsequent evaluations. At the same time, the verified target safety level information and functional safety objectives provide accurate and compliant core basis for subsequent fault tree construction and functional safety requirement generation, ensuring the correctness of subsequent data processing steps.

[0053] Furthermore, in step 122 above, the step of performing deviation sign quantification on the two evaluation results and assigning dynamic weights to each risk parameter based on the deviation sign quantification results can be performed according to the following steps 1221 to 1222: Step 1221: Use multi-level deviation symbols to quantify the degree of deviation between the two evaluation results.

[0054] Step 1221: Increase the weighting of risk parameters corresponding to no bias and slight bias, and decrease the weighting of risk parameters corresponding to maximum positive bias and maximum negative bias.

[0055] In this application, the multi-level deviation symbols may include maximum positive deviation, slight positive deviation, no deviation, slight negative deviation, and maximum negative deviation. These five levels of deviation symbols comprehensively and meticulously reflect the degree of difference between the two teacher models in assessing various risk parameters and safety levels. Maximum positive deviation indicates that one model's assessment result is significantly higher than the other; slight positive deviation indicates that one model's assessment result is slightly higher than the other; no deviation indicates that the assessment results of the two models are completely consistent; slight negative deviation indicates that one model's assessment result is slightly lower than the other; and maximum negative deviation indicates that one model's assessment result is significantly lower than the other. This method transforms assessment deviation from a vague qualitative description into a clear quantitative indicator.

[0056] In this application, dynamic weights can be assigned to each risk parameter based on the quantified deviation sign. The weight of risk parameters corresponding to no deviation and slight deviation is increased, because no deviation and slight deviation indicate a high degree of consensus between the two models in assessing the risk parameter, making the assessment results more credible. Increasing their weight allows the final safety level determination to better reflect actual risks. The weight of risk parameters corresponding to extremely positive and extremely negative deviations is decreased, because extremely positive and extremely negative deviations indicate significant discrepancies between the two models in assessing the risk parameter, resulting in lower reliability. Decreasing their weight reduces the adverse impact of these risk parameters on the final safety level determination, making the determination more objective and accurate.

[0057] For example, taking the safety level verification of a car window lift function as an example, after two teacher models assessed the three risk parameters of exposure rate, severity, and controllability of this function, the assessment results showed that the severity assessment result was unbiased, the controllability assessment result was slightly positive biased, and the exposure rate assessment result was extremely negative biased. Subsequently, a multi-level deviation symbol was used to quantify the assessment difference, labeling severity as unbiased, controllability as slightly positive biased, and exposure rate as extremely negative biased. Then, dynamic weights were assigned based on the quantified deviation symbol results, increasing the weight of severity from 40% to 50%, the weight of controllability from 30% to 35%, and the weight of exposure rate from 30% to 15%, making the subsequent calculation of the safety level difference more consistent with the actual risk assessment logic.

[0058] In this application, by employing multi-level deviation symbols to quantify the degree of deviation between two assessment results, the differences between the two models can be clearly and intuitively presented, providing a clear and quantifiable basis for subsequent weight allocation and avoiding subjective arbitrariness in weight allocation. Simultaneously, dynamic weights are assigned to each risk parameter based on the deviation symbols, allowing the weight percentage of risk parameters to be adjusted according to the assessment consensus. This increases the weight percentage of risk parameters with high consensus and decreases the weight percentage of risk parameters with low consensus, making subsequent safety level difference calculations more scientific and more closely aligned with actual vehicle safety risk conditions. This improves the accuracy of safety level verification results and ensures that the final target safety level information better meets the requirements of the ISO 26262 functional safety standard. Furthermore, this quantification and weight allocation method makes the safety level verification process more logical and interpretable, facilitating the review and traceability of verification results by staff.

[0059] Continue to refer to Figure 1 In step 130, vehicle system architecture information is extracted based on the functional safety objective, and fault tree analysis information is generated by combining the functional safety objective and the vehicle system architecture information.

[0060] In this application, vehicle system architecture information is extracted based on verified functional safety objectives. The system architecture information can clearly present the hardware and software components and connections related to the vehicle. Fault tree analysis information is generated by combining functional safety objectives and vehicle system architecture information. The fault tree analysis information can sort out the causal relationship of vehicle-level hazard events and find the underlying root cause of the fault.

[0061] Specifically, in such Figure 1 In step 130 shown, the extraction of vehicle system architecture information based on the functional safety objective can be performed according to the following steps 131 to 132: Step 131: Obtain the vehicle function definition specification document, system controller and key component description document.

[0062] Step 132: Combine the functional safety target call parsing model to perform structured parsing on the vehicle function definition specification document, the system controller and the key component description document, so as to extract and generate vehicle system architecture information containing architecture element description, system function description, static architecture description and dynamic architecture description. The static architecture description is the physical connection relationship of the architecture elements, and the dynamic architecture description is the signal transmission mode of the architecture elements.

[0063] In this application, the vehicle function definition specification document clarifies the design requirements, working logic, and operation process of each function of the vehicle, and serves as the functional basis for sorting out the system architecture information. The system controller and key component description document details the parameters, models, and installation locations of the hardware components such as ECUs, sensors, actuators, and communication buses included in the vehicle, and serves as the hardware basis for sorting out the system architecture information.

[0064] In this application, a functional safety objective call parsing model is used to perform structured parsing on the two types of documents mentioned above. The functional safety objective can define the scope of architectural information extraction for the parsing model, allowing the model to extract only architectural information related to the functional safety objective, avoiding meaningless full extraction and improving extraction efficiency. Structured parsing transforms the unstructured information in the documents into standardized and organized structured information to extract and generate vehicle system architecture information that includes architectural element descriptions, system function descriptions, static architecture descriptions, and dynamic architecture descriptions. Among them, the architectural element descriptions provide detailed descriptions of all hardware and software elements within the extraction scope; the system function descriptions, combined with the architectural elements, explain the specific working process of the functions; the static architecture descriptions clearly present the physical connection relationships between architectural elements and the hardware connection methods between each element; and the dynamic architecture descriptions clearly define the signal transmission methods between architectural elements and the information interaction process between each element. The four types of descriptions work together to form a complete vehicle system architecture information system.

[0065] For example, taking the tire pressure monitoring system (TPMS) as an example, its functional safety objective is to prevent TPMS malfunctions from causing drivers to be unable to promptly detect abnormal tire pressure. First, the definition specification document for the TPMS function, and description documents of key components such as the TPMS ECU, sensors, and wireless communication module are obtained. Then, in conjunction with this functional safety objective, a parsing model is used to perform structured parsing on both types of documents, extracting the architectural elements related to TPMS, including the tire pressure sensor, TPMS ECU, in-vehicle central control screen, and wireless communication bus. After a detailed description of each architectural element, the system function of the TPMS is explained: the tire pressure sensor collects tire pressure signals, transmits them to the TPMS ECU via the wireless communication bus, and the ECU processes the data and sends the tire pressure information to the in-vehicle central control screen for display. Simultaneously, a static architecture description is generated, which states that the tire pressure sensors are installed inside each tire and connected to the tire pressure monitoring ECU via a wireless communication bus. The tire pressure monitoring ECU is connected to the central control screen via the vehicle's CAN bus. A dynamic architecture description is also generated, which states that the tire pressure sensors collect air pressure signals in real time, encode them through the wireless communication module, and send them to the tire pressure monitoring ECU. After the ECU decodes and verifies the signals, it transmits the normal or abnormal tire pressure information to the central control screen for display.

[0066] In this application, by combining functional safety objectives with the extraction of vehicle system architecture information, the scope of architecture information extraction can be more precise, extracting only content related to safety objectives and avoiding the problems of information redundancy and low processing efficiency caused by full extraction. At the same time, by acquiring two types of basic documents, namely functional and hardware documents, the extraction of architecture information is more comprehensive and based on evidence, avoiding information gaps. The structured parsing method transforms the originally scattered document information into standardized structured architecture information. The complete description of architecture elements, system functions, static architecture, and dynamic architecture can clearly present the hardware composition, connection relationships, and information interaction processes related to vehicle functions. This provides accurate and detailed architectural basis for the subsequent generation of fault tree analysis information, allowing the construction of the fault tree to cover all relevant architecture nodes and avoiding omissions in fault analysis. At the same time, the standardized architecture information format also facilitates subsequent data traceability and correlation, solving the problems of chaotic format and incomplete information when manually sorting out architecture information in the past.

[0067] Continuing, in such Figure 1 In step 130, the generation of fault tree analysis information by combining the functional safety objective and the vehicle system architecture information can be performed according to steps 133 to 135 as follows: Step 133: Take the vehicle-level hazard event corresponding to the functional safety target as the top-level event, split the top-level event into intermediate events and basic events, and record the logical relationship between each event.

[0068] Step 134: Use a recursive traversal algorithm to detect the split events and determine whether the events cover all controller nodes in the vehicle system architecture information.

[0069] Step 135: If the event covers all controller nodes, generate fault tree analysis information including top-level events, intermediate events, basic events, and the logical relationships between each event. If the event does not cover all controller nodes, re-divide the top-level event into hierarchical components and re-detect the event.

[0070] In this application, when generating fault tree analysis information by combining functional safety objectives and vehicle system architecture information, the vehicle-level hazard events corresponding to the functional safety objectives can first be taken as top-level events. Top-level events are the core starting point of fault tree analysis, directly corresponding to the safety risks that the vehicle needs to control. Then, the top-level events are hierarchically decomposed to obtain intermediate events and basic events. At the same time, the logical relationships between each event are recorded. The hierarchical decomposition is based on the causal relationship of the fault, gradually breaking down the top-level events into more specific fault events. Intermediate events are fault events between the top-level events and basic events, which are caused by multiple basic events. Basic events are low-level fault events that cannot be further decomposed and are the root cause of the occurrence of the top-level events. The logical relationships between each event include AND, OR, etc., clearly presenting the causal relationship between events.

[0071] In this application, a recursive traversal algorithm is used to detect the split events. This algorithm repeatedly calls its own function to comprehensively and without omission traverse all split events, determining whether these events cover all controller nodes in the vehicle system architecture information. Controller nodes are the core hardware of the vehicle system architecture and the main carriers of faults; covering all controller nodes is crucial to ensuring the comprehensiveness of fault tree analysis. If the events cover all controller nodes, it indicates that the fault tree splitting result is comprehensive and without omissions, generating fault tree analysis information including top-level events, intermediate events, basic events, and the logical relationships between each event. If the events do not cover all controller nodes, it indicates that the fault tree splitting result has omissions, requiring a re-splitting of the top-level events and event detection until all controller nodes are covered.

[0072] For example, taking the anti-lock braking system (ABS) of a car as an example, its functional safety goal is to prevent wheel lock-up during braking due to ABS malfunction. The corresponding vehicle-level hazard event is wheel lock-up during braking. This event is treated as the top-level event and hierarchically broken down into intermediate events such as ABS ECU malfunction, brake pressure sensor malfunction, and hydraulic actuator malfunction. Each intermediate event is further broken down into basic events, such as ABS ECU malfunction being broken down into ECU power supply malfunction, ECU chip malfunction, and ECU software malfunction. The logical relationship between each event is recorded as an OR relationship, meaning that any basic event will trigger a corresponding intermediate event, and any intermediate event will trigger the top-level event. Subsequently, a recursive traversal algorithm is used to detect all the decomposed events, determining whether these events cover all controller nodes of the ABS system, including the ECU, pressure sensor, and hydraulic actuator. The detection shows that all controller nodes are covered, thus generating fault tree analysis information containing the top-level event, each intermediate event, basic events, and their OR logical relationships. If the inspection finds that the solenoid valve node of the hydraulic actuator is not covered, the top-level events need to be re-segmented. Basic events such as solenoid valve jamming and solenoid valve circuit failure should be added under the intermediate events of hydraulic actuator failure. The inspection should be repeated until all controller nodes are covered.

[0073] In this application, by using vehicle-level hazard events as top-level events for hierarchical decomposition and recording logical relationships, the fault tree analysis information can clearly present the causal relationship of vehicle functional safety faults, identify the underlying root causes of top-level hazard events, and provide clear fault prevention targets for subsequent functional safety requirement generation. Simultaneously, a recursive traversal algorithm is used to check whether the decomposed events cover all controller nodes, ensuring the comprehensiveness of the fault tree analysis and avoiding incomplete fault analysis due to missing controller nodes. This allows subsequent functional safety requirements to cover all possible fault points, improving the comprehensiveness of functional safety design. Furthermore, by re-decomposing and detecting uncovered nodes, a closed-loop verification of fault tree construction is formed, further ensuring the accuracy and completeness of fault tree analysis information. This fault tree analysis information provides accurate and comprehensive fault basis for the generation of subsequent functional safety requirements, solving problems such as omissions and logical confusion that easily occur in traditional manual fault tree construction, and improving the efficiency and accuracy of fault tree construction.

[0074] Continue to refer to Figure 1 In step 140, the functional safety requirements generation model is invoked to generate functional safety requirements information based on the fault tree analysis information, and the functional safety requirements information is verified for compliance to obtain the target functional safety requirements information of the vehicle.

[0075] In this application, a functional safety requirements generation model is invoked to generate functional safety requirements information based on fault tree analysis information. Then, a comprehensive compliance verification of the functional safety requirements information is performed to eliminate non-compliant content and obtain the target functional safety requirements information for the vehicle, providing a feasible and compliant basis for the functional safety design of the vehicle.

[0076] Specifically, the generation of functional safety requirement information based on the fault tree analysis information can be performed according to the following steps 141 to 144: Step 141: Based on the vehicle functional safety standard and the fault tree analysis information, obtain functional safety requirement reference information by means of model prompt word input or vector library retrieval.

[0077] Step 142: Based on the functional safety requirements reference information, generate basic functional safety requirements information, including expected functional descriptions, fault diagnosis mechanisms, and fault handling mechanisms, for each basic event in the fault tree analysis information.

[0078] Step 143: Assign a corresponding safety level to the basic information of functional safety requirements, design a corresponding redundancy mechanism based on the assigned safety level, and assign time constraints to the basic information of functional safety requirements in combination with the fault tolerance interval of the vehicle functional safety target.

[0079] Step 144: Based on the functional safety requirement reference information, the basic information of functional safety requirements after adding safety level, redundancy mechanism and time constraint is formatted to generate functional safety requirement information containing unique identifier, name, description, time constraint, safety level, software component, controller, event identifier and signal code.

[0080] In this application, when generating functional safety requirement information based on fault tree analysis information, functional safety requirement reference information can first be obtained based on vehicle functional safety standards and fault tree analysis information through model prompt input or vector library retrieval. Vehicle functional safety standards provide compliance basis for obtaining requirement reference information, while fault tree analysis information provides specific objects for fault prevention and control. Model prompt input can directly transmit compliance requirements and fault information to the model, while vector library retrieval can quickly find relevant reference information from the functional safety requirement data of historical projects. The two methods can be flexibly selected according to actual development needs to ensure the compliance and relevance of the reference information.

[0081] In this application, based on functional safety requirements reference information, functional safety requirements basic information including expected functional description, fault diagnosis mechanism, and fault handling mechanism is generated for each basic event in the fault tree analysis information. Each basic event corresponds to an independent set of requirements basic information, realizing refined design of fault prevention and control. The expected functional description clarifies the normal working requirements of the system when there is no fault. The fault diagnosis mechanism designs specific methods to discover faults. The fault handling mechanism formulates the response process after a fault occurs.

[0082] In this application, corresponding safety levels are assigned to the basic information of functional safety requirements, and corresponding redundancy mechanisms are designed according to the assigned safety levels. The design of the redundancy mechanisms can match different fault prevention and control intensities according to the level of safety. At the same time, time constraints are assigned to the basic information of functional safety requirements in combination with the fault tolerance interval of vehicle functional safety objectives. The time constraints clarify the time requirements for fault diagnosis and handling, ensuring that faults can be prevented and controlled in a timely manner.

[0083] In this application, based on the functional safety requirements reference information, the basic information of functional safety requirements after adding safety level, redundancy mechanism and time constraint is formatted to generate functional safety requirements information containing unique identifier, name, description, time constraint, safety level, software component, controller, event identifier and signal code. The standardized field design makes the format of functional safety requirements information uniform, which is convenient for subsequent compliance verification and actual development and application.

[0084] For example, taking the fault tree analysis information of an automotive engine cooling system as an example, its basic events include coolant pump failure, temperature sensor failure, and cooling fan failure. First, based on the ISO26262 standard and the fault tree analysis information, reference information is obtained from historical engine cooling system safety requirement data through vector library retrieval. Then, basic requirement information is generated for each basic event. For example, for temperature sensor failure, the expected function description is that the temperature sensor should accurately collect the engine coolant temperature; the fault diagnosis mechanism is to detect the range and frequency of the sensor signal in real time, and if it exceeds the normal range, it is determined to be a fault; the fault handling mechanism is to immediately send a fault signal to the engine ECU after detecting a fault. Next, the basic requirement information is assigned a safety level of ASILA. Because the level is low, no system redundancy mechanism needs to be designed; only the signal acquisition stage needs a safety mechanism. At the same time, a time constraint is assigned based on the fault tolerance interval of the cooling system, requiring the fault diagnosis time to not exceed one hundred milliseconds. Finally, the basic requirement information is formatted to generate functional safety requirement information with a unique identifier of FSR-023, a name of temperature sensor fault prevention, and a description of real-time detection of sensor signals and sending a signal when a fault occurs.

[0085] In this application, functional safety requirement information is generated through multiple steps, enabling precise correspondence between the requirement information and each basic event in the fault tree analysis. This allows for refined design of fault prevention and control, ensuring that functional safety requirements address each underlying fault problem in a targeted manner. Furthermore, obtaining reference information based on vehicle functional safety standards guarantees the compliance of the requirement information. Redundancy mechanisms are designed according to safety levels, and time constraints are allocated to ensure that the prevention and control strength of the requirement information matches the fault risk, balancing functional safety and development costs. Standardized formatting ensures a unified format for functional safety requirement information, facilitating subsequent compliance verification. This addresses issues such as incomplete prevention and control, disconnect from faults, and chaotic formatting that often occur when traditionally generating functional safety requirements manually, improving the efficiency and accuracy of requirement information generation. Additionally, the design of fields such as unique identifiers for each requirement information facilitates subsequent data traceability and management.

[0086] In step 142 above, generating functional safety requirement basic information, including expected functional descriptions, fault diagnosis mechanisms, and fault handling mechanisms, for each basic event in the fault tree analysis information can be performed according to steps 1421 to 1423 as follows: Step 1421: Generate the expected functional description of the system under fault-free conditions corresponding to the basic event, and ensure that the expected functional description conforms to the vehicle function definition and system architecture relationship.

[0087] Step 1422: Design corresponding fault diagnosis mechanisms for internal communication failures of software components, communication failures between software components, signal acquisition failures, sensor execution failures, and controller failures.

[0088] Step 1423: Design a fault handling mechanism. The fault handling mechanism includes sending a fault flag bit to the control arbitration layer after fault detection, and the control arbitration layer entering a preset safety state after receiving the fault flag bit. For safety levels above the preset level, it also includes prompting an alarm on the human-machine interface after the control layer receives the fault flag bit, and directly entering a safety state when there is an actuator communication failure.

[0089] In this application, when generating functional safety requirements basic information including expected functional descriptions, fault diagnosis mechanisms, and fault handling mechanisms for each basic event in the fault tree analysis information, the expected functional description of the system under fault-free conditions corresponding to the basic event can be generated first. This expected functional description needs to strictly follow the vehicle function definition and system architecture relationship. The vehicle function definition clarifies the design requirements of the system, while the system architecture relationship clarifies the coordination method of each hardware and software element. Following both can make the expected functional description fit the actual design and operation of the system, clarify the normal working standard of the system under fault-free conditions, and provide a clear comparative basis for fault diagnosis.

[0090] In this application, corresponding fault diagnosis mechanisms are designed for internal communication failures of software components, communication failures between software components, signal acquisition failures, sensor execution failures, and controller failures. These five types of failures are the most common types of failures in vehicle electronic and electrical systems, covering key links such as software communication, signal acquisition, hardware execution, and control core. Designing a dedicated diagnosis mechanism for each type of failure can make fault diagnosis more targeted and improve the accuracy and efficiency of diagnosis.

[0091] In this application, a unified fault handling mechanism is designed. This mechanism first includes sending a fault flag bit to the control arbitration layer after fault detection, so that the vehicle's core control layer can be informed of the fault information in a timely manner. After receiving the fault flag bit, the control arbitration layer puts the system into a preset safety state. The preset safety state is set according to functional safety objectives and can effectively avoid the safety risks caused by faults. For safety levels above the preset level, the mechanism also includes human-machine interface prompts and alarms after the control layer receives the fault flag bit, so that the driver can be informed of the fault situation in a timely manner, and directly entering the safety state when there is an actuator communication failure, further improving the prevention and control strength of high safety level faults.

[0092] For example, taking the basic event of the car door unlocking function, "communication failure between software components of the door unlocking controller," as an example, the expected functional description corresponding to this basic event is first generated. That is, the software components of the door unlocking controller should achieve zero-delay and error-free information interaction through the vehicle's CAN bus to accurately transmit unlocking commands. This description follows the definition of the door unlocking function and the system architecture relationship of the controller. Then, a corresponding fault diagnosis mechanism is designed for the communication failure between software components, that is, real-time detection of the CAN bus signal transmission rate and data frame integrity. If the transmission rate is lower than the preset value or data frames are lost or erroneous, it is determined to be a communication failure. Finally, a fault handling mechanism is designed, that is, after detecting a fault, a fault flag is immediately sent to the vehicle control arbitration layer. After receiving the flag, the control arbitration layer puts the door unlocking system into a safe state, maintaining the current locked or unlocked state of the door. Since the safety level of this fault is ASILB, which is a safety level higher than the preset level, after receiving the fault flag, the control layer also needs to provide a human-machine interface prompt alarm on the vehicle's central control screen, displaying "door unlocking system communication failure." If a communication failure occurs between the unlocking actuator and the controller, the door unlocking system is directly put into a safe state, keeping the door locked.

[0093] In this application, by generating expected functional descriptions that align with vehicle function definitions and system architecture, clear and accurate normal operating standards can be provided for fault diagnosis, giving fault judgment a clear basis for comparison and improving the accuracy of fault diagnosis. Dedicated fault diagnosis mechanisms are designed for five common fault types, making fault diagnosis more targeted and effectively identifying different types of faults. This solves the problem of traditional fault diagnosis mechanisms being highly general but lacking specificity. Simultaneously, a hierarchical fault handling mechanism is designed. Basic fault signal transmission and safety state switching enable basic fault prevention. For high-safety-level faults, the added human-machine interface alarms and actuator faults directly enter a safe state, further enhancing fault prevention strength. This ensures that the fault handling mechanism matches the fault risk level, balancing functional safety and user experience. The method of generating basic functional safety requirement information ensures that requirement information accurately corresponds to fault type, laying a solid foundation for subsequent safety level allocation and formatting, and improving the relevance and practicality of functional safety requirement information.

[0094] In step 143 above, the allocation of corresponding security levels to the functional safety requirement basic information and the design of corresponding redundancy mechanisms based on the allocated security levels can be performed according to the following steps 1431 to 1432: Step 1431: Assign a security level to the functional safety requirement basic information according to the preset security level combination rules. If the controller is a routing controller, the security level of its corresponding functional safety requirement basic information is uniformly set to the first level.

[0095] Step 1432: If the assigned security level is Level 4, design a system-level redundancy mechanism. If the assigned security level is Level 2 or Level 3, design a security mechanism only in the signal acquisition stage. If the assigned security level is Level 1 or a level with no functional safety requirements, do not design a system redundancy mechanism.

[0096] In this application, when assigning corresponding security levels to basic functional safety requirements and designing corresponding redundancy mechanisms based on these security levels, the first step is to assign security levels to the basic functional safety requirements according to preset security level combination rules. These rules are based on the ISO 26262 functional safety standard and clearly define the inheritance and combination methods of security levels under different fault scenarios, ensuring the compliance and scientific nature of the security level allocation. If the controller is a routing controller, its corresponding basic functional safety requirements security level is uniformly set to Level 1. Since the routing controller primarily undertakes signal forwarding functions and has a relatively low fault risk, setting it to Level 1 balances functional safety and development costs. Subsequently, a corresponding redundancy mechanism is designed based on the assigned security level. If the assigned security level is Level 4, which is the highest level of vehicle functional safety, the safety risk from a fault is extremely high. Therefore, a system-level redundancy mechanism needs to be designed to achieve system-wide fault backup and prevention.

[0097] In this application, if the assigned safety level is Level 2 or Level 3, the failure risk of this level is moderate. Safety mechanisms are designed only in the signal acquisition stage to prevent and control failures in the core acquisition stage, balancing the effectiveness of prevention and control with development costs. If the assigned safety level is Level 1 or Level without functional safety requirements, the failure risk of this level is low and will not have a significant impact on vehicle safety. Therefore, no system redundancy mechanism is designed to reduce unnecessary development costs.

[0098] For example, taking the functional safety requirements of an automotive in-vehicle entertainment system and braking system as an example, firstly, safety levels are assigned to both according to preset safety level combination rules. A fault in the in-vehicle entertainment system only affects the user experience and has no functional safety requirement level. A fault in the braking system will cause vehicle braking failure and is assigned to level four. The functional safety requirements of the vehicle's routing controller are uniformly set to level one. Then, redundancy mechanisms are designed according to the assigned safety levels. Since the in-vehicle entertainment system has no functional safety requirement level, no system redundancy mechanism is designed. The braking system, being at level four, has a system-level redundancy mechanism, namely, dual-machine hot standby for the main brake controller and backup brake controller. In the event of a fault in the main controller, it immediately switches to the backup controller. Simultaneously, the brake pressure sensor uses a dual-sensor design to mutually verify signal accuracy. If the functional safety requirements of a vehicle's steering system are assigned to level two, then a safety mechanism is only designed in the signal acquisition stage of the steering angle sensor, i.e., real-time verification of the sensor signal's reasonableness. If it exceeds the reasonable range, it is judged as a signal acquisition fault, and no system-level redundancy mechanism is designed. If a vehicle's lighting control system is assigned to level one, then no system redundancy mechanism is designed; only basic fault detection is required.

[0099] In this application, by allocating safety levels according to preset safety level combination rules, the allocation results can be guaranteed to meet the requirements of the ISO26262 functional safety standard, ensuring that the control strength of functional safety requirements matches the failure risk. Setting a uniform safety level for the routing controller can balance functional safety and development costs, avoiding over-design. At the same time, differentiated redundancy mechanisms are designed according to different safety levels. The highest safety level is designed with a system-level redundancy mechanism, which can achieve comprehensive control of major failures and ensure the core safety of the vehicle. For the medium level, safety mechanisms are designed only in the signal acquisition stage, which can control development costs while ensuring control effectiveness. For low level or no level, no system redundancy mechanism is designed, which can avoid unnecessary development investment. This solves the problems of over-design or under-design in traditional redundancy mechanism design, making the design of redundancy mechanisms more scientific and reasonable. At the same time, the differentiated design method can also improve the overall cost-effectiveness of functional safety development, allowing development resources to be tilted towards high-risk functional links.

[0100] Continuing, in such Figure 1 In step 140, the compliance verification of the functional safety requirement information to obtain the target functional safety requirement information of the vehicle can be performed according to steps 145 to 147 as follows: Step 145: The functional safety requirement information is checked item by item using a pre-created script to verify the completeness of the fields and the consistency of the upstream and downstream traceability chains.

[0101] Step 146: Calculate the coverage of the functional safety requirements information to the fault tree analysis information and the coverage of the description of the vehicle system controller.

[0102] Step 147: If the functional safety requirement information fields are complete, the traceability chain is consistent, and the coverage reaches a preset threshold, the functional safety requirement information is identified as the target functional safety requirement information. If the preset requirements are not met, the functional safety requirement information is regenerated and compliance verification is performed.

[0103] In this application, compliance verification of functional safety requirement information is performed. When the target functional safety requirement information of the vehicle is obtained, the functional safety requirement information can first be checked item by item through a pre-created script. The script is written according to the vehicle functional safety standards and standardized requirements for data processing, which can realize automated item by item checking, avoiding the subjective bias and inefficiency of manual checking. The core content of the check is the field completeness of functional safety requirement information and the consistency of upstream and downstream traceability chain. Field completeness check ensures that all preset fields of each requirement information are not missing, and upstream and downstream traceability chain consistency check ensures that the event identifier, hazard identifier and other fields of the requirement information can be accurately associated with the previous fault tree analysis information and hazard scenario information, so as to realize the traceability of data in the whole chain.

[0104] In this application, the coverage of functional safety requirements information with fault tree analysis information and the coverage of vehicle system controller description are statistically analyzed. The fault tree analysis information coverage check ensures that each basic event has corresponding functional safety requirements information, with no omissions in fault prevention and control. The vehicle system controller description coverage check ensures that all relevant controller nodes are reflected in the functional safety requirements information, ensuring the comprehensiveness of the prevention and control scope.

[0105] In this application, if the functional safety requirement information fields are complete, the traceability chain is consistent, and the coverage reaches a preset threshold (which is set according to the requirements of functional safety development and is generally 100%), it indicates that the functional safety requirement information meets all compliance requirements and is identified as the target functional safety requirement information. If the preset requirements are not met, it indicates that the functional safety requirement information has problems such as missing information, incorrect association, or omissions in prevention and control. The functional safety requirement information needs to be regenerated and compliance verification needs to be performed until the preset requirements are met.

[0106] For example, taking the functional safety requirement information verification of the vehicle parking function as an example, a compliance verification script is created in advance to check all functional safety requirement information of the parking function one by one. This involves checking whether the unique identifier, name, description, time constraint, and other fields of each piece of information are complete, and whether the event identifiers of the requirement information are consistent with the basic event identifiers of the fault tree analysis information, and whether the hazard identifiers are consistent with the previous hazard scenario information, ensuring the consistency of the upstream and downstream traceability chain. Subsequently, the coverage of the functional safety requirement information to the fault tree analysis information of the parking function is calculated, checking whether each basic event has corresponding requirement information, and the description coverage of controller nodes such as the parking system ECU, parking motor, and position sensor, checking whether all controller nodes are reflected in the requirement information. After verification, if all fields are complete, the traceability chain is consistent, and both coverages reach 100%, reaching the preset threshold, then this functional safety requirement information is determined as the target functional safety requirement information for the parking function. If the verification finds that a certain requirement information is missing a time constraint field, or that the controller node of the parking motor is not covered, or that the coverage does not reach the preset threshold, then the functional safety requirement information for the parking function needs to be regenerated, the missing fields need to be supplemented, and the control requirements for the parking motor need to be added, and compliance verification needs to be performed again.

[0107] In this application, a pre-created script is used to automatically verify functional safety requirement information item by item. This automates compliance verification, significantly improving verification efficiency while avoiding subjective biases and omissions caused by manual verification, ensuring the accuracy of verification results. Comprehensive verification of field completeness, traceability chain consistency, and coverage ensures the compliance and completeness of functional safety requirement information from three dimensions: format, data association, and control scope. This solves problems such as inconsistent formats, chaotic data associations, and control omissions that easily occur in traditional manual verification. By regenerating and re-verifying non-compliant information, a closed-loop verification process for functional safety requirement generation is formed, further improving the quality of target functional safety requirement information. This ensures that the final target functional safety requirement information fully complies with the ISO 26262 functional safety standard and the requirements for vehicle functional safety development, providing a feasible, comprehensive, and traceable compliance basis for vehicle functional safety design. Furthermore, the automated verification method reduces labor costs and improves the overall efficiency of functional safety standard data processing.

[0108] In this application, after obtaining the target functional safety requirements information of the vehicle, the following steps 151 to 154 may also be performed: Step 151 involves storing hazard scenario information, risk parameter assessment data, safety level verification data, vehicle system architecture information, fault tree analysis information, functional safety requirements information, and verification data from each stage in an itemized manner, and setting a unique association identifier for the data in each stage to achieve full-process data traceability.

[0109] Step 152: Classify and label the processed data stored in itemized form according to valid data and invalid data, and label the reasons for the deviation of invalid data and the correction plan.

[0110] Step 153: Construct a continuous learning model based on the labeled processed data, and fine-tune and optimize the student model for evaluating risk parameters, the teacher model for verifying safety levels, and the functional safety requirements generation model through the continuous learning model.

[0111] Step 154: In subsequent data processing, historical knowledge is reused by retrieving the processed data stored in an itemized manner, thereby improving data processing efficiency.

[0112] In this application, after obtaining the target functional safety requirements information of the vehicle, a series of subsequent data processing tasks can be performed. First, hazard scenario information, risk parameter assessment data, safety level verification data, vehicle system architecture information, fault tree analysis information, functional safety requirements information, and verification data from each stage are stored in an itemized manner. A unique association identifier is assigned to the data at each stage. Itemized storage can standardize and organize all data according to stages and types, making the data storage structure clear and facilitating subsequent retrieval and use. The unique association identifier can accurately link the data at each stage, achieving full-process data traceability, allowing staff to query relevant information for any data in all other stages using the data identifier at any stage. Subsequently, the itemized stored processed data is classified and labeled as valid and invalid data. The reasons for the deviations and correction schemes for invalid data are also labeled. Valid data refers to data that meets the requirements after verification at each stage, while invalid data refers to data that does not meet the requirements after verification at each stage and is regenerated. Labeling the reasons for the deviations and correction schemes for invalid data clearly presents the problems and solutions encountered during data processing, providing a clear basis for model optimization. Next, a continuous learning model is built based on the labeled processed data. This model is then used to fine-tune and optimize the student model for assessing risk parameters, the teacher model for verifying safety levels, and the functional safety requirements generation model. The continuous learning model learns from both valid and invalid labeled data, summarizing patterns and problems in data processing, and making targeted fine-tuning of each core model. This allows the model to avoid past errors and improve subsequent data processing capabilities. Finally, in subsequent data processing, historical knowledge is reused by retrieving itemized stored processing data. When processing safety standard data for similar vehicle functions, relevant historical processing data can be quickly retrieved from the stored data as a reference, eliminating the need for analysis from scratch and improving data processing efficiency.

[0113] For example, taking the development of whole-vehicle functional safety for an automotive brand as an example, after generating the target functional safety requirements information for its first new energy vehicle, all data from various stages, including hazard scenario information, risk parameter assessment data, and safety level verification data, are stored in an itemized manner. Each data entry is assigned a unique identifier containing the vehicle model, function, and fault type, such as XNY-zy-005, representing the new energy vehicle model, braking function, and Category 5 fault, respectively. The stored data is then divided into valid and invalid data. Invalid data, such as a hazard scenario entry missing a vehicle-level hazard field, is rejected. The error is labeled as a missing field, and the correction is to supplement the vehicle-level hazard description. Next, a continuous learning model is built based on this labeled processed data. This model is used to fine-tune and optimize the student model, teacher model, and functional safety requirements generation model, enabling the model to automatically verify field completeness during subsequent processing and avoid similar errors. When the brand develops its second new energy vehicle, it can quickly obtain relevant hazard scenarios, risk parameter assessment standards, and functional safety requirements references by retrieving the processed data of the braking function of the first model, which is stored in an itemized manner. This allows for the reuse of historical knowledge and significantly improves the efficiency of processing functional safety standard data for the second model.

[0114] In this application, by storing all process data in an itemized manner and setting unique associated identifiers, the traceability of functional safety standard data throughout the entire process can be achieved. This solves the problems of poor data traceability and the need for manual updates of the entire data chain when requirements change in traditional processing. It allows for quick location and updating of relevant data through unique associated identifiers when requirements change, improving data maintenance efficiency. Classifying and labeling the stored data and recording the reasons for deviations and correction schemes for invalid data provides accurate and specific basis for model optimization, making model optimization more targeted. Building a continuous learning model based on labeled data and fine-tuning and optimizing each core model allows the model's data analysis capabilities to continuously improve with project iterations, achieving an analysis accuracy rate of 90%. The accuracy rate has been increased to over 95%, solving the problem of fixed capabilities and inability to self-optimize in traditional models. It enables the reuse of historical knowledge in subsequent data processing, allowing new projects to proceed without starting from scratch, significantly improving data processing efficiency. Simultaneously, it reduces repetitive work in similar projects, lowering manpower and time costs. This subsequent processing step creates a closed-loop system for vehicle functional safety standard data processing: "data processing - data storage - model optimization - knowledge reuse." This achieves continuous improvement in data processing capabilities and optimization of processing efficiency, allowing functional safety standard data processing to better adapt to the pace of agile vehicle development. It also accumulates valuable historical data assets for automakers' functional safety development, enhancing the overall functional safety development level of automakers.

[0115] To enable those skilled in the art to better understand this application, the method for processing vehicle functional safety standard data of this application will be further described in detail below, in conjunction with specific embodiments.

[0116] This embodiment takes the functional safety standard data processing of an electric power steering function in a car as an example to illustrate the processing method of this application in detail. The development of this function must strictly comply with the ISO26262 functional safety standard. The specific processing steps are as follows: Step 1: Obtain the vehicle function checklist for electric power steering as vehicle function data. Use a few-shot learning approach to call the large model. Analyze the failure modes of the electric power steering function item by item based on this checklist to generate standardized hazard scenario information. Each piece of information includes a hazard symbol, a function failure description, failure impact, vehicle-level hazard, scenario description, and hazard event description. For example, hazard symbol E08 describes a function failure as an error in the electric power steering ECU calculation, a failure impact as abnormal steering assist output, a vehicle-level hazard as loss of vehicle steering control, a scenario description as the ECU suddenly making a calculation error while the vehicle is traveling at 60 km / h on a rural road, and a hazard event description as the electric power steering ECU calculating incorrectly during vehicle operation, leading to abnormal steering assist output, loss of vehicle steering control, and a high risk of rollover accidents.

[0117] Step 2: Based on the core features in the hazard scenario information, a pre-trained student model is used to score the three risk parameters: exposure rate, severity, and controllability. A score description for each parameter is generated. For example, an exposure rate score of 2 indicates that the probability of the fault occurring during vehicle operation is 1% to 5%; a severity score of 4 indicates that the fault will cause loss of vehicle steering control, resulting in serious personal injury; and a controllability score of 1 indicates that the driver cannot manually resolve the impact of the fault. Subsequently, following the ISO 26262 algorithm and combining the score results, the preliminary safety level of the function is calculated to be ASILC. Simultaneously, the corresponding safety objective is generated: to prevent electric power steering malfunction from causing loss of vehicle steering control; and the safety state is to immediately stop the electric power steering function after a fault occurs, maintaining basic mechanical steering.

[0118] Step 3: Two independent pre-trained teacher models, BaseA and BaseB, are used as validation benchmarks. BaseA uses Q / M as the evaluation benchmark, and BaseB uses A / B as the evaluation benchmark. The two models perform parallel evaluations of each risk parameter and ASILC level in the preliminary safety level information, resulting in ASILC+ for BaseA and ASILC-- for BaseB. A multi-level deviation sign system (maximum positive deviation, slight positive deviation, no deviation, slight negative deviation, and maximum negative deviation) is used to quantify the degree of deviation between the two evaluation results, resulting in a slight negative deviation sign for each risk parameter. Dynamic weights are assigned to each risk parameter based on the deviation sign quantification results, increasing the weight of severity and decreasing the weight of exposure rate. The safety level difference between the two evaluation results under the dynamic weights is calculated. Since this difference is within the preset compliance range, the preliminary safety level ASILC is determined as the target safety level information, and the corresponding functional safety objective is extracted as avoiding vehicle steering loss of control due to electric power steering malfunction.

[0119] Step 4: Obtain the definition specification document for the electric power steering function, and the description documents for key components such as the system ECU, sensors, steering motor, and communication bus. Combine the functional safety target call parsing model to perform structured parsing on the two types of documents, extract relevant architectural elements, and generate system architecture information, including architectural element description, system function description, static architecture description, and dynamic architecture description. The static architecture description is that the steering sensor and the electric power steering ECU are connected via a CAN bus, and the ECU is connected to the steering motor via a control line. The dynamic architecture description is that the steering sensor collects steering angle and torque signals, transmits them to the ECU, and the ECU calculates and outputs the corresponding power assist signal to the steering motor.

[0120] Step 5: The vehicle-level hazard event "vehicle steering failure" corresponding to the functional safety objective is taken as the top-level event. It is then hierarchically decomposed to obtain intermediate events: steering sensor failure, electric power steering ECU failure, and steering motor failure. Each intermediate event is further decomposed into basic events; for example, ECU failure is decomposed into ECU power supply failure, chip failure, and software failure. Simultaneously, the logical relationships between these events are recorded as OR relationships. A recursive traversal algorithm is used to detect the decomposed events. The detection covers all controller nodes of the electric power steering system, thus generating fault tree analysis information containing the top-level event, intermediate events, basic events, and OR logical relationships.

[0121] Step 6: Based on the ISO26262 standard and fault tree analysis information, functional safety requirement reference information is retrieved from historical project data through vector library retrieval. For each basic event, basic functional safety requirement information is generated, including a description of the expected function, fault diagnosis mechanism, and fault handling mechanism. The basic requirement information is assigned a safety level of ASILC according to a preset safety level combination rule. Based on this level, a safety mechanism is designed in the signal acquisition stage. Simultaneously, a time constraint is assigned based on the fault tolerance interval of the functional safety objective, requiring the fault diagnosis time to not exceed fifty milliseconds. Finally, the basic requirement information is formatted to generate functional safety requirement information containing complete fields such as unique identifier, name, and description.

[0122] Step 7: The functional safety requirement information is checked item by item using a pre-created compliance verification script. The integrity of the fields and the consistency of the upstream and downstream traceability chains are checked. Then, the coverage of the requirement information with the fault tree analysis information and the description coverage of the controller nodes are calculated. After verification, all requirements meet the preset thresholds. Therefore, this functional safety requirement information is determined as the target functional safety requirement information for the electric power steering function.

[0123] Step 8 involves storing all data from the current processing stages, including hazard scenario information, risk parameter assessment data, and safety level verification data, in an itemized manner. A unique identifier is assigned to each stage's data. The stored data is then categorized and labeled as valid and invalid. A continuous learning model is built based on the labeled processing data, and the student model, teacher model, and functional safety requirement generation model are fine-tuned and optimized. When processing steering function safety standard data for the same brand of vehicles subsequently, the stored processing data is retrieved to reuse historical knowledge and improve processing efficiency.

[0124] Through the above steps, the functional safety standard data processing of automotive electric power steering function was completed automatically. The human involvement in this process was only 15%, the processing time was shortened by 80% compared with traditional manual processing, and the analysis accuracy reached 96%, which fully complies with the requirements of ISO26262 functional safety standard. At the same time, the traceability of data throughout the process was realized, which facilitates subsequent functional safety design and requirement changes.

[0125] Overall, based on the technical solution proposed in this application, through standardized and automated step-by-step processing, the entire process of vehicle functional safety standard data processing, from hazard scenario generation to functional safety requirement output, can be automated. This effectively reduces reliance on manual labor, minimizes deviations caused by manual operation, and reduces manpower and time costs. Simultaneously, dual-benchmark cross-validation eliminates the distortion problem of single-model results, ensuring that safety level determination meets the logical requirements of the ISO 26262 functional safety standard and resolving the illusion problem of large models. The standardized data format design and unique identifier setting throughout the entire process achieve full traceability of functional safety standard data, solving the problems of poor traceability and the need for manual updates of the entire data chain when requirements change in traditional processing, significantly improving the efficiency of data maintenance and requirement change management. By constructing a continuous learning model to fine-tune and optimize each core model, the model's analytical capabilities continuously improve with project iterations, achieving a continuous increase in analytical accuracy. Furthermore, the reuse of historical knowledge eliminates the need for new projects to start from scratch, significantly improving data processing efficiency and greatly shortening the processing time for functional safety standard data, better adapting to the pace of agile vehicle development. Furthermore, by designing differentiated redundancy mechanisms based on safety levels, the effectiveness of functional safety control and development costs are balanced, avoiding over-design or under-design issues. The closed-loop verification design throughout the entire process further ensures the accuracy and completeness of data processing, ensuring that the final target functional safety requirements information meets industry standards and vehicle development requirements. This provides accurate, compliant, and implementable basis for vehicle functional safety development, while also accumulating valuable functional safety data assets for automakers and improving the overall functional safety development level of automakers.

[0126] The following describes an embodiment of the apparatus described in this application, which can be used to execute the vehicle functional safety standard data processing method described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the vehicle functional safety standard data processing method described above in this application.

[0127] See Figure 2 The diagram shows a block diagram of a vehicle functional safety standard data processing device according to an embodiment of this application.

[0128] like Figure 2 As shown, the vehicle functional safety standard data processing device 200 according to an embodiment of this application includes: an evaluation unit 201, a verification unit 202, a first generation unit 203, and a second generation unit 204.

[0129] The system comprises the following components: an evaluation unit 201, used to generate standardized hazard scenario information based on vehicle functional data, and to evaluate the hazard scenario information using risk parameters to obtain preliminary safety level information, wherein the risk parameters include exposure rate, severity, and controllability; a verification unit 202, used to perform dual-benchmark cross-validation on the preliminary safety level information to obtain verified target safety level information and corresponding functional safety objectives; a first generation unit 203, used to extract vehicle system architecture information based on the functional safety objectives, and to generate fault tree analysis information by combining the functional safety objectives and the vehicle system architecture information; and a second generation unit 204, used to call a functional safety requirement generation model, generate functional safety requirement information based on the fault tree analysis information, and to perform compliance verification on the functional safety requirement information to obtain the target functional safety requirement information for the vehicle.

[0130] Based on the same inventive concept, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor so as to cause a computer device having the processor to perform operations performed by the method for processing vehicle functional safety standard data as described above.

[0131] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to perform the operations performed by the vehicle functional safety standard data processing method described above.

[0132] Based on the same inventive concept, this application also provides a vehicle, see reference. Figure 3 The diagram shows a structural schematic of a vehicle according to an embodiment of this application. The vehicle includes one or more memories 304, one or more processors 302, and at least one computer program (computer program instruction) stored in the memory 304 and executable on the processor 302. When the processor 302 executes the computer program, it implements the vehicle functional safety standard data processing method as described above.

[0133] Among them, Figure 3In this document, a bus architecture (represented by bus 300) is used. Bus 300 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 302 and memory represented by memory 304. Bus 300 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 305 provides an interface between bus 300 and receiver 301 and transmitter 303. Receiver 301 and transmitter 303 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 302 is responsible for managing bus 300 and general processing, while memory 304 can be used to store data used by processor 302 during operation.

[0134] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, the functions can be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

[0135] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0136] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0137] When the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0138] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for processing vehicle functional safety standard data, characterized in that, The method includes: Standardized hazard scenario information is generated based on vehicle function data, and risk parameters are assessed on the hazard scenario information to obtain preliminary safety level information. The risk parameters include exposure rate, severity, and controllability. The preliminary security level information is subjected to dual-benchmark cross-validation to obtain the verified target security level information and the corresponding functional safety target. Based on the functional safety objectives, vehicle system architecture information is extracted, and fault tree analysis information is generated by combining the functional safety objectives and the vehicle system architecture information. The functional safety requirements generation model is invoked, functional safety requirements information is generated based on the fault tree analysis information, and the functional safety requirements information is verified for compliance to obtain the target functional safety requirements information of the vehicle.

2. The method according to claim 1, characterized in that, The risk parameter assessment of the hazardous scenario information to obtain preliminary safety level information includes: Based on the core features in the hazardous scenario information, a pre-trained student model is invoked to score each risk parameter and generate a corresponding score description for each risk parameter. Preliminary safety level information is calculated based on the algorithm of the vehicle functional safety standard and the scoring results of each risk parameter. The preliminary safety level information also includes the safety target and safety status corresponding to the hazard scenario information.

3. The method according to claim 1, characterized in that, The step of performing dual-benchmark cross-validation on the preliminary security level information to obtain the validated target security level information and the corresponding functional safety target includes: Two pre-trained, independent teacher models are used as validation benchmarks to evaluate each risk parameter and the initial security level in the preliminary security level information in parallel, and the evaluation results of the two validation benchmarks are obtained. The two assessment results are subjected to deviation sign quantification, and dynamic weights are assigned to each risk parameter based on the deviation sign quantification results; Calculate the security level difference between the two evaluation results under the dynamic weight, and determine whether the security level difference is within the preset compliance range; If the safety level difference is within the preset compliance range, the preliminary safety level information is determined as the target safety level information, and the corresponding functional safety target is extracted; if the safety level difference exceeds the preset compliance range, the hazard scenario information is regenerated and risk parameters are assessed, while the evaluation benchmark of the teacher model is updated.

4. The method according to claim 3, characterized in that, The step of performing deviation sign quantification on the two assessment results and assigning dynamic weights to each risk parameter based on the deviation sign quantification results includes: The degree of deviation between the two evaluation results is quantified using multi-level deviation symbols, which include maximum positive deviation, slight positive deviation, no deviation, slight negative deviation, and maximum negative deviation. Increase the weighting of risk parameters corresponding to no bias and slight bias, and decrease the weighting of risk parameters corresponding to maximum positive bias and maximum negative bias.

5. The method according to claim 1, characterized in that, The extraction of vehicle system architecture information based on the functional safety objectives includes: Obtain vehicle function definition specifications, system controller and key component description documents; The functional safety target invocation parsing model is used to perform structured parsing on the vehicle function definition specification document, the system controller and the key component description document to extract and generate vehicle system architecture information that includes architecture element description, system function description, static architecture description and dynamic architecture description. The static architecture description is the physical connection relationship of the architecture elements and the dynamic architecture description is the signal transmission mode of the architecture elements.

6. The method according to claim 1, characterized in that, The process of generating fault tree analysis information by combining the functional safety objectives and the vehicle system architecture information includes: The vehicle-level hazard events corresponding to the functional safety objectives are taken as top-level events. The top-level events are then hierarchically decomposed to obtain intermediate events and basic events. At the same time, the logical relationships between each event are recorded. A recursive traversal algorithm is used to detect the split events and determine whether the events cover all controller nodes in the vehicle system architecture information; If the event covers all controller nodes, a fault tree analysis is generated, which includes top-level events, intermediate events, basic events, and the logical relationships between each event. If the event does not cover all controller nodes, the top-level event is re-segmented and the event is detected.

7. The method according to claim 1, characterized in that, The generation of functional safety requirements information based on the fault tree analysis information includes: Based on vehicle functional safety standards and the fault tree analysis information, functional safety requirement reference information is obtained through model prompt word input or vector library retrieval. Based on the functional safety requirements reference information, for each basic event in the fault tree analysis information, functional safety requirements basic information including expected functional description, fault diagnosis mechanism, and fault handling mechanism is generated respectively. Assign corresponding safety levels to the basic information of functional safety requirements, design corresponding redundancy mechanisms based on the assigned safety levels, and assign time constraints to the basic information of functional safety requirements in combination with the fault tolerance interval time of vehicle functional safety objectives. Based on the aforementioned functional safety requirement reference information, the basic information of functional safety requirements, after adding safety levels, redundancy mechanisms, and time constraints, is formatted to generate functional safety requirement information containing unique identifiers, names, descriptions, time constraints, safety levels, software components, controllers, event identifiers, and signal codes.

8. The method according to claim 1, characterized in that, The compliance verification of the functional safety requirements information to obtain the target functional safety requirements information of the vehicle includes: The functional safety requirement information is checked item by item using a pre-created script to verify the completeness of the fields and the consistency of the upstream and downstream traceability chain. The coverage of the functional safety requirements information to the fault tree analysis information and the description coverage to the vehicle system controller are statistically analyzed. If the functional safety requirement information fields are complete, the traceability chain is consistent, and the coverage reaches a preset threshold, the functional safety requirement information is determined as the target functional safety requirement information; if the preset requirements are not met, the functional safety requirement information is regenerated and compliance verification is performed.

9. The method according to claim 1, characterized in that, After obtaining the target functional safety requirements information of the vehicle, the method further includes: Hazard scenario information, risk parameter assessment data, safety level verification data, vehicle system architecture information, fault tree analysis information, functional safety requirements information, and verification data of each stage are stored in an itemized manner, and a unique association identifier is set for the data of each stage to achieve full-process data traceability. The processed data stored in an itemized manner is classified and labeled as valid data and invalid data, and the reasons for the deviation of invalid data and the correction plan are labeled. A continuous learning model is constructed based on the labeled and processed data, and the student model for evaluating risk parameters, the teacher model for verifying safety levels, and the functional safety requirements generation model are fine-tuned and optimized using the continuous learning model. In subsequent data processing, historical knowledge is reused by retrieving the itemized storage of processed data, thereby improving data processing efficiency.

10. An electronic device, characterized in that, The electronic device includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to implement the method as described in any one of claims 1 to 9.

Images