Table-based equipment command design and analysis method and apparatus

Abstract

The invention discloses an equipment command design and analysis method and device based on a table, and the method comprises the steps: defining two types of table files: an overall function control table, and defining each function module and a corresponding equipment command group; defining a plurality of data input templates in different pages of the same table file according to the data configuration table of the single command group; designing device commands and parameters based on the defined two types of form files; and customizing an analysis tool for developing the table files, analyzing the two types of defined table files, ensuring that the input data meets the requirements, and generating a configuration file required by a back-end system according to the requirements of various service function logics. According to the method and the device, command design is realized on the basis of the table file, a configuration file is generated for a back-end system to use by assisting with a customized and developed analysis tool, and efficient management and control of key data of an equipment man-machine system are realized at relatively low research and development cost.

Description

Technical Field

[0001] The present invention relates to the field of design and development of large-scale equipment commands, and in particular to a method and device for designing and parsing equipment commands based on a table. Background Art

[0002] In the design and development of command line interface commands (referred to as device commands or commands in this invention) for human-machine data exchange through text terminals, the command development process of ordinary devices usually has only two steps: analyzing user input and command execution & report output. The command development process of large-scale equipment should have two steps: generating configuration files and analyzing configuration files. Figure 1 shown.

[0003] In the design and development of large-scale device commands, complex functions and a large number of device commands are designed. Some device commands have multiple formal parameters (formal parameters), and each formal parameter can also input multiple actual parameters (actual parameters) of different data types. The parameter combination of the command is quite complex. Device commands and parameters are usually managed in the form of text configuration files. In the scenario where a large number of commands and parameters are required, it is easy to cause frequent functional development errors, low efficiency and management confusion. Ultimately, it takes a huge cost to customize and develop a special tool set for data processing and management. Without proper strategy and tool support, it will have a serious impact on the smooth progress of R&D tasks. Summary of the invention

[0004] In order to solve the above-mentioned problems existing in the prior art, the present invention provides a method and device for table-based device command design and parsing, which implements device command design based on table files, and uses customized analysis tools to generate configuration files for use by the back-end system, thereby achieving efficient management and control of key data of the device human-machine system at a relatively low R&D cost.

[0005] To achieve the above object, the present invention adopts the following technical solutions:

[0006] In one embodiment of the present invention, a table-based device command design and parsing method is proposed, the method comprising:

[0007] Define two types of table files: overall function control table, which defines each function module and the corresponding device command group; data configuration table of a single command group, which defines multiple data input templates in different pages of the same table file; design device commands and parameters based on the two defined table files;

[0008] Customize and develop analysis tools for table files, analyze the two types of defined table files to ensure that the input data meets the requirements, and then generate the configuration files required by the back-end system according to the requirements of various business function logics.

[0009] Furthermore, the overall function control table defines the Chinese and English names of each function module, the command domain name and number, the command group name and Chinese and English descriptions, the starting value of the command identifier and the associated program name.

[0010] Furthermore, for each command group, a command group table file is created for designing the commands and parameters of the command group; a single command group table file is used to design the command list page, formal parameter list page, constant definition page, parameter type page, actual parameter list page and each human-machine command page.

[0011] Furthermore, in the design of parameter types, with the support of the backend system, various parameter types are customized according to functional requirements.

[0012] In one embodiment of the present invention, a table-based device command design and parsing device is also proposed, the device comprising:

[0013] The command table module is used to define two types of table files: the overall function control table, which defines each function module and the corresponding device command group; the data configuration table of a single command group, which defines multiple data input templates in different pages of the same table file; based on the two types of defined table files, the device commands and parameters are designed;

[0014] The tool generates a configuration file module, which is used to customize the analysis tool for developing table files. It analyzes the two types of defined table files to ensure that the input data meets the requirements, and then generates the configuration files required by the back-end system according to the requirements of various business function logics.

[0015] Furthermore, the overall function control table defines the Chinese and English names of each function module, the command domain name and number, the command group name and Chinese and English descriptions, the starting value of the command identifier and the associated program name.

[0016] Furthermore, for each command group, a command group table file is created for designing the commands and parameters of the command group; a single command group table file is used to design the command list page, formal parameter list page, constant definition page, parameter type page, actual parameter list page and each human-machine command page.

[0017] Furthermore, in the design of parameter types, with the support of the backend system, various parameter types are customized according to functional requirements.

[0018] In one embodiment of the present invention, a computer device is also proposed, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the aforementioned table-based device command design and parsing method is implemented.

[0019] In one embodiment of the present invention, a computer-readable storage medium is further provided, wherein the computer-readable storage medium stores a computer program for executing a table-based device command design and parsing method.

[0020] Beneficial effects:

[0021] 1. The present invention designs the overall function control table and the data configuration table of a single command group, and the design of the human-machine commands and parameters is grouped and layered, and certain data constraints are realized through the built-in data binding capabilities of the table. Each command group table file is designed with independent data pages such as constant definition page, formal parameter list page, actual parameter list page, parameter type page and human-machine command design page; when developers design, each page has clear functions, flexible adjustments and efficient management and control.

[0022] 2. The present invention fully considers the need for data compatibility during table design and tool analysis to improve the utilization of various types of data. For example, in response to the requirement of formal parameter sharing within the same command group, the formal parameters within the same command group are uniformly assigned formal parameter numbers, and different actual parameter combinations can be designed for the same formal parameters under different commands; when defining constants, all constants within the same command group are defined centrally, and duplicate constants are supported, and duplicate constants can point to different values ​​respectively.

[0023] 3. The design and implementation of the present invention are separated, and the parameter type is extensible. According to the functional requirements, various parameter types can be customized with the cooperation of the back-end system. The implementation of the parameter type does not need to be considered during the front-end design, and the back-end completes the functional implementation of the customized parameter type, and the design and implementation are completely separated.

[0024] 4. The analysis tool of the present invention realizes a powerful data verification capability and supports developers in designing commands and parameters. The analysis tool performs various syntax analyses, consistency checks and parameter dependency analyses on various types of data designed in the table file, and provides friendly prompts for the design errors found, ensuring that the data is correct and valid from the design level.

[0025] 5. The analysis tool of the present invention is easy to adjust and improve, making full use of powerful computing power to analyze various business function logics, form various required data, and instantly generate complex and complete configuration files for the back-end system; it completely avoids the problem of difficult control and maintenance of conventional file editing quality.

[0026] 6. The table file designed in the present invention also provides data input for the development of user manuals and online help; the analysis tool can also be expanded to provide flexible and adaptive data support for other application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is the development flow chart of device commands;

[0028] Figure 2 It is a flow chart of a method for designing and parsing table-based device commands of the present invention;

[0029] Figure 3 is a functional flow chart of the analysis tool custom developed by the present invention;

[0030] Figure 4 It is a schematic diagram of the structure of the device for designing and parsing table-based device commands of the present invention;

[0031] Figure 5 It is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0032] The principles and spirit of the present invention will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0033] Those skilled in the art will appreciate that the embodiments of the present invention may be implemented as a system, device, apparatus, method or computer program product. Therefore, the present disclosure may be specifically implemented in the following forms, namely: complete hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0034] According to an implementation manner of the present invention, a method and apparatus for designing and parsing device commands based on a table are proposed, which implement the design and management of commands and parameters based on a table file, and are supplemented by a customized analysis tool to implement data analysis and application strategies; each functional module is independently designed in a separate table file, and finally the analysis tool performs data integration to generate the configuration file required by the back-end system.

[0035] The principle and spirit of the present invention are explained in detail below with reference to several representative embodiments of the present invention.

[0036] Figure 2 1 is a flow chart of the method for designing and parsing table-based device commands of the present invention. Figure 2 As shown in the figure, this method is used in the development process of device commands ( Figure 1 ) adds two steps: command table and tool generation configuration file. The specific steps are as follows:

[0037] 1. Define two types of table files: the first type is the overall function control table, which defines each function module and the corresponding device command group; the second type is the data configuration table of a single command group, which defines multiple data input templates in different pages of the same table file. Developers can design device commands and parameters efficiently and controllably based on the two defined table files.

[0038] 2. In the design of device commands and parameters, not only can it support all common parameter types supported by XSD (XML structure definition), including simple types and complex types, but it can also support customized designed parameter types with the cooperation of the back-end system according to functional requirements, further improving the developer's design and the implementation of the back-end system.

[0039] 3. Customize and develop analysis tools for table files using computer programming languages, perform various syntax analyses, consistency checks, and parameter dependency analyses on various types of data designed in table files, and effectively help developers complete design work. The analysis tool generates the required data based on the requirements of various business function logics, and ultimately creates complex and complete configuration files for the back-end system.

[0040] It should be noted that, although the operations of the method of the present invention are described in a specific order in the above embodiments and the accompanying drawings, this does not require or imply that the operations must be performed in the specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0041] In order to explain the above table-based device command design and parsing method more clearly, a specific embodiment is used for illustration below. However, it should be noted that this embodiment is only for better illustrating the present invention and does not constitute an improper limitation to the present invention.

[0042] The device command consists of a command and parameters. The parameters consist of a parameter name and a parameter value. The parameter value can be composed of multiple parameter type values ​​connected by special characters. In the present invention, the parameter name is called a formal parameter, and the parameter type value is called an actual parameter.

[0043] The following are examples of device commands (in the following examples, the single character '&' is used as a connector for multiple parameter type values. Other special characters can also achieve the same effect):

[0044] CLI-111: PARAM01=2,PARAM02=2,PARAM09,PARAM17=3&3&ALL.

