Device model data generation method based on markup language, electronic device and storage medium

Abstract

The invention discloses a markup language-based equipment model data generation method, electronic equipment and a storage medium. The method comprises the following steps: defining an equipment model data generation rule through a Json script; parameter data are input by the manufacturing equipment; and generating, outputting and verifying the equipment model data according to the equipment model data generation rule and the equipment input parameter data. According to the invention, the design flexibility of a real-time data platform is greatly improved, and the efficiency of a data preparation stage is improved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a method for generating device model data based on a markup language for a smart city rail transit system, an electronic device and a storage medium. Background Art

[0002] The smart city rail transit system uses a unified software and hardware platform to bring together real-time data from multiple disciplines, including the signal system (ATS), power supply system (PSCADA), environment and equipment monitoring system (BAS), access control system (ACS), fire alarm system (FAS), ticket sales and inspection system (AFC), broadcasting system (PA), passenger guidance system (PIS), closed-circuit television system (CCTV), etc., to achieve a high degree of information integration and achieve comprehensive system coordination and linkage.

[0003] Based on this requirement, the smart city rail transit system usually needs to configure and define different systems and equipment data of different professions, which will bring many problems in the configuration process. First, the basic parameters and dynamic attributes of data of each profession are often different, and the data types are complicated and diverse, and it is impossible to unify all information into a few pre-defined data table structures; second, the parameters of various professional equipment are required to be added or modified at any time as the system construction and development and functional requirements change; third, although the data definitions of the same type of equipment in the same profession in different project implementations are generally consistent, the attributes will still differ to varying degrees. The traditional device data configuration method is usually carried out through one or more development tools based on relational library design, which disperses the data belonging to the same device into multiple tables for storage, and even stores the device attributes separately according to the data type to meet the storage requirements. This design will lead to a complex database structure, increase the difficulty of querying device attributes, and thus reduce the efficiency of concurrent data processing. Therefore, in order to reduce the design difficulty, the relationship between devices is often simplified. In addition, the device model definition is often a built-in configuration tool, so if the data definition needs to be modified, the tool needs to be recoded, which is not conducive to the upgrade and transformation of the device model. Summary of the invention

[0004] The purpose of the present invention is to provide a device model data generation method, electronic device and storage medium based on markup language for smart city rail transit systems, so as to greatly enhance the design flexibility of the real-time data platform and improve the efficiency of the data preparation stage.

[0005] In order to achieve the above objectives, the present invention is implemented by the following technical solutions:

[0006] A device model data generation method based on markup language, applied in a smart city rail transit system, comprises:

[0007] Define the device model data generation rules through Json script;

[0008] Make equipment input parameter data;

[0009] The device model data is generated, output and verified according to the device model data generation rule and the device input parameter data.

[0010] Optionally, the step of defining device model data generation rules through Json script includes: defining generation rules for basic attribute data, data generation rules for device types, generation rules for project-specific device data through Json script, and defining the data generation process according to project requirements.

[0011] Optionally, the step of defining the generation rule of basic attribute data by using a Json script includes:

[0012] Use Json script to define the common properties and generation rules of several basic quantities. Each basic quantity includes at least: a structure description domain node, a type domain node and a value domain node. The structure description domain node defines the data structure of the basic quantity; the type domain node defines the parent type of the basic type, which is used to inherit the generation rules of the parent type; the value domain node defines the generation rules of the data attributes of the basic quantity.

[0013] Optionally, the data structure definition of the basic quantity includes at least: Key attribute: defines the keyword of the basic quantity as a global index; Name attribute defines the name of the basic quantity, the basic quantity in the same device is guaranteed to be unique, and can be searched in the device through the Name attribute; Type attribute defines the type of the basic quantity, which can be used for inspection; Description attribute describes the function and use of the basic quantity, which can be used to splice alarm text.

[0014] Optionally, the basic quantities include: input quantities, control quantities and relationship quantities.

[0015] Optionally, use a Json script to define the properties of the device containing the input quantity and define the corresponding generation rules according to the properties of the device;

[0016] The types of input quantities include digital quantity, polymorphic digital quantity, digital quantity with timestamp, long integer, string and analog quantity;

[0017] Each input quantity can define a parent type. The generation rules of the input quantity attributes can directly inherit the generation rules of the parent type, or redefine the rules to cover the rule definition corresponding to the parent type.

[0018] Optionally, use the Json script to define the properties of the device containing the control quantity and define the corresponding generation rules according to the properties of the device;

[0019] Among them, the types of control quantities include dynamic attribute update quantity, switch control quantity and analog quantity control;

[0020] Each control quantity can define a parent type. The generation rules of the control quantity attributes can directly inherit the generation rules of the parent type, or redefine the rules to cover the rule definition corresponding to the parent type.

[0021] Optionally, use Json script to define the properties of the possible associated quantities between devices and define corresponding generation rules according to the properties of the devices;

[0022] Among them, the types of association quantities that may exist between devices include: fixed relationship, switch relationship, selection relationship, cluster relationship, set relationship and multi-set relationship. These relationships can be used to describe one-to-one, one-to-many static or dynamic relationships between devices;

[0023] Each associated quantity can define a parent type. The generation rules of the associated quantity attributes can directly inherit the generation rules of the parent class, or redefine the rules to cover the rule definition corresponding to the parent type.

[0024] Optionally, the step of generating a rule for data of the device type includes:

[0025] Define the attribute parameters and generation rules of the included equipment types according to project requirements;

[0026] The attribute data generation rules for defining the device type mainly include: structure description domain node, parent device domain node, type domain node, processing process domain node, temporary variable domain node and value domain node;

