A target controller configuration data system and generation method

Abstract

The application discloses a target controller configuration data system and a generating method, relates to the technical field of target controller configuration data generation, and comprises a physical layer, a logic layer and an interface layer: the physical layer is used for describing hardware configuration information of the target controller, the hardware configuration information comprises a physical position, equipment types and quantities and a communication protocol of a main safety control unit, the physical layer comprises a plurality of RACK structures corresponding to a plurality of cabinets of the target controller, and the RACK structure comprises a plurality of LRU structures recording different hardware modules of the cage; the logic layer is used for describing a logic set, and elements of the logic set are logic objects; the logic layer comprises a plurality of OBJECT structures used for storing the logic objects; and the interface layer is used for describing communication between different LRU structures and binding the physical layer and the logic layer. According to the application, the configuration data is divided into three layers of logic, physics and interface, and special parameters and communication information of a plurality of complex hardware boards can be clearly stored.

Description

Technical Field

[0001] The present invention relates to the technical field of target controller configuration data generation, and more particularly to a target controller configuration data system and generation method. Background Art

[0002] With the continuous advancement of railway system informatization and the development of dynamic-interval-based train control equipment, the application and promotion of target controllers are accelerating. Developed based on the safety control unit (VCU), the target controller system consists of fully electronic boards for driving relays and other equipment, collecting and driving relays, signals, track circuit switches, and other discrete devices. For products based on the safety control unit, the configuration and parameter data of all boards are centrally stored in a device connected to the main safety control unit. The main safety control unit distributes the configuration and parameter data of each board via an internal bus.

[0003] Among them, each board has its own configuration data and possible parameter data. Currently, the project adopts manual method to compile the configuration data and parameter definition files of the board, and confirms their correctness through manual review. Due to the diverse types of boards, complex parameters, and large number of configuration items, the manual compilation and review method has the defects of high work intensity, low resource utilization and production efficiency. With the large-scale application of target controller systems, manual compilation and review methods have become difficult to adapt to engineering applications.

[0004] Therefore, there is an urgent need for a system and method for generating target controller configuration data to realize automatic configuration and storage of target controller board configuration data and parameter data, thereby reducing labor, verification and project design costs, which is particularly important. Summary of the Invention

[0005] To overcome the aforementioned shortcomings of the prior art, the present invention discloses a target controller configuration data system and generation method. The purpose of the present invention is to address the difficulty of existing manual compilation and review methods in adapting to engineering applications. Using the application design plan and system-level application design files provided by the project designer, the present invention divides the target controller configuration data into physical, logical, and interface layers, and stores them in XML-formatted files. Ultimately, the specific parameters of each board are converted into binary files for use in the configuration and compilation of safety control unit products.

[0006] In order to achieve the above objectives, the present invention adopts the following technical solutions:

[0007] In a first aspect, the present invention provides a target controller configuration data system, comprising a physical layer, a logical layer, and an interface layer:

[0008] The physical layer is used to describe the hardware configuration information of the target controller, including the physical location, device type and quantity, and the communication protocol of the main safety control unit. The physical layer includes multiple RACK structures corresponding to multiple chassis of the target controller, and the RACK structure includes multiple LRU structures that record different hardware modules of the cage;

[0009] The logic layer is used to describe a logic set, wherein the elements of the logic set are logic objects. The logic layer includes a plurality of OBJECT structures for storing the logic objects, and the OBJECT structures include data parameter information and data type information;

[0010] The interface layer is used to describe the communication between different LRU structures and bind the physical layer and the logical layer. The interface layer includes an INTERFACES structure for describing the communication information of the interface layer. The INTERFACES structure includes an INTER_OBJECT structure. The INTER_OBJECT structure includes several SAFE configuration items.

[0011] In the present invention, an XML configuration file is defined and generated, wherein the XML configuration file includes the above-mentioned three-layer structure of the physical layer, the logical layer, and the interface layer. The three-layer structure is specifically as follows:

[0012] 1. Physical Layer (PHY_STRUCT)

[0013] In this invention, the physical layer abstracts the target controller's hardware configuration information, including physical location (cage, rack location), device type and quantity, and the communication protocol configuration of the main safety control unit, into an equivalent data structure. This data structure includes multiple RACK structures corresponding to the target controller's multiple chassis.

[0014] Preferably, the RACK structure further includes: RACK_NB for recording the cage number attribute and RACK_SIZE for recording the cage capacity attribute.

[0015] In the present invention, the number of chassis of each target controller is obtained according to the input document (interface code table), and the corresponding number of RACK configuration items are defined in the physical layer configuration. That is, a corresponding RACK configuration item is generated for each chassis in turn. The cage information in the interface code table is split and abstracted into the number attribute RACK_NB and the capacity attribute RACK_SIZE. According to the hardware conditions, the capacity attribute is set to a fixed value. According to the design rules, the main and standby hardware board mapping relationship array is defined, which consists of the slot position of the main board and the slot position of the redundant standby board. The mapping rules are fixed, and the main and standby hardware board mapping relationship array is queried, and the REDUNDANT_LRU_ID attribute is set to record the redundant relationship between the main module and the standby module.

[0016] Preferably, each LRU structure includes:

[0017] Record the LRU_ID of the hardware number;

[0018] LRU_SLOT that records the physical location of the hardware;

[0019] LRU_NAME records the hardware name;

[0020] LRU_TYPE records the hardware board type;

[0021] LRU_CODE that stores the electronic stamp string of the electronic error prevention mechanism of the safety control unit;

[0022] LRU_PARAM structure that stores hardware module-specific parameter data;

[0023] The hardware structure is decomposed and stored to define the functions in the LRU and the CELL structure of the communication configuration information contained in the main safety control unit.

[0024] In this invention, the different hardware modules on a rack are converted into an LRU structure. Each hardware module (LRU) defines LRU_ID, LRU_SLOT, LRU_NAME, and LRU_TYPE to record the hardware number, physical location, name, and hardware board type, respectively. The electronic stamp string used for the electronic error prevention mechanism of the safety control unit is stored as a 13-bit string in the LRU_CODE attribute. The LRU_PARAM structure and CELL structure are as follows:

