Intelligent rail transit system multi-device association method, system, device and storage medium

Abstract

The application relates to a smart rail transit system multi-device association method, system, device and storage medium, the method comprising the following steps: S1, according to whether a device state is affected, an association quantity and association reference information, type classification is performed on a device association relationship, a metadata template under each type is constructed, and the metadata template is stored in a Key-Value in-memory database; S2, based on the metadata template, a device association relationship static model based on a functional requirement is constructed and data storage is performed; S3, device association relationship data is loaded from the Key-Value in-memory database, a device association relationship dynamic model is constructed, and dynamic attribute association is performed; S4, an observer for listening to a device state change event is created on the device, and the device association relationship is updated in real time according to a listening result. Compared with the prior art, the application has the advantages of high reliability, good real-time performance and high flexibility.

Description

Technical Field

[0001] This invention relates to the field of rail transit equipment management, and in particular to a method, system, equipment, and storage medium for associating multiple devices in an intelligent rail transit system. Background Technology

[0002] Smart city rail transit systems typically integrate information from multiple disciplines, including the signaling system (ATS), power supply system (PSCADA), environmental and equipment monitoring system (BAS), access control system (ACS), fire alarm system (FAS), fare collection system (AFC), public address system (PA), passenger guidance system (PIS), and closed-circuit television system (CCTV), to achieve information fusion and comprehensive analysis.

[0003] Currently, intelligent rail transit systems aggregate data from multiple disciplines and various devices through real-time data platforms, enabling rapid response to changes in data collection points and real-time updates to equipment status. For example, vehicle operation information, signal equipment status, power supply conditions, and platform screen door operating status are all integrated into the intelligent rail transit system, and the data information can be processed and analyzed. However, comprehensive analysis of the relationships between devices is rarely addressed, even though the devices in these systems actually influence, constrain, and verify each other. The main reason for this is that the real-time database of intelligent rail transit systems often uses relational databases to define devices and their attributes, using association tables to describe the relationships between devices. This approach leads to the following problems during use:

[0004] First, the relationships between different professions and types of equipment within the system are complex and diverse. Therefore, it is usually necessary to create an independent association table for each relationship. Moreover, adding a new association requires redesigning and implementing it. There will be a large number of association tables to process in the system, which increases the complexity and expansion difficulty of the system.

[0005] Second, relational database technology cannot well describe one-to-many and many-to-many relationships between devices, making it inconvenient to use and affecting operational efficiency.

[0006] Third, the application cannot be notified in a timely manner when the relationship changes, and the detection is usually carried out by polling, which reduces the real-time performance and availability of the entire system.

[0007] Therefore, there is an urgent need to design a method and system for multi-device association in a smart rail transit system that is highly reliable and has good real-time performance. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the existing technology and provide a highly reliable and real-time intelligent rail transit system multi-device association method, system, device and storage medium. By summarizing and defining the association relationships between various types of devices, it can promptly detect and respond to changes in association relationships and changes in the dynamic attributes of devices with established relationships.

[0009] The objective of this invention can be achieved through the following technical solutions:

[0010] According to a first aspect of the present invention, a method for associating multiple devices in an intelligent rail transit system is provided, the method comprising:

[0011] Step S1: Based on whether the device status affects the relationship, the number of associated devices, and the associated reference information, classify the device association relationships into types, construct metadata templates for each type, and store them in a Key-Value in-memory database.

[0012] Step S2: Based on the metadata template, construct a static model of device association relationships based on functional requirements and store the data;

[0013] Step S3: Load device association data from the Key-Value in-memory database, construct a dynamic model of device association, and perform dynamic attribute association;

[0014] Step S4: Create an observer on the device to listen for device state change events, and update the device association in real time based on the listening results.

[0015] Preferably, the classification of device association relationships based on whether they are affected by device status, the association form, and the association reference value includes:

[0016] Type 1 relationship: describes a fixed and unchanging association between two devices;

[0017] The second type of relationship describes the correlation between changes between two devices, with the reference value defined on the device data;

[0018] The third type of relationship describes the correlation between changes between two devices, with the reference value defined on the relationship data;