[0027] Among them, the structure description domain node defines the data structure name of the device type; the parent device domain node describes the parent device name of the device; the type domain node defines the parent type and can directly inherit the generation rules defined by the parent type; the value domain node is used to describe the specific generation rules of the device type attribute data;

[0028] Among them, the processing domain node defines the processing operation sequence, and the temporary variable domain node defines the temporary variable table. Both domain nodes are temporary intermediate processes for data generation and are used to assist the value domain node rule definition in outputting data;

[0029] Among them, the processing domain node, temporary variable domain node and value domain node can define and execute built-in functions and reference parameter variables.

[0030] Optionally, define the generation rules of input quantities, control quantities, associated quantities and sub-equipment of the equipment type;

[0031] All input quantities are defined according to the input quantity domain node. Each input quantity mainly defines a name domain node, a description domain node, an input parameter domain node, a value domain node, a processing function domain node and a type domain node. Then the input quantity can be generated according to the rules defined in the type domain node.

[0032] All control quantities are defined according to the control quantity domain node. Each control quantity mainly defines the name domain node, description domain node, value domain node, type domain node and control value parameter. Then the output quantity can be generated according to the rules defined in the type domain node.

[0033] All associated quantities between devices are defined according to the associated quantity domain node. Each associated quantity mainly defines a name domain node, an associated device domain node, an associated quantity name domain node, a related device name domain node, a related device attribute name domain node, a value domain node, and a type domain node. Then, the associated quantity can be generated according to the rules defined in the type domain node.

[0034] Domain node sub-device domain node defines all sub-devices of the device. Each sub-device mainly defines the name domain node, description domain node, value domain node and type domain node. Then the device can be generated according to the rules defined by the type domain node.

[0035] Optionally, the device type includes actual devices and virtual devices.

[0036] Optionally, the step of defining project-specific equipment data generation rules includes:

[0037] According to the actual requirements of the project, the generation rules of specific equipment can be defined;

[0038] The data generation rules for a specific device are defined, mainly including: structure description domain node, parent device domain node, type domain node, processing process domain node, temporary variable domain node and value domain node;

[0039] Among them, the structure description domain node defines the data structure name of the device type; the parent device domain node describes the parent device name; the type domain node defines the parent type of the basic type and can directly inherit the generation rules defined by the parent type; the value domain node is used to describe the generation rules of the device type attribute data;

[0040] Among them, the processing process domain node defines the processing operation sequence, and the temporary variable domain node defines the temporary variable table. Both domain nodes are temporary intermediate processes for data generation and are used to assist the definition of value domain node rules;

[0041] Among them, the processing domain node, temporary variable domain node and value domain node can define and execute built-in functions and reference parameter variables;

[0042] Then, define the generation rules of input quantity, control quantity, associated quantity and sub-equipment of specific equipment;

[0043] All input quantities are defined through input quantity domain nodes. Each input quantity mainly defines a name domain node, a description domain node, an input parameter domain node, a value domain node, a processing function domain node, and a type domain node. Then, the input quantity can be generated according to the rules defined in the type domain node.

[0044] All control quantities are defined through the control quantity domain node. Each control quantity mainly defines the name domain node, description domain node, value domain node, type domain node and control value parameter domain node. Then the output quantity can be generated according to the rules defined by the type.

[0045] All associated quantities between devices are defined through associated quantity domain nodes. Each associated quantity mainly defines name domain nodes, associated device domain nodes, associated quantity name domain nodes, related device name domain nodes, related device attribute name domain nodes, value domain nodes and type domain nodes. Then, associated quantities can be generated through the rules defined in the type domain nodes.

[0046] All sub-devices belonging to the device are defined through the sub-device domain node. Each sub-device mainly defines the name domain node, description domain node, value domain node and type domain node. Then the device can be generated according to the rules defined by the type.

[0047] Optionally, the step of defining a data generation process according to project requirements includes:

[0048] Define the steps for generating equipment data for each system and each specialty, and define the specific data generation execution process through process domain nodes;

[0049] Alternatively, you can combine multiple professional device data generation steps for multiple systems in batch mode and then define execution commands through Launch: Progress.

[0050] Optionally, the step of making device input parameter data includes:

[0051] Define the equipment parameter data input template according to the structure description domain node of the equipment type;

[0052] Enter the static parameter data of all devices according to the template of the actual project.

[0053] Optionally,

[0054] The step of generating, verifying and implementing the device model data according to the device model data generation rule and the device input static parameter data comprises:

[0055] Load all device generation rule definitions and generation process instruction sets;

[0056] Execute the command defined by Launch:Progress, read the corresponding parameter data as required, and execute the corresponding device generation rules to generate the corresponding device data, including static data, dynamic data, associated data, sub-device data, and other data required for specific projects;

[0057] Verify the generated data according to the structural description domain nodes;

[0058] Output device data to the corresponding database or specified file.

[0059] On the other hand, the present invention further provides an electronic device, including a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the method described above is implemented.

[0060] In other aspects, the present invention further provides a readable storage medium, wherein the readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described above is implemented.

[0061] The present invention has at least the following technical effects:

[0062] The present invention uses a Json format script to define device attributes and association relationships, fully utilizing the readability and maintainability of the Json format, and improving the efficiency of device model data production.

[0063] The present invention defines basic quantity definition, equipment type definition and equipment definition in a hierarchical manner, so that equipment data can be inherited or overwritten and updated. In this way, new equipment types and equipment attributes can be added without changing the existing design, thereby improving the reusability of data rule definition and increasing the flexibility of data production.

[0064] The present invention can define device attribute data in the configuration rule definition, and can also import external input data file definition, and flexibly formulate the data configuration process according to actual conditions.

