Controller software development method and system, server and storage medium

Abstract

The invention discloses a controller software development method and system, a server and a storage medium. According to the scheme, the software demand description of the target controller is obtained, and the software demand description comprises the function demand. Dividing the function demand into a plurality of sub-function demands based on the software demand description, and generating a plurality of independent function modules; and performing software coding and testing on the plurality of function modules based on the software demand description, and generating source codes of each function module passing the test. Constructing a traceability relationship between the tested source code of each functional module and the software demand description, and constructing a demand verification matrix based on the traceability relationship; and performing module verification on each functional module through the demand verification matrix. And when each functional module passes module verification, performing overall verification on the target controller software. According to the technical scheme, modularized software development is achieved, meanwhile, the requirement verification matrix is established, comprehensive coverage of software requirements is achieved, and then the overall quality and stability of target controller software are improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a controller software development method, system, server and storage medium. Background Art

[0002] With the rapid progress of industrial automation and intelligent technology, controllers are increasingly used in many devices and systems such as automotive electronics, robot control, smart home, etc. The quality of controller software is directly related to the reliability and stability of these devices.

[0003] However, the current controller software development process, such as the traditional waterfall model, agile development model and DevOps practice, is insufficient in testing, which often results in untested code being deployed to the production environment, thus affecting the overall quality and stability of the controller software. Summary of the invention

[0004] Based on the above problems, the present application provides a controller software development method, system, server and storage medium, the purpose of which is to improve the quality and stability of the controller software.

[0005] The embodiments of the present application disclose the following technical solutions:

[0006] A first aspect of the present application provides a controller software development method, the method comprising:

[0007] Obtaining a software requirement description of a target controller; the software requirement description includes functional requirements that the target controller software needs to implement;

[0008] Based on the software requirement description, the functional requirement is divided into a plurality of sub-functional requirements, and a plurality of independent functional modules are generated according to the plurality of sub-functional requirements; the plurality of independent functional modules together constitute the target controller software;

[0009] Based on the software requirement description, software coding and testing are performed on the multiple independent functional modules to generate source code for each functional module that passes the test;

[0010] Constructing a traceability relationship between the source code of each functional module that has passed the test and the software requirement description, and constructing a requirement verification matrix based on the traceability relationship; the requirement verification matrix includes the software requirements of the target controller and the corresponding test cases;

[0011] Perform module verification on each of the functional modules through the requirement verification matrix;

[0012] When each of the functional modules passes the module verification, the target controller software is verified as a whole.

[0013] In an optional implementation, the software coding and testing of the plurality of independent functional modules based on the software requirement description to generate source code for each of the functional modules that passes the test includes:

[0014] Based on the software requirement description, a unified standard coding specification is used to perform software coding on the multiple independent functional modules;

[0015] Conduct compliance verification on the coded software to obtain verification results;

[0016] If the verification result is failed, feedback will be given and the code will be modified to form a new software version;

[0017] If the verification result is passed, the verified software is tested;

[0018] Generate source code for each of the functional modules to pass the test.

[0019] In an optional implementation, the testing of the verified software includes:

[0020] Performing functional testing, software static scanning and regression testing on the verified software in sequence;

[0021] When the functional test, software static scan and regression test are all passed, the compatibility test is performed on the passed software.

[0022] In an optional implementation, the controller software development method further includes:

[0023] A version management document is generated through a version control algorithm; the version management document includes the content of each version change of the target controller software and the corresponding version number.

[0024] In an optional implementation, after constructing the traceability relationship between the source code of each functional module that has passed the test and the software requirement description, and constructing the requirement verification matrix based on the traceability relationship, the controller software development method further includes:

[0025] Identify a unique product serial number for the target controller software; the product serial number uniquely indicates the target controller software and its corresponding version;

[0026] The product serial number is associated with a software configuration management baseline.

[0027] In an optional implementation, the overall verification of the target controller software includes:

[0028] Verifying the version compatibility of the target controller software;

[0029] Perform compliance check on the input and output of the target controller software that has passed the version compatibility check;

[0030] Perform executability and correctness checks on the execution code of the target controller software that has passed the compliance check.

[0031] A second aspect of the present application provides a controller software development system, the system comprising:

