An airborne software airworthiness component feature construction method

Abstract

The application provides an airborne software airworthiness component feature construction method, and relates to the technical field of data processing. The method comprises the following steps: obtaining basic information of each component on the airborne software; obtaining airworthiness feature values of each component based on the basic information of each component; integrating the airworthiness feature values and the basic information based on a preset airworthiness component feature paradigm template to generate a component feature architecture of the component; performing content integrity calculation on the component feature architecture to generate integrity information; supplementing the integrity information to the component feature architecture to obtain a target component feature architecture; and storing the target component feature architecture in a component feature library of the airborne software. The method provided by the application can describe and manage components of different source types under the same paradigm template, thereby providing a unified and reliable data basis for subsequent component retrieval, airworthiness state query and correlation analysis between components.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a method for constructing airworthiness component features for airborne software. Background Technology

[0002] With the development of the aviation industry, airborne software is increasingly widely used in core components such as flight control systems and navigation systems, and its safety and reliability are directly related to flight safety. To ensure the quality of airborne software, the International Civil Aviation Organization (ICAO) and national aviation authorities have formulated strict airworthiness standards, clearly defining the airworthiness requirements for the entire lifecycle of airborne software, from requirements analysis, design, coding, testing to verification.

[0003] In related technologies, airworthiness certification management for airborne software typically employs a document-driven approach. Specifically, developers write corresponding requirement documents, design documents, and test documents for each functional component of the airborne software. They establish traceability relationships between requirements, verification test cases, test results, and other documents using configuration management tools, and manually review each document according to airworthiness standards to determine whether the airborne software meets airworthiness requirements.

[0004] However, the document-driven approach described above suffers from low efficiency and reliability in airworthiness attribute management. Summary of the Invention

[0005] The purpose of this application is to address the shortcomings of the prior art by providing a method for constructing airworthiness component features of airborne software, so as to describe and manage components from different sources under the same paradigm template, providing a unified and reliable data foundation for subsequent component retrieval, airworthiness status query and correlation analysis between components.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, one embodiment of this application provides a method for constructing airworthiness component features of airborne software, the method comprising: Obtain basic information about the various components of the onboard software; The airworthiness characteristic values ​​of each component are obtained based on the basic information of each component; Based on a preset airworthiness component feature paradigm template, the airworthiness feature values ​​are integrated with the basic information to generate the component feature architecture. Perform content integrity calculations on the component feature architecture to generate integrity information; The integrity information is added to the component feature architecture to obtain the target component feature architecture; The target component feature architecture is stored in the component feature library of the airborne software.

[0007] In some embodiments, obtaining the airworthiness characteristic values ​​of each component based on the basic information of each component includes: Based on the component identifier in the basic information, retrieve the data record associated with the component identifier from the product lifecycle data management platform, and read the airworthiness feature value corresponding to the component from the data record.

[0008] In some embodiments, after obtaining the airworthiness characteristic values ​​of each component based on the basic information of each component, the method further includes: Based on the preset airworthiness component feature paradigm template, determine whether there are any missing fields in the airworthiness feature values ​​of the component; If any fields are missing, perform the corresponding field completion operation.

[0009] In some embodiments, before performing the padding operation for the corresponding field, the method further includes: Determine whether there are data packet links among the airworthiness characteristics; If it exists, the airworthiness feature value of the corresponding field is parsed and extracted from the data packet pointed to by the data packet link; If the data packet link does not exist or a valid airworthiness feature value is not extracted from the data packet, the component is analyzed, and the external interface list, compilation environment, running platform and data structure definition of the component are extracted from the analysis results. Based on the external interface list, compilation environment, running platform and data structure definition, the airworthiness feature value of the corresponding field is determined. If no valid airworthiness feature value is obtained from the analysis results, the missing airworthiness feature field will be marked as pending confirmation to indicate the input of the corresponding airworthiness feature value.

[0010] In some embodiments, performing content integrity calculations on the component feature architecture to generate integrity information includes: Perform a binary hash calculation on the component content of the component to obtain the component content hash value; The component feature architecture is signed to generate feature architecture signature information; The preset airworthiness component feature paradigm template is signed to generate template signature information; Obtain the chain fingerprint of the historical versions of the component feature architecture, bind the hash value of the component content of the current version and the feature architecture signature information with the chain fingerprint of the historical versions to generate the chain fingerprint of the current version; The integrity information is generated based on the component content hash value, the feature architecture signature information, the template signature information, and the chain fingerprint of the current version.

[0011] In some embodiments, storing the target component feature architecture in the component feature library of the airborne software includes: The target component feature architecture is subjected to compliance verification to obtain compliance verification information; When the compliance verification information indicates that the verification has passed, the target component feature architecture is stored in the component feature library of the airborne software.

[0012] In some embodiments, the compliance verification of the target component feature architecture to obtain compliance verification information includes: Based on the security level of the component, verify whether the coverage rate recorded in the MC / DC coverage status field of the correction condition determination in the feature architecture of the target component reaches the preset threshold corresponding to the security level, and obtain the first verification result; Verify whether each traceability identifier in the full-chain traceability identifier list is complete and can be associated with the source, and obtain the second verification result; Verify the validity of the integrity information to obtain a third verification result; Based on the first verification result, the second verification result, and the third verification result, the compliance verification information is generated and output.

