Software source code security verification method and system of rail transit trackside subsystem, computing equipment and computer readable storage medium

Abstract

The invention discloses a software source code security verification method and system of a rail transit trackside subsystem, computing equipment and a computer readable storage medium. The method comprises the following steps: S1, based on a software demand security verification report, extracting a tracking relationship between security demands and software demands, and automatically generating a security demand-software demand tracking table lt; sSRgt, SSRgt; ; s2, based on an SCADE model annotation file in the software source code, a function annotation block and a walking reading result of the software source code, extracting a tracking relation between the software requirement and the software source code, and automatically generating a software requirement-software source code verification table lt; an SRCodegt (SRCodegt ; s3, splicing a table lt by taking a software demand ID field as a key; sSRgt, SSRgt; and a table lt; an SRCodegt (SRCodegt A comprehensive verification conclusion field is added in the spliced table, and a software source code security verification table lt is obtained; swSCSVR < gt > is carried out; ; the comprehensive verification conclusion field is used for storing a final conclusion generated by a software security engineer according to a code walk-by-read result.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of rail transit safety technology, in particular to a software source code safety verification method and system for a rail transit trackside subsystem, a computing device and a computer readable storage medium. BACKGROUND

[0002] In a rail transit signal system, a trackside subsystem is mainly composed of a zone controller (ZC) and a line controller (LC). The core function of the ZC is to maintain the train sequence on the track and calculate the movement authority for the train. The core function of the LC is to manage the safety clock and handle the temporary speed limit. In order to ensure that the safety functions allocated to the software layer can be correctly implemented and meet the "fail-safe" principle, according to the European standard EN50128:2011, safety verification activities need to be carried out on the software source code of the trackside. Therefore, it is particularly important to verify the safety of the software source code in the development process of the trackside subsystem application software.

[0003] The current software source code safety verification method is that a software safety verification engineer manually establishes a safety requirement and software requirement tracking matrix in a software source code safety verification table according to the output of the software requirement safety verification activity (including safety requirements, functional requirements (subsystem requirements and structural design), a software requirement tracking matrix, and a verification conclusion of whether the software requirements can cover the safety requirements, etc.), and then manually reads and checks the software source code according to the safety requirements and software requirements to confirm whether the software source code has correctly implemented the software requirements and safety requirements.

[0004] Currently, software safety verification engineers manually establish the tracking relationship between safety requirements and software requirements, which is time-consuming and laborious and has the risk of missing or misconstructing. Moreover, in the process of reading and reviewing the software source code, the code evidence that can cover the safety requirements and software requirements, i.e., all functions that implement the entire software requirement complete process (including the path information of the function in the project), need to be manually listed. Currently, this process entirely relies on the manual recording of software safety verification personnel, which is time-consuming and laborious. And with the continuous increase of software size and software requirement complexity, the verification efficiency continues to decline.

[0005] The statements herein merely provide background technology related to the present application, and do not necessarily constitute the prior art. SUMMARY

[0006] The purpose of the present application is to provide a software source code safety verification method and system for a rail transit trackside subsystem, a computing device and a computer readable storage medium, to overcome the problem that the current software source code safety verification method relies too much on manpower and is prone to errors.

[0007] In order to achieve the above object, a software source code security verification method of a trackside subsystem of rail transit, the software source code including SCADE models and ManualCode, the method comprising: Step S1, based on a software requirement security verification report, extracting a trace relationship of safety requirements and software requirements and automatically generating a safety requirement-software requirement trace table <S_SR>; The safety requirement-software requirement trace table <S_SR> at least includes: a safety requirement ID field, a safety requirement description field, a software requirement ID field, a software requirement description field, a software requirement verification conclusion field, a safety verification description field and a safety verification comment field; Step S2, based on the SCADE model annotation file in the software source code, the function annotation block and the reading result of the software source code, extracting a trace relationship of software requirements and software source code and automatically generating a software requirement-software source code verification table <SR_Code>; The software requirement-software source code verification table <SR_Code> at least includes: a software requirement ID field, a related SCADE field, a related ManualCode field, a code verification conclusion field, a code comment field and a related CR field; the code verification conclusion field, the code comment field and the related CR field are used to record the code reading evidence of the software safety engineer; Step S3, taking the software requirement ID field as the key, splicing the safety requirement-software requirement trace table <S_SR> and the software requirement-software source code verification table <SR_Code>, and adding a comprehensive verification conclusion field in the spliced table to obtain a software source code security verification table <SwSC_SVR>; the comprehensive verification conclusion field is used to store the conclusion generated by the software safety engineer according to the field value of the software requirement verification conclusion field and the field value of the code verification conclusion field.

[0008] Optionally, the step S1 comprises: Step S11, inputting the software requirement security verification report; Step S12, creating an empty safety requirement-software requirement trace table <S_SR>; Step S13, traversing the report by row; the report includes multiple field values, each field value having a corresponding attribute label; Step S14, checking whether the field value of the attribute label as the responsible party in the row data of the report is the regional controller or the line controller; if it is the regional controller or the line controller, executing step S15; otherwise, deleting the row data; Step S15, check if the field value of the attribute label of software requirement ID in the reported row data is empty; if not, execute step S16; otherwise, delete the row data; Step S16, retain the field values of the attribute labels of safety requirement ID, safety requirement description, responsible party, software requirement ID, software requirement description, software requirement verification conclusion, safety verification description, and safety verification comment in the reported row data; Step S17, determine if the row index i of the row traversal reaches the last row position of the report; if not, update the row index i = i + 1 and continue to execute step S13; if yes, execute step S18; Step S18, store the plurality of field values retained in step S16 into the corresponding fields of the table <S_SR>.

[0009] Optionally, the step S2 comprises: Step S21, obtain all SCADE model annotation files from the SCADE model engineering files in the software source code; extract SCADE model file names from the annotation files; extract source information and model function description information from the annotation files by a regular expression matching method; store the model names, source information, and model function description information extracted from the annotation files into the model name field, software requirement ID field, and model function description field of the software requirement-SCADE model tracking table <SR_SCADE> respectively; the source information in the annotation file includes the software requirement ID tracked by the SCADE model; Step S22, obtain all ManualCode function annotation blocks from the ManualCode engineering files in the software source code; extract function names, source information, function function description, global variables, parameters, and return values from the function annotation blocks by a regular expression matching method, and store them into the function name field, software requirement ID field, function function description field, global variable field, parameter field, and return value field of the software requirement-ManualCode tracking table <SR_ManualCode> respectively; the source information in the function annotation block includes the software requirement ID covered by the function; Step S23, take the software requirement ID field as the key, classify and aggregate the model name field values and function name field values corresponding to the same software requirement ID field values in the table <SR_SCADE> and the table <SR_ManualCode>, and generate the table <SR_Code> based on the classification and aggregation result.

[0010] Optionally, the step S21 comprises: Step S2101, input the engineering path of the SCADE model in the software source code; Step S2102, creating a software requirement-SCADE model tracking table <SR_SCADE>; Step S2103, scanning all SCADE model files under the SCADE model engineering path to obtain a SCADE model file path list; Step S2104, traversing the SCADE model file path list; Step S2105, judging whether the file under the current SCADE model file path is an SCADE model annotation file based on the suffix name of the file; if yes, extracting the corresponding SCADE model file name based on the annotation file, and entering step S2106; otherwise, entering step S2104; Step S2106, parsing the annotation file, designing a regular expression matching rule, and capturing line data including source information and line data including model function description in the annotation file; Step S2107, extracting all software requirement IDs from the line data including source information and recording them to a software requirement ID list SR_list; Step S2108, traversing the list SR_list; Step S2109, generating a full-path SCADE model name based on the current SCADE model file path and the SCADE model name; saving each software requirement ID in the list SR_list, the full-path SCADE model file name, and the line data including model function description; Step S2110, judging whether the traversal of the list SR_list is completed; if yes, executing step S2111; Step S2111, judging whether the traversal of the SCADE model file path list is completed; if yes, entering step S2112; otherwise, entering step S2104; Step S2112, storing all software requirement IDs, full-path SCADE model file names, and line data including model function description saved in step S2109 to the software requirement ID field, model name field, and model function description field of the table <SR_SCADE> respectively.

[0011] Optionally, the step S22 includes: Step S2201, inputting the engineering path of software source code ManualCode; Step S2202, creating a software requirement-ManualCode tracking table <SR_ManualCode>; Step S2203, scanning all files under the ManualCode engineering directory to obtain a ManualCode file path list; Step S2204, traverse the ManualCode file path list; Step S2205, based on the set file suffix name, judge whether the file under the current ManualCode file path includes logic code and function definition; if yes, extract the path information of the file and enter step S2206; otherwise, enter step S2204; Step S2206, design a regular expression for parsing the file with the set file suffix name, and capture the function name, line data containing source information, function function description information, global variable, parameter and return value from the function comment block of the file; Step S2207: using the regular expression designed in step S2206, read the file extracted in step S2205 by line, and store the captured function name, line data containing source information, function function description information, global variable, parameter and return value in matches_functions_list.Groups[1], matches_functions_list.Groups[2], matches_functions_list.Groups[3], matches_functions_list.Groups[4], matches_functions_list.Groups[5], matches_functions_list.Groups[6] in turn; wherein matches_functions_list is a list; Groups is a matching group in the list matches_functions_list; Step S2208: traverse the matches_functions_list list obtained in step S2207; Step S2209: store matches_functions_list[i].Groups[2] in the string variable Function Sources; i is the list index; Step S2210, extract all software requirement IDs in the string variable Function Sources and store them in the list function_sources_list; Step S2211, traverse the list function_sources_list obtained in step S2210; Step S2212, generating a full path function name based on the file path information extracted in step S2205 and matches_functions_list[i]Groups[1]; saving the full path function name, function_sources_list[j], matches_functions_list[i]Groups[3], matches_functions_list[i]Groups[4], matches_functions_list[i]Groups[5], matches_functions_list[i]Groups[6]; wherein j is the list index of the list function_sources_list; Step S2213, judging whether the list function_sources_list is traversed to the end; if yes, entering step S2214; otherwise, updating the list index j to j+1, and entering step S2211; Step S2214, judging whether the list matches_functions_list is traversed to the end; if yes, entering step S2215; otherwise, updating the list index i to i+1, and entering step S2208; Step S2215, judging whether the list ManualCode file path is traversed to the end; if yes, entering step S2216; otherwise, entering step S2204; Step S2216, storing the full path function name, the list function_sources_list, matches_functions_list[i]Groups[3], matches_functions_list[i]Groups[4], matches_functions_list[i]Groups[5], matches_functions_list[i]Groups[6] saved in step 2212 into the function name field, the software requirement ID field, the function function description field, the global variable field, the parameter field and the return value field of the table <SR_ManualCode> respectively.

[0012] Optionally, the step S23 comprises: Step S231, performing a grouping aggregation operation on the table <SR_SCADE> with the software requirement ID as the key, collecting and merging the model name field values corresponding to the same key value, and storing the processing result into a dictionary structure SR_SCADE_Dict; the key of the dictionary structure SR_SCADE_Dict is the software requirement ID, and the value is a list of corresponding model name field values; Step S232, performing a group aggregation operation on the table <SR_ManualCode> with the software requirement ID as the key, and merging the function name field values corresponding to the same key value, and storing the processing result in the dictionary structure SR_MC_Dict; the key of the dictionary structure SR_MC_Dict is the software requirement ID, and the value is a list of corresponding function name field values; Step S233, structurally aggregating the model name field value list and the function name field value list under the same primary key, and storing the processing result in the dictionary structure SR_Code_Dict; the key of the dictionary structure SR_Code_Dict is the software requirement ID, and the value is a binary data structure; the binary data structure includes a first attribute value and a second attribute value; the first attribute value is the model name field value list in the dictionary structure SR_SCADE_Dict, and the second attribute value is the function name field value list in the dictionary structure SR_MC_Dict; Step S234, creating a software requirement-software source code verification table <SR_Code>, and writing the data in the dictionary structure SR_Code_Dict into the table <SR_Code> in sequence; the software requirement ID field, the related SCADE field, and the related ManualCode field of the table <SR_Code> are used to store the key value of the dictionary structure SR_Code_Dict, the first attribute value, and the second attribute value, respectively; The software safety engineer writes the reading result of the software source code, the implementation details of the code reading evidence, and the defect information, and the related tracking record identifier proposed when the defect is found in the reading process into the code verification conclusion field, the code comment field, and the related CR field, respectively.

[0013] Optionally, the step S3 includes: Step S31, inputting a safety requirement-software requirement tracking table <S_SR> and a software requirement-software source code verification table <SR_Code>; Step S32, creating a software source code safety verification table <SwSC_SVR>; the table <SwSC_SVR> includes a safety requirement ID field, a safety requirement description field, a responsible party field, a software requirement ID field, a software requirement description field, a software requirement verification conclusion field, a safety verification description field, a safety verification comment field, a related SCADE field, a related ManualCode field, a code verification conclusion field, a code comment field, a related CR field, and a comprehensive verification conclusion field; Step S33, traversing the table <S_SR> by row, and the row index of the table <S_SR> is m; Step S34, traversing the table <SR_Code> by row; the row index of the table <SR_Code> is n; Step S35, judging whether the software requirement ID value in the mth row of the table <S_SR> is equal to the software requirement ID value in the nth row of the table <SR_Code>; if yes, entering step S36; otherwise, entering step S37; Step S36, obtaining the data set <S_SR>[m][:] from the table <S_SR> and the data set <SR_Code>[n][:] from the table <SR_Code>; performing row-level merging of the two data sets by taking the software requirement ID as the association key, and writing the merged data set into the corresponding field of the table <SwSC_SVR>; writing the conclusion generated by the software safety engineer according to the field value of the software requirement verification conclusion field and the field value of the code verification conclusion field into the comprehensive verification conclusion field; The data set <S_SR>[m][:] represents a data set composed of all field values in the mth row of the table <S_SR>; the data set <SR_Code>[n][:] represents a data set composed of all field values in the nth row of the table <SR_Code>; Step S37, judging whether the row index n is equal to the position of the last row of the table <SR_Code>; if no, updating the row index n to n+1 and entering step S34; if yes, entering step S38; Step S38, judging whether the row index m is equal to the position of the last row of the table <S_SR>; if no, updating m to m+1 and entering step S33; if yes, entering step S39; Step S39, outputting the data saved in the table <SwSC_SVR>.

[0014] Optionally, in step 2105, if the suffix of the file is “.ann”, it is judged that the file under the SCADE model file path is an annotation file of the SCADE model.

[0015] Optionally, in step S2205, if the suffix of the file is “.c”, it is judged that the file includes logic code and function definition.

[0016] The application further provides a software source code safety verification system of a rail transit trackside subsystem, which is used for executing the software source code safety verification method of the rail transit trackside subsystem as described in the application, and comprises: An input module is configured to input a software requirement safety verification report and a software source code engineering file; An operation module is configured to extract a safety requirement-software requirement tracking table <S_SR> based on the software requirement safety verification report, so as to obtain the relationship between the safety requirement and the software requirement; The operation module generates a software requirement-software source code verification table <SR_Code> based on the software source code engineering file to obtain the relationship between the software requirement and the software source code; and the operation module further generates a software source code security verification table <SwSC_SVR> based on the table <S_SR> and the table <SR_Code> to obtain the relationship among the security requirement, the software requirement and the software source code. An output module generates a corresponding software source code security verification report based on the table <SwSC_SVR> and outputs the table <SwSC_SVR> and the software source code security verification report.

[0017] The application further provides a computing device, comprising: at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, which, when executed by the at least one processor, cause the computing device to perform the steps of the software source code security verification method of the rail transit trackside subsystem according to the application.

[0018] The application further provides a computer readable storage medium having stored thereon computer program code which, when executed, performs the software source code security verification method of the rail transit trackside subsystem according to the application.

[0019] Compared with the prior art, the application has the following beneficial effects: 1) The application creatively realizes automatic construction of the tracking relationship between the security requirement and the software requirement in the software source code security verification process, significantly reduces the risk of incorrect construction and omission in the traditional manual construction process, and improves the accuracy and reliability of software security verification.

[0020] 2) The application realizes automatic construction of the correlation relationship between the software requirement and the software source code in the software source code security verification process, greatly reduces the heavy burden of traditional manual verification, and significantly improves the code review efficiency and overall work efficiency of software security verification personnel.