[0032] A software requirement acquisition module is used to acquire a software requirement description of a target controller; the software requirement description includes functional requirements that the target controller software needs to implement;

[0033] A function division module, used for dividing the function requirement into a plurality of sub-function requirements based on the software requirement description, and generating a plurality of independent function modules according to the plurality of sub-function requirements; the plurality of independent function modules together constitute the target controller software;

[0034] A coding and testing module, used to perform software coding and testing on the plurality of independent functional modules based on the software requirement description, and generate source code for each of the functional modules that passes the test;

[0035] A requirement verification matrix construction module is used to construct a traceability relationship between the source code of each functional module that has passed the test and the software requirement description, and to construct a requirement verification matrix based on the traceability relationship; the requirement verification matrix includes the software requirements of the target controller and the corresponding test cases;

[0036] A first verification module, used for performing module verification on each of the functional modules through the requirement verification matrix;

[0037] The second verification module is used to perform overall verification on the target controller software when each of the functional modules passes the module verification.

[0038] In an optional implementation, the coding test module includes:

[0039] A coding unit, configured to perform software coding on the plurality of independent functional modules using a unified standard coding specification based on the software requirement description;

[0040] A conformity verification unit, used to perform conformity verification on the encoded software to obtain a verification result;

[0041] The code modification unit is used to provide problem feedback and modify the code to form a new software version if the verification result is failed;

[0042] The test unit is used to test the verified software if the verification result is passed;

[0043] The source code generation unit is used to generate source code for each of the functional modules to pass the test.

[0044] A third aspect of the present application provides a controller software development server, the server comprising:

[0045] a memory having a computer program stored thereon;

[0046] A processor is used to execute the computer program in the memory to implement the steps of the controller software development method introduced in any implementation manner of the first aspect.

[0047] A fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the controller software development method introduced in any implementation manner of the first aspect are implemented.

[0048] Compared with the prior art, this application has the following beneficial effects:

[0049] First, the software requirement description of the target controller is obtained, and the software requirement description includes functional requirements; secondly, the functional requirements are divided into multiple sub-functional requirements based on the software requirement description, and multiple independent functional modules are generated according to the multiple sub-functional requirements; again, the multiple independent functional modules are coded and tested based on the software requirement description, and the source code of each functional module is generated; then the traceability relationship between the source code of each functional module and the software requirement description is constructed, and the requirement verification matrix is ​​constructed based on the traceability relationship; then the module verification is performed on each functional module through the requirement verification matrix; finally, when each functional module passes the module verification, the target controller software is verified as a whole. It can be seen that in the technical solution of this application, through modular development, the functional requirements of the target controller are subdivided into multiple sub-functional requirements, and corresponding functional modules are generated, which effectively reduces the development complexity and improves the development efficiency, thereby enhancing the flexibility and response speed when the software requirements are changed, and significantly reducing the rework time caused by the change of requirements. By establishing a comprehensive requirement verification matrix, not only the comprehensive coverage of the software requirements of the target controller is ensured, the overall quality and stability of the software are improved, but also deviations can be discovered and corrected in time during the development process, ensuring the consistency of requirements, thereby greatly improving the accuracy and reliability of the controller software. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0051] Figure 1 A flow chart of a controller software development method provided in an embodiment of the present application;

[0052] Figure 2 A schematic diagram of the structure of a controller software development system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] As described above, the current controller software development method has deficiencies in testing, which often leads to the deployment of untested code into the production environment, thus affecting the overall quality and stability of the controller software.

[0054] After research, the inventor provides a controller software development method, system, server and storage medium.

[0055] First, the software requirement description of the target controller is obtained, and the software requirement description includes functional requirements; secondly, the functional requirements are divided into multiple sub-functional requirements based on the software requirement description, and multiple independent functional modules are generated according to the multiple sub-functional requirements; again, the multiple independent functional modules are coded and tested based on the software requirement description, and the source code of each functional module that passes the test is generated; then, a traceability relationship is established between the source code of each functional module that passes the test and the software requirement description, and a requirement verification matrix is ​​constructed based on the traceability relationship; then, each functional module is verified through the requirement verification matrix; finally, when each functional module passes the module verification, the target controller software is verified as a whole.

