WO2020063995A1 - Pon网络，用于pon网络的方法及装置，以及机器人系统 - Google Patents

Pon网络，用于pon网络的方法及装置，以及机器人系统 Download PDF

Info

Publication number
WO2020063995A1
WO2020063995A1 PCT/CN2019/109256 CN2019109256W WO2020063995A1 WO 2020063995 A1 WO2020063995 A1 WO 2020063995A1 CN 2019109256 W CN2019109256 W CN 2019109256W WO 2020063995 A1 WO2020063995 A1 WO 2020063995A1
Authority
WO
WIPO (PCT)
Prior art keywords
canopen
nmt
bus
onu
virtual
Prior art date
Application number
PCT/CN2019/109256
Other languages
English (en)
French (fr)
Inventor
黄晓庆
李晖
Original Assignee
深圳前海达闼云端智能科技有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 深圳前海达闼云端智能科技有限公司 filed Critical 深圳前海达闼云端智能科技有限公司
Publication of WO2020063995A1 publication Critical patent/WO2020063995A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B10/00—Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/25—Arrangements specific to fibre transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B10/00—Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/27—Arrangements for networking
    • H04B10/272—Star-type networks or tree-type networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Definitions

  • the present disclosure relates to the field of communications, and in particular, to a PON network, a method and device for the PON network, and a robot system.
  • CiA CiA
  • CiA CiA
  • CiA CiA
  • CAN Automation, Draft Standard, CAN Automation Standard Draft
  • EN50325-4 CiA European Commission for Electrotechnical Standardization, Ceelec European Electrotechnical Standardization Commission
  • CiA also defines a number of other CANopen-related frameworks, device profiles, and application profiles.
  • the main purpose of this disclosure is to provide a PON network, a method and device for the PON network, and a robot system capable of supporting ONUs to run CANopen-based applications under the PON-CAN bus architecture.
  • a first aspect of the embodiments of the present disclosure provides a PON network, where the PON network includes:
  • An optical line terminal OLT as a network management control master device
  • At least one optical network unit ONU as a network management control slave device
  • the CANopen protocol layer is deployed in the OLT, and the CANopen protocol layer is deployed in the ONU, so that the OLT acts as a CANopen network management terminal NMT master node, and each ONU acts as a CANopen NMT slave node to run based on
  • the application of CANopen enables the PON-CAN bus architecture to support multiple virtual CAN buses, wherein each of the virtual CAN buses is used to connect a plurality of the NMT slave nodes.
  • a second aspect of the embodiments of the present disclosure provides an apparatus for a PON network, the apparatus being configured as an OLT in the PON network according to any one of the above.
  • a third aspect of the embodiments of the present disclosure provides an apparatus for a PON network, the apparatus being configured as an ONU in the PON network according to any one of the above.
  • a fourth aspect of the embodiments of the present disclosure provides a method for a PON network, the PON network including: an optical line terminal OLT as a network management control master device; and at least one optical network unit ONU as a network management control slave device, The method includes:
  • the OLT returns a configuration request for configuring the ONU to the ONU;
  • the OLT issues a topic message to the ONU based on a communication connection established with the ONU, and / or receives a topic message issued by the ONU.
  • a fifth aspect of the embodiments of the present disclosure provides a method for a PON network, the PON network including: an optical line terminal OLT as a network management control master device; and at least one optical network unit ONU as a network management control slave device, The method includes:
  • At least one ONU in the PON network sends an access request to the OLT;
  • the ONU returns a configuration response to the OLT to indicate that the configuration is complete;
  • the ONU issues a subject message to the OLT based on a communication connection established with the OLT, and / or receives a subject message issued by the OLT.
  • a sixth aspect of the embodiments of the present disclosure provides a robot system including the PON network according to any one of the foregoing.
  • a PON-CAN bus architecture can support multiple virtual CAN buses, each virtual CAN bus supports multiple CANopen NMT nodes, and ONUs that are NMT nodes can run various CANopen applications, and CANopen's related framework (device), device profile (application profile) and application profile (application profile) can be used to manage and configure all nodes on the PON-CAN bus architecture.
  • FIG. 1 is a schematic diagram of a PON-CAN bus architecture provided by an embodiment of the present disclosure
  • FIG. 2 is a schematic diagram of a module structure of a CANopen protocol layer in an OLT for implementing a Virtual CANopen over PON-CAN bus architecture provided by an embodiment of the present disclosure
  • FIG. 3 is a schematic structural diagram of an OLT according to an embodiment of the present disclosure.
  • FIG. 4 is a schematic diagram of a module structure of a CANopen protocol layer used to implement a Virtual CANopen over PON-CAN bus architecture in an ONU according to an embodiment of the present disclosure
  • FIG. 5 is a schematic structural diagram of an ONU according to an embodiment of the present disclosure.
  • FIG. 6 is a schematic diagram of a main state machine of a CANopen management module in an OLT according to an embodiment of the present disclosure
  • FIG. 7 is a schematic diagram of a slave state machine of a CANopen management module in an OLT according to an embodiment of the present disclosure
  • FIG. 8 is a schematic flowchart of a method for a PON network according to an embodiment of the present disclosure
  • FIG. 9 is a schematic flowchart of another method for a PON network according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic diagram of an initial configuration process of a PON network according to an embodiment of the present disclosure
  • FIG. 11 is a schematic diagram of a process in which an OLT sends PDO data to an ONU according to an embodiment of the present disclosure.
  • the PON-CAN bus architecture based on passive fiber networking and symmetric couplers and / or asymmetric couplers avoids electromagnetic interference and does not cause bandwidth reduction between levels, which can provide very high bandwidth. With the increasing number of connected nodes, it can also meet the high-speed transmission requirements, and solves the problem of the low CAN bus communication rate and the limited number of node connections.
  • FIG. 1 is a schematic diagram of the PON-CAN bus architecture.
  • the PON-CAN bus architecture includes an OLT (Optical Line Terminal) 101 and an optical fiber bus connected to the OLT 101.
  • the bus is formed by interconnecting multiple asymmetric couplers.
  • the optical fiber bus 102 shown in FIG. 1 is formed by interconnecting multiple asymmetric couplers 103.
  • FIG. 1 is only a schematic illustration of the linear interconnection between the asymmetric couplers.
  • the couplers can use other interconnection methods, or use multiple interconnection methods to form a fiber optic bus.
  • an ONU Optical Network Unit
  • the ONU 104 is used to realize the conversion of the photoelectric signals between the optical fiber bus and the electronically controlled terminal equipment. Furthermore, the total information equipment (not shown in FIG. 1, which can be the upper computer of the robot system, for example) connected to the OLT 101 can implement communication with the terminal equipment through the PON-CAN bus architecture.
  • MQTT Message Queuing Telemetry Transmission
  • M2M Machine-to-Machine
  • IoT Internet of Things
  • robots System internal communication
  • MQTT Sensor, Networks, MQTT-SN
  • MQTT-SN The sensor version of MQTT (MQTT, Sensor, Networks, MQTT-SN) is an optimized design for various low-cost battery-driven devices and sensors based on MQTT.
  • MQTT-SN has no strict requirements on the underlying network services. Any network can support MQTT-SN as long as it can provide two-way data transmission service between any node and a specific node (gateway).
  • the above-mentioned PON-CAN bus architecture supports flexible message bus topology, for example, up to 128 ONUs under one wavelength CT (wavelength channel port) on one Wavelength port (wavelength port); or multiple wavelength CTs on one Wavelength port
  • NMT Network Management Terminal
  • the purpose of the embodiments of the present disclosure is to provide a PON network so that all ONUs on a PON-CAN bus architecture can run various applications of CANopen, and the PON-CAN bus architecture can support more NMT nodes, further In order to maintain isolation between different Virtual CAN buses. It is worth noting that the embodiments of the present disclosure do not use CAN at the physical level, but at the software level, use the existing implementation of the CAN bus to run devices based on the CAN bus as long as the software remains unchanged. On the PON-CAN bus architecture. The following specifically describes the PON network provided by the embodiments of the present disclosure.
  • a PON network provided in an exemplary embodiment of the present disclosure includes: an OLT as a network management control master device and at least one ONU as a network management control slave device;
  • a CANopen protocol layer is deployed in the OLT, and a CANopen protocol layer is deployed in the ONU, so that the OLT acts as a CANopen NMT master node, and each ONU can act as a CANopen NMT slave node to run CANopen-based applications
  • the PON-CAN bus architecture supports multiple virtual CAN buses, where each of the virtual CAN buses is used to connect multiple NMT slave nodes.
  • the PON network may form a PON-CAN bus architecture with a CAN bus, and the PON-CAN bus architecture may be applied to a robot system.
  • a PON-CAN bus architecture supporting multiple virtual CAN buses is referred to as a Virtual CANopen over PON-CAN bus architecture.
  • CANopen-related framework device
  • CiA application profile defined by CiA
  • all nodes on the PON-CAN bus architecture are implemented. Management and configuration.
  • the present disclosure redesigns the management configuration of the existing CANopen Manager (CANopen Management Module), including the management configuration of the NMT master node and the NMT slave node.
  • NMC-M Network Management Control Master Device
  • NMC-S network management control slave device
  • Virtual CAN bus The definition of Virtual CAN bus and the method of using Virtual CAN bus to support more than one traditional CAN bus node capacity on a new fieldbus;
  • Virtual CANopen over PON-CAN bus architecture the main CANopen management module (Master CANopen Manager) implementation method;
  • CANopen Manager The state machine of the CANopen management module (CANopen Manager) on the PON-CAN bus architecture and its implementation method.
  • the module structure of the CANopen protocol layer in the network management control master device (NMC-M) used to implement the Virtual CANopen over PON-CAN bus architecture is shown in Figure 2, including:
  • Virtual CANopen Application Layer 20 SDO Segmentation Reassembly Manager 21, Service Data Object (SDO) Layer 22, Process Data Object (PDO) Layer 23 CANopen Adapter Master 24, network management control client interface 25 and message bus client interface 26;
  • the virtual CANopen application layer 20 includes:
  • a master CANopen management module (Master CANopen Manager) 201, configured to support the OLT as an NMT master node to manage and configure NMT slave nodes on the virtual CAN bus;
  • a CANopen management module (CANopen Manager) 202 configured to configure a CANopen application on each of the NMT nodes;
  • the SDO segmentation and reorganization manager 21 includes an encapsulation layer of the SDO layer 22 in the CANopen architecture.
  • the SDO segmentation and reorganization manager 21 is connected to the virtual CANopen application layer 20 and the SDO layer 22.
  • the object data whose length exceeds a predetermined value is divided and transmitted during transmission, and the object data divided and transmitted is reassembled into the original object data when received.
  • the predetermined value may be, for example, 4 bytes.
  • the CANopen master adapter 24 is connected to the SDO layer 22, the PDO layer 23, the CANopen application layer 20, the network management control client interface 25 and the message bus client interface 26, and is used to connect the network management control client interface 25 and the message bus client interface.
  • 26 is adapted to the SDO layer 22, the PDO layer 23 and the CANopen application layer 20.
  • the network management control client interface 25 is used to connect to the network management control server interface in the state machine module of the OLT
  • the message bus client interface 26 is used to connect to the message bus server interface in the message bus layer module of the OLT.
  • TPDO Transmit-PDO
  • RPDO Receive-PDO
  • TPDO is used to transmit data
  • nodes supporting TPDO are producers of PDO data
  • RPDO is used to receive PDO data
  • nodes supporting RPDO are consumers of PDO data.
  • SDO uses client-server mode to establish point-to-point communication and implements reading and writing entries in the object dictionary.
  • the device of the accessed object dictionary serves as the server, and the device of the accessed object dictionary serves as the client.
  • SDO adopts the request response mode.
  • Each SDO access will correspond to two CAN data frames: one is a request and the other is a response.
  • FIG. 3 shows another structural diagram of the OLT.
  • the OLT includes a first message bus layer module 28, a first state machine module 27, a first transmission network 29, and the CANopen protocol layer shown in FIG.
  • the module structure of the CANopen protocol layer shown in FIG. 2 shows the connection relationship between the module structure of the CANopen protocol layer and the first state machine module 27 and the first message bus layer module 28 of the OLT.
  • the first state machine module 27 includes: a master state machine for performing a state operation according to an event occurring on the OLT itself; a slave state machine for performing a state operation according to an event occurring on an ONU connected to the OLT; and a network management control service End interface for supporting the first state machine module 27 to implement service specifications and service flow tags for communication between the OLT and the ONU at the first message bus layer module 28; a network controller for all The first state machine module 27 performs NMC service configuration on the first transmission network 29.
  • a first message bus layer module 28 configured to provide a message bus server and a first message bus client to support users of the message bus client in the OLT and users of all message bus clients in the ONU to register and subscribe to message topics, Post and receive topic messages.
  • the user of the message bus client in the OLT refers to a module having a message bus client interface.
  • the first state machine module 27 further includes a message bus client interface, so that the first state machine module 27 serves as a message. Users of the bus client can register and subscribe to message topics and publish and receive topic messages with the message bus server.
  • the first message bus layer module 28 further includes a network management control client interface for supporting the first state machine module in the first message bus layer module to implement service specifications and communication between the OLT and the ONU.
  • Service flow tag a network adapter connected to the transmission network of the OLT to implement the adaptation of the first message bus layer module 28 to the first transmission network 29, wherein the network adapter stores the OLT and all The message transmission path of each message subject between ONUs is described.
  • the network management control client interface 25 in the module configuration of the CANopen protocol layer shown in FIG. 2 is used to connect to the network management control server interface in the first state machine module 27 of the OLT to read the first state machine module 27 synchronously.
  • the status information of the first state machine module 27 is asynchronously acquired and the state changes and events of the first state machine module 27 are obtained.
  • the message bus client interface 26 is used to connect with the message bus server interface in the first message bus layer module 28 of the OLT.
  • the virtual CANopen application layer can subscribe, publish topic messages through the message bus client interface, and register message topics in the message bus server.
  • the module structure of the CANopen protocol layer in the network management control slave device (NMC-S) used to implement the Virtual CANopen over PON-CAN bus architecture is shown in Figure 4, including:
  • CANopen application module 31 service data object SDO layer 32, process data object PDO layer 33, CANopen slave adapter 34, network management control client interface 35, and message bus client interface 36;
  • the CANopen application module 31 is connected to the CANopen slave adapter 34, the SDO layer 32, and the PDO layer 33, and is configured to run a CANopen-based application. That is, the CANopen application module 31 includes the existing technology. CANopen-based applications and core object data;
  • the CANopen slave adapter 34 is connected to the SDO layer 32, the PDO layer 33, the network management control client interface 35, and the message bus client interface 36, and is configured to connect the network management control client interface 35 and the message bus client interface 36 are adapted to the SDO layer 32, the PDO layer 33 and the CANopen application module 31 to achieve the SDO layer 32, the PDO layer 33 and the CANopen application module 31 can be run directly on the PON-CAN bus architecture without modification.
  • each NMC slave node of the PON-CAN is still maintained as a CANopen NMT slave node, and the CANopen slave adapter 34 is used, so that the CANopen application module 31,
  • the service data object SDO layer 32 and the process data object PDO layer 33 can be run directly on the PON-CAN bus architecture without modification, in order to maximize the reuse of the existing CANopen-based applications and core object data transmission modules in the prior art.
  • Support for the virtual CAN bus mainly depends on the CANopen slave adapter 34.
  • different message topics between OUN and OLT correspond to different virtual CAN buses.
  • Each virtual CAN bus message has a message subject with the virtual CAN bus identification information.
  • the ONU as the NMT slave node can communicate with the OLT as the NMT master node on different message topics through the network management control client interface and message bus client interface adapted by the CANopen slave adapter.
  • FIG. 5 shows another schematic diagram of an ONU.
  • the ONU includes a second message bus layer module 38, a second state machine module 37, a second transmission network 39, and the CANopen protocol layer shown in Fig. 4
  • FIG. 5 shows the connection relationship between the module structure of the CANopen protocol layer shown in FIG. 4 and the second state machine module 37 and the second message bus layer module 38 of the ONU.
  • the second state machine module 37 is configured to run a slave state machine that performs a state operation according to an event occurring on the ONU itself and according to an event of the slave state machine running in the first state machine module; a second message bus layer module 38 For providing a second message bus client to support users of the message bus client in the ONU to register and subscribe to message topics, and to publish and receive topic messages, wherein the users of the message bus client in the ONU have a message center line
  • the client interface module for example, the second state machine module 37 includes a message bus client interface, so that the second state machine module 37 can register and subscribe to message topics and publish messages on the OLT side message bus server through the second message bus client. And receive topic messages.
  • the second state machine module 37 further includes:
  • a network management control server interface for supporting the second state machine module 37 to implement the service specification and service flow mark of the communication between the ONU and the OLT through the second message bus layer module 38;
  • the second message bus layer module 38 further includes:
  • a network management control client interface configured to support the second state machine module 37 to implement a service specification and a service flow mark of the communication between the ONU and the OLT at the second message bus layer module 38;
  • a network adapter is connected to the second transmission network 39 to implement adaptation of the second message bus layer module 38 to the second transmission network 39.
  • the network management control client interface 35 in the module configuration of the CANopen protocol layer shown in FIG. 4 is used to connect to the network management control server interface in the second state machine module 37 of the ONU to read the second state machine module 37 synchronously.
  • the CANopen application module of the ONU can subscribe and publish topic messages through the message bus client interface 36, and register message topics in the message bus server.
  • the embodiments of the present disclosure can map the NMC node number to the PON-CAN bus system in a static configuration. CANopen NMT node number.
  • the embodiment of the present disclosure may also add a Virtual CAN bus ID as the identification information of the virtual bus in addition to the CANopen node number, so that the Virtual CAN bus ID and CANopen NMT
  • the node numbers together form the CANopen NMT node number on the CANopen over PON-CAN bus architecture.
  • the Virtual CANopen NMT node number is used to support multiple Virtual CAN buses. Each Virtual CAN bus supports a maximum of 127 nodes (compared to the traditional CAN bus supporting 127 nodes, which has universal significance and greater versatility). All ONUs on the PON-CAN bus can run various applications of CANopen. And can achieve isolation between different Virtual CAN bus.
  • the definition of the virtual CAN bus ID can be shown in Table 1 below:
  • the Virtual CANopen on the NMC-M and the PON-CAN CANopen Manager can be based on the Virtual CAN bus ID of the CANopen NMT slave node on each NMC-S node.
  • the OLT may determine, for each ONU, the virtual CAN where the ONU is the NMT slave node.
  • the bus identification information (Virtual CAN Bus ID), writes the identification information and the mapping table between the node number of the NMT slave node and the NMC node number of the ONU into the object dictionary of the ONU.
  • the embodiment of the present disclosure may add the Virtual CAN bus ID to 1C91 in the Communication Profile section of the object dictionary.
  • the object dictionary of the Virtual CANopen and PON-CAN bus architecture is shown in Table 2 below:
  • the message bus message format on the Virtual CANopen over PON-CAN bus architecture is described, including connection-oriented message communication services and message formats between message bus nodes:
  • VoP Header Add the virtual CAN bus ID field to the Virtual CANopen PON-CAN header (VCoP Header), as shown in Table 3 below:
  • the embodiments of the present disclosure may allow messages on different virtual CAN buses to be transmitted in different message topics distinguished by a virtual CAN bus ID (vCANBusID) to isolate different virtual CAN buses. That is to say, the subject of the message registered by the OLT as the NMT master node and the ONU as the NMT slave node includes the identification information of the corresponding virtual CAN bus. Each message on the virtual CAN bus has the identification information of the virtual CAN bus. The message subject is transmitted to isolate the different virtual CAN buses.
  • vCANBusID virtual CAN bus ID
  • the virtual CAN bus ID in the PON-CAN (VCoP) Header can be used to combine the message topics of different virtual CAN buses to achieve isolation and isolation. Balance in scale. Since only one CANopen NMT slave node is supported on each PON-CAN NMC slave node, the Virtual CANopen on the PON-CAN NMC slave node. The PON-CAN subsystem will keep the traditional CANopen over PON-CAN subsystem running on it. The system (ie the module structure in the ONU shown in Figure 3) is completely isolated on its own virtual CAN bus.
  • mapping method for implementing a virtual CAN bus and a virtual CANopen over PON-CAN bus based on a message subject is explained.
  • the PON-CAN bus architecture can define a unified Virtual CANopen over PON-CAN control channel message topic to simulate the broadcast bus in the CANopen environment.
  • the NMC-M master node and all NMC-S slave nodes can directly address this message topic.
  • Publish and receive control messages As shown in Table 4, the messages transmitted in this control channel include:
  • the Virtual CANopen PON-CAN bus architecture can remove the original CANopen message from the start of frame (SOF), cyclic redundancy check (cyclic redundancy check, CRC), After the end of frame (EOF) field is directly used as the service data unit SDU of the CANopen over PON-CAN.
  • SOF start of frame
  • CRC cyclic redundancy check
  • EEF end of frame
  • the Virtual CANopen over PON-CAN bus architecture can support multiple CANopen message formats, such as CAN basic format, CAN extended format, CAN with Flexible Data-Rate (CAN) basic format, CAN FD extended format.
  • CANopen master adapter and CANopen slave adapter are responsible for the conversion and simulation on the PON-CAN message format and the CANopen management module and CANopen application interface.
  • the following describes the message format in the sixth aspect, including the description of the SDO message and the PDO message.
  • the embodiments of the present disclosure can add Virtual CANopen over a PON-CAN (VCoP) Header to the Basic Connection-Oriented Header, and Virtual CANopen for SDO services.
  • VOC PON-CAN
  • the definition of the header is shown in Table 6 below:
  • the embodiments of the present disclosure may adopt a Virtual CANopen PON-CAN (VCoP) header.
  • VoP Virtual CANopen PON-CAN
  • the implementation method of the master CANopen management module (Master CANopen Manager) of the PON-CAN bus architecture is explained.
  • the main CANopen management module is the management and configuration module of the entire Virtual CANopen over PON-CAN bus architecture.
  • the main CANopen management module in the OLT as the network control management master device can implement the management and configuration of the virtual CAN bus through the following operations:
  • each virtual CAN bus with at least one NMT slave node For each virtual CAN bus with at least one NMT slave node, for each NMT slave node on the virtual CAN bus, start a state machine instance in the CANopen management module and the NMT slave node on the virtual CAN bus, and update The DCF configuration file and the time stamp of the DCF configuration file are transmitted as parameters to the state machine instance, so as to realize the configuration of the NMT slave node on this virtual CAN bus according to the newly generated DCF configuration file, and complete all the tasks on the virtual CAN bus. After the configuration of the NMT slave node, all NMT slave nodes on the virtual CAN bus are started.
  • main processing procedure of the main CANopen management module in combination with specific commands, which may include:
  • vCANBusID Virtual CAN bus
  • the tenth aspect explains the state machine of the CANopen management module on the PON-CAN bus architecture and its implementation method.
  • Figure 6 is a schematic diagram of the main state machine of the CANopen management module. As shown in Figure 6, the main state machine of the CANopen management module is used for state transition according to at least one of the following events:
  • VNMT_MOD_CTRL_REQ VNMT_MOD_CTRL_REQ
  • VNMT_BOOTUP_IND is used to describe the event that NMT is started from the node
  • VNMT_SDO_RESP event is used to characterize the event that the SMT response of the NMT slave node is obtained
  • VNMT_HEARTBEAT_CONSUMER_TIMEOUT event used to characterize the timeout of the NMT heartbeat message.
  • the main state machine shown in FIG. 6 includes four states: Initialization, Pre-Operational, Operational, and Stopped.
  • the key state transitions of the main state machine are as follows. The description is shown by circles 1-7 in FIG. 6, where:
  • getConfigLastTimestamp () and startHeartbeatConsumerTimer () are executed and transferred to the pre-running state.
  • the getConfigLastTimestamp () function is used to configure the latest time stamp for the NMT slave node.
  • the startHeartbeatConsumerTimer () function is used to start the consumer heartbeat detection timer for the NMT slave node;
  • the consumer heartbeat detection timer of the node such as restart HeartbeatConsumerTimer () in the figure
  • the CANopen management module includes a slave state machine, as shown in FIG. 7, the slave state machine is configured to perform state transition according to at least one of the following events:
  • VNMT_MOD_CTRL_REQ VNMT_MOD_CTRL_REQ
  • VNMT_BOOTUP_IND is used to describe the event that NMT is started from the node
  • VNMT_SDO_RESP VNMT_SDO_RESP
  • the post-event is represented by VNMT_HEARTBEAT_CONSUMER_TIMEOUT.
  • the slave state machine shown in FIG. 7 (the slave state machine is a sub-state machine in the pre-run state in the master state machine shown in FIG. 6) includes a configuration version ConfigVersion state and a configuration entering a ConfigEntry state.
  • the state transitions represented by 1, 4, and 6 are in the pre-running state
  • the corresponding ConfigVersion state of the sub-state machine is 2, 3, 5
  • the state transition represented by 7 is the transition from the pre-running state, which corresponds to the ConfigEntry state of the sub-state machine, and Figure 7 specifically shows the processing of the events corresponding to 1-7 within the pre-running state.
  • the ConfigVersion state transitions to The trigger event for the ConfigEntry state is VNMT_SDO_RESP (ConfigLastTimestamp) [OK and configLastTimestampis notLatest] / startConfigDCF () shown in Figure 7, that is, in the ConfigVersion state, if the time stamp of the NMT slave node is not the latest time stamp (DCF configuration File changes), then all the NMT slave nodes on the virtual CAN bus are reconfigured and transferred to the ConfigEntry state.
  • VNMT_SDO_RESP ConfigLastTimestamp
  • startConfigDCF startConfigDCF
  • the PON network when the PON network forms a PON-CAN bus architecture, it can use the relevant framework of CANopen, device profile, and application profile. , Manage and configure all nodes on the PON-CAN bus architecture, and support multiple Virtual CAN buses, each Virtual CAN bus supports up to 127 CANopen NMT nodes, so that all ONUs on the PON-CAN bus can Run various applications of CANopen.
  • An embodiment of the present disclosure further provides an OLT configured as the OLT as a network management control master device in the PON network.
  • An embodiment of the present disclosure also provides a method for a PON network.
  • the execution subject of the method may be, for example, the above-mentioned OLT.
  • the PON network includes: an optical line terminal OLT as a master device for network management and control, and a slave device for network management and control. At least one optical network unit ONU of the device, the PON network may form a PON-CAN bus architecture with a CAN bus, as shown in FIG. 8, the method includes:
  • An OLT in a PON network receives an access request sent by at least one ONU.
  • the OLT returns a configuration request for configuring the ONU to the ONU.
  • the OLT establishes a communication connection with the ONU when it receives a message indicating that the configuration is complete and returned by the ONU.
  • the OLT and the ONU may establish a communication connection through a three-way handshake.
  • the OLT issues a topic message to the ONU based on the communication connection established with the ONU, and / or receives the topic message issued by the ONU.
  • An embodiment of the present disclosure also provides an ONU configured as an ONU that is a network management control slave device in the PON network.
  • An embodiment of the present disclosure also provides a method for a PON network.
  • the execution subject of the method may be, for example, the above-mentioned ONU.
  • the PON network includes an optical line terminal OLT as a master device for network management and control, and a slave device for network management and control.
  • At least one optical network unit ONU of the device, the PON network may form a PON-CAN bus architecture with a CAN bus, as shown in FIG. 9, the method includes:
  • At least one ONU in the PON network sends an access request to the OLT.
  • the ONU receives a configuration request for configuring the ONU, and performs configuration according to the configuration request.
  • the ONU returns a configuration response to the OLT to indicate that the configuration is complete.
  • the ONU establishes a communication connection with the OLT.
  • the ONU issues a topic message to the OLT based on the communication connection established with the OLT, and / or receives a topic message issued by the OLT.
  • FIG. 10 shows the initial configuration process of the PON network
  • FIG. 11 shows the process of the OLT sending PDO data to the ONU.
  • the relevant steps involved in the figure are already in the above embodiment. Description will not be repeated here.
  • An embodiment of the present disclosure further provides a robot system, which includes the PON network provided in the above embodiments.
  • the upper computer in the robot system can be used as the OLT in the PON-CAN bus architecture.
  • the median computer system, power management system, lower computer control system, servo system of each limb joint, and corresponding terminal equipment of each limb joint can be located in the next-level network connected to the optical fiber bus of the PON-CAN bus architecture.
  • the control devices and terminals of the robot system can be connected through the PON-CAN bus architecture. Due to the existence of the virtual bus, the nodes of the PON-CAN bus architecture are highly expandable, so they can be based on the system. Actually, multiple robot topology terminals need to be connected to solve the problem of node limitation in the existing robot bus system, and it can ensure that the high-speed transmission requirements can be met under the condition of increasing nodes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • Computing Systems (AREA)
  • Small-Scale Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Communication Control (AREA)