[0045] CLI-111: PARAM01=2, PARAM02=3, PARAM10=ABC, PARAM19, PARAM20=15, PARAM21=K'123.

[0046] After the user enters a device command on the operation terminal, the front-end program first performs a series of checks on the validity of the command and parameters, parameter type consistency, and parameter dependencies, and then transmits the command to the back-end program. The back-end program continues to perform command function analysis and data processing, forms a report with the processing results, and finally outputs the report to the user operation terminal to complete the command execution.

[0047] The present invention is in the development process of device command ( Figure 1 ) adds two steps, command table and tool generation configuration file, and creatively provides a method for designing and parsing device commands and parameters based on tables, such as Figure 2 As shown:

[0048] Command table section:

[0049] The present invention uses Microsoft's EXCEL file or WPS's XLS or XLSX worksheet and other table files as table carriers, making full use of the multi-page characteristics of such table files, and defining data templates adapted to different data input requirements on different pages of the same table file. In the practice of the present invention, EXCEL files are used for example description, and other table files can also be used without obvious differences. The present invention uses the following two types of table files:

[0050] The overall function control table defines each functional module and the corresponding device command group, and supports the flexible access of new command groups through data configuration.

[0051] The data configuration table of a single command group is designed to define constants, parameter types, formal parameter lists, actual parameter lists, independent parameter definitions for each human-machine command, and dependencies between parameters.

[0052] The specific steps to fill in the command form are as follows:

[0053] S101: Fill in the overall function control table to define the Chinese and English names of the function modules, the command domain name and number, the command group name and Chinese and English descriptions, the starting value of the command identifier, the associated program name and other configuration data; these data are explained as follows:

[0054] Functional modules (Module, Module-EN) define different functional units in the system, which are defined in Chinese and English respectively. Each functional module can be developed and maintained independently.

[0055] A command domain (AREA) is a functional subdivision in a functional module and is also an execution permission control unit;

[0056] A command group (CLI-Group) is a set of commands for creating, deleting, modifying and querying the same operation objects within a command domain, supporting the shared definition and use of data such as parameter types, formal parameters and actual parameters;

[0057] The command ID-StartValue is used to define the unique ID value used by all commands in the group for message communication between the two major program modules: the front-end user input and the back-end command execution. Sufficient intervals are reserved between the command ID-StartValues ​​set for each command group. Each command occupies two IDs, command sending and response receiving, respectively. The analysis tool automatically assigns a unique ID value to the two IDs of each command within the set ID value range.

[0058] The associated program name (Program) defines the corresponding program name of the command group in the backend command execution module, ensuring that each command group can independently develop functions and all commands in the same command group can be centrally designed and code shared.

[0059] An example of the overall function control table is shown in Table 1:

[0060] Table 1

[0061]

[0062] S102: For each command group, a command group table file is created to design the commands and parameters of the command group; fill in the individual command group table files in sequence, and execute the following S103-S110 respectively;

[0063] S103: Fill in the command list page of the specified command group table file, including data such as command number, command name, description, attributes and report number; these data are explained as follows:

[0064] Command number (CmdNbr) defines the command number. Users can use the command number instead of the command name when operating.

[0065] Command name (NAME) defines the command name and can be replaced with the command number;

[0066] Description (DESCRIPTION) defines the command description, which is used for command help;

[0067] Chinese description (DESCRIPTION_CN) defines the Chinese command description, which is used for Chinese help of the command;

[0068] ReadOnly defines the read and write properties of the command. The analysis tool can customize different data configurations for commands with different properties, and the subsequent command execution module can also be given different function settings; this type of command properties can be defined as needed;

[0069] The report number (ReportNbr) defines the number of the output report after the command is executed. It is used to match report templates, control report routing, and perform report analysis. The same command can trigger multiple reports with different report numbers.

[0070] An example of the command list page is shown in Table 2 below:

[0071] Table 2

[0072] CmdN NAME Description Description_CN ReadOnly ReportNbr 111 CLI-111 Description for CLI-111 Chinese Description 111 Y 3001,3002 112 CLI-112 Description for CLI-112 Chinese Description 112 N 3005

[0073] S104: The following steps continue to fill in other pages of the command group table file. On the parameter list page, fill in the parameter name, number and description used by this command group; the parameter number (NBR) defined in the present invention may be discontinuous to support keeping the command input method unchanged when the system is upgraded.

[0074] An example of the parameter list page is shown in Table 3 below:

[0075] Table 3

[0076] PARAMETER NBR DESCRIPTION DESCRIPTION_CN PARAM01 1 Description01 Chinese Description 01 PARAM02 2 Description02 Chinese Description 02 PARAM03 3 Description03 Chinese Description 03 PARAM04 34 Description04 Chinese Description 04 PARAM05 35 Description05 Chinese Description 05 PARAM06 36 Description06 Chinese Description 06 PARAM07 9 Description07 Chinese Description 07 PARAM08 10 Description08 Chinese Description 08