[0056] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0057] See also Figure 1 , which is a flow chart of a controller software development method provided by an embodiment of the present application, such as Figure 1 As shown, the method comprises the following steps:

[0058] S101. Obtain software requirement description of a target controller.

[0059] In the embodiment of the present application, in order to develop the target controller software, firstly, the software requirement description of the target controller is obtained, and the software requirement description includes the functional requirements that the target controller software needs to implement.

[0060] In the embodiment of the present application, the software requirement description also includes external data interface, configuration parameters and execution process, etc.

[0061] In an example implementation, the target controller is an automotive electronic controller, and the corresponding software requirements include, but are not limited to, functional requirements such as engine control, transmission control, and brake system control; external data interfaces such as sensor input and actuator output; configuration parameters such as the controller's operating mode and parameter thresholds, and execution processes such as control logic and fault handling.

[0062] S102: Divide the functional requirement into multiple sub-functional requirements based on the software requirement description, and generate multiple independent functional modules according to the multiple sub-functional requirements.

[0063] In an embodiment of the present application, after clarifying the software requirement description, the functional requirements corresponding to the target controller are divided into multiple sub-functional requirements according to the software requirement description, and corresponding multiple independent functional modules are generated. The multiple independent functional modules together constitute the target controller software.

[0064] In an exemplary implementation, the functional requirements of the target controller software can be divided into five sub-functional requirements, namely, sub-functional requirement A, sub-functional requirement B, sub-functional requirement C, sub-functional requirement D, and sub-functional requirement E. Five corresponding functional modules are generated, namely, functional module A, functional module B, functional module C, functional module D, and functional module E.

[0065] Then the functional requirements of the target controller software can be expressed as:

[0066] Functional requirements = {function module A, function module B, function module C, function module D, function module E}.

[0067] Optionally, after generating multiple functional modules, the processing logic between the input functional information and the output functional information of the target controller software is determined. Taking the input function of the target controller software as I, the output function as O, and the input data as D as an example, the input functional information can be expressed as I＝f(D) , the output function information can be expressed as O=g(I).

[0068] Optionally, in order to ensure effective testing of the software in the subsequent development process, a state machine model may be used to represent the relationship between the input, processing, and output of each functional module.

[0069] In an example implementation, a functional module is defined as a state machine S, the processing process of the functional module is represented by the state transfer function T of the state machine S, the input of the functional module is represented by the input I of the state machine S, and the output of the functional module is represented by the output O of the state machine S. Then, the relationship between the input, processing and output of the functional module can be represented by the state transfer matrix O=T(S,I).

[0070] In the embodiment of the present application, by defining each functional module as a state machine, the logical relationship between input and output can be clearly described, ensuring that the interaction between the functional modules is accurately understood during the controller software development process.

[0071] S103, performing software coding and testing on multiple independent functional modules based on the software requirement description, and generating source code for each functional module that passes the test.

[0072] In the embodiment of the present application, software coding is performed on each functional module based on the software requirement description, and the functional requirements corresponding to each functional module are converted into computer executable codes.

[0073] After the coding is completed, each functional module is tested to ensure that each functional module can work normally according to the functional requirements.

[0074] After the test passes, the source code for each functional module that passes the test is generated.

[0075] S104: Construct a traceability relationship between the source code of each functional module that has passed the test and the software requirement description, and construct a requirement verification matrix based on the traceability relationship.

[0076] In the embodiment of the present application, the traceability relationship between the source code for constructing each functional module and passing the test and the software requirement description includes: the traceability relationship between the source code for constructing each functional module and passing the test and the software requirement information, input and output information, software flow information and software verification file. Among them, the software requirement information, input and output information, software flow information and software verification file are determined according to the software requirement description.

[0077] In the embodiment of the present application, the software requirement information includes a detailed description of the functions required by the target controller software, such as the processing logic of sensor data, the definition of input and output interfaces, etc. In the process of clarifying the software requirement information, the input data needs to be strictly defined to ensure that the format and type of the data meet the requirements of the target controller software. For example, for the input data of the temperature sensor, its data format is specified as a floating point number, and the value range is limited to between 0 and 100 degrees Celsius.