[0019] The fourth type of relationship describes the association between a device and a class of devices, with the reference value defined in the device data;

[0020] The fifth type of relationship describes the association between a device and a class of devices, with reference values ​​defined in the relationship data; and

[0021] The sixth type of relationship describes the association between one type of equipment and another type of equipment.

[0022] Preferably, the construction of metadata templates for each type in step S1 specifically includes the following sub-steps:

[0023] Step S11: Define the attributes of various types of relationships using JSON format string specifications. The data for each type of relationship includes primary key, type, name, associated device, associated device type, relationship name, reference value, and reference attribute name.

[0024] Step S12: Define the relationship structure. Each type of relationship only sets static attributes including associated device and reference value information, and stores the corresponding data in a key-value in-memory database.

[0025] Step S13: Define the attributes of the relational quantity measurement through the JSON format string specification. The relational quantity measurement takes the list of devices with established relationships as input, and transforms and updates the corresponding dynamic attributes according to predefined rules.

[0026] Step S14: Define the measurement structure and store the corresponding data in a key-value in-memory database.

[0027] Preferably, the attributes of the measurement data include:

[0028] Static attributes: relation name, type, name, input parameters, conversion method, and alarm parameters;

[0029] Dynamic attributes: value, quality flag, and update time.

[0030] Preferably, step S2 includes the following sub-steps:

[0031] Step S21: Based on the product function definition, the equipment included in each specialty, the relationships between various types of equipment, the measurement of relationships, and the relationship between data and equipment, construct a static model of equipment relationships based on functional requirements.

[0032] Step S22: Based on the static model of equipment association, generate association relationships and relationship quantity measurement data in batches using the data configuration tool;

[0033] Step S23: Customize and modify the static model of equipment association relationships;

[0034] Step S24: Define the input parameters for relational quantity measurement. The input parameters related to the association relationship are divided into static attribute types and dynamic attribute types of the association relationship device set.

[0035] Step S25: Store the device association relationship and relationship quantity measurement data as a hash type in the key-value in-memory database.

[0036] Preferably, step S25 further includes storing the relational data and relational quantity measurements as a list type of key-value pair in-memory database onto the relevant device data to clarify the subordinate relationship of the data.

[0037] Preferably, step S23 specifically involves: customizing the static model of device association relationships according to specific requirements and principles, including but not limited to adding, adjusting, and deleting device association relationships and relationship quantity measurements; wherein, the principles include: the association relationship data must be equivalent, that is, both devices establishing the association relationship must define relationship data and reference each other; the relationship quantity measurement must be defined on the device to which the association relationship belongs or on the sub-device of the device to which the association relationship belongs, depending on the type of association relationship.

[0038] Preferably, step S3 includes the following sub-steps:

[0039] Step S31: Load the metadata template from the Key-Value in-memory database;

[0040] Step S32: Load device, association, and relation measurement data, and verify them according to the metadata template defined by the type attribute. Repeat this process until all static data defined by the data model is loaded.

[0041] Step S33: Perform pairing operations on all related relationship data. If a match is successful, create sub-type relationship data on the sub-devices contained in the device according to the device type and match it with the related relationship data of the parent device to form a complete relationship topology. If a match fails, discard the related relationship data and record it in the log.

[0042] Step S34: Create and register a status observer on the device according to the association relationship and the measurement requirements of the relationship quantity, so as to listen for device status change events in real time.

[0043] Preferably, step S4 includes the following sub-steps:

[0044] Step S41: Listen for device attribute change events that affect the relationship in real time through the device status observer. When the device attribute changes, detect whether the relationship between devices changes according to preset conditions. When the relationship changes, trigger the corresponding event to notify the corresponding associated device object.

[0045] Step S42: When the association is established, the next level observer is started to listen. When the relevant dynamic attributes of the associated device change, the input point value of the relationship quantity measurement will be updated in time, and then the relationship quantity measurement and the dynamic attributes of the corresponding device can be updated, as well as triggering alarms and other subsequent actions.

[0046] Step S43: Update the generated relevant data changes to the key-value in-memory database in real time and broadcast them within the system.