Abstract

一种PON网络，用于PON网络的方法及装置，以及机器人系统，能够在PON-CAN总线架构下支持ONU运行基于CANopen的应用。该PON网络包括：作为网络管理控制主设备的光线路终端OLT；以及作为网络管理控制从设备的至少一个光网络单元ONU；其中，所述OLT中部署有CANopen协议层，所述ONU中部署有CANopen协议层，使得所述OLT作为CANopen的网络管理终端NMT主节点，每一所述ONU作为CANopen的NMT从节点以运行基于CANopen的应用，且使得所述PON-CAN总线架构支持多个虚拟CAN总线，其中，每一所述虚拟CAN总线用于连接多个所述NMT从节点。

Description

PON网络，用于PON网络的方法及装置，以及机器人系统
相关申请的交叉引用
本申请要求于2018年9月29日提交的、申请号为62/739214的美国临时申请的优先权，该申请的内容通过引用的方式合并于此。
技术领域
本公开涉及通信领域，具体地，涉及一种PON网络，用于PON网络的方法及装置，以及机器人系统。
背景技术
CANopen是在CiA DS301(CAN in Automation Draft Standard，CAN自动化标准草案)和EN50325-4(Cenelec European Committee for Electrotechnical Standardization，Cenelec欧洲电工标准化委员会)里定义的广泛应用于工业控制自动化、汽车、机器人等领域的通信协议和控制管理方法。除了DS301，CiA还定义了很多其它的与CANopen相关的框架(framework)、设备配置模板(device profile)和应用配置模板(application profile)。
随着科学科技的发展，控制系统的应用范围不断扩大，受控制的节点越来越多，例如机器人系统，其具有运动量大、传感器多、关节多等特点，从而对节点数、指令响应速度以及传输速率的要求也会越来越高。而现有的CAN总线网络在多节点控制传输的情况下，无法满足高速率的要求。
发明内容
本公开的主要目的是提供一种PON网络，用于PON网络的方法及装置，以及机器人系统，能够在PON-CAN总线架构下支持ONU运行基于CANopen的应用。
为了实现上述目的，本公开实施例第一方面提供一种PON网络，所述PON网络包括：
作为网络管理控制主设备的光线路终端OLT；以及
作为网络管理控制从设备的至少一个光网络单元ONU；
其中，所述OLT中部署有CANopen协议层，所述ONU中部署有 CANopen协议层，使得所述OLT作为CANopen的网络管理终端NMT主节点，每一所述ONU作为CANopen的NMT从节点以运行基于CANopen的应用，且使得所述PON-CAN总线架构支持多个虚拟CAN总线，其中，每一所述虚拟CAN总线用于连接多个所述NMT从节点。
本公开实施例第二方面提供一种用于PON网络的装置，所述装置被配置为上述任一项所述的PON网络中的OLT。
本公开实施例第三方面提供一种用于PON网络的装置，所述装置被配置为如上述任一项所述的PON网络中的ONU。
本公开实施例第四方面提供一种用于PON网络的方法，所述PON网络包括：作为网络管理控制主设备的光线路终端OLT；以及作为网络管理控制从设备的至少一个光网络单元ONU，所述方法包括：
所述OLT接收所述至少一个ONU发送的接入请求；
所述OLT向所述ONU返回用于对所述ONU进行配置的配置请求；
所述OLT在接收到所述ONU返回的用于表征配置完成的消息时，与所述ONU建立通讯连接；
所述OLT基于与所述ONU建立的通讯连接向所述ONU发布主题消息，和/或接收所述ONU发布的主题消息。
本公开实施例第五方面提供一种用于PON网络的方法，所述PON网络包括：作为网络管理控制主设备的光线路终端OLT；以及作为网络管理控制从设备的至少一个光网络单元ONU，所述方法包括：
所述PON网络中的至少一个ONU向所述OLT发送接入请求；
所述ONU接收用于对所述ONU进行配置的配置请求，并根据所述配置请求进行配置；
所述ONU向所述OLT返回用于表征配置完成的配置响应；
所述ONU与所述OLT建立通讯连接；
所述ONU基于与所述OLT建立的通讯连接向所述OLT发布主题消息，和/或接收所述OLT发布的主题消息。
本公开实施例第六方面提供一种机器人系统，所述机器人系统包括上述任一项所述的PON网络。
通过采用上述技术方案，一个PON-CAN总线架构可以支持多条虚拟CAN总线，每一条虚拟CAN总线上支持多个CANopen的NMT节点，且作为NMT节点的ONU都可以运行CANopen的各种应用，并可以利用CANopen的相关框架(framework)、设备配置模板(device profile)和应用配置模板(application profile)，对PON-CAN总线架构上的所有节点进行管理和配置。
本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。
附图说明
附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：
图1是本公开实施例提供的一种PON-CAN总线架构的一种示意图；
图2是本公开实施例提供的一种OLT中用于实现Virtual CANopen over PON-CAN总线架构的CANopen协议层的模块构成的示意图；
图3是本公开实施例提供的一种OLT的结构示意图；
图4是本公开实施例提供的一种ONU中用于实现Virtual CANopen over PON-CAN总线架构的CANopen协议层的模块构成的示意图；
图5是本公开实施例提供的一种ONU的结构示意图；
图6是本公开实施例提供的一种OLT中CANopen管理模块的主状态机的一种示意图；
图7是本公开实施例提供的一种OLT中CANopen管理模块的从状态机的一种示意图；
图8是本公开实施例提供的一种用于PON网络的方法的流程示意图；
图9是本公开实施例提供的另一种用于PON网络的方法的流程示意图；
图10是本公开实施例提供的一种PON网络初始配置过程的示意图；
图11是本公开实施例提供的一种OLT向ONU发送PDO数据过程的示意图。
具体实施方式
以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。
为了是本领域技术人员能够更加容易理解本公开实施例提供的技术方案，首先对PON-CAN总线架构进行说明。
基于无源光纤组网以及对称耦合器和/或不对称耦合器构成的PON-CAN总线架构，避免了电磁干扰影响，并且层级之间不会造成带宽消减，从而可以提供非常高的带宽，进而在所连接的节点不断增加的情况下也可以满足高速率的传输要求，解决了现有CAN总线通信速率低，节点连接数受限的问题。
图1是PON-CAN总线架构的一种示意图，如图1所示，PON-CAN总线架构包括OLT(Optical Line Terminal，光线路终端)101，以及与该OLT101连接的光纤总线，其中，该光纤总线由多个不对称耦合器互连形成。例 如，图1中所示的光纤总线102，由多个不对称耦合器103互连形成，其中，图1只是以不对称耦合器之间的线性互连进行示意，在具体实施时，不对称耦合器之间可以采用其他互连方式，或者采用多种互连方式组合构成光纤总线。并且，光纤总线上连接有ONU(Optical Network Unit，光网络单元)，如图1中所示的ONU 104，其中，ONU 104用于实现光纤总线与电控的终端设备之间光电信号的转换，进而与OLT 101连接的的总信息设备(图1中未示出，例如可以是机器人系统的上位机)可以通过PON-CAN总线架构实现与终端设备之间的通信。
此外，对于PON-CAN总线架构中的PON网络，相关技术中存在部署MQTT-SN进行OLT与ONU节点间通讯的方案，实现OLT与ONU之间的消息总线和发布/订阅消息通讯模式。其中，消息队列遥测传输(Message Queuing Telemetry Transport，MQTT)是一个基于客户端服务端架构的支持发布/订阅消息通讯模式的消息传输协议。它的设计思想是轻巧、开放、简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境，如机器与机器的通信(Machine to Machine，M2M)、物联网环境(Internet of things，IoT)以及机器人系统内部通信。传感器版本的MQTT(MQTT For Sensor Networks，MQTT-SN)是在MQTT基础上专门针对各种低成本的电池驱动设备以及传感器的一个优化设计。MQTT-SN对底层网络服务没有严格要求。任何网络只要能在任何节点和特定节点(网关)之间提供双向数据传输服务就能够支持MQTT-SN。
上述PON-CAN总线架构支持灵活的消息总线拓扑，例如，一个Wavelength port(波长端口)上的一个波长CT(波长通道端口)下的最多128个ONU；或者，一个Wavelength port上的多个波长CT下的所有ONU为128乘N个，其中，N为波长CT的个数，1<＝N<＝8，也即最多1024个ONU；又或者，多个Wavelength port上的多个波长CT下的所有ONU超过1024个ONU(具体个数取决于系统整体和各个Wavelength port上对多个波长的支持)。
而如果需要在多个ONU上面运行CANopen的各种应用，由于一个CAN总线上CANopen的NMT(Network Management Terminal)节点个数最多只能127个，因此需要有方法能支持更多节点。
本公开实施例的目的即是提供一种PON网络，使得一个PON-CAN总线架构上的所有ONU都可以运行CANopen的各种应用，且PON-CAN总线架构可以支持更多的NMT节点，进一步地，使不同Virtual CAN总线之间保持隔离。值得说明的是，本公开实施例在物理层面上并不使用CAN，只是在软件层面上，利用CAN总线的现有实现，将以前基于CAN总线的装置尽可能在软件不变的情况下，运行在PON-CAN总线架构上。下面对本公开实施例提供的PON网络进行具体说明。
本公开一种示例性实施例中提供的PON网络包括：作为网络管理控制主设备的OLT和作为网络管理控制从设备的至少一个ONU；
所述OLT中部署有CANopen协议层，所述ONU中部署有CANopen协议层，使得所述OLT作为CANopen的NMT主节点，每一所述ONU能作为CANopen的NMT从节点以运行基于CANopen的应用，且使得所述PON-CAN总线架构支持多个虚拟CAN总线，其中每一所述虚拟CAN总线上用于连接多个所述NMT从节点。可选地，所述PON网络可以与CAN总线组成PON-CAN总线架构，该PON-CAN总线架构可以可以应用于机器人系统。本公开实施例中，将支持多个虚拟CAN总线的PON-CAN总线架构称为Virtual CANopen over PON-CAN总线架构。
具体地，为支持虚拟CAN总线，以及支持利用CiA定义的与CANopen相关的框架(framework)、设备配置模板(device profile)和应用配置模板(application profile)对PON-CAN总线架构上的所有节点进行管理和配置，本公开对现有的CANopen Manager(CANopen管理模块)的管理配置进行了重新设计，包括对NMT主节点和对NMT从节点的管理配置。
下面将分别对以下几个方面进行举例说明：
网络管理控制主设备(NMC-M)中用于实现Virtual CANopen over PON-CAN总线架构的CANopen协议层的模块构成；
网络管理控制从设备(NMC-S)中用于实现Virtual CANopen over PON-CAN总线架构的CANopen协议层的模块构成；
Virtual CANopen NMT节点号和PON-CAN NMC节点号映射方法；
虚拟CAN总线(Virtual CAN bus)的定义以及利用Virtual CAN bus在新型现场总线(fieldbus)上支持超过一个传统CAN总线节点容量的方法；
Virtual CANopen over PON-CAN总线架构对象字典(Object Dictionary)；
Virtual CANopen over PON-CAN总线架构消息格式；
基于Virtual CANopen over PON-CAN总线架构的消息主题实现隔离不同virtual CAN bus的方法；
基于消息主题实现虚拟CAN总线和Virtual CANopen over PON-CAN总线的映射方法；
Virtual CANopen over PON-CAN总线架构上主CANopen管理模块(Master CANopen Manager)的实现方法；
Virtual CANopen over PON-CAN总线架构上CANopen管理模块(CANopen Manager)的状态机及其实现方法。
第一方面，网络管理控制主设备(NMC-M)中用于实现Virtual CANopen over PON-CAN总线架构的CANopen协议层的模块构成如图2所示，包括：
虚拟CANopen应用层(Virtual CANopen Application)20、SDO分段重 组管理器(SDO segmentation Reassembly Manager)21、服务数据对象(Service Data Object，SDO)层22、过程数据对象(Process Data Object，PDO)层23、CANopen主适配器(CANopen Adapter Master)24、网络管理控制客户端接口25和消息总线客户端接口26；
其中，所述虚拟CANopen应用层20包括：
主CANopen管理模块(Master CANopen Manager)201，用于支持所述OLT作为NMT主节点对虚拟CAN总线上的NMT从节点进行管理和配置；
CANopen管理模块(CANopen Manager)202，用于配置每一个所述NMT节点上的CANopen应用；
其中，SDO分段重组管理器21包括CANopen架构中SDO层22的封装层，SDO分段重组管理器21连接虚拟CANopen应用层20和SDO层22，用于在读写对象字典的过程中，在传送时将长度超过预定值对象数据分割传送，在接收时将被分割传送的对象数据重新拼装成原始对象数据，该预定值例如可以为4字节。
CANopen主适配器24与SDO层22、PDO层23、CANopen应用层20、网络管理控制客户端接口25和消息总线客户端接口26连接，用于将网络管理控制客户端接口25和消息总线客户端接口26适配到SDO层22，PDO层23和CANopen应用层20。其中，网络管理控制客户端接口25用于与OLT的状态机模块中的网络管理控制服务器接口相连，消息总线客户端接口26用于与OLT的消息总线层模块中的消息总线服务器接口相连。
值得说明的是，CANOpen中的实时数据传输是由PDO来完成的。PDO的传输采用了生产者消费者模式。共有两种PDO：TPDO(Transmit-PDO，传输PDO)和RPDO(Receive-PDO，接收PDO)。TPDO用来传输数据，支持TPDO的节点都是PDO数据的生产者；RPDO用来接收PDO数据，支持RPDO的节点是PDO数据的消费者。
SDO使用客户端服务器模式建立起点到点的通讯并实现了对对象字典中条目的读写。其中被访问的对象字典的所在设备作为服务器，访问对象字典的设备作为客户端。SDO采用请求应答模式，每次SDO访问都会有2条CAN的数据帧对应：一条是请求，一条是应答。
图3示出了OLT的另一种结构示意图，如图3所示，OLT包括第一消息总线层模块28，第一状态机模块27，第一传输网络29以及图2所示的CANopen协议层的模块构成，呈现出了图2所示的CANopen协议层的模块构成与OLT的第一状态机模块27以及第一消息总线层模块28之间的连接关系。
其中，所述第一状态机模块27包括：主状态机，用于根据OLT自身发生的事件进行状态操作；从状态机用于根据接入OLT的ONU发生的事件进行状态操作；网络管理控制服务端接口，用于支持所述第一状态机模块27 在所述第一消息总线层模块28实现所述OLT与所述ONU之间通讯的服务规格和服务流标记；网络控制器，用于所述第一状态机模块27对所述第一传输网络29进行NMC服务配置。
第一消息总线层模块28，用于提供消息总线服务器和第一消息总线客户端，以支持所述OLT中的消息总线客户端的用户和所有ONU中的消息总线客户端的用户注册和订阅消息主题，发布和接收主题消息。其中，所述OLT中的消息总线客户端的用户是指具备消息总线客户端接口的模块，例如，第一状态机模块27还包括消息总线客户端接口，使得所述第一状态机模块27作为消息总线客户端的用户可以在所述消息总线服务器注册和订阅消息主题以及发布和接收主题消息。
第一消息总线层模块28还包括网络管理控制客户端接口，用于支持所述第一状态机模块在所述第一消息总线层模块实现所述OLT与所述ONU之间通讯的服务规格和服务流标记；网络适配器，与所述OLT的传输网络相连，实现所述第一消息总线层模块28与所述第一传输网络29的适配，其中，所述网络适配器存储所述OLT与所述ONU之间的每一消息主题的消息传送路径。
图2所示的CANopen协议层的模块构成中的网络管理控制客户端接口25用于与OLT的第一状态机模块27中的网络管理控制服务器接口相连，以同步读取第一状态机模块27的状态信息和异步获取第一状态机模块27的状态变化和事件，消息总线客户端接口26用于与OLT的第一消息总线层模块28中的消息总线服务器接口相连。其中，虚拟CANopen应用层可以通过消息总线客户端接口订阅、发布主题消息，以及在消息总线服务器中进行消息主题的注册。
第二方面，网络管理控制从设备(NMC-S)中用于实现Virtual CANopen over PON-CAN总线架构的CANopen协议层的模块构成如图4所示，包括：
CANopen应用模块31、服务数据对象SDO层32、过程数据对象PDO层33、CANopen从适配器34、网络管理控制客户端接口35和消息总线客户端接口36；
所述CANopen应用模块31与所述CANopen从适配器34、所述SDO层32和所述PDO层33相连，用于运行基于CANopen的应用，也就是说，所述CANopen应用模块31包括现有技术中的基于CANopen协议的应用程序和核心对象数据；
所述CANopen从适配器34与所述SDO层32、所述PDO层33、所述网络管理控制客户端接口35和所述消息总线客户端接口36连接，用于把所述网络管理控制客户端接口35和消息总线客户端接口36适配到所述SDO层32，所述PDO层33和所述CANopen应用模块31，以达到让所述SDO层32、所述PDO层33和所述CANopen应用模块31可以不做修改，直接 运行在PON-CAN总线架构上的目的。
另外，值得说明的是，本公开实施例中仍然保持每一个PON-CAN的NMC从节点作为一个CANopen的NMT从节点，并利用所述CANopen从适配器34，使得图4中的CANopen应用模块31、服务数据对象SDO层32、过程数据对象PDO层33的可以不做修改直接运行在PON-CAN总线架构上，以最大限度重用现有技术中的基于CANopen协议的应用程序和核心对象数据传送模块。
对于虚拟CAN总线的支持主要依赖于CANopen从适配器34，例如，OUN和OLT之间的不同消息主题对应不同的虚拟CAN总线，每一条虚拟CAN总线的消息在具有该虚拟CAN总线标识信息的消息主题中发送，作为NMT从节点的ONU即可通过CANopen从适配器适配的网络管理控制客户端接口和消息总线客户端接口与作为NMT主节点的OLT实现在不同消息主题上的通讯。
图5示出了ONU的另一种结构示意图，如图5所示，ONU包括第二消息总线层模块38、第二状态机模块37、第二传输网络39以及图4所示的CANopen协议层的模块构成，图5呈现了图4所示的CANopen协议层的模块构成与ONU的第二状态机模块37以及第二消息总线层模块38之间的连接关系。
第二状态机模块37，用于运行根据所述ONU自身发生的事件以及根据所述第一状态机模块中运行的从状态机的事件进行状态操作的从状态机；第二消息总线层模块38，用于提供第二消息总线客户端，以支持所述ONU中的消息总线客户端的用户注册和订阅消息主题，发布和接收主题消息，其中，ONU中的消息总线客户端的用户是指具有消息中线客户端接口的模块，例如第二状态机模块37包括消息总线客户端接口，使得第二状态机模块37通过第二消息总线客户端，可以在OLT侧的消息总线服务器注册和订阅消息主题，发布和接收主题消息。
具体地，所述第二状态机模块37还包括：
网络管理控制服务端接口，用于支持所述第二状态机模块37通过所述第二消息总线层模块38实现所述ONU与所述OLT之间通讯的服务规格和服务流标记；
网络控制器，用于所述第二状态机模块对所述第二传输网络39进行NMC服务配置。
所述第二消息总线层模块38还包括：
网络管理控制客户端接口，用于支持所述第二状态机模块37在所述第二消息总线层模块38实现所述ONU与所述OLT之间通讯的服务规格和服务流标记；
网络适配器，与所述所述第二传输网络39相连，实现所述第二消息总 线层模块38与所述第二传输网络39的适配。
图4所示的CANopen协议层的模块构成中的网络管理控制客户端接口35用于与ONU的第二状态机模块37中的网络管理控制服务器接口相连，以同步读取第二状态机模块37中从状态机的状态信息和异步获取第二状态机模块37中从状态机的状态变化和事件，消息总线客户端接口36用于与ONU的第二消息总线层模块38中的消息总线服务器接口相连。其中，ONU的CANopen应用模块可以通过该消息总线客户端接口36订阅、发布主题消息，以及在消息总线服务器中进行消息主题的注册。
第三方面，由于ONU即作为PON-CAN总线的NMC从节点，又作为CANopen的NMT从节点，因此，本公开实施例可以在PON-CAN总线系统里采用静态配置的方式把NMC节点号映射成CANopen NMT节点号。
进一步地，第四方面，在CANopen NMT节点号的基础上，本公开实施例还可以在CANopen的节点号之外增加一个Virtual CAN总线ID作为虚拟总线的标识信息，让Virtual CAN总线ID和CANopen NMT节点号一起构成CANopen over PON-CAN总线架构上Virtual CANopen NMT节点号。该Virtual CANopen NMT节点号用以支持多个Virtual CAN总线，每一个Virtual CAN总线上支持最多127个节点(相比与传统CAN总线支持127个节点，具有普遍意义，通用性更强)，让一个PON-CAN总线上的所有ONU都可以运行CANopen的各种应用。并且可以实现不同Virtual CAN总线之间保持隔离。
鉴于系统的容量大小和整体处理能力、以及和消息头大小的平衡考虑，本公开实施例可以定义Virtual CAN总线ID为4个比特，可以在一个PON-CAN总线上支持16条Virtual CAN总线，总共2032个Virtual CANopen节点(127×16＝2032)。在实际系统的使用中，Virtual CAN总线ID的比特数目可以根据需要调整，本公开对此不做限定。
示例地，其中虚拟CAN总线ID的定义可以如下表1所示：
Figure PCTCN2019109256-appb-000001
表1
具体地，NMC-M上的Virtual CANopen over PON-CAN CANopen Manager(例如图2中所示的CANopen管理模块202)可以根据每一个NMC-S 节点上的CANopen NMT从节点所在的Virtual CAN总线ID，将该Virtual CAN总线上所有CANopen NMT从节点的节点号和其对应的PON-CAN NMC节点号的映射表写到该节点的对象字典中的CANopen节点号和NMC节点号映射表中。
也就是说，在OLT作为CANopen协议下的NMT主节点、ONU作为CANopen协议下的NMT从节点的情况下，所述OLT可以针对每一ONU，确定该ONU作为的NMT从节点所处的虚拟CAN总线的标识信息(Virtual CAN Bus ID)，将该标识信息以及该NMT从节点的节点号和该ONU的NMC节点号之间的映射表写入该ONU的对象字典中。
第五方面，以下将对Virtual CANopen over PON-CAN总线架构的对象字典进行说明。
参照上述对Virtual CAN总线ID的说明，本公开实施例可以在对象字典Communication Profile部分中的1C91增加Virtual CAN总线ID。这样，Virtual CANopen over PON-CAN总线架构的对象字典如下表2所示：
Figure PCTCN2019109256-appb-000002
Figure PCTCN2019109256-appb-000003
表2
第六方面，说明Virtual CANopen over PON-CAN总线架构上消息总线的消息格式，包括消息总线节点间面向连接消息通信服务和消息格式：
在Virtual CANopen over PON-CAN消息头(VCoP Header)增加虚拟CAN总线ID域，如下表3所示：
Figure PCTCN2019109256-appb-000004
表3
其中，CANopen over PON-CAN服务类型和传送消息主题如下表4所 示：
Figure PCTCN2019109256-appb-000005
表4
第七方面，说明基于Virtual CANopen over PON-CAN总线架构的消息主题实现隔离不同虚拟CAN总线的方法。
具体地，本公开实施例可以让不同的虚拟CAN总线上的消息，传送在按虚拟CAN总线ID(vCANBusID)区分的不同的消息主题里，来隔离不同的虚拟CAN总线。也就是说，作为NMT主节点的OLT和作为NMT从节点的ONU注册的消息主题中包括对应的虚拟CAN总线的标识信息，每一虚拟CAN总线上的消息在具有该虚拟CAN总线的标识信息的消息主题中传送，以隔离不同的虚拟CAN总线。
在实际系统中，可以根据系统的规模、隔离的具体需要，利用Virtual CANopen over PON-CAN(VCoP)Header中的虚拟CAN总线ID，将不同虚拟CAN总线的传送消息主题进行组合，实现在隔离和规模中达到平衡。由于在每一个PON-CAN NMC从节点上只支持一个CANopen NMT从节点，因此，PON-CAN NMC从节点上的Virtual CANopen over PON-CAN子系统会保持其上运行的传统CANopen over PON-CAN子系统(即图3所示的ONU中的模块结构)被完全隔离在自己的虚拟CAN总线。
第八方面，说明基于消息主题实现虚拟CAN总线和Virtual CANopen over PON-CAN总线的映射方法。
首先，PON-CAN总线架构可以定义一个统一的Virtual CANopen over PON-CAN控制通道消息主题来模拟CANopen环境下的广播总线，NMC-M主节点和所有NMC-S从节点都可以直接在这个消息主题发布和接收控制消息。如表4所示，在这个控制通道中传送的消息包括：
同步SYNC、时间TIME、紧急通讯EMCY、NMT模块控制服务NMT Module Control Service、NMT错误控制服务NMT Error Control Service、NMT启动服务NMT Bootup Service、以及读取PDO远程传输请求(Read PDO Remote Transmission Request，RTR)。
进一步地，在传送的消息格式上，Virtual CANopen over PON-CAN总线架构可以通过把原始的CANopen消息去除帧起始(start of frame，SOF)、循环冗余校验(cyclic redundancy check，CRC)、帧结尾(end of frame，EOF)域后直接作为CANopen over PON-CAN的业务数据单元SDU。
本公开实施例提供的Virtual CANopen over PON-CAN总线架构可以支持多种CANopen消息格式，例如CAN基本格式、CAN扩展格式、具有灵活数据速率的CAN FD(CAN with Flexible Data-Rate)基本格式、CAN FD扩展格式。在此种情况下，CANopen主适配器和CANopen从适配器负责在PON-CAN的消息格式和CANopen管理模块和CANopen应用接口上的转换和模拟。
在本公开实施例的一种可能的实现方式中，Virtual CANopen over PON-CAN总线架构上的所有消息主题可以如下表5所示：
Figure PCTCN2019109256-appb-000006
Figure PCTCN2019109256-appb-000007
表5
下面返回对第六方面中的消息格式进行说明，具体包括对SDO消息和PDO消息的说明。
首先，针对SDO消息，本公开实施例可以在基本面向连接头(Basic Connection-Oriented Header)上加上Virtual CANopen over PON-CAN(VCoP)Header，用于SDO服务的Virtual CANopen over PON-CAN面向连接头的定义如下表6所示：
Figure PCTCN2019109256-appb-000008
Figure PCTCN2019109256-appb-000009
表6
针对PDO消息格式，本公开实施例可以采用Virtual CANopen over PON-CAN(VCoP)Header。
第九方面，说明Virtual CANopen over PON-CAN总线架构主CANopen管理模块(Master CANopen Manager)的实现方法。其中，主CANopen管理模块是整个Virtual CANopen over PON-CAN总线架构的管理和配置模块。
具体地，作为网络控制管理主设备的OLT中的主CANopen管理模块可以通过如下操作实现所述虚拟CAN总线的管理和配置：
根据每一虚拟CANopen NMT节点号，生成对应的配置文件(例如，驱动器配置文件DCF文件)；
判断新生成的DCF配置文件与上一次生成的DCF配置文件是否相同，如果不相同，则根据新生成的DCF配置文件更新上一次生成的DCF配置文件和DCF配置文件的时间标签；
对于每一个至少存在一个NMT从节点的虚拟CAN总线，对于该虚拟CAN总线上的每一个NMT从节点，启动CANopen管理模块中和该虚拟CAN总线上NMT从节点对应的状态机实例，并把更新后的DCF配置文件和DCF配置文件时间标签作为参数传送给所述状态机实例，以实现根据新生成的DCF配置文件配置这个虚拟CAN总线上NMT从节点，并在完成该虚拟CAN总线上的所有NMT从节点的配置后，启动(start)该虚拟CAN总线上的所有NMT从节点。
示例地，以下将结合具体命令描述主CANopen管理模块的主要处理过程，该过程可以包括：
convertSysConfigtoNodeConfigVCoPDCF(node＝NMC_VCOP_NODE_AL L)：
将整个Virtual CANopen over PON-CAN的配置按每一个节点(用Virtual CAN总线ID+CANopen NMT节点ID唯一标识)进行分解，生成Virtual CANopen over PON-CAN DCF配置文件；
verifyNodeConfigVCoPDCFVersion(node＝NMC_VCOP_NODE_ALL)：
对于每一个节点(用Virtual CAN总线ID+CANopen NMT节点ID唯一标识)，比较上述生成的DCF配置文件和保存的上一次DCF配置文件。如果不相同，则更新保存的上一次DCF配置文件和DCF配置文件时间标签；如果相同，则保持上一次DCF配置文件和时间标签不变；
startNodeVCoPManager(node＝NMC_VCOP_NODE_ALL)：
针对每一个至少存在一个CANopen NMT从节点的Virtual CAN总线(vCANBusID)上的每一个CANopen NMT Slave节点，启动CANopen管理模块中和该从节点对应的状态机实例，并将上一次DCF配置文件和DCF配置文件时间标签作为参数传送给状态机实例；
resetNodeVCoPSlave(vCANBusID，nodeID＝NMC_VCOP_NMT_NODE_
ALL)：
利用sendNMTModCtrlReq(cs＝NMT_MOD_RESET_NODE，nodeID＝0)来重新启动整个vCANBusID上的所有CANopen NMT从节点。
可选地，CANopen管理模块管理命令和其状态机进行状态转移的事件图如下表7所示：
Figure PCTCN2019109256-appb-000010
Figure PCTCN2019109256-appb-000011
Figure PCTCN2019109256-appb-000012
表7
第十方面，说明Virtual CANopen over PON-CAN总线架构上CANopen管理模块的状态机及其实现方法。
图6是CANopen管理模块的主状态机的一种示意图。如图6所示，CANopen管理模块的主状态机用于根据以下事件中的至少一件进行状态转移：
用于表征NMT主节点请求对NMT从节点进行控制的事件，该事件后文用VNMT_MOD_CTRL_REQ表示；
用于表征NMT从节点启动的事件，该事件后文用VNMT_BOOTUP_IND表示；
用于表征获取到NMT从节点心跳报文的事件，该事件后文用VNMT_HEARTBEAT_IND表示；
用于表征获取到NMT从节点的SDO响应的事件，该事件后文用VNMT_SDO_RESP；
用于表征NMT心跳报文超时的事件，该事件后文用VNMT_HEARTBEAT_CONSUMER_TIMEOUT。
具体地，图6中所示的主状态机包括初始化(Initialisation)、预运行(Pre-Operational)、运行(Operational)、停止(Stopped)四个状态，下面对主状态机关键的状态转移进行说明，如图6中圆形标记出的1-7所示，其中：
1、在初始化状态下，若发生NMT从节点启动的VNMT_BOOTUP_IND事件，则执行getConfigLastTimestamp()以及startHeartbeatConsumerTimer()，并转移到预运行状态，getConfigLastTimestamp()函数用于为NMT从节点配置最新的时间戳，startHeartbeatConsumerTimer()函数用于为NMT从节点启动消费者心跳检测定时器；
2、在预运行状态下，若发生获取到NMT从节点的SDO响应错误事件(图中用VNMT_SDO_RESP(rslt)[rslt＝ERR]表示)，则向该NMT从节点发送用于重置该NMT从节点的NMT控制请求(图中用sendNMTModCtrlReq(cs＝NMT_MOD_RESET_NODE)表示)，并转移到初始化状态；
3、在预运行状态下，若发生SDO响应成功的事件(图中用VNMT_SDO_RESP(rslt)[rslt＝OK and allConfigCompleted＝True]表示)，则向该NMT从节点发送用于启动该NMT从节点的NMT控制请求(图中用sendNMTModCtrlReq(cs＝NMT_MOD_START_NODE)表示)，并转移到运行状态；
4、在运行状态下，若接收到NMT从节点用于请求转移到预运行状态的NMT控制请求(图中用VNMT_MOD_CTRL_REQ(cs)[cs＝NMT_MOD_STATE_PREOPERATIONAL]表示)，则发送用于控制该NMT从节点转移到预运行状态的NMT控制请求(图中用sendNMTModCtrlReq(cs＝NMT_MOD_STATE_PREOPERATIONAL)表示)，并为该NMT从节点设置最新的时间戳(如图中所示的getConfigLastTimestamp())，以及重启该NMT从节点的消费者心跳检测定时器(如图中的restart HeartbeatConsumerTimer())，并转移到预运行状态；
5、在预运行状态下，若接收到用于请求停止运行的NMT控制请求(图中用VNMT_MOD_CTRL_REQ(cs)[cs＝NMT_MOD_STOP_NODE]表示)，则发送用于控制停止运行的NMT控制请求(图中用sendNMTModCtrlReq(cs＝NMT_MOD_STOP_NODE)表示)，并转移到停止状态；
6、在停止状态下，若接收到NMT从节点用于请求转移到预运行状态的NMT控制请求(图中用VNMT_MOD_CTRL_REQ(cs)[cs＝NMT_MOD_ STATE_PREOPERATIONAL]表示)，则发送用于控制该NMT从节点转移到预运行状态的NMT控制请求(图中用sendNMTModCtrlReq(cs＝NMT_MOD_STATE_PREOPERATIONAL)表示)，并为该NMT从节点设置最新的时间戳(如图中所示的getConfigLastTimestamp()所示)，以及重启该NMT从节点的消费者心跳检测定时器(如图中的restart HeartbeatConsumerTimer()所示)，并转移到预运行状态；
7、在预运行状态下，若发生NMT从节点重置事件或者通讯连接重置事件(VNMT_MOD_CTRL_REQ(cs)[cs＝NMT_MOD_RESET_NODE or NMT_MOD_RESET_COMM])或者消费者心跳检测超时事件(图中用VNMT_HEARTBEAT_CONSUMER_TIMEOUT表示)，则发送用于重置NMT从节点或者重置通讯连接的NMT控制请求(图中用sendNMTModCtrlReq(cs＝NMT_MOD_RESET_NODE or NMT_MOD_RES ET_COMM)表示)，并转移到初始化状态。
图6中示出的其他状态转移情况，不再一一赘述。
在本公开实施例一种可能的实现方式中，CANopen管理模块包括从状态机，如图7所示，该从状态机用于根据以下事件中的至少一件进行状态转移：
用于表征NMT主节点请求对NMT从节点进行控制的事件，该事件后文用VNMT_MOD_CTRL_REQ表示；
用于表征NMT从节点启动的事件，该事件后文用VNMT_BOOTUP_IND表示；
用于表征获取到NMT从节点心跳报文的事件，该事件后文用VNMT_HEARTBEAT_IND表示；
用于表征获取到NMT从节点的SDO响应的事件，该事件后文用VNMT_SDO_RESP表示；
用于表征NMT心跳报文超时的事件，该事件后文用VNMT_HEARTBEAT_CONSUMER_TIMEOUT表示。
具体地，图7中所示的从状态机(该从状态机为图6所示的主状态机中预运行状态的子状态机)，包括配置版本ConfigVersion状态以及配置进入ConfigEntry状态。参照上述对图6中主状态机关键的状态转移1-7的说明可知，1、4、6表征的状态转移是进入预运行状态，对应的子状态机的ConfigVersion状态，2、3、5、7表征的状态转移是转移出预运行状态，对应的是子状态机的ConfigEntry状态，而图7即具体示出了1-7对应的事件在预运行状态内部的处理，其中，ConfigVersion状态转移到ConfigEntry状态的触发事件是图7中示出的VNMT_SDO_RESP(ConfigLastTimestamp)[OK and configLastTimestamp is not Latest]/startConfigDCF()，即在ConfigVersion 状态下，若NMT从节点的时间戳非最新时间戳时(DCF配置文件发生变化)，则重新配置虚拟CAN总线上的所有NMT从节点，并转移到ConfigEntry状态。
采用上述PON网络，通过以上十方面的设计，使得该PON网络在组成PON-CAN总线架构时，能够利用CANopen的相关框架(framework)、设备配置模板(device profile)和应用配置模板(application profile)，对PON-CAN总线架构上的所有节点进行管理和配置，并且支持多条Virtual CAN总线，每一个Virtual CAN总线上支持最多127个CANopen的NMT节点，让PON-CAN总线上的所有ONU都可以运行CANopen的各种应用。
本公开实施例还提供一种OLT，该OLT被配置为上述PON网络中的作为网络管理控制主设备的OLT。
本公开实施例还提供一种用于PON网络的方法，该方法的执行主体例如可以是上述OLT，所述PON网络包括：作为网络管理控制主设备的光线路终端OLT，以及作为网络管理控制从设备的至少一个光网络单元ONU，所述PON网络可以与CAN总线组成PON-CAN总线架构，如图8所示，所述方法包括：
S801、PON网络中的OLT接收至少一个ONU发送的接入请求。
S802、所述OLT向所述ONU返回用于对所述ONU进行配置的配置请求。
S803、所述OLT在接收到所述ONU返回的用于表征配置完成的消息时，与所述ONU建立通讯连接。
例如所述OLT与所述ONU可以通过三次握手建立通讯连接。
S804、所述OLT基于与所述ONU建立的通讯连接向所述ONU发布主题消息，和/或接收所述ONU发布的主题消息。
值得说明的是，ONU接入OLT以及与OLT建立通讯过程中，OLT内部的状态机的变化可以参照图6以及图7，以及OLT与ONU之间的控制通道消息主题、SDO消息主题的传送、PDO消息主题的传送等均可以参照上述对PON网络的说明，此处不再赘述。
本公开实施例还提供一种ONU，该ONU被配置为上述PON网络中的作为网络管理控制从设备的ONU。
本公开实施例还提供一种用于PON网络的方法，该方法的执行主体例如可以是上述ONU，所述PON网络包括：作为网络管理控制主设备的光线路终端OLT，以及作为网络管理控制从设备的至少一个光网络单元ONU，所述PON网络可以与CAN总线组成PON-CAN总线架构，如图9所示，所述方法包括：
S901、PON网络中的至少一个ONU向OLT发送的接入请求。
S902、所述ONU接收用于对所述ONU进行配置的配置请求，并根据 所述配置请求进行配置。
S903、所述ONU向所述OLT返回用于表征配置完成的配置响应。
S904、所述ONU与所述OLT建立通讯连接。
S905、所述ONU基于与所述OLT建立的通讯连接向所述OLT发布主题消息，和/或接收所述OLT发布的主题消息。
结合OLT和ONU两侧的方法步骤，图10示出了PON网络初始配置的过程，图11示出了OLT向ONU发送PDO数据的过程，图中涉及到的相关步骤均已在上述实施例中进行描述，此处不再赘述。
本公开实施例还提供一种机器人系统，所述机器人系统包括以上实施例中提供的PON网络。
如图1所示，机器人系统中的上位机可以作为PON-CAN总线架构中的OLT。而中位机系统、电源管理系统、下位机控制系统、各个肢体关节的伺服系统、各个肢体关节相应的终端设备，可以位于与PON-CAN总线架构的光纤总线连接的下一级网络。
采用本公开实施例提供的机器人系统，机器人系统的各控制设备以及终端可以通过PON-CAN总线架构连接起来，由于虚拟总线的存在，该PON-CAN总线架构的节点扩展性强，因此可以根据系统实际需要连接多个机器人拓扑终端，解决现有机器人总线系统中节点受限问题，且保证了在节点不断增加的情况下也可以满足高速率的传输要求。
以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。
另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。
此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。

