Integrated avionics system demand analysis method based on large model LoRA fine tuning

Abstract

The invention discloses an integrated avionics system demand analysis method based on large model LoRA fine tuning, and the method comprises the following steps: collecting demand contents, dividing the demand contents, and obtaining different types of demand texts; designing a corresponding demand template based on the semantic structure and the expression feature of each type of demand text; constructing a modular demand analysis data set based on the demand template; performing fine tuning training on the large language model by using the modular demand analysis data set to obtain a demand analysis model; and realizing avionics system demand analysis based on the demand analysis model.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of safety-critical system development, and particularly relates to a comprehensive avionics system requirement analysis method based on large model LoRA fine-tuning. BACKGROUND

[0002] Safety-critical system refers to a system that, in the event of a failure or malfunction during operation, may cause personnel injury, equipment damage or significant economic loss. Such systems are typically used in aerospace, nuclear power, rail transportation and medical fields that have extremely high requirements for safety, reliability and predictability.

[0003] Integrated modular avionics (IMA) is one of the typical safety-critical systems, which integrates multiple avionics function modules on a unified hardware platform to achieve resource sharing and task isolation, thereby improving the scalability and maintainability of the system while ensuring safety. The design and development of IMA systems must strictly follow avionics software standards (such as ARINC 653, DO-178C, etc.), and requirement analysis as a prerequisite for system development has a decisive influence on system function correctness and safety certification.

[0004] Traditional safety-critical system requirement analysis mainly relies on manual methods, including expert experience analysis, structured requirement modeling and formal verification processes. Although such methods can ensure a certain level of accuracy and traceability, as the scale and coupling complexity of avionics system functions continue to grow, the manual requirement analysis process gradually exposes problems such as low efficiency, high cost and difficulty in covering complex interaction scenarios, making it difficult to meet the rapid development and verification needs of new-generation avionics systems.

[0005] In recent years, with the rapid development of large language models (LLM), the natural language understanding and generation capabilities based on large language models have gradually shown broad application potential in software engineering, requirement analysis and system modeling. Researchers have begun to explore the use of large language models for requirement identification, requirement extraction and requirement consistency checking, thereby improving the automation level and analysis accuracy of requirement analysis, becoming one of the current research hotspots.

[0006] However, existing large language models still face problems such as insufficient domain knowledge, parameter redundancy and excessive consumption of computing resources when directly applied to safety-critical system requirement analysis. SUMMARY

[0007] Invention purpose: In order to overcome the problems of high degree of artificial dependence, low efficiency, insufficient accuracy and difficulty in adapting to the continuous improvement of system scale and complexity in the existing comprehensive modular avionics system requirement analysis process, the application proposes a comprehensive avionics system requirement analysis method based on large model LoRA fine tuning.

[0008] Technical scheme: A comprehensive avionics system requirement analysis method based on large model LoRA fine tuning, comprising the following steps: Collecting requirement content, dividing the requirement content to obtain different types of requirement text; Designing corresponding requirement templates based on the semantic structure and expression characteristics of each type of requirement text; Based on the requirement template, a modular requirement analysis dataset is constructed; Fine-tune the large language model using the modular requirement analysis dataset to obtain a requirement analysis model; Based on the requirement analysis model, the avionics system requirement analysis is realized.

[0009] Further, the requirement text includes process requirement text, performance requirement text, design constraint text, architecture requirement text, resource requirement text, mode requirement text, communication requirement text and program requirement text.

[0010] Further, the requirement template defines the input and output fields in the form of parameter placeholders.

[0011] Further, the requirement analysis model includes: architecture analysis model, resource analysis model, mode analysis model, communication analysis model and program analysis model.

[0012] Further, the architecture analysis model is based on process requirement text to generate architecture requirement of avionics system, which is used to describe the overall structure and organization relationship between functional modules; The resource analysis model combines process requirement text and architecture requirement text to analyze and deduce the resource configuration of avionics system, and determines the resource requirement of each module, partition and task; The mode analysis model generates mode requirement text according to process requirement text, which is used to describe the mode switching mechanism and interface connection relationship of avionics system in different running stages; The communication analysis model generates communication requirement text based on process requirement text to clarify the data interaction path, communication mode and port mapping relationship between internal and cross-module of avionics system; The program analysis model deduces program requirement text based on process requirement text to determine the calling relationship, parameter interaction mode and execution order of various programs in avionics system.

[0013] Furthermore, the construction of a modular requirements analysis dataset based on the requirements template specifically includes: According to the requirements analysis task, the modular requirements analysis dataset includes a subset of architecture analysis data, a subset of resource analysis data, a subset of module and device pattern analysis data, a subset of partition and network interface pattern analysis data, a subset of inter-partition communication analysis data, a subset of intra-partition communication analysis data, and a subset of program analysis data. Based on the core functional characteristics and task division of avionics systems, avionics systems are systematically classified into multiple categories; Each data subset includes data from these multiple categories; Each data sample is organized using a uniform format, as follows: {“instruction”: “task_type”, “input”: “input_requirement”, “output”: “output_requirement”} in: “instruction” indicates the type of requirements analysis task; “input” represents the input requirements corresponding to the specific requirements analysis task type; “output” indicates the output requirements corresponding to the type of requirements analysis task.

