Function security demand generation method and device and storage medium

Through hazard and operability analysis and fault tree analysis, the safety requirements of automatic emergency braking function are identified and combined, and the problem of insufficient development of safety requirements in the existing technology is solved, and the safety and reliability of automatic emergency braking function is improved. .

CN119127125APending Publication Date: 2024-12-13SINO TRUK JINAN POWER CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411128630.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-08-16
Publication Date
2024-12-13

AI Technical Summary

Technical Problem

When developing the safety requirements of automatic emergency braking function, the prior art only relies on fault tree analysis, resulting in low adequacy and integrity of the acquired safety requirements, and the safety reliability of the automatic emergency braking function cannot be ensured.

Method used

Use hazard and operability analysis methods to define functional failures of automatic emergency braking items, identify functional failures through keywords, conduct hazard and risk analysis, obtain safety objectives of functional failures, and use fault tree analysis to identify functional failure safety requirements. Merge the processing to obtain the target functional security requirements.

Benefits of technology

The safety and reliability of the automatic emergency braking function are improved, and the safety requirements obtained are more fully and comprehensive.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119127125A_ABST
    Figure CN119127125A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides a function security demand generation method and device and a storage medium. According to the method, a function fault of an automatic emergency braking project is defined through a danger and operability analysis method, hazard and risk analysis is carried out on the function fault to obtain a safety target of the function fault, a function starting requirement is obtained according to the safety target, and after a function implementation safety requirement is obtained according to the function starting requirement, the automatic emergency braking project is started. The method comprises the steps of analyzing and identifying a safety target through a fault tree to obtain a function fault safety demand, and carrying out merging and summarizing processing according to a function implementation safety demand and the function fault safety demand to obtain a target function safety demand, so that compared with an existing scheme which is developed only according to the fault tree, the scheme aims at an automatic emergency braking function, and the development efficiency is improved. And the obtained safety requirements are more sufficient and comprehensive, so that the safety and the reliability of the automatic emergency braking function are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to vehicle functional safety technology, and in particular to a method, device and storage medium for generating functional safety requirements. Background Art

[0002] At present, the development of heavy-duty vehicle intelligent network systems needs to meet functional safety requirements, which has gradually become a trend. There are also relatively clear regulations on safety requirements development in the functional safety standards for road vehicles.

[0003] The existing technology for safety requirement development is usually based on the fault tree analysis method to achieve fault judgment and then obtain the corresponding functional safety requirement information. However, this solution only develops functional safety requirements based on the fault tree, and does not develop safety requirements for the automatic emergency braking function. Therefore, the sufficiency and completeness of the safety requirements for the automatic emergency braking function are low, and the safety and reliability of the automatic emergency braking function cannot be ensured;

[0004] Therefore, when developing the safety requirements for the automatic emergency braking function, the existing solutions are only developed based on the fault tree, so that the sufficiency and completeness of the obtained safety requirements are low, and the safety and reliability of the automatic emergency braking function cannot be ensured. Summary of the invention

[0005] The embodiments of the present application provide a functional safety requirement generation method, device and storage medium to address the defect that the existing solutions only develop the safety requirements for the automatic emergency braking function based on the fault tree, resulting in low sufficiency and completeness of the obtained safety requirements.

[0006] In a first aspect, an embodiment of the present application provides a method for generating functional safety requirements, including:

[0007] An automatic emergency braking item is defined, wherein the automatic emergency braking item is used to implement an active braking function of a vehicle;

[0008] By means of a hazard and operability analysis method, functional failures of the automatic emergency braking project are defined, and the functional failures are identified by means of keywords, wherein the functional failures include a loss of braking force request, an excessive braking force request, an insufficient braking force request, and an unexpected braking request;

[0009] Performing hazard and risk analysis on the functional failure to obtain a safety target for the functional failure, wherein the safety target is used to indicate functions that meet the normal operation of the project;

[0010] Acquire function start requirements according to the security goals, and acquire function realization security requirements according to the function start requirements;

[0011] Analyze and identify the safety goals through a fault tree to obtain functional failure safety requirements;

[0012] According to the function implementation safety requirement and the function failure safety requirement, a target function safety requirement is obtained.