[0065] The present invention performs universal design on the device attribute definition, and defines the relevant dynamic attributes through the device model, so as to ensure that a type of devices have exactly the same attributes, and can be modified as a whole according to the device category, thus simplifying the input data production process.

[0066] The present invention defines a clear structural description of the data model, and after the data is generated, the data can be checked for consistency, thus ensuring the legitimacy and availability of the data;

[0067] The present invention standardizes project input data, refines and clarifies the data preparation process according to the characteristics of the smart city rail transit system, and simplifies the input data production process (generating a corresponding csv file as data production input). BRIEF DESCRIPTION OF THE DRAWINGS

[0068] Figure 1 A schematic diagram of a flow chart of a method for generating device model data based on a markup language according to an embodiment of the present invention;

[0069] Figure 2 A schematic diagram of a process flow for defining device model data generation rules provided in an embodiment of the present invention;

[0070] Figure 3 A schematic diagram of a process flow for preparing input data provided by an embodiment of the present invention;

[0071] Figure 4 A schematic diagram of a device model data generation process according to an embodiment of the present invention;

[0072] Figure 5a to Figure 5c An example of a device generation rule provided in an embodiment of the present invention;

[0073] Figure 6 An example of a device model data output process definition provided by an embodiment of the present invention;

[0074] Figure 7 A schematic diagram of a flow chart of generating device model data according to generation rules provided in one embodiment of the present invention. DETAILED DESCRIPTION

[0075] The following is a further detailed description of a device model data generation method, electronic device and storage medium based on markup language for a smart city rail transit system proposed by the present invention in combination with the accompanying drawings and specific embodiments. According to the following description, the advantages and features of the present invention will be clearer. It should be noted that the accompanying drawings are in a very simplified form and use non-precise proportions, which are only used to conveniently and clearly assist in explaining the purpose of the embodiments of the present invention. In order to make the purposes, features and advantages of the present invention more obvious and easy to understand, please refer to the accompanying drawings. It should be noted that the structures, proportions, sizes, etc. illustrated in the accompanying drawings of this specification are only used to match the contents disclosed in the specification for people familiar with this technology to understand and read, and are not used to limit the limiting conditions for the implementation of the present invention, so they have no technical substantive significance. Any structural modification, change in proportional relationship or adjustment of size, without affecting the effects that the present invention can produce and the purposes that can be achieved, should still fall within the scope of the technical content disclosed by the present invention.

[0076] In order to solve the problem described in the background technology, the present invention uses the characteristics of the Json text format to establish a configuration and generation method for device model data, giving full play to the unstructured storage characteristics of the Json format. The device model data modeling method designed by the present invention is suitable for scenarios with complex data structures, frequent changes in attribute fields, and high concurrent reading.

[0077] Functionally, the device model data configuration tool obtains output data in a specified format by performing logical operations on input data in a specific format according to specified rules. The data formats processed and generated are diverse. The development method of independently developed data configuration tools cannot uniformly adapt to input files and output files in different formats. The differences in tool developers may lead to differences in tool quality, which cannot meet the security requirements of the rail transit field for data generated by data configuration tools.

[0078] In view of this, if Figure 1 As shown, this embodiment provides a method for generating device model data based on markup language, which is applied to a smart city rail transit system, including:

[0079] Step S1, defining device model data generation rules through Json script;

[0080] Step S2, input parameter data of production equipment;

[0081] Step S3: Generate, output and verify the device model data according to the device model data generation rules and the device input parameter data.

[0082] The present invention makes full use of the advantages of Json format, such as flexibility, readability, strong extensibility and convenient reading, and processes, standardizes and automates the device model data definition and device data generation process through a custom scripting language. When the device attribute definition needs to be modified, it only needs to inherit the Json definition of the existing device, which greatly improves the design flexibility of the real-time data platform and the efficiency of the data preparation stage. It is a device model data generation method with the device as the main modeling object.

[0083] like Figure 2 As shown, in this embodiment, step S1 includes:

[0084] Step S101, defining the generation rules of basic attribute data through Json script;

[0085] Step S102, defining data generation rules for device types;

[0086] Step S103, defining project-specific equipment data generation rules; and

[0087] Step S104: define the data generation process according to project requirements.

[0088] The step S101 includes: using Json script to define the common properties and generation rules of several basic quantities, each basic quantity includes at least: a structure description domain node (schema), a type domain node (type) and a value domain node (values), wherein the structure description domain node (schema) defines the data structure definition name of the basic quantity; the type domain node (type) defines the parent type and can directly inherit the generation rules defined by the parent type; the value domain node (values) defines the generation rules of the data attributes of the basic quantity.

[0089] In this embodiment, the data structure definition of the basic quantity includes but is not limited to: a Key attribute, a Name attribute, a Type attribute, and a Description attribute.

[0090] Among them, the Key attribute: defines the keyword of the basic quantity as a global index; the Name attribute defines the name of the basic quantity. The basic quantity in the same device is guaranteed to be unique and can be searched in the device through Name; the Type attribute defines the type of the basic quantity and can be used for inspection; the Description attribute describes the function and use of the basic quantity and can be used to splice the alarm text.

[0091] In this embodiment, the basic quantities include: input quantity (Measure), control quantity (Control) and relationship quantity (Relevance).

[0092] In this embodiment, the step S101 further includes:

[0093] Step S1011, using Json script to define the attributes of the device including the input quantity and defining the corresponding generation rules according to the attributes of the device;

[0094] The input quantities include: digital quantity (DIG), polymorphic digital quantity (DIGPoly), digital quantity with timestamp (DIGTS), long integer (LINT), string (STR) and analog quantity (ANA).