Claims (15)

  1. 一种PON网络，其特征在于，所述PON网络包括：
    作为网络管理控制主设备的光线路终端OLT；以及
    作为网络管理控制从设备的至少一个光网络单元ONU；
    其中，所述OLT中部署有CANopen协议层，所述ONU中部署有CANopen协议层，使得所述OLT作为CANopen的网络管理终端NMT主节点，每一所述ONU作为CANopen的NMT从节点以运行基于CANopen的应用，且使得所述PON-CAN总线架构支持多个虚拟CAN总线，其中，每一所述虚拟CAN总线用于连接多个所述NMT从节点。
  2. 根据权利要求1所述的PON网络，其特征在于，所述OLT包括虚拟CANopen应用层、服务数据对象SDO分段重组管理器、SDO层、过程数据对象PDO层、CANopen主适配器、网络管理控制客户端接口、消息总线客户端接口；
    其中，所述虚拟CANopen应用层包括：
    主CANopen管理模块，用于支持所述OLT作为NMT主节点对所述虚拟CAN总线上的NMT从节点进行管理和配置；以及
    CANopen管理模块，用于配置每一个所述NMT节点上的CANopen应用；
    其中，所述SDO分段重组管理器包括CANopen架构中SDO的封装层，所述SDO分段重组管理器连接所述虚拟CANopen应用层和所述SDO层，用于在读写对象字典的过程中，在传送时将长度超过预定值的对象数据分割传送，在接收时将被分割传送的对象数据重新拼装成原始对象数据；
    其中，所述CANopen主适配器与所述SDO层、所述PDO层、所述虚拟CANopen应用层、所述网络管理控制客户端接口和所述消息总线客户端接口连接；
    所述网络管理控制客户端接口用于与所述OLT的状态机模块中的网络管理控制服务器接口相连，所述消息总线客户端接口用于与所述OLT的消息总线层模块中的消息总线服务器接口相连。
  3. 根据权利要求1所述的PON网络，其特征在于，所述ONU包括CANopen应用模块、SDO层、PDO层、CANopen从适配器、网络管理控制客户端接口和消息总线客户端接口；
    所述CANopen应用模块与所述CANopen从适配器、所述SDO层和所述PDO层相连，用于运行基于CANopen的应用；
    所述CANopen从适配器与所述SDO层、所述PDO层、所述网络管理 控制客户端接口和所述消息总线客户端接口相连；
    所述网络管理控制客户端接口用于与所述ONU的状态机模块中的网络管理控制服务器接口相连，所述消息总线客户端接口用于与所述ONU的消息总线层模块中的消息总线服务器接口相连。
  4. 根据权利要求1-3任一项所述的PON网络，其特征在于，每一所述ONU作为所述OLT的网络管理控制NMC从节点，且每一所述ONU作为所述OLT的CANopen协议控制下的网络管理NMT从节点；
    其中，所述PON网络采用静态配置的方式将每一所述ONU的NMC节点号映射为NMT节点号。
  5. 根据权利要求1-3任一项所述的PON网络，其特征在于，每一所述虚拟CAN总线具有标识信息；
    每一所述虚拟CAN总线的标识信息与该虚拟CAN总线上的NMT节点的节点号组成所述PON-CAN网络结构上的一个虚拟CANopen NMT节点号；
    所述OLT用于，针对每一ONU，确定该ONU作为NMT从节点时，该NMT从节点所处的虚拟CAN总线的标识信息，将该标识信息以及该NMT节点的节点号和该ONU的NMC节点号之间的映射表写入该ONU的对象字典中。
  6. 根据权利要求5所述的PON网络，其特征在于，所述虚拟CAN总线上的节点间消息的消息头中包括虚拟总线ID域，用于承载虚拟总线的标识信息。
  7. 根据权利要求1-3任一项所述的PON网络，其特征在于，所述OLT和所述ONU注册的消息主题中包括对应的虚拟CAN总线的标识信息，每一所述虚拟CAN总线上的消息在具有该虚拟CAN总线的标识信息的消息主题中传送，以隔离不同的虚拟CAN总线。
  8. 根据权利要求5所述的PON网络，其特征在于，所述OLT中的主CANopen管理模块具体用于通过如下操作实现所述虚拟CAN总线的管理和配置：
    根据每一所述虚拟CANopen NMT节点号，生成对应的配置文件；
    判断新生成的配置文件与上一次生成的配置文件是否相同，如果不相同，则根据新生成的文件更新上一次生成的配置文件和配置文件的时间标签；
    对于每一个至少存在一个NMT从节点的虚拟CAN总线，对于该虚拟 CAN总线上的每一个NMT从节点，启动所述CANopen管理模块中和该虚拟CAN总线上NMT从节点对应的状态机实例，并把更新后的配置文件和配置文件时间标签作为参数传送给所述状态机实例，以根据新生成的配置文件配置该虚拟CAN总线上的NMT从节点，并在完成该虚拟CAN总线上的所有NMT从节点的配置后，启动该虚拟CAN总线上的所有NMT从节点。
  9. 根据权利要求2所述的PON网络，其特征在于，所述CANopen管理模块的主状态机用于根据以下事件中的至少一件进行状态转移：
    用于表征NMT主节点请求对NMT从节点进行控制的事件；
    用于表征NMT从节点启动的事件；
    用于表征获取到NMT从节点心跳报文的事件；
    用于表征获取到NMT从节点的SDO响应的事件；
    用于表征NMT心跳报文超时的事件。
  10. 根据权利要求2所述的PON网络，其特征在于，所述CANopen管理模块的从状态机用于根据以下事件中的至少一件进行状态转移：
    用于表征NMT主节点请求对NMT从节点进行控制的事件；
    用于表征NMT从节点启动的事件；
    用于表征获取到NMT从节点心跳报文的事件；
    用于表征获取到NMT从节点的SDO响应的事件；
    用于表征NMT心跳报文超时的事件。
  11. 一种用于PON网络的装置，其特征在于，所述装置被配置为如权利要求1-10任一项所述的PON网络中的OLT。
  12. 一种用于PON网络的装置，其特征在于，所述装置被配置为如权利要求1-10任一项所述的PON网络中的ONU。
  13. 一种用于PON网络的方法，所述PON网络包括：作为网络管理控制主设备的光线路终端OLT；以及作为网络管理控制从设备的至少一个光网络单元ONU，其特征在于，所述方法包括：
    所述OLT接收所述至少一个ONU发送的接入请求；
    所述OLT向所述ONU返回用于对所述ONU进行配置的配置请求；
    所述OLT在接收到所述ONU返回的用于表征配置完成的消息时，与所述ONU建立通讯连接；
    所述OLT基于与所述ONU建立的通讯连接向所述ONU发布主题消息，和/或接收所述ONU发布的主题消息。
  14. 一种用于PON网络的方法，所述PON网络包括：作为网络管理控制主设备的光线路终端OLT；以及作为网络管理控制从设备的至少一个光网络单元ONU，其特征在于，所述方法包括：
    所述PON网络中的至少一个ONU向所述OLT发送接入请求；
    所述ONU接收用于对所述ONU进行配置的配置请求，并根据所述配置请求进行配置；
    所述ONU向所述OLT返回用于表征配置完成的配置响应；
    所述ONU与所述OLT建立通讯连接；
    所述ONU基于与所述OLT建立的通讯连接向所述OLT发布主题消息，和/或接收所述OLT发布的主题消息。
  15. 一种机器人系统，其特征在于，所述机器人系统包括权利要求1-10任一项所述的PON网络。
