Functional safety monitoring method and device of vehicle, vehicle and storage medium
By receiving and judging vehicle information through the functional safety service layer, the problem that software under SOA architecture cannot meet the functional safety level is solved, and the safe response and state control of the vehicle in dangerous scenarios are realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHONGQING CHANGAN TECH CO LTD
- Filing Date
- 2022-08-30
- Publication Date
- 2026-07-24
AI Technical Summary
Under the SOA architecture, vehicle software development cannot meet functional safety level requirements, affecting overall vehicle safety.
The functional safety service layer receives current scenario information of the vehicle, user requests, and requests from the main functional service layer. It determines whether the scenario is a hazardous scenario and verifies the consistency of the requests within the allowable fault time, and then passes them through to the functional abstraction service layer to achieve a safe state.
It improves vehicle safety, ensures timely response in dangerous scenarios, reduces information transmission time, and achieves a safe state and objectives.
Smart Images
Figure CN115470071B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle functional safety technology, and in particular to a method, device, vehicle, and storage medium for monitoring the functional safety of a vehicle. Background Technology
[0002] With the rapid development of the automotive industry towards the "new four modernizations" (electrification, connectivity, intelligence, and sharing), the frequency of software function iteration and updates is increasing. To meet the needs of rapid software function updates, OEMs have gradually introduced the concept of SOA (Service-Oriented Architecture) into vehicle function development and implemented it through software to decouple various service functions and improve development efficiency. At the same time, the development of the "new four modernizations" has led to fewer mechanical parts and a sharp increase in electronic and electrical components within the vehicle, which also increases the probability of electronic and electrical failures, affecting overall vehicle safety. Therefore, OEMs consider incorporating functional safety into the development of each function and propose safety goals and safety states for electronic and electrical components with functional safety levels.
[0003] In related technologies, functional safety strategies for vehicles generally involve connecting the input and output signals of the monitored functional module (without functional safety level requirements) to the monitoring module (with functional safety level requirements) to achieve the required functional safety level for the entire control software.
[0004] However, in the SOA architecture, information is transmitted through services, and the signaling method used in related technologies may not be suitable for SOA architecture, which needs to be addressed. Summary of the Invention
[0005] This application provides a method, device, vehicle, and storage medium for monitoring the functional safety of a vehicle, thereby solving the problem that software developed based on SOA architecture cannot meet the functional safety level requirements, enabling the whole vehicle to achieve a safe state and safety objectives.
[0006] The first aspect of this application provides a method for monitoring the functional safety of a vehicle. The vehicle includes a service-oriented architecture (SOA), which comprises a main functional service layer, a functional safety service layer, and a functional abstraction service layer. The method includes the following steps: receiving current scenario information, user requests, intelligent driving requests, and main functional service requests issued by the main functional service layer through the functional safety service layer; determining whether the current scenario is a hazardous scenario based on the current scenario information, and determining whether the user request or the intelligent driving request is consistent with the main functional service request; if the current scenario is the hazardous scenario, and the user request or the intelligent driving request is inconsistent with the main functional service request, determining whether the user request or the intelligent driving request is consistent with the main functional service request within the maximum permissible fault time, and if the user request or the intelligent driving request is consistent with the main functional service request, passing the main functional service request to the functional abstraction service layer.
[0007] Based on the above technical means, the problem that software developed based on SOA architecture cannot meet the functional safety level requirements is solved, enabling the whole vehicle to achieve a safe state and safety goals.
[0008] Furthermore, the above-mentioned vehicle functional safety monitoring method further includes: if the current scenario is not the hazardous scenario, and / or the user request or the intelligent driving request is consistent with the main functional service request, then the main functional service request is directly passed through to the functional abstract service layer.
[0009] By directly transmitting the main function service request to the function abstraction service layer, the information transmission time is reduced and the vehicle safety is improved.
[0010] Furthermore, before receiving the vehicle's current scenario information, the user request, the intelligent driving request, and the main function service request issued by the main function service layer through the functional safety service layer, the method further includes: determining whether there is an abnormality in the vehicle's drive equipment; if there is no abnormality in the vehicle's drive equipment, then receiving the vehicle's current scenario information, the user request, the intelligent driving request, and the main function service request issued by the main function service layer through the functional safety service layer.
[0011] Based on the above technical means, it is possible to determine whether the vehicle's drive system is abnormal, so that the functional safety layer can receive vehicle information and requests, thereby improving the detection of vehicle safety.
[0012] Furthermore, the above-mentioned vehicle functional safety monitoring method further includes: when the vehicle's drive equipment is abnormal, or when the user request or the intelligent driving request is consistent with the main function service request, controlling the vehicle to enter a safe state; determining whether the safe state can be restored; if the safe state can be restored, then re-determining whether the vehicle's drive equipment is abnormal; otherwise, maintaining the vehicle in the safe state.
[0013] By using the aforementioned technical means, vehicle safety can be improved by determining whether the safety status can be restored.
[0014] Furthermore, the maximum permissible failure time is obtained by the functional safety service layer by decomposing the user request or the intelligent driving request with the main function service request through the Fault Tolerant Time Interval (FTTI).
[0015] Based on the aforementioned technical means, the maximum permissible fault time refers to the correction time that does not put the driver in a dangerous situation, thus avoiding situations where the vehicle malfunctions without the driver's awareness.
[0016] A second aspect of this application provides a functional safety monitoring device for a vehicle. The vehicle includes a service-oriented architecture (SOA), which comprises a main functional service layer, a functional safety service layer, and a functional abstraction service layer. The device includes: a receiving module, configured to receive current scenario information, user requests, intelligent driving requests, and main functional service requests issued by the main functional service layer through the functional safety service layer; a first judging module, configured to judge whether the current scenario is a hazardous scenario based on the current scenario information, and to judge whether the user request or the intelligent driving request is consistent with the main functional service request; and a first transmission module, configured to, if the current scenario is the hazardous scenario and the user request or the intelligent driving request is inconsistent with the main functional service request, judge whether the user request or the intelligent driving request is consistent with the main functional service request within the maximum permissible fault time, and if the user request or the intelligent driving request is consistent with the main functional service request, transmit the main functional service request to the functional abstraction service layer.
[0017] Furthermore, the aforementioned vehicle functional safety monitoring device further includes: a second transmission module, used to directly transmit the main functional service request to the functional abstract service layer if the current scenario is not the hazardous scenario, and / or if the user request or the intelligent driving request is consistent with the main functional service request.
[0018] Furthermore, before receiving the vehicle's current scenario information, the user request, the intelligent driving request, and the main function service request issued by the main function service layer through the functional safety service layer, the receiving module is specifically used to: determine whether there is an abnormality in the vehicle's drive equipment; if there is no abnormality in the vehicle's drive equipment, then receive the vehicle's current scenario information, the user request, the intelligent driving request, and the main function service request issued by the main function service layer through the functional safety service layer.
[0019] Furthermore, the aforementioned vehicle functional safety monitoring device further includes: a control module, used to control the vehicle to enter a safe state when the vehicle's drive equipment is abnormal, or when the user request or the intelligent driving request is consistent with the main function service request; a second judgment module, used to determine whether the safe state can be restored; and a third judgment module, used to re-determine whether the vehicle's drive equipment is abnormal if the safe state can be restored, otherwise, maintain the vehicle in the safe state.
[0020] Furthermore, the maximum permissible failure time is obtained by the functional safety service layer by decomposing the user request or the intelligent driving request with the main function service request through the fault tolerance time interval (FTTI).
[0021] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the functional safety monitoring method for the vehicle as described in the above embodiments.
[0022] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the functional safety monitoring method for a vehicle as described in the above embodiments.
[0023] Therefore, this application receives the vehicle's current scenario information, user requests, intelligent driving requests, and main function service requests issued by the main function service layer through the functional safety service layer. Based on the current scenario information, it determines whether the current scenario is a hazardous scenario and whether the user request or intelligent driving request is consistent with the main function service request. If the current scenario is a hazardous scenario and the user request or intelligent driving request is inconsistent with the main function service request, it determines whether a situation occurs where the user request or intelligent driving request is consistent with the main function service request within the maximum permissible fault time. If such a situation occurs, the main function service request is passed through to the functional abstraction service layer. This solves the problem that software developed based on the SOA architecture cannot meet functional safety level requirements, enabling the entire vehicle to achieve a safe state and safety objectives.
[0024] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description
[0025] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:
[0026] Figure 1 This is a flowchart of a vehicle functional safety monitoring method according to an embodiment of this application;
[0027] Figure 2 This is a schematic diagram of the software components used in the SOA-based functional safety monitoring method according to an embodiment of this application.
[0028] Figure 3 This is a flowchart of a vehicle functional safety monitoring method according to an embodiment of this application;
[0029] Figure 4 This is a block diagram of a vehicle functional safety monitoring device according to an embodiment of this application;
[0030] Figure 5 This is a structural schematic diagram of a vehicle according to an embodiment of this application.
[0031] Explanation of reference numerals in the attached drawings: 10-Vehicle functional safety monitoring device, 100-Receiving module, 200-First judgment module, 300-First transmission module, 501-Memory, 502-Processor, 503-Communication interface. Detailed Implementation
[0032] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.
[0033] The functional safety monitoring method, apparatus, vehicle, and storage medium of this application are described below with reference to the accompanying drawings. Addressing the problem mentioned in the background art that software developed based on SOA architecture cannot meet functional safety level requirements, this application provides a functional safety monitoring method for vehicles. In this method, a functional safety service layer receives current scenario information, user requests, intelligent driving requests, and main functional service requests issued by the main functional service layer. Based on the current scenario information, it determines whether the current scenario is a hazardous scenario and whether the user request or intelligent driving request is consistent with the main functional service request. If the current scenario is a hazardous scenario and the user request or intelligent driving request is inconsistent with the main functional service request, it determines whether a situation occurs within the maximum permissible fault time where the user request or intelligent driving request is consistent with the main functional service request. If such a situation occurs, the main functional service request is transparently transmitted to the functional abstract service layer. This solves the problem that software developed based on SOA architecture cannot meet functional safety level requirements, enabling the entire vehicle to achieve a safe state and safety objectives.
[0034] Specifically, Figure 1 This is a flowchart illustrating a vehicle functional safety monitoring method provided in an embodiment of this application.
[0035] In this embodiment, such as Figure 2 As shown, the vehicle includes an SOA architecture 1, which includes a main functional service layer 11, a functional safety service layer 12, and a functional abstraction service layer 13.
[0036] In this embodiment, such as Figure 2 As shown, the vehicle includes an SOA architecture 1, which includes a main functional service layer 11, a functional safety service layer 12, and a functional abstraction service layer 13.
[0037] like Figure 2 As shown, the main functional service layer 11 contains multiple service layers, primarily used to implement the relevant functions of the entire vehicle. The functional safety layer receives service requests from the main functional service layer 11 and determines whether the request contradicts human or intelligent driving requests in the required scenario. The functional abstraction service layer 13 receives service requests from the functional safety layer and simultaneously implements the functional abstraction of the hardware.
[0038] The main functional service layer 11 contains multiple service layers. Through the arrangement and combination of these services and the mutual invocation of their interfaces, the corresponding functions of the entire vehicle are realized. Simultaneously, the main functional service layer 11 receives service requests from external applications and invokes their services, completing information interaction with external applications. In addition, the main functional service layer 11 invokes the service interfaces provided by the functional safety service layer 12 to drive related functions, and obtains feedback from the functional safety service layer 12, including but not limited to fault information, current information, and status information of the driving equipment. The main functional service layer 11 can be developed according to the requirements for a non-functional level.
[0039] The Functional Abstraction Service Layer 13 is used to implement the functional abstraction of the hardware. It drives relevant functions by receiving service requests from the Functional Safety Service Layer 12. Simultaneously, the Functional Abstraction Service Layer 13 can acquire, but is not limited to, fault information, current information, and status information of the driving device, and feed this information back to the Functional Safety Service Layer 12. The Functional Abstraction Service Layer 13 is located at the bottom layer of the entire service and must be developed according to the functional safety requirements.
[0040] like Figure 1 As shown, the functional safety monitoring method for this vehicle includes the following steps:
[0041] In step S101, the current scene information of the vehicle, user requests, intelligent driving requests, and main function service requests issued by the main function service layer are received through the functional safety service layer.
[0042] It should be understood that the functional safety service layer receives external information from the vehicle. This external information includes, but is not limited to, scene information and requests from human or intelligent driving systems. Scene information includes, but is not limited to, vehicle speed information, lateral acceleration information, longitudinal acceleration information, ambient light information, rainfall information, etc., which come from other software systems or sensors. Requests from human or intelligent driving systems include, but are not limited to, the operating intentions of the driver or passengers and decision commands from intelligent control algorithms.
[0043] Optionally, in some embodiments, before receiving the vehicle's current scene information, user requests, intelligent driving requests, and main function service requests issued by the main function service layer through the functional safety service layer, the method further includes: determining whether there is an abnormality in the vehicle's drive equipment; if there is no abnormality in the vehicle's drive equipment, then receiving the vehicle's current scene information, user requests, intelligent driving requests, and main function service requests issued by the main function service layer through the functional safety service layer.
[0044] In step S102, it is determined whether the current scene is a hazardous scene based on the current scene information, and it is determined whether the user request or intelligent driving request is consistent with the main function service request.
[0045] Optionally, in some embodiments, the above-described vehicle functional safety monitoring method further includes: if the current scenario is not a hazardous scenario, and / or the user request or intelligent driving request is consistent with the main functional service request, then directly pass the main functional service request to the functional abstract service layer.
[0046] In this context, a hazardous scenario can be understood as a situation that could cause harm to the driver, passengers, or surrounding objects. Specifically, the functional safety service layer determines the scenario in which the vehicle is located based on the received scenario information, and confirms whether the current scenario is a hazardous scenario based on the results of the functional safety analysis. If the current scenario is not a hazardous scenario, and the human request or intelligent driving request is consistent with the main functional service request, or if the human request or intelligent driving request is consistent with the main functional service request, then the main functional service request is directly passed through to the functional abstraction service layer.
[0047] In step S103, if the current scenario is a hazardous scenario and the user request or intelligent driving request is inconsistent with the main function service request, it is determined whether the user request or intelligent driving request is consistent with the main function service request within the maximum allowable fault time. If the user request or intelligent driving request is consistent with the main function service request, the main function service request is passed through to the functional abstract service layer.
[0048] In some embodiments, the maximum permissible failure time is obtained by the functional safety service layer by decomposing user requests or intelligent driving requests with main function service requests through the Fault Tolerance Time Interval (FTTI).
[0049] Specifically, if the current scenario is a hazardous scenario, the Functional Safety Service Layer will, based on requests from humans or intelligent driving systems, confirm whether there is an intent to use related functions, such as decision commands from drivers, passengers, or intelligent control algorithms. Simultaneously, the Functional Safety Service Layer receives service requests from the Main Functional Service Layer and determines whether these requests are consistent with human or intelligent driving requests. If the Main Functional Service Layer's service request is consistent, the Functional Safety Service Layer will directly pass the received Main Functional Service Layer's service request to the Functional Abstraction Service Layer. After completion, the judgment process for the next frame will restart. If the Main Functional Service Layer's service request is inconsistent with human or intelligent driving requests, the Functional Safety Service Layer will obtain the maximum allowable failure time for inconsistencies between the Main Functional Service Layer's service request and human or intelligent driving requests from FTTI decomposition. It will then determine whether any inconsistencies occur within this timeframe. If inconsistencies are found, the Functional Safety Service Layer will record these inconsistencies, pass the Main Functional Service Layer's service request to the Functional Abstraction Service Layer, and after completing these actions, the judgment process for the next frame will restart.
[0050] Optionally, in some embodiments, the above-described vehicle functional safety monitoring method further includes: controlling the vehicle to enter a safe state when there is an abnormality in the vehicle's drive equipment, or when a user request or intelligent driving request is consistent with the main function service request; determining whether the safe state can be restored; if the safe state can be restored, re-determining whether there is an abnormality in the vehicle's drive equipment; otherwise, maintaining the vehicle in a safe state.
[0051] Specifically, the functional safety service layer receives the drive device status feedback from the functional abstraction service layer and determines whether the drive device is abnormal. If the vehicle's drive device is abnormal, the vehicle enters a safe state. When the vehicle enters a safe state, or when a human request or intelligent driving request is consistent with the main functional service request, the vehicle enters a safe state. Once the vehicle enters a safe state, it determines whether the safe state can be restored. If the safe state can be restored, it re-determines whether the drive device is abnormal and begins determining whether the drive device has returned to normal in the next frame. If the safe state cannot be restored, the determination ends, and the vehicle remains in a safe state.
[0052] For ease of understanding, it will be combined here. Figure 3 Provide a detailed explanation of the process for monitoring the functional safety of vehicles. Figure 3 This is a flowchart of a vehicle functional safety monitoring method according to a specific embodiment of this application.
[0053] In step S301, it is determined whether the drive device is malfunctioning. If the drive device is malfunctioning, step S309 is executed; if the drive device is not malfunctioning, step S302 is executed.
[0054] In step S302, it is determined whether the scenario is a hazardous scenario. If the scenario is a hazardous scenario, step S304 is executed; otherwise, step S303 is executed.
[0055] In step S303, it is determined whether the human or intelligent driving request is consistent with the main function service request. If they are consistent, step S304 is executed; otherwise, step S305 is executed.
[0056] In step S304, a request is made to the main function service layer to pass through.
[0057] In step S305, it is determined whether the FTTI user request or intelligent driving request is consistent with the main function service request. If they are consistent, step S306 is executed; otherwise, step S307 is executed.
[0058] In step S306, inconsistencies are recorded, and the service request of the main functional service layer is passed through when final consistency is achieved.
[0059] In step S307, the safe state is maintained.
[0060] In step S308, it is determined whether the safe state can be restored. If it cannot be restored, the determination ends; if it can be restored, step S301 is executed.
[0061] In step S309, the safe state is maintained.
[0062] In step S310, it is determined whether the safety state can be restored. If it cannot be restored, the determination ends. If it can be restored, step S301 is executed.
[0063] The vehicle functional safety monitoring method proposed in this application receives current scenario information, user requests, intelligent driving requests, and main functional service requests issued by the main functional service layer through the functional safety service layer. Based on the current scenario information, it determines whether the current scenario is a hazardous scenario and whether the user request or intelligent driving request is consistent with the main functional service request. If the current scenario is a hazardous scenario and the user request or intelligent driving request is inconsistent with the main functional service request, it determines whether the user request or intelligent driving request is consistent with the main functional service request within the maximum permissible fault time. If the user request or intelligent driving request is consistent with the main functional service request, the main functional service request is transparently transmitted to the functional abstract service layer. This solves the problem that software developed based on SOA architecture cannot meet functional safety level requirements, enabling the entire vehicle to achieve a safe state and safety goals.
[0064] Next, the functional safety monitoring device for vehicles proposed according to embodiments of this application is described with reference to the accompanying drawings.
[0065] Figure 4 This is a block diagram of a vehicle functional safety monitoring device according to an embodiment of this application.
[0066] The vehicle includes a service-oriented architecture (SOA), which comprises a main functional service layer, a functional safety service layer, and a functional abstraction service layer.
[0067] like Figure 4 As shown, the functional safety monitoring device 10 of the vehicle includes: a receiving module 100, a first judgment module 200 and a first transmission module 300.
[0068] The receiving module 100 is used to receive the vehicle's current scenario information, user requests, intelligent driving requests, and main function service requests issued by the main function service layer through the functional safety service layer; the first judgment module 200 is used to determine whether the current scenario is a hazardous scenario based on the current scenario information, and to determine whether the user request or intelligent driving request is consistent with the main function service request; the first transmission module 300 is used to determine whether, within the maximum permissible fault time, a situation occurs where the user request or intelligent driving request is consistent with the main function service request if the current scenario is a hazardous scenario and the user request or intelligent driving request is inconsistent with the main function service request, and to pass through the main function service request to the functional abstract service layer if a situation occurs where the user request or intelligent driving request is consistent with the main function service request.
[0069] Optionally, in some embodiments, the above-mentioned vehicle functional safety monitoring device 10 further includes: a second transmission module, used to directly transmit the main functional service request to the functional abstract service layer if the current scenario is not a hazardous scenario and / or the user request or intelligent driving request is consistent with the main functional service request.
[0070] Optionally, in some embodiments, before receiving the vehicle's current scenario information, user requests, intelligent driving requests, and main function service requests issued by the main function service layer through the functional safety service layer, the receiving module 100 is specifically used to: determine whether there is an abnormality in the vehicle's drive equipment; if there is no abnormality in the vehicle's drive equipment, then receive the vehicle's current scenario information, user requests, intelligent driving requests, and main function service requests issued by the main function service layer through the functional safety service layer.
[0071] Optionally, in some embodiments, the above-mentioned vehicle functional safety monitoring device 10 further includes: a control module, used to control the vehicle to enter a safe state when there is an abnormality in the vehicle's drive equipment, or when a user request or intelligent driving request is consistent with the main function service request; a second judgment module, used to judge whether the safe state can be restored; and a third judgment module, used to re-judge whether there is an abnormality in the vehicle's drive equipment if the safe state can be restored, otherwise, to maintain the vehicle in a safe state.
[0072] Optionally, in some embodiments, the maximum permissible failure time is obtained by the functional safety service layer by decomposing user requests or intelligent driving requests with main function service requests through the Fault Tolerance Time Interval (FTTI).
[0073] It should be noted that the foregoing explanation of the vehicle functional safety monitoring method embodiment also applies to the vehicle functional safety monitoring device of this embodiment, and will not be repeated here.
[0074] The vehicle functional safety monitoring device proposed in this application receives current scenario information, user requests, intelligent driving requests, and main functional service requests issued by the main functional service layer through the functional safety service layer. Based on the current scenario information, it determines whether the current scenario is a hazardous scenario and whether the user request or intelligent driving request is consistent with the main functional service request. If the current scenario is a hazardous scenario and the user request or intelligent driving request is inconsistent with the main functional service request, it determines whether a situation occurs within the maximum permissible fault time where the user request or intelligent driving request is consistent with the main functional service request. If such a situation occurs, the main functional service request is transparently transmitted to the functional abstract service layer. This solves the problem that software developed based on SOA architecture cannot meet functional safety level requirements, enabling the entire vehicle to achieve a safe state and safety objectives.
[0075] Figure 5 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include:
[0076] The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.
[0077] When processor 502 executes the program, it implements the vehicle functional safety monitoring method provided in the above embodiments.
[0078] Furthermore, the vehicle also includes:
[0079] Communication interface 503 is used for communication between memory 501 and processor 502.
[0080] The memory 501 is used to store computer programs that can run on the processor 502.
[0081] The memory 501 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.
[0082] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0083] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.
[0084] Processor 502 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of this application.
[0085] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described vehicle functional safety monitoring method.
[0086] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0087] Furthermore, 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 technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0088] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0089] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.
[0090] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.
[0091] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.
Claims
1. A method for monitoring the functional safety of a vehicle, characterized in that, The vehicle includes a service-oriented architecture (SOA), which comprises a main functional service layer, a functional safety service layer, and a functional abstraction service layer. The method includes the following steps: The functional safety service layer receives the vehicle's current scenario information, user requests, intelligent driving requests, and main function service requests issued by the main function service layer. Based on the current scenario information, determine whether the current scenario is a hazardous scenario, and determine whether the user request or the intelligent driving request is consistent with the main function service request; and If the current scenario is the hazardous scenario, and the user request or the intelligent driving request is inconsistent with the main function service request, then it is determined whether the user request or the intelligent driving request is consistent with the main function service request within the maximum allowable fault time. If the user request or the intelligent driving request is consistent with the main function service request, the main function service request is passed through to the function abstract service layer. The functional abstraction service layer is used to implement the functional abstraction of hardware. The functional abstraction service layer receives service requests from the functional safety service layer and drives related functions. The functional abstraction service layer can obtain fault information, current information, and status information of the driving device, including but not limited to, and feed this information back to the functional safety service layer. The functional abstraction service layer is located at the bottom layer of the entire service and is developed according to the functional safety requirements.
2. The method according to claim 1, characterized in that, Also includes: If the current scenario is not the hazardous scenario, and / or the user request or the intelligent driving request is consistent with the main function service request, then the main function service request is directly passed through to the function abstract service layer.
3. The method according to claim 1, characterized in that, Before receiving the vehicle's current scenario information, the user request, the intelligent driving request, and the main function service request issued by the main function service layer through the functional safety service layer, the method further includes: Determine if there is any abnormality in the vehicle's drive system; If the vehicle's drive system is not malfunctioning, the functional safety service layer receives the vehicle's current scenario information, the user request, the intelligent driving request, and the main function service request issued by the main function service layer.
4. The method according to claim 1 or 3, characterized in that, Also includes: If there is an abnormality in the vehicle's drive system, or if the user request or the intelligent driving request is consistent with the main function service request, the vehicle shall be controlled to enter a safe state. Determine whether the security state can be restored; If the safety status can be restored, then the vehicle's drive system is reassessed for any abnormalities; otherwise, the vehicle remains in the safety status.
5. The method according to claim 1, characterized in that, The maximum permissible failure time is obtained by the Functional Safety Service Layer through Fault Tolerance Time Interval (FTTI) decomposition of the user request or the intelligent driving request and the main function service request.
6. A functional safety monitoring device for a vehicle, characterized in that, The vehicle includes a service-oriented architecture (SOA), which comprises a main function service layer, a functional safety service layer, and a functional abstraction service layer. The device includes: The receiving module is used to receive the vehicle's current scene information, user requests, intelligent driving requests, and main function service requests issued by the main function service layer through the functional safety service layer. The first judgment module is used to determine whether the current scene is a hazardous scene based on the current scene information, and to determine whether the user request or the intelligent driving request is consistent with the main function service request; and The first transmission module is configured to determine whether the user request or the intelligent driving request is consistent with the main function service request within the maximum allowable fault time if the current scenario is the hazardous scenario and the user request or the intelligent driving request is inconsistent with the main function service request, and if the user request or the intelligent driving request is consistent with the main function service request, then the main function service request is transparently transmitted to the function abstract service layer. The functional abstraction service layer is used to implement the functional abstraction of hardware. The functional abstraction service layer receives service requests from the functional safety service layer and drives related functions. The functional abstraction service layer can obtain fault information, current information, and status information of the driving device, including but not limited to, and feed this information back to the functional safety service layer. The functional abstraction service layer is located at the bottom layer of the entire service and is developed according to the functional safety requirements.
7. The apparatus according to claim 6, characterized in that, Also includes: The second transmission module is used to directly transmit the main function service request to the function abstract service layer if the current scenario is not the hazardous scenario, and / or the user request or the intelligent driving request is consistent with the main function service request.
8. The apparatus according to claim 6, characterized in that, Before receiving the vehicle's current scenario information, the user request, the intelligent driving request, and the main function service request issued by the main function service layer through the functional safety service layer, the receiving module is specifically used for: Determine if there is any abnormality in the vehicle's drive system; If the vehicle's drive system is not malfunctioning, the functional safety service layer receives the vehicle's current scenario information, the user request, the intelligent driving request, and the main function service request issued by the main function service layer.
9. A vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the functional safety monitoring method for a vehicle as described in any one of claims 1-5.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the functional safety monitoring method for vehicles as described in any one of claims 1-5.
Citation Information
Patent Citations
Vehicle-mounted central computer
CN114261356A