[0021] 3) The application realizes automatic extraction of the target function or target model path information, solves the tediousness of manual copying of the target function or model path information, and greatly improves the work efficiency of software security verification personnel. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 For the embodiment of the application, the flowchart of the software source code security verification method of the rail transit trackside subsystem.

[0023] Figure 2Flowchart for creating the security requirement-software requirement traceability table <SR> in an embodiment of the present application.

[0024] Figure 3 Flowchart for creating the software requirement-software source code verification table <SR_Code> in an embodiment of the present application.

[0025] Figure 4 Flowchart for creating the software requirement-SCADE model traceability table <SR_SCADE> in an embodiment of the present application.

[0026] Figure 5 Flowchart for creating the software requirement-ManualCode traceability table <SR_ManualCode> in an embodiment of the present application.

[0027] Figure 6 Schematic diagram for creating the software requirement-software source code traceability table <SR_Code> according to the table <SR_SCADE> and the table <SR_ManualCode> in an embodiment of the present application.

[0028] Figure 7 Flowchart for preprocessing the table <SR_SCADE> in an embodiment of the present application.

[0029] Figure 8 Flowchart for preprocessing the table <SR_ManualCode> in an embodiment of the present application.

[0030] Figure 9 Flowchart for creating the dictionary structure SR_Code_Dict in an embodiment of the present application.