[0047] According to a second aspect of the present invention, a system based on the aforementioned intelligent rail transit system multi-device association method is provided, the system comprising:

[0048] The metadata template construction module classifies device association relationships into types based on whether they are affected by device status, the number of associations, and the association reference information, constructs a metadata template for each type, and stores it in a Key-Value in-memory database;

[0049] The static relationship model building module is used to build a static model of device association relationships based on functional requirements and store the data, based on metadata templates;

[0050] The dynamic relationship model building module is used to load device relationship data from the Key-Value in-memory database, build a dynamic model of device relationships, and perform dynamic attribute association.

[0051] The listener update module is used to create observers on the device to listen for device state change events and update the device association relationships in real time based on the listening results.

[0052] According to a third aspect of the present invention, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described thereon.

[0053] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described thereon.

[0054] Compared with the prior art, the present invention has the following advantages:

[0055] 1) This invention summarizes and abstracts the relationships between rail transit equipment into various types, thereby enabling the standardized and normalized definition of the relationships between various equipment.

[0056] 2) It fully leverages the efficiency and flexibility of Key-Value in-memory databases and JSON format strings, and can perform validation through metadata definitions, thus achieving data reliability and consistency.

[0057] 3) Combine static and dynamic relationship models. Define the relationships between parent devices in the static relationship model, and then expand and concretize them in the dynamic relationship model. Describe the real relationship by creating relationships between associated child devices and parent devices. In this way, adding child devices does not require modifying the static relationship data, reducing the preparation of configuration data, simplifying system design and implementation, and ensuring the integrity and consistency of data.

[0058] 4) By adopting an event-driven model, the system responds in real time to changes in relationships and device status, enhancing its real-time performance and availability. Attached Figure Description

[0059] Figure 1 This is a flowchart of the method of the present invention;

[0060] Figure 2 This is a diagram illustrating the relationship between the equipment.

[0061] Figure 3 This is a schematic diagram of device relationship data storage; where, Figure 3 a to 3d correspond to the attribute information of the relationship type Schema:Relevanty:Bucket, RSStatistics:Bucket1, Signal:Bucket1, and Window1:RSTotalFault, respectively.

[0062] Figure 4 Prepare flowcharts for equipment relationship model data;

[0063] Figure 5 Load and create flowcharts for the dynamic model of device relationships;

[0064] Figure 6 A flowchart for real-time processing of the device relationship model. Detailed Implementation

[0065] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0066] Example

[0067] like Figure 1 As shown in the figure, this embodiment presents a method for associating multiple devices in a smart rail transit system, which includes:

[0068] Step 1: Based on whether the device status affects the relationship, the number of associated devices, and the associated reference information, classify the device association relationships into types, construct metadata templates for each type, and store them in a Key-Value in-memory database;

[0069] Step 2: Based on the metadata template, construct a static model of device relationships based on functional requirements and store the data;

[0070] Step 3: Load device association data from the Key-Value in-memory database, build a dynamic model of device association, and perform dynamic attribute association;

[0071] Step 4: Create an observer on the device to listen for device status change events, and update the device association in real time based on the listening results.

[0072] The following is a detailed description of each step of the present invention.

[0073] First, refer to Figures 2-3 This section introduces the modeling process of the device relationship model in this embodiment.

[0074] Step 101: Define a template for general relationship data and categorize the relationships between devices into six types: Fixed, Switch, Select, Muster, Cluster, and Bucket.

[0075] 1) Static relationships unaffected by the status of rail transit equipment, including:

[0076] Fixed: Used to describe a fixed and unchanging relationship between two rail transit devices;

[0077] 2) Dynamic relationships that change with the dynamic attributes of rail transit equipment, including:

[0078] Switch: Used to describe the relationship between changes in two rail transit devices; the reference value is defined in the device data.

[0079] Select: Used to describe the relationship between changes in two rail transit devices; the reference value is defined on the relationship data.

[0080] Muster: Used to describe the relationship between a rail transit device and a class of rail transit devices; the reference value is defined in the device data.

[0081] Cluster: Used to describe the relationship between a rail transit device and a class of rail transit devices; reference values ​​are defined in the relational data.