[0013] In a possible implementation manner, the automatic emergency braking project includes a sensing unit, a functional logic unit and signal interface information, the sensing unit is used to collect external and vehicle information, and the functional logic unit is used to generate a logic control request signal according to the collected external and vehicle information;

[0014] The signal interface information includes a signal flow, a sub-function and an interface information, wherein the signal flow is used to indicate a signal for implementing the automatic emergency braking project, and the interface information is used to indicate an interface between the automatic emergency braking project and the entire vehicle.

[0015] In a possible implementation manner, identifying the functional failure by using keywords includes:

[0016] Obtain a target keyword, and obtain a keyword identical to the target keyword in a fault identification library; wherein the fault identification library pre-associatively stores multiple groups of keywords and fault information, and the keywords include missing, incorrect excess, incorrect reverse, and unexpected;

[0017] Obtain corresponding fault information using the same keyword and determine it as target fault information;

[0018] The functional fault is determined by means of the target fault information.

[0019] In a possible implementation manner, obtaining a function startup requirement according to the security goal includes:

[0020] Determine the enabling conditions for achieving the stated safety objectives;

[0021] The start condition is used as the function start requirement, wherein the start condition includes acquisition detection information, distance data detection information, brake request detection information and transmission detection information;

[0022] Among them, the acquisition detection information is used to indicate whether the sensor acquisition signal is correct, the distance data detection information is used to indicate whether the distance data acquired by the functional logic unit is correct, the braking request detection information is used to indicate whether the braking request signal is correct, and the transmission detection information is used to indicate whether the braking request signal is correctly transmitted to the actuator.

[0023] In a possible implementation, the obtaining of function implementation security requirements according to the function startup requirements includes:

[0024] Converting the function startup requirement into the function implementation safety requirement, wherein the function implementation safety requirement includes an identification name, a startup requirement name, description information, and a vehicle safety integrity level;

[0025] Among them, the identification name is used to indicate the name of the security target, the startup requirement name is used to indicate the name of each information in the startup condition, and the description information is used to indicate the content of each information in the startup condition.

[0026] In a possible implementation manner, obtaining the functional failure safety requirement includes:

[0027] Draw the fault tree according to the safety goal, wherein the fault tree includes top events, intermediate events and basic events;

[0028] The top event is used to indicate a functional failure that violates the safety goal, the intermediate event is used to indicate a failure factor that directly causes the top event, the basic event is used to indicate a bottom failure factor, and the events in the fault tree are connected by a preset logical relationship, and the preset logical relationship includes an AND gate relationship and an OR gate relationship;

[0029] The basic events are arranged and combined to obtain a vehicle failure event combination, and the vehicle failure event combination is determined as the functional failure safety requirement.

[0030] In a possible implementation, the obtaining a target functional safety requirement according to the functional implementation safety requirement and the functional failure safety requirement includes:

[0031] Compare the function realization safety requirement with the function failure safety requirement to obtain a comparison result;

[0032] If the comparison result is that the requirements are the same, determining the function implementation safety requirement or the function failure safety requirement as the target function safety requirement;

[0033] If the comparison result is that the requirements are different, then in the function implementation safety requirements and the function failure safety requirements, different requirements are extracted and marked as difference requirements; the same requirements are merged to obtain the same requirements; the same requirements and the difference requirements are summarized to obtain the target function safety requirements.

[0034] In a second aspect, an embodiment of the present application provides a functional safety requirement generation device, comprising:

[0035] An acquisition module, used for defining an automatic emergency braking item, wherein the automatic emergency braking item is used for realizing active braking of the vehicle;

[0036] a processing module, configured to define functional failures of the automatic emergency braking project by means of a hazard and operability analysis method, and identify the functional failures by means of keywords, wherein the functional failures include a loss of braking force request, an excessive braking force request, an insufficient braking force request, and an unexpected braking request, and perform a hazard and risk analysis on the functional failures to obtain a safety target of the functional failure, wherein the safety target is used to indicate a function that satisfies normal operation of the project;

[0037] A control module is used to obtain function startup requirements according to the safety goal, and obtain function implementation safety requirements according to the function startup requirements, analyze and identify the safety goal through a fault tree to obtain function failure safety requirements, and obtain target function safety requirements according to the function implementation safety requirements and the function failure safety requirements.