[0025] (1) LRU_PARAM structure

[0026] Preferably, in the LRU_PARAM structure, the parameter data of the hardware module includes specific parameter data values ​​of the target controller-related hardware board, general data values ​​of board parameters, actual data values ​​of board parameters, and special data values ​​of board parameters.

[0027] Preferably, the LRU_PARAM structure includes:

[0028] LRU_COM configuration item used to define the parameter data of the main control unit;

[0029] A FILETYPE configuration item is used to store parameters of the hardware board. The NAME attribute of the FILETYPE configuration item is used to indicate the type of binary file loaded into the safety control unit.

[0030] Preferably, the steps for calculating the final value of the parameter data of the hardware board are as follows:

[0031] A, traverse the specific parameter data value storage file Special_Parameters.xml of the target controller related hardware board card, for each hardware type, traverse its parameter name and parameter value, and establish a key-value pair dictionary with the parameter value as the key, form a specific parameter data dictionary of the target controller related hardware board card with the hardware type keyword as the key and the <parameter name, parameter value> dictionary as the value;

[0032] B, traverse the general data value record table of the hardware board card parameters, and update and supplement the specific parameter data dictionary established in step A with the general parameter values, to obtain a new parameter data dictionary with general parameter information;

[0033] C, traverse the actual data value record table of the hardware board card parameters, and update and supplement the parameter data dictionary established in step B with the actual application parameter values, to obtain a new parameter data dictionary with actual application parameter information;

[0034] D, query the above parameter data dictionary with the hardware board card type as the key, and generate N parameter data of the board card in the FILETYPE configuration item in order;

[0035] E, add special parameter values unique to the board card according to the board card type.

[0036] (2) CELL structure

[0037] In the present application, in the LRU structure for storing the main safety control unit module, the CELL structure is arranged to define the function condition in an LRU, which is a detailed description of the function, and an LRU can be composed of several modules as a function, each CELL structure corresponds to an LRU and can have its own special parameters, wherein the COM CELL is a special CELL structure: describing the general Ethernet communication unit.

[0038] For the main safety control module, a CELL_COM must be defined and can only have one CELL_COM. For other SVCU modules, CELL_COM is prohibited.

[0039] The CELL structure includes:

[0040] CELL_ID (used to store the identifier of the Cell unit);

[0041] CELL_NB (used to store the serial number of the configuration of the Cell unit defined in the configuration item);

[0042] CELL_USE (used to store whether the Cell defined in the configuration item is used);

[0043] CELL_PARAM (used to store the parameters of the Cell);

[0044] CELL_PARAM includes CELL_COM, which includes IP (IP protocol related configuration), UDP (describing UDP parameters used for secure communication, UDP protocol is used for the IP upper layer), USIG (security layer parameters) and MAINT (maintenance parameters).

[0045] In the present invention, CELL_COM is used to define the Ethernet unit of the main safety control module and is only defined in the main safety control unit. The CELL_COM structure is closely related to various network layers and can interact with each other during communication by using the COM unit.

[0046] 2. Logical layer (LOG_STRUCT):

[0047] In this invention, similar to the physical layer, a logical layer is defined to describe logical collections, not limited to directly connected hardware architectures. The elements of a logical collection are logical objects. The physical layer abstracts the structure between logical objects and stores mappings between objects, including logical and physical mappings. A logical object OBJECT structure is defined to store logical objects. Logical objects include physical and logical types. Physical types describe the interaction between inputs and outputs and physical units, while logical types describe the interaction between outputs and data generated by a logical pair or used by a logical object. Therefore, the OBJECT structure contains both data parameter information and data type information.

[0048] Preferably, the OBJECT structure includes:

[0049] Global attributes;

[0050] MAPPING structure used to describe different input and output between objects;

[0051] A SPECIFIC structure used to describe special parameters for an object and other object or unit processing unit data.

[0052] In the present invention, the steps for generating the configuration file logic layer are as follows:

[0053] First, establish the OBJECT structure of the communication processing board of the target controller system, which describes the code position information sent by the interlocking control system to the target controller system, the code position information sent by the target controller to the interlocking control system, the code position required by the communication processing board for the master-slave mutual synchronization SN, the code position information customized by the communication processing board for output to the interlocking control system, and the code position information of the constant 1 sent by the interlocking control system to the target controller.

[0054] Secondly, define a corresponding OBJECT structure according to each hardware board.

[0055] (1) Global attributes

[0056] In the present invention, the global attributes include OBJ_TYPE for describing the type of the logical object, OBJECT_DESCR for describing the transmission type of the interactive information, and OBJECT_NAME for recording the name of the logical module.

[0057] In the present invention, global attributes are the same for all types of objects. OBJ_TYPE is used to describe the type of logical objects. When the logical object is used to define the input and output communication module, the value of OBJ_TYPE item defines<OBJ_MSG> 、<OBJ_COM> OBJ_GUEST or OBJ_MSG is used to describe a message object. The logical object type for sending or receiving messages from the main safety control module is OBJ_MSG. When the logical object OBJECTE is used to define the logical configuration of a hardware board, the value of the OBJ_TYPE item in this OBJECT configuration should be OBJ_GUEST. When the logical object OBJECTE is used to define the logical configuration of the custom and constant 1 code bits of a communication processing board, the value of the OBJ_TYPE item in this OBJECT configuration should be OBJ_COM.

[0058] (2) MAPPING structure

[0059] In the present invention, the MAPPING structure includes an INPUT configuration item and an OUTPUT configuration item.

[0060] In the present invention, the steps for generating the input-output relationship in the MAPPING element of each logical object of the OBJECT structure are as follows:

[0061] Ⅰ. Read the code configuration table of the hardware board, generate input and output code bits according to the board type, and store them in the input and output code bit arrays of the board object;

[0062] Ⅱ. Generate one or more INPUT and OUTPUT configuration items based on the input\output code bits.