[0078] In the embodiment of the present application, in order to facilitate subsequent verification and testing, the input and output information can be standardized.

[0079] In one example implementation, the input interface may be represented as Iin , the output interface can be represented as O out The following model is used to describe the standardization requirements of input and output interface information:

[0080] Input interface information = {I in ,D,E};

[0081] Output interface information = {O out ,D out ,E}.

[0082] Where D is the input data, D out is the output data, and E is the fault type of input and output.

[0083] In an embodiment of the present application, the software process information can be described in the form of a flowchart or pseudo code to intuitively display the execution logic and data flow of the software.

[0084] In an exemplary implementation, a graphical tool is used to draw a complete flow chart of the target controller software from receiving sensor data to outputting control instructions.

[0085] In an embodiment of the present application, the software verification file includes test cases and verification standards to ensure that the software can continue to meet established requirements during the development process.

[0086] In an embodiment of the present application, the requirement verification matrix includes the software requirements of the target controller and the corresponding test cases. The requirement verification matrix can correspond the software requirements to the corresponding test cases one by one. The formula for constructing the requirement verification matrix is:

[0087] Verification matrix = {(N i ,T j )},

[0088] Among them, N i is the i-th software requirement of the target controller, T j is the jth test case corresponding to the ith software requirement.

[0089] S105. Perform module verification on each functional module through the requirement verification matrix.

[0090] In the embodiment of the present application, each functional module is verified by using the test cases in the constructed requirement verification matrix to ensure that its function meets the software requirement description.

[0091] S106: When each functional module passes the module verification, the target controller software is verified as a whole.

[0092] In the embodiment of the present application, when each functional module passes the module verification, the target controller software is verified as a whole to ensure that the coordination between the functional modules is normal.

[0093] In an example implementation, the automotive electronic controller software is checked as a whole to ensure that functions such as engine control, transmission control, and brake system control work together properly.

[0094] The embodiment of the present application realizes modular development by dividing the functional requirements of the target controller into multiple sub-functional requirements and generating corresponding functional modules, thereby reducing development complexity and improving development efficiency. At the same time, modular design also enhances flexibility and response speed when software requirements change, greatly reducing unnecessary rework time caused by changes in requirements. By constructing a traceability relationship between the source code and the software requirements description of each functional module that has passed the test, and establishing a requirements verification matrix, comprehensive coverage of the target controller software requirements is ensured, and each functional module undergoes a strict verification process, thereby improving the overall quality and stability of the controller software. At the same time, by establishing a requirements verification matrix, deviations can be discovered and corrected in a timely manner during the development process, ensuring the consistency of requirements during the development process, thereby significantly improving the accuracy and reliability of the controller software.

[0095] Next, we will explain in more detail how to develop controller software.

[0096] In an optional implementation, step S103 includes:

[0097] S1031. Based on the software requirement description, use a unified standard coding specification to perform software coding on the multiple independent functional modules.

[0098] In the embodiment of the present application, in order to ensure the consistency and readability of the code, a set of unified standard coding specifications is used to perform software coding on multiple independent functional modules.

[0099] In an example implementation, the Motor Industry Software Reliability Association C language coding standards (MISRA.C) or other code style guides can be used to define naming conventions, comment requirements, code structure, etc. to reduce the complexity of subsequent maintenance.

[0100] S1032. Perform compliance verification on the encoded software to obtain a verification result.

[0101] In the embodiment of the present application, compliance verification is to verify whether the encoded software complies with the aforementioned coding specifications.

[0102] In the embodiment of the present application, the compliance verification can be verified by a static code analysis tool, and the verification process is formulated as follows:

[0103] Verification result = f(code, specification).

[0104] If the verification result obtained is failed, that is, code items that do not comply with the coding specifications are found, then the process proceeds to step S1033; if the verification result obtained is passed, that is, code items that do not comply with the coding specifications are not found, then the process proceeds to step S1034.

[0105] S1033. Provide problem feedback and modify the code to form a new software version.

[0106] In the embodiment of the present application, the code items that do not conform to the coding specification are reported as problems, and the code is modified according to the problem feedback to ensure that the modified code conforms to the coding specification. The modified code is re-verified for compliance until the verification passes.

[0107] In the embodiment of the present application, each modified code will form a new software version.

[0108] S1034. Test the verified software.

[0109] In the embodiment of the present application, the version number of the verified software is V test . For V test Functional testing, software static scanning and regression testing are performed in sequence.

[0110] Functional testing verifies whether each functional module works normally as required. The formula for calculating the pass rate of functional testing is as follows:

[0111]

[0112] Among them, P f is the passing rate of the functional test, if P f <1, it means that there are functions that have not passed, and problem feedback and corresponding code modifications are required until the functional test results are qualified.

[0113] In the embodiment of the present application, after the functional test is qualified, static code scanning is performed. Static code analysis tools can be used to perform code review to identify potential defects and security vulnerabilities in the code.

[0114] In one example implementation, the defect density formula for evaluating static scanning is as follows:

[0115]

[0116] If the defect density exceeds a preset threshold (such as 10%), the code needs to be refactored and repaired to ensure the quality of the software.

[0117] In the embodiment of the present application, regression testing is performed on the software that passes the static scan. Regression testing is used to ensure that changes to the code do not affect the normal operation of the implemented functions.

[0118] In an exemplary implementation, the passing rate of the regression test is P r , then the calculation formula for the pass rate of the regression test is as follows:

[0119]

[0120] If P r <1, it means that there are use cases that have not passed the regression test, and problem feedback and corresponding code modifications are required until the regression test results are qualified.

[0121] In the embodiment of the present application, when the functional test, the software static scan and the regression test are all passed, the compatibility test is performed on the software that has passed the test.

[0122] Compatibility testing is a compatibility test between each functional module and the updated new version. It can be expressed by the following formula:

[0123] Compatibility test result = f(V upg ,V curr ),

[0124] Among them, V curr For the current version, V upg This is the upgraded version.

[0125] If the compatibility test fails, you need to provide problem feedback and make corresponding code modifications until the compatibility test passes.

[0126] In an example implementation, multiple functional modules divided from the target controller are encoded, and after the compliance verification is passed, a test version V1.0 is generated. When the test version is subjected to functional testing (or regression testing), functional module A fails the test, and the problem is fed back and the code is modified. After the modification, the functional test (or regression testing) is performed again. If all functional modules pass at this time, the version is upgraded to V1.1. After the version upgrade is completed, a compatibility test is performed to ensure the compatibility of the new version with the existing functions.

[0127] The embodiment of the present application performs a series of tests on the encoded software to ensure that the software implements the correct predetermined functions and that no new errors are introduced during the software update process.

[0128] S1035: Generate source code for each of the functional modules that passes the test.

[0129] In the embodiment of the present application, after each test is passed, source code of each functional module passing the test is generated. These source codes are part of the target controller software product finally delivered to the user and can be used for subsequent deployment, integration and maintenance.

[0130] In an optional implementation, in order to ensure compatibility and traceability between each version during the software development process, the controller software development method further includes:

[0131] Generate version management documents through version control algorithm.

[0132] In the embodiment of the present application, the version management document includes the content of each version change of the target controller software and the corresponding version number.

[0133] The current version number is V curr , the previous version number is V prev , then the relationship between versions is expressed as V curr =V prev +Δv, Δv is the change content of the version.

[0134] In an example implementation, the current version of the target controller software is V1.0, which has been modified several times during the development process to form versions such as V1.1, V1.2, and V1.3. The generated version management document is as follows:

[0135] Version number: V1.0

[0136] Description of changes: Initial version, including basic functions.

[0137] Version number: V1.1

[0138] Description of changes: Fixed the input interface I in To solve the compatibility issues, a new data processing module is added.

[0139] Version number: V1.2

[0140] Description of changes: Optimized the output interface O out The response time is shortened and the fault handling capability is enhanced.

[0141] Version number: V1.3

[0142] Description of changes: Based on user feedback, the stability of the signal interface has been improved and the data encryption function has been added.

[0143] …

[0144] The embodiment of the present application automatically generates version management documents through a version control algorithm, clearly records the changes of each version, facilitates effective management and control of software versions during the target controller software development process, reduces errors that may be caused when introducing new functions or modifying functions, and improves the quality of target controller software development. At the same time, when the new functions are unstable or there are risks, they can be quickly rolled back to a stable version to ensure the stability of the target controller software.