[0077] S105: On the constant definition page, fill in the constant name, constant value and Chinese and English description used by the command group; the constants defined in the present invention support the same name, and are distinguished by adding actual values ​​when the constants are used. See S106 for usage examples.

[0078] An example of a constant definition page is shown in Table 4 below:

[0079] Table 4

[0080] NAME VALUE DESCRIPTION DESCRIPTION_CN CONST01 Y Description01 Chinese Description 01 CONST02 N Description02 Chinese Description 02 CONST03 -1 Description03 Chinese Description 03 CONST04 0 Description04 Chinese Description 04 CONST05 1 Description05 Chinese Description 05 CONST04 2 Description06 Chinese Description 06 CONST05 3 Description07 Chinese Description 07 CONST08 254 Description08 Chinese Description 08 CONST09 255 Description09 Chinese Description 09 CONST10 ---- Description10 Chinese Description 10

[0081] S106: On the parameter type page, fill in the parameter type name and specific definition used by this command group; if the referenced constant has a duplicate name, you can directly specify the value corresponding to the constant after the constant, such as: "CONST04:2". If the specified definition value is not displayed, the analysis tool will specify the first definition value; this page can be customized and designed according to actual needs with the support of the backend program. The example is as follows:

[0082] Integer: integer type;

[0083] Char: character type;

[0084] Boolean: Boolean type;

[0085] String: string type;

[0086] Enum: enumeration type;

[0087] Char(x): String type with maximum length x;

[0088] Range(x,y): specifies the range as an integer type of xy;

[0089] RangeOrAll(x,y): Parameter type in the Range(x,y) format, and also supports the string ALL input format;

[0090] Interval(x,y): supports the parameter type of data range format (x&&y) and also supports the input format of RangeOrAll(x,y);

[0091] OctStr(x): a String type with a maximum length of x and containing only characters 0-7;

[0092] HexStr(x): a String of maximum length x containing only characters 0-9a-fA-F;

[0093] KeyNR: String type starting with K' and followed by characters 0-9a-eA-E;

[0094] DigitStr(x): a String type containing only digits with a maximum length of x;

[0095] Float(m,n): A floating-point number type with a maximum of m digits for the integer part and n digits for the decimal part.

[0096] An example of the parameter type page is shown in Table 5 below:

[0097] Table 5

[0098] TYPE DEFINITIONS T_ARGU01 Enum(CONST01,CONST02) T_ARGU02 Enum(CONST03,CONST04:2,CONST05:3) T_ARGU03 Char T_ARGU04 Char(16) T_ARGU05 String T_ARGU06 Integer T_ARGU07 Range(1:255) T_ARGU08 RangeOrAll(1:12) T_ARGU09 Interval(0:31) T_ARGU10 KeyNR

[0099] S107: On the parameter list page, fill in the parameter name, type and description used by this command group; these data are explained as follows:

[0100] ARGUMENT defines the name of the argument;

[0101] Type (TYPE) defines the parameter type. When filling in the data on the actual parameter list page, you can choose to automatically fill in the data after the parameter type defined on the parameter type page through the data binding relationship. If you fill in incorrect data manually, an error message will appear; different actual parameters can point to the same parameter type;

[0102] DESCRIPTION defines parameter description, which is used for command help;

[0103] Chinese description (DESCRIPTION_CN) defines the Chinese parameter description for command help.

[0104] An example of the actual parameter list page is shown in Table 6 below:

[0105] Table 6

[0106]

[0107]

[0108] S108: For each human-machine command, a page is created to design the formal parameters and actual parameters of the command, the mandatory requirements for parameter input, and the parameter dependency.

[0109] S109: On the first human-machine command design page, fill in the formal and actual parameters of the command, the mandatory requirements for parameter input, and the parameter dependency relationship; these data are explained as follows:

[0110] Parameter: defines the formal parameters allowed by the command. The parameter numbers are defined on the parameter list page. The parameters can be shared in the same command group, and the parameter numbers remain unchanged. In different commands, the same parameter can also be designed as different actual parameter combinations. When filling in the data on the command design page, you can choose to automatically fill in the data after the parameters defined on the parameter list page through the data binding relationship. If you fill in incorrect data manually, there will be an error prompt.

[0111] Mandatory (M / MO / O) parameter requirements: define the mandatory requirements for each parameter of the command: M is mandatory, MO is mandatory and O is optional. The default is optional. Mandatory parameters must be accompanied by actual parameters. If there are mandatory multiple parameters, there must be at least two.

[0112] Actual parameter quantity (ARG_NBR): defines the actual parameter quantity corresponding to the formal parameter, which can be 0, 1 or more;