[0013] In some embodiments, the step of verifying whether the coverage rate recorded in the coverage status field of the correction condition determination reaches a preset threshold corresponding to the security level, based on the security level of the component, includes: When the security level is Level 1, verify whether the statement coverage, decision coverage, and MC / DC coverage in the coverage are all at the first preset threshold. When the security level is level 2, verify whether the statement coverage rate and the judgment coverage rate are both the first preset threshold. When the security level is level three, verify whether the statement coverage rate is at the first preset threshold. When the security level is level four or five, verify whether the statement coverage rate is at the second preset threshold.

[0014] In some embodiments, generating and outputting compliance verification information based on the first verification result, the second verification result, and the third verification result includes: Determine whether the security level is consistent with the preset security level classification rule level to obtain the fourth verification result; Based on the first verification result, the second verification result, the third verification result, and the fourth verification result, compliance verification information is generated and output.

[0015] In some embodiments, storing the target component feature architecture in the component feature library of the airborne software includes: An index is created using the security level, change history, and affected domain as index keys and the target component feature architecture as the index object. The target component feature architecture is stored in the component feature library of the airborne software.

[0016] Secondly, another embodiment of this application provides an airworthiness component feature construction apparatus for airborne software, the apparatus comprising: an acquisition module, a generation module, and a storage module, wherein: The acquisition module is used to acquire basic information of each component on the airborne software; and to acquire airworthiness characteristic values ​​of each component based on the basic information of each component. The generation module is used to integrate the airworthiness feature values ​​with the basic information based on a preset airworthiness component feature paradigm template to generate a component feature architecture of the component; perform content integrity calculation on the component feature architecture to generate integrity information; and supplement the integrity information into the component feature architecture to obtain the target component feature architecture. The storage module is used to store the target component feature architecture into the component feature library of the airborne software.

[0017] In some embodiments, the acquisition module is specifically used to retrieve data records associated with the component identifier from the product lifecycle data management platform based on the component identifier in the basic information, and read the airworthiness feature value corresponding to the component from the data records.

[0018] In some embodiments, the apparatus further includes a determining module, configured to determine whether there are missing fields in the airworthiness feature values ​​of the component based on the preset airworthiness component feature paradigm template; and to perform a field completion operation if there are missing fields.

[0019] In some embodiments, the determining module is specifically used to determine whether a data packet link exists in the airworthiness feature value; if it exists, the airworthiness feature value of the corresponding field is parsed and extracted from the data packet pointed to by the data packet link; if the data packet link does not exist or a valid airworthiness feature value is not extracted from the data packet, the component is analyzed, and the external interface list, compilation environment, running platform and data structure definition of the component are extracted from the analysis results, and the airworthiness feature value of the corresponding field is determined based on the external interface list, compilation environment, running platform and data structure definition; if a valid airworthiness feature value is not obtained from the analysis results, the missing airworthiness feature field is marked as pending confirmation to indicate the input of the airworthiness feature value of the corresponding field.

[0020] In some embodiments, the apparatus further includes a computing module for performing binary hash calculation on the component content of the component to obtain a component content hash value; The generation module is specifically used to sign the component feature architecture to generate feature architecture signature information; sign the preset airworthiness component feature paradigm template to generate template signature information; obtain the chain fingerprint of the historical version of the component feature architecture, bind the component content hash value of the current version, the feature architecture signature information, and the chain fingerprint of the historical version to generate the chain fingerprint of the current version; and generate the integrity information based on the component content hash value, the feature architecture signature information, the template signature information, and the chain fingerprint of the current version.

[0021] The storage module is specifically used to perform compliance verification on the target component feature architecture to obtain compliance verification information; when the compliance verification information indicates that the verification is passed, the target component feature architecture is stored in the component feature library of the airborne software.

[0022] In some embodiments, the device further includes a verification module, configured to verify, based on the security level of the component, whether the coverage rate recorded in the MC / DC coverage status field of the modified condition determination in the feature architecture of the target component reaches a preset threshold corresponding to the security level, to obtain a first verification result; verify whether each traceability identifier in the full-link traceability identifier list is complete and can be associated with traceability, to obtain a second verification result; and verify whether the integrity information is valid, to obtain a third verification result. The generation module is specifically used to generate and output the compliance verification information based on the first verification result, the second verification result, and the third verification result.

[0023] In some embodiments, the verification module is configured to verify whether the statement coverage, decision coverage, and MC / DC coverage in the coverage are all at a first preset threshold when the security level is level 1; verify whether the statement coverage and decision coverage are both at the first preset threshold when the security level is level 2; verify whether the statement coverage is at the first preset threshold when the security level is level 3; and verify whether the statement coverage is at the second preset threshold when the security level is level 4 or level 5.

[0024] In some embodiments, the determining module is specifically used to determine whether the security level is consistent with the preset security level classification rule level, and to obtain a fourth verification result; The generation module is specifically used to generate and output compliance verification information based on the first verification result, the second verification result, the third verification result, and the fourth verification result.