[0145] In an optional implementation, after step S104, the controller software development method further includes:

[0146] Identifies the target controller software with a unique product serial number.

[0147] In the embodiment of the present application, the product serial number uniquely indicates the target controller software and its corresponding version. The corresponding relationship between the product and the version can be expressed as the following formula:

[0148] C ij =f(P i ,V j ),

[0149] Among them, C ij is the jth version of the i-th target controller software, P i is the product serial number of the target controller, V j is the corresponding software version number.

[0150] Associate product serial numbers with software configuration management baselines.

[0151] In an embodiment of the present application, the software configuration management baseline includes detailed information of the software version, the developer's change history, and the results of test verification.

[0152] In the embodiment of the present application, each product serial number is associated with the corresponding software configuration management baseline so that the complete history and configuration information of the software can be quickly retrieved when needed. This can be achieved by establishing corresponding records or links in the software configuration management baseline system to ensure that each serial number can be traced back to its corresponding software version and development process.

[0153] In an optional implementation, step S106 includes:

[0154] S1061. Verify the version compatibility of the target controller software.

[0155] In an embodiment of the present application, the version compatibility of the target controller software is checked to check whether there are conflicts or errors in the input, output and execution processes between different versions.

[0156] In an example implementation, interfaces and functions of different versions may be compared through a compatibility check matrix, the construction formula of which is as follows:

[0157]

[0158] By analyzing the values ​​in the compatibility check matrix, you can quickly identify version compatibility issues and establish a problem feedback mechanism to ensure that each problem can be tracked and resolved.

[0159] Optionally, if the version compatibility check fails, a compatibility management strategy description and compatibility verification analysis table should be established for each version for subsequent tracking and resolution. The compatibility verification analysis table should include problem description, affected versions, solutions, and verification results, so that all problems can be effectively managed.

[0160] S1062. Perform a compliance check on the input and output of the target controller software that has passed the version compatibility check.

[0161] In an embodiment of the present application, the input of the target controller software that has passed the version compatibility check is verified, and the standardized description of all input data is formed into a data list. The data list includes the type, format, range of each input data and its corresponding relationship with the software function. The data list can be expressed as:

[0162] D i ={(I j ,T j ,R j )|j∈[1,n]}

[0163] Among them, D i is the data list corresponding to the i-th software function, I j is the type of the jth input data, T j is the format of the jth input data, R j is the range of the j-th input data.

[0164] The embodiment of the present application can ensure that all input data complies with the specifications through the data list, thereby reducing errors in the subsequent development process.

[0165] In addition, the validity of the input and output interface information is verified to ensure the standardization of the interface information.

[0166] In an example implementation, test cases are used to cover all possible inputs of the interface to ensure that the interface can work properly in various situations. The formula for interface validity verification is:

[0167]

[0168] In the embodiment of the present application, potential problems can be discovered in time and repaired through interface validity verification.

[0169] S1063. Perform an executability check and a correctness check on the execution code of the target controller software that has passed the compliance check.

[0170] In the embodiment of the present application, the executable code of the target controller software that has passed the compliance check can be checked for executableness and correctness by using static scanning technology.

[0171] In an example implementation, a code quality checking tool may be used to generate a defect report to identify potential problems and irregularities in the code. Multiple code quality indicators may be set, such as complexity, duplicate code, potential memory leaks, etc.

[0172] The indicator for executing code verification can be expressed as: Q = {C, D, M, R}.

[0173] Among them, Q is a set of evaluation indicators for code quality, C represents code complexity, D represents the number of code defects, M represents code repetition rate, and R represents memory usage rate.

[0174] In the embodiments of the present application, the quality of the code can be judged by analyzing these indicators. If problems are found during the executable verification and correctness verification, they need to be fed back and repaired to ensure the stability and reliability of each version of the software in actual applications.

[0175] In the embodiments of the present application, modular design is used to improve flexibility and response speed when requirements change, and reduce unnecessary rework time. By using version control algorithms to manage software versions, compatibility and traceability between each version are ensured, which fundamentally reduces the risk of potential defects. Through the establishment of a demand verification matrix, through comprehensive coverage of software requirements, input and output, and software process information, it is ensured that each functional module is strictly verified, thereby improving the overall quality and stability of the software.

