Function safety analysis method and system for automobile software continuous integration

Abstract

The invention discloses a function safety analysis method and system for automobile software continuous integration. The method comprises the following steps: taking an existing security file as a baseline, and obtaining a change item relative to the baseline; automatically classifying the change items according to a preset classification rule by utilizing a change type identification model based on machine learning training so as to identify target change items related to functional safety; executing a differentiated safety analysis process corresponding to the type of the target change item on the target change item; and updating a security file based on an analysis result, and taking the security file as a baseline of next iteration. Through AI automatic classification and screening, one-by-one manual analysis is avoided, manpower is saved, and errors are reduced; by triggering differentiation analysis, precise delivery of security resources and pertinence of the process are realized; and through iterative updating of the baseline, an automatic safety management closed loop adaptive to continuous integration is formed, and the development efficiency and quality are remarkably improved on the premise of ensuring compliance.

Description

Technical Field

[0001] This invention relates to the fields of automotive electronics and functional safety technology, specifically to a method and system for automating and intelligently analyzing the impact of functional safety changes in a continuous integration (CI) and continuous deployment (CD) environment. Background Technology

[0002] As vehicles become increasingly intelligent and connected, automotive software systems are becoming more complex and their development and iteration speed is accelerating. To cope with rapidly changing market demands, agile development and continuous integration / continuous deployment (CI / CD) have become mainstream practices in automotive software engineering. However, this has created a significant conflict with the automotive industry's stringent functional safety standards (such as ISO 26262).

[0003] According to ISO 26262, during the development of vehicle-related items, any changes to functions, requirements, designs, or hardware / software modules must undergo a systematic "impact analysis" to assess the impact of the change on existing functional safety objectives, safety requirements, and technical solutions. This process includes determining at the item level whether a completely new hazard analysis and risk assessment (HARA) is needed, and at the element level analyzing whether reused or modified elements still meet safety requirements.

[0004] In current development practices, the aforementioned impact analysis primarily relies on manual operations by functional safety engineers. Engineers need to review each change item (such as new features, modified requirements, code commits, hardware changes, etc.) one by one, manually determine its safety relevance, and decide on the depth of the safety analysis process to initiate. In frequent CI / CD iterations, this model leads to the following prominent problems: Inefficient and costly in terms of manpower: Each iteration generates a large number of changes that require initial manual review, which consumes a lot of engineers' time in repetitive work.

[0005] The analysis quality is unstable and prone to errors and omissions: human judgment is greatly affected by the engineer's experience and the state of the situation. Under high pressure and high frequency of change, it is easy to produce analysis bias or omissions, which may result in potential safety risks not being identified.

[0006] Rigid processes and lack of precision: It is difficult to quickly and accurately screen out the "critical few" that truly require in-depth security analysis from a massive number of changes, resulting in unreasonable allocation of security analysis resources or over-analysis of all changes in a "one-size-fits-all" manner.

[0007] Therefore, there is an urgent need for a functional safety change handling method that can be seamlessly integrated with the CI / CD process, and is automated and intelligent, in order to improve development efficiency and quality while ensuring functional safety compliance.

[0008] The methods described in this section are not necessarily methods that had been previously conceived or adopted. Unless otherwise specified, no method described in this section should be assumed to be prior art simply because it is included in this section. Similarly, unless otherwise specified, the issues mentioned in this section should not be considered to be accepted in any prior art. Summary of the Invention

[0009] The present invention aims to overcome the above-mentioned defects of the prior art and provide a functional safety analysis method and system for continuous integration of automotive software. Its core lies in using artificial intelligence technology to automatically classify and screen changes, and trigger differentiated safety analysis processes accordingly, thereby realizing automated, accurate and iterative management of safety analysis work.

[0010] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: In a first aspect, the present invention provides a functional safety analysis method for continuous integration of automotive software, comprising: The existing functional safety profile is used as the baseline for current safety analysis; Obtain the changes relative to the current security analysis baseline; A change type identification model trained based on machine learning is used to classify the change items in order to identify target change items related to functional safety from the change items. The classification is based on preset change classification rules. Based on the type of change, a differentiated security analysis process is performed on the identified target change. Based on the results of the aforementioned safety analysis process, the functional safety profile is updated, and the updated functional safety profile is used as the baseline for the next iteration of safety analysis.