[0025] In some embodiments, the storage module is specifically used to create an index using the security level, change history, and impact domain as index keys and the target component feature architecture as the index object; and to store the target component feature architecture in the component feature library of the airborne software.

[0026] Thirdly, another embodiment of this application provides a computer device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the computer device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of any of the methods described in the first aspect above.

[0027] Fourthly, another embodiment of this application provides a storage medium storing a computer program, which, when executed by a processor, performs the steps of any of the methods described in the first aspect above.

[0028] The beneficial effects of this application are as follows: By pre-setting an airworthiness component feature paradigm template, scattered airworthiness feature values ​​are organized into a component feature architecture with a unified format and standardized fields. Components from different sources can be described and managed under the same paradigm template. By performing content integrity calculations on the component feature architecture and supplementing the generated integrity information into the architecture, the component feature architecture has a verifiable integrity protection mechanism. Any subsequent modifications to the component content or feature data can be identified through the integrity information. In addition, by storing the target component feature architecture in the component feature library, the airworthiness feature data of each component can be centrally stored and managed, providing a unified and reliable data foundation for subsequent component retrieval, airworthiness status query, and correlation analysis between components. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A flowchart illustrating a method for constructing airworthiness component features of airborne software according to an embodiment of this application is shown. Figure 2 A schematic diagram of a field completion process provided in another embodiment of this application is shown; Figure 3 A flowchart illustrating the feature architecture of a storage target component provided in an embodiment of this application is shown; Figure 4 A schematic diagram of a feature storage process according to an embodiment of this application is shown; Figure 5 A flowchart illustrating a method for constructing airworthiness component features of airborne software according to another embodiment of this application is shown. Figure 6 This illustration shows a structural schematic diagram of an airworthiness component feature construction device for airborne software according to an embodiment of this application; Figure 7 This illustration shows a structural schematic diagram of an airworthiness component feature construction apparatus for airborne software according to another embodiment of this application; Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0032] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0033] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0034] Figure 1 This illustration shows a flowchart of a method for constructing airworthiness component features of airborne software according to an embodiment of this application. Figure 1As shown, the method includes steps 110-160, wherein: Step 110: Obtain basic information about each component on the airborne software.

[0035] Airborne software is embedded software that runs on aircraft and other aircraft, including core functional software such as flight control systems, navigation systems, and communication systems.

[0036] Components are independent modules of airborne software divided according to their functions, such as the attitude calculation module in a flight control system, the satellite signal processing module in a navigation system, and the data link protocol module in a communication system. Each component has clearly defined functional boundaries and interface definitions.

[0037] Basic information is metadata used to describe the basic attributes of a component, including but not limited to: component unique identifier (ID), component name, functional description, component type (source code component or object code component), version number, compilation environment, runtime platform, component dependency list (other components that the component depends on and their versions), external interface list (input parameters, output parameters and interface protocol definitions), component input definition (dependent shared libraries or static libraries), component output definition (executable file, shared library or static library generated after compilation), component feature configuration (compilation options, macro definition switches, etc.), etc.

[0038] In some embodiments, basic information can be obtained automatically through a feature adaptation interface or manually entered.

[0039] As an example, for source code components (self-developed source code components), after developers complete the component coding, they submit the basic information of the component through an integrated development environment or project management tool. The system automatically parses the compilation configuration file in the code repository, extracts the compilation environment and dependency information, and uses static code analysis tools to scan header files and interface definition files to automatically extract the list of external interfaces.

[0040] For target code components (third-party target code components), developers fill in the relevant information from the component specification document provided by the supplier through the system's input interface, or complete the basic information input in batches by importing standardized interface description files (such as component lists in XML or JSON format). The above basic information is stored in the system's database, providing a data foundation for the subsequent acquisition of airworthiness feature values.

[0041] Step 120: Obtain the airworthiness characteristic values ​​of each component based on the basic information of each component.

[0042] Airworthiness feature values ​​are key attribute data required for the airworthiness certification process of components, and serve as the basis for determining whether a component meets airworthiness standards. The data collection path for obtaining airworthiness feature values ​​can be determined based on the component type.

[0043] As an example, when the component is a source code component, the unique identifier of each component in its basic information can be used as the search keyword to retrieve all work item data associated with each component from the Product Lifecycle Data Management (PLM) platform, and the corresponding airworthiness feature values ​​can be read from the work item data. This method allows the unique identifier information of components and airworthiness feature information, which were originally stored independently in different systems, to be uniformly queried and aggregated based on the unique identifier of the component.

[0044] When the component is a target code component, the corresponding airworthiness feature field can be determined from the basic information of the target code component by keyword matching, and the corresponding airworthiness feature value can be read from the airworthiness feature field.