[0176] Based on the controller software development method provided in the aforementioned embodiment, the present application also provides a controller software development system accordingly. Figure 2 A schematic diagram of the structure of a controller software development system provided in an embodiment of the present application. Figure 2 As shown, the controller software development system includes:

[0177] The software requirement acquisition module 201 is used to acquire the software requirement description of the target controller; the software requirement description includes the functional requirements that the target controller software needs to implement.

[0178] The function division module 202 is used to divide the function requirement into multiple sub-function requirements based on the software requirement description, and generate multiple independent function modules according to the multiple sub-function requirements; the multiple independent function modules together constitute the target controller software.

[0179] The coding and testing module 203 is used to perform software coding and testing on the multiple independent functional modules based on the software requirement description, and generate source code for each of the functional modules that passes the test.

[0180] The requirement verification matrix construction module 204 is used to construct a traceability relationship between the source code of each functional module that has passed the test and the software requirement description, and to construct a requirement verification matrix based on the traceability relationship; the requirement verification matrix includes the software requirements of the target controller and the corresponding test cases.

[0181] The first verification module 205 is used to perform module verification on each of the functional modules through the requirement verification matrix.

[0182] The second verification module 206 is used to perform overall verification on the target controller software when each of the functional modules passes the module verification.

[0183] The controller software development system of the embodiment of the present application realizes modular software development through the functional interaction of the software requirement acquisition module 201, the function division module 202, the coding test module 203, the requirement verification matrix construction module 204, the first verification module 205 and the second verification module 206, thereby reducing the development complexity and improving the development efficiency. At the same time, the flexibility and response speed when the software requirements are changed are also enhanced, and the unnecessary rework time caused by the change of requirements is greatly reduced. The traceability relationship between the source code and the software requirements description of each functional module through the requirement verification matrix construction module 204 is constructed, and the requirement verification matrix is ​​established to ensure the comprehensive coverage of the target controller software requirements. Each functional module undergoes a strict verification process, thereby improving the overall quality and stability of the controller software. At the same time, the requirement verification matrix established by the requirement verification matrix construction module 204 can timely discover and correct deviations during the development process, ensure the consistency of requirements during the development process, and thus significantly improve the accuracy and reliability of the controller software.

[0184] Optionally, the coding test module 203 includes:

[0185] A coding unit, configured to perform software coding on the plurality of independent functional modules using a unified standard coding specification based on the software requirement description;

[0186] A conformity verification unit, used to perform conformity verification on the encoded software to obtain a verification result;

[0187] The code modification unit is used to provide problem feedback and modify the code to form a new software version if the verification result is failed;

[0188] The test unit is used to test the verified software if the verification result is passed;

[0189] The source code generation unit is used to generate source code for each of the functional modules to pass the test.

[0190] Optionally, the test unit is specifically used for:

[0191] Performing functional testing, software static scanning and regression testing on the verified software in sequence;

[0192] When the functional test, software static scan and regression test are all passed, the compatibility test is performed on the passed software.

[0193] Optionally, the controller software development system further includes:

[0194] The version management module is used to generate a version management document through a version control algorithm. The version management document includes the content of each version change of the target controller software and the corresponding version number.

[0195] Optionally, the controller software development system further includes:

[0196] The identification module is used to identify a unique product serial number for the target controller software. The product serial number uniquely indicates the target controller software and its corresponding version.

[0197] The association module is used to associate the product serial number with the software configuration management baseline.

[0198] Optionally, the second verification module 206 is specifically used for:

[0199] Verifying the version compatibility of the target controller software;

[0200] Perform compliance check on the input and output of the target controller software that has passed the version compatibility check;

[0201] Perform executability and correctness checks on the execution code of the target controller software that has passed the compliance check.

[0202] In addition, an embodiment of the present application also provides a controller software development server, which includes a processor and a memory.

[0203] The memory is used to store computer program code and transmit the program code to the processor;

[0204] The processor is used to execute the steps of the controller software development method introduced in any of the above method embodiments according to the instructions in the program code.

[0205] In addition, an embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the program is executed by a processor, the controller software development method described in any of the method embodiments is implemented.