[0038] In a third aspect, an embodiment of the present application provides an electronic device, including: a memory, a processor;

[0039] The memory stores computer-executable instructions;

[0040] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0041] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0042] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0043] The functional safety requirement generation method, device and storage medium provided in the embodiments of the present application, during the development process of the vehicle automatic emergency braking system, based on the defined automatic emergency braking project, define the functional failures of the automatic emergency braking project through a hazard and operability analysis method, and perform hazard and risk analysis on the functional failures to obtain the safety goals of the functional failures, obtain the function startup requirements according to the safety goals, and obtain the function implementation safety requirements according to the function startup requirements, then analyze and identify the safety goals through a fault tree to obtain the functional failure safety requirements, merge and summarize the functional implementation safety requirements and the functional failure safety requirements to obtain the target functional safety requirements. Compared with the existing scheme that is developed only based on the fault tree, the present scheme obtains more comprehensive and sufficient safety requirements for the automatic emergency braking function, so as to improve the safety and reliability of the automatic emergency braking function. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0045] Figure 1 Schematic diagram of the functional safety requirements generation method provided for this application Figure 1 ;

[0046] Figure 2 Schematic diagram of the functional safety requirements generation method provided for this application Figure 2 ;

[0047] Figure 3 The automatic emergency braking project architecture diagram provided for this application;

[0048] Figure 4 Fault tree analysis logic diagram provided for this application;

[0049] Figure 5 A schematic diagram of the structure of the functional safety requirement generation device provided in this application;

[0050] Figure 6 A schematic diagram of the structure of the electronic device provided in this application.

[0051] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0052] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0053] When developing various vehicle functions, it is necessary to meet functional safety requirements or needs. The road vehicle functional safety standards have clear provisions on the contents of the definitions of related items, and also have clear methodologies for hazard analysis and risk assessment. The description of safety demand development is: according to safety goals, define the functional behavior or degraded functional behavior of related items, define constraints for reasonable and timely detection and control of related faults, and define safety strategies or external measures to achieve fault tolerance or reduce the impact of related faults.

[0054] The existing technology for safety requirement development is usually based on the fault tree analysis method to achieve the judgment of functional failures and then obtain the corresponding functional safety requirement information. However, this solution only develops functional safety requirements based on the fault tree, and does not develop safety requirements in combination with the automatic emergency braking function. Therefore, the sufficiency and completeness of the safety requirements for the automatic emergency braking function are low, and the safety and reliability of the automatic emergency braking function cannot be ensured;

[0055] Therefore, the present application provides a method for generating functional safety requirements. During the development process of the automatic emergency braking system for heavy vehicles, based on the defined automatic emergency braking project, the functional failures of the automatic emergency braking project are defined through a hazard and operability analysis method, and the functional failures are subjected to hazard and risk analysis to obtain the safety goals of the functional failures. The function startup requirements are obtained according to the safety goals, and after the function implementation safety requirements are obtained according to the function startup requirements, the safety goals are analyzed and identified through a fault tree to obtain the functional failure safety requirements, and the functional implementation safety requirements and the functional failure safety requirements are combined and summarized to obtain the target functional safety requirements. Compared with the existing scheme that is only developed based on the fault tree, the present scheme obtains more comprehensive and sufficient safety requirements for the automatic emergency braking function, so as to improve the safety and reliability of the automatic emergency braking function.

[0056] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0057] Figure 1 Schematic diagram of the functional safety requirements generation method provided for this application Figure 1 ,like Figure 1 As shown, the method includes:

[0058] S101, defining an automatic emergency braking item, where the automatic emergency braking item is used to implement active braking of a vehicle;

[0059] Specifically, the automatic emergency braking system AEB (Autonomous Emergency Braking) is defined and described based on the vehicle level, that is, the automatic emergency braking project is defined, wherein the definition of the automatic emergency braking project includes a perception unit, a functional logic unit and signal interface information, the perception unit is used to collect external and vehicle information, the functional logic unit is used to generate a logic control request signal according to the collected external and vehicle information, the signal interface information includes signal flow, sub-functions and interface information, the signal flow is used to indicate the signal for implementing the automatic emergency braking project, and the interface information is used to indicate the interface between the automatic emergency braking project and the whole vehicle.