[0063] Among them, the number of INPUT configuration items is determined according to the number of code bits of the external input of the logical object described by the OBJECT structure, and the number of OUTPUT configuration items is determined according to the number of code bits of the external output of the logical object described by the OBJECT structure; if a logical object does not define input code bits or output code bits, the logical object corresponding to the communication node is not generated.

[0064] In the present invention, the number of INPUT configuration items is determined by the number of external input code points of the logical object described by the OBJECT structure, and the number of OUTPUT configuration items is determined by the number of external output code points of the logical object described by the OBJECT structure. The external input code points and external output code points of the logical object are composed of the input / output code points actually defined by each board in the code point table (the valid code point array obtained from the code point table in step I) and other input / output code points. Other code points primarily include broadcast connections between logical objects, such as input information generated by a physical hardware module and received by two or more different hardware modules, and local connections, such as interactive information occurring on the same hardware module. Therefore, when the logical object containing the MAPPING configuration defines the logical configuration for receiving communication processing unit data (communication processing board), an INPUT configuration item is required in the MAPPING. When the logical object containing the MAPPING configuration defines the logical configuration for sending communication processing unit data (communication processing board), an OUTPUT configuration item is required in the MAPPING. When the logical object where the MAPPING configuration is located is used for the logical configuration of the master and slave boards, the actual code position and the information transmitted between the master and slave boards must be defined in the MAPPING.

[0065] If a logical object does not define an input code bit (all logical objects of non-input and output communication modules have no output code bits, and the input and output communication module does not output a constant 1 code bit to the communication node), the logical object corresponding to the communication node (i.e., the OBJECT named OBJ_COM_OUTGOING) is not generated.

[0066] If a logical object does not define an output code bit (all non-input and output communication modules have no input code bits, and the communication node does not output a constant 1 code bit to all non-input and output communication modules), the logical object corresponding to the communication node (i.e., the OBJECT named OBJ_COM_INCOMING) is not generated.

[0067] (3) SPECIFIC structure

[0068] In the SPECIFIC structure, when the OBJECT structure is used to define an input / output communication module and OBJ_TYPE is OBJ_MSG, two OBJECT_COM_MSG configuration items are defined in the SPECIFIC configuration item of the OBJECT as special parameters of the expected message object; the OBJECT_COM_MSG configuration item includes two attribute items: MESSAGE_ID (which defines a message identifier containing data, referenced from the Cell structure) and DIRECTION (which indicates whether the message is generated or consumed), as well as one or more DATA_MAPPING configuration items.

[0069] The number of DATA_MAPPING configuration items is determined by the number of receive code bits or send code bits of the OBJECT configuration item where the OBJECT_COM_MSG configuration item is located. It is used to indicate how the input or output data corresponds to the message content. The DATA_MAPPING structure sequentially defines two attribute items: IO_NUMBER (input and output port numbers) and OFFSET (offset of the starting position of the data in the message).

[0070] In this invention, when the OBJECT structure is used to define an input / output communication module and the OBJ_TYPE is OBJ_MSG, two OBJECT_COM_MSG configuration items are defined in the OBJECT's SPECIFIC configuration item. OBJECT_COM_MSG is configured with two attributes: MESSAGE_ID and DIRECTION. When the object is loaded into a message, the DIRECTION attribute indicates whether the message is "produced" or "consumed."

[0071] The OBJECT_COM_MSG configuration item should contain one or more DATA_MAPPING configuration items. The number of DATA_MAPPING configuration items is determined by the number of receive code points (OUTPUT) or transmit code points of the OBJECT configuration item in which the OBJECT_COM_MSG configuration item is located. The DATA_MAPPING structure defines two attributes, IO_NUMBER and OFFSET. The value of IO_NUMBER should start at 1 and increase sequentially. The specific number of OBJECT_COM_MSG configuration items in the first OBJECT configuration item is determined by the total number of receive code points in the OBJECT (when the OBJECT configuration is used to define the logical configuration of cell unit data reception (OUTPUT)). The specific number of OBJECT_COM_MSG configuration items in the second OBJECT configuration item is determined by the number of transmit code points in the A series in which the OBJECT is located (when the OBJECT configuration is used to define the logical configuration of cell unit data transmission (INPUT)). The value of the OFFSET attribute item should start at 0 and increase sequentially to describe the length of the message.

[0072] 3. Interface Layer (INTERFACES)

[0073] The interface layer binds the logical elements of the logical layer and the physical elements of the physical layer together by describing the communication between different LRUs. In the present invention, the INTER_OBJECT structure includes several SAFE configuration items, each of which includes:

[0074] LRU_ID of the slot number of the hardware board to which the current communication information belongs;

[0075] The SAFE configuration item is described as the DIRECTION of the input or output of the MAPPING configuration of the corresponding logical object OBJECT structure;

[0076] DATA_NAME is the name of the external input or output code point;

[0077] The DATA_ID of the INPUT or OUPUT code corresponding to the same board increases starting from 1.

[0078] In this invention, the interface layer defines communication between internal buses. The INTERFACES structure is used to describe communication information within the interface layer. INTERFACES defines an INTER_OBJECT structure, which contains one or more SAFE (safe communication) configuration items. SAFE has four attributes: LRU_ID, DIRECTION, DATA_NAME, and DATA_ID.

[0079] SAFE includes the custom code bits required by the communication processing board for master / slave synchronization, custom code bits for output to the interlocking control system, the constant 1 code bits sent by the interlocking control system to the target controller, and the logical interaction information corresponding to each hardware board. Specifically, a SAFE configuration item is defined for each INPUT and OUTPUT configuration item of the logical object (OBJECT_NAME: OBJ_COM_1) used to define the communication processing board, as well as for each slave board's logical object.

[0080] In a second aspect, the present invention further provides a method for generating target controller configuration data, comprising the following steps:

[0081] 1. Prepare the input file, define its file path in the input configuration file Config.tab, and create an object class library to read the input document defined in the input configuration file Config.tab to obtain various parameter dictionaries; the details are as follows:

[0082] Step 1. Prepare the input file and define its file path in the input configuration file Config.tab;

[0083] Step 2: Create an object class library and abstract the three-layer structure into InterfaceStruct (interface layer structure), LogStruct (logical layer structure), and PHYStruct (physical layer structure) structure classes;

[0084] Step 3: Read the input document defined in the input configuration file Config.tab to obtain various parameter dictionaries;

[0085] Preferably, the various parameter dictionaries include a communication parameter dictionary, a basic special parameter dictionary [board type, special parameters], a universal special parameter dictionary [board type, special parameters], a configurable special parameter dictionary [board type, special parameters], a board-universal code suffix dictionary [board type, suffix structure], and a board-configurable code suffix dictionary [board type, suffix structure]. In the present invention, the suffix structure is a structure containing the board input suffix and output suffix.

[0086] 2. Using the input document, create and store the target station target controller protocol dictionary, and create a key-value pair [target controller number, hardware board object collection]; the details are as follows:

[0087] Step 4: Use the internal device information table of the input document to create a target station target controller protocol dictionary and store it in the format of key-value pairs [target controller number, protocol].

[0088] Step 5: Create a key-value pair [target controller number, hardware board object set] based on the physical location information of each hardware board stored in the interface code table of the input document, where the target controller number is the number of the target controller to which the hardware board object set belongs;

[0089] Step 6: Complete the redundant hardware board information of the target controller with dual-system configuration. Its communication information is the same as that of the main board. The physical location is obtained in a predefined manner. Add the corresponding redundant board object to the hardware board object set corresponding to the current target controller in [target controller number, hardware board object set] in step 5.

[0090] 3. Traverse [target controller number, hardware board object set] to establish the physical layer, and establish a board object LRU for each hardware board. Then establish a special parameter set for each LRU object, and add object-specific special parameters to the special parameter set of the LRU object based on the type of the LRU object; the details are as follows:

[0091] Step 7: Traverse [target controller number, hardware board object set], create a physical layer PHY_STRUCT structure object, create a Rack structure according to the cage number of the hardware board, and create a board object LRU for each hardware board in the Rack;

[0092] The hardware board feature description attribute of the LRU object is determined by the type of the hardware board.

[0093] Step 8: Create a special parameter set for each LRU object;

[0094] First, traverse the basic special parameter dictionary obtained in step 3 and generate the parameter set A of the LRU object based on the board type attribute of the current LRU object;

[0095] Secondly, traverse the general special parameter dictionary, query the special parameters corresponding to the board type of the current LRU object, overwrite the values ​​of the special parameters with the same name in parameter set A, and obtain parameter set B updated by the general special parameters;

[0096] Finally, the set B is updated with the configurable special parameter dictionary to obtain the final special parameter set of the LRU object.

[0097] Step 9: Merge the board universal code point suffix dictionary [board type, suffix structure] and the board configurable code point suffix dictionary [board type, suffix structure] obtained in step 3, and use the configurable suffix to update the universal code point suffix;

[0098] Step 10: traverse the updated board suffix dictionary [board type, suffix structure], query the suffix structure of the LRU object, and store the input and output code points of the LRU object in the input code point set and output code point set of the board object; the details are as follows:

[0099] Step 1: Traverse every valid code position of the board;

[0100] Step 2: Extract the suffix based on the valid code position, query the suffix dictionary based on the board type, and obtain the suffix structure;

[0101] Step 3: Traverse the suffix structure of the board, merge the valid code position with the suffix, and obtain the input and output code positions.

[0102] Step 11: Add object-specific special parameters to the special parameter set of the LRU object according to the type of the LRU object;

[0103] 4. Traverse the target controller protocol dictionary to obtain the protocol type of the current target controller. Based on the IP configuration information, communication parameter dictionary, and protocol type in the engineering design document, generate and store the network communication unit of the target controller's input and output modules. The details are as follows:

[0104] Step 12: traverse the target controller protocol dictionary in step 4 to obtain the protocol type of the current target controller;

[0105] Step 13: Based on the IP configuration information in the engineering design document, the communication parameter dictionary obtained in step 3, and the protocol type obtained in step 12, generate the network communication unit of the input and output module of the target controller and store it in the CellStruct structure;

[0106] 5. Generate the logic layer and interface layer based on the input and output code bit sets of the board object and the type of the LRU object, and serialize the class object into an XML string and save it to a file. The details are as follows:

[0107] S14. Generate InterfaceStruct (interface layer) and LogStruct (logic layer) based on the input and output code bit sets of the board object and the type of the LRU object. For different LRU objects, add the master-slave mutual transmission code bit and other exclusive input and output code bits according to their board type.

[0108] S15. Serialize the class object into an XML string and save it to a file. At this point, the configuration file is ready and the configuration data is generated.

[0109] Beneficial effects of the present invention:

[0110] The present invention divides configuration data into a three-layer structure of logic, physics and interface, and can clearly store various and complex special parameters and communication information of hardware boards.

[0111] The present invention adopts XML format storage, has a clear hierarchical structure, is easy to query, and uses the XSD check corresponding to the XML file to flexibly verify the correctness of the configuration item value.

[0112] The present invention uses engineering design documents as direct input documents and adopts an automatic generation method without manual compilation, and can generate configuration data of multiple target controllers of a station at one time.

[0113] The present invention realizes flexible configuration through a generation method that combines universal input with configurable input, and configuration files with input files, and is compatible with multiple protocol types and multiple usage scenarios.

[0114] The LRU structure of the present invention sets universal hardware board feature description attributes, can define various types of hardware boards, and realizes flexible configuration of special parameters of different hardware boards through a query method combining board type and parameter definition file. BRIEF DESCRIPTION OF THE DRAWINGS

[0115] Figure 1 This is a schematic diagram of the physical layer data structure of the present invention;

[0116] Figure 2 This is a schematic diagram of the LRU structure of the present invention;

[0117] Figure 3 Schematic diagram of the CELL structure of the present invention;

[0118] Figure 4 This is a schematic diagram of the logic layer structure of the present invention;