[0031] Figure 10 Flowchart for creating the software source code security verification table <SwSC_SVR> in an embodiment of the present application.

[0032] Figure 11 Architectural diagram of the software source code security verification system of the rail transit wayside subsystem in an embodiment of the present application.

[0033] Figure 12 Man-machine interface diagram of the software source code security verification system of the rail transit wayside subsystem in an embodiment of the present application. DETAILED DESCRIPTION

[0034] The trackside subsystem software source code security verification method, system, computing device and computer readable storage medium of the trackside subsystem of rail transit are further described in detail below in combination with the accompanying drawings and specific embodiments. The advantages and features of the present application will be clearer according to the following description. It should be noted that the drawings are greatly simplified and all use non-precise proportions, only for the purpose of facilitating and clarifying the purpose of assisting in the description of the embodiments of the present application. In order to make the purpose, features and advantages of the present application more obvious and easy to understand, please refer to the accompanying drawings. It should be noted that the structure, proportion, size and the like shown in the drawings attached to the present specification are only used to cooperate with the content disclosed in the specification, so as to be understood and read by those skilled in the art, and are not used to limit the implementation of the present application. Therefore, it does not have the technical meaning of substance, and any modification of structure, change of proportion relationship or adjustment of size, which does not affect the effect and purpose that can be achieved by the present application, should still fall within the scope of the technical content disclosed by the present application.

[0035] The software source code of the trackside subsystem of rail transit includes SCADE model and ManualCode (code written by rail transit software engineers). The present embodiment provides a software source code security verification method for the trackside subsystem of rail transit, as shown in Figure 1 The method comprises the following steps: Step S1, based on the software requirement safety verification report, Sw_SVR (Software Requirement Safety Verification Report) report, extract the trace relationship between safety requirements and software requirements and automatically generate a safety requirement-software requirement trace table <S_SR>.

[0036] The safety requirement-software requirement trace table <S_SR> at least includes: safety requirement ID field, safety requirement description field, software requirement ID field, software requirement description field, software requirement verification conclusion field, safety verification description field and safety verification comment field. The safety verification description field is used to record the reason of NOK (No OK) or NA (Not Applicable) (for example, the reason why the software requirement cannot cover the safety requirement, the reason why the safety verification fails). The safety verification comment field is used to record the detailed evidence of the software requirement covering the safety requirement.

[0037] As shown in Figure 2 In the present embodiment, step S1 comprises: Step S11, input the Sw_SVR report.

[0038] Step S12, create an empty safety requirement-software requirement trace table <S_SR>.

[0039] Step S13, traversing the Sw_SVR report by row, the Sw_SVR report including multiple field values, each field value having a corresponding attribute label.

[0040] Step S14, checking whether the field value of the attribute label of responsibility party in the row data of the Sw_SVR report is a zone controller or a line controller; if yes, executing step S15; otherwise, deleting the row data.

[0041] Step S15, checking whether the field value of the attribute label of software requirement ID in the row data of the Sw_SVR report is empty; if no, executing step S16; otherwise, deleting the row data.

[0042] Step S16, reserving multiple field values of the attribute labels of safety requirement ID, safety requirement description, responsibility party, software requirement ID, software requirement description, software requirement verification conclusion, safety verification description, safety verification comment in the row data of the Sw_SVR report.

[0043] Step S17, judging whether the row index i of the row traversal reaches the end row position of the Sw_SVR report; if no, updating the row index i=i+1 and continuing to execute step S13; if yes, executing step S18. Step S18, storing the multiple field values reserved in step S16 into the corresponding fields of the table <S_SR>.

[0044] Step S2, based on the SCADE model annotation file, the function annotation block in the software source code and the reading result of the software source code, extracting the tracking relationship between the software requirement and the software source code and automatically generating a software requirement-software source code verification table <SR_Code>.

[0045] The software requirement-software source code verification table <SR_Code> at least includes a software requirement ID field, a related SCADE field, a related ManualCode field, a code verification conclusion field, a code comment field and a related CR (Change Request) field; the code verification conclusion field, the code comment field and the related CR field are used for recording the code reading evidence of the software safety engineer.