PCT/CN2019/109256 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统 WO2020063995A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862739214P 2018-09-29 2018-09-29
US62/739,214 2018-09-29

Publications (1)

Publication Number Publication Date
WO2020063995A1 true WO2020063995A1 (zh) 2020-04-02

Family

ID=69950254

Family Applications (8)

Application Number Title Priority Date Filing Date
PCT/CN2019/096208 WO2020063044A1 (zh) 2018-09-29 2019-07-16 节点通讯方法，服务器，客户端
PCT/CN2019/096217 WO2020063048A1 (zh) 2018-09-29 2019-07-16 Pon网络及其通讯方法，olt，mqtt-sn网关，onu及mqtt服务器
PCT/CN2019/109252 WO2020063993A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统
PCT/CN2019/109256 WO2020063995A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统
PCT/CN2019/109257 WO2020063996A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统
PCT/CN2019/109247 WO2020063992A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统
PCT/CN2019/109246 WO2020063991A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统
PCT/CN2019/109263 WO2020063997A1 (zh) 2018-09-29 2019-09-30 节点间通信方法、通信节点以及通信系统

Family Applications Before (3)

Application Number Title Priority Date Filing Date
PCT/CN2019/096208 WO2020063044A1 (zh) 2018-09-29 2019-07-16 节点通讯方法，服务器，客户端
PCT/CN2019/096217 WO2020063048A1 (zh) 2018-09-29 2019-07-16 Pon网络及其通讯方法，olt，mqtt-sn网关，onu及mqtt服务器
PCT/CN2019/109252 WO2020063993A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统