[0014] Furthermore, the large language model adopts a Transformer architecture, consisting of an encoder and a decoder; the encoder is responsible for the information representation and context modeling of the input sequence, and the decoder is responsible for generating the target output text based on the context semantics; The encoder consists of multiple stacked self-attention layers and a feedforward network. The self-attention layers are used to calculate the global dependencies between words in the input sequence and obtain the context-related representation of the input sequence through the Scaled Dot-Product Attention mechanism. The feedforward network performs nonlinear transformation and feature extraction on the hidden state at each position.

[0015] Furthermore, fine-tuning training of the large language model is performed, including using the LoRA method, QLoRA method, or AdaLoRA method to fine-tune the large language model. The LoRA method introduces two low-rank matrices A and B into several linear transformation layers of a large language model, keeping the original weight matrix W frozen and training only on matrices A and B, thereby making ΔW = A×B as a compensation update for the weight matrix W. The QLoRA method, based on the imported LoRA adapter, stores the weights of the large language model in a 4-bit quantization format, performs dequantization and gradient propagation operations during backpropagation, and only updates the LoRA matrix. The AdaLoRA method introduces a dynamic rank allocation strategy based on the LoRA structure, which adaptively allocates the rank r of the low-rank matrix to different layers or modules during training according to the model level and task feedback.

[0016] Beneficial Effects: This invention collects and organizes relevant information on various avionics systems from multiple channels; designs corresponding requirement templates based on the content of requirement texts to support interactive development between users and large language models; constructs a requirement analysis framework for integrated modular avionics systems, clarifying the generation and transformation relationships between different requirements; combines the requirement analysis framework and requirement templates to construct a standardized requirement analysis dataset; selects high-performance pre-trained large language models from domestic and international sources, uses the constructed dataset for LoRA series fine-tuning training, updates the learnable parameters of the models, and obtains a trained requirement analysis model after multiple rounds of iterative optimization; verifies the performance of the trained requirement analysis model using a test dataset, evaluates its analytical effect under different task scenarios, and encapsulates the model into a tool for academic research and industrial applications of avionics systems. This invention significantly improves the automation and accuracy of requirement analysis, reduces manual analysis costs, and enhances the development efficiency and reliability of integrated modular avionics systems. Compared with existing technologies, it has the following advantages: (1) The method of the present invention can significantly reduce the degree of manual involvement in the requirements analysis of integrated modular avionics systems and improve the efficiency of requirements extraction and classification; (2) The method of the present invention improves the domain adaptability and computational resource utilization of the model through LoRA series fine-tuning technology; (3) The method of the present invention realizes automatic correlation analysis between multiple types of requirements, and enhances the consistency of system-level requirements; (4) The method of the present invention provides a standardized evaluation system, providing an objective basis for the application of the model in the design, verification and safety assessment of avionics systems; (5) The method of the present invention supports the integrated deployment of academic research and industrial application, and has high scalability and application value. Attached Figure Description

[0017] Figure 1 This is an overall flowchart of the integrated avionics system requirements analysis method based on large model LoRA fine-tuning proposed in this invention; Figure 2 This is a framework diagram for the requirements analysis of an integrated modular avionics system based on LoRA series fine-tuning of a large language model, as proposed in this invention. Figure 3 Here is a diagram of the encoder structure; Figure 4 This is a schematic diagram of the LoRA series fine-tuning principle. Detailed Implementation

[0018] The method of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0019] This invention relates to a method and corresponding tools for integrated avionics system requirements analysis based on large model LoRA fine-tuning, which is used to improve the automation level and analysis accuracy of integrated modular avionics systems in the requirements analysis phase, reduce manual workload, and improve system development efficiency and reliability.

[0020] like Figure 1 As shown, the method proposed in this embodiment of the invention includes the following steps: Step 1: Data Collection and Classification. Relevant information on avionics systems is collected from various sources, including domestic and international books, journals, papers, and online platforms. The acquired avionics systems and their requirements documents are systematically organized and classified to provide a data foundation for subsequent analysis. This step involves data collection and classification, which can be divided into the following sub-steps: Sub-step 1: Collect relevant information on avionics systems from various channels, including domestic and international books, newspapers, magazines, academic papers, and online platforms. This includes the system architecture, functional components, operating mechanisms, communication protocols, task scheduling methods, resource allocation strategies, and typical application cases of avionics systems. The systematic collection and organization of this multi-channel information provides rich corpus support and technical basis for the subsequent construction and analysis of the requirements document.

[0021] Sub-step 2: Content analysis and classification of the requirements text. Through comprehensive analysis of the text's semantics and structure, the requirements are divided into eight categories: process requirements, performance requirements, design constraints, architecture requirements, resource requirements, pattern requirements, communication requirements, and program requirements.

[0022] in: Process requirements are used to standardize the working mechanism of the system at different stages of operation, so as to ensure the correctness of system functions and the predictability of the operation process.

[0023] Performance requirements describe the scheduling and communication characteristics of partitions and tasks in the system, mainly constraining and specifying system performance from aspects such as processor scheduling strategy, partition runtime, task configuration, and communication mechanism.

[0024] Design constraints describe the limitations and requirements on hardware and software configurations during system implementation, including detailed descriptions of module processors, partitioned runtime, memory allocation, task partitioning, mode settings, and program implementation.

[0025] Architecture requirements describe the overall structure of the system and the organizational relationships between key components to ensure that the system has a complete and consistent implementation framework at both the hardware and software layers.

[0026] Resource requirements are used to describe the binding relationships between various resources, partitions, and data within the system, ensuring the rationality and efficiency of resource allocation during system operation.

[0027] Mode requirements describe the mode switching and interface connection relationships of the system at different stages, covering mode conversion information for modules, devices, module network interfaces, and partitions.

[0028] Communication requirements describe the interface and port connection relationships of multi-level communication in the system, including port mapping and communication paths between modules, devices, module network interfaces, and partitions.

[0029] Program requirements are used to describe the calling relationships and parameter interaction methods of various programs in an integrated modular aviation system to ensure that the system functions as expected and meet real-time and safety requirements.

[0030] Through the above classification and organization, a structured expression of complex requirement texts can be achieved, providing data support and a logical foundation for subsequent requirement modeling and system analysis.

[0031] Sub-step 3: Based on the core functional characteristics and task division of the avionics system, the avionics system is systematically divided into six main categories: flight control system, communication system, navigation system, surveillance system, mission management system, and special extended system.

[0032] in: The flight control system is used to automatically control the flight attitude and trajectory. Its typical subsystems include: airspeed control system, altitude control system, automatic lateral trajectory control system, and automatic instrument landing system, etc., to ensure flight stability and safety. The communication system is used to realize information exchange and data transmission between the aircraft and the outside world. Its typical subsystems include: radio frequency communication system, satellite communication system, selective calling system and flight intercom system, etc., to support voice and data communication during flight missions; Navigation systems are used to provide positioning and navigation information for aircraft. Typical subsystems include the Global Positioning System (GPS), GLONASS, Galileo, and BeiDou, to ensure the accuracy and continuity of flight paths. The surveillance system is used to monitor flight status and environmental safety. Its typical subsystems include: Engine Indication and Crew Alarm System (EICAS / ECAM), Ground Proximity Warning System (GPWS / EGPWS), Air Collision Avoidance System (TCAS), and Electronic Checklist System (ECL), etc., to improve flight monitoring and risk warning capabilities. The mission management system is used to centrally manage flight missions and equipment status. Its typical subsystems include: Flight Management System (FMS), Power Management System (PMS), Data Management System (DMS), and Display Management System (DMS / EFIS), which are used to coordinate mission execution and resource allocation. Specialized extended systems are used to support specific mission scenarios or military extended functions. Typical subsystems include electronic warfare systems, radar warning systems, active jamming systems, and aerial refueling systems, to enhance the combat and survivability of avionics systems under special mission conditions.

[0033] Through the above functional classification and system division, hierarchical modeling of the avionics system architecture can be achieved, providing clear logical boundaries and functional basis for subsequent requirements analysis, architecture design and task allocation.

[0034] Step 2: Requirement Template Design. Based on the semantic structure and expressive characteristics of the aforementioned requirement text, a standardized and modular requirement template is designed to support interactive requirement development between users and the large language model. The requirement template defines input and output fields using parameter placeholders, including several placeholders marked with "[]" to represent variable fields that can be replaced by specific names, types, or quantities. This facilitates the unified extraction and modeling of subsequent requirement elements.

[0035] The process requirement template is used to standardize the working mechanism of the system in different operating stages to ensure functional correctness and predictability of operation; the operating stages include the initialization stage, the operating stage, and the termination stage.

[0036] During the initialization phase, the system completes resource allocation, parameter configuration, and environment self-check operations by placing modules and related devices in initialization mode and executing initialization procedures; partitions and network interfaces are set to cold start mode and cold start procedures are run to ensure that each functional unit is activated in a controlled manner.

[0037] During the operation phase, system modules and devices switch to operating mode, partitions and network interfaces enter normal communication mode, and tasks are executed according to a predefined scheduling order to achieve functional interaction and real-time processing.

[0038] During the termination phase, system modules and devices enter termination mode, partitions and network interfaces switch to idle state and execute termination procedures to release resources and exit safely.

[0039] The process requirement template is as follows, where System, Bus, System Manager, Module, Device, Module Manager, Module Network Interface, Partition, Task, Task Program, and Data are specific names. Communication includes sampling communication and queue communication between partitions, as well as blackboard communication, buffer communication, semaphore communication, and event communication within a partition.

[0040] The process requirement template includes: [System] ([Bus]) 1. Initialization Phase (1) Set [Module], ..., [Device], ... to initialization mode in [System Manager].

[0041] (2) [Module], .... [Device], ..... Execute the initialization program.

[0042] (3) Set [Partition], ... [Module Network Interface] to cold start mode in [Module Manager].

[0043] (4) [Partition], ... [Module Network Interface] execute the cold start procedure.

[0044] 2. Operational Phase (1) Set [Module], ..., [Device], ... to running mode in [System Manager].

[0045] (2) [Module], .... [Device], ..... Execute the running program.

[0046] (3) Set [Partition], ... [Module Network Interface] to normal mode in [Module Manager].

[0047] (4) [Partition], ... [Module Network Interface] execute the normal procedure.

[0048] (5) The task of [device] acquiring [data] and transmitting it to [partition] via [communication].

[0049] (6) The [task] of the [partition] executes the [task program], generates [data], and transmits it to the [task] of the [partition] via [communication].

[0050] (7) The [task] of the [partition] executes the [task program], generates [data], and transmits it to the [device] via [communication]. ... 3. Termination Phase (1) Set [Module], ..., [Device], ... to termination mode in [System Manager].

[0052] (2) [Module], .... [Device], ..... Execute the termination procedure.

[0053] (3) Set [Partition], ... [Module Network Interface] to idle mode in [Module Manager].

[0054] (4) [Partition], ... [Module Network Interface] execute the idle program.

[0055] The performance requirements template is used to describe the scheduling and communication performance constraints of partitions and tasks in the system, including processor scheduling, partition runtime, task configuration, and communication mechanisms.

[0056] At the processor level, the partition scheduling protocol, main frame duration, and scheduling scheme are defined; at the partition level, the task scheduling protocol and task switching time are specified; at the task level, the execution time, time capacity, period, deadline, priority, and type are described; at the communication mechanism level, the refresh period, queue size, queuing rules, and timeout policy of sampling, queues, blackboards, buffers, semaphores, and event communication are defined.

[0057] Performance requirements template, including: [System] ([Bus]) 1. [Module Processor] (1) Scheduling protocol: [Partition scheduling protocol].

[0058] (2) Module main frame: [Module runtime].

[0059] (3) Module scheduling: [Partition], [Partition runtime], [Whether to enable periodic processing]. ... (4) Partition swap execution time: [lower limit] - [upper limit]. ... 2. Partitioning during runtime (1) [Partition runtime], [task scheduling protocol], [task exchange execution time]. ... 3. Task (1) [Task], [Calculate Execution Time], [Time Capacity], [Deadline], [Period], [Priority], [Deadline Type]. ... 4. Sampling Communication (1) [Data], [Sampling refresh cycle]. ... 5. Queue Communication (1) [Data], [Queue Size], [Queue Rules], [Timeout]. ... 6. Blackboard Communication (1) [Data], [Timeout]. ... 7. Buffer communication (1) [Data], [Queue size], [Queue rules]. ... 8. Semaphore communication (1) [Data], [Queueing rules], [Timeout]. ... 9. event communication (1) [Data], [Timeout]. ... Design constraint templates are used to describe the limitations and requirements of hardware and software configuration in system implementation, including information such as module processor, partition runtime, partition memory, tasks, modes, and programs.

[0070] The module processor section defines the model, version, and serial number; the partition runtime section defines the authentication level, name, and serial number; the memory section defines the base address, storage capacity, and type; the task section describes the amount of code, data, and stack size; the mode section describes the initial mode, operating mode, and mode switching relationship; and the program section defines the program name, source file, and programming language. Design constraint templates include: [System] ([Bus]) 1. Module Processor (1) [Module processor], [Module version number], [Module number]. ... 2. Partitioning during runtime (1) [Partition runtime], [Development certification level], [Partition], [Partition number], [Whether it is a system partition]. ... 3. Partition memory (1) [Partition memory], [base address], [storage size], [storage protocol], [storage type]. ... 4. Partitioning (1) [Partition], [Data volume], [Code volume]. ... 5. Task (1) [Task], [Data volume], [Code volume], [Heap size], [Stack size]. ... 6. Module, device, and module network interface modes (1) Start mode: [mode].

[0076] (2) Other modes: [mode], ..... (3) Mode switching [Trigger Port]: [Mode]->[Mode]. ... (4) Pattern information [Pattern Number], [Pattern]. ... 7. Partitioning Mode (1) Start mode: [mode].

[0079] (2) Other modes: [mode], ..... (3) Mode switching [Trigger Port]: [Mode]->[Mode]. ... (4) Pattern information [Pattern Number], [Pattern]. ... 8. Procedure (1) [Program], [Source File], [Source Language], [Source Name]. ... The architecture requirements template is used to describe the overall structure and component organization of the system, including elements such as system manager, modules, devices, buses, data, and programs.

[0083] The module section is further subdivided into module manager, partitions, tasks, network interfaces, processors, and memory architecture; the device section describes the device type and quantity; the bus section defines the type and quantity; the data section describes the data objects and quantity; and the program section includes initialization, running, termination, cold start, normal operation, and idle programs. The architecture requirements template includes: [System] ([Bus]) 1. [System Manager].

[0084] 2. [Module] (1) [Module Manager].

[0085] (2) [Partition]: [Task], ..... ... (3) [Module network interface].

[0086] (4) [Module Processor]: [Partition Runtime], ..... (5) [Module Memory]: [Partitioned Memory], ..... ... 3. Equipment: [Quantity] [Equipment], ..... 4. Bus: [Quantity][Bus].

[0087] 5. Data: [Quantity][Data], ..... 6. Procedure (1) Modules and devices: initialization program, running program, termination program.

[0088] (2) Partitions and network interfaces: cold start program, normal program, idle program.

[0089] (3) Task: [Task Procedure], ..... Resource requirement templates are used to describe the binding relationships between resources and partitions and data in the system, including processor binding, memory binding and bus binding.

[0090] Processor binding defines the mapping between partitions and runtime environments; memory binding defines the mapping between partitions and partition memory; bus binding defines the data communication and bus access relationships. Resource requirement templates include: [System] ([Bus]) 1. Processor Bonding (1) [Partition] is bound to [Partition runtime]. ... 2. Memory Bonding (1) [Partition] is bound to [partition memory]. ... 3. Bus bonding (1) [Data] [communication] is bound to [bus]. ... The mode requirement template is used to describe the state switching and interface connection relationships of the system under different operating modes, covering mode conversion information of modules, devices, module network interfaces and partitions.

[0094] When switching module or device modes, the system manager output event port is connected to the module or device input event port; when switching module network interfaces or partitions, the module manager output port is connected to the corresponding input port. The mode requirement template includes: [System] ([Bus]) 1. Convert [module] to [mode], ..... (1) Output event port: [Port] in [System Manager], ... (2) Input event port: [port] of [module], ... (3) Port connection: [System Manager] [Port] -> [Module] [Port]. ... ... 2. [Device] to [Mode] (1) Output event port: [Port] in [System Manager], ... (2) Input event port: [port] of [device], .... (3) Port connection: [System Manager] [Port] -> [Device] [Port]. ... ... 3. Convert [Module Network Interface] to [Mode] (1) Output event port: [Port] in [Module Manager], ... (2) Input event port: [Port] of [Module Network Interface], ... (3) Port connection: [System Manager] [Port] -> [Module Network Interface] [Port]. ... ... 4. Convert [Partition] to [Mode] (1) Output event port: [Port] in [Module Manager], ... (2) Input event port: [port] of [partition], ... (3) Port connection: [Port] in [Module Manager] -> [Port] in [Partition]. ... ... The communication requirement template is used to describe the interface and port connection relationships of multi-level communication in the system, including port mapping and communication paths between modules, devices, module network interfaces and partitions.

[0100] Communication includes inter-division sampling communication and queue communication, intra-division blackboard communication, buffer communication, semaphore communication, and event communication. Sampling and queue communication uses a chained port connection method, while cross-module communication is implemented through a bus. Blackboard, buffer, and event communication are implemented through direct connection of task ports, and semaphore communication is implemented through the task data access interface for data binding. The communication requirement template includes: [System] ([Bus]) 1. Sampling communication of [data] (1) Output data ports: [port] of the [sending component], [port] of the [intermediate component], ... (2) Input data ports: [port] of [intermediate component], ..... [port] of [receiving component].

[0101] (3) Port connection: [Sending component] [port] -> [intermediate component] [port] ... -> [receiving component] [port].

[0102] (4) Bus access required: [bus access] of [transmitting component] and [bus access] of [receiving component].

[0103] (5) Bus access connection: [Transmitting component]'s [Bus access] -> [Bus] -> [Receiver component]'s [Bus access]. ... 2. Queue communication of [data] (1) Output event data ports: [port] of [sending component], [port] of [intermediate component], ... (2) Input event data ports: [port] of [intermediate component], ..... [port] of [receiving component].

[0105] (3) Port connection: [Sending component] [port] -> [Intermediate component] [port] -> [Intermediate component] [port] ... -> [Receiving component] [port].

[0106] (4) Bus access required: [bus access] of [transmitting component] and [bus access] of [receiving component].

[0107] (5) Bus access connection: [Transmitting component]'s [Bus access] -> [Bus] -> [Receiver component]'s [Bus access]. ... 3. Blackboard communication for [data] (1) Output data port: [port] of [task].

[0109] (2) Input data port: [port] of [task].

[0110] (3) Port connection: [Task]'s [Port] -> [Task]'s [Port]. ... 4. Buffer communication of [data] (1) Output event data port: [port] of [task].

[0112] (2) Input event data port: [port] of [task].

[0113] (3) Port connection: [Task]'s [Port] -> [Task]'s [Port]. ... 5. Semaphore communication of [data] (1) Data access required: [Task]'s [Data Access].

[0115] (2) Data access connection: [Task] [Data Access] -> [Data]. ... 6. Event Communication of [Data] (1) Output event port: [port] of [task].

[0117] (2) Input event port: [port] of [task].

[0118] (3) Port connection: [Task]'s [Port] -> [Task]'s [Port]. ... The program requirement template is used to describe the calling relationships and parameter interactions of various programs in the system to ensure that the system functions as expected and meet real-time requirements.

[0120] Modules and devices respectively call initialization, running, and termination procedures; partitions and module network interfaces call cold start, warm start, and normal operation procedures; tasks call their corresponding task programs, define input and output parameters, and achieve ordered interaction with data objects through ports. The program requirement template includes: [System] ([Bus]) 1. Initialize, run, and terminate the program. (1) Caller: [Module], ... [Device], ... 2. Cold start, warm start, normal, and idle programs. (1) Caller: [Partition], ... [Module Network Interface], ... 3. [Task Procedure] (1) Caller: [Module]'s [Partition]'s [Task].

[0121] (2) Input parameters: [data], ..... (3) Output parameters: [data], ..... (4) Parameter connection [Task] [Port] -> [Data]. ... [Data] -> [Task] [Port]. ... ... Step 3: Requirements Analysis Framework Construction. Establish a requirements analysis framework for the integrated modular avionics system, clarifying the generation relationships and transformation logic between different types of requirements, forming a system-level requirements correlation network. The requirements analysis framework for the integrated modular avionics system is as follows: Figure 2 As shown.

