Intelligent Controller and Sensor Network Bus, System and Method Including General Encapsulation Modes

Abstract

A machine automation system for controlling and operating an automated machine. The system includes a controller and a sensor bus that implement dynamic bursts for a broadcast transmission scheme, and the controller and sensor bus include a central processing core and a multimedia transmission intranet, wherein messages burst from nodes to the central processing core and are broadcast from the central processing core to all nodes.

Description

[0001] Cross-reference

[0002] This application is a partial continuation of the pending U.S. patent application Ser. No. 16 / 529,682, filed on Aug. 1, 2019, entitled “Intelligent Controller and Sensor Network Bus, System and Method,” which is incorporated herein by reference. Technical Field

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

[0004] With the development of autonomous vehicles, intelligent robots, and factory automation, the field of machine automation is expanding rapidly. However, due to their diverse and high-speed requirements, there is currently no bus or network architecture that can effectively meet all the requirements of these emerging technologies. Instead, current networks have high latency, low bandwidth, complex cabling, high electromagnetic interference (EMI), high cost, insecure data, and complex system integration. For example, the network does not have sufficient speed and throughput to carry sensor data, such as camera and lidar (LIDAR) data, over the network to the CPU core. In addition, existing cable systems are complex, short-range, and unable to handle EMI without expensive shielding due to the use of copper cable wiring systems. There is currently no multi-functional “controller and sensor network” system bus solution that can support and carry Internet L2 / L3 Ethernet packets, motor and motion control information, sensor data, and CPU commands (CPU-CMD) throughout the system from edge node to edge node. 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 that includes a central processing core and a multimedia transport intranet for implementing dynamic bursts for a broadcast transmission scheme, where messages burst from nodes to the central processing core and are broadcast from the central processing core to all nodes.

[0006] A first aspect of the present application relates to a machine automation system for controlling and operating an automated machine. The system includes: a controller and a sensor bus including a plurality of input / output ports, and a plurality of external machine automation devices operatively coupled together through the ports of the bus. Among them, the bus includes a central processing core and a multimedia transport intranet, and the multimedia transport intranet includes: one or more central transport networks directly coupled to the core and including a plurality of nodes and one or more gates; and a plurality of subnets respectively coupled to different gates of the central transport network, the subnets including a plurality of sub-nodes, wherein each node and sub-node is coupled to one or more devices through one or more ports, receives messages from one or more devices coupled to one or more ports; encapsulates the messages into a General Encapsulation Mode (GEM) format for transmission to the central processing core; and de-encapsulates the messages received from the central processing core from the GEM format into the original format of the input data received from one of the devices.

[0007] In some embodiments, the header of the GEM format includes: a source / destination field that identifies one of the ports as the source of the message or one or more nodes and sub-nodes as the destination of the message; and a GEM packet identifier field that identifies one or more ports that the message is directed to. In some embodiments, when one of the ports is identified as the source of the message, the value of the source field is selected from a first set of epoch identifier values, and when one or more nodes and sub-nodes are identified as the destination of the message, the value of the destination field is selected from a second set of node identifier values. In some embodiments, the value of the GEM packet identifier field is selected from a third set of GEM identifier values, and each node identifier value is mapped to one or more epoch identifier values, and each epoch identifier value is mapped to one or more GEM identifier values. In some embodiments, the header of the GEM format includes a GEM packet type field that indicates the original format and header type of the message encapsulated in the GEM format. In some embodiments, the header of the GEM format includes a source identifier field and a report message type field, the source identifier field indicates the source of the message, and the report message type field indicates whether the report data in the message is independent of the source of the message indicated in the source identifier field.

[0008] In some embodiments, the GEM - formatted header includes a start - time field and an authorized - size field. The start - time field indicates the time when the authorized - bandwidth window starts, and the authorized - size field indicates the size of the authorized - bandwidth window. In some embodiments, the GEM - formatted header includes an authorization - command field that indicates one or more types of messages allowed during the authorized - bandwidth window. In some embodiments, after encapsulating a message into the GEM format, each node and sub - node places one or more messages into a burst physical - layer frame format and transmits the messages to the central - processing kernel by bursting the burst physical - layer frame including one or more messages to the central - processing kernel. In some embodiments, the burst - physical - frame format includes a separate burst - end delimiter for each of the one or more messages, and the separate burst - end delimiter indicates the end of one of the one or more messages within the burst physical - layer frame. In some embodiments, each gate aggregates GEM - formatted messages from multiple sub - nodes into a single larger message in the burst physical - layer frame format. In some embodiments, each gate omits the preambles of the messages from multiple sub - nodes from the single larger message in the burst physical - layer frame format. In some embodiments, the device includes one or more of the group consisting of an ultrasonic sensor, a light detection and ranging sensor, an infrared sensor, a camera, a motor, and a micro - controller. In some embodiments, the automated machine is one of the group consisting of a robot and an autonomous vehicle.

[0009] The second aspect of the present application relates to a controller and a sensor bus. The bus includes a plurality of input / output ports for coupling to a plurality of external machine - automation devices of a machine - automation system, a central - processing kernel, and a multimedia - transmission intranet. The multimedia - transmission intranet includes one or more central - transmission networks that are directly coupled to the kernel and include a plurality of nodes and one or more gates; and a plurality of sub - networks that are respectively coupled to different gates of the central - transmission network. The sub - network includes a plurality of sub - nodes, wherein each node and sub - node is coupled to one or more devices through one or more ports, receives messages from the one or more devices coupled to the one or more ports; encapsulates the messages into a General Encapsulation Mode (GEM) format for transmission to the central - processing kernel; and de - encapsulates the messages received from the central - processing kernel from the GEM format into the original format of the input data received from one of the devices.

[0010] In some embodiments, the GEM - formatted header includes: a source / destination field that identifies one of the ports as the source of the message or one or more nodes and sub - nodes as the destination of the message; and a GEM packet identifier field that identifies one or more ports that the message is targeted at. In some embodiments, when identifying one of the ports as the source of the message, the value of the source / destination field is selected from a first set of epoch identifier values, and when identifying one or more nodes and sub - nodes as the destination of the message, the value of the source / destination field is selected from a second set of node identifier values. In some embodiments, the value of the GEM packet identifier field is selected from a third set of GEM identifier values, and each node identifier value maps to one or more epoch identifier values, and each epoch identifier value maps to one or more GEM identifier values. In some embodiments, the GEM - formatted header includes a GEM packet type field that indicates the original format and header type of the message encapsulated within the GEM format. In some embodiments, the GEM - formatted header includes a source identifier field and a report message type field, where the source identifier field indicates the source of the message and the report message type field indicates whether the report data within the message is independent of the source of the message indicated in the source identifier field.

[0011] In some embodiments, the GEM - formatted header includes a start time field and an authorized size field, where the start time field indicates the time when the authorized bandwidth window starts and the authorized size field indicates the size of the authorized bandwidth window. In some embodiments, the GEM - formatted header includes an authorization command field that indicates one or more types of messages allowed during the authorized bandwidth window. In some embodiments, after encapsulating the message into the GEM format, each node and sub - node places one or more messages into a burst physical layer frame format and transmits the message to the central processing core by bursting the burst physical layer frame including one or more messages to the central processing core. In some embodiments, the burst physical frame format includes a separate burst end delimiter for each of the one or more messages, and the separate burst end delimiter indicates the end of one of the one or more messages within the burst physical layer frame. In some embodiments, each gate aggregates GEM - formatted messages from multiple sub - nodes into a single larger message in the burst physical layer frame format. In some embodiments, each gate omits the preambles of the messages from multiple sub - nodes from the single larger message in the burst physical layer frame format. In some embodiments, the device includes one or more of the group consisting of ultrasonic sensors, light detection and ranging sensors, infrared sensors, cameras, motors, and microcontrollers. In some embodiments, the automated machine is one of the group consisting of robots and autonomous vehicles.

[0012] A third aspect of the present application relates to an operation method of a controller and a sensor bus. The controller and the sensor bus include a plurality of input / output ports for connecting to a plurality of external machine automation devices of a machine automation system, a central processing core; and a multimedia transmission intranet, the multimedia transmission intranet including one or more central transmission networks, the one or more central transmission networks being directly connected to the core and including a plurality of nodes and one or more gates; and a plurality of subnets, the plurality of subnets being respectively connected to different gates of the central transmission network, the subnets including a plurality of sub-nodes. The method includes: one or more nodes and sub-nodes receiving messages from one or more devices connected to one or more ports associated with the one or more nodes and sub-nodes; encapsulating the messages into a Generic Encapsulation Mode (GEM) format for transmission to the central processing core; and de-encapsulating the messages received from the central processing core from the GEM format into the original format of the input data received from one of the devices.