[0113] Arguments: define the actual parameters corresponding to the formal parameters, and number them consecutively in the actual order; multiple actual parameters in a formal parameter can be the same; when filling in this data on the human-machine command design page, you can choose to automatically fill in the data after the actual parameters defined on the actual parameter list page through the data binding relationship. If you fill in incorrect data manually, there will be an error prompt;

[0114] Dependency between parameters (Required_AND, Required_OR, Must_NOT): Define the dependency between parameters: required, multiple, mutually exclusive; each parameter in the dependency table between parameters must be valid. If there are multiple dependent parameters, there must be at least two. A single parameter cannot appear multiple times in the three dependency tables of the same parameter. Mutually exclusive parameters must be paired.

[0115] An example of the human-machine command design page is shown in Table 7 below:

[0116] Table 7

[0117]

[0118] Step 110: On the second human-machine command design page, design the second human-machine command; until the design of all human-machine commands of the command group is completed.

[0119] Tool analysis section:

[0120] The customized analysis tool in the present invention will first analyze the two types of table files to ensure that the filled-in data meets various consistency requirements and data logic requirements, and give reasonable prompts for data that does not meet the requirements, to help developers design control tables for device commands and parameters; then the analysis tool will extract the table data and generate the configuration files required by the back-end program according to the requirements of various functional logics.

[0121] In the practice of the present invention, three data configuration files, namely XML, XSD and parameter dependency table, are generated. Other file formats can also be used to adapt to the backend program without substantial differences.

[0122] The functional flow of the analysis tool is as follows Figure 3 As shown:

[0123] The analysis tool execution steps are as follows:

[0124] S201: Analyze the overall function control table to check whether the data is complete and whether there is any conflict;

[0125] S202: Analyze the data configuration table of each single command group in turn, and execute the following S203-S219 respectively:

[0126] S203: Check whether the associated program name is defined, if not defined, terminate the data analysis of the command group;

[0127] S204: Check whether the table file of this group exists, and if it is not defined, terminate the data analysis of this command group;

[0128] S205: Analyze the command list page to ensure that the data is complete and there is no conflict between the command name and number;

[0129] S206: Analyze the parameter list page to ensure that the data is complete and there is no conflict between the parameter name and number;

[0130] S207: Analyze the constant definition page to ensure that the data is complete and that duplicate constant names are allowed;

[0131] S208: Analyze the parameter type page to ensure that the data is complete and there is no conflict in the parameter type;

[0132] S209: Analyze the actual parameter list page to ensure that the data is complete, there is no conflict in the actual parameter names, and different actual parameters can point to the same parameter type;

[0133] S210: Analyze each human-machine command design page in turn, and execute the following S211-S219 respectively:

[0134] S211: Analyze the human-machine command design page to ensure that the data is complete and there is no conflict between the various data, including but not limited to the following rules:

[0135] Requirements for single parameter design: formal parameters and actual parameters must be valid and non-repetitive, and the actual parameter numbers under the same formal parameter must be continuous;

[0136] Mandatory parameter requirements: Mandatory parameters must have actual parameters. If there are mandatory multiple-choice parameters, there must be at least two.

[0137] Requirements for dependency relationships between parameters: Each parameter in the dependency relationship table between parameters must be valid. If there are multiple dependent parameters, there must be at least two. A single parameter cannot appear multiple times in the three dependency relationship tables of the same parameter. Mutually exclusive parameters must be paired.

[0138] If any parameter design does not comply with these rules, the analysis script will terminate the data analysis and give a clear error prompt until the developer completes the correct command and parameter design and passes the analysis script check;

[0139] S212: The analysis script starts data generation. First, an operation request node is generated. The node includes two sub-nodes: command sending (Output name = "cli-111_program") and response receiving (Input name = "cli-111_rps"). The command sending sub-node is configured with the backend processing program name of the command, the command sending identifier, and the sub-nodes of each parameter of the command; an example is as follows:

[0140] <Operationname="cli-111_program">

[0141] <output name＝"cli-111_program"port＝"moss"type＝"t_cli-111_program">

[0142] <programclass> Program11< / programclass>

[0143] <programreqcommand>

[0144] <xsl:value-of select="CLI_111_REQ" / >

[0145] < / programreqcommand>

[0146] <param01>

[0147] <xsl:value-of select=" / cli-111 / PARAM01" / >

[0148]

[0149] <param02>

[0150] <xsl:value-of select=" / cli-111 / PARAM02" / >

[0151]

[0152] <xsl:iftest=" / cli-111 / PARAM03">

[0153] <param03>

[0154] <xsl:value-of select=" / cli-111 / PARAM03" / >

[0155] ... ...

[0158] < / output>

[0159] <Inputname="cli-111_rsp"port="Moss"type="T_cli-111_rsp" / >

[0160]

[0161] S213: Generate an operation return node, define the format of the return report body, including the automatically configured input parameter echo and the report body returned by the backend program, as shown in the following example:

[0162] <Operation name="cli-111_report">