[0060] S102. Define the functional failure of the automatic emergency braking project by means of a hazard and operability analysis method, and perform a hazard and risk analysis on the functional failure to obtain a safety target for the functional failure, wherein the safety target is used to indicate a function that satisfies the normal operation of the project;

[0061] Specifically, after completing the definition of the automatic emergency braking project, based on the automatic emergency braking project, according to the Hazard and Operability Study (HAZOP) method, the functional failures of the automatic emergency braking system AEB are defined, and the functional failures of the automatic emergency braking system are identified and obtained by keyword method.

[0062] S103, acquiring a function startup requirement according to the safety goal, and acquiring a function implementation safety requirement according to the function startup requirement, analyzing and identifying the safety goal through a fault tree to acquire a function failure safety requirement, and acquiring a target function safety requirement according to the function implementation safety requirement and the function failure safety requirement;

[0063] Specifically, based on the identified functional failures, the possible vehicle hazards (Hazard) are analyzed through hazard and risk analysis, i.e. HARA analysis (Hazard Analysis and Risk Assessment). The hazard events (Hazard Event) are obtained by analyzing the vehicle hazards in the vehicle operation scenario, and the vehicle safety integrity level ASIL and safety target SG of the hazard events are determined. The start conditions for achieving the safety target are obtained, and the function realization safety requirements are obtained based on the start conditions.

[0064] Furthermore, a fault tree analysis is performed on the automatic emergency braking system AEB, that is, based on the safety goal, a top-down analysis of the fault tree is used to locate which faults or combinations of external events lead to a given fault in the automatic emergency braking function, and these faults or combinations of external events are used as functional failure safety requirements. The functional implementation safety requirements and functional failure safety requirements are compared, the same requirements are merged, and different requirements are summarized. After summarizing and collating, the complete functional safety requirements of the automatic emergency braking system are obtained, that is, the target functional safety requirements are obtained.

[0065] The functional safety requirement generation method provided in the embodiment of the present application, during the development process of the automatic emergency braking system for heavy vehicles, is based on the defined automatic emergency braking project, and through the hazard and operability analysis method, the functional failures of the automatic emergency braking project are defined, and the functional failures are subjected to HARA analysis to obtain the safety goals of the functional failures, and the function startup requirements are obtained according to the safety goals. After obtaining the function implementation safety requirements according to the function startup requirements, the safety goals are analyzed and identified through a fault tree to obtain the functional failure safety requirements, and the functional implementation safety requirements and the functional failure safety requirements are combined and summarized to obtain the target functional safety requirements. Compared with the existing scheme that is developed only according to the fault tree, the present scheme obtains more comprehensive and sufficient safety requirements for the automatic emergency braking function, so as to improve the safety and reliability of the automatic emergency braking function.

[0066] Figure 2 Schematic diagram of the functional safety requirements generation method provided for this application Figure 2 , Figure 3 The automatic emergency braking project architecture diagram provided for this application, Figure 4 The fault tree analysis logic diagram provided for this application is combined with Figure 2 , Figure 3 and Figure 4 In this embodiment, Figure 1 Based on the embodiment, a method for generating functional safety requirements is described in detail, and the method includes:

[0067] S201, defining an automatic emergency braking item, where the automatic emergency braking item is used to achieve active braking of a vehicle;

[0068] Specifically, the definition of automatic emergency braking project includes perception unit, functional logic unit and signal interface information. The perception unit includes camera sensor, radar sensor and body status sensor to collect external and whole vehicle information. The external and whole vehicle information collected by the perception unit is sent to the functional logic unit, and after being processed by the camera controller in the functional logic unit and the control algorithm in the domain controller, the logic control request signal of the automatic emergency braking function is output to the whole vehicle actuator, that is, the execution unit, for alarm, driving or braking. The signal interface information also includes CAN communication network information and dependencies and requirements on other systems.

[0069] S202. defining functional failures of the automatic emergency braking project by means of a hazard and operability analysis method;