[0013] In some embodiments, the header of the GEM format includes a source / destination field that identifies one of the ports as the source of the message or identifies one or more nodes and sub-nodes as the destination of the message; and a GEM packet identifier field that identifies one or more ports that the message is directed to. In some embodiments, when one of the ports is identified as the source of the message, the value of the source / destination field is selected from a first set of epoch identifier values, and when one or more nodes and sub-nodes are identified as the destination of the message, the value of the source / destination field is selected from a second set of node identifier values. In some embodiments, the value of the GEM packet identifier field is selected from a third set of GEM identifier values, and each node identifier value is mapped to one or more epoch identifier values, and each epoch identifier value is mapped to one or more GEM identifier values. In some embodiments, the header of the GEM format includes a GEM packet type field that indicates the original format and header type of the message encapsulated within the GEM format. In some embodiments, the header of the GEM format includes a source identifier field and a report message type field, the source identifier field indicating the source of the message, and the report message type field indicating whether the report data within the message is independent of the source of the message indicated in the source identifier field.

[0014] In some embodiments, the GEM - formatted header includes a start - time field and an authorization - size field. The start - time field indicates the time when the authorized bandwidth window starts, and the authorization - size field indicates the size of the authorized bandwidth window. In some embodiments, the GEM - formatted header includes an authorization - command field that indicates one or more types of messages allowed during the authorized bandwidth window. In some embodiments, the method further includes, after encapsulating a message into the GEM format, placing one or more messages into a burst physical - layer frame format using each node and sub - node, and transmitting the message to a central processing core by bursting the burst physical - layer frame including one or more messages to the central processing core using each node and sub - node. In some embodiments, the burst physical - frame format includes a separate burst - end delimiter for each of the one or more messages, and the separate burst - end delimiter indicates the end of one of the one or more messages within the burst physical - layer frame. In some embodiments, the method further includes aggregating GEM - formatted messages from multiple sub - nodes into a single larger message in the burst physical - layer frame format using each gate. In some embodiments, the method further includes, using each gate, omitting the preambles of the messages from multiple sub - nodes from the single larger message in the burst physical - layer frame format. In some embodiments, the device includes one or more of the group consisting of an ultrasonic sensor, a light detection and ranging sensor, an infrared sensor, a camera, a motor, and a microcontroller. In some embodiments, the automated machine is one of the group consisting of a robot and an autonomous vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 FIG. shows a machine - automation system according to some embodiments.

[0016] Figure 2 FIG. shows an intelligent - controller and sensor internal - network bus according to some embodiments.

[0017] Figure 3 FIG. shows a tree - topology of an intelligent - controller and sensor internal - network bus according to some embodiments.

[0018] Figure 4 FIG. shows a block diagram of an exemplary computing device for implementing the system according to some embodiments.

[0019] Figure 5 FIG. shows an operation method of a machine - automation system including an intelligent - controller and sensor internal - network bus according to some embodiments.

[0020] Figure 6A FIG. shows an exemplary GEM packet format according to some embodiments.

[0021] Figure 6BShows a detailed view of the GEM packet header format according to some embodiments.

[0022] Figure 6C Shows a detailed view of the GEM header format for node report messages according to some embodiments.

[0023] Figure 6D Shows a detailed view of the first variant of the GEM header format for root port bandwidth authorization messages according to some embodiments.

[0024] Figure 6E Shows a detailed view of the second variant of the GEM header format for root port bandwidth authorization messages according to some embodiments.

[0025] Figure 6F Shows a detailed view of the GEM header format for control messages according to some embodiments.

[0026] Figure 7A Shows the Broadcast-PHY-Frame according to some embodiments.

[0027] Figure 7B Shows the Burst-PHY-Frame according to some embodiments.

[0028] Figure 7C Shows the gated Burst-PHY-Frame according to some embodiments.

[0029] Figure 8 Shows an operating method of an intelligent controller and a sensor intranet bus according to some embodiments. Detailed Description

[0030] The embodiments described herein relate to machine automation systems, methods, and devices for controlling and operating automated machines. The systems, methods, and devices include a controller and a sensor bus that includes a central processing core and a multimedia transmission intranet for implementing dynamic bursts for broadcast transmission schemes. Among them, messages burst from nodes to the central processing core and are broadcast from the central processing core to all nodes. Therefore, although the systems, methods, and devices incorporate low-speed network media, they still have the advantage of high-speed performance; the systems, methods, and devices also provide a unified software image of a complete intranet system including all gates, nodes, and root ports, thereby achieving a simplified software architecture, a shorter product development cycle, and easier system-level debugging, remote monitoring, and troubleshooting. In particular, the systems, methods, and devices provide a unique intranet system architecture defined and optimized specifically for machine automation applications.

[0031] Figure 1FIG. 0 shows a machine automation system 100 according to some embodiments. As Figure 1 shown, system 100 includes one or more external devices 102 that are operably coupled to an intelligent controller and sensor intranet bus 104. In some embodiments, system 100 can be part of an automated device (such as an autonomous vehicle, an automated industrial machine, or an automated robotic controller). Optionally, system 100 can be part of other machine automation applications. Devices 102 can include one or more of sensor devices (such as ultrasonic, infrared, cameras, lidar (LIDAR), sonar (SONAR), magnetic, radar (RADAR)), Internet devices, motors, actuators, lights, displays (such as screens, user interfaces), speakers, graphics processing units, central processing units, memories (such as solid state drives, hard disk drives), and controllers / microcontrollers. Each device 102 can be operably wired and / or wirelessly connected to bus 104 through one or more bus input / output (IO) ports (see Figure 2 ). Although as Figure 1 shown, system 100 includes a discrete number of external devices 102 and bus 104, it is contemplated that there can be more or fewer devices 102 and / or bus 104.

[0032] Figure 2 FIG. 10 shows an intelligent controller and sensor intranet bus 104 according to some embodiments. As Figure 2 shown, bus 104 includes an intranet formed by a central core 200 that is coupled to one or more gates 202 and a plurality of edge nodes 204 (each edge node 204 having one or more external IO ports 99) through one or more central transmission networks 206, and is coupled to one or more edge sub-nodes 208 (each edge sub-node 208 having one or more external IO ports 99) through one or more subnets 210 extending from gates 202. Thus, as Figure 3 shown, bus 104 forms a network tree topology, where the central network 206 branches from the central core 200 (e.g., the root port 230 of the core) to edge nodes 204 and gates 202, and subnets 210 branch from gates 202 to sub-nodes 208 and / or sub-gates 202'. In this way, the central core 200 can view all nodes 204 and sub-nodes 208 (since gates 202 and sub-gates 202' are transparent to the central core 200). In some embodiments, in the absence of nodes, one or more gates 202 are directly coupled to IO ports 99 (e.g., to couple to an external CPU, GPU, AI core, and / or solid state drive (SSD)).

[0033] Port 99 can be any type of interface port, such as a Peripheral Component Interconnect Express (PCIe), Mobile Industry Processor Interface (MIPI), Ethernet, Universal Serial Bus (USB), General-Purpose Input / Output (GPIO), Universal Asynchronous Receiver / Transmitter (UART), Inter-Integrated Circuit (I2C), and / or other types of ports. Although as Figure 2 shown, bus 104 includes a discrete number of ports 99, cores 200, nodes 204, 208, gates 202, networks 206, 210, other elements and components, it is contemplated that there may be more or fewer ports 99, cores 200, nodes 204, 208, gates 202, networks 206, 210, other elements and / or components.

[0034] The central transmission network 206 can include connection media that is faster / lower latency than the connection media of subnet 210 of gate 202 coupled to the central transmission network 206. Similarly, subnet 210 can include connection media that is faster / lower latency than the connection media of subnet 210' of gate 202' coupled to subnet 210; and so on for each iterative subnet. This speed / latency relationship of the network / subnet connection media enables the prevention of the slowdown of the entire bus 104 from occurring, 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 can have the same or other connection media speed / latency relationships.

[0035] In some embodiments, the connection medium of the central transmission network 206 includes an optical fiber cable 212, which is split using a 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 an optical fiber connection medium (e.g., similar to the connection medium of the central transmission network 206, but possibly of a lower grade), a wireless connection (e.g., a radio frequency transceiver 218), a copper cable connection (e.g., a twisted pair copper wire 220, which is preferably split using an analog splitter 222 (e.g., a fan-out output / multiplexer) and has a serializer / deserializer (SERDES) 224 to connect to and receive data from nodes 204, 208), and / or a combination thereof (e.g., a hybrid optical fiber, copper cable, and / or wireless connection medium). Thus, the bus 104 supports multi-rate traffic transmission, where different nodes / networks can be used to connect to the bus 104 according to the latency / speed, connectivity, and / or distance requirements of the data / traffic / external device 102 while still providing the required throughput. For example, for high-speed, low-latency, and long-distance requirements, the optical connection medium of the central network can be used by connecting to node 204. Otherwise, other networks 210 can be used according to cost, speed, connectivity, and / or distance requirements. In some embodiments, the central network 206 is a passive optical network, and / or the copper cable subnet 210 is an active network. In some embodiments, as Figure 2 shown, one or more nodes 204 are connected to a controller area network (CAN) 226 such that each node inputs data from each controller connected to the controller area network. Optionally, as Figure 3 shown, one or more subnets 210 can be a CAN connected to the central core 200 through a gate 20.

[0036] Multi-layer bus addressing

[0037] The bus 104 can utilize a multi - level addressing scheme, where the root port 230, IO ports 99, nodes 204, 208, 234, and / or gates 202 can use node, epoch, and GEM identification addresses to direct messages through the bus 104. In particular, each of the root port 230, nodes 204, 208, 234, and gates 202 can be assigned a node ID identifier (node - ID), and nodes 204, 208, and gates 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 the networks 206, 210 (e.g., nodes / gate devices and their IO ports, embedded central processors, and / or other types of services), while the GEM - ID can be used to identify the target of a message (e.g., a set and subset of nodes / gate devices and their IO ports, embedded central processors, and / or other types of services). Thus, the epoch ID can be used for the transmission / routing of messages across the entire networks 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 as its target.

[0038] Based on the service - level agreement (SLA) profile of the node / gate (which can correspond to the device connected to port 99 of the node / gate), multiple epoch IDs and multiple GEM - IDs can be assigned to the node / gate. Thus, the node ID of each of nodes 204, 208, and gates 202 can be mapped to one or more epoch IDs, which can be mapped to one or more GEM - IDs. For example, nodes 204, 208 connected to two IO 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). Additionally, although the node ID and epoch ID are unique for each node / gate / port, the GEM - ID can be shared among nodes / gates / ports. For example, the ports 99 of the same nodes 204, 208 or different ports 99 of different nodes 204, 208 can all be associated with matching or overlapping sets of GEM - IDs.

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

[0040] Each of the other nodes 234 and the cores 232 (which are directly coupled to the core 200, such as IO devices and embedded central processor cores) can have one or more GEM-IDs and global node IDs, but do not need to be assigned an epoch ID, which is unnecessary because messages traveling to and from these nodes 234 and the core 200 are entirely within the core 200. Similar to nodes 204, 208, the number of GEM-IDs assigned to each node 234 and core 232 can be determined based on the SLA profile of the node 234 or core 232 (which can correspond to a device coupled to port 99 of the node 234). Each of the core switches 220, root ports 230, nodes 204, 208, 234, and / or gates 202 can maintain and update a local SLA table that indicates the mapping between each node ID, epoch ID, and GEM-ID. Thus, bus addressing provides the advantage of using epoch IDs and / or node IDs to facilitate simplified burst / broadcast messaging between nodes, gates, and cores within the network 100, while using GEM-IDs to facilitate any required more complex messaging between devices / IO ports 99 and / or the cores themselves.

[0041] General Encapsulation Mode

[0042] The bus 104 can encapsulate all input data and internally generated data (e.g., control messages, operation messages, and management messages) in a General Encapsulation Mode (GEM) for transmission over the bus 104 internal network. Thus, GEM serves as a unique standardized data and message container for transmitting data between nodes and / or to the central core 200 over the bus 104 internal network. Thus, input data can be encapsulated into GEM format at each node when entering the bus 104 and reach its destination node via the central core 200 (where it is de-encapsulated for processing and re-encapsulated for transmission), and the destination node de-encapsulates the data into its original format for external delivery to the target external device 102 or other destination. This input data can come from various sources (e.g., device 102, CAN 226) input through port 99 at nodes 204, 208, 234, or gates 202 and / or the embedded CPU core 232.

[0043] There are two types of GEM formats: GEM packet and GEM control. The GEM packet format includes a GEM header plus a GEM payload (e.g., with a length from 8 bytes to 4 kilobytes). Generally, the GEM packet format is used to encapsulate input port data, packets, and messages at the ingress (e.g., nodes, ports). The following are some examples of IO port data, packets, and messages that can utilize the GEM packet format:

[0044] - Using the GEM packet format, Ethernet packets are carried from the local gate 202 and / or nodes 204, 208 through the bus 104 after GEM encapsulation, to the remote gate 202 and / or nodes 204 (for example, the remote gate 202 and / or nodes 204 can be used for Internet and Wi-Fi interfaces through Ethernet ports or PCIe ports).

[0045] - Using the GEM packet format, sensor data is carried from the local gate 202 and / or nodes 204 through the bus 104 after GEM encapsulation, to the remote gate 202 and / or nodes 204 (for example, CAN bus data, camera (MIPI) frame data, lidar (Ethernet) data, electromagnetic encoder data (ADC), and other types of sensor data).

[0046] - Using the GEM packet format, jumbo data and packets are carried from the local nodes 204, 208 to the remote nodes 204, 208 through a fragmentation and defragmentation scheme. This can include fragmentation, defragmentation, and reordering / retransmission functions.

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

[0048] - Using the GEM packet format, CPU / PCIe access CMD / DATA is carried from the kernel 200 and the local gate 202 and / or nodes 204 through the bus 104 after GEM encapsulation, to the remote local gate 202 and / or nodes 204 (for example, the CPU 232 accesses target devices 102 from node to node through PCIe, USB, I2C, UART, and GPIO interfaces).

[0049] - Finally, using the GEM packet format, it is used for VPN tunnel applications between the local nodes 204, 208 and the remote nodes 204, 208 through the bus 104.

[0050] The GEM control message format includes messages and extended messages (e.g., 8 bytes + 8 bytes in length...). On bus 104, the GEM control message format can be used for internal network management and control purposes, including dynamic bandwidth allocation (DBA) reporting, DBA authorization, GEM receive (RX) confirmation, GEM flow control, GEM power management, GEM listening, GEM remote messages, and / or other types of control messages. As described above, node 204 is responsible for encapsulating data into the GEM packet format and the GEM control message format / decapsulating data from the GEM packet format and the GEM control message format. This solution 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 distance to long distance.

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