[0119] Figure 5 This is a schematic diagram of the interface layer structure of the present invention. DETAILED DESCRIPTION

[0120] The following will provide a clear and complete description of the concept, specific structure and technical effects of the present invention in conjunction with the embodiments and drawings, so as to fully understand the purpose, features and effects of the present invention.

[0121] Example 1

[0122] A target controller configuration data system includes a physical layer, a logical layer, and an interface layer:

[0123] The physical layer is used to describe the hardware configuration information of the target controller, including the physical location, device type and quantity, and the communication protocol of the main safety control unit. The physical layer includes multiple RACK structures corresponding to multiple chassis of the target controller, and the RACK structure includes multiple LRU structures that record different hardware modules of the cage;

[0124] The logic layer is used to describe a logic set, wherein the elements of the logic set are logic objects. The logic layer includes a plurality of OBJECT structures for storing the logic objects, and the OBJECT structures include data parameter information and data type information;

[0125] The interface layer is used to describe the communication between different LRU structures and bind the physical layer and the logical layer. The interface layer includes an INTERFACES structure for describing the communication information of the interface layer. The INTERFACES structure includes an INTER_OBJECT structure. The INTER_OBJECT structure includes several SAFE configuration items.

[0126] This embodiment divides the configuration data into three layers: logic, physical, and interface, which can clearly store the diverse and complex special parameters and communication information of the hardware boards.

[0127] Example 2

[0128] This embodiment further elaborates on the physical layer based on the first embodiment. In this embodiment, the physical layer abstracts the hardware configuration information of the target controller, including the physical location (cage, rack location), device type and quantity, and the communication protocol configuration of the main safety control unit, into an equivalent data structure. The data structure is defined as follows: Figure 1 shown.

[0129] In this embodiment, the number of chassis for each target controller is obtained based on the input document (interface code table), and the corresponding number of RACK configuration items is defined in the physical layer configuration. That is, a corresponding RACK configuration item is generated for each chassis in turn. The cage information in the interface code table is split and abstracted into the number attribute RACK_NB and the capacity attribute RACK_SIZE. Based on the hardware conditions, the capacity attribute is set to a fixed value. The primary and standby hardware board mapping relationship array is defined according to the design rules, consisting of the slot position of the main board and the slot position of the redundant standby board. The mapping rules are fixed, and the primary and standby hardware board mapping relationship array is queried, and the REDUNDANT_LRU_ID attribute is set to record the redundancy relationship between the main module and the standby module.

[0130] Convert different hardware modules on a rack into an LRU structure. Each hardware module (LRU) defines LRU_ID, LRU_SLOT, LRU_NAME, and LRU_TYPE to record the hardware number, physical location, name, and type of the hardware board. The electronic stamp string used for the electronic error prevention mechanism of the safety control unit is stored as a 13-bit string in the LRU_CODE attribute. The LRU structure is as follows: Figure 2 shown.

[0131] Define the LRU_PARAM structure to store hardware module-specific parameter data. The parameter data of the hardware module consists of the specific parameter data values ​​of the hardware boards related to the target controller, the common data values ​​of the board parameters (including the common data values ​​of the special parameters of the EIOCOM-4 board (communication processing board), VOOB16-2 board, VIIB32S-2 board, VIIB32D-2 board, SDDM-2-110-LED board, SDDM-2-220-LED board, SDDM-2-220-TJS board, PDDM46-2 board, PDDM5-2 board, TCIM-2 board, and SIOM-2 board), the actual data values ​​of the board parameters (including the actual data values ​​of the special parameters of the SDDM-2-110-LED board, SDDM-2-220-LED board, SDDM-2-220-TJS board, PDDM46-2 board, PDDM5-2 board, and SIOM-2 board), and the special data values ​​of the board parameters. The LRU_COM configuration item defined in the LRU_PARAM structure is used to define the parameter data of the main control unit. The FILETYPE configuration item is defined to store the parameters of the hardware board. The NAME attribute of the FILETYPE configuration item is used to indicate the type of binary file loaded into the safety control unit. The final value calculation steps of the hardware board parameter data are as follows:

[0132] 1. Traverse the Special_Parameters.xml file that stores the specific parameter data values ​​of the target controller's related hardware boards. For each hardware type, traverse its parameter name and parameter value, use the parameter value as the key, and establish a key-value pair dictionary. Finally, a specific parameter data dictionary of the target controller's related hardware boards is formed with the hardware type keyword as the key and the <parameter name, parameter value> dictionary as the value.

[0133] 2. Traverse the general data value record table of the hardware board parameters, and use the general parameter values ​​to update and supplement the specific parameter data dictionary established in step 1 to obtain a new parameter data dictionary with general parameter information.

[0134] 3. Traverse the actual data value record table of the hardware board parameters, and use the actual application parameter values ​​to update and supplement the parameter data dictionary established in step 2 to obtain a new parameter data dictionary with actual application parameter information.

[0135] 4. Using the hardware board type as the keyword, query the parameter data dictionary above and generate N parameter data of the board in the FILETYPE configuration item in sequence.

[0136] 5. Finally, add special parameter values ​​unique to the board type.

[0137] In this embodiment, in the LRU structure storing the main safety control unit module, a CELL structure is provided to decompose and store the hardware structure, so as to define the functions in the LRU and the communication configuration information contained in the main safety control unit.

[0138] The CELL structure is defined as Figure 3 As shown in Figure 1. CELL_COM is used for the Ethernet network unit defined in the main safety control module and is defined only in the main safety control unit. The CELL_COM structure is closely associated with various network layers, enabling interaction during communication through the use of COM units.

[0139] Example 3

[0140] This embodiment further elaborates on the logical layer based on the embodiment 2. Similar to the physical layer, the logical layer is defined to describe the logical set and is not limited to the directly connected hardware architecture, wherein the elements of the logical set are logical objects, and the physical layer abstracts the structure between the logical objects to store the mapping relationship between objects, including logical mapping and physical mapping. The logical object OBJECT structure is defined to store logical objects. Logical objects include two types: physical type and logical type. The physical type describes the interaction relationship between input and output and the physical unit, while the logical type describes the interaction relationship between output and data generated by the logical pair or the data used by the logical object. Therefore, the OBJECT structure contains data parameter information and data type information. Its structure is as follows: Figure 4 shown.