[0070] Specifically, after completing the definition of the automatic emergency braking project, the functional failures of the automatic emergency braking system AEB are defined according to the hazard and operability analysis (HAZOP) method. Functional failures include loss of braking force request, excessive braking force request, insufficient braking force request and unexpected braking request, and of course also include faults such as reverse braking force output and braking force jamming.

[0071] S203, identifying a functional failure of the automatic emergency braking item by means of keywords;

[0072] Specifically, after completing the functional fault definition of the automatic emergency braking project, a target keyword is obtained, and in the fault identification library, a keyword identical to the target keyword is obtained, and the corresponding fault information is obtained for the identical keyword, and determined as the target fault information, and the functional fault is determined by the target fault information. The fault identification library is as follows:

[0073]

[0074] The fault identification library stores multiple groups of keywords and fault information in a pre-associated manner, and the keywords include lost, incorrect excess, incorrect reverse, unexpected, and stuck.

[0075] S204, performing a hazard and risk analysis on the functional failure to obtain a safety target for the functional failure, wherein the safety target is used to indicate a function that satisfies normal operation of the project;

[0076] Specifically, after identifying and acquiring the functional failure of the automatic emergency braking project, based on the functional failure, the possible vehicle hazards are analyzed in the vehicle operation scenario to obtain hazardous events. By analyzing the hazards of the whole vehicle in the vehicle operation scenario, hazardous events are obtained, and the severity S, exposure rate E, and controllability C of the hazardous events are evaluated to determine the vehicle safety integrity level ASIL, safety target SG, and safety status of the hazardous events.

[0077] S205, determining a start-up condition for achieving the security goal, taking the start-up condition as the function start-up requirement, and converting the function start-up requirement into the function realization security requirement;

[0078] Specifically, after obtaining the safety goal, the function start-up requirements are obtained according to the safety goal, that is, the function start-up conditions of the automatic emergency braking system AEB safety goal are disassembled. For safety goals such as avoiding unexpected emergency braking, the start-up conditions of the emergency braking function are analyzed, where the start-up conditions include collecting detection information, distance data detection information, braking request detection information and transmission detection information;

[0079] Furthermore, when analyzing the start-up conditions of the emergency braking function, first, it is necessary to ensure that the correctness of the camera acquisition signal meets the functional safety requirements, that is, the acquisition detection information indicates that the sensor acquisition signal is correct; then, it is necessary to ensure that the correctness of the distance data calculated by the functional logic module of the controller meets the functional safety requirements, that is, the distance data detection information indicates that the distance data obtained by the functional logic unit is correct; then, it is necessary to ensure the correctness of the braking request signal, that is, the braking request detection information indicates that the braking request signal is correct; finally, it is also necessary to ensure that the braking request signal can be correctly transmitted to the actuator for execution, that is, the transmission detection information indicates that the braking request signal is correctly transmitted to the actuator. The startup process described above is converted into the functional implementation safety requirements as follows:

[0080]

[0081] Among them, the function implementation safety requirements include the identification name SG ID, the start requirement name FSR ID, the description information FSR description and the vehicle safety integrity level ASIL. The identification name is used to indicate the name of the safety goal such as avoid unexpected emergency braking SG_001. The start requirement name is used to indicate the name of each information in the start condition such as FSR_001. The description information is used to indicate the content of each information in the start condition.

[0082] S206, drawing the fault tree according to the safety goal, wherein the fault tree includes top events, intermediate events and basic events, arranging and combining the basic events to obtain a vehicle fault event combination, and determining the vehicle fault event combination as the functional fault safety requirement;

[0083] Specifically, a fault tree analysis is conducted on the automatic emergency braking project. Fault tree analysis is a deductive analysis method from results to causes. Based on the functional safety goal SG and combined with the automatic emergency braking project architecture, a top-down analysis of the fault tree is used to locate which faults, external events, or combinations of fault events will cause a given product failure.

[0084] In the fault tree, the fault behavior of the automatic emergency braking system is taken as the top event. The top event is a fault state that the system does not want to occur, that is, the top event indicates a functional failure that violates the safety goal. Starting from the top event, the factor that directly causes the top event is the first-level intermediate event. Follow this path downward, through various intermediate events, until a fault event that cannot or does not need to be further investigated is reached. The bottom-level fault event is the basic event of the top event. The basic event or combination of basic events obtained by analysis is the vehicle fault event combination.