[0045] In the embodiments of this application, airworthiness characteristics include, but are not limited to: Development Assurance Level (DAL) safety level: A / B / C / D / E; Coupling constraint identifier (present / absent); Coupling type (applicable only when there is a coupling constraint): data sharing coupling, input / output (I / O) sharing coupling, component interface coupling; MC / DC coverage status: number of covered items, coverage rate, uncovered items, verification result (pass / fail); Full-link traceability identifier ID list: requirement ID, design model ID, code ID, verification test case ID, verification procedure ID, verification report ID; Problem report (PR) ID; Field loadable identifier (yes / no); Commercial-Off-The-Shelf (COTS) identifier (yes / no); Reuse identifier (yes / no); User-modifiable identifier (yes / no); Parameter Data Item (PDI) identifier (yes / no); Verification status: unverified, failed, passed; Airworthiness status: random certification, China Civil Aviation Technical Standard Order Authorization. (CTSOA), uncertified; Issuing authority (applicable only when airworthiness is valid): Civil Aviation Administration of China (CAAC), Federal Aviation Administration (FAA), European Union Aviation Safety Agency (EASA); Issuance date (applicable only when airworthiness is valid); Issuance validity period (applicable only when airworthiness is valid), etc.

[0046] The DAL safety level can include, for example, five levels: A / B / C / D / E, used to determine the impact on flight safety after component failure. Coupling constraint identifiers and coupling types can include, for example, data sharing coupling, input / output (I / O) sharing coupling, component interface coupling, etc., used to describe the degree of dependency between components. Modified Condition / Decision Coverage (MC / DC) coverage status can include statement coverage, decision coverage, specific values ​​of MC / DC coverage, a list of uncovered items, and verification results. The end-to-end traceability identifier list can include requirement identifiers (ID), design model IDs, code IDs, verification test case IDs, verification procedure IDs, and verification report IDs, forming a complete traceability chain from requirement to verification. Verification status can include: unverified, failed, and passed. Airworthiness status can include random certification, China Technical Standard Order Authorization (CTSOA), and uncertified.

[0047] Step 130: Based on the preset airworthiness component feature paradigm template, integrate the airworthiness feature values ​​with the basic information to generate the component feature architecture.

[0048] The above method, which organizes scattered airworthiness feature values ​​into a standardized component feature architecture by pre-setting an airworthiness component feature paradigm template, solves the problems of broken traceability between documents and code and mismatch between document descriptions and actual software behavior in related technologies.

[0049] Among them, the preset airworthiness component feature paradigm template is a preset template corresponding to the preset airworthiness certification standard. The preset airworthiness certification standard can be the airborne software airworthiness certification standard (DO). 178C), Airborne Complex Electronic Hardware Airworthiness Standard (DO) 254), Part 21 of the Civil Aviation Regulations of China (CCAR) 21). In the following embodiments, all are consistent with the preset airworthiness certification standard DO. Let's take 178C as an example for explanation.

[0050] The pre-defined airworthiness component feature paradigm template is a predefined data structure template designed for airborne software airworthiness certification requirements. Based on airworthiness standards, it is a standardized feature description framework for airborne software components, specifying which fields should be included in the component feature data, the data type of each field, its value range, required / optional attributes, and the logical relationships between fields. The purpose of this template is to transform previously fragmented and unstandardized airworthiness attributes into machine-readable, searchable, and verifiable paradigmatic data.

[0051] In the embodiments of this application, according to DO The preset template corresponding to 178C integrates airworthiness feature values ​​and basic information, converting them into a standardized feature set in a unified format.

[0052] Step 140: Perform content integrity calculation on the component feature architecture to generate integrity information.

[0053] Content integrity calculation refers to performing cryptographic operations on the component entity content corresponding to the component feature architecture to generate integrity verification data that can uniquely identify the content state of the component.

[0054] As an example, content integrity calculation is a hash operation performed on the actual entity content (i.e., source code file or object code file) of the component at runtime.

[0055] In an embodiment of this application, step 140 may include: performing binary hash calculation on the component content of the component to obtain a component content hash value; signing the component feature architecture to generate feature architecture signature information; signing the preset airworthiness component feature paradigm template to generate template signature information; obtaining the chain fingerprint of historical versions of the component feature architecture, binding the current version's component content hash value and feature architecture signature information with the chain fingerprint of historical versions to generate the current version's chain fingerprint; and generating integrity information based on the component content hash value, feature architecture signature information, template signature information, and the current version's chain fingerprint.

[0056] Perform binary hash calculation on the component content corresponding to the component. When the component is a source code component, the component content is the binary object file or the final executable image file generated by compiling the source code file (e.g., .c / .h / .cpp, etc.); when the component is an object code component, the component content is a library file (e.g., .a / .so / .lib, etc.) or an executable file delivered by a third party.

[0057] As an example, hash algorithms such as SHA-256 can be used to perform hash calculations on the component content to generate a fixed-length hash value. The hash value can uniquely identify the state of the component content, and any modification to the component content will cause the hash value to change.

[0058] MD5 / CRC32 can be used to sign the component feature architecture to generate feature architecture information; correspondingly, MD5 / CRC32 can be used to sign the preset airworthiness component feature paradigm template to generate template signature information, thereby completing the encryption of tamper-proof data.

[0059] Integrity information is a set of cryptographic data generated by content integrity calculations, including the binary hash value of the component content, the signature information of the component feature architecture, the template signature information, and the chain fingerprint associated with historical versions.