[0046] In this embodiment, as shown in Figure 3 The step S2 includes: Step S21: Obtain the annotation files of all SCADE models from the SCADE model project files in the software source code; extract the SCADE model file names from the annotation files; extract source information and model functional description information from the annotation files using regular expression matching; store the source information, model names, and model functional description information extracted from the annotation files into the Software Requirements - SCADE Model Tracking Table, respectively.<SR_SCADE> The software requirement ID field, model name field, and model function description field are included in the annotation file; the source information includes the software requirement ID tracked by the SCADE model. This generates a tracking relationship between software requirements and the SCADE model, as shown in the table.<SR_SCADE> This serves as a mapping table for the tracking relationship.

[0047] like Figure 4 As shown, in this embodiment, step S21 includes: Step S2101: Input the project path of the SCADE model in the software source code.

[0048] Step S2102: Create a Software Requirements - SCADE Model Tracking Table<SR_SCADE> .

[0049] Step S2103: Scan all SCADE model files under the SCADE model project path to obtain a list of SCADE model file paths.

[0050] Step S2104: Traverse the SCADE model file path list.

[0051] Step S2105: Based on the file extension, determine whether the file in the current SCADE model file path is an annotation file of the SCADE model; if so, extract the corresponding SCADE model file name based on the annotation file and proceed to step S2106; otherwise, proceed to step S2104.

[0052] In this embodiment, the annotation information of the SCADE model is stored in a file with the extension ".ann". Therefore, the file name ".ann" is used to determine whether it is an annotation file of the SCADE model.

[0053] Step S2106: Parse the annotation file, design regular expression matching rules, and capture the line data in the annotation file that includes source information and line data that includes model function descriptions.

[0054] In this embodiment, the regular expressions are "^#Src=(.+)$" and "^#Des=(.+)$", which are used to capture the software requirement ID and the content of the line including the model function description tracked by the model. The "^" is used to match the beginning of the line to ensure that the content of the line starts with "#Src=" or "#Des=". The "(.+)$" is used to capture all the characters following "#Src=" or "#Des=" until the end of the line.

[0055] Step S2107, extract all the software requirement IDs from the line data including the source information and record them to the software requirement ID list SR_list.