[0141] The OBJECT object defines three attributes in sequence: OBJ_TYPE, OBJECT_DESCR, and OBJECT_NAME.

[0142] OBJ_TYPE is used to describe the type of logical object. When the logical object is used to define the input and output communication module, the value of OBJ_TYPE item defines<OBJ_MSG> or<OBJ_COM> The logical object type for sending or receiving USIG messages is OBJ_MSG. When the logical object OBJECTE is used to define the logical configuration of a hardware board, the value of the OBJ_TYPE item of the OBJECT configuration should be defined as OBJ_GUEST.

[0143] OBJECT_DESCR is used to describe the transmission type of interactive information, and OBJECT_NAME is used to record the name of the logical module.

[0144] In this embodiment, an OBJECT entity consists of the following elements:

[0145] 1. Global attributes (the attributes are the same for all types of objects)

[0146] 2.MAPPING structure, used to describe different inputs and outputs between objects.

[0147] 3. SPECIFIC structure, used to describe special parameters for objects and describe other objects or unit processing unit data. The steps to generate the configuration file logic layer are as follows:

[0148] First, establish the OBJECT structure of the communication processing board of the target controller system, which describes the code position information sent by the interlocking control system to the target controller system, the code position information sent by the target controller to the interlocking control system, the code position required by the communication processing board for the master-slave mutual synchronization SN, the code position information customized by the communication processing board for output to the interlocking control system, and the code position information of the constant 1 sent by the interlocking control system to the target controller.

[0149] Secondly, define a corresponding OBJECT structure according to each hardware board.

[0150] In this embodiment, the steps for generating the input-output relationship in the MAPPING element of each logical object of the OBJECT structure are as follows:

[0151] 1. Read the code configuration table of the hardware board, generate input and output code bits according to the board type, and store them in the input and output code bit array of the board object

[0152] 2. Generate one or more INPUT and OUTPUT configuration items based on the input / output code points.

[0153] The number of INPUT configuration items is determined by the number of external input code points of the logical object described by the OBJECT structure, while the number of OUTPUT configuration items is determined by the number of external output code points of the logical object described by the OBJECT structure. The external input and output code points of a logical object consist of the input / output code points actually defined for each board in the code point table (the valid code point array obtained from the code point table in step 1) and other input / output code points. Other code points primarily include broadcast connections between logical objects, such as input information generated by a physical hardware module and received by two or more different hardware modules, and local connections, such as information exchanged within the same hardware module. Therefore, if the logical object containing the MAPPING configuration defines the logical configuration for receiving data from a communications processing unit (communications processing board), an INPUT configuration item is required in the MAPPING configuration. If the logical object containing the MAPPING configuration defines the logical configuration for sending data from a communications processing unit (communications processing board), an OUTPUT configuration item is required in the MAPPING configuration. When the logical object where the MAPPING configuration is located is used for the logical configuration of the master and slave boards, the actual code position and the information transmitted between the master and slave boards must be defined in the MAPPING.

[0154] If a logical object does not define an input code bit (all logical objects of non-input and output communication modules have no output code bits, and the input and output communication module does not output a constant 1 code bit to the communication node), the logical object corresponding to the communication node (i.e., the OBJECT named OBJ_COM_OUTGOING) is not generated.

[0155] If a logical object does not define an output code bit (all non-input and output communication modules have no input code bits, and the communication node does not output a constant 1 code bit to all non-input and output communication modules), the logical object corresponding to the communication node (i.e., the OBJECT named OBJ_COM_INCOMING) is not generated.

[0156] In this embodiment, the SPECIFIC structure of the OBJECT structure is defined as follows:

[0157] When an OBJECT structure is used to define an I / O communication module and OBJ_TYPE is OBJ_MSG, two OBJECT_COM_MSG configuration items are defined in the OBJECT's SPECIFIC configuration item. OBJECT_COM_MSG is configured with two properties: MESSAGE_ID and DIRECTION. When the object is loaded into a message, the DIRECTION property indicates whether the message is "produced" or "consumed."

[0158] The OBJECT_COM_MSG configuration item should contain one or more DATA_MAPPING configuration items. The number of DATA_MAPPING configuration items is determined by the number of receive code points (OUTPUT) or transmit code points of the OBJECT configuration item in which the OBJECT_COM_MSG configuration item is located. The DATA_MAPPING structure defines the IO_NUMBER and OFFSET attributes. The value of IO_NUMBER should start at 1 and increase sequentially. The specific number of OBJECT_COM_MSG configuration items in the first OBJECT configuration item depends on the total number of receive code points of the OBJECT (when the OBJECT configuration is used to define the logical configuration of cell unit data reception (OUTPUT)). The specific number of OBJECT_COM_MSG configuration items in the second OBJECT configuration item depends on the number of transmit code points of the A system in which the OBJECT is located (when the OBJECT configuration is used to define the logical configuration of cell unit data transmission (INPUT)). The value of the OFFSET attribute should start at 0 and increase sequentially to describe the length of the message.

[0159] Example 4

[0160] This embodiment further elaborates on the interface layer based on embodiment 3. The interface layer defines the communication between internal buses. The INTERFACES structure is defined to describe the communication information of the interface layer. INTERFACES defines an INTER_OBJECT structure, which contains one or more SAFE configuration items. SAFE has four attribute items: LRU_ID, DIRECTION, DATA_NAME, and DATA_ID. The structure is as follows: Figure 5 shown.

[0161] SAFE includes the custom code bits required by the communication processing board for master and slave synchronization, custom code bit information output to the interlocking control system, the constant 1 code bit information sent by the interlocking control system to the target controller, and the logical interaction information corresponding to each hardware board. Specifically, a SAFE configuration item is defined for each INPUT configuration item and OUTPUT configuration item of the logical object (OBJECT_NAME OBJ_COM_1) used to define the communication processing board and the logical objects of each slave board.