[0060] Chain fingerprinting is a data structure that cryptographically binds the integrity information of the current version to that of the previous version. The integrity information of each version contains the fingerprint of the previous version, thus realizing the construction of a chain fingerprint of evidence throughout the entire lifecycle.

[0061] In other words, this application establishes a tamper-proof evidence chain for the entire lifecycle of component feature architecture through content integrity calculation and chain fingerprint binding. Tampering in any historical version can be detected, avoiding the risk of the traceability link being broken.

[0062] Step 150: Add the integrity information to the component feature architecture to obtain the target component feature architecture.

[0063] Based on the component feature architecture, integrity information is added to the integrity dimension fields of the component feature architecture to obtain the complete target component feature architecture.

[0064] In some embodiments, when the component is a target code component, target code extension information can be added to the target component feature architecture, including but not limited to: the source of the target code component, the link of the third-party verified data packet, the original fingerprint data, etc.

[0065] In other words, in the embodiments of this application, the target component feature architecture may include features in four dimensions: basic information, airworthiness feature value, integrity information, and target code extension information.

[0066] Step 160: Store the target component feature architecture in the component feature library of the airborne software.

[0067] A component signature repository is a database or storage warehouse used to store and manage the signature architecture of various components of airborne software. It is a dedicated component management repository with indexing, retrieval, verification, and traceability capabilities.

[0068] An index is a retrieval mapping relationship established when the target feature architecture is stored in the component feature library. It includes hierarchical indexes with DAL security level as the index key, source indexes with change history as the index key, and association indexes with the domain of influence as the index key.

[0069] The airworthiness component feature construction method for airborne software provided in this application organizes scattered airworthiness feature values ​​into a component feature architecture with a unified format and standardized fields by pre-setting an airworthiness component feature paradigm template. Components from different sources can be described and managed under the same paradigm template. By performing content integrity calculation on the component feature architecture and supplementing the generated integrity information into the architecture, the component feature architecture has a verifiable integrity protection mechanism. Any subsequent modification to the component content or feature data can be identified through the integrity information. In addition, by storing the target component feature architecture in the component feature library, the airworthiness feature data of each component can be centrally stored and managed, providing a unified and reliable data foundation for subsequent component retrieval, airworthiness status query, and correlation analysis between components.

[0070] Figure 2 This illustration shows a flowchart of a field completion process according to another embodiment of this application, such as... Figure 2 As shown, after step 120, the method may further include steps 121-122: Step 121: Based on the preset airworthiness component feature paradigm template, determine whether there are any missing fields in the airworthiness feature values ​​of the component.

[0071] When obtaining airworthiness feature values, there may be some airworthiness feature values ​​that are not successfully obtained. Therefore, in order to ensure the availability of subsequent data, it is necessary to determine whether there are any fields that are not obtained based on the preset airworthiness component feature paradigm template.

[0072] Step 122: For fields that are missing, perform the corresponding field completion operation.

[0073] Before performing the field completion operation, it is necessary to obtain the airworthiness feature value corresponding to the missing field, and then perform the field completion operation based on the airworthiness feature value of the missing field.

[0074] In the embodiments of this application, airworthiness feature values ​​can be obtained through a hierarchical acquisition method.

[0075] As an example, first determine whether there is a data packet link in the airworthiness feature value; if so, parse and extract the airworthiness feature value of the corresponding field from the data packet pointed to by the data packet link.

[0076] If no data packet link exists, or if no valid airworthiness feature value is extracted from the data packet, the component is analyzed, and the component's external interface list, compilation environment, runtime platform, and data structure definition are extracted from the analysis results; the airworthiness feature value of the corresponding field is determined based on the external interface list, compilation environment, runtime platform, and data structure definition.

[0077] If no valid airworthiness feature value is obtained from the analysis results, the missing airworthiness feature field will be marked as pending confirmation to indicate the input of the corresponding airworthiness feature value.

[0078] Figure 3 A flowchart illustrating the characteristic architecture of a storage target component provided in an embodiment of this application is shown, as follows: Figure 3 As shown, step 160 may further include steps 161-162, wherein: Step 161: Perform compliance verification on the target component feature architecture to obtain compliance verification information.

[0079] In the embodiments of this application, compliance verification can be performed using a hierarchical verification method, such as calling the DAL hierarchical rule base of DO-178C to automatically verify the feature architecture of the target component, verifying the integrity of fields, the coverage of hierarchical levels, and the integrity of the traceability chain, etc.

[0080] Specifically, step 161 may include: verifying whether the coverage rate recorded in the MC / DC coverage status field of the target component feature architecture reaches the preset threshold corresponding to the security level, based on the security level of the component, to obtain a first verification result; verifying whether each traceability identifier in the full-link traceability identifier list is complete and can be traced back to its source, to obtain a second verification result; verifying whether the integrity information is valid, to obtain a third verification result; and generating and outputting compliance verification information based on the first verification result, the second verification result, and the third verification result.