[0011] Preferably, the preset change classification rules define multiple change categories, including at least: vehicle functional safety-related categories that require incremental hazard and risk assessment, and element change categories involving software or hardware implementation. Further, the change categories may also include: non-functional related categories, functional enhancement but non-safety-related categories, and categories involving modifications to interfaces with non-safety functions.

[0012] Preferably, classifying change items using a change type identification model trained based on machine learning includes: training the change type identification model based on historical change data and manually labeled category tags; inputting the change item into the trained model, and having the model output its change category.

[0013] Preferably, the differentiated safety analysis process includes: if the target change item is classified as a vehicle functional safety related category, then an incremental hazard and risk assessment analysis is performed; if the target change item is classified as an element change category, then an impact domain analysis is performed to determine the impact of the change on existing safety objectives and safety requirements.

[0014] Preferably, the method further includes: after using the updated functional safety profile as the baseline for security analysis in the next iteration, performing verification tests on the system after the changes are implemented, wherein the verification tests include regression tests for existing security functions and specific tests for the changed content.

[0015] Secondly, the present invention provides a functional safety analysis system for continuous integration of automotive software, comprising: The baseline management unit is used to maintain the current security analysis baseline, which is based on the existing functional safety profile. A change collection unit is used to acquire change items relative to the current security analysis baseline; The intelligent classification unit is used to classify the change items using a change type recognition model trained based on machine learning, so as to identify target change items related to functional safety from the change items, the classification being based on preset change classification rules; The analysis and execution unit is used to perform a differentiated security analysis process corresponding to the change type of the identified target change item; The file update unit is used to update the functional safety file based on the results of the security analysis process. The baseline management unit is further used to set the updated functional safety profile as the safety analysis baseline for the next iteration.

[0016] Preferably, the system further includes a model training unit for training and generating or optimizing the change type recognition model in the intelligent classification unit based on historical change data and manually labeled category tags.

[0017] Thirdly, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements a functional safety analysis method for continuous integration of automotive software as described in the first aspect of the present invention.

[0018] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a functional safety analysis method for continuous integration of automotive software as described in the first aspect of the present invention.

[0019] Compared with the prior art, the beneficial effects of the present invention are: 1. Significantly improve efficiency and reduce labor costs: The change type identification model automatically completes the initial classification and screening of change items, freeing security engineers from the heavy and repetitive manual preliminary review work, allowing them to focus on in-depth security analysis that requires professional judgment, significantly improving overall work efficiency and reducing project labor costs.

[0020] 2. Improve the accuracy and consistency of analysis: The change type identification model, trained on a large amount of historical data, can make objective and stable judgments based on unified classification rules, effectively avoiding analysis omissions or inconsistent standards caused by human fatigue and experience differences, thus improving the comprehensiveness and reliability of functional safety analysis.

[0021] 3. Achieving Precision and Differentiation in Security Analysis: By accurately categorizing changes, the system can automatically trigger the most suitable security analysis sub-processes (such as incremental HARA or impact domain analysis). This allows for precise allocation of security resources, avoiding "over-analysis" or "under-analysis," and optimizing the analysis process while ensuring security.

[0022] 4. Supports rapid and safe iteration of CI / CD: This invention seamlessly embeds functional safety analysis into the CI / CD pipeline, forming an automated closed loop of "baseline-change-analysis-update baseline". Each iteration starts with a clear safety status, and the impact of changes is quickly assessed and integrated into the new safety baseline, thereby supporting rapid and continuous iterative development of automotive software while complying with functional safety standards.

[0023] 5. Reduce process complexity: The change type recognition model can understand changes described in natural language, which reduces the strict requirements on change submission format, simplifies the developer participation process, and is more in line with agile development practices. Attached Figure Description