[0095] Each input quantity can define a parent type. The attribute generation rules of the input quantity can directly inherit the generation rules corresponding to the parent type, or redefine the rules to cover the attribute definition corresponding to the parent type.

[0096] Step S1012, using Json script to define the properties of the device including the control quantity and defining the corresponding generation rules according to the properties of the device;

[0097] Among them, the control quantity includes: dynamic attribute update quantity (Alter), switch control quantity (DO) and analog quantity control (AO) and other types.

[0098] Each control quantity can define a parent type. The attribute generation rules of the control quantity can directly inherit the generation rules corresponding to the parent type, or redefine the rules to cover the attribute definition corresponding to the parent type.

[0099] Step S1013, using Json script to define the attributes of the possible association quantities between devices and to define corresponding generation rules according to the attributes of the devices;

[0100] Among them, the possible association quantities between devices include: fixed relationship (Fixed), switch relationship (Switch), selection relationship (Select), cluster relationship (Muster), set relationship (Cluster) and multi-set relationship (Bucket) and other types. Through these relationship definitions, the one-to-one, one-to-many static or dynamic relationships between devices can be described.

[0101] Each associated quantity can define a parent type. The attribute generation rules of the control quantity can directly inherit the generation rules corresponding to the parent type, or redefine the rules to cover the attribute definition corresponding to the parent type.

[0102] In this embodiment, step S102 includes:

[0103] Step S1021, defining attribute parameters and generation rules of the required equipment type according to project requirements;

[0104] The data generation rules for defining general device types mainly include: structure description domain node (schema), parent device domain node (parent), type domain node (type), processing process domain node (processes), temporary variable domain node (temps) and value domain node (values).

[0105] Among them, the structure description domain node (schema) defines the data structure name of the device type; the parent device domain node (parent) describes the parent device name of the device; the type domain node (type) defines the parent type and can inherit the generation rules defined by the parent type; the value domain node (values) is used to describe the generation rules of the device type attribute data.

[0106] Among them, the processing domain node (processes) defines the processing operation sequence, and the temporary variable domain node (temps) defines the temporary variable table. Both domain nodes are intermediate temporary processes for data generation and are used to assist the value domain node (values) rule definition.

[0107] Among them, the process domain node (processes), temporary variable domain node (temps) and value domain node (values) can define and execute built-in functions and reference parameter variables.

[0108] Step S1022, defining the generation rules of input quantity, control quantity, associated quantity and sub-equipment of the general equipment type;

[0109] All input quantities are defined through the input quantity domain node (measurements). Each input quantity mainly defines the name domain node (name), description domain node (description), input parameter domain node (input), value domain node (values), processing function domain node (transform) and type domain node (type). In this way, the input quantity can be generated according to the rules defined in the type domain node (type).

[0110] All control quantities are defined through the control quantity domain node (controls). Each control quantity mainly defines the name domain node (name), description domain node (description), value domain node (values), type domain node (type) and control value parameter domain node (output). In this way, the output quantity can be based on the generation rules defined by the type domain node (type).

[0111] All the related quantities between devices are defined through the related quantity domain node (relevtancys). Each related quantity mainly defines the name domain node (name), the related equipment domain node (releEquip), the related quantity name domain node (releName), the related equipment name domain node (refEquipType), the related equipment attribute name domain node (refVarName), the value domain node (values) and the type domain node (type). In this way, the related quantity can be generated according to the rules defined in the type domain node (type);

[0112] All sub-devices belonging to the device are defined through the sub-device domain node (devices). Each sub-device mainly defines the name domain node (name), description domain node (description), value domain node (values) and type domain node (type). In this way, devices can be generated according to the rules defined in the type domain node (type).

[0113] The specific rules are the same as those for independently defining basic quantities and equipment quantities and will not be repeated here.

[0114] In this embodiment, the device type includes a real device type and a virtual device type.

[0115] In this embodiment, step S103 includes:

[0116] Step S1031: According to the actual requirements of the project, the generation rules of specific equipment can be defined;

[0117] Among them, the data generation rules for specific devices are defined: structure description domain node (schema), parent device domain node (parent), type domain node (type), process domain node (processes), temporary variable domain node (temps) and value domain node (values);

[0118] Among them, the structure description domain node (schema) defines the data structure name of the device type; the parent device domain node (parent) describes the parent device name of the device; the type domain node (type) defines the parent type and can directly inherit the generation rules defined by the parent type; the value domain node (values) is used to describe the generation rules of the device type attribute data.

[0119] Among them, the process domain node (processes), temporary variable domain node (temps) and value domain node (values) can define and execute built-in functions and reference parameter variables; and

[0120] Among them, the processing domain node (processes) defines the processing operation sequence, and the temporary variable domain node (temps) defines the temporary variable table. Both domain nodes are intermediate temporary processes for data generation and are used to assist the value domain node (values) rules in generating data.

[0121] Step S1032: define the generation rules of input quantity, control quantity, associated quantity and sub-equipment of the specific equipment.

[0122] All input quantities are defined through the input quantity domain node (measurements). Each input quantity should define a name domain node (name), a description domain node (description), an input parameter domain node (input), a value domain node (values), a processing function domain node (transform) and a type domain node (type). In this way, the corresponding input quantity can be generated through the rules defined in the type domain node (type);

[0123] All control quantities are defined through the control quantity domain node (controls). Each control quantity mainly defines the name domain node (name), description domain node (description), value domain node (values), type domain node (type) and control value parameter domain node (output). In this way, the corresponding output quantity can be generated by the generation rule defined by the type domain node (type).