[0056] In this embodiment, the content of the line starting with "#Src=" usually consists of multiple software requirement IDs (such as [SR-001], [SR-002],..., [SR-006]), so it is necessary to process the content of the line starting with "#Src=" captured in step S2106 to extract all the closed content between the pairs of square brackets from the line, i.e., the list of software requirement IDs tracked by the model file, denoted as SR_list. The main implementation logic is as follows: for (int i = 0; i < line.Length; i++) / / iterate through each character of the content of the line starting with "#Src=" { if (line[i] == '[') { bracketStart.Push(i); / / record the position index of the left bracket} else if (line[i] == ']') { if (bracketStart.Count > 0) / / ensure that the stack is not empty { int j = bracketStart.Pop(); / / get the position index of the nearest left bracket r_list.Add(line.Substring(j + 1, i - j - 1)); / / extract the string between '[' and ']' } } Step S2108, iterate through the list SR_list.

[0057] Step S2109, generate the full path SCADE model name based on the current SCADE model file path (the directory information of the model file in the project file) and the SCADE model name; save each software requirement ID in the list SR_list, the full path SCADE model file name, and the line data including the model function description.

[0058] Step S2110, judging whether the SR_list list is traversed to the end, if yes, executing step S2111; Step S2111, judging whether the SCADE model file path list is traversed to the end, if yes, entering step S2112, otherwise, entering step S2104; Step S2112, storing all the software requirement IDs, the full path SCADE model file names and the line data including the model function descriptions saved in step S2109 into the software requirement ID field, the model name field and the model function description field of the table <SR_SCADE> respectively (corresponding to the first column to the third column of the table <SR_SCADE> respectively).

[0059] Step S22, obtaining all the ManualCode function comment blocks from the ManualCode project files in the software source code; extracting the function name, the source information, the function function description, the global variable, the parameter and the return value from the function comment block through the regular expression matching method, and storing them into the function name field, the software requirement ID field, the function function description field, the global variable field, the parameter field and the return value field of the software requirement-ManualCode tracking table <SR_ManualCode> respectively; the source information in the function comment block includes the software requirement ID covered by the function.

[0060] In this embodiment, as shown in Figure 5 The step S22 includes: Step S2201, inputting the engineering path of the software source code ManualCode.

[0061] Step S2202, creating the software requirement-ManualCode tracking table <SR_ManualCode>.

[0062] Step S2203, scanning all the files under the ManualCode project directory to obtain a ManualCode file path list.

[0063] Step S2204, traversing the ManualCode file path list.

[0064] Step S2205, judging whether the file under the current ManualCode file path includes logic code and function definition based on the set file suffix name, if yes, extracting the path information of the file and entering step S2206, otherwise, entering step S2204.

[0065] In this embodiment, if the suffix name of the file is “.c”, it is judged that the file includes logic code and function definition.

[0066] Step S2206, a regular expression is designed for parsing a file with a set file suffix name (".c") and capturing a function name, line data containing source information, function function description information, global variables, parameters and return value from a function comment block of the file.

[0067] The regular expression in the embodiment is as follows: pattern_function_start=" / \**\s*" pattern_function_name="Function Name:\s*--(\w+)\s*" pattern_function_sources="Function Source:\s*--([\s\S]*?)FunctionIntention:" pattern_function_intention="\s*([\s\S]*?)Global Variables:" pattern_function_global_parameters="\s*([\s\S]*?)Formal Parameters:" pattern_function_formal_parameters="\s*([\s\S]*?)Return Value:" pattern_function_return_value="\s*--([\s\S]*?)\s*\** / \s*.*?\s*" Wherein, the "pattern_function_start" is used for matching the beginning of the function comment block.

[0068] The "pattern_function_name" is used for matching the function name in the function comment block.

[0069] The "pattern_function_sources" is used for matching all software requirement information tracked in the function comment block.

[0070] The "pattern_function_intention" is used for matching the function description of the corresponding function in the function comment block.

[0071] The "pattern_function_global_parameters" is used for matching the global variables of the corresponding function in the function comment block.

[0072] "pattern_function_formal_parameters" is used to match the formal parameters of the corresponding function in the function comment block.

[0073] "pattern_function_return_value" is used to match the return value of the corresponding function in the function comment block.

[0074] Step S2207: Using the regular expression designed in step S2206, read the file extracted in step S2205 line by line, and store the captured function name, line data containing source information, function function description information, global variables, parameters and return value in matches_functions_list.Groups[1], matches_functions_list.Groups[2], matches_functions_list.Groups[3], matches_functions_list.Groups[4], matches_functions_list.Groups[5], matches_functions_list.Groups[6] in turn; Where matches_functions_list is a list; Groups is a matching group in the list matches_functions_list.

[0075] Step S2208: Traverse the matches_functions_list list obtained in step S2207 (list index i).

[0076] Step S2209: Store matches_functions_list[i].Groups[2] in the string variable Function Sources.

[0077] Function Sources=matches_functions_list[i].Groups[2].

[0078] Step S2210, extract all software requirement IDs in the string variable Function Sources and store them in the list function_sources_list.

[0079] The source information tracked by the ManualCode function is the same as the above-mentioned line content starting with "#Src=". Therefore, the function source information extracted needs to be processed. All closed content between square brackets in Function Sources is extracted to obtain a list of software requirement IDs tracked by the function, denoted as function_sources_list.

[0080] Step S2211, the list function_sources_list obtained in step S2210 is traversed.

[0081] Step S2212, a full path function name is generated based on the file path information extracted in step S2205 and matches_functions_list[i]Groups[1]; the full path function name, function_sources_list[j], matches_functions_list[i]Groups[3], matches_functions_list[i]Groups[4], matches_functions_list[i]Groups[5], and matches_functions_list[i]Groups[6] are saved; wherein j is the list index of the list function_sources_list.

[0082] In this embodiment, let Function Name represent the full path function name, and let file_path represent the path information of the.c file in the ManualCode in the project file, then Function Name=file_path+”\”+matches_functions_list[i]Groups[1].

[0083] Step S2213, it is judged whether the list function_sources_list is traversed; if yes, step S2214 is entered; otherwise, the list index j is updated to j+1, and step S2211 is entered. Step S2214, it is judged whether the list matches_functions_list is traversed; if yes, step S2215 is entered; otherwise, the list index i is updated to i+1, and step S2208 is entered. Step S2215, it is judged whether the ManualCode file path list is traversed; if yes, step S2216 is entered; otherwise, step S2204 is entered. Step S2216, save the full path function name, list function_sources_list, matches_functions_list[i]Groups[3], matches_functions_list[i]Groups[4], matches_functions_list[i]Groups[5], matches_functions_list[i]Groups[6] saved in step 2212 into the function name field, software requirement ID field, function description field, global variable field, parameter field and return value field of the table <SR_ManualCode> (in this embodiment, corresponding to the first column to the sixth column of the table <SR_ManualCode> respectively).

[0084] Step S23, take the software requirement ID field as the key, classify and aggregate the model name field value and the function name field value corresponding to the same software requirement ID field value in the table <SR_SCADE> and the table <SR_ManualCode>, and generate a table <SR_Code> based on the classification and aggregation result.

[0085] In this embodiment, as shown in Figure 6 , step S23 includes: Step S231, perform a grouping aggregation operation on the table <SR_SCADE> with the software requirement ID as the key, collect and combine the model name field values corresponding to the same key value, and store the processing result in a dictionary structure SR_SCADE_Dict. The key of the dictionary structure SR_SCADE_Dict is the software requirement ID, and the value is a list of corresponding model name field values.

[0086] Step 231 is a preprocessing of the table <SR_SCADE>. In this embodiment, as shown in Figure 7 , step S231 includes: Step S2311, input the table <SR_SCADE>.

[0087] Step S2312, create an empty dictionary SR_SCADE_Dict.

[0088] Step S2313, read the table <SR_SCADE> by row (row index i).

[0089] In this embodiment, since the first row of the table <SR_SCADE> stores the field name (i.e. the column name), i starts from 2, which is used to skip the column name row.

[0090] Step S2314, judge whether the value of <SR_SCADE>[i][1] exists in the dictionary SR_SCADE_Dict; if exists (indicating the same software requirement ID key exists), enter step 2315; otherwise (indicating the software requirement ID key does not exist in the dictionary SR_SCADE_Dict, at this time the write operation of the key-value pair needs to be performed), enter step 2316. In this embodiment, “[1]” in <SR_SCADE>[i][1] represents the column index, i.e. the 1st column (field name: software requirement ID) of the i-th row of the table <SR_SCADE>.

[0091] Step S2315, perform the merging operation of the same key-value pair model name field value on the table <SR_SCADE> with the software requirement ID as the key, form a model name field value list, and the specific operation is as follows: SR_SCADE_Dict[<SR_SCADE>[i][1]].append(<SR_SCADE>[i][2]).

[0092] Wherein, “[2]” in <SR_SCADE>[i][2] represents the column index, i.e. the model name column; Step 2316, write <SR_SCADE>[i][1] and <SR_SCADE>[i][2] into the SR_SCADE_Dict dictionary. The specific operation is as follows: SR_SCADE_Dict[<SR_SCADE>[i][1]]= [<SR_SCADE>[i][2]].

[0093] Step 2317, judge whether the reading of the <SR_SCADE> table is completed. If not, update the row index i of the table <SR_SCADE> to i+1, and enter step 2313; otherwise, enter step 2318.

[0094] Step 2318, if the reading of the table <SR_SCADE> is completed, output the dictionary SR_SCADE_Dict.

[0095] The key of the dictionary SR_SCADE_Dict is the software requirement ID, and the value is the corresponding model name field value list.

[0096] Step S232, perform the grouping aggregation operation with the software requirement ID as the key on the table <SR_ManualCode>, collect and merge the function name field values corresponding to the same key value, and store the processing result into the dictionary structure SR_MC_Dict; the key of the dictionary structure SR_MC_Dict is the software requirement ID, and the value is the list of corresponding function name field values.

[0097] Step 232 is preprocessing of the table <SR_ManualCode>. As shown in the figure, in this embodiment, step S232 includes: Figure 8 Step 2321, input the table <SR_ManualCode>.

[0098] Step 2322, create an empty dictionary SR_MC_Dict.

[0099] Step 2322, read the <SR_ManualCode> table by row (row index is j).

[0100] In this embodiment, since the first row of the table <SR_ManualCode> stores the field name (i.e. column name), j starts from 2, which is used to skip the column name row.

[0101] Step 2324, judge whether the value of <SR_ManualCode>[j][1] exists in the dictionary SR_MC_Dict; if yes (it indicates that there is the same software requirement ID key), go to step 2325; otherwise (it indicates that the dictionary SR_MC_Dict does not have the software requirement ID key, at this time, the write operation of the key-value pair needs to be performed), go to step 2326.

[0102] In the above, “[1]” in <SR_ManualCode>[j][1] represents the column index, i.e. the software requirement ID column.

[0103] Step 2325, perform the merging operation of the function name field value corresponding to the same key value. The specific operation is as follows: SR_MC_Dict[<SR_ManualCode>[j][1]].append(<SR_ManualCode>[j][2]).

[0104] In the above, “[2]” in <SR_ManualCode>[j][2] represents the column index, i.e. the function name column.

[0105] Step 2326, write <SR_ManualCode>[j][1] and <SR_ManualCode>[j][2] into the dictionary SR_MC_Dict, and the specific operation is as follows: SR_MC_Dict[<SR_ManualCode>[j][1]]= [<SR_ManualCode>[j][2]].

[0106] ​Step 2327, judge whether the reading of table <SR_ManualCode> is finished; if not, update the row index j to j+1, and go to step 2323; otherwise, go to step 2328.

[0107] Step 2328, output the dictionary SR_MC_Dict.

[0108] The key of the dictionary SR_MC_Dict is the software requirement ID, and the value is the corresponding function name field value list.

[0109] Step S233, structurally aggregate the model name field value list and the function name field value list under the same primary key, and store the processing result to the dictionary structure SR_Code_Dict; the key of the dictionary structure SR_Code_Dict is the software requirement ID, and the value is a binary tuple data structure; the binary data structure includes a first attribute value and a second attribute value; the first attribute value is the model name field value list in the dictionary structure SR_SCADE_Dict, and the second attribute value is the function name field value list in the dictionary structure SR_MC_Dict.

[0110] In this embodiment, as shown in Figure 9 Step 233 includes: Step 233.1, input the dictionary SR_SCADE_Dict and the dictionary SR_MC_Dict.

[0111] Step 233.2, create an empty dictionary SR_Code_Dict.

[0112] Step 233.3, store the dictionary SR_SCADE_Dict and the dictionary SR_MC_Dict to the list Dict_list, and traverse the Dict_list list (index value k, initial value of k is 0).

[0113] Step 233.4, perform full key-value pair traversal operation on the current dictionary Dict_list[k], wherein each key-value pair (Key-Value Pair) is abbreviated as kvp, and the traversal process follows the storage order of the dictionary data structure.

[0114] Step 233.5, judge whether the current kvp.key (the key of Dict_list[k], i.e. the software requirement ID) exists in the dictionary SR_Code_Dict; if not (it is explained that the dictionary SR_Code_Dict has no software requirement ID key), go to step 233.6; otherwise, go to step 233.7.

[0115] Step 233.6, create a new record (record), and perform the following operations: SR_Code_Dict[kvp.key]=record wherein record has a scade_name attribute (corresponding to the first attribute value described above) and a fun_name attribute (corresponding to the second attribute value described above). At this time, record is an empty record, and has not yet stored the first attribute value and the second attribute value corresponding to kvp.key.

[0116] Step 233.7, determine whether kvp.value.scade_name is not empty; if yes, execute step 233.8 (i.e. the model name field value list in the current dictionary is not empty, then execute the assignment operation); otherwise, go to step 233.9.

[0117] wherein kvp.value.scade_name represents the model name field value list in the current key-value pair.

[0118] Step 233.8, write the model name field value list information stored in the current key-value pair (kvp) to the scade_name attribute of the newly created record record. That is: record.scade_name=kvp.value.scade_name Step 233.9, continue to determine whether kvp.value.fun_name is not empty; if not empty, execute step 233.10 (i.e. the function name field value list in the current dictionary is not empty, then execute the assignment operation); otherwise, continue to execute step 233.11 (determine whether the key-value pair of the kth dictionary in Dict_list is traversed to the end); wherein kvp.value.fun_name represents the function name field value list in the current key-value pair.

[0119] Step 233.10, write the Function Name list information stored in the current key-value pair (kvp) to the fun_name attribute of the newly created record record; that is: record.fun_name=kvp.value.fun_name Step 233.11, determine whether the key-value pair of the kth dictionary in Dict_list is traversed to the end; if traversed to the end, go to step 233.12; otherwise, go to step 233.4.

[0120] Step 233.12, determine whether the dictionary list Dict_list is traversed to the end; if not ended, update k to k+1, and go to step 233.3; otherwise, go to step 233.13.

[0121] Step 233.13: Output the dictionary SR_Code_Dict.

[0122] The dictionary SR_Code_Dict has software as its key, a list of model name field values ​​as its first attribute, and a list of function name field values ​​as its second attribute.

[0123] Step S234: Create a software requirements - software source code verification form<SR_Code> Write the data from the dictionary structure SR_Code_Dict into a table in order.<SR_Code> The table<SR_Code> The Software Requirement ID field, the related SCADE field, and the related ManualCode field are used to store the key, first attribute value, and second attribute value of the dictionary structure SR_Code_Dict, respectively. The software security engineer writes the results of the software source code walkthrough, the implementation details and defect information of the code walkthrough evidence, and the relevant tracking record identifiers proposed when defects are found during the walkthrough into the code verification conclusion field, code comment field, and relevant CR field, respectively.

[0124] Step S3: Concatenate the security requirement-software requirement traceability table using the software requirement ID field as the key.<S_SR> And the software requirements - software source code verification form<SR_Code> Then, a comprehensive verification conclusion field is added to the concatenated table to obtain the software source code security verification table.<SwSC_SVR> The comprehensive verification conclusion field is used to store the conclusions generated by the software security engineer based on the field values ​​of the software requirements verification conclusion field and the code verification conclusion field.

[0125] like Figure 10 As shown, in this embodiment, step S3 includes: Step S31: Input security requirements - Software Requirements Traceability Form<S_SR> Software Requirements - Software Source Code Verification Form<SR_Code> .

[0126] Step S32: Create a software source code security verification form<SwSC_SVR> ;sheet<SwSC_SVR> This includes: Security Requirement ID field, Security Requirement Description field, Responsible Party field, Software Requirement ID field, Software Requirement Description field, Software Requirement Verification Conclusion field, Security Verification Description field, Security Verification Comment field, Related SCADE field, Related ManualCode field, Code Verification Conclusion field, Code Comment field, Related CR field, and Comprehensive Verification Conclusion field.

[0127] Step S33: Traverse the table row by row<S_SR> The row index is m.

[0128] Step S34, traversing the table <SR_Code> by row, with row index n.

[0129] Step S35, judging whether the software requirement ID value in the mth row of the table <S_SR> is equal to the software requirement ID value in the nth row of the table <SR_Code>; if equal, entering step S36; otherwise, entering step S37.

[0130] Step S36, obtaining the data set <S_SR>[m][:] from the table <S_SR> and the data set <SR_Code>[n][:] from the table <SR_Code>; performing row-level merging of the two data sets by taking the software requirement ID as the association key, and writing the merged data set into the corresponding field of the table <SwSC_SVR>; writing the conclusion generated by the software safety engineer according to the field value of the software requirement verification conclusion field and the field value of the code verification conclusion field into the comprehensive verification conclusion field.

[0131] The data set <S_SR>[m][:] represents a data set composed of all field values in the mth row of the table <S_SR>; the data set <SR_Code>[n][:] represents a data set composed of all field values in the nth row of the table <SR_Code>.

[0132] In the table <SwSC_SVR>, the field values of the safety requirement ID field, the safety requirement description field, the responsible party field, the software requirement ID field, the software requirement description field, the software requirement verification conclusion field, the safety verification instruction field, and the safety verification comment field are from the table <S_SR>.

[0133] In the table <SwSC_SVR>, the field values of the related SCADE field, the related ManualCode field, the code verification conclusion field, the code comment field, and the related CR field are from the table <SR_Code>.

[0134] Step S37, judging whether the row index n is equal to the position of the last row of the table <SR_Code>; if not, updating the row index n to n+1 and entering step S34; if yes, entering step S38.

[0135] Step S38, judging whether the row index m is equal to the position of the last row of the table <S_SR>; if not, updating m to m+1 and entering step S33; if yes, entering step S39.

[0136] Step S39, outputting the data saved in the table <SwSC_SVR>.

[0137] The present application also provides a software source code safety verification system for a rail transit trackside subsystem, which is used to execute the software source code safety verification method for the rail transit trackside subsystem as described in the present application.Figure 11 As shown, the system comprises: an input module, an operation module and an output module.

[0138] The input module is configured to input a software requirement safety verification report and a software source code engineering file.

[0139] The operation module extracts a safety requirement-software requirement tracking table <S_SR> based on the software requirement safety verification report, to obtain the relationship between the safety requirement and the software requirement. The operation module generates a software requirement-software source code verification table <SR_Code> based on the software source code engineering file, to obtain the relationship between the software requirement and the software source code. The operation module further generates a software source code safety verification table <SwSC_SVR> based on the table <S_SR> and the table <SR_Code>, to obtain the relationship among the safety requirement, the software requirement and the software source code.

[0140] The output module generates a corresponding software source code safety verification report based on the table <SwSC_SVR>, and outputs the table <SwSC_SVR> and the software source code safety verification report.

[0141] The present application also provides a computing device comprising: at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, which, when executed by the at least one processor, cause the computing device to perform the steps of the software source code safety verification method of the rail transit wayside subsystem according to the present application.

[0142] The present application also provides a computer-readable storage medium having computer program code stored thereon, which, when executed, performs the software source code safety verification method of the rail transit wayside subsystem according to the present application.

[0143] It should be noted that in this document, the terms "comprising", "including", or any other variant thereof are intended to cover non-exclusive inclusions, so that processes, methods, articles or devices including a series of elements not only include those elements, but also include other elements not explicitly listed, or inherent to such processes, methods, articles or devices. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of another identical element in the process, method, article or device comprising the element.

[0144] While the application has been described in detail and with reference to specific preferred embodiments thereof, it will be apparent to one skilled in the art that various modifications and alternatives can be employed without departing from the spirit and scope of the application. Accordingly, the scope of the application should be determined by the appended claims and their equivalents.

Claims

1. A method for security verification of software source code in a rail transit trackside subsystem, characterized in that, The software source code includes a SCADE model and ManualCode, and the method includes: Step S1: Based on the software requirements security verification report, extract the traceability relationship between security requirements and software requirements and automatically generate a security requirements-software requirements traceability table.<S_SR> ; The security requirements - software requirements traceability table<S_SR> It should include at least the following fields: Security Requirement ID, Security Requirement Description, Software Requirement ID, Software Requirement Description, Software Requirement Verification Conclusion, Security Verification Description, and Security Verification Comments. Step S2: Based on the SCADE model annotation files, function comment blocks, and the results of the software source code walkthrough, extract the tracing relationship between software requirements and software source code, and automatically generate a software requirements-software source code verification table.<SR_Code> ; The Software Requirements - Software Source Code Verification Form<SR_Code> It includes at least the following fields: Software Requirement ID, related SCADE, related ManualCode, code verification conclusion, code comment, and related CR; the code verification conclusion, code comment, and related CR fields are used to record evidence of code review by software security engineers. Step S3: Concatenate the security requirement-software requirement traceability table using the software requirement ID field as the key.<S_SR> And the software requirements - software source code verification form<SR_Code> Then, a comprehensive verification conclusion field is added to the concatenated table to obtain the software source code security verification table.<SwSC_SVR> The comprehensive verification conclusion field is used to store the conclusions generated by the software security engineer based on the field values ​​of the software requirements verification conclusion field and the code verification conclusion field.

2. The software source code security verification method for a rail transit trackside subsystem as described in claim 1, characterized in that, Step S1 includes: Step S11: Input the software requirement security verification report; Step S12: Create an empty security requirements - software requirements traceability table.<S_SR> ; Step S13: Traverse the report row by row; the report includes multiple field values, each field value has a corresponding attribute label; Step S14: Check whether the field value of the attribute label "responsible party" in the row data of the report is a regional controller or a line controller; if it is a regional controller or a line controller, proceed to step S15; otherwise, delete the row data. Step S15: Check if the value of the field with the attribute label "Software Requirement ID" in the row data of the report is empty; if it is not empty, proceed to step S16; otherwise, delete the row data. Step S16: Retain the values ​​of multiple fields in the row data of the report, whose attribute labels are security requirement ID, security requirement description, responsible party, software requirement ID, software requirement description, software requirement verification conclusion, security verification description, and security verification comment. Step S17: Determine whether the row index i of the row traversal has reached the last row of the report; if not, update the row index i = i + 1 and continue to execute step S13; if yes, execute step S18. Step S18: Store the multiple field values ​​retained in step S16 into the table.<S_SR> In the corresponding fields.

3. The software source code security verification method for a rail transit trackside subsystem as described in claim 2, characterized in that, Step S2 includes: Step S21: Obtain the annotation files of all SCADE models from the SCADE model project files in the software source code; extract the SCADE model file names from the annotation files; extract source information and model functional description information from the annotation files using regular expression matching; store the model names, source information, and model functional description information extracted from the annotation files into the Software Requirements - SCADE Model Tracking Table, respectively.<SR_SCADE> The model name field, software requirement ID field, and model function description field; the source information in the annotation file includes the software requirement ID tracked by the SCADE model; Step S22: Obtain all function comment blocks of ManualCode from the ManualCode project file in the software source code; extract the function name, source information, function description, global variables, formal parameters, and return value from the function comment blocks using regular expression matching, and store them in the Software Requirements - ManualCode Tracking Table respectively.<SR_ManualCode> The function name field, software requirement ID field, function description field, global variable field, formal parameter field, and return value field; the source information in the function comment block includes the software requirement ID covered by the function; Step S23: Using the Software Requirement ID field as the key, the table...<SR_SCADE> and the table<SR_ManualCode> In the table, the model name field value and function name field value corresponding to the same software requirement ID field value are categorized and aggregated, and the table is generated based on the categorization and aggregation results.<SR_Code> .

4. The software source code security verification method for a rail transit trackside subsystem as described in claim 3, characterized in that, Step S21 includes: Step S2101: Input the project path of the SCADE model in the software source code; Step S2102: Create a Software Requirements - SCADE Model Tracking Table<SR_SCADE> ; Step S2103: Scan all SCADE model files under the SCADE model project path to obtain a list of SCADE model file paths; Step S2104: Traverse the SCADE model file path list; Step S2105: Based on the file extension, determine whether the file in the current SCADE model file path is an annotation file of the SCADE model; if so, extract the corresponding SCADE model file name based on the annotation file and proceed to step S2106; otherwise, proceed to step S2104. Step S2106: Parse the annotation file, design regular expression matching rules, and capture the line data in the annotation file that includes source information and line data that includes model function description; Step S2107: Extract all software requirement IDs from the row data including source information and record them in the software requirement ID list SR_list; Step S2108: Traverse the list SR_list; Step S2109: Generate a full-path SCADE model name based on the current SCADE model file path and SCADE model name; save each software requirement ID in the list SR_list, the full-path SCADE model file name, and the row data including the model function description; Step S2110: Determine whether the SR_list list has been traversed to the end. If it has, proceed to step S2111. Step S2111: Determine whether the SCADE model file path list has been traversed to the end; if it has, proceed to step S2112; otherwise, proceed to step S2104. Step S2112: Store all software requirement IDs, full path SCADE model file names, and row data including model function descriptions saved in step S2109 into the table.<SR_SCADE> The software requirement ID field, model name field, and model function description field.

5. The software source code security verification method for a rail transit trackside subsystem as described in claim 4, characterized in that, Step S22 includes: Step S2201: Enter the project path of the software source code ManualCode; Step S2202: Create a Software Requirements - ManualCode Trace Table<SR_ManualCode> ; Step S2203: Scan all files in the ManualCode project directory to obtain a list of ManualCode file paths; Step S2204: Traverse the list of ManualCode file paths; Step S2205: Based on the set file extension, determine whether the files under the current ManualCode file path include logic code and function definitions; if so, extract the path information of the file and proceed to step S2206; otherwise, proceed to step S2204. Step S2206: Design a regular expression to parse files with a specified file extension and capture the function name, line data containing source information, function description information, global variables, formal parameters, and return value from the function comment block of the file. Step S2207: Using the regular expression designed in step S2206, read the file extracted in step S2205 line by line, and store the captured function name, line data containing source information, function description information, global variables, formal parameters and return values ​​in matches_functions_list.Groups[1], matches_functions_list.Groups[2], matches_functions_list.Groups[3], matches_functions_list.Groups[4], matches_functions_list.Groups[5], matches_functions_list.Groups[6] in sequence; where matches_functions_list is a list; Groups is the matching group in the list matches_functions_list; Step S2208: Iterate through the matches_functions_list obtained in step S2207; Step S2209: Store matches_functions_list[i].Groups[2] into the string variable FunctionSources; i is the list index; Step S2210: Extract all software requirement IDs from the string variable Function Sources and store them in the list function_sources_list; Step S2211: Iterate through the list function_sources_list obtained in step S2210; Step S2212: Generate the full path function name based on the file path information extracted in step S2205 and matches_functions_list[i]Groups[1]; save the full path function name, function_sources_list[j], matches_functions_list[i]Groups[3], matches_functions_list[i]Groups[4], matches_functions_list[i]Groups[5], and matches_functions_list[i]Groups[6]; where j is the list index of the list function_sources_list; Step S2213: Determine whether the list function_sources_list has finished traversing; if yes, proceed to step S2214; otherwise, update the list index j to j+1 and proceed to step S2211. Step S2214: Determine whether the list of matches_functions_list has been traversed to the end; if yes, proceed to step S2215; otherwise, update the list index i to i+1 and proceed to step S2208. Step S2215: Determine whether the list of ManualCode file paths has been traversed to the end; if yes, proceed to step S2216; otherwise, proceed to step S2204. Step S2216: Store the full path function names, lists function_sources_list, matches_functions_list[i]Groups[3], matches_functions_list[i]Groups[4], matches_functions_list[i]Groups[5], and matches_functions_list[i]Groups[6] saved in step 2212 into tables respectively.<SR_ManualCode> The function name field, software requirement ID field, function description field, global variable field, formal parameter field, and return value field.

6. The software source code security verification method for a rail transit trackside subsystem as described in claim 5, characterized in that, Step S23 includes: Step S231, check the table<SR_SCADE> Perform a grouping and aggregation operation with the software requirement ID as the key, merge the model name field values ​​corresponding to the same key value, and store the processing result in the dictionary structure SR_SCADE_Dict; the key of the dictionary structure SR_SCADE_Dict is the software requirement ID, and the value is a list of the corresponding model name field values; Step S232, check the table<SR_ManualCode> Perform a grouping and aggregation operation with the software requirement ID as the key, merge the function name field values ​​corresponding to the same key value, and store the processing result in the dictionary structure SR_MC_Dict; the key of the dictionary structure SR_MC_Dict is the software requirement ID, and the value is a list of the corresponding function name field values; Step S233: Perform structured aggregation on the list of model name field values ​​and the list of function name field values ​​under the same primary key, and store the processing result in the dictionary structure SR_Code_Dict; the key of the dictionary structure SR_Code_Dict is the software requirement ID, and the value is a binary data structure; the binary data structure includes a first attribute value and a second attribute value; the first attribute value is the list of model name field values ​​in the dictionary structure SR_SCADE_Dict, and the second attribute value is the list of function name field values ​​in the dictionary structure SR_MC_Dict; Step S234: Create a software requirements - software source code verification form<SR_Code> Write the data from the dictionary structure SR_Code_Dict into a table in order.<SR_Code> The table<SR_Code> The Software Requirement ID field, the related SCADE field, and the related ManualCode field are used to store the key value, the first attribute value, and the second attribute value of the dictionary structure SR_Code_Dict, respectively. The software security engineer writes the results of the software source code walkthrough, the implementation details and defect information of the code walkthrough evidence, and the relevant tracking record identifiers proposed when defects are found during the walkthrough into the code verification conclusion field, code comment field, and relevant CR field, respectively.

7. The software source code security verification method for a rail transit trackside subsystem as described in claim 6, characterized in that, Step S3 includes: Step S31: Input security requirements - Software Requirements Traceability Form<S_SR> Software Requirements - Software Source Code Verification Form<SR_Code> ; Step S32: Create a software source code security verification form<SwSC_SVR> ;sheet<SwSC_SVR> This includes: Security Requirement ID field, Security Requirement Description field, Responsible Party field, Software Requirement ID field, Software Requirement Description field, Software Requirement Verification Conclusion field, Security Verification Description field, Security Verification Comment field, Related SCADE field, Related ManualCode field, Code Verification Conclusion field, Code Comment field, Related CR field, and Comprehensive Verification Conclusion field; Step S33: Traverse the table row by row<S_SR> ,sheet<S_SR> The row index is m; Step S34: Traverse the table row by row<SR_Code> ;sheet<SR_Code> The row index is n; Step S35: Determine the table<S_SR> Is the software requirement ID value in row m equal to the table?<SR_Code> The software requirement ID value in the nth row; if it is equal, proceed to step S36; otherwise, proceed to step S37. Step S36, from the table<S_SR> Get Dataset<S_SR> [m][:], from the table<SR_Code> Get Dataset<SR_Code> [n][:]; Using the software requirement ID as the association key, the two datasets are merged at the row level and written to a table.<SwSC_SVR> The corresponding fields; write the conclusion generated by the software security engineer based on the field values ​​of the software requirements verification conclusion field and the code verification conclusion field into the comprehensive verification conclusion field; Dataset<S_SR> [m][:] indicates a table<S_SR> The dataset consists of all field values ​​in row m;<SR_Code> [n][:] represents a table<SR_Code> The dataset consists of all field values ​​in the nth row; Step S37: Determine if row index n is equal to table index n.<SR_Code> If the last row position is not specified, update the row index n to n+1 and proceed to step S34; if yes, proceed to step S38. Step S38: Determine if row index m is equal to table index m.<S_SR> If the last position is not specified, update m to m+1 and proceed to step S33; if yes, proceed to step S39. Step S39: Output and save to a table<SwSC_SVR> The data in the middle.

8. The software source code security verification method for the trackside subsystem as described in claim 4, characterized in that, In step 2105, if the file extension is ".ann", then the file in the current SCADE model file path is determined to be the annotation file of the SCADE model.

9. The software source code security verification method for a rail transit trackside subsystem as described in claim 5, characterized in that, In step S2205, if the file extension is ".c", it is determined that the file contains logic code and function definitions.

10. A software source code security verification system for a rail transit trackside subsystem, used to execute the software source code security verification method for a rail transit trackside subsystem as described in any one of claims 1 to 9, characterized in that, include: The input module is used to input the software requirements security verification report and the software source code project file; The computing module extracts the security requirements-software requirements traceability table based on the software requirements security verification report.<S_SR> To obtain the relationship between security requirements and software requirements; The computation module generates a software requirements-software source code verification form based on the software source code project file.<SR_Code> To obtain the relationship between software requirements and software source code; the calculation module also uses the table<S_SR> and the table<SR_Code> Generate software source code security verification form<SwSC_SVR> To understand the relationship between security requirements, software requirements, and software source code; The output module, which is based on the table<SwSC_SVR> Generate the corresponding software source code security verification report and output the table.<SwSC_SVR> And the security verification report of the software source code.

11. A computing device, characterized in that, include: At least one processor; And at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions, when executed by the at least one processor, causing the computing device to perform the steps of the software source code security verification method for a rail transit trackside subsystem according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, It stores computer program code, which, when run, executes the software source code security verification method for the rail transit trackside subsystem as described in any one of claims 1 to 9.

Images