Family Applications After (4)

Application Number Title Priority Date Filing Date
PCT/CN2019/109257 WO2020063996A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统
PCT/CN2019/109247 WO2020063992A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统
PCT/CN2019/109246 WO2020063991A1 (zh) 2018-09-29 2019-09-29 Pon网络，用于pon网络的方法及装置，以及机器人系统
PCT/CN2019/109263 WO2020063997A1 (zh) 2018-09-29 2019-09-30 节点间通信方法、通信节点以及通信系统

Country Status (1)

Country Link
WO (8) WO2020063044A1 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112383904B (zh) * 2020-10-22 2023-03-14 赞同科技股份有限公司 无配对快速外设调用方法及装置
WO2021237229A2 (en) * 2020-12-09 2021-11-25 Futurewei Technologies, Inc. Efficient protection switching in wdm-pon
CN114979097B (zh) * 2021-06-03 2023-07-21 中移互联网有限公司 基于mqtt的消息推送方法、装置及电子设备
CN114338082A (zh) * 2021-11-30 2022-04-12 福建超智集团有限公司 一种智能网关安全连接云平台方法和系统
CN114363422A (zh) * 2021-12-31 2022-04-15 深圳市普渡科技有限公司 室内机器人及其控制系统和方法
CN114938329A (zh) * 2022-01-25 2022-08-23 厦门锐谷通信设备有限公司 一种基于mqtt的路由器网关设备管理方法及系统
CN115086380B (zh) * 2022-07-25 2022-11-15 苏州思萃工业互联网技术研究所有限公司 基于能源管理平台的数据传输系统及方法
CN115297144B (zh) * 2022-07-29 2024-03-08 中汽创智科技有限公司 节点数据交互方法和装置
CN116208379B (zh) * 2022-12-30 2023-08-22 金茂云科技服务(北京)有限公司 物联网设备mqtt主题发布订阅权限校验方法及系统
CN117880143B (zh) * 2024-01-11 2024-07-30 江苏征途技术股份有限公司 一种网关机设备的串口模块读写功能检测装置和检测方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101355387A (zh) * 2007-07-26 2009-01-28 华为技术有限公司 光网络单元接入网络的方法、设备及系统
CN102075247A (zh) * 2009-11-25 2011-05-25 中国科学院光电研究院 高速光纤总线及其冗余拓扑结构的实现方法
US20120087662A1 (en) * 2010-10-06 2012-04-12 Hitachi, Ltd Passive optical network and subscriber line terminal
CN103347221A (zh) * 2013-07-04 2013-10-09 北京邮电大学 一种基于阀值比较的epon动态节能方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101123649A (zh) * 2006-08-08 2008-02-13 中国移动通信集团公司 信息服务系统及服务信息提供和获取的方法
US9071536B2 (en) * 2010-05-07 2015-06-30 Rong-Nan Chiou Bus-based optical network system
US20110274428A1 (en) * 2010-05-07 2011-11-10 Rong-Nan Chiou Bus-based optical network system
CN101841747B (zh) * 2010-05-12 2013-04-10 烽火通信科技股份有限公司 插板式fttb型onu及实现语音业务的方法
CN103916442A (zh) * 2013-01-07 2014-07-09 阿里巴巴集团控股有限公司 消息推送实现方法、移动终端及消息推送系统
CN203300035U (zh) * 2013-04-25 2013-11-20 国家电网公司 一种采集器及用电信息采集系统
EP3092736B1 (en) * 2014-01-23 2018-11-07 Huawei Technologies Co., Ltd. Optical line terminal communication method and device with data structure
CN104837077B (zh) * 2014-02-12 2019-05-07 中兴通讯股份有限公司 光线路终端/光网络单元波长调节方法及装置
WO2015199267A1 (ko) * 2014-06-27 2015-12-30 주식회사 쏠리드시스템스 이더넷 기반의 통신 시스템
EP3195566B1 (en) * 2014-07-21 2019-09-04 Convida Wireless, LLC Service layer interworking using mqtt protocol
KR101980475B1 (ko) * 2015-04-23 2019-05-20 콘비다 와이어리스, 엘엘씨 M2m 서비스를 추가하기 위한 디바이스 및 방법
DE102016122384A1 (de) * 2016-11-21 2018-05-24 Beckhoff Automation Gmbh Konzept zum steuern einer nachrichtenübermittlung zwischen kommunikationsteilnehmern eines automatisierungssystems
CN106657340A (zh) * 2016-12-26 2017-05-10 安徽超清科技股份有限公司 一种警情无线采集推送系统及方法
CN106713124A (zh) * 2017-01-24 2017-05-24 深圳市启仑智能科技有限公司 一种基于mqtt和mysql的消息推送方法和系统
CN108989372B (zh) * 2017-06-02 2021-04-09 华为技术有限公司 服务发现的方法、注册中心和设备
CN107708112A (zh) * 2017-11-02 2018-02-16 重庆邮电大学 一种适用于mqtt‑sn协议的加密方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101355387A (zh) * 2007-07-26 2009-01-28 华为技术有限公司 光网络单元接入网络的方法、设备及系统
CN102075247A (zh) * 2009-11-25 2011-05-25 中国科学院光电研究院 高速光纤总线及其冗余拓扑结构的实现方法
US20120087662A1 (en) * 2010-10-06 2012-04-12 Hitachi, Ltd Passive optical network and subscriber line terminal
CN103347221A (zh) * 2013-07-04 2013-10-09 北京邮电大学 一种基于阀值比较的epon动态节能方法