[0024] Figure 1 This is a schematic flowchart of a functional safety analysis method for continuous integration of automotive software provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a functional safety analysis system for continuous integration of automotive software, provided in an embodiment of the present invention. Figure 3 This is a schematic diagram of an electronic device structure provided in an embodiment of the present invention. Detailed Implementation

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

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

[0027] In the description of this application, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0028] Example 1 Please see Figure 1 This illustration shows a flowchart of a functional safety analysis method for continuous integration of automotive software, provided by an embodiment of the present invention. This method can be integrated into a CI / CD server or a dedicated functional safety management platform and automatically triggered during each code integration or project build.

[0029] Specifically, this functional safety analysis method includes the following steps: Step S110: Establish and load the current security analysis baseline. This baseline is the complete state of the validated and solidified functional safety profile after the last iteration, and typically includes version snapshots of published HARA reports, Safety Goals, Functional Safety Requirements (FSRs), Technical Safety Requirements (TSRs), and related architecture documents.

[0030] By establishing a clear and traceable starting point for iteration, the security management process under frequent changes becomes more standardized and orderly, laying the foundation for continuous security status management in "continuous integration".

[0031] Step S120: Collect Changes. Through interfaces with version control systems (such as Git), requirements management tools (such as JIRA, DOORS), design databases, etc., automatically collect all committed, modified, or added entries since the previous baseline version. These "changes" are descriptions of differences relative to the baseline in Step S110, and may include textual or structured information such as requirement entries, design document paragraphs, software code commit logs, and hardware configuration change descriptions. Automated collection replaces manual summarization, providing input for subsequent batch processing and improving workflow startup efficiency.

[0032] Step S130: AI Intelligent Classification and Filtering. Input the collected list of changes into a pre-trained change type recognition model. This model is built based on machine learning algorithms (such as text classification models and natural language processing models). Its training process includes: First, defining a set of structured change classification rules based on enterprise or project experience, for example: Category A (Non-functional): Such as UI text modification, log format adjustment.

[0033] Category B (Function Enhancement but Not Security Related): Such as adding sound effects to the music player.

[0034] Category C (related to vehicle functional safety): such as adding automatic emergency braking (AEB) function, or exporting vehicles to areas with new regulations.

[0035] Category D (Software Element Changes): Such as fixing bugs in the brake control algorithm or adjusting sensor fusion parameters.

[0036] Category E (Hardware Element Changes): Such as changing the radar model or modifying the power supply circuit design.

[0037] Type F (Interface Change): Such as an insecure navigation module sending a new signal to a secure chassis module.

[0038] Then, a large amount of historical change data is collected, and security experts label it according to the above rules. Finally, the labeled data is used to train the model, enabling it to learn to map change descriptions to corresponding categories. In the application phase, the model automatically classifies the input changes and outputs a list of changes with category labels. Based on this, the system quickly filters out "target changes" such as C, D, E, and F, which are strongly related to functional safety.

[0039] By using AI-powered intelligent classification and screening, we no longer need to manually classify and screen each change, saving significant manpower costs and avoiding oversights and errors caused by human intervention. At the same time, training the AI ​​with well-defined rules makes the identification more accurate and consistent. Finally, the AI ​​can understand natural language descriptions, reducing the strict requirements on the format of change descriptions and simplifying change management.

[0040] Step S140: Perform differentiated security analysis. This step calls different analysis sub-processes based on the classification results: For Category C changes, the system triggers an incremental HARA analysis process. Based on the existing HARA report, security engineers or auxiliary tools will analyze potential new hazard events, assess their risk levels (ASILs), and derive new security objectives for the new function or scenario.

[0041] For example, when adding "HWP (Highway Automated Driver Assistance) Functionality," the engine automatically creates an "Incremental HARA Analysis Task" and links it to the HARA database in the baseline. It may pre-populate some information, such as suggesting an analysis scenario of "highway," and prompting engineers to assess potential hazards such as "the system incorrectly keeping its lane." After the analysis is complete, the newly derived safety objectives (such as "SG-101: HWP systems should avoid unintended lateral displacements, ASIL B") are automatically added to the safety requirements management library.