[0085] S207, comparing the function realization safety requirement and the function failure safety requirement to obtain a comparison result;

[0086] Specifically, after obtaining the function implementation safety requirements and function failure safety requirements respectively, the function implementation safety requirements and function failure safety requirements are compared, and the comparison results indicate whether the function implementation safety requirements and function failure safety requirements are exactly the same, and the target function safety requirements are obtained based on the comparison results.

[0087] S208. If the comparison result shows that the requirements are the same, determining the function implementation safety requirement or the function failure safety requirement as the target function safety requirement;

[0088] Specifically, when the comparison results indicate that the functional implementation safety requirements and the functional failure safety requirements are exactly the same, the functional implementation safety requirements or the functional failure safety requirements can be used as the target functional safety requirements. Of course, the functional implementation safety requirements and the functional failure safety requirements can also be merged to use the merged safety requirements as the target functional safety requirements.

[0089] S209: If the comparison result indicates that the requirements are different, obtain the different requirements and the same requirements, and summarize the same requirements and the different requirements to obtain the target functional safety requirements;

[0090] Specifically, when the comparison results indicate that the functional implementation safety requirements and the functional failure safety requirements are not exactly the same, different requirements are extracted from the functional implementation safety requirements and the functional failure safety requirements, and the different requirements are marked as difference requirements, and the same requirements are merged to obtain the same requirements; the same requirements and difference requirements are summarized to obtain the target functional safety requirements, and the safety goals are traced to confirm that each safety goal has at least one safety requirement to achieve it. At the same time, each safety activity must confirm that the design implementation meets the functional safety requirements in accordance with the development verification review checklist.

[0091] The functional safety requirement generation method provided in the embodiment of the present application, during the development process of the automatic emergency braking system for heavy vehicles, is based on the defined automatic emergency braking project, and through the hazard and operability analysis method, the functional failures of the automatic emergency braking project are defined, and the functional failures are subjected to HARA analysis to obtain the safety goals of the functional failures, and the function startup requirements are obtained according to the safety goals. After obtaining the function implementation safety requirements according to the function startup requirements, the safety goals are analyzed and identified through a fault tree to obtain the functional failure safety requirements, and the functional implementation safety requirements and the functional failure safety requirements are combined and summarized to obtain the target functional safety requirements. Compared with the existing scheme that is developed only according to the fault tree, the present scheme obtains more comprehensive and sufficient safety requirements for the automatic emergency braking function, so as to improve the safety and reliability of the automatic emergency braking function.

[0092] Figure 5 A schematic diagram of the structure of the functional safety requirement generation device provided in this application, such as Figure 5 As shown, the functional safety requirement generating device 40 provided in this embodiment includes:

[0093] An acquisition module 501 is used to define an automatic emergency braking item, where the automatic emergency braking item is used to implement active braking of the vehicle;

[0094] The processing module 502 is used to define the functional failure of the automatic emergency braking project by means of a hazard and operability analysis method, and identify the functional failure by means of keywords, wherein the functional failure includes a loss of braking force request, an excessive braking force request, an insufficient braking force request, and an unexpected braking request, and perform a hazard and risk analysis on the functional failure to obtain a safety target of the functional failure, wherein the safety target is used to indicate a function that satisfies the normal operation of the project;

[0095] The control module 503 is used to obtain the function startup requirement according to the safety goal, and obtain the function implementation safety requirement according to the function startup requirement, analyze and identify the safety goal through a fault tree to obtain the function failure safety requirement, and obtain the target function safety requirement according to the function implementation safety requirement and the function failure safety requirement.

[0096] Further, the acquisition module 501 is specifically used to define an automatic emergency braking project, and the automatic emergency braking project includes: a sensing unit, a functional logic unit and signal interface information, the sensing unit is used to collect external and vehicle information, and the functional logic unit is used to generate a logic control request signal according to the collected external and vehicle information;