[0162] LRU_ID: The slot number of the hardware board to which the current communication information belongs.

[0163] DIRECTION: describes whether the SAFE configuration item is the input or output of the corresponding logical object OBJECT structure MAPPING configuration.

[0164] DATA_NAME: The name of the external input or output code point.

[0165] DATA_ID: The INPUT or OUPUT code corresponding to the same board increases starting from 1.

[0166] Example 5

[0167] A method for generating target controller configuration data comprises the following steps:

[0168] Step 1: Prepare the input file and define the file path in the input configuration file Config.tab.

[0169] Step 2: Create an object class library and abstract the three-layer structure into structural classes such as InterfaceStruct, LogStruct, and PHYStruct.

[0170] Step 3: read the input document defined by the input configuration file Config.tab, obtain the communication parameter dictionary, the basic special parameter dictionary [board type, special parameter], the general special parameter dictionary [board type, special parameter], the configurable special parameter dictionary [board type, special parameter], the board general code bit suffix dictionary [board type, suffix structure], and the suffix structure is a structure containing the board input suffix and the output suffix, and the board configurable code bit suffix dictionary [board type, suffix structure].

[0171] Step 4, establish the target controller protocol dictionary of the target station through the internal device information table (input document), and store it in the format of key-value pair [target controller number, protocol];

[0172] Step 5, according to the physical location information (cage, rack, and target controller number) of each hardware board card stored in the interface code bit table (input document), establish a key-value pair [target controller number, hardware board card object set], wherein the target controller number is the number of the target controller to which the hardware board card object set belongs.

[0173] Step 6, according to the design needs, complete the redundant hardware board card information of the target controller using dual system configuration, which has the same communication information as the main board card, and the physical location is obtained in a pre-defined manner. The corresponding redundant board card object is added to the hardware board card object set corresponding to the current target controller in [target controller number, hardware board card object set] in step 5.

[0174] Step 7, traverse [target controller number, hardware board card object set] to establish a physical layer PHY_STRUCT structure object, establish a Rack structure (RackStruct) according to the cage number of the hardware board card, and establish a board card object LRU (LRUStruct) for each hardware board card in the Rack. The hardware board card characteristic description attribute of the LRU object is determined by the type of the hardware board card.

[0175] Step 8, establish a special parameter set for each LRU object. First, traverse the basic special parameter dictionary obtained in step 3, generate the parameter set A of the LRU object based on the board type attribute of the current LRU object. Second, traverse the general special parameter, query the special parameter corresponding to the board type of the current LRU object, and cover the value of the special parameter with the same name in parameter set A to obtain parameter set B updated by the general special parameter. Finally, update set B with the configurable special parameter dictionary to obtain the final special parameter set of the LRU object.

[0176] Step 9, merge the board general code bit suffix dictionary [board type, suffix structure] and the board configurable code bit suffix dictionary [board type, suffix structure] obtained in step 3, and update the general code bit suffix with the configurable suffix.

[0177] Step 10: traverse the updated board suffix dictionary [board type, suffix structure] to query the suffix structure of the LRU object, and store the input and output code bits of the LRU object in the input code bit set and the output code bit set of the board object. Specifically as follows:

[0178] Step 1: traverse each valid code bit of the board (skip empty ports);

[0179] Step 2: according to the valid code bit, the suffix is intercepted, and the suffix dictionary is queried according to the board type to obtain the suffix structure.

[0180] Step 3: traverse the suffix structure (sufficStruct) of the board, combine the valid code bit with the suffix, and obtain the input and output code bits.

[0181] Step 11: according to the type of the LRU object, add special parameters specific to the object to the special parameter set of the LRU object.

[0182] Step 12: traverse the target controller protocol dictionary in step 4 to obtain the protocol type of the current target controller.

[0183] Step 13, based on the IP configuration information in the engineering design document, the communication parameter dictionary obtained in step 3, and the protocol type obtained in step 12, generate the network communication unit of the input and output module of the target controller, and store it in the CellStruct structure.

[0184] Step 14, according to the input and output code bit set of the board object and the type of the LRU object, generate InterfaceStruct and LogStruct. For different LRU objects, according to their board type, increase the master-slave intercommunication code bit and other exclusive input and output code bit.

[0185] Step 15, serialize the object of the class into an xml string and save it to a file.

[0186] The embodiments of the application are specifically described above, but the application is not limited to the described embodiments, and those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the application. These equivalents or replacements are all included in the scope defined by the claims of the application.

Claims