[0042] For changes classified as D, E, and F, the system triggers an impact domain analysis process. Analysts or tools will trace the software modules, hardware components, or interfaces affected by the change to determine which existing security objectives, functional safety requirements, and technical safety concepts are affected, and assess whether these existing requirements can still be met or whether adjustments are needed.

[0043] For example, if the parameter is modified to meet the battery over-temperature protection threshold, the engine triggers an "impact domain analysis." The system automatically traces the Battery Management Controller (BMC) software module to which the parameter belongs, and then uses a requirement traceability matrix to find all the safety requirements that the module is responsible for implementing (e.g., "TSR-205: The BMC should request a reduction in charging power within X milliseconds when the cell temperature exceeds T_max, ASIL C"). The analysis task guides engineers to focus on evaluating: After the parameter modification, can TSR-205 still be met under all conditions? Is it necessary to update the corresponding test cases? The analysis conclusions are recorded and linked to the change item.

[0044] By accurately identifying change types, the system can automatically trigger the most suitable and differentiated security analysis processes (such as incremental HARA or impact domain analysis). This enables precise allocation of security analysis resources, avoiding a "one-size-fits-all" approach to analysis, achieving precision and targeting in security analysis, and significantly improving analysis efficiency while ensuring security.

[0045] Step S150: Update the security profile and baseline. Based on the analysis results of step S140, the system assists or automatically updates relevant functional safety documents, such as updating HARA reports, adding or modifying security requirements, updating security cases, etc., and ensuring that all changes are traceable. After the update is completed, the complete and verified security profile generated in this iteration is sealed and established as the new security analysis baseline, which will be used as the starting point for the next iteration, thus forming a complete closed loop.

[0046] By updating security profiles and baselines, automated updates and version management of security profiles are achieved, preserving complete change logs to meet standard requirements. More importantly, it "baselines" the security status and iteratively updates it, forming an automated "analysis-update-reanalysis" closed loop. This enables the system to continuously and efficiently respond to subsequent changes, supporting rapid continuous integration development.

[0047] Step S160 (Optional but Preferred): Security Verification. After the deployment change, perform automated or manual security testing. This includes: 1) regression testing to ensure that existing security functions have not been compromised; and 2) targeted testing to verify the new security requirements or modifications involved in the change. Test results can be fed back and reinforce the new security baseline.

[0048] Through automated or guided verification testing, it is ensured that each change not only undergoes theoretical analysis but also meets security requirements after actual implementation, forming a complete security assurance loop and further reducing the possibility of introducing security risks.

[0049] Example 2 Please see Figure 2 This illustrates a functional safety analysis system for continuous integration of automotive software, provided by an embodiment of the present invention. Specifically, the functional safety analysis system includes: The baseline management unit is used to maintain the current security analysis baseline, which is based on the existing functional safety profile. A change collection unit is used to acquire change items relative to the current security analysis baseline; The intelligent classification unit is used to classify the change items using a change type recognition model trained based on machine learning, so as to identify target change items related to functional safety from the change items, the classification being based on preset change classification rules; The analysis and execution unit is used to perform a differentiated security analysis process corresponding to the change type of the identified target change item; The file update unit is used to update the functional safety file based on the results of the security analysis process. The baseline management unit is further used to set the updated functional safety profile as the safety analysis baseline for the next iteration.

[0050] Preferably, the system further includes a model training unit for training and generating or optimizing the change type recognition model in the intelligent classification unit based on historical change data and manually labeled category tags.

[0051] According to one aspect of this disclosure, an electronic device is also disclosed, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods described above.

[0052] According to one aspect of this disclosure, a non-transitory computer-readable storage medium is also disclosed, wherein computer instructions are stored therein, which, when executed by a computer, implement the above-described method.

[0053] According to one aspect of this disclosure, a computer program product is also disclosed, comprising a computer program, wherein, The computer program implements the above method when executed by the processor.