[0097] The signal interface information includes: signal flow, sub-functions and interface information, wherein the signal flow is used to indicate the signal for implementing the automatic emergency braking project, and the interface information is used to indicate the interface between the automatic emergency braking project and the entire vehicle.

[0098] Further, the processing module 502 is specifically configured to identify the functional failure of the automatic emergency braking item by means of keywords;

[0099] Obtain a target keyword, and obtain a keyword identical to the target keyword in a fault identification library; wherein the fault identification library pre-associatively stores multiple groups of keywords and fault information, and the keywords include missing, incorrect excess, incorrect reverse, and unexpected;

[0100] Obtain corresponding fault information using the same keyword and determine it as target fault information;

[0101] The functional fault is determined by means of the target fault information.

[0102] Further, the processing module 502 is specifically used to determine the starting conditions for achieving the security goal;

[0103] The start condition is used as the function start requirement, wherein the start condition includes acquisition detection information, distance data detection information, brake request detection information and transmission detection information;

[0104] Among them, the acquisition detection information is used to indicate whether the sensor acquisition signal is correct, the distance data detection information is used to indicate whether the distance data acquired by the functional logic unit is correct, the braking request detection information is used to indicate whether the braking request signal is correct, and the transmission detection information is used to indicate whether the braking request signal is correctly transmitted to the actuator.

[0105] Further, the execution module 503 is specifically used to convert the function startup requirement into the function implementation safety requirement, wherein the function implementation safety requirement includes an identification name, a startup requirement name, description information and a vehicle safety integrity level;

[0106] Among them, the identification name is used to indicate the name of the security target, the startup requirement name is used to indicate the name of each information in the startup condition, and the description information is used to indicate the content of each information in the startup condition.

[0107] Further, the execution module 503 is specifically used to draw the fault tree according to the safety goal, wherein the fault tree includes top events, intermediate events and basic events;

[0108] The top event is used to indicate a functional failure that violates the safety goal, the intermediate event is used to indicate a failure factor that directly causes the top event, the basic event is used to indicate a bottom failure factor, and the events in the fault tree are connected by a preset logical relationship, and the preset logical relationship includes an AND gate relationship and an OR gate relationship;

[0109] The basic events are arranged and combined to obtain a vehicle failure event combination, and the vehicle failure event combination is determined as the functional failure safety requirement.

[0110] Further, the execution module 503 is specifically used to draw the fault tree according to the safety goal, wherein the fault tree includes top events, intermediate events and basic events;

[0111] Compare the function realization safety requirement with the function failure safety requirement to obtain a comparison result;

[0112] If the comparison result is that the requirements are the same, determining the function implementation safety requirement or the function failure safety requirement as the target function safety requirement;

[0113] If the comparison result shows that the requirements are different, then in the functional implementation safety requirements and the functional failure safety requirements, different requirements are extracted and marked as difference requirements; the same requirements are merged to obtain the same requirements; the same requirements and the difference requirements are summarized to obtain the target functional safety requirements

[0114] The functional safety requirement generation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and this embodiment will not be described in detail here.

[0115] Figure 6 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the device 60 also includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus 604.

[0116] In a specific implementation process, at least one processor 601 executes the computer execution instructions stored in the memory 602, so that at least one processor 601 executes the above method.

[0117] The specific implementation process of the processor 601 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0118] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0119] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0120] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0121] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0122] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0123] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0124] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0125] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0126] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0127] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0128] If the function is implemented in the form of 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 the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0129] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0130] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A method for generating functional safety requirements, characterized in that: include: An automatic emergency braking item is defined, wherein the automatic emergency braking item is used to implement an active braking function of a vehicle; By means of a hazard and operability analysis method, functional failures of the automatic emergency braking project are defined, and the functional failures are identified by means of keywords, wherein the functional failures include a loss of braking force request, an excessive braking force request, an insufficient braking force request, and an unexpected braking request; Performing hazard and risk analysis on the functional failure to obtain a safety target for the functional failure, wherein the safety target is used to indicate functions that meet the normal operation of the project; Acquire function start requirements according to the security goals, and acquire function realization security requirements according to the function start requirements; Analyze and identify the safety goals through a fault tree to obtain functional failure safety requirements; According to the function implementation safety requirement and the function failure safety requirement, a target function safety requirement is obtained.