[0206] It should be noted that each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The system embodiment described above is merely schematic, in which the units described as separate components may or may not be physically separated, and the components indicated as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0207] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A controller software development method, characterized in that: The method comprises: Obtaining a software requirement description of a target controller; the software requirement description includes functional requirements that the target controller software needs to implement; Based on the software requirement description, the functional requirement is divided into a plurality of sub-functional requirements, and a plurality of independent functional modules are generated according to the plurality of sub-functional requirements; the plurality of independent functional modules together constitute the target controller software; Based on the software requirement description, software coding and testing are performed on the multiple independent functional modules to generate source code for each functional module that passes the test; Constructing a traceability relationship between the source code of each functional module that has passed the test and the software requirement description, and constructing a requirement verification matrix based on the traceability relationship; the requirement verification matrix includes the software requirements of the target controller and the corresponding test cases; Perform module verification on each of the functional modules through the requirement verification matrix; When each of the functional modules passes the module verification, the target controller software is verified as a whole.

2. The method according to claim 1, characterized in that The step of performing software coding and testing on the plurality of independent functional modules based on the software requirement description, and generating source code for each functional module that passes the test, comprises: Based on the software requirement description, a unified standard coding specification is used to perform software coding on the multiple independent functional modules; Conduct compliance verification on the coded software to obtain verification results; If the verification result is failed, feedback will be given and the code will be modified to form a new software version; If the verification result is passed, the verified software is tested; Generate source code for each of the functional modules to pass the test.

3. The method according to claim 2, characterized in that The testing of the verified software includes: Performing functional testing, software static scanning and regression testing on the verified software in sequence; When the functional test, software static scan and regression test are all passed, the compatibility test is performed on the passed software.

4. The method according to claim 1, characterized in that: The method further comprises: A version management document is generated through a version control algorithm; the version management document includes the content of each version change of the target controller software and the corresponding version number.

5. The method according to claim 1, characterized in that After constructing the traceability relationship between the source code of each functional module that has passed the test and the software requirement description, and constructing the requirement verification matrix based on the traceability relationship, the method further includes: Identify a unique product serial number for the target controller software; the product serial number uniquely indicates the target controller software and its corresponding version; The product serial number is associated with a software configuration management baseline.

6. The method according to claim 1, characterized in that The overall verification of the target controller software includes: Verifying the version compatibility of the target controller software; Perform compliance check on the input and output of the target controller software that has passed the version compatibility check; Perform executability and correctness checks on the execution code of the target controller software that has passed the compliance check.

7. A controller software development system, characterized in that: The system comprises: A software requirement acquisition module is used to acquire a software requirement description of a target controller; the software requirement description includes functional requirements that the target controller software needs to implement; A function division module, used for dividing the function requirement into a plurality of sub-function requirements based on the software requirement description, and generating a plurality of independent function modules according to the plurality of sub-function requirements; the plurality of independent function modules together constitute the target controller software; A coding and testing module, used to perform software coding and testing on the plurality of independent functional modules based on the software requirement description, and generate source code for each of the functional modules that passes the test; A requirement verification matrix construction module is used to construct a traceability relationship between the source code of each functional module that has passed the test and the software requirement description, and to construct a requirement verification matrix based on the traceability relationship; the requirement verification matrix includes the software requirements of the target controller and the corresponding test cases; A first verification module, used for performing module verification on each of the functional modules through the requirement verification matrix; The second verification module is used to perform overall verification on the target controller software when each of the functional modules passes the module verification.

8. The system according to claim 7, characterized in that The coding test module comprises: A coding unit, configured to perform software coding on the plurality of independent functional modules using a unified standard coding specification based on the software requirement description; A conformity verification unit, used to perform conformity verification on the encoded software to obtain a verification result; The code modification unit is used to provide problem feedback and modify the code to form a new software version if the verification result is failed; The test unit is used to test the verified software if the verification result is passed; The source code generation unit is used to generate source code for each of the functional modules to pass the test.

9. A controller software development server, characterized in that: The server comprises: a memory having a computer program stored thereon; A processor, configured to execute the computer program in the memory to implement the steps of the controller software development method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the controller software development method according to any one of claims 1 to 6 are implemented.

Images