[0054] refer to Figure 3 The present invention describes a structural block diagram of an electronic device 600 that can serve as a server or client of the present disclosure, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0055] like Figure 3As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0056] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, output unit 607, storage unit 608, and communication unit 609. Input unit 606 can be any type of device capable of inputting information to electronic device 600. Input unit 606 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device, and can include, but is not limited to, a mouse, keyboard, touchscreen, trackpad, trackball, joystick, microphone, and / or remote control. Output unit 607 can be any type of device capable of presenting information, and can include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 608 can include, but is not limited to, disk and optical disk. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and can include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth™ devices, 802.11 devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0057] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as image processing methods. For example, in some embodiments, the image processing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the image processing method described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform image processing methods by any other suitable means (e.g., by means of firmware).

[0058] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0059] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0060] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, and portable compact disc read-only memory (CD). ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0061] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0062] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0063] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via a communication network. This is achieved by having clients running on corresponding computers and interacting with each other. Computer programs that establish server-side relationships use this information to create client-server relationships. A server can be a cloud server, a server in a distributed system, or a server integrated with blockchain technology.

[0064] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0065] While embodiments or examples of this disclosure have been described with reference to the accompanying drawings, it should be understood that the methods, systems, and devices described above are merely exemplary embodiments or examples, and the scope of the invention is not limited by these embodiments or examples, but only by the granted claims and their equivalents. Various elements in the embodiments or examples may be omitted or replaced by their equivalents. Furthermore, the steps may be performed in a different order than that described in this disclosure. Further, various elements in the embodiments or examples may be combined in various ways. Importantly, as the technology evolves, many elements described herein can be replaced by equivalents that appear after this disclosure.

Claims

1. A functional safety analysis method for continuous integration of automotive software, characterized in that, include: The existing functional safety profile is used as the baseline for current safety analysis; Obtain the changes relative to the current security analysis baseline; A change type identification model trained based on machine learning is used to classify the change items in order to identify target change items related to functional safety from the change items. The classification is based on preset change classification rules. Based on the type of change, a differentiated security analysis process is performed on the identified target change. Based on the results of the aforementioned safety analysis process, the functional safety profile is updated, and the updated functional safety profile is used as the baseline for the next iteration of safety analysis.

2. The method according to claim 1, characterized in that, The preset change classification rules define multiple change categories, including at least: vehicle functional safety related categories that require incremental hazard and risk assessment, and element change categories involving software or hardware implementation.

3. The method according to claim 2, characterized in that, The change categories also include: non-functional related categories, functional enhancement but non-security related categories, and categories involving modifications to interfaces with non-security functions.

4. The method according to claim 1, characterized in that, The method of classifying change items using a change type identification model trained based on machine learning includes: Based on historical change data and manually labeled category tags, the change type recognition model is trained. The changes are input into the trained model, and the model outputs the change category to which they belong.

5. The method according to claim 1 or 2, characterized in that, The differentiated security analysis process includes: If the target change item is classified as a vehicle functional safety related category, then an incremental hazard and risk assessment analysis is performed; If the target change is classified as an element change, then an impact domain analysis is performed to determine the impact of the change on existing security objectives and security requirements.

6. The method according to claim 1, characterized in that, The updated security profile includes: updating at least one of the following: hazard and risk assessment report, security objectives, and technical security requirements document, and recording change history.

7. The method according to claim 1, characterized in that, Also includes: After using the updated functional safety profile as the baseline for the next iteration of security analysis, verification tests are conducted on the system after the changes are implemented. These verification tests include regression tests on existing security functions and specific tests on the changes.

8. A functional safety analysis system for continuous integration of automotive software, characterized in that, include: The baseline management unit is used to maintain the current security analysis baseline, which is an existing functional safety profile. A change collection unit is used to acquire change items relative to the current security analysis baseline; The intelligent classification unit is used to classify the change items using a change type recognition model trained based on machine learning, so as to identify target change items related to functional safety from the change items, the classification being based on preset change classification rules; The analysis and execution unit is used to perform a differentiated security analysis process corresponding to the change type of the identified target change item; The file update unit is used to update the functional safety file based on the results of the security analysis process. The baseline management unit is further used to set the updated functional safety profile as the safety analysis baseline for the next iteration.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images