[0163] <Outputname="cli-111_report"port="TERM"type="string">

[0164]

[0165] PARAM01:

[0166] <xsl:value-of select=" / cli-111 / PARAM01" / >

[0167]

[0168] PARAM02:

[0169] <xsl:value-of select=" / cli-111 / PARAM02" / >

[0170]

[0171] <xsl:iftest=" / cli-111 / PARAM03">

[0172] PARAM03:

[0173] <xsl:value-of select=" / cli-111 / PARAM03" / >

[0174] ... ...

[0177] <xsl:value-ofselect=" / cli-111 / cli-111_program / cli-111_rsp / REPORT" / >

[0178]

[0179]

[0180]

[0181] S214: Generate a command node, including an operation request node and an operation return node, and define attributes of the command node, such as area, area number, description, number, command name, and type. An example is as follows:

[0182] <command area＝"AREA1"areaid＝"1"desc＝"Description for CLI-111"id＝"111"name＝"cli-111"type＝"T_cli-111_cmd">

[0183] <Operation name="cli-111_program">

[0184] <output name＝"cli-111_program"port＝"moss"type＝"t_cli-111_program">

[0185] <programclass> Program11< / programclass>

[0186] <programreqcommand>

[0187] <xsl:value-of select="CLI_111_REQ" / >

[0188] < / programreqcommand>

[0189] <param01>

[0190] <xsl:value-of select=" / cli-111 / PARAM01" / >

[0191] ... ...

[0194] < / output>

[0195] <input name＝"cli-111_rsp"port＝"Moss"type＝"T_cli-111_rsp">

[0196]

[0197] <Operation name="cli-111_report">

[0198] <Outputname="cli-111_report"port="TERM"type="string">

[0199]

[0200] PARAM01:

[0201] <xsl:value-of select=" / cli-111 / PARAM01" / >

[0202] ... ...

[0205] <xsl:value-ofselect=" / cli-111 / cli-111_program / cli-111_rsp / REPORT" / >

[0206]

[0207]

[0208]

[0209]

[0210] S215: Generate nodes for data definition of each enumeration type, as shown in the following example:

[0211] <xs:simpleType name="T_AREA1_GROUP11_ARGU02_A">

[0212] <xs:restriction base="xs:Integer">

[0213] <xs:emeration name="CONST03"value="-1" / >

[0214] <xs:emeration name="CONST04"value="2" / >

[0215] <xs:emeration name="CONST05"value="3" / >

[0216]

[0217]

[0218] S216: Generate nodes for each parameter definition. Multiple actual parameters of the same data type are supported in a single formal parameter. The built-in formal parameter names in this scenario are extended to avoid possible data conflicts. The example is as follows:

[0219] <xs:complexType name="T_AREA1_GROUP11_PARAM10">

[0220] <xs:element desc="Description03"id="1"name="ARGU031"type="xs:String" / >

[0221] <xs:element desc="Description03"id="2"name="ARGU032"type="xs:String" / >

[0222] <xs:element desc="Description03"id="3"name="ARGU033"type="xs:String" / >

[0223] <xs:element desc="Description05"id="4"name="ARGU05"type="xs:String" / >

[0224]

[0225] S217: Generate a node for the command parameter list, an example is as follows:

[0226] <xs:complexType name="T_cli-111_cmd">

[0227] <xs:element desc="Description01"id="1"name="PARAM01"type="xs:T_AREA1_GROUP11_PARAM01" / >

[0228] <xs:element desc="Description02"id="2"name="PARAM02"type="xs:T_AREA1_GROUP11_PARAM02" / >

[0229] <xs:element desc="Description03"id="3"name="PARAM03"type="xs:NULL" / >

[0230] <xs:element desc="Description06"id="36"name="PARAM06"type="xs:T_AREA1_GROUP11_PARAM06" / >

[0231] <xs:element desc="Description09"id="9"name="PARAM09"type="xs:NULL" / >

[0232] <xs:element desc="Description10"id="10"name="PARAM10"type="xs:T_AREA1_GROUP11_PARAM10" / >

[0233] <xs:element desc="Description14"id="14"name="PARAM14"type="xs:T_AREA1_GROUP11_PARAM14" / >

[0234] <xs:element desc="Description17"id="17"name="PARAM17"type="xs:T_AREA1_GROUP11_PARAM17" / >

[0235] <xs:element desc="Description19"id="39"name="PARAM19"type="xs:NULL" / >

[0236] <xs:element desc="Description20"id="40"name="PARAM20"type="xs:T_AREA1_GROUP11_PARAM20" / >

[0237] <xs:element desc="Description21"id="21"name="PARAM21"type="xs:T_AREA1_GROUP11_PARAM21" / >

[0238]

[0239] S218: Generate a node for the structure definition of the response data. The example is as follows:

[0240] <xs:complexType name="T_cli-111_rsp">