[0124] All the associated quantities between devices are defined through the associated quantity domain node (relevtancys). Each associated quantity mainly defines the name domain node (name), the associated equipment domain node (releEquip), the associated associated quantity name domain node (releName), the related equipment name domain node (refEquipType), the related equipment attribute name domain node (referVarName), the value domain node (values) and the type domain node (type). In this way, the corresponding associated quantity can be generated through the rules defined by the type domain node (type).

[0125] All sub-devices belonging to the device are defined through the sub-device domain node (devices). Each sub-device mainly defines the name domain node (name), description domain node (description), value domain node (values) and type domain node (type). In this way, the corresponding device can be generated according to the rules defined by the type domain node (type).

[0126] The specific rules are the same as the general equipment rule definitions and will not be repeated here. However, external data is required to generate specific equipment data based on general equipment, and special equipment can generally generate specific equipment data without external data input.

[0127] In this embodiment, step S104 includes: defining the equipment data generation steps for each system and each profession, and defining the specific data generation execution process through process domain nodes (processes).

[0128] Alternatively, you can combine multiple professional equipment data generation steps for multiple systems in batch mode and define execution commands through Launch: Progress.

[0129] like Figure 3 As shown, in this embodiment, step S2 includes:

[0130] Step S201: Define the parameter data input template of the device type according to the structure description domain (schema).

[0131] Step S202: According to the actual situation of the project and the parameter data input template of the equipment type, configure the static parameter data of all equipment.

[0132] like Figure 4 As shown, in this embodiment, step S3 includes:

[0133] Step S301, loading all device generation rules and generation process instruction sets;

[0134] Specifically, the device model data generation rules are loaded, including the basic quantity, device type and device data generation rules described in steps S101-103, and the data generation process described in step S104 is loaded.

[0135] Step S302, execute the command defined by Launch:Progress;

[0136] Step S303, read the corresponding parameter data according to the requirements, execute the corresponding equipment generation rules to generate the corresponding equipment data, including static data, dynamic data, input quantity data, control quantity data, associated quantity data, sub-equipment data and other data required for specific projects;

[0137] Verify the generated data according to the result description definition set in the structure description domain node (schema) to ensure the integrity, consistency and accuracy of the data;

[0138] That is, the step S303 is to execute the corresponding function according to the specific process definition:

[0139] Launch: Find and execute another defined build process;

[0140] Clear: Clear the context device list and all temporary variable lists;

[0141] Export: export all equipment data according to the predetermined format and requirements;

[0142] Setlist: parameter definition of device environment context;

[0143] Create: Generate a specified device, and all parameters are defined in the generation rules;

[0144] Loads: Input type device according to input parameter file, the variable part of the parameter is defined in the input parameter file.

[0145] All the above process definition functions are nested and executed in sequence to generate corresponding device data.

[0146] Step S304: output device data to a corresponding database or a designated file.

[0147] In order to understand the above embodiment, the above embodiment is further described below with a specific example:

[0148] like Figure 5a to 5c As shown, for the above step S101, the basic quantity attribute structure is defined and the definition rules are generated according to the product data configuration requirements.

[0149] like Figure 5aAs shown, two basic quantities, Measurement:Measure and Relevancy:Relevance, are defined, which respectively define the basic output rules of input quantity and related quantity (other types of basic quantities can also be defined). The basic output parameters and generation rules of the basic quantity are defined through the value range node (values), including the common properties such as Key, Name, Type, Description, etc. Of course, other specific parameter properties can also be defined. For example, Measurement:Measure defines parameter properties such as Input and Transform. Relevancy:Relevance defines parameter properties such as RelevancyEquipment and RelevancyName.

[0150] Each parameter attribute defines generation rules in the value domain node (values). The rule definition methods can be roughly divided into three categories. The first category is a simple string, which is directly output; the second category contains the $ symbol, which requires the string to be concatenated according to the internal variables contained in the $ symbol and then output; the third category contains the # symbol, which requires calling the corresponding built-in function, and the parameter list is defined by the string separated by parentheses.

[0151] Step S101 also includes: defining the attribute structure and output rules of basic quantities such as specific input quantities, control quantities and associated quantities. Figure 5a to 5c As shown, Measurement:Proxy, Measurement:STR, and Relevancy:RELE1 are defined; among them, the type value of Measurement:Proxy and Measurement:STR is Measurement:Measure, indicating that they are input quantities; the type value of Relevancy:RELE1 is Relevancy:Relevance, indicating that it is a related quantity.

[0152] Rule definitions can inherit all rules of the parent class and customize specific properties. For example, Measurement:Proxy defines a structure description domain node (schema) as the basis for verifying the generated data, and adds ID and Lonely output properties to the value domain node (values) and describes the corresponding generation rules.

[0153] The above-mentioned step S102 includes: defining the attribute parameters and output rules of the device type according to the product requirements. Figure 5a to 5cAs shown, Equipment:EQ1 is defined, where the structure description domain node (schema) is the basis for verifying the output data, and the value domain node (values) defines the data parameters and output rules (the specific definition rules are the same as those described in step S101). The measurement domain node (measurements) defines all input quantities, the relevancy domain node (relevtancys) defines all relevancy quantities, the control domain node (controls) defines all control quantities, and the sub-device domain node (devices) defines all sub-devices. You can also define the process domain node (processes) and the temporary variable domain node (temps).

[0154] The process domain node (processes) defines several execution steps, and the temporary variable domain node (temps) defines related temporary variables. These two nodes can be used to save intermediate calculation results to assist the generation process.

[0155] The above-mentioned step S103 includes: defining the attribute structure and output rules of a specific device according to the specific project requirements. Figure 5a to Figure 5c As shown, Device1 is defined, and Device1 can inherit the data parameters and output rules of Equipment:EQ1 according to the type definition, and can modify or add corresponding output data generation rules, but cannot delete the attribute parameters already defined in the parent device type. The specific rules are the same as those described in step S102. The difference between this step and step S102 is: step S102 defines the output rules for a class of equipment, and step S103 defines the output rules for a specific device.

[0156] Through steps S101 to S103, a series of device data output rules in Json format are defined. These format definitions can be stored in a key-value database or Json file according to the type name, and a complete tree relationship diagram is formed between the data through the type domain node (type), which facilitates the storage and modification of rule data.

[0157] The above step S104 includes: defining the data generation process according to the project's requirements for the equipment model data, such as Figure 6 As shown in the figure, Launch:Project1:Batch:Whole is defined, where the process domain node (processes) defines the specific generation process, which is composed of a series of commands, such as the clear function clears and initializes related data, the launch function calls other generation processes, the export function outputs device definition data, the setList function sets the parameter dictionary, the create function creates a device, and the loads function creates a type of device based on the device parameter input data.

[0158] It can be seen that the data generation process is also composed of a set of data in Json format. These format definitions can be stored in a key-value database or Json file according to the type name, which is consistent with the storage method of the data output rules, so as to facilitate overall reading and saving.

[0159] Then, refer to Figure 1 and Figure 3 As shown, the configuration project contains all device parameters.

[0160] The above step S201 includes: generating parameter definition template files of related systems and devices as needed according to the structure description definition. The template files can be in csv, xml or xls format, containing all the attribute parameter names that need to be input for the equipment of this type, so that data production personnel can prepare basic parameter data for the project.

[0161] The above step S202 includes: compiling all device attribute static parameters that need to be output according to the template and the actual situation of the project.

[0162] Finally, refer to Figure 1 and Figure 4 and Figure 7 As shown, according to the equipment data generation rules and output process definition, the equipment model data is generated and verified in combination with the equipment parameter static parameter input file.

[0163] The step S301 includes: loading device data generation rules and output process, and storing them in an environment context according to the classification of names.

[0164] The step S302 includes: executing the output process defined by Launch: Progress, and generating all device attribute data according to the device parameter input file.

[0165] Launch: Progress can define and execute another output process definition (launch command), clear all output data and temporary variable lists of the environment context (context) (clear command), output device data (including device input, control and associated quantities) in the form of key-value pairs (export command), set the parameter definition of the environment context (context) (setList command), directly generate devices (create command) and generate devices according to the input parameter file (loads command) (generally, each line of the device parameter input file corresponds to the generation of a device data). The entire output process is completed after the loop nested execution of all process definition functions. The following focuses on the output process of device data.

[0166] like Figure 7As shown, the step S303 includes: generating designated device data according to the device parameter input file and the generation rule definition.

[0167] First, create a device blueprint based on the Json data of the generation rule corresponding to the device type. Because the generation rule can simplify the definition process by defining the parent type through the type domain node (type), it is necessary to load the rules in sequence according to the type domain node (type) to form a complete device blueprint as a reference and basis for device data generation.

[0168] Different strategies are adopted for different domain nodes during the loading process. For example, the rules defined for the device attribute domain node (values), temporary variable domain node (temps), and process domain node (processes) are to construct a list in the order from parent type to child type. The data of the child device domain node (records), input quantity domain node (measurements), control quantity domain node (controls), and related quantity domain node (relevtancys) are to add the relevant array elements to the corresponding list in sequence. For other domain nodes, the sub-type rules cover the parent type rules until the final blueprint is obtained after the loop nests and loads all the generation rules.

[0169] Again, a temporary variable list is generated based on the temporary variable domain node (temps). This list will inherit the temporary variable list of the parent device, and its life cycle is limited to the generation cycle of this device. Temporary variables will overwrite existing variables in the temporary variable list, but will not affect the generation of other device data.

[0170] Temporary variable rules can be string values, built-in functions can be referenced using the # symbol, or strings can be concatenated using $. Device properties (device), temporary variables (temp), global variables (global), and parent device properties (super) can be referenced by the $ identifier based on the prefix. If there is no identifier, the Json node value with the same name defined in the generation rule is referenced.

[0171] The process function is executed according to the process domain node (process), mainly to update the global variables of the context (context) to ensure that the device data output process is completed normally.

[0172] Next, the device properties are generated based on the value range node (values) and the static input data of the device parameters. In essence, the device parameter input data is equivalent to the data defined in the value range node (values), and the rules for defining data in the value range node (values) are the same as those of the temporary variable domain node (temps).

[0173] Next, the parent device is defined according to the parent class domain node (parent), and the structure description definition constraints are defined according to the structure description domain node (schema).

[0174] Please continue to refer to Figure 7 As shown, then, the input quantity blueprint is generated according to the input quantity domain node (measurements); the control quantity blueprint is generated according to the control quantity domain node (controls); the relevancy blueprint is generated according to the relevancy domain node (relevtancys). The generation process of these blueprints is basically the same. It is necessary to check whether the corresponding node contains a complex data domain node (complex).

[0175] If it does not contain complex data domain nodes (complex), it is a simple blueprint. According to the type domain nodes (type), the rules are loaded in sequence to form a complete blueprint. The strategies adopted for different domain nodes during the loading process are the same as those adopted in the device blueprint generation process described above.

[0176] If it contains a complex data domain node (complex), it is a complex blueprint, which means that zero, one or more basic quantities or sub-equipment can be generated according to different conditions. There are two main types of complex blueprints: judge type and loop type. A complex blueprint needs to generate zero or more simple blueprints according to conditional logic processing, and then process the simple blueprint to generate data.