[0052] Figure 6B shows a detailed view of the GEM packet header format according to some embodiments. As Figure 6B shown, header 602 includes a GEM type field 606, a payload length indication field 608, an encryption key index field 610 (e.g., 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, a confirmation required field 620, a last fragment indication field 622, and a header error correction / check (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 confirmation required field 620 is one bit, the last fragment indication field 622 is one bit, and the header error correction / check (HEC) field 622 is thirteen bits. Optionally, one or more of the above fields can be larger or smaller.

[0053] The GEM type field 606 indicates what type of header 602 of the GEM packet 600 is (and thus what type of packet it is). For example, the GEM type field can indicate that the header 602 is a packet header, a bandwidth authorization message header (e.g., transmitted from the root port 230 to the gate / node), a bandwidth report message header (e.g., transmitted from the gate / node to the root port 230), and / or a control message (e.g., between the root port 230, one or more of the gates 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.

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

[0055] The GEM packet type field 616 can indicate the type and format of the header of a message encapsulated within the 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 Operations and Control Report (NOCR) message. The acknowledgment required field 620 can indicate whether an acknowledgment message is required in response to the message; the transmission sequence identifier field 618 can identify the transmission sequence number of the packet 600 within a set of packets from the source node and / or its epoch ID (for packets from the slave bursting to the kernel 200). In some embodiments, when indicated by the acknowledgment required field 620, an acknowledgment message is required from the receiving root port 230. For packets broadcast from the root port 230 to the nodes / gates, the transmission sequence identifier field 618 can identify 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, when indicated by the acknowledgment required field 620, an acknowledgment is required from the receiving root port 230 and / or the node. The last fragment indicator field 622 can indicate whether the packet 600 is the last fragment in a series of fragments of a large packet, and the Header Error Correction / Checksum (HEC) field 622 can be used to check for errors in the header 602.

[0056] Figure 6C A detailed view of the GEM header format of a node report message according to some embodiments is shown. As Figure 6CAs shown, the header 602 includes a GEM type field 606, a report message type field 624, a source epoch ID field 626, a report total 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 (such as CPU-IO, PLOAM, NMCI, CAN, sensor, Ethernet, or other types), a report priority field 636, and a header error correction / check (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 report total 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 field of six bits), the report priority field 636 is two bits, and the header error correction / check (HEC) field 622 is thirteen bits. Optionally, one or more of the above fields can be larger or smaller.

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

[0058] The report sequence number field 632 can indicate which number in the sequence a message is (e.g., whether there is a sequence of related report messages to determine if a message is lost or out of order). One or more source node virtual output queue (VOQ) status fields 634 can each indicate the status of the source node with respect to a particular function / type of data (e.g., CPU / IO, PLOAM, NMCI, CAN, sensors, Ethernet). The report priority field 636 can indicate what priority is given to a message (e.g., best effort, normal bandwidth request priority, CAN message request priority, power-down alarm request priority).

[0059] Figure 6D and Figure 6E shows a detailed view of two variants of the GEM header format for root port bandwidth authorization messages according to some embodiments. As Figure 6D shown, for a node authorization message where the node ID is the same as the epoch ID, the 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 indicator (FWI) field 650, a burst profile field 652, and a header error correction / check (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 indicator field 650 is one bit, the burst profile field 652 is two bits, and the header error correction / check (HEC) field 622 is thirteen bits. Optionally, one or more of the above fields can be larger or smaller.

[0060] The epoch ID field 638 can be or represent the epoch ID or node ID of the node to which the message is targeted. The start time field 640 can indicate the start time of the authorization window granted to the target node (e.g., the epoch of the node), and 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 reports are 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 tests; in combination with one or more of the following: PLOAM and NMCI reports only CPU-IO messages, CAN messages, and sensor data, and mandatory reports of PLOAM / NMCI; Ethernet packets and mandatory reports of CPU-IO / CAN / sensor and PLOAM / NMCI; and / or mandatory complete reports of PLOAM / NMCI / CPU-IO / CAN / sensor / ethernet and node operation and control report (NOCR). The authorization command field 648 can indicate what type of messages / data are authorized for the burst window. For example, the authorization command field 648 can indicate one or more of the following: the window is not for PLOAM and NMCI messages; the authorization window is only for PLOAM messages; the authorization window is only for NMCI messages; and / or authorization is for PLOAM, NMCI, and NOCR messages. The FWI field 650 indicates whether to force the wake-up of a sleeping node; the burst profile field 652 can indicate the burst configuration (e.g., the length, pattern, and / or other characteristics of the SOB delimiter, EOB delimiter, and / or preamble).

[0061] As Figure 6E shown, for a GEM authorization message where the node ID is different from the epoch ID, except for not having the report command field 646 and the FWI field 650, the header 602 can be substantially the same as Figure 6D the header. Additionally, different from Figure 6D this, the authorization command field 648 can be six bits. Optionally, the authorization command field 648 can be larger or smaller. Also different from Figure 6D this is that the authorization command field 648 can indicate different types of GEM bandwidth authorizations. For example, the field 648 can indicate bandwidth authorizations for the following: only for CAN messages, only for sensor data, only for power-off alarm messages, and / or all VOQ / CoS (class of service) for node-based output scheduling of CAN messages and sensor data. Additionally, the field 648 can force the node ID to save power in the case where the node replies with an acknowledgment message.

[0062] Figure 6FShows a detailed view of the GEM header format for controlling messages according to some embodiments. As Figure 6F shown, the 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 / check (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 are a total of forty-five bits, and the header error correction / check (HEC) field 622 is thirteen bits. Optionally, one or more of the above fields can be larger or smaller.

[0063] The control message type field 654 can indicate what type of control message the message is (e.g., so that the control message fields 656 and their offsets are known for processing). In some embodiments, the control message type field 654 indicates one or more of the following: report confirmation message; CAN confirmation message; flow control message; power saving message; and IO event message (e.g., power-off alarm); runtime status message; and / or timestamp update (e.g., from port to node). The control message fields 656 can include various control message fields based on the control message type (as shown in the control message type field 654).

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

[0065] Burst / Broadcast Frame Format

[0066] In some embodiments, the broadcast message is formatted as a Broadcast-PHY-Frame defined by a Preamble + Start-of-Frame-Delimiter + Frame-Payload, where the Frame-Payload includes a plurality of GEM-Packet data and GEM-Control messages. The Broadcast-PHY-Frame can have a fixed frame size (e.g., between 25 μs and 125 μs). Optionally, larger or smaller frame sizes can be used. For example, for a central network 206 and subnet 210 with fewer node devices 204, 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 a root port 230 to gates 202 and / or nodes 204, 208, 234 over networks 206, 210 including optical fiber, copper cable, and wireless networks.

[0067] In some embodiments, the burst message is formatted as a Burst-PHY-Frame defined by a Preamble + Start-of-Frame-Delimiter + Frame-Payload + End-of-Frame-Delimiter, where the Frame-Payload includes one or more GEM-Packet data and GEM-Control messages. The size of the Burst-PHY-Frame can vary according to the size of the total burst window 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 constructed 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 over networks 206, 210 including optical fiber, copper cable, and wireless networks.

[0068] Figure 7A A Broadcast-PHY-Frame 700 according to some embodiments is shown. As Figure 7AAs shown, Broadcast-PHY-Frame 700 includes a Physical Synchronization Block for Broadcast (PSBbc) 702 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) tail 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 Burst-PHY-Frame 710 according to some embodiments is shown. As Figure 7B shown, Burst-PHY-Frame 710 includes a Physical Synchronization Block Unicast Start of Burst Delimiter (PSBuc_sd) 712, a Burst Framing Sublayer (FS) 714, and a Physical Synchronization Block Unicast End of Burst Delimiter (PSBuc_ed) 716. PSBuc_sd 712 can include a preamble 718 and a Start of Burst (SOB) delimiter 720, and PSBuc_ed 716 can include an End of Burst (EOB) delimiter 722. The burst FS 714 can include an FS header 724, one or more epochs 726, and an FS tail 708. Each epoch 726 can include one or more GEM data packets 600 having a header 602 and a payload 604 as described above. In some embodiments, the burst FS frame is FEC protected. In particular, by including (in addition to the SOB delimiter and the size of the frame) an EOB delimiter, structure 710 enables a sniffer, an analysis engine, or other elements to monitor the traffic within bus 104, even if the size of the frame is not known / accessed, and it enables the elements to determine the end of each burst frame based on the EOB delimiter.

[0069] Figure 7C Gated Burst-PHY-Frame 728 according to some embodiments is shown. As Figure 7C shown, Gated Burst-PHY-Frame 728 can include one or more Burst-PHY-Frames 710 that are combined together into a single combined burst-PHY-frame having 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 IO ports 99 (which act as virtual nodes), and combine these frames 728 into a single combined burst-PHY-frame as Figure 7CThe combined gate Burst-PHY-Frame728 shown. As a result, system 100 provides the following advantages: more efficient message communication through combined burst frames, and less overhead per frame by using only a single preamble for the combined frame as a whole instead of a separate preamble for each combined burst frame (each of which can be up to 256 bytes or more).

[0070] Figure 8 Shows an operating method of the intelligent controller and the sensor intranet bus 103 according to some embodiments. As Figure 8 shown, at step 802, one or more nodes 204, 208 input one or more messages from one or more devices 102 coupled to one or more ports 99. At 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 a node 234 within the core 200, then at step 806, the core de-encapsulates, processes, and transmits the message to its destination without re-encapsulation. Otherwise, if the destination of the input message is one or more other nodes 204, 208 (outside the core 200), then at step 808, the core 200 de-encapsulates, processes, and re-encapsulates the message back into GEM format for broadcasting to its destination. At step 810, nodes 204, 208 de-encapsulate the messages received from the core 200 from GEM format into the original format of the input data received from one of the devices 102. Optionally, if the input messages are input from a node 234 within the core 200, they can be input and processed by the core 200 (without encapsulation), and if their destination is one or more nodes 204, 208 outside the core 200, they are only encapsulated by the core 200 for broadcasting. Thus, the method provides the following advantages: the ability to communicate many different types of data (e.g., sensor, controller bus, Ethernet, or other types of data), more efficient message communication through combined burst frames, and less overhead per frame by using only a single preamble for the combined frame as a whole instead of a separate preamble for each combined burst frame.

[0071] core

[0072] The kernel 200 may include a kernel switch 228, one or more root ports 230 (internal ports), a central processing unit 232, and one or more kernel nodes 234 having IO ports 99 (external ports). In some embodiments, the kernel 200 further includes a secure memory (e.g., Secure Digital (SD) memory) node 236 for storing data in a black box memory 238. Optionally, the SD node 236 and / or the memory 238 may be omitted. The kernel node 234 enables a user to directly connect a user plug-in module (e.g., a CPU core, WIFI LTE / 5G, a user application software) to the kernel 200 by bypassing the networks 206, 210.

[0073] The kernel switch 228 includes a forwarding engine element, a queuing buffer manager, and a traffic manager. The forwarding engine element may include multiple forwarding engines. For example, the 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, 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 functions to protect the bus 104 from external Internet DOS attacks. The GEM queuing buffer manager may be a centralized buffering architecture that uses a linked list-based buffer and queuing storage method combining store-and-forward and cut-through forwarding schemes. For latency-sensitive GEM packets and GEM messages, the cut-through forwarding scheme may be used; while for congested GEM packets, the store-and-forward scheme may be used. The two schemes can be dynamically mixed together and dynamically switched between each other according to the runtime traffic congestion situation. The GEM traffic manager supports dual token policing, single token rate limiting, and output shaping functions for the GEM-ID and NODE-ID libraries, including related Management Information Base (MIB) counters. It can support GEM-ID library Weighted Random Early Detection (WRED) and tail drop functions, as well as early traffic congestion detection and indication and feedback mechanisms to notify the Hybrid Dynamic Bandwidth Allocation (HDBA) mechanism, the root port 230, the gates 202 and nodes 204, 208, 234 to slow down traffic transmission to avoid traffic congestion.

[0074] Accordingly, the kernel switch 228 can provide ingress functionality where the switch 228 receives GEMs from one or more of the root port 230, local node 234, computer 232, and / or other IO ports, processes the GEMs and egresses, forwards and transmits the received GEMs to one or more of the root port 230, local node 234, computer 232, and / or other IO ports. In other words, the switch 228 is capable of receiving GEM packets from multiple sources; performing GEM and Ethernet L2 / L3 / L4 header parsing, L2 MAC lookup and learning, GEM message, and 5-tuple ACL and classification; modifying the GEM header and GEM payload Ethernet header if necessary; and store-and-forwarding (or cut-through buffering) the GEM packets to one or more hybrid automatic repeat request (HARQ) functional blocks and the broadcast MAC of one or more root ports 230.

[0075] When performing this processing and / or forwarding functionality, the switch 228 can support hybrid store-and-forward and cut-through forwarding schemes to reduce propagation latency for latency-sensitive GEMs and provide a large enough buffer for over-burst GEM traffic. Additionally, the switch 228 can support an in-bus 104 immediate flow control mechanism, including hybrid dynamic bandwidth allocation and granting to ensure overall quality of service (QoS) on the bus 104. Further, the switch 228 can support L2 / L3 / L4 ACL and classification, L2 MAC address learning and forwarding, L3 IP address to GEM-ID routing / mapping, and DOS attack protection. Finally, the switch 228 can support QoS scheduling, GEM buffer WRED / tail drop, node, and / or GEM policing and output shaping functionality.

[0076] Root port

[0077] The root port 230 may include a root transmit MAC, a root receive MAC, a security engine (such as the Advanced Encryption Standard (AES)), a Forward Error Correction (FEC) engine, a Hybrid Dynamic Bandwidth Allocation (HDBA) engine, an activation processor (such as an activation state machine), and a burst mode SERDES IP. Optionally, one or more of the above elements may be omitted. The transmit MAC of each root port 230 is responsible for: receiving GEMs to be transmitted by the switch 228 and / or HARQ ready; mapping and packing the GEMs into a broadcast frame format (such as the Broadcast Physical Layer Frame structure); and broadcasting the GEMs to all gates 202 and / or nodes 204 (such as via the root SERDES and the optical / copper cable network broadcast domain) in the central transmission network 206 to which the root port 230 is connected. Conversely, the receive MAC of each root port 230 is responsible for: receiving GEMs in burst frame format (such as the Burst-PHY-Frame structure) from the burst mode SERDES and gates 202 and / or nodes 204, 208; extracting the GEMs from the burst frame format, parsing the GEM headers of the GEMs, and receiving the GEMs addressed to the GEM headers (such as based on the GEM headers and the system Service Level Agreement (SLA) profile settings), and then outputting the GEM / data to the switch 228 for further processing and forwarding. In other words, each root port 230 is capable of receiving burst traffic from nodes 204 and / or gates 202 (forwarded from nodes 208 in the subnet 210 of gate 202), converting the burst traffic into the correct format for processing by the switch 228, and then reformatting and broadcasting the output traffic (via gate 202) to all nodes 204 and nodes 208 to reach the destination indicated by the switch 228.

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

[0079] The root activation state machine is responsible for exchanging Physical Layer Operations, Administration and Maintenance (PLOAM) GEM messages between the nodes 204, 208, 234 and the root port 230, and performing and completing the activation and registration of the node 204, 208, 234 devices through the activation process and procedures. The security engine can be an AES-128 / 256 encryption and decryption functional block for receiving and sending MACs. Optionally, other encryptions can also be used. The Forward Error Correction (FEC) engine is used to control errors in data transmission through unreliable or noisy communication channels. In some embodiments, the FEC engine uses Reed-Solomon FEC coding schemes of RS(255,216) and RS(225,232) for 10G and 2.5G data rates respectively. Optionally, the FEC engine can use user Low-Density Parity-Check (LDPC) schemes and / or other FEC algorithms. The burst mode SERDES uses a fast Clock and Data Recovery (CDR) lock mode to ensure proper receipt of appropriate burst messages (e.g., burst-PHY-Frame). In some embodiments, the fast lock function of the CDR is required in fiber-cut, fast fail-over, and protection flip recovery.

[0080] Finally, after the registration process, root port 230 receives broadcast Data Distribution Service (DDS) messages from nodes 204, 208, which notify root port 230 that new nodes / devices have joined and registered to bus 104. Accordingly, root port 230 is configured to always listen for and receive these Data Distribution Service (DDS) messages from switch 228 and new nodes 204, 208 that claim to join bus 104, and update the root port SLA profile database and settings to reflect the newly added nodes / devices.

[0081] node

[0082] Within bus 104, edge nodes 204, 208, 234 provide a bridging function, interfacing with external device 102 via IO ports 99 on one side and connecting to the bus internal network 104 on the other side. To provide data to devices 102 connected to port 99 of nodes 204, 208, nodes 204, 208, 234 construct and send burst messages (e.g., Broadcast-PHY-Frame of data encapsulated as GEM) via bus 104 and through root port 230 (of the network 206 or its subnet 210 to which they belong) to other nodes 204, 208. Additionally, to provide data to devices 102 connected to port 99 of nodes 204, 208, nodes 204, 208, 234 receive broadcast messages (e.g., Broadcast-PHY-Frame of data encapsulated as GEM) from other nodes 204, 208 through root port 230 (of the network 206 or its subnet 210 to which they belong), extract data from the broadcast messages (e.g., GEM from RX BC-PHY-Frame), and filter and receive data belonging to (addressed to) nodes 204, 208.

[0083] To perform these and other functions, edge nodes 204, 208 may include one or more IO ports 99, an encapsulation / decapsulation engine, a HARQ block, and a node MAC. Each port 99 may be one of a CPU interface (e.g., PCIe, SB, 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), I2C, ADC, and GPIO). The encapsulation / decapsulation engine receives input data from port 99 and encapsulates packets, commands (CMD), and messages received from an Internet port (e.g., Ethernet, Wi-Fi), a sensor interface, a motor module interface, and a CPU (e.g., PCIe and USB) into GEM format at the ingress. Subsequently, nodes 204, 208 may output the encapsulated messages (e.g., GEM) to HARQ and / or the node transmission MAC (described below). At the egress, it receives GEM packets from the node MAC (received from root port 230 and / or another node 204, 208, 234) and decapsulates the GEM back to the original data format (such as the data format received from attached device 102) to output to device 102 through one of the ports 99. Similar to root port 230, the HARQ of nodes 204, 208 performs a hybrid automatic repeat request function to ensure successful transmission of GEM packets to one or more destination nodes 204, 208, 234. Specifically, the HARQ may be built with a retransmission timer, a transmitted GEM list flag table, and a received acknowledgment check function (e.g., GEM receive acknowledgment) to trigger GEM retransmission in case of a timer timeout without receiving an acknowledgment.

[0084] The node MAC includes a transmit MAC (TX MAC), a receive MAC (RX MAC), a security engine (e.g., AES), a forward error correction (FEC) engine, a DBA-report engine, and SERDES IP. The TX MAC is responsible for mapping / packaging GEM into a burst structure (e.g., Burst-PHY-Frame structure) and sending burst messages to the root port 230 and / or nodes 204, 208, 234 during the burst window of the node authorized by the dynamic burst allocation engine of the root port 230. The RX MAC is responsible for receiving and terminating broadcast messages (e.g., Broadcast-PHY-Frame) from the root port 230 and / or nodes 204, 208, 234, extracting GEM from the broadcast message format, parsing and receiving GEM addressed to the root port 230 and / or nodes 204, 208, 234 (e.g., addressed to a port 99 of the root port 230 and / or nodes 204, 208, 234) based on the node-based SLA profile settings, and then outputting the data to the encapsulation / decapsulation engine.

[0085] The DBA report engine reports the total number of data packets and messages in a queue (e.g., EPOCH queue) to the HDBA engine of the associated root port 230 (as described above) through burst reporting. Additionally, the DBA report engine receives GEM-authorization messages from the HDBA of the associated root port 230 and / or the DBA of the associated gate 202, and prepares the node transmit MAC to construct burst messages (e.g., Burst-PHY-Frame) using the GEM stored in the queue (e.g., EPOCH queue).

[0086] The node activation processor is responsible for performing and completing the node activation processing and procedures between nodes 204, 206, 234 and the root port 230. The security engine can be an AES-128 / 256 encryption and decryption functional block for both the receive MAC and the transmit MAC. Optionally, other encryption can also be used. The FEC engine is used to control errors in data transmission through unreliable or noisy communication channels. In some embodiments, the FEC engine uses Reed-Solomon FEC coding schemes of RS(255,216) and RS(225,232) for 10G and 2.5G data rates respectively. The burst-mode SERDES uses a fast clock and data recovery (CDR) lock mode to ensure fast fiber cut-off, fast failover, and protection flip-chip recovery.

[0087] Finally, after the activation process (e.g., after the registration process is completed), nodes 204, 206, 234 can broadcast DDS messages to the entire bus 104 to notify and inform the root port 230, switch 228, door 202, and / or other nodes 204, 206, 234 that a new device has been joined and registered with the bus 104 at nodes 204, 208, 234. Additionally, nodes 204, 206, 234 can listen for DDS messages from switch 228 and other new nodes 204, 206, 234 that claim to have joined the bus 104, and update their global SLA profile database and settings based on the DDS messages.

[0088] Door

[0089] Door 202 may include a node MAC (with multiple virtual node state machines and buffering), an adaptive domain bridge (ADB), a root port MAC (with built-in door DBA function / door DBA), a door SLA profile database, and a burst mode SERDES. The node MAC includes one or more of 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 groups (e.g., one group for each node within subnet 210), virtual node profile and settings, and associated MIB counters and reporting logic. The transmit MAC receives a GEM from the door ADB, then maps and packages it into its associated virtual node burst structure (e.g., Burst-PHY-Frame structure) based on the door's virtual node SLA profile database settings. Additionally, the transmit MAC aggregates multiple virtual node burst structures (e.g., Burst-PHY-Frame) into one door burst structure (e.g., GATE / Turbo Burst-PHY-Frame), and sends the burst message to the root port 230 through network 206, based on the authorized burst window received from the HDBA of the root port 230 for those nodes 208. The node receive MAC receives a broadcast message (e.g., Broadcast-PHY-Frame) from the root port 230, extracts the GEM from the message, parses the GEM header, determines which messages are for the nodes 208 within subnet 210 of door 202 based on the GEM header and the virtual node SLA profile database settings, and outputs these messages to the ADB.

[0090] ADB performs a bridging function between the node MAC and the root MAC of door 202. Specifically, in the broadcast direction (from the root port 230 to node 208), ADB receives the MAC receive GEM from the node and performs a GEM header lookup, and performs a check and filtering function based on the door virtual node profile database, so as to receive the GEM of node 208 belonging to subnet 210 of door 202. Then ADB can output these GEMs to the root port transmit MAC of door 202. In the burst direction (from node 208 to root port 230), ADB receives the GEM from the root receive MAC, stores the GEM in its associated virtual node buffer memory, and outputs the GEM to the virtual node transmit MAC when the start time of its burst window arrives.

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

[0092] The main function of the gate 202 is to extend the central transmission network 206 of one of the root ports 230 by bridging to one or more subnets 210 (and the nodes 208 therein) through adaptive bridging. In particular, the gate 202 can burst messages from the nodes 208 and / or other gates 202' within its subnet 210 to the root port 230 of the network 206 in which it is located, as if the burst traffic were from a node within the central transmission network 206. Similarly, the gate 202 can broadcast messages received from other nodes 204, 208, 234, switches 228, and / or root ports 230 to the nodes 208 and / or other gates 202' within its subnet 210, as if the nodes 208 and / or other gates 202' were within the central transmission network 206. Thus, while maintaining the burst / broadcast communication method within the central transmission network 206, the gate 202 can also extend the central transmission network 206 to additional nodes 208 and / or different types of subnets 210.

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

[0094] Third, in order to obtain the best throughput bandwidth, high burst bandwidth efficiency, and / or low transmission latency, gate 202 may 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. In particular, this amount of time provides gate 202 with time to receive and format the burst data from node 208 before bursting the data from gate 202 to root port 230 at the moment indicated by the original window authorization message. In fact, by performing this operation simultaneously for 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., GATE Burst-PHY-Frame).

[0095] 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 member list table and know each of the following gates 230 as virtual nodes 208 of a group. Therefore, when node 208 sends a report message (e.g., GEM report) to the HDBA of root port 230, gate 203 can intercept the report message, modify the report message to include GEM data temporarily stored in the virtual node buffer memory of gate 202 (if any), and send a new report message to the HDBA of root port 230. In other words, gate 202 can combine the report messages from the nodes in its subnet 210 to make the report more efficient.

[0096] In addition, when the HDBA of root port 230 is sending an authorization message (e.g., GEM authorization message) to node 208 in subnet 210, since root port 230 knows all nodes 208 in this subnet 210 (e.g., through the 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 in sequential / consecutive order, so that gate 202 can combine and / or burst the burst messages (e.g., burst-PHY-Frame) of all virtual nodes except the first virtual node without each burst message having a preamble. This provides the benefit of reducing preamble overhead and increasing burst bandwidth efficiency (especially for small bursts of GEM control messages).

[0097] In other words, for the data path, Gate 202 receives burst messages (e.g., burst-PHY-frame) from the burst mode SERDES and the remote nodes 208, extracts the GEM from the messages in the MAC received at the root of Gate 202, stores the GEM in its associated virtual NODE buffer memory, and waits for the virtual node burst window authorization to enter from the root port 230 of those virtual nodes 208. Then, Gate 202 can map and pack the stored GEMs for that node 208 and other nodes 208 back into the burst message format, so that in the node transmit MAC of Gate 202, multiple burst messages are aggregated together into a larger burst message. Finally, Gate 202 can send this larger burst message to the SERDES and send it to the root port 230 through the network 206 based on the authorized burst window (e.g., multiple consecutive virtual node burst windows of this Gate 202).

[0098] Now looking at the broadcast direction (e.g., from the root port / switch / kernel to the node / gate), Gate 202 can similarly extend the central network 206 to the subnet 210 while being transparent to both the root port 230 of its network 206 and the nodes 208 in its subnet 210. To achieve this, Gate 202 can act like a virtual node and receive broadcast messages (e.g., Broadcast-PHY-Frame) from the root port 230, extract the GEM from the messages, and discard any GEMs not directed to either the nodes 208 / gates 202' in its subnet 210 (e.g., as indicated by the message header and the gate SLA profile database). Conversely, Gate 202 can use a store-and-forward scheme and / or a cut-through scheme to pack and map the GEMs back into the root port broadcast message structure (e.g., Broadcast-PHY-Frame structure) in the root transmit MAC of Gate 202 and broadcast the new broadcast message to all nodes 208 and / or gates 202' in its subnet 210.

[0099] Data transfer operation

[0100] In operation, the bus 104 operates using a burst / broadcast communication scheme, where all data messages from nodes 204, 208, 234 (and gate 202) are aggregated to the kernel 200 using a burst transmission method, and a transmission window that can be dynamically sized (by the kernel 200) is granted to nodes 204, 208, 234, such that nodes 204, 208, 234 (or gate 202 representing nodes 204, 208, 234) can transmit their data messages as a "burst" within the granted window. If the sending node is in subnet 210, then gate 202 (as the root port of this network 210) receives the burst message from node 208 through subnet 210 and then bursts this message through the central network 206 to the kernel 200 (as if node 208 were part of the central network 206). When performing 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 that may increase latency relative to the central network 206. Even, the above steps can be repeated for gate 202' within subnet 210, which provides a gateway to sub-subnet 210', etc., to support any number of "linked / gated" networks. In addition, during this process, gate 202 can be transparent relative to the kernel 200 and node 208, such that there is no need to address messages to gate 202.

[0101] The kernel 200 receives these messages (from one or more root ports 230 that connect the kernel 200 to each central network 206), processes these messages (including modifying and / or determining the target destinations of these messages), and broadcasts these messages (as well as any messages originating from the kernel 200) to the target nodes 204, 208, 234 (or gate 202 representing the target node 208) on whichever central transmission network 206 it is. Similar to the burst communication above, if the target node 208 is within subnet 210, then gate 202 bridged to this subnet 210 can receive / intercept the message from the kernel and re-broadcast the message to all nodes 208 (and / or gate 202') on subnet 210. For any broadcast message to the target node 204 that is not on subnet 210 (or a subnet of subnet 210), it can be discarded by gate 202 to improve 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 through the network. Thus, all nodes 204, 208, 234 (and gate 202) on each network 206 (as well as subnet 210 connected to network 206) receive all messages broadcast on this network 206 from the kernel 200 and only need to find which messages are directed to nodes 204, 208, 234 (and gate 202), while discarding other messages.

[0102] More specifically, when nodes 204, 208, 234 receive data from one or more external devices 102 through one or more of their IO ports 99, nodes 204, 208, 234 store the data in the GEM-ID queue buffer memory and burst a report message (e.g., GEM-Report) to the root port 230 of the central network 206 in which they are located (either directly or, in the case where one or more gates 202 are in the subnet 210 of the central network 206, through one or more gates 202), 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 gate 202’) in its subnet 210 and aggregate the report messages into a single larger report message, and gate 202 is capable of bursting the single larger report message to the root port 230 more efficiently during the burst windows of those ports 208.

[0103] Meanwhile, nodes 204, 208, 234 are capable of encapsulating the input data into GEM format (segmenting GEMs that exceed a predetermined size into smaller GEMs), encrypting the GEMs using the security keys of nodes 204, 208, 234, updating the HARQ table, and mapping and packing the GEMs into a burst format (e.g., Burst-PHY-Frame format) and performing encoding (e.g., FEC RS(255,216) encoding). Subsequently, after the burst window authorized for each node arrives, the nodes burst the GEMs including the input data to the associated root port 230.

[0104] The HDBA of the root port 230 receives all the report 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-sensitive level, traffic congestion feedback, committed 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 the authorized burst window is determined for one or more nodes 204, 208, the root port 230 broadcasts the window to each node, to the associated central network 206, and / or all nodes 204, 208 in any subnet 210 (through gate 202) with a broadcast authorization message (e.g., GEM authorization). As described above, the broadcast messages from the root port 230 are of the same size, while the burst windows from nodes 204, 208 to the root port 230 can change in size as dynamically allocated by the HDBA.

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

[0106] Upon receiving a burst message that includes a GEM (including input data from an external device 102), the 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. Then, the root port 230 can 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 the switch 228. For each GEM, the switch 228 can then perform a GEM-header lookup, parse and classify the Ethernet L2 / L3 addresses and headers, process the GEM forwarding flow chart and determine the GEM forwarding destination information, store the GEM in (throughput) buffer memory, and output the GEM to the HARQ and the target root port 230 (e.g., the root port 230 whose network 206 or subnet 210 includes the target nodes 204, 208) based on the SLA database QoS output scheduler.

[0107] The root port 230 receives the GEM, performs GEM encryption (e.g., AES-128 / 256 encryption) using the security key of the destination node (or broadcasts the GEM), packages the GEM and maps it to 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 of the root port and its subnet 210. If node 208 is within subnet 210, the gateway 202 to that subnet receives the broadcast message and broadcasts the message to all nodes 208 within subnet 210. In some embodiments, the gateway 202 filters out any broadcast messages that are not for nodes 208 within its subnet 210 (or a subnet of subnet 210) and broadcasts only the broadcast messages for one of those nodes 208. Optionally, the gateway 202 can re-broadcast all broadcast messages to the nodes 208 within the subnet 210 of the gateway 202 without determining whether the message is relevant to one of those nodes 208.

[0108] All nodes 204, 208 monitor the received broadcast messages, process the messages for nodes 204, 208 and discard other messages. Specifically, for the undiscarded messages, nodes 204, 208 decode and correct errors in the message (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 security key of the destination node), unpack the data from the GEM format back to the original IO-Port data format, and output the data through the specified IO port 99 to the external device 102. Thus, the bus 104 and the system 100 provide the following benefits: the ability to combine multiple different networks with different input data, different processing speeds, and data constraints while still maintaining the low latency and high throughput required for a machine automation system. This is a unique intranet system architecture and is specifically defined and optimized for such machine automation applications.

[0109] Figure 4FIG. shows a block diagram of an exemplary computing device 400 configured to implement system 100 according to some embodiments. In addition to the above features, external device 102 may also include some or all of the features of the following device 400. Generally, the hardware structure suitable for implementing computing device 400 includes network interface 402, memory 404, processor 406, I / O device 408 (e.g., reader), bus 410, and storage device 412. Optionally, one or more of the shown components can be removed or replaced by other components known in the art. The choice of the 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 can include a hard disk drive, CDROM, CDRW, DVD, DVDRW, flash card, or any other storage device. Computing device 400 may include one or more network interfaces 402. Examples of network interfaces include network cards connected to Ethernet or other types of LANs. I / O device 408 can include one or more of the following: keyboard, mouse, monitor, display, printer, modem, touch screen, button interface, and other devices. Operating software / application 430 or its functions / modules can be stored in storage device 412 and memory 404 and be processed when the application is typically processed. Computing device 400 can include more or fewer components than Figure 4 shown. In some embodiments, machine automation system hardware 420 is included. Although Figure 4 computing device 400 in includes application 430 and hardware 420 for system 100, system 100 can be implemented on the computing device in hardware, firmware, software, or any combination thereof.

[0110] Figure 5 FIG. shows a method of operating a machine automation system 100 including an intelligent controller and a sensor intranet bus 104 according to some embodiments. As Figure 5As shown, in step 502, nodes 204 and 208 receive input data from a plurality of external devices 102 through one or more ports 99 of bus 104. In step 504, nodes 204 and 208 burst the input data as a burst message in a variable-sized burst window to kernel 200. In some embodiments, for each of nodes 204 and 208, the HDBA of root port 230 dynamically adjusts the burst window start time and size of the variable burst window, and based on the data traffic parameters reported by nodes 204 and 208 therein, allocates the adjusted window to the corresponding nodes 204 and 208 as a broadcast authorization window message. In some embodiments, gate 202 aggregates two or more burst messages including the 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. Thus, before the window authorized by root port 230, node 208 bursts its data to gate 202, enabling 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 nodes 204 and 208 within central network 206 and subnet 210 that need to reach the destination nodes 204 and 208 of the message. In step 508, destination nodes 204 and 208 convert the data of the broadcast message into a format acceptable to devices 102 coupled to nodes 204 and 208 and output the data to devices 102. Thus, the method has the following advantages: enabling bus 104 to maintain high speed despite using a lower-speed network medium.

[0111] System 100 for implementing dynamic burst to broadcast transmission networks and machine automation controller and sensor bus 104 have many advantages. Specifically, the following benefits are provided: simplified cable systems and connections; significantly reduced impact of electromagnetic interference (EMI) by using optical fibers; ensuring low latency for node-to-node communication; high throughput bandwidth (10, 25, 100 or higher Gbps) for transmission from node to node; node-to-node devices can extend up to 20 km; low power consumption achieved due to passive optical network architecture; industrial-grade QoS without traffic congestion achieved due to centralized DBA scheduling mechanism; built-in HARQ mechanism to ensure successful node-to-node and GEM transmission; and a unified software image for the entire intranet system including all gates, nodes, and root ports, thus simplifying the software architecture, shortening the product development cycle, and simplifying system-level debugging, monitoring, and troubleshooting.

[0112] This application has been described in terms of specific embodiments in combination with details to facilitate understanding of the construction and operating principles of the application. The specific embodiments and details herein are not intended to limit the scope of the appended claims. Those skilled in the art should understand that various other modifications can be made based on the selected embodiments without departing from the spirit and scope of the application defined by the claims. For example, although the bus is described as operating within a machine automation system as herein, it should be understood that the bus can operate with 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 comprises: a controller and a sensor bus, which includes a plurality of input / output ports, and a plurality of external machine automation devices, which are operably coupled together through the ports of the bus, wherein the bus includes a central processing core and a multimedia transport intranet, and the multimedia transport intranet includes: one or more central transport networks, which are directly coupled to the core and include a plurality of nodes and one or more gates; and a plurality of subnets, each subnet is respectively coupled to a different gate of the central transport network, and the subnets include a plurality of sub-nodes; wherein each of the nodes and the sub-nodes: is coupled to one or more devices through one or more ports, receives messages from the one or more devices coupled to the one or more ports; encapsulates the messages into a General Encapsulation Mode (GEM) format for transmission to the central processing core; and decapsulates the messages received from the central processing core from the GEM format into the original format of the input data received from one of the devices; wherein the header of the GEM format includes: a source / destination field, which identifies one of the ports as the source of the message, or identifies one or more of the nodes and the sub-nodes as the destination of the message; and a GEM packet identifier field, which identifies one or more of the ports that the message is directed to; wherein, when one of the ports is identified as the source of the message, the value of the source field is selected from a first set of epoch identifier values, and when one or more of the nodes and the sub-nodes are identified as the destination of the message, the value of the destination field is selected from a second set of node identifier values.

2. The system according to claim 1, wherein the value of the GEM packet identifier field is selected from a third set of GEM identifier values, and each of the node identifier values is mapped to one or more of the epoch identifier values, and each of the epoch identifier values is mapped to one or more of the GEM identifier values.

3. The system according to claim 2, wherein, the header of the GEM format includes a GEM packet type field, and the GEM packet type field indicates the original format and the header type of the message encapsulated in the GEM format.

4. The system according to claim 1, wherein the header of the GEM format includes a source identifier field and a report message type field, the source identifier field indicates the source of the message, and the report message type field indicates whether the report data in the message is independent of the source of the message indicated in the source identifier field.

5. The system according to claim 1, wherein, the header of the GEM format includes a start time field and an authorized size field, the start time field indicates the time when the authorized bandwidth window starts, and the authorized size field indicates the size of the authorized bandwidth window.

6. The system according to claim 5, wherein the header in the GEM format includes an authorization command field that indicates one or more types of messages allowed during the authorized bandwidth window.

7. The system according to claim 1, wherein after encapsulating the message into the GEM format, each of the nodes and the child nodes places one or more of the messages in a burst physical layer frame format and transmits the message to the central processing core by bursting the burst physical layer frame including the one or more messages to the central processing core.

8. The system according to claim 7, wherein the burst physical layer frame format includes a separate burst end delimiter for each of the one or more messages, and the separate burst end delimiter indicates the end of one of the one or more messages within the burst physical layer frame.

9. The system according to claim 1, wherein each of the gates aggregates the GEM format messages from multiple child nodes into a single larger message in the burst physical layer frame format.

10. The system according to claim 9, wherein each of the gates omits the preambles of the messages from the multiple child nodes from the single larger message in the burst physical layer frame format.

11. The system according to claim 1, wherein, the device includes one or more of the group consisting of an ultrasonic sensor, a light detection and ranging sensor, an infrared sensor, a camera, a motor, and a microcontroller.

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

13. A controller and a sensor bus, the bus comprising: a plurality of input / output ports for coupling with a plurality of external machine automation devices of a machine automation system, a central processing core; and a multimedia transmission intranet, the multimedia transmission intranet comprising: one or more central transmission networks directly coupled to the core and including a plurality of nodes and one or more gates; and a plurality of subnets, each subnet being respectively coupled to a different gate of the central transmission network, the subnets including a plurality of child nodes, wherein each of the nodes and the child nodes: is coupled to one or more devices through one or more ports, receives messages from the one or more devices coupled to the one or more ports; encapsulates the messages into a General Encapsulation Mode (GEM) format for transmission to the central processing core; and decapsulates the messages received from the central processing core from the GEM format into the original format of the input data received from one of the devices; wherein the header in the GEM format includes: a source / destination field that identifies one of the ports as the source of the message or identifies one or more of the nodes and the child nodes as the destination of the message; and a GEM packet identifier field that identifies one or more of the ports that the message is directed to. Wherein, when one of the ports is identified as the source of the message, the value of the source field is selected from a first set of epoch identifier values, and when one or more of the nodes and the child nodes are identified as the destination of the message, the value of the destination field is selected from a second set of node identifier values.

14. The bus according to claim 13, wherein the value of the GEM packet identifier field is selected from a third set of GEM identifier values, and each of the node identifier values is mapped to one or more of the epoch identifier values, and each of the epoch identifier values is mapped to one or more of the GEM identifier values.

15. The bus according to claim 14, wherein, the GEM format header includes a GEM packet type field, and the GEM packet type field indicates the original format and header type of the message encapsulated within the GEM format.

16. The bus according to claim 13, wherein the GEM format header includes a source identifier field and a report message type field, the source identifier field indicates the source of the message, and the report message type field indicates whether the report data within the message is independent of the source of the message indicated in the source identifier field.

17. The bus according to claim 13, wherein, the GEM format header includes a start time field and an authorization size field, the start time field indicates the time when the authorized bandwidth window starts, and the authorization size field indicates the size of the authorized bandwidth window.

18. The bus according to claim 17, wherein the GEM format header includes an authorization command field, and the authorization command field indicates one or more types of messages allowed during the authorized bandwidth window.

19. The bus according to claim 13, wherein after encapsulating the message into the GEM format, each of the nodes and the child nodes places one or more of the messages in a burst physical layer frame format, and transmits the message to the central processing core by bursting the burst physical layer frame including the one or more messages to the central processing core.

20. The bus according to claim 19, wherein the burst physical layer frame format includes a separate burst end delimiter for each of the one or more messages, and the separate burst end delimiter indicates the end of one of the one or more messages within the burst physical layer frame.

21. The bus according to claim 13, wherein each of the gates aggregates GEM format messages from a plurality of the child nodes into a single larger message in a burst physical layer frame format.

22. The bus according to claim 21, wherein each of the gates omits the preambles of the messages from the plurality of child nodes from the single larger message in the burst physical layer frame format.

23. The bus according to claim 13, wherein, the device includes one or more of the group consisting of an ultrasonic sensor, a light detection and ranging sensor, an infrared sensor, a camera, a motor, and a microcontroller.

24. The bus according to claim 13, wherein, The automated machine is one of a group consisting of a robot and an autonomous vehicle.

25. A method of operating a controller and a sensor bus, the controller and sensor bus including a plurality of input / output ports for coupling to a plurality of external machine automation devices of a machine automation system, a central processing core, and a multimedia transport intranet; the multimedia transport intranet including one or more central transport networks and a plurality of subnets; the one or more central transport networks being directly coupled to the core and including a plurality of nodes and one or more gates ； Each of the plurality of subnets is respectively coupled to a different gate of the central transport network, the subnets including a plurality of sub-nodes, the method including: One or more of the nodes and the sub-nodes: Receiving a message from one or more devices coupled to one or more ports associated with the one or more nodes and sub-nodes; Encapsulating the message into a General Encapsulation Mode (GEM) format for transmission to the central processing core; and De-encapsulating a message received from the central processing core from the GEM format into the original format of the input data received from one of the devices; Wherein the header of the GEM format includes: A source / destination field that identifies one of the ports as the source of the message, or identifies one or more of the nodes and the sub-nodes as the destination of the message; and A GEM packet identifier field that identifies one or more of the ports that the message is directed to; Wherein, when one of the ports is identified as the source of the message, the value of the source field is selected from a first set of epoch identifier values, and when one or more of the nodes and the sub-nodes are identified as the destination of the message, the value of the destination field is selected from a second set of node identifier values.

26. The method according to claim 25, wherein the value of the GEM packet identifier field is selected from a third set of GEM identifier values, and each of the node identifier values maps to one or more of the epoch identifier values, and each of the epoch identifier values maps to one or more of the GEM identifier values.

27. The method according to claim 26, Wherein, The header of the GEM format includes a GEM packet type field that indicates the original format and header type of the message encapsulated within the GEM format.

28. The method according to claim 25, wherein the header of the GEM format includes a source identifier field and a report message type field, the source identifier field indicating the source of the message, and the report message type field indicating whether the report data within the message is independent of the source of the message indicated in the source identifier field.

29. The method according to claim 25, Wherein, The header of the GEM format includes a start time field and an authorized size field, the start time field indicating the time at which an authorized bandwidth window begins, and the authorized size field indicating the size of the authorized bandwidth window.

30. The method according to claim 29, wherein the GEM - formatted header includes an authorization command field, and the authorization command field indicates one or more types of messages allowed during the authorized bandwidth window.

31. The method according to claim 25, further comprising, after encapsulating the message into the GEM format, placing one or more of the messages in a burst physical - layer frame format by each of the nodes and the sub - nodes, and transmitting the message to the central processing core by bursting the burst physical - layer frame including the one or more messages to the central processing core by each of the nodes and the sub - nodes.

32. The method according to claim 31, wherein the burst physical - layer frame format includes a separate burst - end delimiter for each of the one or more messages, and the separate burst - end delimiter indicates the end of one of the one or more messages within the burst physical - layer frame.

33. The method according to claim 25, further comprising aggregating GEM - formatted messages from a plurality of the sub - nodes into a single larger message in a burst physical - layer frame format by each of the gates.

34. The method according to claim 33, further comprising omitting, by each of the gates, the preambles of the messages from the plurality of sub - nodes from the single larger message in the burst physical - layer frame format.

35. The method according to claim 25, wherein, the device includes one or more of the group consisting of an ultrasonic sensor, a light detection and ranging sensor, an infrared sensor, a camera, a motor, and a microcontroller.

36. The method according to claim 25, wherein, the automated machine is one of the group consisting of a robot and an autonomous vehicle.

Images