[0124] First, the pre-trained large language model is fine-tuned using LoRA series based on the requirements analysis dataset of a comprehensive modular avionics system, resulting in a requirements analysis model optimized for safety-critical systems. The fine-tuned model is then functionally divided into architecture analysis, resource analysis, pattern analysis, communication analysis, and program analysis models to achieve multi-dimensional requirements parsing and generation.

[0125] Within this framework, users first provide the system's process requirements, performance requirements, and design constraints as input.

[0126] Among them, the architecture analysis model is based on process requirements to generate system architecture requirements, which are used to describe the overall structure of the system and the organizational relationship between functional modules; Among them, the resource analysis model combines process requirements and architecture requirements to analyze and deduce the system's resource configuration, and determine the resource requirements of each module, partition and task. Among them, the pattern analysis model generates pattern requirements based on process requirements, which are used to describe the pattern switching mechanism and interface connection relationship of the system at different operating stages. Among them, the communication analysis model generates communication requirements based on process requirements in order to clarify the data interaction paths, communication methods and port mapping relationships within the system and between modules; The program analysis model derives program requirements based on process requirements, determines the calling relationships, parameter interaction methods, and execution order of various programs in the system, thereby ensuring the traceability and logical consistency of system functions.

[0127] Through the aforementioned multi-model collaborative requirements analysis framework, it is possible to achieve systematic requirements analysis and automated generation of integrated modular avionics systems at the architecture, resource, mode, communication, and program layers, providing a structured and reusable requirements foundation for subsequent system design and verification.

[0128] Step 4: Construction of the Requirements Analysis Dataset. Based on the requirements analysis framework and requirements template, a standardized requirements analysis dataset is constructed. This dataset contains requirements texts for different types of avionics systems, and the data is labeled and structured to ensure consistency in format and semantics among training samples, meeting the input requirements for fine-tuning the LoRA series of large language models.

[0129] The requirements analysis framework comprises seven tasks: architecture analysis, resource analysis, module and device pattern analysis, partition and network interface pattern analysis, inter-partition communication analysis, intra-partition communication analysis, and program analysis. The requirements analysis dataset is divided into seven corresponding subsets based on the task categories.

[0130] Each data subset contains a total of 570 data samples, including: 150 data samples from the flight control system, 140 data samples from the communication system, 140 data samples from the navigation system, 50 data samples from the surveillance system, 40 data samples from the mission management system, and 50 data samples from the special extended system.

[0131] Each data sample is organized using a uniform format, as follows: {“instruction”: “task_type”, “input”: “input_requirement”, “output”: “output_requirement”} in: “instruction” indicates the task type, which corresponds to the architecture analysis, resource analysis, pattern analysis, communication analysis, and program analysis in the requirements analysis process of integrated modular avionics systems; “input” indicates the input requirements corresponding to a specific task type; “output” indicates the output requirements corresponding to a specific task type.

[0132] The requirement analysis dataset constructed in the above manner can provide high-quality, standardized sample support for subsequent fine-tuning training of large language model requirement analysis, thereby improving the accuracy and generalization ability of the model in avionics system requirement analysis tasks.

[0133] Step 5: LoRA Fine-tuning Training of the Model. High-performing pre-trained large language models from both domestic and international sources are selected, and LoRA fine-tuning techniques (including LoRA, QLoRA, and AdaLoRA) are employed for domain-specific training using a constructed requirements analysis dataset. Through multiple rounds of iterative optimization, the learnable parameters of the model are updated to obtain a fully trained model suitable for requirements analysis of integrated modular avionics systems.

[0134] Among them, the pre-trained large language model adopts a typical Transformer architecture, which consists of an encoder and a decoder. The encoder is responsible for the information representation and context modeling of the input sequence, and the decoder is responsible for generating the target output text based on the context semantics.

[0135] The encoder consists of multiple stacked self-attention layers and a feed-forward network (FFN). The self-attention layers are used to calculate the global dependencies between words in the input sequence and obtain the context-related representation of the input sequence through the Scaled Dot-Product Attention mechanism. The feed-forward network performs non-linear transformations and feature extraction on the hidden states at each position to enhance the semantic expressive power of the model.

[0136] Each layer of the encoder includes two sub-layers: a self-attention sub-layer and a feedforward neural network sub-layer. Each sub-layer is equipped with a residual connection structure to maintain the stable transmission of input information. Layer normalization is performed after the output of each sub-layer to improve training stability and model convergence performance.

[0137] The working principle of the self-attention layer is as follows: First, for each word embedding vector in the input sequence, it is coupled with three sets of learnable weight matrices W. Q W K W V Matrix multiplication yields three corresponding feature vectors: query vector Q, key vector K, and value vector V. The weight matrix is ​​automatically optimized during model training using the gradient descent algorithm.

[0138] Next, the Q-vector of each input word is multiplied by the K-vectors of all other words in the sequence to obtain its relevance score to the words in the sentence. This score represents the intensity of attention the current word pays to other words during the encoding process. To prevent instability caused by excessively large gradients, the original dot product is divided by the square root of the dimension of the K-vector to achieve numerical scaling and gradient stability optimization.

