CN115857420A - IO (input/output) mutual control method between industrial control equipment - Google Patents
IO (input/output) mutual control method between industrial control equipment Download PDFInfo
- Publication number
- CN115857420A CN115857420A CN202310196316.1A CN202310196316A CN115857420A CN 115857420 A CN115857420 A CN 115857420A CN 202310196316 A CN202310196316 A CN 202310196316A CN 115857420 A CN115857420 A CN 115857420A
- Authority
- CN
- China
- Prior art keywords
- mutual control
- message
- kernel
- module
- mutual
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Landscapes
- Communication Control (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention discloses an IO (input/output) mutual control method between industrial control equipment, which comprises a user calling interface API (application program interface) module, an IO mutual control logic kernel module and an IO mutual control protocol module, wherein the user transfers working parameters to the IO mutual control logic kernel module by calling the interface API in the invention; the IO mutual control logic kernel module operates to complete main flow tasks and branch flow tasks of IO mutual control and establish IO mutual control relation among all the devices; the IO mutual control protocol module completes the packaging and unpacking work of the IO mutual control communication message and completes the receiving and sending tasks of the IO mutual control communication message by cooperating with the IO mutual control logic kernel module; the invention can realize the complex IO mutual control operations of one-to-one, one-to-many, many-to-one and many-to-many between the IO devices without depending on a central node, and when any one IO device participating in the mutual control fails, the mutual control between other IO devices can not be influenced, thereby greatly improving the robustness, the stability and the expandability of the system.
Description
Technical Field
The invention relates to the technical field of IO mutual control among industrial control devices, in particular to a method for IO mutual control among industrial control devices.
Background
Along with the rise of industrial control internet of things, the demand that IO signals are transmitted among industrial control devices to realize IO mutual control is continuously increased, the existing mainstream method is to collect and collect data through centralized nodes and then forward the collected data to each IO device, and the methods have the following serious defects: firstly, all IO modules depend on a central node, so that the delay of signal transmission is greatly increased, and the situation needing real-time control cannot be met; secondly, once the central node is paralyzed, the whole system is unavailable; thirdly, the methods are often bound with specific hardware or operating systems and programming languages, and the development of manpower and material resources needs to be invested again when a platform architecture is changed, so that the project cost and the period are greatly increased; fourthly, the methods can not enable each device participating in IO mutual control to freely determine the type and the number of IO signals to be transmitted, and the system freedom and the expandability are poor.
Patent number CN105426562A proposes a UART communication method and apparatus between multiple IO modules and multiple communication modules, through which we know to use FPGA to solve the problem of UART transceiving port selection between communication module and IO module, thereby realizing many-to-many communication between IO module and communication module, but the method mainly realizes many-to-many communication between IO module and communication module, not inter-control operation between IO modules, and is essentially different from the method; secondly, the method in the patent only aims at uart and fpag hardware and has no universality; in addition, in the patent, the free selection of the type and number of io signals by each io module is not realized.
Patent No. CN114384849A proposes a safety instrument system, which discloses a safety instrument system, wherein a gateway switch is used as an intermediate manager to perform bidirectional data transmission, so as to implement data communication between each IO module and a plurality of controllers, but the method mainly implements data communication between the IO module and the plurality of controllers, and is not a mutual control operation between the IO modules, which is different from the method in nature; secondly, the method in the patent is limited to a central gateway, and once the gateway fails, the whole system is at risk of being unavailable; in addition, the method in the patent depends on the communication mode of the ethernet, does not support other types of communication modes, and has a great limitation in practical application.
Disclosure of Invention
In order to solve the problems that in the prior art, all IO modules depend on a central node, the signal transmission time is greatly prolonged, and the situation that real-time control is needed cannot be met; secondly, once the central node is paralyzed, the whole system is unavailable; thirdly, the methods are often bound with specific hardware or operating systems and programming languages, and the development of manpower and material resources needs to be invested again when a platform architecture is changed, so that the project cost and the period are greatly increased; fourthly, the methods can not enable each device participating in IO mutual control to freely determine the type and the number of IO signals to be transmitted, and have the defects of poor system freedom and expandability.
In order to solve the technical problems, the invention provides the following technical scheme:
the invention relates to an IO mutual control method between industrial control devices, which comprises an API module for a user calling interface, an IO mutual control logic kernel module and an IO mutual control protocol module, and specifically comprises the following steps,
and 3, the IO mutual control protocol module completes the packaging and unpacking work of the IO mutual control communication message and completes the receiving and sending tasks of the IO mutual control communication message by cooperating with the IO mutual control logic kernel module.
As a preferred technical scheme of the invention, the equipment is industrial control equipment or Internet of things terminal equipment with switching value, analog quantity, pulse and communication interfaces.
As a preferred technical solution of the present invention, the IO mutual control relationship means that each device can freely send the collected switching value, analog value, pulse, and data to one or more other devices and output the collected switching value, analog value, pulse, and data.
As a preferred technical scheme of the invention, the user call interface API module comprises a switching value operation API callback interface, an analog value operation API callback interface, a pulse value operation API callback interface, a data read-write API callback interface, an IO mutual control configuration API interface and an IO mutual control logic kernel driving engine API interface.
As a preferred technical scheme of the invention, the IO mutual control protocol module is used for completing the packing and unpacking work of the IO mutual control communication message.
As a preferred technical scheme of the invention, the working process of the IO inter-control logic kernel module is to firstly check whether each API interface is correctly configured by a user, if not, an error code is returned to inform the user, if so, the API directly enters an IO inter-control logic kernel inlet to start circulating operation, the kernel firstly judges whether an IO inter-control protocol message needs to be sent, if so, the assembly work of the IO inter-control protocol message is started, and the specific process is as follows, loading message serial number to PktSqu field of IO mutual control protocol, loading ProtoVer field of IO mutual control protocol according to current protocol version, loading SysClk field of IO mutual control protocol according to current system clock, loading SrcAddr field of IO mutual control protocol according to current IO module station number, loading PayloadMask field of IO mutual control protocol according to IO resource type of current IO module, reading switching value input of user layer and loading to PayloadDigNum and PayloadDig field, reading analog input of user layer and loading to PayloadAnaNum and PayloadAna field, reading pulse input of user layer and loading to PayloadPwmNum and PayloadPwm field, reading data input of user layer and loading to PayloData and PayloadData field, calculating total length of message to be sent, loading PktSqu field of mutual control protocol, and computing API code of IO mutual control protocol, and calling the exchange CRC code of IO mutual control protocol, and calling the final communication of IO mutual control protocol, after the transmission is finished, re-entering an IO mutual control logic kernel inlet to start the next task cycle;
if the kernel judges that the IO mutual control protocol message does not need to be sent, whether the IO mutual control protocol message needs to be received or not needs to be judged, if not, the kernel returns to the kernel inlet, if so, the IO mutual control protocol message is started to be received, the actually received data length is compared with whether the PktLen field in the message is consistent or not, if not, the message is incomplete, at the moment, the residual message needs to be continuously received, but if the complete message still cannot be received within the overtime, the kernel discards the message and returns to the kernel inlet again;
if the kernel receives a complete message, judging whether the sequence number PktSqu of the actually received message is correct, whether the protocol version number ProtoVer is correct, whether the system clock SysClk is correct, whether the check code Crc of the message is correct according to the following sequence, if any one of the conditions is not satisfied, the kernel still discards the message and returns to the kernel inlet again; if the above conditions are met, the kernel reads the PayloadMask field in the message and determines whether to extract the PayloadDigNum and PayloadDig fields and drive the switching value output of the user layer, whether to extract the payloadanananum and PayloadAna fields and drive the analog value output of the user layer, whether to extract the PayloadPwmNum and PayloadPwmN fields and drive the pulse output of the user layer, whether to extract the PayloadDataNum and PayloadData fields and drive the data output of the user layer, and completes the above logic flow, and the kernel transfers to the entry again to continue the operation, and so on.
The invention has the beneficial effects that:
the method for IO mutual control among the industrial control devices is used for realizing one-to-one, one-to-many, many-to-one and many-to-many IO mutual control among the industrial control devices or the terminal devices of the Internet of things. The method integrally encapsulates the complex logic and communication protocol in the IO mutual control process and opens the complex logic and communication protocol to a user through the API interface, and the user can realize the IO signal acquisition, transmission and output among the IO devices only by operating according to the API interface requirement. The method has universality, is not limited by the types of CPU hardware and communication hardware, and is not limited by a specific operating system and a specific programming language, so that a great amount of development cost and debugging time are saved for a user; the method can realize the complex IO mutual control operations of one-to-one, one-to-many, many-to-one and many-to-many among the IO devices without depending on a central node, and when any one IO device participating in the mutual control fails, the mutual control among other devices cannot be influenced, so that the robustness and the stability of the system are greatly improved; in the method, each device participating in IO mutual control can freely determine the type and the number of signals to be acquired or output, and the signals can be single switching value, analog value, pulse and data or mixed switching value, analog value, pulse and data, so that the freedom and expandability in the use process are greatly improved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention and not to limit the invention. In the drawings:
FIG. 1 is a general block diagram of a method of IO inter-control between devices;
FIG. 2 is a user call interface API block diagram of a method for inter-device IO inter-control;
FIG. 3 is a flowchart of the IO inter-control logic core operation of the method for inter-device IO inter-control;
fig. 4 is a practical application networking diagram of the method for IO mutual control between devices.
Detailed Description
The preferred embodiments of the present invention will be described in conjunction with the accompanying drawings, and it will be understood that they are described herein for the purpose of illustration and explanation and not limitation.
Example (b): as shown in fig. 1-4, the IO mutual control method between devices according to the present invention includes a user call interface API module, an IO mutual control logic kernel module, and an IO mutual control protocol module, and specifically includes the following steps,
step 3, the IO mutual control protocol module completes the packaging and unpacking work of the IO mutual control communication message and completes the receiving and sending tasks of the IO mutual control communication message by cooperating with the IO mutual control logic kernel module;
the equipment is industrial control equipment or internet of things terminal equipment with switching value, analog quantity, pulse and communication interfaces.
The IO mutual control relation refers to that each device can freely send collected switching values, analog values, pulses and data to one or more other devices and then output the switching values, the analog values, the pulses and the data.
The IO mutual control protocol is used for completing the packaging and unpacking work of the IO mutual control communication message.
As shown in fig. 2, the user call interface API module includes a switching quantity operation API callback interface, an analog quantity operation API callback interface, a pulse quantity operation API callback interface, a data read-write API callback interface, an IO mutual control configuration API interface, and an IO mutual control logic kernel driver engine API interface; the O inter-control logic kernel can have the authority to operate the hardware interfaces of switching value, analog value, pulse value and data input and output on the user equipment; then, the user needs to call an IO mutual control configuration API interface to inform the IO mutual control logic kernel of working parameters, configuration equipment station numbers, protocol version numbers and system clocks, and determine whether to transmit switching values, analog values, pulse values and data singly or in a mixed mode; next, calling a communication transceiving API call-back interface by a user, wherein the purpose of calling the communication transceiving API call-back interface is to enable the IO mutual control logic kernel to have the authority of operating a hardware communication interface on user equipment; finally, the user needs to call an API (application program interface) of the drive engine of the IO mutual control logic kernel to allocate CPU (central processing unit) running resources to the IO mutual control logic kernel, so that the kernel can run continuously.
As shown in fig. 3, the working process of the IO inter-control logic kernel module is to check whether each API interface is correctly configured by the user, if not, return an error code to notify the user, if correctly configured, directly enter the entry of the IO inter-control logic kernel to start the cycle operation, the kernel first determines whether an IO inter-control protocol message needs to be sent, if necessary, start the assembly work of the IO inter-control protocol message, and the specific process is, loading message serial numbers to a PktSqu field of an IO (input/output) mutual control protocol, loading a ProtoVer field of the IO mutual control protocol according to a current protocol version, loading a SysClk field of the IO mutual control protocol according to a current system clock, loading a SrcAddr field of the IO mutual control protocol according to a current IO module station number, loading a PayloadMask field of the IO mutual control protocol according to an IO resource type of a current IO module, reading switching value input of a user layer and loading the switching value input to PayloadDigmum and PayloadDig fields, reading analog value input of the user layer and loading the analog value input to PayloadAna Num and PayloadAna fields, reading pulse value input of the user layer and loading the pulse value input to PayloadPwmum and PayloadPymm fields, reading data input of the user layer and loading the data input to PayloadData and PayloadNum and PayloadNonddata fields, calculating total length of a message to be sent, loading a PktsSqu field of the IO mutual control protocol, calculating a download a logical code field of the IO mutual control protocol, and calling a CRC (logical interface), and sending a last communication, and sending a communication, and then sending a call a communication protocol, and a call a CRC (input of a call a communication protocol;
if the kernel judges that the IO mutual control protocol message does not need to be sent, whether the IO mutual control protocol message needs to be received or not needs to be judged, if not, the kernel returns to the kernel inlet, if so, the IO mutual control protocol message is started to be received, the actually received data length is compared with the PktLen field in the message to judge whether the actually received data length is consistent with the PktLen field in the message or not, if not, the message is incomplete, at the moment, the rest message needs to be continuously received, but if the complete message still cannot be received within the overtime, the kernel discards the message and returns to the kernel inlet again;
if the kernel receives a complete message, judging whether the sequence number PktSqu of the actually received message is correct, whether the protocol version number ProtoVer is correct, whether the system clock SysClk is correct, whether the check code Crc of the message is correct according to the following sequence, if any one of the conditions is not satisfied, the kernel still discards the message and returns to the kernel inlet again; if the above conditions are met, the kernel reads the PayloadMask field in the message and determines whether to extract the PayloadDigNum and PayloadDig fields and drive the switching value output of the user layer, whether to extract the payloadanananum and PayloadAna fields and drive the analog value output of the user layer, whether to extract the PayloadPwmNum and PayloadPwmN fields and drive the pulse output of the user layer, whether to extract the PayloadDataNum and PayloadData fields and drive the data output of the user layer, and completes the above logic flow, and the kernel transfers to the entry again to continue the operation, and so on.
The message format of the IO mutual control protocol, all the modules participating in IO mutual control carry out communication transceiving work according to the protocol: the sender sends a request message according to the protocol, and the receiver receives the message according to the protocol. The PktLen field occupies 2 bytes to indicate the total length of the message; the PktSqu field occupies 4 bytes to indicate the message sequence number; the ProtoVer field occupies 1 byte to indicate the current protocol version number, and the SysClk field occupies 4 bytes to indicate the current system clock; the SrcAddr field occupies 2 bytes to indicate the station number of the data source, and the value range is 1 to 65535; the PayloadMask field occupies 4 bytes to indicate a data type mask carried by the message, thereby allowing each IO device to freely determine the type of the IO signal to be transmitted; the PayloadDigNum field occupies 0 or 2 bytes to indicate the number of the carried switching value paths, and occupies 0 bytes if the switching value is not carried; the PayloadDig field occupies 0 or a variable byte to indicate a carried specific value of the switching value, if the switching value is not carried, 0 byte is occupied, and if the switching value is carried, payloadDigNum/8 bytes are occupied; the PayloadAnaNum field occupies 0 or 2 bytes to indicate the number of analog quantity paths carried, and occupies 0 bytes if the analog quantity is not carried; the PayloadAna field occupies 0 or variable byte to indicate the specific value of the carried analog quantity, if the analog quantity is not carried, the PayloadAnaNum occupies 0 byte, and if the analog quantity is carried, the PayloadAnaNum occupies 2 bytes; the PayloadPwmNum field occupies 0 or 2 bytes to indicate the number of carried pulse quantity paths, if not, the PayloadPwmNum field occupies 0 bytes; the PayloadPwm field occupies 0 or variable byte to indicate the specific value of the carried pulse quantity, if the pulse quantity is not carried, the PayloadPwmNum occupies 0 byte, if the pulse quantity is carried, the PayloadPwmNum occupies 4 bytes; the PayloadDataNum field occupies 0 or 2 bytes to indicate the length of the carried user data, and occupies 0 byte if the user data is not carried; the PayloadData field occupies 0 or variable bytes to indicate the specific value of the carried user data, if the user data is not carried, the PayloadDataNum bytes are occupied, and if the user data is carried, the PayloadDataNum bytes are occupied; the last Crc field occupies 2 bytes, is the Crc checksum of the entire message, and is used for checking the correctness of the message.
Referring to fig. 4, in a networking mode in practical application of the present invention, each device participating in IO mutual control packages its switching value, analog value, pulse value, and data according to a flow and a protocol in the method, and then sends the packaged switching value, analog value, pulse value, and data to a communication network, and after receiving the packaged switching value, analog value, pulse value, and data, other IO modules locally output these switching values, analog value, pulse value, and data according to their own requirements. The network can be formed by 1 to 1 network, or 1 to more, more to 1 and more to more networks.
Finally, it should be noted that: although the present invention has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that changes may be made in the embodiments and/or equivalents thereof without departing from the spirit and scope of the invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (6)
1. A method for IO mutual control between industrial control devices is characterized by comprising an API module for a user calling interface, an IO mutual control logic kernel module and an IO mutual control protocol module, and specifically comprises the following steps,
step 1, a user transfers working parameters to an IO mutual control logic kernel module by calling an interface API in the invention;
step 2, starting and operating an IO mutual control logic kernel module, completing main flow tasks and branch flow tasks of IO mutual control, and establishing an IO mutual control relation among all devices;
and 3, the IO mutual control protocol module completes the packaging and unpacking work of the IO mutual control communication message and completes the receiving and sending tasks of the IO mutual control communication message by cooperating with the IO mutual control logic kernel module.
2. The method of claim 1, wherein the devices are industrial control devices or internet of things terminal devices having switching values, analog values, pulses and communication interfaces.
3. The method of claim 1, wherein the IO mutual control relationship means that each device can freely send the collected switching value, analog value, pulse, and data to one or more other devices and output the collected switching value, analog value, pulse, and data.
4. The method of claim 1, wherein the user call interface API module comprises a switching quantity operation API callback interface, an analog quantity operation API callback interface, a pulse quantity operation API callback interface, a data read-write API callback interface, an IO mutual control configuration API interface, and an IO mutual control logic kernel driver engine API interface.
5. The method according to claim 1, wherein the working process of the IO inter-control logic kernel module is to check whether each API has been correctly configured by the user, if not, to return an error code to inform the user, if correctly configured, to directly enter the IO inter-control logic kernel entry to start the cycle operation, the kernel first determines whether the IO inter-control protocol message needs to be sent, if so, to start the assembly work of the IO inter-control protocol message, and the specific process is, loading message serial number to PktSqu field of IO mutual control protocol, loading ProtoVer field of IO mutual control protocol according to current protocol version, loading SysClk field of IO mutual control protocol according to current system clock, loading SrcAddr field of IO mutual control protocol according to current IO module station number, loading PayloadMask field of IO mutual control protocol according to IO resource type of current IO module, reading switching value input of user layer and loading to PayloadDigNum and PayloadDig field, reading analog input of user layer and loading to PayloadAnaNum and PayloadAna field, reading pulse input of user layer and loading to PayloadPwmNum and PayloadPwm field, reading data input of user layer and loading to PayloData and PayloadData field, calculating total length of message to be sent, loading PktSqu field of mutual control protocol, and computing API code of IO mutual control protocol, and calling the exchange CRC code of IO mutual control protocol, and calling the final communication of IO mutual control protocol, after the transmission is finished, re-entering an IO mutual control logic kernel inlet to start the next task cycle;
if the kernel judges that the IO mutual control protocol message does not need to be sent, whether the IO mutual control protocol message needs to be received or not needs to be judged, if not, the kernel returns to the kernel inlet, if so, the IO mutual control protocol message is started to be received, the actually received data length is compared with whether the PktLen field in the message is consistent or not, if not, the message is incomplete, at the moment, the residual message needs to be continuously received, but if the complete message still cannot be received within the overtime, the kernel discards the message and returns to the kernel inlet again;
if the kernel receives a complete message, judging whether the sequence number PktSqu of the actually received message is correct, whether the protocol version number ProtoVer is correct, whether the system clock SysClk is correct, whether the check code Crc of the message is correct according to the following sequence, if any one of the conditions is not satisfied, the kernel still discards the message and returns to the kernel inlet again; if the above conditions are met, the kernel reads the PayloadMask field in the message and determines whether to extract the PayloadDigNum and PayloadDig fields and drive the switching value output of the user layer, whether to extract the payloadanananum and PayloadAna fields and drive the analog value output of the user layer, whether to extract the PayloadPwmNum and PayloadPwmN fields and drive the pulse output of the user layer, whether to extract the PayloadDataNum and PayloadData fields and drive the data output of the user layer, and completes the above logic flow, and the kernel transfers to the entry again to continue the operation, and so on.
6. The method of claim 1, wherein the IO inter-control protocol module is configured to perform the packaging and unpacking of IO inter-control communication packets.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310196316.1A CN115857420B (en) | 2023-03-03 | 2023-03-03 | IO mutual control method between industrial control equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310196316.1A CN115857420B (en) | 2023-03-03 | 2023-03-03 | IO mutual control method between industrial control equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115857420A true CN115857420A (en) | 2023-03-28 |
| CN115857420B CN115857420B (en) | 2023-05-12 |
Family
ID=85659867
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310196316.1A Active CN115857420B (en) | 2023-03-03 | 2023-03-03 | IO mutual control method between industrial control equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115857420B (en) |
Citations (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101646185A (en) * | 2009-09-04 | 2010-02-10 | 重庆大学 | Regulation and measurement equipment of wireless self-organizing network and use method thereof |
| US20120056952A1 (en) * | 1997-07-15 | 2012-03-08 | Silverbrook Research Pty Ltd | Printhead with fluid flow control |
| CN104271704A (en) * | 2012-05-08 | 2015-01-07 | 海洋王照明科技股份有限公司 | Manganese-doped magnesium stannate luminescent material and preparation method therefor |
| CN104331056A (en) * | 2014-11-18 | 2015-02-04 | 武汉大学 | Novel intelligent indoor household wireless network communication system |
| CN108111523A (en) * | 2017-12-28 | 2018-06-01 | 网易（杭州）网络有限公司 | Data transmission method and device |
| CN108712459A (en) * | 2018-03-30 | 2018-10-26 | 深圳市风云实业有限公司 | Protocol massages cross-layer communication method, device and electronic equipment |
| CN111385292A (en) * | 2020-03-04 | 2020-07-07 | 西安旌旗电子股份有限公司 | Descriptor-based protocol message and data interaction method and system |
| CN111526015A (en) * | 2020-04-26 | 2020-08-11 | 昆明大棒客科技有限公司 | Data acquisition uplink method, device, equipment and storage medium |
| CN111781847A (en) * | 2020-07-10 | 2020-10-16 | 珠海市一微半导体有限公司 | Household control system |
| CN112558948A (en) * | 2020-12-16 | 2021-03-26 | 武汉绿色网络信息服务有限责任公司 | Method and device for identifying message under mass flow |
| CN112578727A (en) * | 2019-09-28 | 2021-03-30 | 深圳市综科智控科技开发有限公司 | Programmable algorithm of single chip microcomputer |
| CN112953949A (en) * | 2021-03-01 | 2021-06-11 | 恒安嘉新（北京）科技股份公司 | Message header processing method, device, equipment and storage medium of network message |
| CN113179244A (en) * | 2021-03-10 | 2021-07-27 | 上海大学 | Federal deep network behavior feature modeling method for industrial internet boundary safety |
| CN113344355A (en) * | 2021-05-28 | 2021-09-03 | 中国农业银行股份有限公司 | Method and related device for evaluating automation requirements of robot process of business |
| CN113467696A (en) * | 2021-06-30 | 2021-10-01 | 西南电子技术研究所（中国电子科技集团公司第十研究所） | Multichannel AD data synchronous transmission system |
| CN114189399A (en) * | 2020-09-14 | 2022-03-15 | 深圳长城开发科技股份有限公司 | Intelligent household system based on LoRa and local mutual control method thereof |
-
2023
- 2023-03-03 CN CN202310196316.1A patent/CN115857420B/en active Active
Patent Citations (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120056952A1 (en) * | 1997-07-15 | 2012-03-08 | Silverbrook Research Pty Ltd | Printhead with fluid flow control |
| CN101646185A (en) * | 2009-09-04 | 2010-02-10 | 重庆大学 | Regulation and measurement equipment of wireless self-organizing network and use method thereof |
| CN104271704A (en) * | 2012-05-08 | 2015-01-07 | 海洋王照明科技股份有限公司 | Manganese-doped magnesium stannate luminescent material and preparation method therefor |
| US20150083968A1 (en) * | 2012-05-08 | 2015-03-26 | Mingjie Zhou | Manganese-doped magnesium stannate luminescent material and preparation method therefor |
| CN104331056A (en) * | 2014-11-18 | 2015-02-04 | 武汉大学 | Novel intelligent indoor household wireless network communication system |
| CN108111523A (en) * | 2017-12-28 | 2018-06-01 | 网易（杭州）网络有限公司 | Data transmission method and device |
| CN108712459A (en) * | 2018-03-30 | 2018-10-26 | 深圳市风云实业有限公司 | Protocol massages cross-layer communication method, device and electronic equipment |
| CN112578727A (en) * | 2019-09-28 | 2021-03-30 | 深圳市综科智控科技开发有限公司 | Programmable algorithm of single chip microcomputer |
| CN111385292A (en) * | 2020-03-04 | 2020-07-07 | 西安旌旗电子股份有限公司 | Descriptor-based protocol message and data interaction method and system |
| CN111526015A (en) * | 2020-04-26 | 2020-08-11 | 昆明大棒客科技有限公司 | Data acquisition uplink method, device, equipment and storage medium |
| CN111781847A (en) * | 2020-07-10 | 2020-10-16 | 珠海市一微半导体有限公司 | Household control system |
| CN114189399A (en) * | 2020-09-14 | 2022-03-15 | 深圳长城开发科技股份有限公司 | Intelligent household system based on LoRa and local mutual control method thereof |
| CN112558948A (en) * | 2020-12-16 | 2021-03-26 | 武汉绿色网络信息服务有限责任公司 | Method and device for identifying message under mass flow |
| CN112953949A (en) * | 2021-03-01 | 2021-06-11 | 恒安嘉新（北京）科技股份公司 | Message header processing method, device, equipment and storage medium of network message |
| CN113179244A (en) * | 2021-03-10 | 2021-07-27 | 上海大学 | Federal deep network behavior feature modeling method for industrial internet boundary safety |
| CN113344355A (en) * | 2021-05-28 | 2021-09-03 | 中国农业银行股份有限公司 | Method and related device for evaluating automation requirements of robot process of business |
| CN113467696A (en) * | 2021-06-30 | 2021-10-01 | 西南电子技术研究所（中国电子科技集团公司第十研究所） | Multichannel AD data synchronous transmission system |
Non-Patent Citations (2)
| Title |
|---|
| OLABIMPE: "Glandular sources of pheromones used to control host workers (Apis mellifera scutellata) by socially parasitic workers of Apis mellifera capensis" * |
| 宗群: "基于嵌入式Linux的电梯轿厢控制器设计与实现" * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115857420B (en) | 2023-05-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2237120B1 (en) | Universal network adapter for industrial control networks | |
| CN102664779B (en) | CAN bus data transmitting method | |
| US20230080588A1 (en) | Mqtt protocol simulation method and simulation device | |
| CN104317661A (en) | Intersystem communication method and device of dual embedded systems | |
| US20130315362A1 (en) | Nuclear digital instrumentation and control system | |
| CN102609353A (en) | Method, device and system for managing program debugging | |
| CN105989537A (en) | Security and financial derivative transaction risk control system and risk control method | |
| CN108809949A (en) | The method converted and dispatched between profinet, FF H1, CAN and profibus agreements | |
| CN111541688A (en) | Embedded system compatible with multiple protocols, data processing method and device | |
| CN110430110B (en) | On-site bus gateway and protocol conversion method thereof | |
| CN115857420A (en) | IO (input/output) mutual control method between industrial control equipment | |
| CN116521609A (en) | Multi-host and multi-slave system, ZYNQ arbiter and data processing method thereof | |
| IL101593A (en) | Process for transmitting data to a plurality of data stations | |
| CN113992740B (en) | Middleware based on autonomous control and data transmission method | |
| CN110687854B (en) | PA bus controller and PA bus control system | |
| Xu et al. | Profibus automation technology and its application in DP slave development | |
| CN114785659A (en) | Instruction configuration method and device, electronic equipment and computer-readable storage medium | |
| US20220137604A1 (en) | Coordination Device and Method for Providing Control Applications via a Communication Network for Transmitting Time-Critical Data | |
| CN112994998A (en) | Communication node, communication method, communication device and electronic equipment | |
| CN112019491B (en) | Message processing method and system | |
| CN109814871B (en) | Node management method and system based on DDS bus | |
| CN115396368B (en) | Efficient composite network data transmission method based on node addressing and data encapsulation | |
| CN115037795B (en) | Multi-machine communication method for embedded equipment | |
| CN113938512B (en) | Multi-device linkage control method and system based on configurable gateway | |
| CN114338265B (en) | Program downloading system and method based on TTP/C bus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |