Intelligent controller and sensor network bus, system and method including intelligent flexible actuator modules

Abstract

A machine automation system for controlling and operating an automated machine. The system comprises a controller and a sensor bus comprising a central processing core and a multimedia transport intranet for enabling dynamic bursting for a broadcast transmission scheme. Wherein messages are burst from the nodes to the central processing core and broadcast from the central processing core to all nodes.

Description

[0001] Cross-referencing

[0002] This application is a continuation in part of pending U.S. Patent Application No. 16 / 572,358, filed September 16, 2019, entitled “Intelligent Controller and Sensor Network Bus, System, and Method Including a Common Packaging Pattern,” which is a continuation in part of pending U.S. Patent Application No. 16 / 529,682, filed August 1, 2019, entitled “Intelligent Controller and Sensor Network Bus, System, and Method,” both of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of bus architecture. More specifically, this application relates to controller and sensor network bus architecture. Background Technology

[0004] The field of machine automation is rapidly expanding with the development of autonomous vehicles, intelligent robots, and factory automation. However, due to their diverse and high-speed requirements, no current bus or network architecture can effectively meet all the demands of these emerging technologies. Instead, current networks suffer from high latency, low bandwidth, complex cabling, high electromagnetic interference (EMI), high cost, data insecurity, and complex system integration. For example, networks lack sufficient speed and throughput to carry sensor data—such as camera and LiDAR data—over the network to the CPU core. Furthermore, existing cabling systems are complex, short-range, and cannot address EMI without expensive shielding due to the use of copper cabling systems. Currently, there is no versatile, all-in-one "controller and sensor network" system bus solution capable of supporting and carrying Internet L2 / L3 Ethernet packets, motor and motion control information, sensor data, and CPU commands (CPU-CMD) from edge node to edge node throughout the system. Summary of the Invention

[0005] This application provides a machine automation system for controlling and operating automated machines. The system includes a controller and sensor bus, which includes a central processing core and a multimedia transmission intranet for implementing dynamic bursts for a broadcast transmission scheme, wherein messages burst from nodes to the central processing core and are broadcast from the central processing core to all nodes.

[0006] The first aspect of this application relates to a machine automation system for controlling and operating automated machines. The system includes a controller and sensor bus, one or more controllers, and one or more flexible actuator modules. The controller and sensor bus includes multiple ports, wherein the bus includes a central processing core and a multimedia transmission intranet, the multimedia transmission intranet including one or more central fiber optic transmission networks directly connected to the core and one or more subnets; the central fiber optic transmission network includes multiple nodes and one or more gates; each of the multiple subnets is respectively connected to a different gate of one of the central transmission networks; each subnet includes multiple sub-nodes, wherein each node and sub-node is associated with one or more of the ports. Each controller is connected to a first port of the bus. Each flexible actuator module includes a first fiber optic connector, one or more motors, one or more sensors, and a system-on-a-chip (SoC); each module is operatively connected to a second port of the port via a fiber optic cable from the first fiber optic connector to the second port of the port. The nodes and child nodes of the bus relay messages via the bus through one or more central fiber optic transmission networks. The messages include sensor data from the sensors of the flexible actuator module and control data from the controller between the controller and the flexible actuator module.

[0007] In some embodiments, each of the flexible actuator modules is directly connected in parallel to one of the second ports of the port via the fiber optic cable. In some embodiments, multiple flexible actuator modules are connected in parallel to a beam splitter, which is connected to one of the second ports of the port via the fiber optic cable. In some embodiments, each flexible actuator module includes a second fiber optic connector and a beam splitter, wherein the beam splitter is connected to the first fiber optic connector, the second fiber optic connector, and the SoC. In some embodiments, the flexible actuator modules are connected in series such that the first fiber optic connector in the first flexible actuator module is connected to one of the second ports of the port via the fiber optic cable, and the second fiber optic connector in the first flexible actuator module is connected to the first fiber optic connector in the second flexible actuator module. In some embodiments, each flexible actuator module includes a bidirectional optical sub-assembly (BOSA), a transimpedance amplifier, a laser driver, and a motor driver. In some embodiments, the sensors of one or more flexible actuator modules include an image sensor and a magnetic sensor, wherein the motor controls the sharpness of the image sensor, and the magnetic sensor determines the orientation of the image sensor. In some embodiments, the first fiber optic connector is a pigtail fiber connection point. In some embodiments, the second port of the port is an optical port connected to a pigtail fiber optic connector. In some embodiments, the automated machine is one of a group consisting of robots and autonomous vehicles.

[0008] A second aspect of this application relates to a flexible actuator module utilizing a controller and a sensor bus. The flexible actuator module includes one or more flexible actuator motors; one or more magnetic sensors; and a control board including a first fiber optic connector, a second fiber optic connector, a system-on-a-chip (SoC), and a beam splitter, wherein the beam splitter is coupled to the first fiber optic connector, the second fiber optic connector, and the SoC. The control board: receives sensor data from the magnetic sensors and outputs a status message based on the sensor data via the first fiber optic connector; controls the motor based on a control message input via the first fiber optic connector having a target wavelength; forwards the status message received via the second fiber optic connector from the first fiber optic connector using the beam splitter; and forwards the control message input via the first fiber optic connector having a non-target wavelength. In some embodiments, the module also includes an image sensor, wherein the control board receives image data from the image sensor and outputs sensor data messages based on the image data via the first fiber optic connector. In some embodiments, the motor controls the articulation of the image sensor, and the magnetic sensor determines the orientation of the image sensor. In some embodiments, the control board includes a bidirectional optical subassembly (BOSA), a transimpedance amplifier, a laser driver, and a motor driver. In some embodiments, the first fiber optic connector is a pigtail fiber connection point.

[0009] A third aspect of this application relates to a method of operating a controller and sensor bus, the controller and sensor bus including multiple ports for connection to multiple external machine automation devices of a machine automation system, the bus having a central processing core and a multimedia transmission intranet, the multimedia transmission intranet including one or more central fiber optic transmission networks and multiple subnets, the one or more central fiber optic transmission networks being directly connected to the core and including multiple nodes and one or more gates, each of the multiple subnets being connected to different gates of the central fiber optic transmission network, and each subnet including multiple child nodes. The method includes: connecting one or more controllers to a first port of the bus port; connecting one or more flexible actuator modules to the second port of the bus via an optical fiber cable from a first optical fiber connector to a second port of the port, each flexible actuator module including the first optical fiber connector, one or more motors, one or more sensors, and a system-on-a-chip (SoC); and relaying messages between the controllers and the flexible actuator modules via the one or more central fiber optic transmission networks using the nodes and child nodes of the bus, the messages including sensor data from sensors of the flexible actuator modules and control data from the controllers.

[0010] In some embodiments, each flexible actuator module is directly connected in parallel to one of the second ports of the port via fiber optic cables. In some embodiments, connecting the flexible actuator modules includes connecting the flexible actuator modules in parallel to a beam splitter, and connecting the beam splitter to one of the second ports of the port via fiber optic cables. In some embodiments, each flexible actuator module includes a second fiber optic connector and a beam splitter, wherein the beam splitter is connected to a first fiber optic connector, a second fiber optic connector, and a SoC. In some embodiments, connecting the flexible actuator modules includes connecting the flexible actuator modules by connecting a first fiber optic connector in a first flexible actuator module to one of the second ports of the port via the fiber optic cable, and connecting a second fiber optic connector in a first flexible actuator module to a first fiber optic connector in a second flexible actuator module. In some embodiments, each flexible actuator module includes a bidirectional optical sub-assembly (BOSA), a transimpedance amplifier, a laser driver, and a motor driver. In some embodiments, the sensors of one or more flexible actuator modules include an image sensor and a magnetic sensor, and the method further includes controlling the sharpness of the image sensor using a motor and determining the orientation of the image sensor using a magnetic sensor. In some embodiments, the first fiber optic connector is a pigtail fiber optic connection point. In some embodiments, the second port of this port is an optical port connected to a pigtail fiber optic connector. In some embodiments, the automated machine is one of a group consisting of robots and autonomous vehicles. Attached Figure Description

[0011] Figure 1 A machine automation system according to a partial embodiment is shown.

[0012] Figure 2 A smart controller and sensor intranet bus according to a partial embodiment are shown.

[0013] Figure 3 A tree topology of the intelligent controller and sensor intranet bus according to a partial embodiment is shown.

[0014] Figure 4 A block diagram of an exemplary computing device for implementing a system, according to a partial embodiment, is shown.

[0015] Figure 5 A method of operating a machine automation system including an intelligent controller and a sensor intranet bus, according to a partial embodiment, is illustrated.

[0016] Figure 6A An exemplary GEM data packet format according to a partial embodiment is shown.

[0017] Figure 6B A detailed view of the GEM packet header format according to a partial embodiment is shown.

[0018] Figure 6C A detailed view of the GEM header format for node reporting messages, according to a partial embodiment, is shown.

[0019] Figure 6D A detailed view of a first variant of the GEM header format for root port bandwidth authorization messages, according to a partial embodiment, is shown.

[0020] Figure 6E A detailed view of a second variant of the GEM header format for root port bandwidth authorization messages, according to a partial embodiment, is shown.

[0021] Figure 6F A detailed view of the GEM header format for control messages, according to a partial embodiment, is shown.

[0022] Figure 7A A broadcast-PHY-Frame is shown according to a partial embodiment.

[0023] Figure 7B A burst-PHY-Frame is shown according to a partial embodiment.

[0024] Figure 7C A burst-PHY-Frame according to a partial embodiment is shown.

[0025] Figure 8 The operation method of the intelligent controller and sensor intranet bus according to a partial embodiment is shown.

[0026] Figure 9 A smart flexible actuator (SCA) and sensor module according to a partial embodiment are shown.

[0027] Figure 10A A first variant of the control board for the SCA and sensor module according to a partial embodiment is shown.

[0028] Figure 10B A second variant of the control board for the SCA and sensor module according to a partial embodiment is shown.

[0029] Figure 10C A third variant of the control board for the SCA and sensor module according to a partial embodiment is shown.

[0030] Figure 11A and 11B A machine automation system including a coupled SCA and sensor module is shown according to a partial embodiment.

[0031] Figure 12The operation method of the controller and sensor bus according to a partial embodiment is shown. Detailed Implementation

[0032] The embodiments described herein relate to machine automation systems, methods, and apparatuses for controlling and operating automated machines. The systems, methods, and apparatuses include a controller and sensor bus comprising a central processing core and a multimedia transmission intranet for dynamic bursting of broadcast transmission schemes. Messages burst from nodes to the central processing core and are broadcast from the central processing core to all nodes. Therefore, the systems, methods, and apparatuses, despite incorporating low-speed network media, still offer the advantage of high-speed performance. The systems, methods, and apparatuses also provide a unified software image of the complete intranet system, including all gates, nodes, and root ports, thereby enabling a simplified software architecture, shorter product development cycles, and easier system-level debugging, remote monitoring, and troubleshooting. In particular, the systems, methods, and apparatuses provide a unique intranet system architecture specifically defined and optimized for machine automation applications.