[0139] The scaled result is then input into the Softmax function for normalization, converting all attention weights into a non-negative probability distribution with a sum of 1, thus achieving attention allocation among different words. The probability values ​​output by Softmax reflect the degree of attention the model pays to context words when generating or understanding the current word.

[0140] Subsequently, the corresponding Softmax weight coefficients are applied to the V vectors of each word, and the vectors are summed to obtain a weighted semantic representation for each input position. Through this weighting mechanism, the model can enhance its response to semantically relevant words while suppressing noise words irrelevant to the current context, thereby effectively improving encoding accuracy and context modeling capabilities.

[0141] Finally, the weighted V vector output is the contextual feature encoding result of the self-attention layer for the input sequence. Through multiple stacked layers, the model can progressively capture higher-level semantic dependencies and global structural information.

[0142] The encoder structure of the Transformer model is as follows: Figure 3 As shown, it includes an input embedding layer, a self-attention layer, a feedforward network layer, a residual connection module, and a layer normalization module. These parts are connected sequentially to form a hierarchical feature extraction and semantic expression mechanism.

[0143] The internal structure and training method of the LoRA series of fine-tuned models are limited as follows: The LoRA method introduces two low-rank matrices A and B into several linear transformation layers of the pre-trained model, keeping the original weight matrix W frozen, and only training matrices A and B, so that ΔW = A × B serves as a compensation update for the weight matrix W. Among them, the QLoRA method, based on the LoRA adapter, stores the weights of the pre-trained model in 4-bit quantization format, performs dequantization and gradient propagation operations during backpropagation, and only updates the LoRA matrix, so as to achieve performance similar to 16-bit full-precision fine-tuning while significantly reducing memory usage. Among them, the AdaLoRA method introduces a dynamic rank allocation strategy based on the LoRA structure. During the training process, it adaptively allocates the rank r of the low-rank matrix to different layers or modules according to the model level and task feedback, so as to improve the adaptability of different levels and the convergence effect of the model.

[0144] The fine-tuning principle of the LoRA series, such as Figure 4 As shown.

[0145] By adopting the LoRA series fine-tuning strategies described above, this invention significantly reduces the consumption of computing resources and GPU memory usage during training without compromising model performance. At the same time, it improves the domain adaptability and deployment efficiency of the model in the task of requirements analysis of integrated modular avionics systems, and realizes efficient training and rapid application of large language models in the engineering scenario of avionics systems.

[0146] Step 6: Model Validation and Tool Packaging. The trained requirements analysis model is validated using a test dataset. Multi-dimensional evaluation metrics such as BLEU-4, ROUGE-L, BERTScore, and GPTScore are employed to quantitatively and qualitatively assess the model's analytical performance in different task scenarios. This verifies the model's accuracy and generalization ability in analyzing architectural, resource, communication, and program requirements. After verifying that the model's performance meets preset standards, it is packaged into a deployable analysis tool to enable its application in academic research, requirements modeling, and industrial engineering development of avionics systems.

[0147] The evaluation metrics include BLEU-4, ROUGE-L, BERTScore, and GPTScore, which are used to comprehensively evaluate the text generation quality and demand analysis performance of the trained model. The definitions, calculation formulas, and parameters of each metric are as follows: (1) BLEU-4 index: BLEU-4 (Bilingual Evaluation Understudy) measures the degree of matching between model-generated text and reference text at the 4-gram level, to evaluate the lexical accuracy and grammatical coherence of the generated sentences. Its calculation formula is as follows:

[0148] in, This indicates the exact match rate between the generated text and the reference text at the n-gram level. This represents the weighting coefficient, which is usually taken as... BP stands for Brevity Penalty, defined as:

[0149] Where c represents the length of the generated text and r represents the length of the reference text. The value of this indicator ranges from [0,1], and the larger the value, the higher the matching degree between the generated text and the reference text.

[0150] (2) ROUGE-L index: The ROUGE-L (Recall-Oriented Understudy for Gisting Evaluation) metric, based on the Longest Common Subsequence (LCS) algorithm, measures the similarity between generated and reference text in syntactic structure and overall expression. Its calculation formula is as follows:

[0151] in:

[0152] LCS(X,Y) represents the length of the longest common subsequence between the generated text X and the reference text Y; This is a balancing parameter, typically set to 1.2.

[0153] A higher ROUGE-L value indicates better consistency between the generated text and the reference text in terms of syntactic organization and semantic coverage.

[0154] (3) BERTScore metric: BERTScore utilizes the contextual semantic embeddings of a pre-trained BERT model to calculate semantic similarity between generated and reference text, thereby evaluating semantic consistency. The calculation formula is as follows:

[0155] in: The semantic precision based on cosine similarity is calculated as follows:

[0156] The semantic recall rate based on cosine similarity is calculated as follows:

[0157] in, This represents the context vector representation extracted by the BERT model. This represents the cosine similarity function. The BERTS score ranges from [0,1], and a higher score indicates a higher semantic similarity between the model-generated text and the reference text.

[0158] (4) GPTScore is a probabilistic scoring mechanism based on a large language model. It measures the high-level generation and reasoning ability of the model by comprehensively analyzing the language fluency, semantic consistency, and logical rationality of the generated text. Its calculation formula is as follows:

[0159] Where: x represents the input text. This represents the i-th word in the generated text; Represents model parameters Given context and input conditions, generate words. The conditional probability; N This represents the total number of words in the generated text. A higher GPTScore indicates better fluency and semantic consistency in the generated text.

[0160] By comprehensively calculating BLEU-4, ROUGE-L, BERTScore, and GPTScore, this invention can comprehensively evaluate the requirements analysis model from four aspects: lexical matching, syntactic coverage, semantic consistency, and generation logic, thereby verifying the model's generation quality and domain adaptability in the requirements analysis task of integrated modular avionics systems.

[0161] This invention, through the introduction of efficient parameter fine-tuning technology, achieves efficient and accurate system requirement analysis by combining professional requirement corpora in the field of avionics while maintaining the semantic understanding ability of the pre-trained language model, thereby improving the practicality and interpretability of the model in the field of safety-critical systems.

Claims

1. A method for integrated avionics system requirement analysis based on large model LoRA fine-tuning, characterized in that: The method comprises the following steps: Collecting requirement content, dividing the requirement content, and obtaining different types of requirement text; Designing corresponding requirement templates based on the semantic structure and expression characteristics of each type of requirement text; Building a modular requirement analysis dataset based on the requirement templates; Fine-tuning a large language model using the modular requirement analysis dataset to obtain a requirement analysis model; Implementing the requirement analysis of the avionics system based on the requirement analysis model.

2. The method of claim 1, wherein the method is based on large model LoRA fine-tuning for integrated avionics system requirement analysis. The requirement text includes process requirement text, performance requirement text, design constraint text, architecture requirement text, resource requirement text, mode requirement text, communication requirement text, and program requirement text.

3. The method of claim 1, wherein the method is based on large model LoRA fine-tuning for integrated avionics system requirement analysis. The requirement template defines the input and output fields in the form of parameter placeholders.

4. The method of claim 2, wherein the method is based on large model LoRA fine-tuning for integrated avionics system requirement analysis. The requirement analysis model includes an architecture analysis model, a resource analysis model, a mode analysis model, a communication analysis model, and a program analysis model.

5. The method of claim 4, wherein the method is based on large model LoRA fine-tuning for integrated avionics system requirement analysis. The architecture analysis model is based on the process requirement text to generate the architecture requirement of the avionics system, which describes the overall structure and the organization relationship between functional modules. The resource analysis model combines the process requirement text and the architecture requirement text to analyze and deduce the resource configuration of the avionics system, and determines the resource requirements of each module, partition, and task. The mode analysis model generates mode requirement text based on the process requirement text, which describes the mode switching mechanism and interface connection relationship of the avionics system in different operating stages. The communication analysis model generates communication requirement text based on the process requirement text to clarify the data interaction path, communication method, and port mapping relationship within the avionics system and between modules. The program analysis model deduces program requirement text based on the process requirement text to determine the calling relationship, parameter interaction method, and execution order of various programs in the avionics system.

6. The method of claim 5, wherein the method is based on large model LoRA fine-tuning for integrated avionics system requirement analysis. The modular requirement analysis dataset is constructed based on the requirement templates, which specifically includes: According to the requirement analysis task, the modular requirement analysis dataset includes an architecture analysis data subset, a resource analysis data subset, a mode analysis data subset of modules and devices, a mode analysis data subset of partitions and network interfaces, an inter-partition communication analysis data subset, an intra-partition communication analysis data subset, and a program analysis data subset; According to the core functional characteristics and task division of the avionics system, the avionics system is systematically divided into multiple categories; Each data subset includes data of the multiple categories; Each data sample is organized in a unified format, specifically as follows: {"instruction”: "task_type”, "input”: "input_requirement”, "output”:"output_requirement”} Where: "instruction” represents the requirement analysis task type; "input” represents the input requirement corresponding to the specific requirement analysis task type; "output” represents the output requirement corresponding to the requirement analysis task type.

7. The method according to claim 6, wherein: The large language model adopts a Transformer architecture and is composed of an encoder and a decoder; the encoder is responsible for information representation and context modeling of an input sequence, and the decoder is responsible for generating target output text according to context semantics; The encoder is composed of a plurality of stacked self-attention layers and a feedforward network, wherein the self-attention layer is used to calculate the global dependency between words in the input sequence, and the context-related representation of the input sequence is obtained through a Scaled Dot-Product Attention mechanism; the feedforward network performs nonlinear transformation and feature extraction on the hidden state of each position.

8. The method according to claim 7, wherein: The large language model is fine-tuned, including: using a LoRA method, a QLoRA method or an AdaLoRA method to fine-tune the large language model; The LoRA method introduces two low-rank matrices A and B in a plurality of linear transformation layers of the large language model, so that the original weight matrix W is kept frozen, and only the matrices A and B are trained, so that AW =B is used as a compensation update for the weight matrix W; The QLoRA method stores the weight of the large language model in a 4-bit quantization format on the basis of importing a LoRA adapter, performs dequantization and gradient propagation operations in the back propagation process, and only updates the LoRA matrix; The AdaLoRA method introduces a dynamic rank allocation strategy based on the LoRA structure, and adaptively allocates the rank r of the low-rank matrix to different layers or modules according to the model level and task feedback during the training process.

Images