[0082] Bucket: Used to describe the relationship between one type of rail transit equipment and another type of rail transit equipment.

[0083] Among them, Fixed, Select, and Bucket are peer-to-peer relationships, while Switch, Muster, and Cluster are non-peer-to-peer relationships. For example... Figure 2 The diagram illustrates the device and relationship class diagram using a Bucket type relationship as an example. The Bucket type defines the relationship between two types of devices, which is a many-to-many relationship. The specific device types are defined by the ReferEquipmentType of their respective parent device's relationship data. When the ReferVarName attribute value of device A (e.g., SubEquipmentA1) and the ReferVarName attribute value of device B (e.g., SubEquipmentB1) meet specific conditions, SubEquipmentA1 and SubEquipmentB1 establish an association relationship.

[0084] Step 102, according to Figure 2 The description defines the metadata template for relationships, which serves as the basis for data creation. The metadata template only includes the static parts of the relationships. Figure 3 For example, static properties for the Relevancy: Bucket type relationship are defined, including Key, Type, Classify, Name, ReferEquipmentType, ReferVarName, RelevancyEquipment, and RelevancyName. These are all defined using JSON format strings. For instance, the ReferEquipmentType property is defined as {"type":"string","origin":"input","default":""}, meaning ReferEquipmentType is a string type, and its value is defined during data creation with no default value. The Key property serves as a unique identifier for the metadata template, and the Classify property describes the category of the metadata template, defined as Relevancy during design phase, indicating that the data represents a relational relationship.

[0085] Step 103: Define the relationship data between devices based on the metadata template from Step 102. Two relationship data points form a complete relationship, defined on the corresponding devices. If the relationship includes a class device relationship, then the relationship data should be defined on the parent device, and the child device with type (ReferEquipmentType) participates in the analysis of the relationship. If the relationship data is defined on the root node of the data model, it means that all devices with type (ReferEquipmentType) in the model participate in the analysis of the relationship. Figure 3 As shown, the relationship data between RSStatistics:Bucket1 and Signal:Bucket1 is defined on the RSStatistics and Signal devices respectively. RSStatistics:Bucket1's RelevancyEquipment is Signal, and its RelevancyName is Bucket1. Signal:Bucket1's RelevancyEquipment is RSStatistics, and its RelevancyName is Bucket1, indicating that RSStatistics:Bucket1 and Signal:Bucket1 are peer-to-peer data. RSStatistics:Bucket1's ReferEquipmentType is RollingStock, and Signal:Bucket1's ReferEquipmentType is Window, indicating that this relationship actually defines a many-to-many relationship between a device belonging to the RSStatistics device with type RollingStock and a device belonging to the Signal device with type Window.

[0086] Secondly, refer to Figure 1 , Figure 3 and Figure 4 This section describes the data preparation process in this embodiment.

[0087] Step 201: Based on product functional requirements, compile and list the relationships between various devices, and define the relationship types and relationship quantity measurements. Relationship quantity measurements take the set of devices with which relationships are established as input, and therefore should be defined on the specific devices affected by the relationships. For example... Figure 3 As shown, Window1:RSTotalFault is defined on the Window1 device of type Window, not on the Signal device.

[0088] Step 202: Using the data configuration tool, define the relationships and quantity measurements between all devices in batches according to Step 201, and set the input information for the quantity measurements. For example... Figure 3 As shown, all Windows devices need to add a relational measurement named RSTotalFault and use the Bucket1 association as the input for this measurement.

[0089] Step 203: During project implementation, there are often situations that do not conform to the model template definition. In this step, the device relationship data model generated in step 202 can be adjusted, such as modifying the association between devices, adding relationship quantity measurement for specified devices, etc., in order to meet actual business needs.

[0090] Step 204: To facilitate the storage and retrieval of the Key-Value in-memory database, the metadata template data and device data are serialized, and a Key-Value in-memory database operation instruction set is generated, such as... Figure 3 As shown, both metadata templates and devices are stored in hash tables. The attribute definitions of the metadata templates are formatted in JSON format, for example, the key is defined as {"type":"string","origin":"input","default":""}, and the device attribute parameters are converted to strings. Then, the operation instruction set is executed to completely store the metadata templates and model data into the key-value in-memory database.