[0033] Figure 1 A machine automation system 100 according to a partial embodiment is shown. For example... Figure 1 As shown, system 100 includes one or more external devices 102 operatively coupled to an intelligent controller and sensor intranet bus 104. In some embodiments, system 100 may be part of an automated device (such as an autonomous vehicle, automated industrial machine, or automated autonomous robot). Alternatively, system 100 may be part of other machine automation applications. Devices 102 may include one or more of sensor devices (e.g., ultrasonic, infrared, camera, LiDAR, sonar, magnetic, radar), internet devices, motors, actuators, lights, displays (e.g., screens, user interfaces), speakers, graphics processing units, central processing units, memory (e.g., solid-state drives, hard disk drives), and controllers / microcontrollers, or combinations thereof. Each device 102 may be accessible via one or more bus input / output (I / O) ports (see... Figure 2 ) can be operatively connected via wired and / or wireless connection to bus 104. Although as Figure 1 As shown, system 100 includes a discrete number of external devices 102 and bus 104, but more or fewer devices 102 and / or bus 104 may be envisioned.

[0034] Figure 2 A smart controller and sensor intranet bus 104 according to a partial embodiment are shown. For example... Figure 2As shown, bus 104 includes an intranet formed by a central core 200, which is connected to one or more gates 202 and multiple edge nodes 204 (each edge node 204 having one or more external I / O ports 99) via one or more central transmission networks 206, and to one or more edge child nodes 208 (each edge child node 208 having one or more external I / O ports 99) via one or more subnets 210 extending from the gates 202. Therefore, as... Figure 3 As shown, bus 104 forms a network tree topology, where central network 206 branches from central core 200 (e.g., root port 230 of the core) to edge nodes 204 and gates 202, and subnet 210 branches from gates 202 to child nodes 208 and / or child gates 202'. In this way, central core 200 can view all nodes 204 and child nodes 208 (because gates 202 and child gates 202' are transparent to central core 200). In some embodiments, in the absence of nodes, one or more gates 202 are directly connected to I / O port 99 (e.g., to connect to an external CPU, GPU, AI core, and / or solid-state drive (SSD).

[0035] Port 99 can be any type of interface port, such as PCIe (Peripheral Component Interconnect), Mobile Industrial Processor Interface (MIPI), Ethernet, Universal Serial Bus (USB), General Purpose Input / Output (GPIO), Universal Asynchronous Receiver / Transmitter (UART), Internal Integrated Circuit (I2C), and / or other types of ports. Although... Figure 2 As shown, bus 104 includes discrete quantities of ports 99, cores 200, nodes 204, 208, gates 202, networks 206, 210, other elements and components, but more or fewer ports 99, cores 200, nodes 204, 208, gates 202, networks 206, 210, other elements and / or components are conceivable.

[0036] The central transmission network 206 may include a connection medium that is faster / has lower latency than the connection medium of subnet 210 connected to gate 202 of the central transmission network 206. Similarly, subnet 210 may include a connection medium that is faster / has lower latency than the connection medium of subnet 210' connected to gate 202' of subnet 210; and so on for each iterated subnet. This network / subnet connection medium speed / latency relationship prevents the overall processing of bus 104 from slowing down, even though bus 104 still includes slower connection media, as described in detail below. Optionally, one or more of subnets 210, 210' and / or the central network 206 may have the same or other connection medium speed / latency relationships.

[0037] In some embodiments, the connection medium of the central transmission network 206 includes fiber optic cable 212, which is split using a beam splitter 214 (e.g., a 2-to-1 beam splitter) and has an optical transceiver 216 to connect to and receive data from nodes 204, 208. In some embodiments, the connection medium of the subnet 210 includes fiber optic connection media (e.g., similar to the connection media of the central transmission network 206, but possibly of a lower grade), wireless connections (e.g., radio frequency transceivers 218), copper cabling connections (e.g., twisted-pair copper wire 220, which is preferably split using an analog beam splitter 222 (e.g., a fan-out output / multiplexer) and has serializer / deserializer (SERDES) 224 to connect to and receive data from nodes 204, 208), and / or combinations thereof (e.g., a hybrid fiber optic, copper, and / or wireless connection medium). Therefore, bus 104 supports multi-rate traffic transmission, wherein different nodes / networks can be used to connect to bus 104 based on the latency / speed, connectivity, and / or distance requirements of data / traffic / external device 102, while still providing the required throughput. For example, for high-speed, low-latency, and long-distance requirements, an optical connection medium of the central network can be used by connecting to node 204. Furthermore, other networks 210 can be used based on cost, speed, connectivity, and / or distance requirements. In some embodiments, the central network 206 is a passive optical network, and / or the copper subnet 210 is an active network. In some embodiments, such as... Figure 2 As shown, one or more nodes 204 are connected to a controller area network (CAN) 226, allowing each node to input data from each controller connected to the CAN. Optionally, as... Figure 3 As shown, one or more subnets 210 can be CANs connected to the central core 200 via a gate 20.

[0038] Multi-level bus addressing

[0039] Bus 104 can utilize a multi-level addressing scheme, where root port 230, I / O port 99, nodes 204, 208, 234, and / or gate 202 can use node, epoch, and GEM identifier addresses to guide messages through bus 104. Specifically, each of root port 230, nodes 204, 208, 234, and gate 202 can be assigned a node ID identifier (node-ID), and nodes 204, 208, and gate 202 are also assigned at least one epoch identifier (epoch-ID) and at least one GEM identifier (GEM-ID). The epoch ID can be used to identify the source / destination of messages in networks 206, 210 (e.g., node / gate devices and their I / O ports, embedded CPUs, and / or other types of services), while the GEM-ID can be used to identify the destination of messages (e.g., a set or subset of node / gate devices and their I / O ports, embedded CPUs, and / or other types of services). Therefore, the epoch ID can be used for message transmission / routing throughout network 206, 210, while the GEM-ID can be used by the device itself (via port 99) to determine whether to capture a received / broadcast message that is its target.

[0040] According to the Service Level Agreement (SLA) profile of a node / gate (which can correspond to a device connected to port 99 of the node / gate), multiple epoch IDs and multiple GEM-IDs can be assigned to a node / gate. Therefore, the node ID of each of nodes 204, 208, and gate 202 can be mapped to one or more epoch IDs, which in turn can be mapped to one or more GEM-IDs. For example, nodes 204 and 208 connected to two I / O ports 99 can have a single node ID, two epoch IDs (one for each port 99), and ten GEM-IDs (one associated with the first epoch ID and the first port 99, and nine associated with the second epoch ID and the second port 99). Furthermore, although the node ID and epoch ID are unique for each node / gate / port, GEM-IDs can be shared between nodes / gates / ports. For example, port 99 of the same node 204 or 208, or different ports 99 of different nodes 204 or 208, can be associated with a matching or overlapping set of GEM-IDs.

[0041] One or more virtual node IDs can also be assigned to gate 202 for port 99, which is directly connected to gate 202. Like regular nodes, these virtual nodes represented by gate 202 can be assigned multiple epoch IDs and multiple GEM-IDs according to the SLA profile of gate 202 (which can correspond to the device connected to port 99 of the virtual node / gate).

[0042] Each other node 234 and core 232 (which is directly connected to core 200, such as I / O devices and embedded CPU cores) can have one or more GEM-IDs and a global node ID, but does not need to be assigned an epoch ID. This is unnecessary because messages traveling to and from these nodes 234 and core 200 are entirely within core 200. Like nodes 204 and 208, the number of GEM-IDs assigned to each node 234 and core 232 can be determined based on the SLA profile of node 234 or core 232 (which can correspond to a device connected to port 99 of node 234). Each of the kernel switch 220, root port 230, nodes 204, 208, 234, and / or gate 202 can maintain and update a local SLA table that indicates the mapping between each node ID, epoch ID, and GEM-ID. Therefore, bus addressing offers the advantage of using epoch IDs and / or node IDs to facilitate simplified burst / broadcast message passing between nodes, gates, and the kernel within network 100, while using GEM-IDs to facilitate any more complex message passing required between devices / IO ports 99 and / or the kernel itself.

[0043] General packaging method

[0044] Bus 104 can encapsulate all input data and internally generated data (e.g., control messages, operation messages, and management messages) into a Generic Encapsulation (GEM) for transmission over the bus 104 intranet. Therefore, the GEM acts as a unique, standardized data and message container for transmitting data between nodes and / or to the central core 200 via the bus 104 intranet. Thus, input data can be encapsulated into GEM format at each node upon entering bus 104, and then transmitted via the central core 200 (where it is decapsulated for processing and recapsulated for transmission) to its destination node, which decapsulates the data into its original format and sends it to the target external device 102 or other destinations. This input data can originate from various sources (e.g., device 102, CAN 226) input through port 99 at nodes 204, 208, 234, or gate 202 and / or the embedded CPU core 232.

[0045] There are two types of GEM formats: GEM packets and GEM controls. A GEM packet format consists of a GEM header plus a GEM payload (e.g., 8 bytes to 4 kilobytes in length). Typically, the GEM packet format is used to encapsulate input port data, packets, and messages at the entry point (e.g., a node or port). Below are some examples of IO port data, packets, and messages that can utilize the GEM packet format:

[0046] - Using the GEM packet format, Ethernet packets are carried in GEM encapsulation from local gate 202 and / or nodes 204, 208 via bus 104 to remote gate 202 and / or node 204 (e.g., capable of being used for Internet and Wi-Fi interfaces via Ethernet ports or PCIe ports).

[0047] - Using the GEM packet format, sensor data (e.g., CAN bus data, camera (MIPI) frame data, lidar (Ethernet) data, electromagnetic encoder (ADC) data, and other types of sensor data) are carried from local door 202 and / or node 204 via bus 104 after being GEM-encapsulated.

[0048] - Using the GEM packet format, massive data and packets are carried from local nodes 204 and 208 through a fragmentation and defragmentation scheme to remote nodes 204 and 208. This includes fragmentation, defragmentation, and reordering / retransmission capabilities.

[0049] - Using the GEM packet format, network control, operation, and management messages are carried between kernel 200 and nodes 204, 208 (and / or gates), including physical layer operation, management, and maintenance (PLOAM), node management control interface (NMCI), and operation, management, and maintenance (OAM) messages.

[0050] - Using the GEM packet format, CPU / PCIe access to CMD / DATA is carried from kernel 200 and local gate 202 and / or node 204 through bus 104 after being GEM encapsulated, to remote local gate 202 and / or node 204 (e.g., CPU 232 accesses the target device 102 from node to node via PCIe, USB, I2C, UART and GPIO interfaces).

[0051] Finally, using the GEM packet format, VPN tunneling is performed between local nodes 204, 208 and remote nodes 204, 208 via bus 104.

[0052] The GEM control message format includes messages and extended messages (e.g., 8 bytes + 8 bytes...). On bus 104, the GEM control message format can be used for internal network management and control purposes, including Dynamic Bandwidth Allocation (DBA) reports, DBA authorization, GEM Receive (RX) acknowledgments, GEM flow control, GEM power management, GEM snooping, GEM remote messages, and / or other types of control messages. As described above, node 204 is responsible for encapsulating data into and decapsulating data in the GEM packet format and GEM control message format. This scheme can extend the PCIe interface protocol from a point-to-point topology to a point-to-multipoint topology and extend the interface distance from short distances to long distances.

[0053] Figure 6A -F illustrates an exemplary GEM packet format and GEM header format according to a partial embodiment. For example... Figure 6A As shown, a GEM data packet 600 can include a header 602 and a corresponding payload 604. As mentioned above, for message data packets, the header can be a fixed size (e.g., 8 bytes), and the payload can vary in length (e.g., from 8 bytes to 4 kilobytes); for control data packets, the header can be, for example, 8 bytes, with or without one or more 8-byte extensions.

[0054] Figure 6B A detailed view of the GEM packet header format according to a partial embodiment is shown. Figure 6B As shown, header 602 includes a GEM type field 606, a payload length indication field 608, an encryption key index field 610 (e.g., an AES key index), a node / epoch ID field 612, a GEM-ID field 614, a GEM packet type field 616, a transmission sequence identifier field 618, an acknowledgment field 620, a last fragment indication field 622, and a header error correction / verification (HEC) field 622. Optionally, one or more fields can be omitted and / or one or more additional fields can be added. In some embodiments, the GEM type field 606 is two bits, the payload length indication field 608 is twelve bits, the encryption key index field 610 is two bits, the node / epoch ID field 612 is twelve bits, the GEM-ID field 614 is twelve bits, the GEM packet type field 616 is three bits, the transmission sequence identifier field 618 is six bits, the acknowledgment field 620 is one bit, the last fragment indication field 622 is one bit, and the header error correction / verification (HEC) field 622 is thirteen bits. Optionally, one or more of the above fields may be larger or smaller.

[0055] The GEM Type field 606 indicates the type of header 602 of the GEM packet 600 (and therefore, the type of packet it is). For example, the GEM Type field can indicate that header 602 is one or more of a packet header, a bandwidth grant message header (e.g., transmitted from root port 230 to a gate / node), a bandwidth report message header (e.g., transmitted from a gate / node to root port 230), and / or a control message (e.g., between root port 230, gate 202, and / or nodes 204, 208, 234). The Payload Length Indication field 608 indicates the length of the payload 604 of the packet 600. The Encryption Key Index field 610 indicates the type of encryption used on the packet 600. For example, the Encryption Key Index field 610 can be used as an index value in an encryption table to identify one or more of the following: whether the packet is encrypted, which key is used to encrypt the packet, and / or which encryption method is used.

[0056] The Node / Era ID field 612 can identify the source or destination node of the data packet 600. For example, for a GEM data packet 600 bursting from a node to the kernel, field 612 can be or represent the epoch ID of the node to indicate the source of the data packet 600. As another example, for a GEM data packet 600 broadcast from root port 230 to nodes / gates within its network 206, 210, field 612 can be or represent the destination node ID (including unicast node ID, multicast node ID, and / or broadcast node ID). The GEM-ID field 614 can be or represent the data / data packet / message identifier of the source node for a point-to-point message, or can be or represent the GEM-ID of the destination node for a point-to-multipoint message (e.g., including CAN message GEM-ID, sensor data GEM-ID, and / or Ethernet data packet GEM-ID). Therefore, the GEM format provides the following advantages: it enables the bus 104 to identify the direct source and / or destination nodes through the node / epoch ID field 612, and also enables the target device / port / service to be identified using the GEM-ID field 614.

[0057] The GEM packet type field 616 indicates the type and format of the header of a message encapsulated in GEM format (e.g., received from device 102 and / or via port 99). For example, field 616 can indicate that the message header is a PLOAM message, a Node Management and Control Interface (NMCI) message, a CAN command message, sensor data, an Ethernet packet, a CPU-IO (e.g., PCIe / USB) message, and / or a Node Operation and Control Report (NOCR) message. The Acknowledgment Required field 620 indicates whether an acknowledgment message is required in response to the message. The Transmission Sequence Identifier field 618 identifies the transmission sequence number of packet 600 (for packets bursting from the node to the core 200) within a set of packets from the source node and / or its epoch ID. In some embodiments, an acknowledgment message from the receive root port 230 is required when indicated by the Acknowledgment Required field 620. For packets broadcast from root port 230 to nodes / gates, the Transmission Sequence Identifier field 618 identifies the transmission sequence number of the unicast / broadcast / multicast GEM-ID (e.g., CAN message GEM-ID, sensor data GEM-ID, Ethernet packet GEM-ID, and CPU / PCIe / USB data-message GEM-ID). In some embodiments, acknowledgment from the receiving root port 230 and / or node is required when indicated by the Acknowledgment Required field 620. The Last Fragment Indication field 622 indicates whether packet 600 is the last fragment in a series of fragments of a large packet. The Header Error Correction / Check (HEC) field 622 can be used to check for errors in header 602.

[0058] Figure 6C A detailed view of the GEM header format of a node report message according to a partial embodiment is shown. Figure 6CAs shown, header 602 includes a GEM type field 606, a report message type field 624, a source epoch ID field 626, a total report size field 628, a report threshold size field 630, a report sequence number field 632, one or more source node virtual output queue (VOQ) status fields 634 (e.g., CPU-IO, PLOAM, NMCI, CAN, sensor, Ethernet, or other types), a report priority field 636, and a header error correction / verification (HEC) field 622. Optionally, one or more fields can be omitted and / or one or more additional fields can be added. In some embodiments, the GEM type field 606 is two bits, the report message type field 624 is two bits, the source epoch ID field 626 is twelve bits, the total report size field 628 is fourteen bits, the report threshold size field 630 is eight bits, the report sequence number field 632 is five bits, one or more source node virtual output queue status fields 634 are each one bit (or a single six-bit field), the report priority field 636 is two bits, and the header error correction / verification (HEC) field 622 is thirteen bits. Optionally, one or more of the above fields can be larger or smaller.

[0059] The report message type field 624 indicates what type of report header 602 (and therefore what type of report message) the GEM packet 600 is. For example, the report message type field 624 can indicate that header 602 is an invalid report message, its own node report message (e.g., where the epoch ID of the packet's source is mapped to the node ID of the packet's source), a node report message of another node (e.g., where the epoch ID of the packet's source is not mapped to the node ID of the packet's source), and / or a power failure alarm report message (e.g., a message that requires / requests the highest priority). The source epoch ID field 626 can be or represent: (e.g., for reports of PLOAM and NMCI and CAN / sensor / Ethernet queue flags) the epoch ID of the source node, (e.g., for CAN reports) the epoch ID of the CAN, (e.g., for sensor reports) the epoch ID of one of the sensors / nodes, (e.g., for Ethernet packet reports) the Ethernet epoch ID, and / or (e.g., for PCIe / USB report messages) the PCIe / USB epoch ID. The report total size field 628 can indicate the total size of GEM data within the VOQ (for the epoch ID and / or node ID), while the report threshold size field 630 can indicate the boundaries of GEM packets within the VOQ (single or multiple) (e.g., used when determining the size of the burst window authorized for the epoch and / or node).

[0060] The report sequence number field 632 indicates which number in the sequence the message belongs to (e.g., whether a sequence of related report messages exists to determine if a message is lost or unordered). One or more source node Virtual Output Queuing (VOQ) status fields 634 each indicate the status of the source node relative to a specific function / type of data (e.g., CPU / IO, PLOAM, NMCI, CAN, sensors, Ethernet). The report priority field 636 indicates what priority to give the message (e.g., maximum effort, normal bandwidth request priority, CAN message request priority, power failure alarm request priority).

[0061] Figure 6D and Figure 6E Detailed views are shown of two variations of the GEM header format for root port bandwidth grant messages, according to partial embodiments. (See attached image.) Figure 6D As shown, for a node authorization message where the node ID and epoch ID are the same, header 602 can include a GEM type field 606, an epoch ID field 638, a start time field 640, an authorization size field 642, an authorization flag field 644, a report command field 646, an authorization command field 648, a forced wake-up indicator (FWI) field 650, a burst profile field 652, and a header error correction / verification (HEC) field 622. Optionally, one or more fields can be omitted and / or one or more additional fields can be added. In some embodiments, the GEM type field 606 is two bits, the epoch ID field 638 is twelve bits, the start time field 640 is fourteen bits, the authorization size field 642 is fourteen bits, the authorization flag field 644 is one bit, the report command field 646 is three bits, the authorization command field 648 is two bits, the forced wake-up indicator field 650 is one bit, the burst profile field 652 is two bits, and the header error correction / verification (HEC) field 622 is thirteen bits. Optionally, one or more of the above fields may be larger or smaller.

[0062] The epoch ID field 638 can be or represent the epoch ID or node ID of the node to which the message is addressed. The start time field 640 can indicate the start time of the authorization window authorized to the target node (e.g., the epoch of that node). The authorization size field 642 can indicate the size / duration of the authorization window. The authorization flag field 644 can indicate whether the window is authorized. The report command field 646 can indicate what report is requested from the node / epoch / port. For example, the report command field 646 can indicate one or more of the following: no node request to send (RTS) status report or force the node to report RTS messages to the port for black box and diagnostic testing; in combination with one or more of the following: PLOAM and NMCI reporting only CPU-IO messages, CAN messages and sensor data and forced reporting of PLOAM / NMCI; Ethernet packets and forced reporting of CPU-IO / CAN / sensor and PLOAM / NMCI; and / or forced full reporting of PLOAM / NMCI / CPU-IO / CAN / sensor / Ethernet and Node Operation and Control Report (NOCR). The authorization command field 648 indicates what type of messages / data are authorized to the burst window. For example, the authorization command field 648 can indicate one or more of the following: the window is not used for PLOAM and NMCI messages; the window is authorized only for PLOAM messages; the window is authorized only for NMCI messages; and / or authorized for PLOAM, NMCI, and NOCR messages. The FWI field 650 indicates whether to force a wake-up of a dormant node. The burst profile field 652 can indicate the burst configuration (e.g., the length, mode, and / or other characteristics of the SOB delimiter, EOB delimiter, and / or preamble).

[0063] like Figure 6E As shown, for GEM authorization messages where the node ID and epoch ID are different, except for the absence of the report command field 646 and the FWI field 650, header 602 can be compared with... Figure 6D The headers are basically the same. Furthermore, they are similar to... Figure 6D Unlike other fields, the authorization command field 648 can be six digits. Optionally, the authorization command field 648 can be larger or smaller. Also, it differs from other fields... Figure 6D The difference is that the authorization command field 648 can indicate different types of GEM bandwidth authorization. For example, field 648 can indicate bandwidth authorization for: CAN messages only, sensor data only, power failure alarm messages only, and / or all VOQ / CoS (Class of Service) settings based on node output scheduling for both CAN messages and sensor data. Additionally, field 648 can force node ID power saving if the node responds with an acknowledgment message.

[0064] Figure 6FA detailed view of the GEM header format for control messages, according to a partial embodiment, is shown. Figure 6F As shown, header 602 includes a GEM type field 606, a control message type field 654, one or more control message fields 656, and a header error correction / verification (HEC) field 622. Optionally, one or more fields can be omitted and / or one or more additional fields can be added. In some embodiments, the GEM type field 606 is two bits, the control message type field 654 is four bits, the one or more control message fields total forty-five bits, and the header error correction / verification (HEC) field 622 is thirteen bits. Optionally, one or more of the above fields can be larger or smaller.

[0065] The control message type field 654 can indicate what type of control message the message is (e.g., thus the control message field 656 and its offset are known for processing). In some embodiments, the control message type field 654 indicates one or more of the following: report acknowledgment messages; CAN acknowledgment messages; flow control messages; power saving messages; and IO event messages (e.g., power failure alarms); runtime status messages; and / or timestamp updates (e.g., from port to node). The control message field 656 can include various control message fields based on the control message type (as shown in the control message type field 654).

[0066] Therefore, the benefit of the GEM format is that it enables bus 104 to encapsulate various input data and messages from completely different types of networks (e.g., controller area networks, optical networks, sensor device broadcast networks, wireless networks, CPU access networks) into a unique format (GEM). This unique format then facilitates high-speed standardized processing and transmission of various data inputs for burst messages and broadcast messages, thereby enabling the efficient operation of the multi-network, multi-device bus architecture required for modern machine automation applications.

[0067] Burst / Broadcast Frame Format

[0068] In some embodiments, broadcast messages are formatted as broadcast physical layer frames (Broadcast-PHY-Frames) defined by a preamble, a start-of-frame delimiter, and a frame payload. The frame payload includes multiple GEM packet data and GEM control messages. The broadcast-PHY-Frame can be of a fixed size (e.g., between 25 μs and 125 μs). Alternatively, larger or smaller frame sizes can be used. For example, for a central network 206 and subnet 210 with fewer node devices 204 and 208, the frame size can be smaller (e.g., 25 μs or 50 μs). In some embodiments, the Broadcast-PHY-Frame is configured to carry GEM-Packet and GEM-Control messages from root port 230 to gate 202 and / or nodes 204, 208, 234 via networks 206, 210, which include fiber optic, copper, and wireless networks.

[0069] In some embodiments, the burst message is formatted as a Burst-PHY-Frame defined by a preamble, a header delimiter, a payload, and an end-of-frame delimiter, wherein the payload includes one or more GEM-Packet data and GEM-Control messages. The size of the Burst-PHY-Frame can vary depending on the total burst window size of the nodes / gates authorized by the root port HDBA and / or gate DBA. In some embodiments, the maximum size of the Burst-PHY-Frame (from gate 202 or nodes 204, 208, 234) cannot exceed the maximum Burst-PHY-Frame size (e.g., between 25 μs and 125 μs). In some embodiments, the Burst-PHY-Frame is configured to carry GEM-Packet and GEM-Control messages from gate 202 and / or nodes 204, 208, 234 to root port 230 and / or gate 202 via networks 206, 210, including fiber optic, copper, and wireless networks.

[0070] Figure 7A A Broadcast-PHY-Frame 700 according to a partial embodiment is shown. For example... Figure 7AAs shown, the Broadcast-PHY-Frame 700 includes a Physical Synchronization Block (PSBbc) 702 for broadcasting and a broadcast framing sublayer frame 704, which includes a GEM control message 706, one or more GEM data packets 600, and a framing sublayer (FS) trailer 708. As described above, each GEM data packet 600 includes a header 602 and a payload 604. In some embodiments, the broadcast FS frame is FEC protected. Figure 7B A Burst-PHY-Frame 710 according to a partial embodiment is shown. For example... Figure 7B As shown, the Burst-PHY-Frame 710 includes a Physical Synchronization Block Unicast Start (PSBuc_sd) 712 with burst delimiters, a Burst Framing Sublayer (FS) 714, and a Physical Synchronization Block Unicast End (PSBuc_ed) 716 with burst delimiters. PSBuc_sd 712 may include a preamble 718 and a Burst Start (SOB) delimiter 720, and PSBuc_ed 716 may include a Burst End (EOB) delimiter 722. The Burst FS 714 may include an FS header 724, one or more epochs 726, and an FS tail 708. Each epoch 726 may include one or more GEM data packets 600 with header 602 and payload 604 as described above. In some embodiments, the Burst FS frame is FEC protected. In particular, by including an EOB delimiter (in addition to the SOB delimiter and the frame size), structure 710 enables sniffers, analysis engines, or other components to monitor traffic within bus 104 even if the size of the unaccessed frame is unknown. It allows the components to determine the end of each burst frame based on the EOB delimiter.

[0071] Figure 7C A gate Burst-PHY-Frame728 according to a partial embodiment is shown. (As...) Figure 7C As shown, gate Burst-PHY-Frame 728 can include one or more Burst-PHY-Frames 710, which are combined together to form a single combined burst-PHY-frame with a single preamble 729 and one or more gaps 730. Specifically, as described in detail below, gate 202 can receive burst frames 728 from one or more child nodes 208 and one or more I / O ports 99 (which act as virtual nodes) and combine these frames 728 into a single burst-PHY-frame. Figure 7CThe combined gate Burst-PHY-Frame728 is shown. As a result, System 100 provides the following advantages: more efficient message communication by combining burst frames, and less overhead per frame by using a single preamble only for the combined frame as a whole, rather than using separate preambles for each combined burst frame (each of which can be up to 256 bytes or more).

[0072] Figure 8 The operation method of the intelligent controller and sensor intranet bus 103 according to a partial embodiment is shown. For example... Figure 8 As shown, in step 802, one or more nodes 204, 208 receive one or more messages from one or more devices 102 connected to one or more ports 99. In step 804, nodes 204, 208 encapsulate the messages into a Generic Encapsulation Mode (GEM) format for transmission to the central processing core 200. If the destination of the input message is node 234 within the core 200, then in step 806, the core decapsulates, processes, and transmits the message to its destination without recapsulation. Otherwise, if the destination of the input message is one or more other nodes 204, 208 (outside the core 200), then in step 808, the core 200 decapsulates, processes, and recapsulates the message back into GEM format for broadcast to its destination. In step 810, nodes 204, 208 decapsulate the messages received from the core 200 from GEM format back into the original format of the input data received from one of the devices 102. Optionally, if the input messages originate from node 234 within kernel 200, they can be input and processed by kernel 200 (without encapsulation), and if their destination is one or more nodes 204, 208 outside kernel 200, they are encapsulated by kernel 200 for broadcasting. Therefore, this method offers the advantages of enabling communication of many different types of data (e.g., sensor, controller bus, Ethernet, or other types of data), more efficient message communication through combining burst frames, and lower overhead per frame by using a single preamble only for the combined frame as a whole, rather than using a separate preamble for each combined burst frame.

[0073] kernel

[0074] Kernel 200 may include kernel switch 228, one or more root ports 230 (internal ports), central processing unit 232, and one or more kernel nodes 234 having I / O ports 99 (external ports). In some embodiments, kernel 200 may also include a secure memory (e.g., secure digital storage (SD) memory) node 236 for storing data in black box memory 238. Optionally, SD node 236 and / or memory 238 may be omitted. Kernel node 234 enables users to bypass networks 206 and 210 and directly connect user plug-in modules (e.g., CPU core, WIFI LTE / 5G, user application software) to kernel 200.

[0075] The kernel switch 228 includes forwarding engine elements, a queuing buffer manager, and a traffic manager. The forwarding engine elements may include multiple forwarding engines. For example, a forwarding engine element may include one engine for L2 / L3 / L4 Ethernet header parser, lookup and classification / access control list (ACL) functions—including L2 Media Access Control (MAC) address learning and forwarding functions, and L3 Internet Protocol (IP) addressing to GEM-ID routing / mapping. Additionally, one engine may be used for GEM header message parser, lookup, ACL, and forwarding, and / or another engine may be used to support DoS attack capabilities to protect bus 104 from external Internet DoS attacks. The GEM queuing buffer manager may be a centralized buffer architecture that uses a linked list-based buffer and queuing storage method that combines store-and-forward and pass-through forwarding schemes. For latency-sensitive GEM packets and GEM messages, a pass-through forwarding scheme can be used; while for congested GEM packets, a store-and-forward scheme can be used. The two schemes can be dynamically mixed and dynamically switched between each other based on runtime traffic congestion. The GEM Traffic Manager supports dual-token control, single-token rate limiting, and output shaping for both the GEM-ID and NODE-ID libraries, including associated Management Information Base (MIB) counters. It supports GEM-ID library-weighted random early detection (WRED) and tail drop functionality, as well as early traffic congestion detection, indication, and feedback mechanisms to notify the Hybrid Dynamic Bandwidth Allocation (HDBA), root port 230, gate 202, and nodes 204, 208, and 234 to slow down traffic transmission to avoid congestion.

[0076] Therefore, the kernel switch 228 can provide inbound functionality, receiving GEMs from one or more of the root port 230, local node 234, computer 232, and / or other I / O ports, processing and outbounding GEMs, and forwarding and transmitting received GEMs to one or more of the root port 230, local node 234, computer 232, and / or other I / O ports. In other words, the switch 228 can receive GEM packets from multiple sources; perform GEM and Ethernet L2 / L3 / L4 header parsing, L2 MAC lookup and learning, GEM messages, and 5-tuple ACLs and classifications; modify GEM headers and GEM payload Ethernet headers (if necessary); and store-and-forward (or pass-through buffer) GEM packets to one or more Hybrid Automatic Repeat Request (HARQ) function blocks and one or more broadcast MACs of the root port 230.

[0077] When performing this processing and / or forwarding function, switch 228 supports hybrid store-and-forward and cut-through forwarding schemes to reduce propagation latency for latency-sensitive GEMs and provide a sufficiently large buffer for bursty GEM traffic. Additionally, switch 228 supports real-time flow control mechanisms within bus 104, including hybrid dynamic bandwidth allocation and granting to ensure overall Quality of Service (QoS) on bus 104. Furthermore, switch 228 supports L2 / L3 / L4 ACLs and classification, L2 MAC addressing learning and forwarding, L3 IP addressing to GEM-ID routing / mapping, and DoS attack protection. Finally, switch 228 supports QoS scheduling, GEM buffered WRED / tail drop, node and / or GEM control, and output shaping functions.

[0078] root port

[0079] Root port 230 may include a root transmit MAC, a root receive MAC, a security engine (e.g., Advanced Encryption Standard (AES)), a forward error correction (FEC) engine, a hybrid dynamic bandwidth allocation (HDBA) engine, an activation processor (e.g., an activation state machine), and burst-mode SERDES IP. Optionally, one or more of the above components may be omitted. The transmit MAC of each root port 230 is responsible for: receiving outgoing GEMs prepared by switch 228 and / or HARQ; mapping and packaging the GEMs into broadcast frame formats (e.g., broadcast PHY-Frame structures); and broadcasting the GEMs to all gates 202 and / or nodes 204 in the central transmission network 206 to which root port 230 is connected (e.g., via root SERDES and optical / copper network broadcast domains). Conversely, the receive MAC of each root port 230 is responsible for: receiving GEMs in burst frame format (e.g., Burst-PHY-Frame structure) from burst mode SERDES and gates 202 and / or nodes 204, 208; extracting the GEM from the burst frame format; parsing the GEM header of the GEM; and receiving the GEM addressed to the GEM header (e.g., based on the GEM header and System Service Level Agreement (SLA) profile settings), and then outputting the GEM / data to switch 228 for further processing and forwarding. In other words, each root port 230 is capable of receiving burst traffic from node 204 and / or gate 202 (forwarded from node 208 in subnet 210 of gate 202), converting the burst traffic into the correct format for processing by switch 228, and then reformatting and broadcasting (through gate 202) the output traffic to all nodes 204 and 208 to reach the destination indicated by switch 228.

[0080] The Hybrid Dynamic Bandwidth Allocation (HDBA) engine is responsible for: receiving reports on bandwidth usage, traffic congestion, and other factors (e.g., NODE-DBA reports); performing HDBA analysis based on the SLA profile of the node / port / device associated with each report, the DBA report data itself, and the Conventional Information Rate (CIR) / Peak Information Rate (PIR) feedback; and authorizing burst windows for each node device and allocated port / EPOCH-ID. In other words, the HDBA engine receives input data from each node 204, 208 (of network 206 associated with root port 230 and its subnet 210) and / or other sources regarding bandwidth usage / traffic congestion, and dynamically allocates burst transmission window start time and / or size for each node 204, 208. When performing this allocation for node 208 within subnet 210, the gate 202 providing access to node 208 is transparent to the HDBA engine. Therefore, as described in detail below, gate 202 receives the required data and performs burst transmissions within the allocated window for each node 208 of gate 202 for subnet 210. The HDBA engine can also publish a report confirmation message (GEM-Report-ACK message) to nodes 204 and 208 to confirm that the report message (GEM-DBA report) has been received.

[0081] The root activation state machine is responsible for exchanging Physical Layer Operation, Management and Maintenance (PLOAM) GEM messages between nodes 204, 208, and 234 and root port 230, executing and completing the activation and registration of devices at nodes 204, 208, and 234 through activation processing and procedures. The security engine may be an AES-128 / 256 encryption and decryption function block for receiving and sending MACs. Alternatively, other encryption methods may be used. The Forward Error Correction (FEC) engine is used to control errors in data transmission over unreliable or noisy communication channels. In some embodiments, the FEC engine uses the Reed-Solomon FEC encoding schemes of RS(255,216) and RS(225,232) for 10G and 2.5G data rates, respectively. Alternatively, the FEC engine may use a user-defined low-density parity check (LDPC) scheme and / or other FEC algorithms. The burst mode SERDES uses a fast clock and data recovery (CDR) locking mode to ensure correct reception of appropriate burst messages (e.g., burst-PHY-Frame). In some embodiments, the CDR's fast locking function is required in fiber-cut, fast fail-over, and protection flip-chip recovery.

[0082] Finally, after the registration process, root port 230 receives broadcast Data Distribution Service (DDS) messages from nodes 204 and 208, which notify root port 230 that a new node / device has joined and registered to bus 104. Therefore, root port 230 is configured to always listen for and receive these DDS messages from switch 228 and the new nodes 204 and 208 that have declared their joining of bus 104, and to update the root port SLA profile database and settings to reflect the newly added node / device.

[0083] node

[0084] Within bus 104, edge nodes 204, 208, and 234 provide bridging functionality, connecting to external device 102 via I / O port 99 on one side and to the bus intranet 104 via the other side. To provide data from device 102 connected to port 99 of nodes 204 and 208, nodes 204, 208, and 234 construct and transmit burst messages (e.g., Broadcast-PHY-Frames encapsulated as GEM data) via bus 104 and through root port 230 (of their network 206 or its subnet 210) to other nodes 204 and 208. In addition, in order to provide data to device 102 connected to port 99 of nodes 204, 208, 234 receive broadcast messages (e.g., Broadcast-PHY-Frames encapsulated as GEM data) from other nodes 204, 208 through root port 230 (of their network 206 or its subnet 210), extract data from the broadcast messages (e.g., GEMs from RX BC-PHY-Frames), and filter and receive data belonging to (addressed to) nodes 204, 208.

[0085] To perform these and other functions, edge nodes 204, 208 may include one or more I / O ports 99, a package / depackage engine, a HARQ block, and a node MAC. Each port 99 may be a CPU interface (e.g., PCIe, USB, and UART), a sensor interface (e.g., MIPI, analog-to-digital converter (ADC), GPIO), an internet interface (e.g., Ethernet, EtherCAT, and CAN bus), and a motor module interface (e.g., pulse width modulation (PWM), I / O, etc.). 2One of C, ADC, and GPIO. The encapsulation / decapsulation engine receives input data from port 99 and encapsulates data packets, commands (CMDs), and messages received from Internet ports (e.g., Ethernet, Wi-Fi), sensor interfaces, motor module interfaces, and CPUs (e.g., PCIe and USB) into GEM format at the entry point. Nodes 204 and 208 can then output the encapsulated messages (e.g., GEM) to HARQ and / or Node Transmission MAC (described below). At the exit point, it receives GEM data packets from Node Transmission MAC (received from root port 230 and / or another node 204, 208, 234) and decapsulates the GEM back into its original data format (such as the data format received from connected device 102) for output to device 102 via port 99. Similar to root port 230, the HARQ of nodes 204 and 208 performs a hybrid automatic request retransmission function to ensure that GEM data packets are successfully sent to one or more of their destination nodes 204, 208, 234. Specifically, HARQ can have a built-in retransmission timer, a GEM list flag table, and a receive acknowledgment check function (e.g., GEM receive acknowledgment) to trigger GEM retransmission if a timer expires and no acknowledgment is received.

[0086] Node MAC includes Transmit MAC (TX MAC), Receive MAC (RX MAC), security engine (e.g., AES), Forward Error Correction (FEC) engine, DBA-reporting engine, and SERDES IP. TX MAC is responsible for mapping / packaging GEMs into burst structures (e.g., Burst-PHY-Frame structures) and sending burst messages to root port 230 and / or nodes 204, 208, and 234 during the burst window for nodes authorized by the dynamic burst allocation engine of root port 230. The RX MAC is responsible for receiving and terminating broadcast messages (e.g., Broadcast-PHY-Frame) from root port 230 and / or nodes 204, 208, 234, extracting GEMs from the broadcast message format, parsing and receiving GEMs addressed to root port 230 and / or nodes 204, 208, 234 (e.g., addressing port 99 of root port 230 and / or nodes 204, 208, 234) based on the node's SLA profile settings, and then outputting the data to the encapsulation / decapsulation engine.

[0087] The DBA reporting engine reports the total packets and messages in the queue (e.g., the EPOCH queue) to the associated HDBA engine at root port 230 via burst reporting (as described above). Additionally, the DBA reporting engine receives GEM-authorization messages from the HDBA at associated root port 230 and / or the DBA at associated gate 202, and prepares nodes to send MACs to construct burst messages (e.g., Burst-PHY-Frames) using the GEMs stored in the queue (e.g., the EPOCH queue).

[0088] The node activation processor is responsible for executing and completing the activation processes and procedures for nodes 204, 208, and 234 between nodes 204, 206, 234 and root port 230. The security engine can be an AES-128 / 256 encryption and decryption function block for both receiving and sending MACs. Alternatively, other encryption methods may be used. The FEC engine is used to control errors in data transmission over unreliable or noisy communication channels. In some embodiments, the FEC engine uses the Reed-Solomon FEC encoding schemes of RS(255,216) and RS(225,232) for 10G and 2.5G data rates, respectively. Burst mode SERDES uses a fast clock and data recovery (CDR) lockout mode to ensure fast fiber optic disconnection, fast failover, and protection flip-chip recovery.

[0089] Finally, after the activation process (e.g., after the registration process is complete), nodes 204, 206, and 234 can broadcast DDS messages to the entire bus 104 to notify and inform root port 230, switch 228, gate 202, and / or other nodes 204, 206, and 234 that new devices have joined and registered on bus 104 at nodes 204, 208, and 234. Furthermore, nodes 204, 206, and 234 can listen for DDS messages from switch 228 and other new nodes 204, 206, and 234 that have declared joining bus 104, and update their global SLA profile database and settings based on the DDS messages.

[0090] Door

[0091] Gate 202 may include a node MAC (with multiple virtual node state machines and buffers), an Adaptive Domain Bridge (ADB), a root port MAC (with built-in gate DBA functionality / gate DBA), a gate SLA profile database, and burst mode SERDES. The node MAC includes a transmit MAC, a receive MAC, a security engine (e.g., AES), an FEC engine, a DBA reporting function module, a SERDES function module for the virtual node processor, and / or multiple sets (e.g., one set for each node within subnet 210), virtual node profiles and settings, and one or more of the associated MIB counters and reporting logic. The transmit MAC receives a GEM from the gate ADB, then maps and packages it to its associated virtual node burst structure (e.g., a Burst-PHY-Frame structure) based on the gate's virtual node SLA profile database settings. Furthermore, the sending MAC aggregates multiple virtual node burst structures (e.g., Burst-PHY-Frame) into a single gate burst structure (e.g., GATE / Turbo Burst-PHY-Frame) and sends the burst message to root port 230 via network 206, based on the authorized burst window for those nodes 208 received from the HDBA at root port 230. The receiving MAC receives broadcast messages (e.g., Broadcast-PHY-Frame) from root port 230, extracts the GEM from the message, parses the GEM header, determines which messages are for nodes 208 within subnet 210 of gate 202 based on the GEM header and virtual node SLA profile database settings, and outputs these messages to the ADB.

[0092] ADB performs bridging between the node MAC and root MAC of gate 202. Specifically, in the broadcast direction (from root port 230 to node 208), ADB receives GEMs from the node receive MAC and performs a GEM header lookup, performing checks and filtering based on the gate virtual node profile database, thereby receiving GEMs from node 208 belonging to subnet 210 of gate 202. ADB can then output these GEMs to the root port send MAC of gate 202. In the burst direction (from node 208 to root port 230), ADB receives GEMs from the root receive MAC, stores the GEMs in its associated virtual node buffer, and outputs the GEMs to the virtual node send MAC when its burst window begins.

[0093] The root port MAC of gate 202 includes a transmit MAC, a receive MAC, a security engine (e.g., AES), an FEC engine, a gate DBA, and a burst mode SERDES module. The transmit MAC is responsible for receiving GEMs from the ADB, mapping and packaging the GEMs into a broadcast format (e.g., a Broadcast-PHY-Frame structure), and outputting the broadcast format frames to the burst mode SERDES. The receive MAC is responsible for receiving burst messages (e.g., Burst-PHY-Frames) from burst mode SERDES (e.g., remote nodes), extracting GEMs from the messages, parsing and receiving only the GEMs targeted by nodes 208 within subnet 210 of gate 202 (as indicated by the parsed GEM header and SLA profile settings), and then outputting the GEMs to the ADB of gate 202. The DBA of gate 202 is an extended HDBA of root port 230. The gate DBA authorizes and allocates node burst windows based on the gate DBA SLA profile settings (which are a subset of the root HDBA). The gate SLA profile database includes a list of node identifiers belonging to gate 202 (e.g., located within subnet 210 of gate 202), an SLA profile table of node identifiers for gate DBA functions, and GEM forwarding information. Burst-mode SERDES receive broadcast messages (e.g., Broadcast-PHY-Frame) from the root transmitting MAC and forward them to node 208 in subnet 210 in the broadcast transmission direction. In the receive direction, burst-mode SERDES receive burst messages (e.g., Burst-PHY-Frame) from node 208 through subnet 210 and output the burst messages to the root receiving MAC for message / frame termination and GEM extraction.

[0094] The primary function of gate 202 is to extend the central transmission network 206 of one of its root ports 230 by bridging to one or more subnets 210 (and nodes 208 therein) via adaptive bridging. Specifically, gate 202 can burst messages from nodes 208 and / or other gates 202' within their subnets 210 to the root port 230 of its network 206 as if the burst traffic originated from a node within the central transmission network 206. Similarly, gate 202 can broadcast messages received from other nodes 204, 208, 234, switch 228, and / or root port 230 to nodes 208 and / or other gates 202' within their subnets 210 as if nodes 208 and / or other gates 202' were within the central transmission network 206. Therefore, while maintaining the burst / broadcast communication method within the central transmission network 206, gate 202 can also extend the central transmission network 206 to additional nodes 208 and / or subnets 210 of different types.

[0095] More specifically, in the burst direction of transmission (e.g., from node / gate to root port / switch / kernel), the burst window grant mechanism from node 208 to gate 202 to root 230 can include the following steps. First, the DBA of gate 202 is a subset of the HDBA of root port 230 (the root port 230 of network 206, of which gate 202 is part), and is therefore transparent to root port 230 and node 208. Second, when gate 202 receives a burst window grant message (e.g., a GEM grant message) broadcast from its root port 230, gate 202 uses the message header (e.g., a GEM header) to look up the gate SLA profile database for GEM forwarding information. In other words, as indicated in the gate SLA profile database, gate 202 uses the header data to determine whether the grant message is for any node 208 within its subnet 210. If the authorization message is not for any node 208 in its subnet 210, gate 202 discards the authorization message; otherwise, the gate stores the message in its virtual node database, updates the database, and broadcasts the new window authorization message (e.g., a GEM authorization message) to all nodes / gates in its subnet 210 that point to the node 208 to which the original authorization message pointed. In response, node 208 provides a burst message to gate 202, and gate 202 formats the message and / or otherwise processes it to burst to root port 230 at the start of the burst window indicated in the received window authorization message for that node 208.

[0096] Third, to achieve optimal throughput bandwidth, high burst bandwidth efficiency, and / or low transmission latency, gate 202 can adjust the authorization window indicated in the new authorization message to be at least a predetermined amount of time earlier than the authorization window indicated in the original authorization message. Specifically, this amount of time provides gate 202 with time to receive and format burst data from node 208 before bursting data from gate 202 to root port 230 at the time indicated by the original window authorization message. In effect, by performing this operation simultaneously on multiple nodes 208, gate 202 can aggregate messages from multiple different nodes (e.g., multiple Burst-PHY-frames) into a single larger burst message (e.g., a GATE Burst-PHY-Frame).

[0097] Fourth, due to the protocol between the gate traffic DBA report and the root port 230 window authorization, root port 230 and gate 202 can maintain a group membership list table and are aware of the virtual nodes 208 below each gate 230 as a group. Therefore, when node 208 sends a report message (e.g., a GEM report) to the HDBA of root port 230, gate 203 can intercept the report message, modify it to include GEM data temporarily stored in the virtual node buffer memory (if present) of gate 202, and send a new report message to the HDBA of root port 230. In other words, gate 202 can combine report messages from nodes in its subnet 210 to make the reporting more efficient.

[0098] Furthermore, when the HDBA of root port 230 is publishing authorization messages (e.g., GEM authorization messages) to nodes 208 in subnet 210, since root port 230 is aware of all nodes 208 in subnet 210 (e.g., through a virtual node database), the HDBA of root port 230 can ensure that the authorization windows of nodes 208 belonging to the same gate 202 and / or subnet 210 are sequential / continuous. This allows gate 202 to combine and / or burst all burst messages (e.g., burst-PHY-Frame) of virtual nodes except for the burst message of the first virtual node, without requiring each burst message to have a preamble. This provides the benefit of reduced preamble overhead and increased burst bandwidth efficiency (especially for small bursts of GEM control messages).

[0099] In other words, for the data path, gate 202 receives burst messages (e.g., burst-PHY-frames) from burst-mode SERDES and remote nodes 208, extracts the GEM from the message in the root receive MAC of gate 202, stores the GEM in its associated virtual node buffer, and waits for virtual node burst window authorization to enter from the root port 230 of those virtual nodes 208. Then, gate 202 is able to map and package the stored GEMs for that node 208 and other nodes 208 back into the burst message format, thereby aggregating multiple burst messages into a larger burst message in the node send MAC of gate 202. Finally, gate 202 is able to send the larger burst message to SERDES and, based on the authorized burst window (e.g., multiple consecutive virtual node burst windows of gate 202), send it to the root port 230 via network 206.

[0100] Now considering the broadcast direction (e.g., from root port / switch / kernel to node / gate), gate 202 can also extend the central network 206 to subnet 210, while remaining transparent to both root port 230 of its network 206 and node 208 in its subnet 210. To achieve this, gate 202 can act as a virtual node, receiving broadcast messages (e.g., Broadcast-PHY-Frame) from root port 230, extracting GEMs from the messages, and discarding any GEMs not directed to either node 208 or gate 202' in its subnet 210 (e.g., as indicated by the message header and gate SLA profile database). Conversely, gate 202 can use store-and-forward and / or pass-through schemes to package and map GEMs back into the root port broadcast message structure (e.g., Broadcast-PHY-Frame structure) in the root send MAC of gate 202, and broadcast the new broadcast message to all nodes 208 and / or gate 202' in its subnet 210.

[0101] Data transfer operation

[0102] In operation, bus 104 operates using a burst / broadcast communication scheme, where all data messages from nodes 204, 208, and 234 (and gate 202) are aggregated to kernel 200 using a burst transmission method. A transmission window, dynamically resizable (by kernel 200), is granted to nodes 204, 208, and 234, allowing nodes 204, 208, and 234 (or gate 202 representing nodes 204, 208, and 234) to transmit their data messages as "bursts" within the granted window. If the sending node is in subnet 210, gate 202 (as the root port of network 210) receives the burst message from node 208 through subnet 210 and then bursts the message to kernel 200 through central network 206 (as if node 208 were part of central network 206). During this burst communication, gate 202 can aggregate burst messages from multiple nodes 208 within subnet 210, thereby improving efficiency and reducing the impact of subnet 210 on potential latency relative to the central network 206. Furthermore, the above steps can be repeated for gate 202' within subnet 210, which provides a gateway to subnet 210', to support any number of "link / gated" networks. Additionally, during this process, gate 202 can be transparent to kernel 200 and nodes 208, eliminating the need to address messages to gate 202.

[0103] Kernel 200 (from one or more root ports 230 that connect kernel 200 to each central network 206) receives these messages, processes them (including modifying and / or determining the target destination of these messages), and broadcasts these messages (and any messages originating from kernel 200) to the target nodes 204, 208, 234 (or the gate 202 representing target node 208) regardless of which central transmission network 206 is on. Similar to the burst communication described above, if target node 208 is within subnet 210, the gate 202, bridged to that subnet 210, can receive / intercept messages from the kernel and rebroadcast them to all nodes 208 (and / or gate 202') on subnet 210. Any broadcast messages to target node 204 that are not on subnet 210 (or a subnet of subnet 210) can be discarded by gate 202 for efficiency. Similarly, this process is transparent and can be repeated by gate 202' within subnet 210, and so on for any number of linked networks, to broadcast messages over the network. Therefore, all nodes 204, 208, 234 (and gate 202) on each network 206 (and the subnet 210 connected to network 206) receive all messages broadcast on that network 206 from kernel 200, and only need to find out which messages are directed to nodes 204, 208, 234 (and gate 202), discarding other messages.

[0104] More specifically, when nodes 204, 208, and 234 receive data from one or more external devices 102 through one or more of their I / O ports 99, nodes 204, 208, and 234 store the data in a GEM-ID queue buffer and burst report messages (e.g., GEM-Reports) to the root port 230 of the central network 206 in which they reside (either directly or through one or more gates 202 if they are located in a subnet 210 of the central network 206), and wait for an authorized burst window to send the input data. As described above, gate 202 can collect report messages from multiple nodes 208 (and / or gates 202') in its subnet 210 and aggregate the report messages into a single larger report message, which gate 202 can more efficiently burst to the root port 230 during the burst windows of those ports 208.

[0105] Simultaneously, nodes 204, 208, and 234 can encapsulate the input data into GEM format (segmenting GEMs exceeding a predetermined size into smaller GEMs), encrypt the GEM using the security keys of nodes 204, 208, and 234, update the HARQ table, and map and pack the GEM into a burst format (e.g., Burst-PHY-Frame format) and perform encoding (e.g., FEC RS(255,216) encoding). Subsequently, after authorization and arrival at each node's burst window, the node bursts the GEM containing the input data to the associated root port 230.

[0106] The HDBA at root port 230 receives all reporting messages from nodes 204, 208 (and / or gate 202) and performs DBA analysis on each node 204, 208 based on the SLA profile database, latency sensitivity level, traffic congestion feedback, agreed information rate (CIR) / peak information rate (PIR) feedback, and / or other factors to determine the authorized window burst size and start time for each node 204, 208. Once an authorized burst window is determined for one or more nodes 204, 208, root port 230 broadcasts the window to each node, to all nodes 204, 208 in the associated central network 206 and / or any subnet 210 (through gate 202) with a broadcast authorization message (e.g., GEM authorization). As mentioned above, broadcast messages from root port 230 have the same size, while the burst window from nodes 204, 208 to root port 230 can change size as dynamically allocated by HDBA.

[0107] Once a broadcast grant message is received for node 208 in its subnet 210 (or a subnet of subnet 210), gate 202 broadcasts the new grant message to all nodes 208 in subnet 210. Specifically, these new grant messages can specify a burst window that occurs before the time indicated by the original / root port grant window. This is to ensure that gate 202 receives (e.g., "bursted") input data / GEM from port 208 before the original / root grant window, thus giving gate 202 time to aggregate data / GEM from multiple nodes 208 and / or port 99 into a single larger message so that it can be bursted to root port 230 when the original / root port grant window arrives. Therefore, gate 202 is able to compensate for the inefficiencies and / or slowness of subnet 210, ensuring that subnet 210 does not slow down the efficiency of the central transmission network 206.

[0108] Upon receiving a burst message including a GEM (including input data from external device 102), root port 230 can perform decoding (e.g., FEC RS(255,216) decoding) and error correction on the burst message to decode and correct any transmission errors. Root port 230 can then extract the GEM from the burst message (e.g., the transmission frame format), decrypt the extracted GEM (e.g., using AES-128 / 256 and the source node security key), bypass the GEM segmentation block, and pass the GEM to switch 228. For each GEM, switch 228 can then perform a GEM-header lookup, parse and classify the Ethernet L2 / L3 address and header, process the GEM forwarding flowchart and determine the GEM forwarding destination information, store the GEM in a (pass-through) buffer, and output the GEM to HARQ and the destination root port 230 (e.g., the root port 230 of network 206 or subnet 210 including target nodes 204, 208) based on the SLA database QoS output scheduler.

[0109] Root port 230 receives the GEM, performs GEM encryption (e.g., AES-128 / 256 encryption) using the security key of the target node (or broadcast GEM), packages and maps the GEM into a broadcast message structure (e.g., Broadcast-Frame structure), encodes the message (e.g., FEC RS(255,216) encoding), and finally broadcasts the broadcast message to all nodes 204, 208 in the network 206 and its subnet 210 of the root port. If node 208 is within subnet 210, it receives the broadcast message at gate 202 of that subnet and broadcasts the message to all nodes 208 within subnet 210. In some embodiments, gate 202 filters out any broadcast messages that are not directed to nodes 208 within its subnet 210 (or subnets of subnet 210) and only broadcasts broadcast messages directed to one of those nodes 208. Optionally, gate 202 can rebroadcast all broadcast messages to nodes 208 within subnet 210 of gate 202 if it is uncertain whether the message is related to one of those nodes 208.

[0110] All nodes 204 and 208 monitor received broadcast messages, process messages for nodes 204 and 208, and discard other messages. Specifically, for messages that are not discarded, nodes 204 and 208 decode and correct the messages (e.g., FEC RS(255,216) decoding), extract the GEM from the broadcast message format (e.g., BC-PHY-Frame), decrypt the extracted GEM (e.g., using AES-128 / 256 and the destination node's security key), decapsulate the data from the GEM format back to the original IO-port data format, and output the data to external device 102 through designated IO port 99. Therefore, bus 104 and system 100 provide the following benefits: the ability to combine multiple different networks with different input data, processing speeds, and data constraints while still maintaining the low latency and high throughput required by machine automation systems. This is a unique intranet system architecture and is specifically defined and optimized for such machine automation applications.

[0111] Figure 4 A block diagram of an exemplary computing device 400 configured to implement system 100 according to a partial embodiment is shown. In addition to the features described above, external device 102 may also include some or all of the features of device 400 described below. Typically, a hardware architecture suitable for implementing computing device 400 includes a network interface 402, memory 404, processor 406, I / O device 408 (e.g., a reader), bus 410, and storage device 412. Optionally, one or more of the components shown can be removed or replaced by other components known in the art. The choice of processor is not critical, as long as a suitable processor with sufficient speed is selected. Memory 404 can be any conventional computer memory known in the art. Storage device 412 may include a hard disk drive, CD-ROM, CDRW, DVD, DVDRW, flash memory card, or any other storage device. Computing device 400 may include one or more network interfaces 402. Examples of network interfaces include network interface cards (NICs) connected to Ethernet or other types of LANs. I / O device 408 may include one or more of the following: keyboard, mouse, monitor, display, printer, modem, touchscreen, button interface, and other devices. Operating software / application 430 or its functions / modules can be stored in storage device 412 and memory 404, and processed as the application is typically processed. Computing device 400 can include more than Figure 4 More or fewer components are shown. In some embodiments, machine automation system hardware 420 is included. Although Figure 4 The computing device 400 includes an application 430 and hardware 420 for the system 100, but the system 100 can be implemented on the computing device in hardware, firmware, software or any combination thereof.

[0112] Figure 5 The operation method of a machine automation system 100, including an intelligent controller and a sensor intranet bus 104, according to a partial embodiment is shown. For example... Figure 5 As shown, in step 502, nodes 204 and 208 receive input data from multiple external devices 102 via one or more ports 99 of bus 104. In step 504, nodes 204 and 208 burst the input data as burst messages to kernel 200 in a variable-size burst window. In some embodiments, for each node 204 and 208, the HDBA of root port 230 dynamically adjusts the burst window start time and size of the variable burst window, and allocates the adjusted window to the corresponding node 204 and 208 by broadcasting an authorized window message based on data traffic parameters reported from nodes 204 and 208. In some embodiments, gate 202 aggregates two or more burst messages, including input data and / or traffic reports received from node 208, into a single larger burst report or input data message for bursting to kernel 200. In these embodiments, gate 202 may omit a portion (e.g., a preamble) of the received burst message to improve the efficiency of bus 104. In some embodiments, after receiving a broadcast window authorization message from kernel 200, gate 202 adjusts the original time of the burst window to an earlier time and broadcasts the adjusted broadcast window authorization message to node 208. Therefore, before the window authorized by root port 230, node 208 bursts its data to gate 202, allowing gate 202 to combine multiple burst messages together and burst them in a subsequent original time window. In step 506, kernel 200 processes the input data as a broadcast message and broadcasts it to each of the target nodes 204, 208 within the central network 206 and subnet 210 that need to receive the message. In step 508, the target nodes 204, 208 convert the broadcast message data into a format acceptable to the device 102 connected to nodes 204, 208 and output the data to device 102. Therefore, this method has the advantage that it allows bus 104 to maintain high speed despite using a lower-speed network medium.

[0113] Device Module

[0114] In some embodiments, device 102 may be a device module. Figure 9A Smart Compliant Actuator (SCA) and sensor module 900 according to a partial embodiment are illustrated. The SCA and sensor module 900 may be one or more of the devices 102 of the machine automation system 100 described herein. In some embodiments, the Smart Compliant Actuator (SCA) and sensor module are allowed to deviate from their own equilibrium position, depending on the applied external force, wherein the equilibrium position of the flexible actuator is defined as the position where the actuator generates zero force or zero torque. Figure 9 As shown, the SCA and sensor module may include one or more motors 902, one or more sensors 904, and / or a control board 906 (for controlling the motors 902 and / or sensors 904) connected together via a device network 908. In particular, this type of module 900 can perform machine automation tasks requiring high bandwidth and / or low latency (e.g., connected to one or more controller devices 102 via bus 104). The motors 902 may include actuator motors to control the actuation of the module 900 (e.g., movement of a robot arm), and the sensors 904 may include image and / or magnetic sensors to input image data and / or detect the position of the module 900 (e.g., the current position of the robot arm, the position of the image sensor, an image sensed from the front of the autonomous vehicle, or other sensed data).

[0115] Figure 10A -C illustrates variations of control panels 906, 906', 906" according to some embodiments. Figure 10A As shown, the control board 906 for the multi-connection mode module 900 may include a node system-on-a-chip (SoC) 1002, a transimpedance amplifier (TIA) and / or laser driver (LD) 1004, a bidirectional optical subassembly (BOSA) 1006, a power conditioner 1008, a motor driver 1010, a flexible actuator motor and power control connector 1012, a motor control signal transceiver 1014, one or more sensors 1016, a beam splitter 1018, an input power connector 1020, one or more output power connectors 1022, a first fiber optic connector 1024, and one or more second fiber optic connectors 1026, all operatively interconnected. Specifically, the BOSA 1006, beam splitter 1018, and fiber optic connectors 1024 and 1026 are interconnected via fiber optic cables. Optionally, one or more of the above components may be omitted, their number may be increased or decreased, and / or other components may be added.

[0116] The control board 906 may be a flexible printed circuit board. The BOSA 1006 may include a transmitter optical subassembly (TOSA), a receiver optical subassembly (ROSA), and a wavelength division multiplexing (WDM) filter, thus enabling it to support two wavelengths on each fiber using bidirectional technology. In some embodiments, the BOSA 1006 is a hybrid silicon photonics BOSA. The motor driver 1010 may be a pre-driver, gate driver, or other type of driver. The flexible actuator motor and power control connector 1012 may transmit control and / or power signals to the motor 902. The motor control signal transceiver 1014 may receive motor control signals via bus 104 and / or transmit motor, sensor, and / or other data to one or more controller devices 102. The sensor 1016 may include a magnetic sensor and / or other types of sensors. For example, the sensor 1016 may sense the position and / or orientation of the module 900 and provide position data as feedback to the SoC 1002 and / or the controller device 102 coupled to the module 900 via bus 104. The splitter 1018 can be integrated into the control board 906. The input power connector 1020 receives power from the control board 906. The output power connector 1022 is configured to supply, transmit, and / or forward power to one or more other boards / modules 900.

[0117] A first fiber optic connector 1024 is connected to a beam splitter 1018, which splits the cable into two or more cables. One cable is connected to a BOSA 1006 for transmitting signals to and from other components of board 906, and the remaining cables are connected to one or more second fiber optic connectors 1026. The first fiber optic connector 1024 and / or the second fiber optic connector 1026 may be a pigtail fiber optic connection point and / or connector 1024. Specifically, the pigtail fiber optic connection point and / or connector may comprise a single short, typically tightly buffered fiber optic cable with a pre-installed optical connector at one end and a section of bare fiber at the other end. The end of the pigtail may be stripped and fused to a single fiber of a multi-fiber backbone. Alternatively, other types of optical connection points and / or connectors 1024 may be used.

[0118] In operation within control boards 906, 906', and 906", motor driver 1010 can receive pulse-width modulation (PWM) control signals generated by SoC 1002 (and / or via controller device 102 of SoC 1002) for controlling the torque, speed, and / or other operations of motor 902 of SCA module 900 (via flexible actuator motor and power control connector 1012). Furthermore, sensors 1016, 904, and / or driver 1010 can provide motor and / or sensor status feedback to SoC 1002, allowing SoC 1002 (and / or via controller device 102 of SoC 1002) to adjust control signals based on this feedback to control the operation of motor 902 and / or sensor 904. For example, driver 1010 can provide motor current sensor feedback including A-phase current values, B-phase current values, and C-phase current values, where the internal analog-to-digital converter (ADC) of SoC 1002 converts these values ​​into digital values, which SoC 1002 (and / or via SoC 1002) can then adjust based on this feedback to control the operation of motor 902 and / or sensor 904. The controller device 102 of 1002 adjusts the PWM control signal sent to the driver 1010 based on feedback from the motor current sensor received from the driver 1010, thereby adjusting the speed, torque and / or other characteristics of the motor 902.

[0119] In operation within system 100, the first fiber optic connector 1024 allows board / module 900 to be connected to bus 104 via fiber optic cable, while the splitter 1018 and the second fiber optic connector 1026 allow board / module 900 to be connected to one or more additional boards / modules 900 via additional fiber optic cables (e.g., for receiving control signals and / or sending data signals to one or more controller devices 102 connected to other ports 99 of bus 104). Therefore, as Figure 11A As shown, board / module 900 can be serially cascaded to port 99 of bus 104, where a single port 99 can connect to multiple boards / modules 900. Specifically, as... Figure 11A As shown, a board 906 is optically coupled to port 99 from a first fiber optic connector 1024 (via fiber optic cable), and each subsequent board 906 connects its first fiber optic connector 1024 (all via fiber optic cable) to a second fiber optic connector 1026 of another board 906. In practice, as... Figure 11AAs shown, if board 906 includes multiple second fiber optic connectors 1026, the cascading can branch into a tree structure, where a single board / module 900 is optically connected to multiple other boards / modules 900. Simultaneously, the boards / modules 900 can share power in the same manner, whereby the input power connector 1020 of one or more modules 900 receiving power from a power source receives power by connecting its input power connector 1020 to the output power connector 1022 of another module 900, thereby achieving optical interconnection of one or more other modules 900.

[0120] Optionally, such as Figure 11B As shown, the control board 906' for the single-connection mode module 900 may not include one or more second fiber optic connectors 1026 and / or one or more output power connectors 1022. In some embodiments, as Figure 10C As shown, the control board 906” for the single-connection mode image sensor module 900 may further include one or more flexible actuator motors 1028 and one or more image or other type (e.g., camera, LiDAR, magnetic, ultrasonic, infrared, radio frequency) sensors 1030. In this embodiment, the motor 1028 may control the movement of the sensor 1030, while the sensor 1016 detects the position and / or orientation of the motor 1028 and / or the sensor 1030. Optionally, the control board 906” may be a multi-connection mode image sensor module 900, which further includes one or more second fiber optic connectors 1026 and / or one or more output power connectors 1022.

[0121] like Figure 11A As shown, these single-connection mode modules 900 and / or boards 906' and 906" can be connected to a cascade or tree and / or parallel connection to bus 104 formed by multi-connection mode modules 900. Additionally, as Figure 11B As shown, system 100 may include one or more external optical splitters 1102, wherein one or more of the boards / modules 906, 906', 906" configured to be serially cascaded, tree-connected, and / or parallel-connected may be further parallelized and / or serialized using external optical splitters 1102 connected to bus 104. For example, as Figure 11B As shown, the beam splitter 1102 is used to connect a single port 99, the cascaded output of module 900, one or more individual modules 900, and another beam splitter 1102. Although as... Figure 11B As shown, splitter 1102 is a 1:4 splitter, but they can be any ratio of 1:N as needed. Furthermore, although as... Figure 11A and 11BAs shown, only modules 906, 906', and 906" are shown as connected to bus 104; however, it should be understood that any combination of other devices 102 may also be connected to bus 104 along with modules. For example, one or more controller devices 102 may be connected to bus 104 to receive data and issue commands to modules.

[0122] Therefore, compared to Module 900, other modules offer advantages in achieving significantly higher throughput and data bandwidth, supporting up to 10 to 100 times the bandwidth and longer distances. In particular, the ability to utilize optical communication and serial cascading connections enables Module 900 to provide fast data transmission speeds and ultra-low latency, unaffected by electromagnetic interference (EMI). Furthermore, Module 900's advantages are particularly pronounced in robotics, industrial automation, and autonomous vehicles, as it can handle their high bandwidth and low latency requirements for sensor data.

[0123] Figure 12 A method of operating a controller and sensor bus according to a partial embodiment is illustrated. The controller and sensor bus include multiple ports for connection to multiple external machine automation devices of the machine automation system. For example... Figure 12 As shown, in step 1202, one or more controller devices 102 are connected to one or more ports 99 of bus 104. In step 1204, first fiber optic connectors 1024 of one or more SCA and sensor modules 900 are connected to one or more ports 99. In step 1206, messages are relayed between controller 104 and SCA and sensor modules 900 via bus 104 through one or more central transmission networks 206. In step 1208, control board 906 adjusts the operation of SCA and sensor modules 900 based on messages received from controller devices 102. In some embodiments, each SCA and sensor module 900 is directly connected in parallel to one of the ports 99 via fiber optic cables. In some embodiments, connecting the SCA and sensor modules 900 includes connecting the SCA and sensor modules 900 in parallel to splitter 1102 and connecting splitter 1102 to port 99 via fiber optic cables. In some embodiments, connecting the SCA and sensor module 900 includes connecting a first fiber optic connector 1024 of the first SCA and sensor module 900 to one of the ports 99 via a fiber optic cable, and connecting a second fiber optic connector 1026 of the first SCA and sensor module 900 to the first fiber optic connector 1024 of the second SCA and sensor module 900.

[0124] The system 100, which enables dynamic burst-to-broadcast transmission networks, along with the machine automation controller and sensor bus 104, offers numerous advantages. Specifically, it provides the following benefits: simplified cabling systems and connections; elimination of significant electromagnetic interference (EMI) caused by the use of fiber optics; ensured low latency for node-to-node communication; high throughput bandwidth (10, 25, 100, or higher Gbps) for node-to-node transmissions; node-to-node device extension up to 20 km; low power consumption due to the passive optical network architecture; industrial-grade QoS that avoids traffic congestion due to the centralized DBA scheduling mechanism; a built-in HARQ mechanism that guarantees successful node-to-node and GEM transmissions; and a unified software image for the entire intranet system, including all gates, nodes, and root ports, thereby simplifying the software architecture, shortening product development cycles, and simplifying system-level commissioning, monitoring, and troubleshooting.

[0125] This application has been described with reference to specific embodiments in conjunction with details to facilitate understanding of the construction and operating principles of this application. The specific embodiments and details herein are not intended to limit the scope of the appended claims. Those skilled in the art will understand that various other modifications may be made based on the selected embodiments without departing from the spirit and scope of this application as defined by the claims. For example, although as described herein, the bus is depicted as operating within a machine automation system, it should be understood that the bus can operate alongside other types of systems and their devices to facilitate communication between devices.

Claims

1. A machine automation system for controlling and operating an automated machine, the system comprising: a controller and sensor bus comprising a plurality of ports, wherein the bus comprises a central processing core and a multimedia transport intranet comprising one or more central fiber optic transport networks directly coupled to the core and one or more subnets; the central fiber optic transport networks comprising a plurality of nodes and one or more gates; each of the plurality of subnets coupled to a different gate of one of the central fiber optic transport networks; the subnets comprising a plurality of sub-nodes, wherein each of the nodes and sub-nodes are associated with one or more of the ports; one or more controllers each coupled to a first one of the ports of the bus; and one or more flexible effector modules each comprising a first fiber optic connector, one or more motors, one or more sensors, and a system on chip (SoC); each module operably coupled to a second one of the ports by a fiber optic cable coupled from the first fiber optic connector to the second one of the ports; wherein the nodes and sub-nodes of the bus relay messages via the one or more central fiber optic transport networks over the bus, the messages comprising sensor data from the sensors of the flexible effector modules and control data from the controllers between the controllers and the flexible effector modules, and the messages are burst from each of the nodes to the central processing core and broadcast from the central processing core to all of the nodes.

2. The system of claim 1, wherein, Each of the flexible effector modules is directly and in parallel coupled to one of the second ones of the ports via the fiber optic cable.

3. The system of claim 1, wherein, A plurality of the flexible effector modules are in parallel coupled to a splitter coupled to one of the second ones of the ports via the fiber optic cable.

4. The system of claim 1, wherein, Each of the flexible effector modules comprises a second fiber optic connector and a splitter, wherein the splitter is coupled to the first fiber optic connector, the second fiber optic connector, and the SoC.

5. The system of claim 4, wherein, The flexible effector modules are in series coupled such that a first fiber optic connector in a first one of the flexible effector modules is coupled to one of the second ones of the ports via the fiber optic cable and a second fiber optic connector in the first one of the flexible effector modules is coupled to a first fiber optic connector in a second one of the flexible effector modules.

6. The system of claim 5, wherein, Each of the flexible effector modules comprises a bidirectional optical subassembly (BOSA), a transimpedance amplifier, a laser driver, and a motor driver.

7. The system of claim 6, wherein, The sensors of one or more of the flexible effector modules comprise an image sensor and a magnetic sensor, wherein the motor controls a sharpness of the image sensor and the magnetic sensor determines a direction of the image sensor.

8. The system of claim 1, wherein, The first fiber optic connector is a pigtail fiber optic connector.

9. The system of claim 1, wherein, The second ones of the ports are optical ports coupled to pigtail fiber optic connectors.

10. The system of claim 1, wherein, The automated machine is one of a group consisting of a robot and an autonomous vehicle.

11. A method of operating a controller and sensor bus, the controller and sensor bus comprising a plurality of ports for coupling with a plurality of external machine automation devices of a machine automation system, the bus having a central processing core and a multimedia transport intranet, the multimedia transport intranet comprising one or more central fiber optic transport networks directly coupled with the core and comprising a plurality of nodes and one or more gates, and a plurality of subnets each coupled with a different gate of the central fiber optic transport networks, the subnets comprising a plurality of subnodes, the method comprising: coupling one or more controllers with a first port of the ports of the bus; coupling one or more flexible effector modules with a second port of the ports of the bus via a fiber optic cable coupled from a first fiber optic connector to the second port, each of the flexible effector modules comprising the first fiber optic connector, one or more motors, one or more sensors, and a system on chip (SoC); and relaying messages between the controllers and the flexible effector modules via the one or more central fiber optic transport networks with the nodes and subnodes of the bus, the messages comprising sensor data from the sensors of the flexible effector modules and control data from the controllers and the messages being burst from each of the nodes to the central processing core and broadcast from the central processing core to all of the nodes.

12. The method of claim 11, wherein, Each of the flexible effector modules is directly and parallel coupled to one of the second ports of the ports via the fiber optic cable.

13. The method of claim 11, wherein, Coupling the flexible effector modules comprises coupling the flexible effector modules in parallel to a splitter and coupling the splitter to one of the second ports of the ports via the fiber optic cable.

14. The method of claim 11, wherein, Each of the flexible effector modules comprises a second fiber optic connector and a splitter, wherein the splitter is coupled with the first fiber optic connector, the second fiber optic connector, and the SoC.

15. The method of claim 14, wherein, Coupling the flexible effector modules comprises coupling a first fiber optic connector in a first of the flexible effector modules to one of the second ports of the ports via the fiber optic cable and coupling a second fiber optic connector in the first of the flexible effector modules to a first fiber optic connector in a second of the flexible effector modules.

16. The method of claim 15, wherein, Each of the flexible effector modules comprises a bidirectional optical subassembly (BOSA), a transimpedance amplifier, a laser driver, and a motor driver.

17. The method of claim 16, wherein, The sensors of one or more of the flexible effector modules comprise an image sensor and a magnetic sensor, the method further comprising controlling a sharpness of the image sensor with the motor and determining a direction of the image sensor with the magnetic sensor.

18. The method of claim 11, wherein, The first fiber optic connector is a pigtail fiber optic connector.

19. The method of claim 11, wherein, The second ports of the ports are optical ports coupled with pigtail fiber optic connectors.

20. The method of claim 11, wherein, The external machines are one of a group consisting of robots and autonomous vehicles.

Images