[0081] In the embodiments of this application, when the security level is level 1, it is determined whether the statement coverage, decision coverage, and MC / DC coverage in the verification coverage are all at a first preset threshold; when the security level is level 2, it is determined whether the statement coverage and decision coverage are both at the first preset threshold; when the security level is level 3, it is determined whether the statement coverage is at the first preset threshold; and when the security level is level 4 or level 5, it is determined whether the statement coverage is at a second preset threshold.

[0082] For example, at security level A, verify whether the statement coverage, decision coverage, and MC / DC coverage in the verification coverage are all 100%; at security level B, verify whether the statement coverage and decision coverage are both 100%; at security level C, verify whether the statement coverage is 100%; and at security levels D or E, verify whether the statement coverage is greater than or equal to 90%. When verifying the coverage recorded in the MC / DC coverage status field, it is also necessary to verify the uncovered entries and verification results simultaneously.

[0083] When coverage is not up to standard, there are uncovered entries, and / or compliance verification results indicate failure, the verification of the MC / DC coverage status field is triggered.

[0084] Step 162: When the compliance verification information indicates that the verification has passed, store the target component feature architecture into the component feature library of the airborne software.

[0085] If the compliance verification information fails, a verification failure indication is returned so that the user can adjust the target component feature architecture according to the verification failure indication until the adjusted target component feature architecture passes the compliance verification. After that, the target feature component that passes the compliance verification is stored in the component feature library of the airborne software.

[0086] In the embodiments of this application, when compliance verification fails, risk warnings and risk markers can be issued for the failed content, along with suggestions on how to modify it. These risk warnings, risk markers, and modification suggestions can be compiled into a compliance testing report and fed back to the user, enabling the user to adjust the target component feature architecture based on the compliance testing report.

[0087] When adjusting the feature architecture of a target component involves changes to component data, the system can automatically analyze the impact of the current change on other upstream and downstream components based on the component's upstream and downstream relationships, and provide incremental authentication criteria and define the scope of incremental authentication. These incremental authentication criteria and scope can be added to the compliance testing report and returned to the user.

[0088] After the compliance test report is generated, it needs to be bound to the corresponding target component feature architecture and archived as evidence for subsequent audits.

[0089] In some embodiments, based on verifying the integrity of the fields, the coverage of the classification, and the integrity of the traceability chain, it can also be determined whether the security level is consistent with the preset security level classification rule level, thus obtaining a fourth verification result; based on the first verification result, the second verification result, the third verification result, and the fourth verification result, compliance verification information is generated and output.

[0090] Based on this, compliance verification rules can also include multiple verification rules. Table 1 below is used as an example for illustration. Table 1 shows some possible verification rules and specific verification methods. Each rule is identified by its number, the rule description is used to describe each rule, the verification logic is the verification logic in the specific verification process of each rule, the triggering condition is the constraint condition that triggers each rule, and the modification prompt is the way to modify the failed content when the verification fails.

[0091] Table 1:

[0092] Figure 4 This illustration shows a flowchart of a feature storage method according to an embodiment of this application, as shown below. Figure 4 As shown, step 160 may include: steps 163-164, wherein: Step 163: Create an index using security level, change history, and affected domain as index keys and target component feature architecture as index objects.

[0093] Step 164: Store the target component feature architecture in the component feature library of the airborne software.

[0094] Figure 5 This illustration shows a flowchart of a method for constructing airworthiness component features of airborne software according to another embodiment of this application, as shown below. Figure 5 As shown, the method includes: During the data preparation phase, the product lifecycle data management platform pre-stores the associated work item data of each component of the airborne software. The associated work item data includes at least requirement work items, design model work items, code work items, verification test case work items, verification program work items, and verification report work items. Each work item records the airworthiness certification attributes of the corresponding component.

[0095] Subsequently, basic information collection is carried out: basic information of each component on the airborne software is obtained, including the component's unique identifier, component name, functional description, component type, version number, compilation environment, running platform, component dependency list, external interface list, component input definition, component output definition, and component feature configuration.

[0096] During the airworthiness feature extraction and configuration phase, based on the acquired basic information of each component, and using the component identifier in the basic information as the search keyword, data records associated with the component identifier are retrieved from the related work item data of the product lifecycle data management platform. The corresponding airworthiness feature values ​​for each component are then read from these data records. Airworthiness feature values ​​include DAL safety level, coupling constraint identifier and coupling type, MC / DC coverage status, end-to-end traceability identifier list, verification status, and airworthiness status. If any airworthiness feature values ​​are missing, an airworthiness feature value completion operation is performed.

[0097] After obtaining the airworthiness feature values, the component feature architecture is automatically generated based on the airworthiness feature values ​​and the basic information of each component.

[0098] Specifically, based on a preset airworthiness component feature paradigm template, airworthiness feature values ​​are integrated with basic information of the steps to automatically generate a standardized component feature architecture. The standardized component feature architecture includes at least a basic information dimension and an airworthiness feature dimension.

[0099] Integrity calculation is performed on the component feature architecture, including binary hash calculation of the component content, signing of the component feature architecture, and binding the hash value and signature information of the current version with the chain fingerprint of the historical version to generate integrity information. The integrity information is then added to the component feature architecture to obtain the target component feature architecture.