[0177] Among them, the judge type requires outputting data according to conditions, and the method of generating a simple blueprint is as follows: if the calculated value of the conditional domain node (condition) is true, then the corresponding simple blueprint is generated according to the value domain nodes (values) defined in the conditional domain node (meet); otherwise, the corresponding simple blueprint is generated according to the value domain nodes (values) defined in the dissatisfaction conditional domain node (dismeet).

[0178] Among them, the loop type requires to output data in a loop multiple times. The method of generating a simple blueprint is as follows: determine the number of simple blueprints to be generated according to the calculation value of the condition node (condition), and generate the corresponding simple blueprints according to the value range node (values) in turn.

[0179] Then, the input quantity data is generated according to the input quantity blueprint: input parameters are generated according to the input domain node (input); transformation parameters are generated according to the transformation domain node (transform); alarm parameters are generated according to the alarm domain node (alert); and corresponding parameters are generated according to other definition domain nodes.

[0180] Then, the control quantity data is generated according to the control quantity blueprint, the output parameters are generated according to the output domain node (output), the transformation parameters are generated according to the transformation domain node (transform), and the alarm parameters are generated according to the alarm domain node (alert); and the corresponding parameters are generated according to other definition domain nodes.

[0181] Then, the associated quantity data is generated according to the associated quantity blueprint.

[0182] Then, generate the sub-device data according to the sub-device blueprint. The generation process is the same as the device generation process:

[0183] Then, the generated data is verified according to the schema to see if it conforms to the predefined structure description and is added to the device list of the context.

[0184] Finally, the device model data is output according to the device list of the context. It can be in the form of a Json file, a key-value database, or other formats as needed. Various dictionary parameter table files can also be generated as required.

[0185] This embodiment standardizes the format and content of the data input file, defines the device data definition through the Json script, defines the data configuration output process through the Json script, and outputs the data in the KV key value format, which is convenient for direct use and secondary processing, thus simplifying the data production process as a whole.

[0186] On the other hand, the present invention further provides an electronic device, including a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the method described above is implemented.

[0187] In other aspects, the present invention further provides a readable storage medium, wherein the readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described above is implemented.

[0188] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0189] It should be noted that the devices and methods disclosed in the embodiments of this article can also be implemented in other ways. The device implementation described above is only schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of this article. In this regard, each box in the flowchart or block diagram can represent a part of a module, program or code, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical function, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented by a dedicated hardware-based system for performing a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0190] In addition, each functional module in each embodiment of the present invention can be integrated together to form an independent part, or each module can exist separately, or two or more modules can be integrated to form an independent part. Although the content of the present invention has been described in detail through the above preferred embodiments, it should be appreciated that the above description should not be considered as a limitation of the present invention. After reading the above content, it will be obvious to those skilled in the art for various modifications and substitutions of the present invention. Therefore, the protection scope of the present invention should be limited by the attached claims.

Claims

1. A method for generating device model data based on markup language, applied to a smart city rail transit system, characterized in that: include: Define the device model data generation rules through Json script; Make equipment input parameter data; The device model data is generated, output and verified according to the device model data generation rule and the device input parameter data.

2. The method for generating device model data based on markup language according to claim 1, characterized in that: The step of defining the device model data generation rule by using the Json script includes: Use Json scripts to define the generation rules for basic attribute data, data generation rules for equipment types, generation rules for project-specific equipment data, and define the data generation process according to project requirements.

3. The method for generating device model data based on markup language according to claim 2, characterized in that: The step of defining the generation rules of basic attribute data through the Json script includes: Use Json script to define the common properties and generation rules of several basic quantities. Each basic quantity includes at least: a structure description domain node, a type domain node and a value domain node. The structure description domain node defines the data structure of the basic quantity; the type domain node defines the parent type of the basic type, which is used to inherit the generation rules of the parent type; the value domain node defines the generation rules of the data attributes of the basic quantity.

4. The method for generating device model data based on markup language according to claim 3, characterized in that: The data structure definition of the basic quantity includes at least: Key attribute: defines the keyword of the basic quantity as a global index; Name attribute defines the name of the basic quantity. The basic quantity in the same device is guaranteed to be unique and can be searched in the device through the Name attribute; Type attribute defines the type of the basic quantity and can be used for inspection; Description attribute describes the function and use of the basic quantity and can be used to splice alarm text.

5. The method for generating device model data based on markup language according to claim 2, characterized in that: The basic quantities include: input quantity, control quantity and relationship quantity.

6. The method for generating device model data based on markup language according to claim 5, characterized in that: Use Json script to define the properties of the device including the input quantity and define the corresponding generation rules according to the properties of the device; The types of input quantities include digital quantity, polymorphic digital quantity, digital quantity with timestamp, long integer, string and analog quantity; Each input quantity can define a parent type. The generation rules of the input quantity attributes can directly inherit the generation rules of the parent type, or redefine the rules to cover the rule definition corresponding to the parent type.

7. The method for generating device model data based on markup language according to claim 5, characterized in that: Use Json script to define the properties of the device including the control quantity and define the corresponding generation rules according to the properties of the device; Among them, the types of control quantities include dynamic attribute update quantity, switch control quantity and analog quantity control; Each control quantity can define a parent type. The generation rules of the control quantity attributes can directly inherit the generation rules of the parent type, or redefine the rules to cover the rule definition corresponding to the parent type.