[0241] <xs:element id="1"name="REPORT"type="xs:String" / >

[0242]

[0243] S219: Generate parameter dependency data of a single command, represented by an N*N matrix diagram, where mutually exclusive parameters must appear in pairs; the description is as follows:

[0244] Diagonal line (upper left ←→ lower right): defines the mandatory requirements of the command for the parameters:

[0245] 0: Mandatory;

[0246] 1: Mandatory-Optional;

[0247] 2: Optional;

[0248] Horizontal line: defines the dependency between parameters. The numbers in the ith row represent the dependency requirements of the ith parameter on other parameters:

[0249] 3: Required-AND;

[0250] 4: Multiple choice (Required-OR);

[0251] 5: Mutually exclusive (Must-NOT);

[0252] 6: NotDefined;

[0253] The parameter dependency table will be saved in the parameter dependency configuration file. The example is as follows:

[0254] 111 <--Command number

[0255] CLI-111 <--Command name

[0256] 11 <--Parameter quantity 03666666666 30666666666 64246666666 66616543465 66661666666 66656145433 66666626666 66666562666 66666666266 66666666626 66656666662

[0268] S220: Generate nodes for all command request identifiers and response identifiers. The analysis tool automatically allocates them according to the rules. An example is as follows:

[0269] <xs:simpleType name="ProgramCommand">

[0270] <xs:restriction base="xs:Integer">

[0271] <xs:emeration name="CLI_111_REQ"value="1000" / >

[0272] <xs:emeration name="CLI_111_RSP"value="1001" / >

[0273] <xs:emeration name="CLI_112_REQ"value="1002" / >

[0274] <xs:emeration name="CLI_112_RSP"value="1003" / >

[0275] <xs:emeration name="CLI_411_REQ"value="2001" / >

[0276] <xs:emeration name="CLI_411_RSP"value="2002" / >

[0277] <xs:emeration name="CLI_412_REQ"value="2003" / >

[0278] <xs:emeration name="CLI_412_RSP"value="2004" / >

[0279]

[0280]

[0281] S221: Generate nodes of program names and serial numbers associated with all command groups, as shown in the following example:

[0282] <xs:simpleType name="MossIndex">

[0283] <xs:restriction base="xs:Integer">

[0284] <xs:emeration name="Program11"value="0" / >

[0285] <xs:emeration name="Program12"value="1" / >

[0286] <xs:emeration name="Program13"value="2" / >

[0287] <xs:emeration name="Program14"value="3" / >

[0288] <xs:emeration name="Program15"value="4" / >

[0289] <xs:emeration name="Program16"value="5" / >

[0290] <xs:emeration name="Program21"value="6" / >

[0291] <xs:emeration name="Program41"value="7" / >

[0292] <xs:emeration name="Program42"value="8" / >

[0293] <xs:emeration name="Program43"value="9" / >

[0294] <xs:emeration name="Program44"value="10" / >

[0295]

[0296]

[0297] S222: Generate device commands to exchange data with backend processing programs, user operation terminals, and internal databases, which are MossReq / MossResp, TermReq / TermResp, and DbReq / DbResp, respectively. The examples are as follows:

[0298] <xs:complexType name="CommonRsp">

[0299] <xs:element name="responsType"type="xs:integer" / >

[0300] <xs:element name="errorCode"type="xs:integer" / >

[0301] <xs:element name="description"type="xs:String" / >

[0302]

[0303] <xs:complexType name="MossReq">

[0304] <xs:element name="programClass"type="MossIndex" / >

[0305] <xs:element name="programReqCommand"type="ProgramCommand" / >

[0306]

[0307] <xs:simpleType name="MossResp">

[0308] <xs:restriction base="CommonRsp" / >

[0309]

[0310] <xs:simpleType name="TermReq">

[0311] <xs:restriction base="xs:String" / >

[0312]

[0313] <xs:simpleType name="TermResp">

[0314] <xs:restriction base="xs:String" / >

[0315]

[0316] <xs:complexType name="DbReq">

[0317] <xs:element default="???"name="username"type="xs:String" / >

[0318] <xs:element default="???"name="passwd"type="xs:String" / >

[0319]

[0320] <xs:simpleType name="DbResp">

[0321] <xs:restriction base="CommonRsp" / >

[0322]

[0323] S223: Finally, all node data are aggregated and saved to XML and XSD configuration files to complete data processing.

[0324] Based on the same inventive concept, the present invention also proposes a device for designing and parsing device commands based on a table. The implementation of the device can refer to the implementation of the above method, and the repeated parts will not be repeated. The term "module" used below can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0325] Figure 4 Schematic diagram of the device structure of the present invention based on table device command design and analysis. Figure 4 As shown, the device comprises:

[0326] The command table module 301 is used to define two types of table files: an overall function control table, which defines each function module and the corresponding device command group; a data configuration table of a single command group, which defines multiple data input templates in different pages of the same table file; based on the defined two types of table files, the device commands and parameters are designed;

[0327] The overall function control table defines the Chinese and English names of each function module, the command domain name and number, the command group name and Chinese and English descriptions, the starting value of the command identifier and the associated program name;

[0328] For each command group, create a command group table file to design the commands and parameters of the command group; for a single command group table file, design the command list page, formal parameter list page, constant definition page, parameter type page, actual parameter list page and each human-machine command page;

[0329] In the design of parameter types, with the support of the back-end system, various parameter types are customized according to functional requirements.

[0330] The tool generates a configuration file module 302, which is used to customize the analysis tool of the developed table file, analyze the two types of defined table files to ensure that the input data meets the requirements, and then generate the configuration file required by the back-end system according to the requirements of various business function logics.

[0331] It should be noted that although several modules of the apparatus for table-based device command design and parsing are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to an embodiment of the present invention, the features and functions of two or more modules described above can be embodied in one module. Conversely, the features and functions of one module described above can be further divided into multiple modules for embodiment.

[0332] Based on the above invention concept, Figure 5As shown, the present invention also proposes a computer device 400, including a memory 410, a processor 420, and a computer program 430 stored in the memory 410 and executable on the processor 420. When the processor 420 executes the computer program 430, the aforementioned table-based device command design and parsing method is implemented.

[0333] Based on the aforementioned inventive concept, the present invention further proposes a computer-readable storage medium, which stores a computer program for executing the aforementioned table-based device command design and parsing method.

[0334] The English names and abbreviations involved in the present invention are explained in Table 8 below:

[0335] Table 8

[0336]

[0337]

[0338] The method and device for table-based device command design and parsing proposed in the present invention implement command design based on table files, and use customized analysis tools to generate configuration files for use by back-end systems, thereby achieving efficient management and control of key data of the device human-machine system at a relatively low R&D cost.

[0339] Although the spirit and principle of the present invention have been described with reference to several specific embodiments, it should be understood that the present invention is not limited to the disclosed specific embodiments, and the division of various aspects does not mean that the features in these aspects cannot be combined to benefit, and such division is only for the convenience of expression. The present invention is intended to cover various modifications and equivalent arrangements contained in the spirit and scope of the attached claims.

[0340] Regarding the limitation of the protection scope of the present invention, those skilled in the art should understand that, based on the technical solution of the present invention, various modifications or variations that can be made by those skilled in the art without creative work are still within the protection scope of the present invention.

Claims

1. A method for designing and parsing device commands based on a table, characterized in that: The method includes: Define two types of table files: overall function control table, which defines each function module and the corresponding device command group; data configuration table of a single command group, which defines multiple data input templates in different pages of the same table file; design device commands and parameters based on the two defined table files; Customize and develop analysis tools for table files, analyze the two types of defined table files to ensure that the input data meets the requirements, and then generate the configuration files required by the back-end system according to the requirements of various business function logics.

2. The method for designing and parsing device commands based on a table according to claim 1, characterized in that: The overall function control table defines the Chinese and English names of each function module, the command domain name and number, the command group name and Chinese and English descriptions, the starting value of the command identifier and the associated program name.

3. The method for designing and parsing device commands based on a table according to claim 1, characterized in that: For each command group, create a command group table file to design the commands and parameters of the command group; for a single command group table file, design the command list page, formal parameter list page, constant definition page, parameter type page, actual parameter list page and each human-machine command page.

4. The method for designing and parsing device commands based on a table according to claim 3, characterized in that: In the design of parameter types, with the support of the back-end system, various parameter types are customized according to functional requirements.

5. A device for designing and parsing device commands based on a table, characterized in that: The device includes: The command table module is used to define two types of table files: the overall function control table, which defines each function module and the corresponding device command group; the data configuration table of a single command group, which defines multiple data input templates in different pages of the same table file; based on the two types of defined table files, the device commands and parameters are designed; The tool generates a configuration file module, which is used to customize the analysis tool for developing table files. It analyzes the two types of defined table files to ensure that the input data meets the requirements, and then generates the configuration files required by the back-end system according to the requirements of various business function logics.

6. The device for designing and parsing device commands based on a table according to claim 5, characterized in that: The overall function control table defines the Chinese and English names of each function module, the command domain name and number, the command group name and Chinese and English descriptions, the starting value of the command identifier and the associated program name.

7. The device for designing and parsing device commands based on a table according to claim 5, characterized in that: For each command group, create a command group table file to design the commands and parameters of the command group; for a single command group table file, design the command list page, formal parameter list page, constant definition page, parameter type page, actual parameter list page and each human-machine command page.

8. The device for designing and parsing device commands based on a table according to claim 7, characterized in that: In the design of parameter types, with the support of the back-end system, various parameter types are customized according to functional requirements.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 4 is implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program for executing the method according to any one of claims 1 to 4.

Images