[0100] The target component feature architecture undergoes compliance verification. The specific methods for compliance verification will not be detailed here. Upon successful verification, verification pass information is generated, and the verified target component feature architecture is stored in the component feature library. An index is created using security level, change history, and impact domain as index keys, and the target feature architecture as the index object, thus completing the storage of the component feature set.

[0101] Based on the same inventive concept, this application also provides an airworthiness component feature construction device for airborne software, which corresponds to the airworthiness component feature construction method for airborne software. Since the principle of the device in this application is similar to the airworthiness component feature construction method for airborne software described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0102] Figure 6 This illustration shows a structural schematic diagram of an airworthiness component feature construction device for airborne software according to an embodiment of this application, as shown below. Figure 6 As shown, the device includes: an acquisition module 210, a generation module 220, and a storage module 230, wherein: The acquisition module 210 is used to acquire basic information of each component on the airborne software; and to acquire the airworthiness characteristic values ​​of each component based on the basic information of each component. The generation module 220 is used to integrate airworthiness feature values ​​and basic information based on a preset airworthiness component feature paradigm template to generate a component feature architecture; perform content integrity calculation on the component feature architecture to generate integrity information; and supplement the integrity information into the component feature architecture to obtain the target component feature architecture. Storage module 230 is used to store the target component feature architecture into the component feature library of the airborne software.

[0103] In some embodiments, the acquisition module 210 is specifically used to retrieve data records associated with the component identifier from the product lifecycle data management platform based on the component identifier in the basic information, and read the airworthiness feature value corresponding to the component from the data record.

[0104] Figure 7 This illustration shows a structural schematic diagram of an airworthiness component feature construction apparatus for airborne software according to another embodiment of this application, as shown below. Figure 7 As shown, the device also includes a determination module 240, which is used to determine whether there are missing fields in the airworthiness feature values ​​of the component according to the preset airworthiness component feature paradigm template; if there are missing fields, the corresponding field completion operation is performed.

[0105] In some embodiments, the determining module 240 is specifically used to determine whether there is a data packet link in the airworthiness feature values; if there is, the airworthiness feature value of the corresponding field is parsed and extracted from the data packet pointed to by the data packet link; if there is no data packet link or no valid airworthiness feature value is extracted from the data packet, the component is analyzed, and the external interface list, compilation environment, running platform and data structure definition of the component are extracted from the analysis results, and the airworthiness feature value of the corresponding field is determined based on the external interface list, compilation environment, running platform and data structure definition; if no valid airworthiness feature value is obtained from the analysis results, the missing airworthiness feature field is marked as pending confirmation to indicate the input of the airworthiness feature value of the corresponding field.

[0106] like Figure 7 As shown, the device also includes a computing module 250, which performs binary hash calculation on the component content of the component to obtain the component content hash value; The generation module 220 is specifically used to sign the component feature architecture and generate feature architecture signature information; sign the preset airworthiness component feature paradigm template and generate template signature information; obtain the chain fingerprint of the historical version of the component feature architecture, bind the current version of the component content hash value and feature architecture signature information with the chain fingerprint of the historical version to generate the chain fingerprint of the current version; and generate integrity information based on the component content hash value, feature architecture signature information, template signature information and the chain fingerprint of the current version.

[0107] The storage module 230 is specifically used to perform compliance verification on the target component feature architecture to obtain compliance verification information; when the compliance verification information indicates that the verification is passed, the target component feature architecture is stored in the component feature library of the airborne software.

[0108] like Figure 7 As shown, the device also includes a verification module 260, which is used to verify whether the coverage rate recorded in the MC / DC coverage status field of the target component feature architecture reaches the preset threshold corresponding to the security level, based on the security level of the component, to obtain a first verification result; verify whether each traceability identifier in the full-link traceability identifier list is complete and can be associated with traceability, to obtain a second verification result; and verify whether the integrity information is valid, to obtain a third verification result. The generation module 220 is specifically used to generate and output compliance verification information based on the first verification result, the second verification result, and the third verification result.

[0109] In some embodiments, the verification module 260 is configured to verify whether the statement coverage, decision coverage, and MC / DC coverage in the coverage are all at a first preset threshold when the security level is level 1; verify whether the statement coverage and decision coverage are both at the first preset threshold when the security level is level 2; verify whether the statement coverage is at the first preset threshold when the security level is level 3; and verify whether the statement coverage is at the second preset threshold when the security level is level 4 or level 5.

[0110] In some embodiments, the determining module 240 is specifically used to determine whether the security level is consistent with the preset security level classification rule level, and to obtain the fourth verification result; The generation module 220 is specifically used to generate and output compliance verification information based on the first verification result, the second verification result, the third verification result, and the fourth verification result.

[0111] In some embodiments, the storage module 230 is specifically used to create an index using security level, change history, and affected domain as index keys and target component feature architecture as index object; and to store the target component feature architecture in the component feature library of the airborne software.

[0112] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0113] This application also provides a computer device. Figure 8 This application provides a schematic diagram of the structure of a computer device, as shown in the embodiment of the present application. Figure 8As shown, the system includes: a processor 61, a memory 62, and optionally, a bus 63. The memory 62 stores machine-readable instructions executable by the processor 61. When the computer device is running, the processor 61 communicates with the memory 62 via the bus 63. When the machine-readable instructions are executed by the processor 61, the aforementioned... Figures 1-5 The steps of constructing airworthiness component features for any airborne software.

[0114] This application also provides a computer-readable storage medium storing a computer program, which is executed by a processor. Figures 1-5 The steps of constructing airworthiness component features for any airborne software.

[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

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

[0117] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for constructing airworthiness component features of airborne software, characterized in that, The method includes: Obtain basic information about the various components of the onboard software; The airworthiness characteristic values ​​of each component are obtained based on the basic information of each component; Based on a preset airworthiness component feature paradigm template, the airworthiness feature values ​​are integrated with the basic information to generate the component feature architecture. Perform content integrity calculations on the component feature architecture to generate integrity information; The integrity information is added to the component feature architecture to obtain the target component feature architecture; The target component feature architecture is stored in the component feature library of the airborne software.

2. The method according to claim 1, characterized in that, The process of obtaining the airworthiness characteristic values ​​of each component based on the basic information of each component includes: Based on the component identifier in the basic information, retrieve the data record associated with the component identifier from the product lifecycle data management platform, and read the airworthiness feature value corresponding to the component from the data record.

3. The method according to claim 2, characterized in that, After obtaining the airworthiness characteristic values ​​of each component based on the basic information of each component, the method further includes: Based on the preset airworthiness component feature paradigm template, determine whether there are any missing fields in the airworthiness feature values ​​of the component; If any fields are missing, perform the corresponding field completion operation.

4. The method according to claim 3, characterized in that, Before performing the field completion operation, the method further includes: Determine whether there are data packet links among the airworthiness characteristics; If it exists, the airworthiness feature value of the corresponding field is parsed and extracted from the data packet pointed to by the data packet link; If the data packet link does not exist or a valid airworthiness feature value is not extracted from the data packet, the component is analyzed, and the external interface list, compilation environment, running platform and data structure definition of the component are extracted from the analysis results. Based on the external interface list, compilation environment, running platform and data structure definition, the airworthiness feature value of the corresponding field is determined. If no valid airworthiness feature value is obtained from the analysis results, the missing airworthiness feature field will be marked as pending confirmation to indicate the input of the corresponding airworthiness feature value.

5. The method according to claim 1, characterized in that, The step of performing content integrity calculation on the component feature architecture to generate integrity information includes: Perform a binary hash calculation on the component content of the component to obtain the component content hash value; The component feature architecture is signed to generate feature architecture signature information; The preset airworthiness component feature paradigm template is signed to generate template signature information; Obtain the chain fingerprint of the historical versions of the component feature architecture, bind the hash value of the component content of the current version and the feature architecture signature information with the chain fingerprint of the historical versions to generate the chain fingerprint of the current version; The integrity information is generated based on the component content hash value, the feature architecture signature information, the template signature information, and the chain fingerprint of the current version.

6. The method according to claim 1, characterized in that, The step of storing the target component feature architecture into the component feature library of the airborne software includes: The target component feature architecture is subjected to compliance verification to obtain compliance verification information; When the compliance verification information indicates that the verification has passed, the target component feature architecture is stored in the component feature library of the airborne software.

7. The method according to claim 6, characterized in that, The compliance verification of the target component feature architecture to obtain compliance verification information includes: Based on the security level of the component, verify whether the coverage rate recorded in the MC / DC coverage status field of the correction condition determination in the feature architecture of the target component reaches the preset threshold corresponding to the security level, and obtain the first verification result; Verify whether each traceability identifier in the full-chain traceability identifier list is complete and can be associated with the source, and obtain the second verification result; Verify the validity of the integrity information to obtain a third verification result; Based on the first verification result, the second verification result, and the third verification result, the compliance verification information is generated and output.

8. The method according to claim 7, characterized in that, The step of verifying whether the coverage rate recorded in the coverage status field of the correction condition determination reaches the preset threshold corresponding to the security level, based on the security level of the component, includes: When the security level is Level 1, verify whether the statement coverage, decision coverage, and MC / DC coverage in the coverage are all at the first preset threshold. When the security level is level 2, verify whether the statement coverage rate and the judgment coverage rate are both the first preset threshold. When the security level is level three, verify whether the statement coverage rate is at the first preset threshold. When the security level is level four or five, verify whether the statement coverage rate is at the second preset threshold.

9. The method according to claim 7, characterized in that, The step of generating and outputting compliance verification information based on the first verification result, the second verification result, and the third verification result includes: Determine whether the security level is consistent with the preset security level classification rule level to obtain the fourth verification result; Based on the first verification result, the second verification result, the third verification result, and the fourth verification result, compliance verification information is generated and output.

10. The method according to claim 7, characterized in that, The step of storing the target component feature architecture into the component feature library of the airborne software includes: An index is created using the security level, change history, and affected domain as index keys and the target component feature architecture as the index object. The target component feature architecture is stored in the component feature library of the airborne software.

Images