2. The method according to claim 1, characterized in that The automatic emergency braking project includes: a sensing unit, a functional logic unit and signal interface information, wherein the sensing unit is used to collect external and vehicle information, and the functional logic unit is used to generate a logic control request signal according to the collected external and vehicle information; The signal interface information includes: signal flow, sub-function and interface information, wherein the signal flow is used to indicate the signal for implementing the automatic emergency braking project, and the interface information is used to indicate the interface between the automatic emergency braking project and the entire vehicle.

3. The method according to claim 1, characterized in that The identifying the functional failure by means of keywords includes: Obtain a target keyword, and obtain a keyword identical to the target keyword in a fault identification library; wherein the fault identification library pre-associatively stores multiple groups of keywords and fault information, and the keywords include missing, incorrect excess, incorrect reverse, and unexpected; Obtain corresponding fault information using the same keyword and determine it as target fault information; The functional fault is determined by means of the target fault information.

4. The method according to claim 1, characterized in that: The obtaining of a function startup requirement according to the security goal includes: Determine the enabling conditions for achieving the stated safety objectives; The start condition is used as the function start requirement, wherein the start condition includes acquisition detection information, distance data detection information, brake request detection information and transmission detection information; Among them, the acquisition detection information is used to indicate whether the sensor acquisition signal is correct, the distance data detection information is used to indicate whether the distance data acquired by the functional logic unit is correct, the braking request detection information is used to indicate whether the braking request signal is correct, and the transmission detection information is used to indicate whether the braking request signal is correctly transmitted to the actuator.

5. The method according to claim 1, characterized in that The obtaining of function implementation security requirements according to the function startup requirements includes: Converting the function startup requirement into the function implementation safety requirement, wherein the function implementation safety requirement includes an identification name, a startup requirement name, description information, and a vehicle safety integrity level; Among them, the identification name is used to indicate the name of the security target, the startup requirement name is used to indicate the name of each information in the startup condition, and the description information is used to indicate the content of each information in the startup condition.

6. The method according to claim 1, characterized in that The obtaining of functional failure safety requirements includes: Draw the fault tree according to the safety goal, wherein the fault tree includes top events, intermediate events and basic events; The top event is used to indicate a functional failure that violates the safety goal, the intermediate event is used to indicate a failure factor that directly causes the top event, the basic event is used to indicate a bottom failure factor, and the events in the fault tree are connected by a preset logical relationship, and the preset logical relationship includes an AND gate relationship and an OR gate relationship; The basic events are arranged and combined to obtain a vehicle failure event combination, and the vehicle failure event combination is determined as the functional failure safety requirement.

7. The method according to any one of claims 1 to 6, characterized in that: The obtaining of target functional safety requirements according to the functional implementation safety requirements and the functional failure safety requirements includes: Compare the function realization safety requirement with the function failure safety requirement to obtain a comparison result; If the comparison result is that the requirements are the same, determining the function implementation safety requirement or the function failure safety requirement as the target function safety requirement; If the comparison result is that the requirements are different, then in the function implementation safety requirements and the function failure safety requirements, different requirements are extracted and marked as difference requirements; the same requirements are merged to obtain the same requirements; the same requirements and the difference requirements are summarized to obtain the target function safety requirements.

8. A functional safety requirement generation device, characterized in that: include: An acquisition module, used for defining an automatic emergency braking item, wherein the automatic emergency braking item is used for realizing active braking of the vehicle; a processing module, configured to define functional failures of the automatic emergency braking project by means of a hazard and operability analysis method, and identify the functional failures by means of keywords, wherein the functional failures include a loss of braking force request, an excessive braking force request, an insufficient braking force request, and an unexpected braking request, and perform a hazard and risk analysis on the functional failures to obtain a safety target of the functional failure, wherein the safety target is used to indicate a function that satisfies normal operation of the project; A control module is used to obtain function startup requirements according to the safety goal, and obtain function implementation safety requirements according to the function startup requirements, analyze and identify the safety goal through a fault tree to obtain function failure safety requirements, and obtain target function safety requirements according to the function implementation safety requirements and the function failure safety requirements.

9. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.