Also Published As

Publication number Publication date
WO2020063993A1 (zh) 2020-04-02
WO2020063991A1 (zh) 2020-04-02
WO2020063997A1 (zh) 2020-04-02
WO2020063044A1 (zh) 2020-04-02
WO2020063992A1 (zh) 2020-04-02
WO2020063048A1 (zh) 2020-04-02
WO2020063996A1 (zh) 2020-04-02

Similar Documents

Publication Publication Date Title
WO2020063995A1 (zh) Pon网络，用于pon网络的方法及装置，以及机器人系统
US8990444B2 (en) Fieldbus gateway using virtual serial fieldbus port and data transmission method thereof
DK2523397T3 (en) Method and device for operating the wind farm-interconnectors with improved data transfer protocol
WO2016070628A1 (zh) 一种电力线载波通讯终端控制装置、系统及方法
CN106789606B (zh) 一种网络通信系统、其管理方法及通信方法
CN111064627A (zh) 一种电力物联终端即插即用管理系统
CN101820355B (zh) 一种获取网络拓扑的方法和网元
WO2015131626A1 (zh) 用于网络设备的时间同步方法、装置及时间同步服务器
CN107168161A (zh) 基于ROS系统的EtherCAT主从站通信系统
CN112866018A (zh) 物联网管理系统及方法
CN114338274B (zh) 一种异构工业现场总线融合方法及系统
CN106506306B (zh) 一种数据报文传输的方法和装置
CN113890680A (zh) 一种应用于光纤通道航电网络dds的传输方法
CN103973677A (zh) 一种IPv6到PROFIBUS的协议转换装置
KR20100034395A (ko) 산업용 제어네트워크 적용을 위한 무선 센서네트워크 및 그구성방법
CN110213385A (zh) 一种工业设备Modbus串行通信的方法
Lin et al. Gigabit Modbus user datagram protocol fieldbus network integrated with industrial vision communication
Pan et al. Design and Performance Analysis of Protocol Conversion between 5G and Modbus TCP
CN112351355B (zh) 一种基于gRPC的ONU通道的管理方法和系统
JP7127481B2 (ja) 通信システム、通信装置、及び通信方法
WO2022222902A1 (zh) 一种通信方法及相关设备
KR20190017397A (ko) 플러그 앤 플레이 디바이스의 인터페이스 장치 및 그 동작 방법
Wang et al. Design and Implementation of EtherCAT Master of Gyrowheel under RTX System
CN117880004A (zh) 一种wifi模块通过mcu桥接有线以太网的方法与设备
Iskefiyeli et al. Interconnection of autonomous profibus segments through ieee 802.16 wman

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19865325

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19865325

Country of ref document: EP

Kind code of ref document: A1