8. The method for generating device model data based on markup language according to claim 5, characterized in that: Use Json scripts to define the properties of possible correlations between devices and define corresponding generation rules based on the properties of the devices. Among them, the types of association quantities that may exist between devices include: fixed relationship, switch relationship, selection relationship, cluster relationship, set relationship and multi-set relationship. These relationships can be used to describe one-to-one, one-to-many static or dynamic relationships between devices; Each associated quantity can define a parent type. The generation rules of the associated quantity attributes can directly inherit the generation rules of the parent class, or redefine the rules to cover the rule definition corresponding to the parent type.

9. The method for generating device model data based on markup language according to claim 2, characterized in that: The steps of generating the data rule of the device type include: Define the attribute parameters and generation rules of the included equipment types according to project requirements; The attribute data generation rules for defining the device type mainly include: structure description domain node, parent device domain node, type domain node, processing process domain node, temporary variable domain node and value domain node; Among them, the structure description domain node defines the data structure name of the device type; the parent device domain node describes the parent device name of the device; the type domain node defines the parent type and can directly inherit the generation rules defined by the parent type; the value domain node is used to describe the specific generation rules of the device type attribute data; Among them, the processing domain node defines the processing operation sequence, and the temporary variable domain node defines the temporary variable table. Both domain nodes are temporary intermediate processes for data generation and are used to assist the value domain node rule definition in outputting data; Among them, the processing domain node, temporary variable domain node and value domain node can define and execute built-in functions and reference parameter variables.

10. The method for generating device model data based on markup language according to claim 9, characterized in that: Define the generation rules of input quantity, control quantity, associated quantity and sub-equipment of equipment type; All input quantities are defined according to the input quantity domain node. Each input quantity mainly defines a name domain node, a description domain node, an input parameter domain node, a value domain node, a processing function domain node and a type domain node. Then the input quantity can be generated according to the rules defined in the type domain node. All control quantities are defined according to the control quantity domain node. Each control quantity mainly defines the name domain node, description domain node, value domain node, type domain node and control value parameter. Then the output quantity can be generated according to the rules defined in the type domain node. All associated quantities between devices are defined according to the associated quantity domain node. Each associated quantity mainly defines a name domain node, an associated device domain node, an associated quantity name domain node, a related device name domain node, a related device attribute name domain node, a value domain node, and a type domain node. Then, the associated quantity can be generated according to the rules defined in the type domain node. Domain node sub-device domain node defines all sub-devices of the device. Each sub-device mainly defines the name domain node, description domain node, value domain node and type domain node. Then the device can be generated according to the rules defined by the type domain node.

11. The method for generating device model data based on markup language according to claim 9, characterized in that: The device types include real devices and virtual devices.

12. The method for generating device model data based on markup language according to claim 2, characterized in that: The steps to define project-specific equipment data generation rules include: According to the actual requirements of the project, the generation rules of specific equipment can be defined; The data generation rules for a specific device are defined, mainly including: structure description domain node, parent device domain node, type domain node, processing process domain node, temporary variable domain node and value domain node; Among them, the structure description domain node defines the data structure name of the device type; the parent device domain node describes the parent device name; the type domain node defines the parent type of the basic type and can directly inherit the generation rules defined by the parent type; the value domain node is used to describe the generation rules of the device type attribute data; Among them, the processing process domain node defines the processing operation sequence, and the temporary variable domain node defines the temporary variable table. Both domain nodes are temporary intermediate processes for data generation and are used to assist the definition of value domain node rules; Among them, the processing domain node, temporary variable domain node and value domain node can define and execute built-in functions and reference parameter variables; Then, define the generation rules of input quantity, control quantity, associated quantity and sub-equipment of specific equipment; All input quantities are defined through input quantity domain nodes. Each input quantity mainly defines a name domain node, a description domain node, an input parameter domain node, a value domain node, a processing function domain node, and a type domain node. Then, the input quantity can be generated according to the rules defined in the type domain node. All control quantities are defined through the control quantity domain node. Each control quantity mainly defines the name domain node, description domain node, value domain node, type domain node and control value parameter domain node. Then the output quantity can be generated according to the rules defined by the type. All associated quantities between devices are defined through associated quantity domain nodes. Each associated quantity mainly defines name domain nodes, associated device domain nodes, associated quantity name domain nodes, related device name domain nodes, related device attribute name domain nodes, value domain nodes and type domain nodes. Then, associated quantities can be generated through the rules defined in the type domain nodes. All sub-devices belonging to the device are defined through the sub-device domain node. Each sub-device mainly defines the name domain node, description domain node, value domain node and type domain node. Then the device can be generated according to the rules defined by the type.

13. The method for generating device model data based on markup language according to claim 2, characterized in that: The steps of defining the data generation process according to project requirements include: Define the steps for generating equipment data for each system and each specialty, and define the specific data generation execution process through process domain nodes; Alternatively, you can combine multiple professional device data generation steps for multiple systems in batch mode and then define execution commands through Launch: Progress.

14. The method for generating device model data based on markup language according to claim 1, characterized in that: The step of making device input parameter data comprises: Define the equipment parameter data input template according to the structure description domain node of the equipment type; Enter the static parameter data of all devices according to the template of the actual project.

15. The method for generating device model data based on markup language according to claim 1, characterized in that: The step of generating, verifying and implementing the device model data according to the device model data generation rule and the device input static parameter data comprises: Load all device generation rule definitions and generation process instruction sets; Execute the command defined by Launch:Progress, read the corresponding parameter data as required, and execute the corresponding device generation rules to generate the corresponding device data, including static data, dynamic data, associated data, sub-device data, and other data required for specific projects; Verify the generated data according to the structural description domain nodes; Output device data to the corresponding database or specified file.

16. An electronic device, characterized in that: The method comprises a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the method according to any one of claims 1 to 14 is implemented.

17. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 14 is implemented.

Images