1. A target controller configuration data system, characterized in that: Including physical layer, logical layer and interface layer: The physical layer is used to describe the hardware configuration information of the target controller, including the physical location, device type and quantity, and the communication protocol of the main safety control unit. The physical layer includes multiple RACK structures corresponding to multiple chassis of the target controller, and the RACK structure includes multiple LRU structures that record different hardware modules of the cage; The logic layer is used to describe a logic set, wherein the elements of the logic set are logic objects. The logic layer includes a plurality of OBJECT structures for storing the logic objects, and the OBJECT structures include data parameter information and data type information; The interface layer is used to describe the communication between different LRU structures and bind the physical layer and the logical layer. The interface layer includes an INTERFACES structure for describing the communication information of the interface layer. The INTERFACES structure includes an INTER_OBJECT structure, and the INTER_OBJECT structure includes several SAFE configuration items. In the physical layer, the RACK structure further includes: RACK_NB for recording the cage number attribute and RACK_SIZE for recording the cage capacity attribute. Each LRU structure includes: Record the LRU_ID of the hardware number; LRU_SLOT that records the physical location of the hardware; LRU_NAME records the hardware name; LRU_TYPE records the hardware board type; LRU_CODE that stores the electronic stamp string of the electronic error prevention mechanism of the safety control unit; LRU_PARAM structure that stores hardware module-specific parameter data; Decompose and store the hardware structure to define the functions in the LRU and the CELL structure of the communication configuration information contained in the main safety control unit; In the logic layer, the OBJECT structure includes: Global attributes, including OBJ_TYPE for describing the type of the logical object, OBJECT_DESCR for describing the transfer type of interactive information, and OBJECT_NAME for recording the name of the logical module; A MAPPING structure used to describe different input and output between logical objects. The MAPPING structure includes INPUT configuration items and OUTPUT configuration items. Used to describe special parameters for logical objects and describe the SPECIFIC structure of other objects or unit processing unit data; In the MAPPING structure, the number of INPUT configuration items is determined by the number of external input code points of the logical object described by the OBJECT structure, and the number of OUTPUT configuration items is determined by the number of external output code points of the logical object described by the OBJECT structure. If a logical object does not define input code points or output code points, the logical object corresponding to the communication node is not generated. In the SPECIFIC structure, when the OBJECT structure is used to define an input / output communication module and OBJ_TYPE is OBJ_MSG, two OBJECT_COM_MSG configuration items are defined in the SPECIFIC configuration item of OBJECT as special parameters of the expected message object; the OBJECT_COM_MSG is configured with two attribute items, MESSAGE_ID and DIRECTION, and one or more DATA_MAPPING configuration items; The number of DATA_MAPPING configuration items is determined by the number of received code bits or sent code bits of the OBJECT configuration item where the OBJECT_COM_MSG configuration item is located. The IO_NUMBER and OFFSET attribute items are defined in sequence in the DATA_MAPPING structure. In the interface layer, each SAFE configuration item includes: LRU_ID of the slot number of the hardware board to which the current communication information belongs; The SAFE configuration item is described as the DIRECTION of the input or output of the MAPPING configuration of the corresponding logical object OBJECT structure; DATA_NAME is the name of the external input or output code point; The DATA_ID of the INPUT or OUPUT code corresponding to the same board increases starting from 1.

2. The system according to claim 1, wherein In the LRU_PARAM structure, the parameter data of the hardware module includes the specific parameter data values ​​of the hardware board related to the target controller, the general data values ​​of the board parameters, the actual data values ​​of the board parameters, and the special data values ​​of the board parameters; The LRU_PARAM structure includes: an LRU_COM configuration item for defining parameter data of the main control unit; A FILETYPE configuration item is used to store parameters of the hardware board. The NAME attribute of the FILETYPE configuration item is used to indicate the type of binary file loaded into the safety control unit.

3. A method for generating target controller configuration data of a system according to any one of claims 1 to 2, characterized in that: The following steps are involved: S1. Prepare the input file, define its file path in the input configuration file Config.tab, create an object class library, read the input document defined in the input configuration file Config.tab, and obtain various parameter dictionaries; S2. Using the input document, a target station target controller protocol dictionary is created and stored, and a key-value pair [target controller number, hardware board object collection] is created; S3. Traverse [target controller number, hardware board object set] to establish the physical layer, and establish a board object LRU for each hardware board. Then, establish a special parameter set for each LRU object, and add object-specific special parameters to the special parameter set of the LRU object based on the type of the LRU object. S4. Traverse the target controller protocol dictionary to obtain the protocol type of the current target controller, and generate and store the network communication unit of the input and output module of the target controller based on the IP configuration information, communication parameter dictionary, and protocol type in the engineering design document; S5. Generate the logic layer and interface layer according to the input and output code bit sets of the board object and the type of the LRU object, and serialize the class object into an XML string and save it to a file.

4. The generation method according to claim 3, wherein: In the S1 step, the various parameter dictionaries include a communication parameter dictionary, a basic special parameter dictionary [board type, special parameters], a general special parameter dictionary [board type, special parameters], a configurable special parameter dictionary [board type, special parameters], a board-universal code suffix dictionary [board type, suffix structure], and a board-configurable code suffix dictionary [board type, suffix structure].

5. The generation method according to claim 3, wherein: The S2 step includes the following steps: S21. Using the internal device information table of the input document, a target station target controller protocol dictionary is established and stored in the format of key-value pairs [target controller number, protocol]. S22. Create a key-value pair [target controller number, hardware board object set] based on the physical location information of each hardware board stored in the interface code table of the input document, where the target controller number is the number of the target controller to which the hardware board object set belongs; S23. Complete the information of the redundant hardware board of the target controller with dual-system configuration. Its communication information is the same as that of the main board. The physical location is obtained in a predefined manner. Add the corresponding redundant board object to the hardware board object set corresponding to the current target controller in [target controller number, hardware board object set] in step S22.

6. The generation method according to claim 3, wherein: The S3 step includes the following steps: S31, traverse [target controller number, hardware board object set], create a physical layer PHY_STRUCT structure object, create a Rack structure according to the cage number of the hardware board, and create a board object LRU for each hardware board in the Rack; S32. Establish a special parameter set for each LRU object. First, traverse the basic special parameter dictionary and generate parameter set A for the LRU object based on the board type attribute of the current LRU object. Second, traverse the general special parameter dictionary to query the special parameters corresponding to the board type of the current LRU object, overwrite the values ​​of the special parameters with the same name in parameter set A, and obtain parameter set B updated with the general special parameters. Finally, update set B with the configurable special parameter dictionary to obtain the final special parameter set for the LRU object. S33. Merge the board universal code point suffix dictionary [board type, suffix structure] and the board configurable code point suffix dictionary [board type, suffix structure], and use the configurable suffix to update the universal code point suffix. S34, traverse the updated card suffix dictionary [card type, suffix structure], query the suffix structure of the LRU object, and store the input and output code points of the LRU object in the input code point set and output code point set of the card object; the details are as follows: Step 1: Traverse every valid code position of the board; Step 2: Extract the suffix based on the valid code position, query the suffix dictionary based on the board type, and obtain the suffix structure; Step 3: Traverse the suffix structure of the board, merge the valid code position with the suffix, and obtain the input and output code positions; S35. According to the type of the LRU object, add the object-specific special parameters to the special parameter set of the LRU object.

Images