[0091] Then, refer to Figure 1 , Figure 5 Describes the process of loading and creating dynamic models at runtime.

[0092] Step 301: Load the metadata template (schema data) from the Key-Value in-memory database.

[0093] Step 302: Load the device, sub-devices, relationships on the device, and measurements. Validate the data according to the metadata template defined by the Type attribute, discarding invalid data and logging the results. Repeat this process until all static data defined in the data model is loaded.

[0094] Step 303: Perform pairing operations on all related relationship data. During the matching process, check for errors such as missing peer relationships or inconsistent peer relationship data. If a match is successful, create Child-type relationship data on the child devices contained in the device, and match it with the relationship data of the parent device to form a complete relationship topology diagram. If a match fails, discard the relationship data and log it.

[0095] Step 304: Create and register a state listener on the device according to the association relationship and relationship quantity measurement requirements so as to be able to listen for device state change events in real time.

[0096] Then, refer to Figure 1 , Figure 6 Describe the data processing process during the runtime of the dynamic model;

[0097] Step 401: Listen for device status change events in real time through the device status Listener.

[0098] Step 402: When a device status change event is received, check whether the association status is affected. If it changes, such as adding or removing devices with established associations, update the association and trigger a relationship change event. Further check whether the measurement status values ​​of the relevant relationship quantities have changed. If they have changed, update the quantity measurements and the corresponding device status.

[0099] Step 403: Publish the device status change and alarm processing procedures, and notify relevant data subscription modules and other systems.

[0100] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the described module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0101] The electronic device of this invention includes a central processing unit (CPU), which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) or loaded from a storage unit into random access memory (RAM). The RAM may also store various programs and data required for device operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0102] Multiple components in the device are connected to the I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0103] The processing unit executes the various methods and processes described above, such as methods S101-S103, S201-S204, S301-S304, and S401-S403. For example, in some embodiments, methods S101-S103, S201-S204, S301-S304, and S401-S403 may be implemented as computer software programs tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of methods S101-S103, S201-S204, S301-S304, and S401-S403 described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute methods S101-S103, S201-S204, S301-S304, and S401-S403 by any other suitable means (e.g., by means of firmware).

[0104] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0105] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0106] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0107] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for associating multiple devices in an intelligent rail transit system, characterized in that, The method includes: Step S1: Based on whether the device status affects the relationship, the number of associated devices, and the associated reference information, classify the device association relationships into types, construct metadata templates for each type, and store them in a Key-Value in-memory database. Step S2: Based on the metadata template, construct a static model of device association relationships based on functional requirements and store the data; Step S3: Load device association data from the Key-Value in-memory database, construct a dynamic model of device association, and perform dynamic attribute association, including the following sub-steps: Step S31: Load the metadata template from the Key-Value in-memory database; Step S32: Load device, association, and relation measurement data, and verify them according to the metadata template defined by the type attribute. Repeat this process until all static data defined by the data model is loaded. Step S33: Perform pairing operations on all related relationship data. If a match is successful, create sub-type relationship data on the sub-devices contained in the device according to the device type and match it with the related relationship data of the parent device to form a complete relationship topology. If a match fails, discard the related relationship data and record it in the log. Step S34: Create and register a status observer on the device according to the correlation and relation quantity measurement requirements, so as to listen for device status change events in real time; Step S4: Create a state observer on the device to listen for device state change events, and update the device association in real time based on the listening results.

2. The method for multi-device association in a smart rail transit system according to claim 1, characterized in that, The device association relationships are categorized based on whether they are affected by device status, the association type, and the association reference value, including: Type 1 relationship: describes a fixed and unchanging association between two devices; The second type of relationship describes the correlation between changes between two devices, with the reference value defined on the device data; The third type of relationship describes the correlation between changes between two devices, with the reference value defined on the relationship data; The fourth type of relationship describes the association between a device and a class of devices, with the reference value defined in the device data; The fifth type of relationship describes the association between a device and a class of devices, with reference values ​​defined in the relationship data; and The sixth type of relationship describes the association between one type of equipment and another type of equipment.

3. The method for multi-device association in a smart rail transit system according to claim 2, characterized in that, The construction of metadata templates for each type in step S1 specifically includes the following sub-steps: Step S11: Define the attributes of various types of relationships using JSON format string specifications. The data for each type of relationship includes primary key, type, name, associated device, associated device type, relationship name, reference value, and reference attribute name. Step S12: Define the relationship structure. Each type of relationship only sets static attributes including associated device and reference value information, and stores the corresponding data in a key-value in-memory database. Step S13: Define the attributes of the relational quantity measurement through the JSON format string specification. The relational quantity measurement takes the list of devices with established relationships as input, and transforms and updates the corresponding dynamic attributes according to predefined rules. Step S14: Define the measurement structure and store the corresponding data in a key-value in-memory database.

4. The method for multi-device association in a smart rail transit system according to claim 3, characterized in that, The attributes measured by the relation quantity include: Static attributes: relation name, type, name, input parameters, conversion method, and alarm parameters; Dynamic attributes: value, quality flag, and update time.

5. The method for multi-device association in a smart rail transit system according to claim 3, characterized in that, Step S2 includes the following sub-steps: Step S21: Based on the product function definition, the equipment included in each specialty, the relationships between various types of equipment, the measurement of relationships, and the relationship between data and equipment, construct a static model of equipment relationships based on functional requirements. Step S22: Based on the static model of equipment association, generate association relationships and relationship quantity measurement data in batches using the data configuration tool; Step S23: Customize and modify the static model of equipment association relationships; Step S24: Define the input parameters for relational quantity measurement. The input parameters related to the association relationship are divided into static attribute types and dynamic attribute types of the association relationship device set. Step S25: Store the device association relationship and relationship quantity measurement data as a hash type in the key-value in-memory database.

6. The method for multi-device association in a smart rail transit system according to claim 5, characterized in that, Step S25 further includes storing relational data and relational quantity measurements as a list type of key-value pair in-memory database onto the relevant device data to clarify the subordinate relationship of the data.

7. The method for multi-device association in a smart rail transit system according to claim 5, characterized in that, Step S23 specifically involves: making customized modifications to the static model of device association relationships according to specific requirements and principles, including but not limited to adding, adjusting, and deleting device association relationships and relationship quantity measurements; wherein, the principles include: the association relationship data must be equivalent, that is, both devices establishing the association relationship must define relationship data and reference each other; the relationship quantity measurement must be defined on the device to which the association relationship belongs or on the sub-device of the device to which the association relationship belongs, depending on the type of association relationship.

8. The method for multi-device association in a smart rail transit system according to claim 1, characterized in that, Step S4 includes the following sub-steps: Step S41: Listen for device attribute change events that affect the relationship in real time through the device status observer. When the device attribute changes, detect whether the relationship between devices changes according to preset conditions. When the relationship changes, trigger the corresponding event to notify the corresponding associated device object. Step S42: When the association is established, the next level observer is started to listen. When the relevant dynamic attributes of the associated device change, the input point value of the relationship quantity measurement will be updated in time, and then the relationship quantity measurement and the dynamic attributes of the corresponding device can be updated, and other actions such as triggering alarms can be triggered. Step S43: Update the generated relevant data changes to the key-value in-memory database in real time and broadcast them within the system.

9. A system based on the multi-device association method of the intelligent rail transit system according to claim 1, characterized in that, The system includes: The metadata template construction module classifies device association relationships into types based on whether they are affected by device status, the number of associations, and the association reference information, constructs a metadata template for each type, and stores it in a Key-Value in-memory database; The static relationship model building module is used to build a static model of device association relationships based on functional requirements and store the data, based on metadata templates; The dynamic relationship model building module is used to load device relationship data from the Key-Value in-memory database, build a dynamic model of device relationships, and perform dynamic attribute association. The listen-update module is used to create a state observer on the device to listen for device state change events and update the device association relationship in real time based on the listening results.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 8.

Images