CN112912809A

CN112912809A - Intelligent controller including universal packaging mode and sensor network bus, system and method

Info

Publication number: CN112912809A
Application number: CN202080004552.3A
Authority: CN
Inventors: 尤金·李
Original assignee: Pengyan Technology Shanghai Co ltd
Current assignee: Pengyan Technology Shanghai Co ltd
Priority date: 2019-09-16
Filing date: 2020-09-09
Publication date: 2021-06-04
Also published as: WO2021055205A1

Abstract

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

Description

Intelligent controller including universal packaging mode and sensor network bus, system and method

Cross-referencing

This application is a continuation of part of a co-pending U.S. patent application entitled "intelligent controller and sensor network bus, system, and method", filed 2019, 8/1, application No. 16/529,682, which is incorporated herein by reference.

Technical Field

The present application relates to the field of buses. More particularly, the present application relates to controller and sensor network bus architectures.

Background

With the development of autonomous cars, intelligent robots and factory automation, the field of machine automation is expanding rapidly. However, due to their diverse and high-speed requirements, no bus or network architecture is currently available that can effectively meet all of the requirements of these emerging technologies. On the contrary, the current network has high delay, low bandwidth, complex wiring, large electromagnetic interference (EMI), high cost, unsafe data and complex system integration. For example, networks do not have sufficient speed and throughput to carry sensor data, such as camera and laser radar (LIDAR) data, over the network to the CPU core. Furthermore, existing cable systems are complex, short-range, and cannot handle EMI without expensive shielding due to the use of copper cabling systems. There is currently no multi-function integrated "controller and sensor network" system bus solution to be able to 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.

Disclosure of Invention

The present application provides a machine automation system for controlling and operating an automation machine. The system includes a controller and a sensor bus including a central processing core and a multimedia transmission intranet for implementing dynamic burst (burst) for a broadcast transmission scheme, wherein messages are burst from a node to the central processing core and broadcast from the central processing core to all nodes.

A first aspect of the present application relates to a machine automation system for controlling and operating an automation machine. The system comprises: a controller and 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. Wherein, the bus includes central processing core and multimedia transmission intranet, and this multimedia transmission intranet includes: one or more central transport networks directly coupled with the core and including a plurality of nodes and one or more gates; and a plurality of sub-networks respectively coupled to different gates of the central transport network, the sub-networks comprising a plurality of sub-nodes, wherein each node and sub-node is coupled to one or more devices through one or more ports, receiving messages from the one or more devices coupled to the one or more ports; encapsulating the message into a Generic Encapsulation Mode (GEM) format for transmission to a central processing core; and decapsulating the 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.

In some embodiments, the header of the GEM format includes: a source/destination field that identifies one of the ports as a source of the message or one or more nodes and child nodes as a destination of the message; and a GEM packet identifier field that identifies one or more ports to which the message is directed. In some embodiments, when one of the ports is identified as a source of a message, a value of a source field is selected from a first set of epoch (epoch) identifier values, and when one or more nodes and child nodes are identified as a destination of the message, a value of a 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 the third set of GEM identifier values, and each node identifier value maps to one or more epoch identifier values, each epoch identifier value maps 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 the header type of the message encapsulated within the GEM format. In some embodiments, the GEM format header includes a source identifier field that indicates the source of the message and a report message type field that indicates whether the report data within the message is independent of the source of the message indicated in the source identifier field.

In some embodiments, the header of the GEM format includes a start time field indicating a time when the authorized bandwidth window starts and a grant size field indicating a size of the authorized bandwidth window. In some embodiments, the header of the GEM format 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 a GEM format, each node and child node places one or more messages in a burst physical layer frame format and transmits the message to the central processing core by bursting a burst physical layer frame including the one or more messages to the central processing core. In some embodiments, the burst physical frame format includes a separate end-of-burst delimiter for each of the one or more messages, the separate end-of-burst delimiter indicating an end of one of the one or more messages within the burst physical layer frame. In some embodiments, each gate aggregates messages in GEM format from multiple child nodes into a single larger message in burst physical layer frame format. In some embodiments, each gate omits preambles for messages from multiple child nodes from a single larger message in a burst physical layer frame format. In some embodiments, the apparatus comprises 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.

A 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 with a plurality of external machine automation devices of the machine automation system, a central processing core, and a multimedia transport intranet. The multimedia transport intranet includes one or more central transport networks directly coupled with the core and including a plurality of nodes and one or more gates; and a plurality of sub-networks respectively coupled to different gates of the central transport network, the sub-networks comprising 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; encapsulating the message into a Generic Encapsulation Mode (GEM) format for transmission to a central processing core; and decapsulating the 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.

In some embodiments, the header of the GEM format includes: a source/destination field that identifies one of the ports as a source of the message or one or more nodes and child nodes as a destination of the message; and a GEM packet identifier field that identifies one or more ports to which the message is directed. In some embodiments, when one of the ports is identified as a source of the message, a value of the source/destination field is selected from a first set of epoch identifier values, and when one or more nodes and children are identified as a destination of the message, a 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 the third set of GEM identifier values, and each node identifier value maps to one or more epoch identifier values, each epoch identifier value maps 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 the header type of the message encapsulated within the GEM format. In some embodiments, the GEM format header includes a source identifier field that indicates the source of the message and a report message type field that indicates whether the report data within the message is independent of the source of the message indicated in the source identifier field.

A third aspect of the present application relates to a method of operation of a controller and a sensor bus. The controller and sensor bus includes a plurality of input/output ports for coupling with a plurality of external machine automation devices of the machine automation system, a central processing core; and a multimedia transport intranet comprising one or more central transport networks directly coupled with the kernel and comprising a plurality of nodes and one or more gates; and a plurality of sub-networks respectively coupled to different gates of the central transport network, the sub-networks including a plurality of sub-nodes. The method comprises the following steps: receiving, by one or more nodes and child nodes, messages from one or more devices coupled to one or more ports associated with the one or more nodes and child nodes; encapsulating the message into a Generic Encapsulation Mode (GEM) format for transmission to a central processing core; and decapsulating the 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.

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 to which the message is directed. In some embodiments, when one of the ports is identified as a source of the message, a value of the source/destination field is selected from a first set of epoch identifier values, and when one or more nodes and children are identified as a destination of the message, a 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 the third set of GEM identifier values, and each node identifier value maps to one or more epoch identifier values, each epoch identifier value maps 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 the header type of the message encapsulated within the GEM format. In some embodiments, the GEM format header includes a source identifier field that indicates the source of the message and a report message type field that indicates whether the report data within the message is independent of the source of the message indicated in the source identifier field.

In some embodiments, the header of the GEM format includes a start time field indicating a time when the authorized bandwidth window starts and a grant size field indicating a size of the authorized bandwidth window. In some embodiments, the header of the GEM format 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 placing the one or more messages in a burst physical layer frame format with each node and child node after encapsulating the message into a GEM format, and transmitting the message to the central processing core by bursting a burst physical layer frame including the one or more messages to the central processing core with each node and child node. In some embodiments, the burst physical frame format includes a separate end-of-burst delimiter for each of the one or more messages, the separate end-of-burst delimiter indicating an end of one of the one or more messages within the burst physical layer frame. In some embodiments, the method further includes aggregating messages in GEM format from multiple child nodes into a single larger message in burst physical layer frame format with each gate. In some embodiments, the method further comprises omitting, with each gate, preambles of messages from multiple child nodes from a single larger message in a burst physical layer frame format. In some embodiments, the apparatus comprises 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.

Drawings

FIG. 1 illustrates a machine automation system according to some embodiments.

FIG. 2 illustrates an intelligent controller and sensor intranet bus according to some embodiments.

FIG. 3 illustrates a tree topology of an intelligent controller and sensor intranet bus according to some embodiments.

FIG. 4 illustrates a block diagram of an exemplary computing device for implementing a system in accordance with some embodiments.

FIG. 5 illustrates a method of operation of a machine automation system including an intelligent controller and a sensor intranet bus in accordance with some embodiments.

FIG. 6A illustrates an exemplary GEM packet format in accordance with some embodiments.

Fig. 6B illustrates a detailed view of a GEM packet header format according to some embodiments.

Fig. 6C illustrates a detailed view of a GEM header format for a node report message according to some embodiments.

Fig. 6D illustrates a detailed view of a first variation of the GEM header format for a root port bandwidth grant message according to some embodiments.

Fig. 6E shows a detailed view of a second variation of the GEM header format for a root port bandwidth grant message according to some embodiments.

Fig. 6F illustrates a detailed view of a GEM header format for a control message according to some embodiments.

FIG. 7A illustrates a Broadcast-PHY-Frame according to some embodiments.

FIG. 7B illustrates a Burst-PHY-Frame according to some embodiments.

FIG. 7C illustrates a gate Burst-PHY-Frame according to some embodiments.

FIG. 8 illustrates a method of operation of an intelligent controller and sensor intranet bus according to some embodiments.

Detailed Description

Embodiments described herein relate to machine automation systems, methods, and devices for controlling and operating automation machines. The system, method and apparatus include a controller and a sensor bus including a central processing core and a multimedia transmission intranet for implementing dynamic bursts for broadcast transmission schemes. Where messages are bursty from node to central processing core and broadcast from central processing core to all nodes. Thus, the system, method and apparatus, while incorporating low speed network media, still have the advantage of high speed performance; the system, method and apparatus also provide a unified software image of the complete intranet system including all gates, nodes and root ports, thereby enabling a simplified software architecture, shorter product development cycles, and easier system level debugging, remote monitoring and troubleshooting. In particular, the systems, methods, and devices provide a unique intranet system architecture specifically defined and optimized for machine automation applications.

FIG. 1 illustrates a machine automation system 100 according to some embodiments. As shown in FIG. 1, the system 100 includes one or more external devices 102, the one or more external devices 102 operatively coupled with an intelligent controller and sensor intranet bus 104. In some embodiments, the system 100 may be part of an automated device (such as an autonomous vehicle, an automated industrial machine, or an automated robotic robot). Alternatively, the system 100 may be part of other machine automation applications. Device 102 may include one or more of a sensor device (e.g., ultrasound, infrared, camera, LIDAR (LIDAR), SONAR (SONAR), magnetic, RADAR (RADAR)), an internet appliance, a motor, an actuator, a light, a display (e.g., screen, user interface), a speaker, a graphics processing unit, a central processing unit, memory (e.g., solid state drive, hard drive), and a controller/microcontroller. Each device 102 may be operatively wired and/or wirelessly connected to bus 104 via one or more bus input/output (IO) ports (see fig. 2). Although the system 100 includes discrete quantities of external devices 102 and buses 104 as shown in fig. 1, more or fewer devices 102 and/or buses 104 are contemplated.

FIG. 2 illustrates an intelligent controller and sensor intranet bus 104 according to some embodiments. As shown in fig. 2, bus 104 includes an intranet formed by a central core 200 coupled to one or more gates 202, a plurality of edge nodes 204 (each edge node 204 having one or more external IO ports 99), and one or more edge sub-nodes 208 (each edge sub-node 208 having one or more external IO ports 99) by one or more subnets 210 extending from gates 202. Thus, as shown in FIG. 3, the bus 104 forms a network tree topology in which the central network 206 branches from the central core 200 (e.g., the root port 230 of the core) to the edge nodes 204 and the gates 202, and the sub-network 210 branches from the gates 202 to the sub-nodes 208 and/or sub-gates 202'. In this manner, central core 200 may view all nodes 204 and child nodes 208 (because gates 202 and child gates 202' are transparent to central core 200). In some embodiments, one or more gates 202 are coupled directly to IO port 99 (e.g., to couple to an external CPU, GPU, AI kernel, and/or Solid State Drive (SSD)) without a node.

Port 99 may be any type of interface port such as peripheral component interconnect express (PCIe), Mobile Industrial 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 the bus 104 includes a discrete number of ports 99, cores 200,

nodes

204, 208, gates 202,

networks

206, 210, other elements and components as shown in FIG. 2, more or fewer ports 99, cores 200,

nodes

204, 208, gates 202,

networks

206, 210, other elements and/or components are contemplated.

The central transport network 206 may include a connection medium, the connection medium of the central transport network 206 being faster/having a lower latency (latency) than the connection medium of the sub-network 210 coupled to the gates 202 of the central transport network 206. Similarly, the subnet 210 can include a connection medium, the connection medium of the subnet 210 being faster/having a lower latency than the connection medium of the subnet 210 'coupled to the gate 202' of the subnet 210; and so on for each iteration subnet. This speed/latency relationship of the network/subnet connection media enables the overall processing of bus 104 to be prevented from slowing despite bus 104 still including a slower connection media, as described in detail below. Optionally, one or more of the subnetworks 210, 210' and/or the central network 206 may have the same or other connection media speed/delay relationships.

In some embodiments, the connection medium of the central transmission network 206 includes a fiber optic cable 212 that is split using a splitter 214 (e.g., a 2-to-1 splitter) and has an optical transceiver 216 to couple to the

nodes

204, 208 and receive data from the

nodes

204, 208. In some embodiments, the connection media of the sub-network 210 includes fiber optic connection media (e.g., similar to that of the central transmission network 206, but perhaps at a lower level), wireless connections (e.g., radio frequency transceiver 218), copper cable connections (e.g., twisted copper pair 220, the twisted copper pair 220 preferably being split using an analog splitter 222 (e.g., fanout exporter/multiplexer) and having a serializer/deserializer (SERDES)224 to couple to the

nodes

204, 208 and receive data from the nodes 204, 208), and/or combinations thereof (e.g., hybrid fiber, copper cable, and/or wireless connection media). Thus, bus 104 supports multi-rate traffic transmission, wherein different nodes/networks can be used to couple to bus 104 depending on latency/speed, connectivity, and/or distance requirements of data/traffic/external device 102, while still providing the required throughput. For example, for high speed, low latency, and long distance requirements, the optical connection medium of the central network may be used by coupling to node 204. Otherwise, other networks 210 may be used depending on cost, speed, connectivity, and/or distance requirements. In some embodiments, central network 206 is a passive optical network and/or copper subnetwork 210 is an active network. In some embodiments, as shown in FIG. 2, one or more of the nodes 204 are coupled to a Controller Area Network (CAN)226 such that each node inputs data from each controller coupled to the controller area network. Alternatively, as shown in fig. 3, one or more of the subnets 210 may be a CAN coupled to the central core 200 through one of the gates 20.

Multi-layer bus addressing

The bus 104 can utilize a multi-layered addressing scheme in which the root port 230, the IO port 99, the

nodes

204, 208, 234, and/or the gate 202 can direct messages through the bus 104 using a node, epoch (epoch), and GEM identification address. In particular, each of the root port 230,

nodes

204, 208, 234, and gate 202 can be assigned a node-ID identifier (node-ID), and the

nodes

204, 208, and gate 202 are also assigned at least one epoch identifier (epoch-ID) and at least one GEM identifier (GEM-ID). The epoch ID can be used to identify the source/destination of the message in the network 206, 210 (e.g., the node/gate device and its IO port, embedded central processor, and/or other type of service), while the GEM-ID can be used to identify the target of the message (e.g., the node/gate device and its IO port, embedded central processor, and/or set and subset of other types of services). Thus, the epoch ID can be used for transmission/routing of messages throughout the

network

206, 210, while the GEM-ID can be used by the device itself (via port 99) to determine whether to capture the received/broadcast message targeted for it.

Nodes/gates can be assigned epoch IDs and GEM-IDs according to the Service Level Agreement (SLA) profile of the node/gate (which can correspond to the equipment coupled to the port 99 of the node/gate). Thus, the node ID of each of the

nodes

204, 208 and the door 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 coupled with 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 a first epoch ID and first port 99, and nine associated with a second epoch ID and second port 99). Furthermore, while the node ID and epoch ID are unique for each node/gate/port, GEM-ID can be shared between nodes/gates/ports. For example, ports 99 of the

same node

204, 208 or different ports 99 of

different nodes

204, 208 can be associated with matching or overlapping sets GEM-IDs.

The door 202 may also be assigned one or more virtual node IDs for the port 99 directly coupled to the door 202. Like conventional nodes, these virtual nodes represented by the doors 202 can be assigned multiple epoch IDs and multiple GEM-IDs according to the SLA profile of the doors 202 (which can correspond to the equipment coupled to the virtual nodes/ports 99 of the doors).

Each other node 234 and core 232 (which is directly coupled to core 200, such as IO devices and embedded central processor cores) can have one or more GEM-IDs as well as global node IDs, but need not be assigned epoch IDs, which is unnecessary because messages to and from these nodes 234 and core 200 are entirely within core 200. Like

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 the devices coupled to port 99 of node 234). Each of kernel switch 220, root port 230,

nodes

204, 208, 234, and/or doors 202 is capable of maintaining and updating a local SLA table indicating a 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 network 100, while using GEM-IDs to facilitate any required more complex messaging between devices/IO ports 99 and/or the cores themselves.

General packaging mode

The bus 104 may encapsulate all incoming data and internally generated data (e.g., control messages, operational messages, and management messages) into a Generic Encapsulation Mode (GEM) for transmission over the bus 104 intranet. Thus, the GEM acts as a unique standardized data and message container for transferring data between nodes and/or to the central core 200 over the bus 104 intranet. Thus, incoming data may be encapsulated into a GEM format at each node upon entering bus 104, and via central core 200 (where it is decapsulated for processing and repackaged for transmission) and arrives at its destination node, which decapsulates the data into its original format for egress to target external device 102 or other destination. The input data may come from various sources (e.g., device 102, CAN 226) input through port 99 and/or embedded CPU core 232 at

node

204, 208, 234 or gate 202.

There are two types of GEM formats: GEM packet (packet) and GEM control (control). The GEM packet format includes a GEM header (header) plus a GEM payload (payload) (e.g., 8 bytes to 4 kilobytes in length). Generally, GEM packet formats are used to encapsulate input port data, packets, and messages at an ingress (e.g., node, port). The following are some examples of IO port data, packets, and messages examples that may utilize the GEM packet format:

using GEM packet format, ethernet packets are carried from the local gate 202 and/or

nodes

204, 208, encapsulated by the bus 104GEM, to the remote gate 202 and/or nodes 204 (e.g., the remote gate 202 and/or nodes 204 can be used for internet and Wi-Fi interfaces through ethernet ports or PCIe ports).

Using GEM packet format, sensor data is encapsulated from local gate 202 and/or node 204, carrying it over bus 104GEM, to remote gate 202 and/or node 204 (e.g., CAN bus data, camera (MIPI) frame data, lidar (ethernet) data, electromagnetic encoder data (ADC), and other types of sensor data).

Using GEM packet format, carry jumbo data and packets from the

local nodes

204, 208 through a fragmentation and defragmentation scheme to the

remote nodes

204, 208. This can include fragmentation, defragmentation, and reordering/re-transmission functions.

Using GEM packet format, network control, operation and management messages are carried between the core 200 and the nodes 204, 208 (and/or gates), including physical layer operations, administration and maintenance (PLOAM), Node Management Control Interface (NMCI) and operation, administration and maintenance (OAM) messages.

Using GEM packet format, from the kernel 200 and local gate 202 and/or node 204, after encapsulating the CPU/PCIe access CMD/DATA with the bus 104GEM, to the remote local gate 202 and/or node 204 (e.g. CPU232 from node to node access target device 102 over PCIe, USB, I2C, UART and GPIO interfaces).

Finally, between the

local nodes

204, 208 and the

remote nodes

204, 208, using GEM packet format, over the bus 104 for VPN tunnel application.

The GEM control message format includes a message and an extension message (e.g., 8 bytes +8 bytes in length). On bus 104, GEM control message formats may be used for internal network management and control purposes, including Dynamic Bandwidth Allocation (DBA) reporting, DBA authorization, GEM Reception (RX) acknowledgement, GEM flow control, GEM power management, GEM sensing, GEM remote messages, and/or other types of control messages. As described above, the node 204 is responsible for encapsulating/decapsulating data into/from the GEM packet format and the GEM control message format. The scheme may extend the PCIe interface protocol from a point-to-point topology to a point-to-multipoint topology and extend the interface distance from short distances to long distances.

Fig. 6A-F illustrate exemplary GEM packet formats and GEM header formats in accordance with some embodiments. As shown in fig. 6A, GEM packet 600 can include a header 602 and a corresponding payload 604. As described above, for message data packets, the header can be a fixed size (e.g., 8 bytes), the payload can vary in length (e.g., from 8 bytes to 4 kilobytes in length), and for control data packets, the header can be, for example, 8 bytes, with or without one or more 8 byte extensions.

Fig. 6B illustrates a detailed view of a GEM packet header format according to some embodiments. As shown in fig. 6B, 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 required for acknowledgement 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, GEM type field 606 is two bits, payload length indication field 608 is twelve bits, encryption key index field 610 is two bits, node/epoch ID field 612 is twelve bits, GEM-ID field 614 is twelve bits, GEM packet type field 616 is three bits, transport sequence identifier field 618 is six bits, acknowledgement required field 620 is one bit, last fragment indication field 622 is one bit, and header error correction/check (HEC) field 622 is twelve bits. Optionally, one or more of the above fields may be larger or smaller.

The GEM type field 606 indicates which type of header 602 of the GEM packet 600 is (and thus which type of packet). For example, the GEM type field can indicate that the header 602 is one or more of a data packet header, a bandwidth grant 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, the gate 202, and/or one or more of the

nodes

204, 208, 234). The payload length indication field 608 indicates the length of the payload 604 of the data packet 600. Encryption key index field 610 indicates the type of encryption used on data 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: whether to encrypt the data packet, which key to use to encrypt the data packet, and/or which encryption method to use.

Node/epoch ID field 612 is capable of identifying a source node or a destination node of data packet 600. For example, for a GEM packet 600 that is bursty from node to core, field 612 can be or represent the epoch ID of the node to indicate the source of packet 600. As another example, for GEM packets 600 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). GEM-ID field 614 may be or represent a data/packet/message identifier of a source node of a point-to-point message or may be or represent a GEM-ID of a 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: the bus 104 is enabled 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 be identified using the GEM-ID field 614.

GEM packet type field 616 can indicate the type and format of the header of the message encapsulated within the GEM format (e.g., received from device 102 and/or through 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 acknowledgement required field 620 can indicate whether an acknowledgement message in response to the message is required; the transmit sequence identifier field 618 can identify the transmit sequence number of a packet 600 (for packets bursty from a node to the core 200) within a group of packets from the source node and/or its epoch ID. In some embodiments, an acknowledgement message from the receiving root port 230 is required, as indicated by the acknowledgement required field 620. 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, an acknowledgement from the receiving root port 230 and/or node is required, as indicated by the acknowledgement required field 620. The last segment indication field 622 can indicate whether the data packet 600 is the last segment in a series of segments of a large data packet, and the header error correction/check (HEC) field 622 can be used to check the header 602 for errors.

Fig. 6C illustrates a detailed view of a GEM header format of a node report message according to some embodiments. As shown in fig. 6C, the header 602 includes a GEM type field 606, a report message type field 624, a source epoch ID field 626, a total report size field 628, a report threshold size field 630, a report sequence number field 632, one or more source node Virtual Output Queue (VOQ) status fields 634 (e.g., CPU-IO, PLOAM, NMCI, CAN, sensor, ethernet, or other types), a report priority field 636, and a header error correction/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 total report size field 628 is fourteen bits, the report threshold size field 630 is eight bits, the report sequence number field 632 is five bits, the 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.

The report message type field 624 indicates which type of report header 602 (and thus which 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., a node ID where the epoch ID of the source of the data packet is mapped to the source of the data packet), a node report message of another node (e.g., a node ID where the epoch ID of the source of the data packet is not mapped to the source of the data packet), and/or a power outage alarm report message (e.g., a message requiring/requesting the highest priority). The source epoch ID field 626 can be or represent: an epoch ID of the source node (e.g., for reports of PLOAM and NMCI and CAN/sensor/ethernet queue flags), an epoch ID of the CAN (e.g., for reports of the CAN), an epoch ID of one of the sensor/nodes (e.g., for reports of the sensor), an ethernet epoch ID (e.g., for reports of ethernet packets), and/or a PCIe/USB epoch ID (e.g., for PCIe/USB report messages). The total size of report field 628 can indicate the total size of GEM data within the VOQ (for the epoch ID and/or node ID), while the threshold size of report field 630 can indicate the GEM packet boundary (single or plural) within the VOQ (e.g., for use in determining the size of the burst window granted for an epoch and/or node).

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 missing or unordered). One or more source node Virtual Output Queuing (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, sensor, ethernet). The report priority field 636 CAN indicate what priority to give to the message (e.g., best effort, normal bandwidth request priority, CAN message request priority, power off alarm request priority).

Fig. 6D and 6E show detailed views of two variants of GEM header format for root port bandwidth grant messages according to some embodiments. As shown in fig. 6D, for a node grant message with a node ID that is the same as an epoch ID, the header 602 can include a GEM type field 606, an epoch ID field 638, a start time field 640, a grant size field 642, a grant flag field 644, a report command field 646, a grant 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 grant size field 642 is fourteen bits, the grant flags field 644 is one bit, the report command field 646 is three bits, the grant 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 twelve bits. Optionally, one or more of the fields described above may be larger or smaller.

Epoch ID field 638 can be or represent an epoch ID or node ID of the node for which the message is intended. The start time field 640 can indicate the start time of the grant window granted to the target node (e.g., the epoch of the node), and the grant size field 642 can indicate the size/duration of the grant 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 a 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 reports or force nodes to report RTS messages to ports for black box and diagnostic tests; in combination with one or more of: PLOAM and NMCI report only CPU-IO message, CAN message and sensor data and PLOAM/NMCI mandatory report; ethernet data packet and CPU-IO/CAN/sensor and PLOAM/NMCI mandatory report; and/or PLOAM/NMCI/CPU-IO/CAN/sensor/ethernet and Node Operations and Control Reporting (NOCR) mandatory full reporting. The grant command field 648 can indicate what type of message/data is granted to the burst window. For example, the authorization command field 648 can indicate one or more of the following: windows are not used for PLOAM and NMCI messages; the authorization window is only for PLOAM messages; the authorization window is for NMCI messages only; and/or authorization for PLOAM, NMCI, and NOCR messages. The FWI field 650 indicates whether to force the sleeping node to wake up; the burst profile field 652 can indicate a burst configuration (e.g., a length, mode, and/or other characteristics of the SOB delimiter, EOB delimiter, and/or preamble).

As shown in fig. 6E, for GEM authorization messages with node IDs different from epoch ID, the header 602 can be substantially the same as the header of fig. 6D except that there is no report command field 646 and FWI field 650. Further, unlike fig. 6D, the authorization command field 648 can be six bits. Alternatively, the authorization command field 648 can be larger or smaller. Also unlike fig. 6D, the grant command field 648 can indicate a different type of GEM bandwidth grant. For example, field 648 can indicate a bandwidth grant for: all VOQ/CoS (class of service) set for CAN messages only, sensor data only, power down alarm messages only, and/or node based output scheduling for CAN messages and sensor data. In addition, field 648 can force node ID power savings if the node replies with an acknowledgement message.

Fig. 6F illustrates a detailed view of a GEM header format for a control message according to some embodiments. As shown in fig. 6F, 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 forty-five bits in total, and the header error correction/check (HEC) field 622 is twelve bits. Optionally, one or more of the above fields can be larger or smaller.

The control message type field 654 can indicate what type of control message the message is (e.g., so the control message field 656 and its offset are known to process). In some embodiments, the control message type field 654 indicates one or more of the following: reporting an acknowledgement message; a CAN acknowledge message; a flow control message; a power saving message; and IO event messages (e.g., power off alarm); a runtime state message; and/or timestamp updates (e.g., from port to node). The control message field 656 can include various control message fields based on the control message type (as shown in the control message type field 654).

Thus, a benefit of the GEM format is to enable the bus 104 to encapsulate various input data and messages of disparate types of networks (e.g., controller area networks, optical networks, sensor device broadcast networks, wireless networks, CPU access networks) into one unique format (GEM). This unique format may then facilitate high-speed standardized processing and transmission of various data inputs for burst and broadcast messages, thereby enabling efficient operation of the multi-network multi-device bus architecture required by modern machine automation applications.

Burst/broadcast frame format

In some embodiments, the Broadcast message is formatted into a Broadcast physical layer Frame (Broadcast-PHY-Frame) defined by a Preamble (Preamble) + a Frame-Start Delimiter (Start-of-Frame-limiter) + a Frame Payload (Frame-Payload), wherein the Frame Payload includes a plurality of GEM Packet (GEM-Packet) data and a GEM Control (GEM-Control) message. The Broadcast-PHY-Frame may be a fixed Frame size (e.g., between 25 μ s and 125 μ s). Alternatively, a larger or smaller frame size can be used. For example, the frame size may be smaller (e.g., 25 μ s or 50 μ s) for a central network 206 and a subnet 210 with

fewer node devices

204, 208. In some embodiments, the Broadcast-PHY-Frame is configured to carry GEM-Packet and GEM-Control messages from root port 230 to door 202 and/or

nodes

204, 208, 234 over

networks

206, 210, including fiber, copper, and wireless networks.

In some embodiments, the Burst message is formatted as a Burst-PHY-Frame defined by a preamble + a head-of-Frame Delimiter + a Frame payload + a tail-of-Frame Delimiter (End-of-Frame-Delimiter), wherein the Frame payload includes one or more of GEM-Packet data and a GEM-Control message. The size of the Burst-PHY-Frame may vary depending on the size of the total Burst window of the node/gate authorized by the root port HDBA and/or the gate DBA. In some embodiments, the maximum size of the Burst-PHY-Frame (from gate 202 or

nodes

204, 208, 234) cannot exceed the maximum Burst-PHY-Frame size (e.g., between 25 μ s and 125 μ s). In some embodiments, the Burst-PHY-Frame is configured to carry GEM-Packet and GEM-Control messages from gate 202 and/or

nodes

204, 208, 234 to root port 230 and/or gate 202 over a

network

206, 210 that includes fiber, copper, and wireless networks.

FIG. 7A illustrates a Broadcast-PHY-Frame700 according to some embodiments. As shown in fig. 7A, the Broadcast-PHY-Frame700 includes a physical synchronization block (PSBbc)702 for Broadcast and a Broadcast framing sublayer Frame 704, the Broadcast framing sublayer Frame 704 including a GEM control message 706, one or more GEM packets 600, and a Framing Sublayer (FS) tail 708. As described above, each GEM packet 600 includes a header 602 and a payload 604. In some embodiments, the broadcast FS frame is FEC protected. FIG. 7B illustrates a Burst-PHY-Frame710 according to some embodiments. As shown in fig. 7B, the Burst-PHY-Frame710 includes a physical sync block unicast start of Burst delimiter (PSBuc _ sd)712, a Burst Framing Sublayer (FS)714, and a physical sync 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. Burst FS714 can include FS header 724, one or more epochs 726, and FS tail 708. Each epoch 726 can include one or more GEM packets 600 having a header 602 and payload 604 as described above. In some embodiments, the burst FS frame is FEC protected. In particular, by including EOB delimiters (in addition to the SOB delimiters and frame size), the structure 710 enables a sniffer, analysis engine, or other element to monitor traffic within the bus 104, even if the size of the frame is not known/accessed, which enables the element to determine the end of each burst frame based on the EOB delimiters.

FIG. 7C illustrates a gate Burst-PHY-Frame728 according to some embodiments. As shown in fig. 7C, the gate Burst-PHY-Frame728 can include one or more Burst-PHY-frames 710, which Burst-PHY-frames 710 are combined together into a single combined Burst-PHY-Frame having a single preamble 729 and one or more gaps 730. In particular, as described in detail below, gate 202 is capable of receiving Burst frames 728 from one or more child nodes 208 and one or more IO ports 99 (which act as virtual nodes) and combining these frames 728 into a combined gate Burst-PHY-Frame728 as shown in fig. 7C. As a result, the system 100 provides the following advantages: by combining burst frames for more efficient communication of messages and by using only a single preamble for the combined frame as a whole, rather than using separate preambles for each combined burst frame (which may each be up to 256 bytes or more), the overhead per frame is less.

FIG. 8 illustrates a method of operation of the intelligent controller and sensor intranet bus 103 according to some embodiments. As shown in fig. 8, 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, the

nodes

204, 208 encapsulate the message into a Generic Encapsulation Mode (GEM) format for transmission to the central processing core 200. If the destination of the incoming message is node 234 within core 200, then at step 806 the core decapsulates, processes and transmits the message to its destination without repackaging. Otherwise, if the destination of the incoming message is one or more other nodes 204, 208 (outside of the core 200), the core 200 decapsulates, processes, and repackages the message back into GEM format for broadcast to its destination at step 808. At step 810, the

nodes

204, 208 decapsulate the message received from the kernel 200 from the GEM format into the original format of the input data received from one of the devices 102. Alternatively, incoming messages can be input and processed by core 200 (without encapsulation) if they are input from node 234 within core 200, and encapsulated for broadcast only by core 200 if their destination is one or

more nodes

204, 208 outside core 200. Thus, the method provides the following advantages: communication of many different types of data (e.g., sensors, controller bus, ethernet, or other types of data) can be achieved, 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, rather than using a separate preamble for each combined burst frame.

Inner core

The core 200 may include a core switch 228, one or more root ports 230 (internal ports), a central processing unit 232, and one or more core nodes 234 having IO ports 99 (external ports). In some embodiments, kernel 200 also includes a secure memory (e.g., Secure Digital (SD) memory) node 236 for storing data in 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 couple user plug-in modules (e.g., CPU kernel, WIFI LTE/5G, user application software) to the kernel 200, bypassing the

networks

206, 210.

The core switch 228 includes forwarding engine elements, queuing buffer managers, and traffic managers. The forwarding engine element may include a plurality of forwarding engines. For example, the forwarding engine element may include one engine for L2/L3/L4 ethernet header parser, lookup and sort/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 bus 104 from external internet DOS attacks. The GEM queuing buffer manager may be a centralized buffering architecture that uses a chain list based buffer and queuing store approach in conjunction with a store-and-forward scheme and a cut-through forwarding scheme. For the GEM data packet and the GEM message which are sensitive to delay, a straight-through forwarding scheme can be used; while for congested GEM packets, a store-and-forward scheme may be used. The two schemes can be dynamically mixed together and dynamically switched between each other according to traffic congestion conditions at runtime. The GEM traffic manager supports dual token policing, single token throttling and output shaping functions of the GEM-ID and NODE-ID libraries, including associated Management Information Base (MIB) counters. GEM-ID pool Weighted Random Early Detect (WRED) and tail drop functionality can be supported, as well as early traffic congestion detection and indication and feedback mechanisms to inform the hybrid dynamic bandwidth allocation mechanism (HDBA), root port 230, gate 202, and

nodes

204, 208, 234 to slow down traffic transmission to avoid traffic congestion.

Thus, the kernel switch 228 may provide ingress functionality, with the switch 228 receiving a GEM from one or more of the root port 230, the local node 234, the computer 232, and/or other IO ports, processing the GEM and forwarding and transmitting the received GEM to one or more of the root port 230, the local node 234, the 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 messages, and 5-tuple ACL and classification; modify GEM header and GEM payload ethernet header (if necessary); and store-forward (or direct-buffer) the GEM packets to the broadcast MAC of one or more hybrid automatic repeat request (HARQ) functional blocks and one or more root ports 230.

In performing this processing and/or forwarding function, switch 228 may support a hybrid store-and-forward and cut-through forwarding scheme to reduce propagation delay for delay sensitive GEM and provide sufficient buffering for over-bursty GEM traffic. In addition, the switch 228 may support immediate flow control mechanisms within the bus 104, including hybrid dynamic bandwidth allocation and delegating (granting) to ensure overall quality of service (QoS) on the bus 104. Further, the switch 228 may support L2/L3/L4ACL and classification, L2 MAC addressing learning and forwarding, L3 IP addressing to GEM-ID routing/mapping, and DOS attack protection. Finally, switch 228 may support QoS scheduling, GEM buffer WRED/tail drop, node and/or GEM policing and output shaping functions.

Root port

Root port 230 may include a root transmit MAC, a root receive MAC, a security engine (e.g., Advanced Encryption Standard (AES)), a Forward Error Correction (FEC) engine, a Hybrid Dynamic Bandwidth Allocation (HDBA) engine, an activation processor (e.g., an activation state machine), and a burst mode SERDES IP. Optionally, one or more of the above elements may be omitted. The transmit MAC for each root port 230 is responsible for: receiving switch 228 and/or HARQ ready outgoing GEM; mapping and packing the GEM into a Broadcast Frame format (e.g., Broadcast physical layer Frame (Broadcast PHY-Frame) structure); and broadcasts the GEM to all of the gates 202 and/or nodes 204 in the central transport network 206 to which the root port 230 is coupled (e.g., broadcasting domains through the root SERDES and optical/copper network). Instead, the receiving MAC of each root port 230 is responsible for: receive a GEM in a Burst Frame format (e.g., Burst-PHY-Frame structure) from the Burst mode SERDES and gate 202 and/or

nodes

204, 208; extract the GEM from the burst frame format, parse the GEM header of the GEM, and receive the GEM addressed to the GEM header (e.g., based on the GEM header and system Service Level Agreement (SLA) configuration file settings), then output the GEM/data to the switch 228 for further processing and forwarding. In other words, each root port 230 is able to receive bursty traffic from node 204 and/or gate 202 (forwarded from node 208 in the subnet 210 of gate 202), convert the bursty traffic to the correct format for processing by switch 228, and then reformat and broadcast (through gate 202) the outgoing traffic to all

nodes

204 and 208 to reach the destination indicated by switch 228.

The Hybrid Dynamic Bandwidth Allocation (HDBA) engine is responsible for: receiving reports (e.g., NODE-DBA reports) regarding bandwidth occupancy, traffic congestion, and other factors; performing HDBA analysis based on the SLA profile of the node/port/device associated with each report, the DBA report data itself, and Committed Information Rate (CIR)/Peak Information Rate (PIR) feedback; and grants a burst window to each node device and assigned port/EPOCH-ID. In other words, the HDBA engine inputs data from each node 204, 208 (of the network 206 associated with the root port 230 and its subnet 210) and/or other sources regarding bandwidth occupancy/traffic congestion and dynamically allocates a burst transmission window start time and/or size for each

node

204, 208. When this allocation is performed to node 208 within subnet 210, the gate 202 providing access to node 208 is transparent to the HDBA engine. Thus, as described in detail below, the gate 202 receives the required data and performs burst transfers within the allocated window for each node 208 of the gate 202 of the subnet 210. The HDBA engine may also issue a Report acknowledgment message (GEM-Report-ACK message) to the

nodes

204, 208 to acknowledge that the Report message (GEM-DBA Report) has been received.

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 ports 230, performing and completing the activation and registration of the

nodes

204, 208, 234 devices through activation processes and procedures. The security engine may be an AES-128/256 encryption and decryption function for receiving and sending MACs. Alternatively, other encryption may be used. A Forward Error Correction (FEC) engine is used to control errors in data transmission over unreliable or noisy communication channels. In some embodiments, the FEC engine uses reed solomon FEC encoding schemes for RS (255,216) and RS (225,232) for 10G and 2.5G data rates, respectively. Alternatively, the FEC engine may use a user Low Density Parity Check (LDPC) scheme and/or other FEC algorithms. Burst mode SERDES uses a fast Clock and Data Recovery (CDR) lock mode to ensure that the proper burst message (e.g., burst-PHY-Frame) is received correctly. In some embodiments, a fast lock function of the CDR is required in fiber-cut (fiber-cut), fast fail-over (fast fail-over), and protection flip-chip recovery.

Finally, after the registration process, root port 230 receives a broadcast Data Distribution Service (DDS) message from a

node

204, 208 informing root port 230 that a new node/device has joined and registered with bus 104. Thus, Root Port 230 is configured to always listen and receive these Data Distribution Service (DDS) messages from switch 228 and

new nodes

204, 208 declaring a join to bus 104, and update the Root-Port (Root-Port) SLA profile database and settings to reflect the newly added node/device.

Node point

Within the bus 104, the

edge nodes

204, 208, 234 provide a bridging function, interfacing with the external device 102 through the IO port 99 on one side and with the bus intranet 104 on the other side. To provide data from a device 102 coupled to a port 99 of a node 204, 28, the

node

204, 208, 234 constructs and sends a burst message (e.g., Broadcast-PHY-Frame of data encapsulated as GEM) to the

other nodes

204, 208 via the bus 104 and through the root port 230 (of the network 206 or its subnet 210 to which it belongs). Further, to provide data to the device 102 coupled to the port 99 of the node 204, 28, the

node

204, 208, 234 receives Broadcast messages (e.g., Broadcast-PHY-Frame encapsulating data as GEM) from

other nodes

204, 208 through the root port 230 (of the network 206 to which it belongs or of its subnet 210), extracts data from the Broadcast messages (e.g., GEM from RX BC-PHY-Frame), and filters and receives data belonging to (addressed to) the

node

204, 208.

To perform these and other functions, the

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 buses), 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 data packets, Commands (CMD) and messages received from internet ports (e.g., ethernet, Wi-Fi), sensor interfaces, electromechanical module interfaces, and CPUs (e.g., PCIe and USB) into GEM format at the ingress. The

nodes

204, 208 may then output an encapsulation message (e.g., GEM) to the HARQ and/or node transmission MAC (described below). At the egress, it receives the GEM packet from the node MAC (received from the root port 230 and/or another

node

204, 208, 234) and decapsulates the GEM back to the original data format (as received from the joining device 102) for output to the device 102 through one of the ports 99. Similar to the root port 230, the HARQ of the

nodes

204, 208 performs a hybrid automatic repeat request function to ensure that GEM packets are successfully transmitted to their one or

more destination nodes

204, 208, 234. Specifically, HARQ may incorporate a retransmission timer, a transmit GEM list flag table, and a receipt acknowledgement check function (e.g., GEM receipt acknowledgement) to trigger GEM retransmission if the timer expires without receiving an acknowledgement.

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-reporting engine, and a SERDES IP. The TX MAC is responsible for mapping/packing the GEM into a Burst structure (e.g., a Burst-PHY-Frame structure) and sending Burst messages to root port 230 and/or

nodes

204, 208, 234 during a Burst window for a node authorized for that node by the dynamic Burst allocation engine of root port 230. The RX MAC is responsible for receiving and terminating Broadcast messages (e.g., Broadcast-PHY-Frame) from the root port 230 and/or

nodes

204, 208, 234, extracting the GEM from the Broadcast message format, parsing and receiving the GEM addressed to the root port 230 and/or

nodes

204, 208, 234 (e.g., to one port 99 of the root port 230 and/or

nodes

204, 208, 234) based on the node's SLA profile settings, and then outputting the data to the encapsulation/encapsulation engine.

The DBA reporting engine reports the total packets and messages in a queue (e.g., an EPOCH queue) to the HDBA engine of the associated root port 230 via burst reporting (as described above). In addition, the DBA reporting engine receives GEM-grant messages from the HDBA of the associated root port 230 and/or the DBA of the associated gate 202 and prepares the node to transmit a MAC to construct a Burst message (e.g., Burst-PHY-Frame) with the GEM stored in a queue (e.g., an EPOCH queue).

The node activation processor is responsible for executing and completing the

node

204, 208, 234 activation processes and procedures between the

nodes

204, 206, 234 and the root port 230. The security engine may be an AES-128/256 encryption and decryption function for both the receive MAC and the transmit MAC. Alternatively, other encryption may be used. The FEC engine is used to control errors in data transmission over unreliable or noisy communication channels. In some embodiments, the FEC engine uses reed solomon FEC encoding schemes for RS (255,216) and RS (225,232) for 10G and 2.5G data rates, respectively. Burst mode SERDES uses a fast Clock and Data Recovery (CDR) locking mode to ensure fast fiber cleaving, fast failover, and protection flip recovery.

Finally, after the activation process (e.g., after completion of the registration process), the

nodes

204, 206, 234 may broadcast a DDS message to the entire bus 104 to notify and inform the root port 230, switch 228, gate 202, and/or

other nodes

204, 206, 234 that a new device has been added to the bus 104 and registered at the

nodes

204, 208, 234. In addition, the

nodes

204, 206, 234 may listen for DDS messages from the switch 228 and other

new nodes

204, 206, 234 declaring a join to the bus 104, and update their global SLA profile database and settings based on the DDS messages.

Door with a door panel

Gate 202 may include a node MAC (with multiple virtual node state machines and buffers), an Adaptive Domain Bridge (ADB), a root port MAC (with built-in gate DBA function/gate DBA), a gate 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, SERDES functions of the virtual node processor and/or multiple sets (e.g., one for each node within subnet 210), virtual node configuration files and settings, and associated MIB counters and reporting logic. The sending MAC receives the GEM from the gate ADB and then sets up a mapping and packaging into its associated virtual node Burst structure (e.g., Burst-PHY-Frame structure) based on the gate's virtual node SLA profile database. In addition, the transmit MAC aggregates multiple virtual node Burst structures (e.g., Burst-PHY-frames) into one GATE Burst structure (e.g., GATE/Turbo Burst-PHY-Frame) and sends the Burst message to the root port 230 over the network 206 based on the authorized Burst window for those nodes 208 received from the HDBA of the root port 230. The node receive MAC receives Broadcast messages (e.g., Broadcast-PHY-Frame) from root port 230, extracts the GEM from the messages, parses the GEM header, determines which messages are for node 208 within sub-network 210 of gate 202 based on the GEM header and virtual node SLA configuration file database settings, and outputs the messages to the ADB.

The ADB performs a bridging function between the node MAC and the root MAC of the gate 202. Specifically, in the broadcast direction (from root port 230 to node 208), the ADB receives the GEM from the node receive MAC and performs a GEM header lookup, based on the gate virtual node profile database to perform checking and filtering functions, to receive the GEM of node 208 belonging to the subnet 210 of gate 202. The ADB may then output these GEM to the root port of gate 202 to send the MAC. In the burst direction (from node 208 to root port 230), the ADB receives the GEM from the root receiving MAC, stores the GEM in its associated virtual node buffer memory, and outputs the GEM to the virtual node sending MAC when its burst window start time comes.

The root port MAC of gate 202 includes a transmit MAC, a receive MAC, a security engine (e.g., AES), an FEC engine, a gate DBA, and a burst mode SERDES module. The transmit MAC is responsible for receiving the GEM from the ADB, mapping and packing the GEM into a Broadcast format (e.g., Broadcast-PHY-Frame structure), and outputting the Broadcast-formatted frames to the burst mode SERDES. The receive MAC is responsible for receiving Burst messages (e.g., Burst-PHY-Frame) from Burst mode SERDES (e.g., a remote node), extracting the GEM from the message, parsing and receiving only the GEM targeted by node 208 within the subnet 210 of gate 202 (as indicated based on the parsed GEM header and SLA configuration file settings), and then outputting the GEM to the ADB of gate 202. The DBA of gate 202 is an extended HDBA for root port 230. The gate DBA authorizes and assigns a node burst window based on the gate DBA SLA profile settings, which are a subset of the root HDBA. The portal SLA profile database includes a list of node identifiers belonging to the portal 202 (e.g., located within the subnet 210 of the portal 202), an SLA profile table of node identifiers for the portal DBA functionality, and GEM forwarding information. Burst mode SERDES receives a Broadcast message (e.g., Broadcast-PHY-Frame) from a root transmit MAC and transmits in a Broadcast transmission direction to node 208 in subnet 210. In the receive direction, the Burst mode SERDES receives a Burst message (e.g., Burst-PHY-Frame) from node 208 through subnet 210 and outputs the Burst message to the root receive MAC for message/Frame termination and GEM extraction.

The main function of the gate 202 is to bridge to one or more subnets 210 (and nodes 208 therein) through adaptive bridging to extend the central transport network 206 of one of the root ports 230. In particular, gate 202 may burst messages from node 208 and/or other gates 202' within its subnet 210 to the root port 230 of the network 206 where it is located, as if the burst traffic is from a node within the central transport network 206. Similarly, the gate 202 may broadcast messages received from

other nodes

204, 208, 234, switches 228, and/or root ports 230 to the node 208 and/or other gates 202 'within the subnet 210 in which it resides as if the node 208 and/or other gates 202' were within the central transport network 206. Thus, the gate 202 may also extend the central transport network 206 to additional nodes 208 and/or different types of subnets 210 while maintaining the burst/broadcast communication method within the central transport network 206.

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

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

Fourth, due to the agreement between the gate traffic DBA reports and root port 230 window authorizations, root port 230 and gates 202 can maintain a group membership list table and know each gate 230 below as a small group of virtual nodes 208. Thus, when node 208 issues a report message (e.g., a GEM report) to the HDBA of root port 230, gate 203 may intercept the report message, modify the report message to include GEM data temporarily stored in the virtual node buffer memory (if any) of gate 202, and issue a new report message to the HDBA of root port 230. In other words, the gate 202 may combine the reporting messages from the nodes in its subnet 210 to make the reporting more efficient.

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

In other words, for the data path, gate 202 receives burst messages (e.g., burst-PHY-frame) from burst mode SERDES and remote NODEs 208, extracts the GEM from the messages in the root receive MAC of gate 202, stores the GEM in its associated virtual NODE buffer memory, and waits for virtual NODE burst window grants to come in from the root ports 230 of those virtual NODEs 208. The gate 202 can then map and package the stored GEM for that node 208 and other nodes 208 back into a burst message format, aggregating multiple burst messages together into one larger burst message in the node sending MAC of the gate 202. Finally, gate 202 can send the larger burst message to the SERDES and over network 206 to root port 230 based on the authorized burst window (e.g., multiple consecutive virtual node burst windows of gate 202).

Looking now at the broadcast direction (e.g., from root port/switch/kernel to node/gate), the gate 202 is also able to extend the central network 206 to the subnet 210 while being transparent to both the root port 230 of its network 206 and the node 208 in its subnet 210. To accomplish this, the gate 202 can act like a virtual node and receive a Broadcast message (e.g., Broadcast-PHY-Frame) from the root port 230, extract a GEM from the message, discard any GEM not directed to one of 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 pass-through scheme to pack and map the GEM back to a 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.

Data transfer operation

In operation, bus 104 operates using a burst/broadcast communication scheme in which all data messages from

nodes

204, 208, 234 (and gate 202) are assembled to core 200 using a burst transfer method, wherein a dynamically resizable (by core 200) transfer window is authorized for

nodes

204, 208, 234 so that

nodes

204, 208, 234 (or gate 202 on behalf of

nodes

204, 208, 234) can transfer their data messages as "bursts" within the authorized window. If the sending node is in subnet 210, gate 202 (as the root port of the network 210) receives a burst message from node 208 through subnet 210 and then bursts the message to core 200 through central network 206 (as if node 208 were part of central network 206). In conducting this burst communication, gate 202 may aggregate burst messages from multiple nodes 208 within sub-network 210, thereby improving efficiency and reducing the impact of sub-network 210 that may increase latency relative to central network 206. Even further, the above steps may be repeated for a gate 202 ' within the subnet 210, the gate 202 ' providing a gateway or the like to the subnet 210 ' to support any number of "linked/gated" networks. Further, in this process, gate 202 may be transparent to core 200 and node 208, such that messages do not need to be addressed to gate 202.

The core 200 receives these messages (from one or more root ports 230 that couple the core 200 to each central network 206), processes them (including modifying and/or determining their target destinations), and broadcasts them (and any messages originating from the core 200) to the

target nodes

204, 208, 234 at it (or the gate 202 representing the target node 208) regardless of which central transport network 206. Like the burst communication above, if the target node 208 is within the subnet 210, the gate 202 bridging to that subnet 210 may receive/intercept the message from the kernel and rebroadcast the message to all nodes 208 (and/or gates 202') on the subnet 210. Any broadcast messages for target node 204 that are not on subnet 210 (or a subnet of subnet 210) may be discarded by gate 202 to improve efficiency. Again, this process is transparent and can be repeated by the gates 202' within the subnet 210, and so on for any number of linked networks to broadcast messages over the network. Thus, all

nodes

204, 208, 234 (and gates 202) on each network 206 (and the subnet 210 coupled to the network 206) receive all messages broadcast on that network 206 from the core 200, and only need to look up which messages are directed to the

nodes

204, 208, 234 (and gates 202), while discarding other messages.

In more detail, when a

node

204, 208, 234 receives data from one or more external devices 102 through its IO port(s) 99, the

node

204, 208, 234 stores the data in a GEM-ID queue buffer memory and bursts a Report message (e.g., GEM-Report) to the root port 230 of the central network 206 where it is located (either directly or through one or more gates 202 if one or more gates 202 are located in a subnet 210 of the central network 206) and waits for an authorized burst window to send the incoming data. As described above, the gate 202 may collect and aggregate report messages from multiple nodes 208 (and/or gates 202') in its subnet 210 into a single larger report message that the gate 202 can more efficiently burst to the root port 230 during the burst window for those ports 208.

Meanwhile, the

nodes

204, 208, 234 can encapsulate the input data into a GEM format (segment a GEM exceeding a predetermined size into smaller GEMs), encrypt the GEM with the security key of the

nodes

204, 208, 234, update the HARQ table, and map and package the GEM into a Burst format (e.g., Burst-PHY-Frame format) and perform encoding (e.g., FEC RS (255,216) encoding). Then, after granting and reaching the burst window for each node, the node bursts the GEM including the input data to the associated root port 230.

The HDBA of the root port 230 receives all report messages from the nodes 204, 208 (and/or the gates 202) and performs DBA analysis on each

node

204, 208 based on the SLA profile database, delay sensitivity level, traffic congestion feedback, Committed Information Rate (CIR)/Peak Information Rate (PIR) feedback, and/or other factors to determine the grant window burst size and start time for each

node

204, 208. Once an authorized burst window is determined for one or

more nodes

204, 208, the root port 230 broadcasts the window to each node, to the associated central network 206, and/or to all

nodes

204, 208 in any subnet 210 (via the gate 202) in a broadcast authorization message (e.g., GEM authorization). As described above, the broadcast messages from root port 230 are of the same size, while the burst windows from

nodes

204, 208 to root port 230 can change size as dynamically allocated by the HDBA.

Upon receiving the broadcast grant message for a node 208 in its subnet 210 (or a subnet of the subnet 210), the gate 202 broadcasts a new grant message to all nodes 208 of the subnet 210. In particular, these new grant messages can specify a burst window that occurs before the time indicated by the original/root port grant window. This is to ensure that gate 202 receives (e.g., "bursted") incoming data/GEM from port 208 before the original/root authorization window, thereby giving gate 202 time to aggregate data/GEM from multiple nodes 208 and/or ports 99 into a single larger message to burst to root port 230 when the original/root port authorization window arrives. Thus, the gate 202 can compensate for inefficiencies and/or slowness of the subnet 210 such that the subnet 210 does not slow down the efficiency of the central transport network 206.

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

The root port 230 receives the GEM, performs GEM encryption (e.g., AES-128/256 encryption) with the security key of the target node (or Broadcast GEM), packages and maps the GEM into a Broadcast message structure (e.g., Broadcast-Frame structure), encodes the message (e.g., FEC RS (255,216) encoding), and finally broadcasts the Broadcast message to all

nodes

204, 208 in the root port's network 206 and its subnet 210. If node 208 is within subnet 210, gate 202 to that subnet receives the broadcast message and broadcasts the message to all nodes 208 within subnet 210. In some embodiments, gate 202 filters out any broadcast messages that are not intended for nodes 208 within its subnet 210 (or a subnet of subnet 210), and broadcasts broadcast messages intended for only one of those nodes 208. Alternatively, the gate 202 can rebroadcast all broadcast messages to nodes 208 within the subnet 210 of the gate 202 without determining whether the message relates to one of those nodes 208.

All

nodes

204, 208 monitor the received broadcast messages, process the messages for the

nodes

204, 208 and discard the other messages. Specifically, for non-discarded messages, the

nodes

204, 208 decode and error correct the message (e.g., FEC RS (255,216) decode), 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), decapsulate the data from the GEM format back to the original IO-Port data format, and output the data to the external device 102 through the designated IO Port 99. Thus, the bus 104 and system 100 provide the following benefits: multiple different networks with different input data, different processing speeds and data constraints can be combined while still maintaining the low latency and high throughput required by machine automation systems. This is a unique intranet system architecture and is specifically defined and optimized for such machine automation applications.

FIG. 4 illustrates a block diagram of an exemplary computing device 400 configured to implement system 100, in accordance with some embodiments. In addition to the features described above, the external device 102 may include some or all of the features of the device 400 described below. In general, a hardware architecture suitable for implementing the computing device 400 includes a network interface 402, memory 404, a processor 406, I/O devices 408 (e.g., readers), a bus 410, and a storage device 412. Alternatively, one or more of the illustrated components can be removed or replaced by other components known in the art. The choice of processor is not critical as long as a suitable processor with sufficient speed is selected. The memory 404 may be any conventional computer memory known in the art. The storage device 412 may include a hard drive, CDROM, CDRW, DVD, DVDRW, flash memory card, or any other storage device. Computing device 400 may include one or more network interfaces 402. Examples of network interfaces include a network card connected to an ethernet or other type of LAN. I/O devices 408 may include one or more of the following: keyboard, mouse, monitor, display, printer, modem, touch screen, button interface, and other devices. Operating software/applications 430 or functions/modules thereof may be stored in the storage device 412 and memory 404 and processed as the applications are typically processed. More or fewer components than are shown in fig. 4 can be included in the computing device 400. In some embodiments, robotic automation system hardware 420 is included. Although computing device 400 in fig. 4 includes application 430 and hardware 420 for system 100, system 100 can be implemented on a computing device in hardware, firmware, software, or any combination thereof.

Fig. 5 illustrates a method of operation of a machine automation system 100 including an intelligent controller and sensor intranet bus 104 in accordance with some embodiments. As shown in fig. 5, in step 502, the

nodes

204, 208 receive input data from a plurality of external devices 102 through one or more ports 99 of the bus 104. In step 504, the

nodes

204, 208 burst the input data as burst messages to the core 200 in variable-size burst windows. In some embodiments, the HDBA of the root port 230 dynamically adjusts the burst window start time and size of the variable burst window for each

node

204, 208, and distributes the adjusted window to the

respective node

204, 208 in a broadcast grant window message based on the data traffic parameters reported from the

node

204, 208 therein. In some embodiments, gate 202 aggregates two or more burst messages, including incoming data and/or traffic reports received from node 208, into a single larger burst report or incoming data message for burst to core 200. In these embodiments, the gate 202 may omit a portion of the received burst message (e.g., a preamble) to improve the efficiency of the bus 104. In some embodiments, after receiving the broadcast window grant message from core 200, gate 202 adjusts the original time of the burst window to an earlier time and broadcasts the adjusted broadcast window grant message to node 208. Thus, node 208 bursts its data to gate 202 before the window granted by root port 230, enabling gate 202 to combine multiple burst messages together and burst them in the subsequent original time window. In step 506, the core 200 processes and broadcasts the input data as a broadcast message to each

node

204, 208 within the central network 206 and the subnet 210 that needs to reach the

target node

204, 208 of the message. In step 508, the

target node

204, 208 converts the data of the broadcast message into a format accepted by the device 102 coupled to the

node

204, 208 and outputs the data to the device 102. Therefore, the method has the following advantages: the bus 104 is enabled to maintain high speeds despite the use of lower speed network media.

The system 100 and machine automation controller and sensor bus 104 implementing a dynamic burst to broadcast transmission network has many advantages. In particular, the following benefits are provided: simplifying cable systems and connections; the influence caused by electromagnetic interference (EMI) is greatly reduced by using the optical fiber; ensuring low latency for node-to-node communications; high throughput bandwidth (10, 25, 100 or higher Gbps) for transmission from node to node; the device can extend from node to node and reach 20 km; low power consumption due to passive optical network architecture; industrial-level QoS that does not cause traffic congestion due to a centralized DBA scheduling mechanism; a built-in HARQ mechanism for ensuring the successful transmission from the node to the node and the GEM; and a unified software image for the entire intranet system including all gates, nodes, and root ports, thereby simplifying the software architecture, shortening the product development cycle, and simplifying system level debugging, monitoring, and troubleshooting.

The present application has been described in terms of specific embodiments incorporating details to facilitate the understanding of the principles of construction and operation of the application. Reference herein to specific embodiments and details thereof is not intended to limit the scope of the claims appended hereto. It will be understood by those skilled in the art that various other modifications may be made based on the embodiments selected without departing from the spirit and scope of the application as defined by the claims. For example, although the bus is described as operating within a machine automation system, as described herein, it should be understood that the bus can operate with other types of systems and their devices to facilitate communication between the devices.

Claims

1. A machine automation system for controlling and operating an automation machine, the system comprising:

a controller and sensor bus including a plurality of input/output ports, an

A plurality of external machine automation devices operatively coupled together through ports of the bus, wherein the bus comprises a central processing core and a multimedia transport intranet, the multimedia transport intranet comprising:

one or more central transport networks directly coupled with the cores and including a plurality of nodes and one or more gates; and

a plurality of sub-networks, each sub-network being coupled to a different gate of the central transport network, the sub-networks comprising a plurality of sub-nodes;

wherein each of the nodes and the child nodes:

coupled to one or more devices through one or more ports,

receiving messages from the one or more devices coupled with the one or more ports;

encapsulating the message into a General Encapsulation Mode (GEM) format for transmission to the central processing core; and

decapsulating messages received from the central processing core from a GEM format into an original format of input data received from one of the devices.

2. The system of claim 1, wherein the header of the GEM format comprises:

a source/destination field that identifies one of the ports as a source of the message or one or more of the nodes and the child nodes as a destination of the message; and

a GEM packet identifier field that identifies one or more of the ports to which the message is directed.

3. The system of claim 2, wherein the value of the source field is selected from a first set of epoch identifier values when one of the ports is identified as the source of the message, and the value of the destination field is selected from a second set of node identifier values when one or more of the nodes and the child nodes are identified as the destination of the message.

4. The system of claim 3, wherein values of the GEM packet identifier field are 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, each of the epoch identifier values maps to one or more of the GEM identifier values.

5. The system of claim 4, wherein the header of the GEM format comprises a GEM packet type field indicating an original format and a header type of a message encapsulated within the GEM format.

6. The system of claim 1, wherein the GEM-formatted header includes a source identifier field that indicates a source of the message and a reporting message type field that indicates whether reporting data within the message is independent of the source of the message indicated in the source identifier field.

7. The system of claim 1, wherein the header of the GEM format includes a start time field indicating a time at which a licensed bandwidth window begins and a licensed size field indicating a size of the licensed bandwidth window.

8. The system of claim 7, wherein the header of the GEM format comprises an authorization command field that indicates one or more types of messages allowed during the authorized bandwidth window.

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

10. The system of claim 9, wherein the burst physical frame format comprises a separate end-of-burst delimiter for each of the one or more messages, the separate end-of-burst delimiter indicating an end of one of the one or more messages within the burst physical layer frame.

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

12. The system of claim 11, wherein each of the gates omits a preamble of messages from the plurality of child nodes from a single larger message of the burst physical layer frame format.

13. The system of claim 1, wherein the device comprises 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.

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

15. A controller and 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, said multimedia transmission intranet comprising:

a plurality of sub-networks, each sub-network being coupled to a different gate of the central transport network, the sub-networks comprising a plurality of sub-nodes, wherein each of the nodes and the sub-nodes:

coupled to one or more devices through one or more ports,

16. The bus of claim 15, wherein a header of the GEM format comprises:

17. A bus according to claim 16 wherein the value of the source field is selected from a first set of epoch identifier values when one of the ports is identified as the source of the message and the value of the destination field is selected from a second set of node identifier values when one or more of the nodes and the child nodes are identified as the destination of the message.

18. The bus of claim 17, wherein values of the GEM packet identifier field are 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, each of the epoch identifier values maps to one or more of the GEM identifier values.

19. The bus of claim 18, wherein the header of the GEM format comprises a GEM packet type field indicating the original format and header type of messages encapsulated within the GEM format.

20. The bus of claim 15, wherein the GEM format header includes a source identifier field indicating a source of the message and a report message type field indicating whether report data within the message is independent of the source of the message indicated in the source identifier field.

21. The bus of claim 15, wherein the GEM format header includes a start time field indicating a time at which a licensed bandwidth window begins and a licensed size field indicating a size of the licensed bandwidth window.

22. The bus of claim 21, wherein the GEM format header includes an authorization command field that indicates one or more types of messages allowed during the authorized bandwidth window.

23. The bus of claim 15, wherein each of the nodes and the child nodes place one or more of the messages in a burst physical layer frame format after encapsulating the messages into the GEM format and transmit the messages to the central processing core by bursting the burst physical layer frame including the one or more messages to the central processing core.

24. The bus of claim 23, wherein the burst physical frame format comprises a separate end-of-burst delimiter for each of the one or more messages, the separate end-of-burst delimiter indicating an end of one of the one or more messages within the burst physical layer frame.

25. The bus of claim 15, wherein each said gate aggregates messages in GEM format from a plurality of said child nodes into a single larger message in burst physical layer frame format.

26. The bus of claim 25 wherein each of the gates omits a preamble of a message from the plurality of child nodes from a single larger message of the burst physical layer frame format.

27. The bus of claim 15, wherein the device comprises 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.

28. The bus of claim 15, wherein the automated machine is one of the group consisting of a robot and an autonomous vehicle.

29. A method of operation of a controller and sensor 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 transport intranet; the multimedia transmission intranet comprises one or more central transmission networks and a plurality of subnetworks; the one or more central transport networks are directly coupled with the core and include a plurality of nodes and one or more gates; each of the plurality of subnets is coupled to a different gate of the central transport network, the subnets including a plurality of child nodes, the method comprising:

one or more of the nodes and the child nodes:

receiving messages from one or more devices coupled with one or more ports associated with the one or more nodes and child nodes;

30. The method of claim 29, wherein a header of the GEM format comprises:

31. The method of claim 30, wherein the value of the source field is selected from a first set of epoch identifier values when one of the ports is identified as the source of the message, and the value of the destination field is selected from a second set of node identifier values when one or more of the nodes and the child nodes are identified as the destination of the message.

32. The method of claim 31, wherein values of the GEM packet identifier field are 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, each of the epoch identifier values maps to one or more of the GEM identifier values.

33. The method of claim 32, wherein the header of the GEM format comprises a GEM packet type field indicating a raw format and a header type of a message encapsulated within the GEM format.

34. The method of claim 29, wherein the GEM format header comprises a source identifier field and a reporting message type field, the source identifier field indicating a source of the message, the reporting message type field indicating whether reporting data within the message is independent of the source of the message indicated in the source identifier field.

35. The method of claim 29, wherein the GEM format header includes a start time field indicating a time at which a licensed bandwidth window begins and a licensed size field indicating a size of the licensed bandwidth window.

36. The method of claim 35, wherein a header of the GEM format comprises an authorization command field indicating one or more types of messages allowed during the authorized bandwidth window.

37. The method of claim 29, further comprising placing one or more of the messages in a burst physical layer frame format with each of the nodes and the child nodes after encapsulating the messages into the GEM format, and transmitting the messages to the central processing core by bursting the burst physical layer frame including the one or more messages to the central processing core with each of the nodes and the child nodes.

38. The method of claim 37, wherein the burst physical frame format comprises a separate end-of-burst delimiter for each of the one or more messages, the separate end-of-burst delimiter indicating an end of one of the one or more messages within the burst physical layer frame.

39. The method of claim 29, further comprising aggregating messages in GEM format from a plurality of the child nodes into a single larger message in burst physical layer frame format with each of the gates.

40. The method of claim 39, further comprising omitting, with each of the gates, preambles of messages from the plurality of child nodes from a single larger message of the burst physical layer frame format.

41. The method of claim 29, wherein the device comprises 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.

42. The method of claim 29, wherein the automated machine is one of the group consisting of a robot and an autonomous vehicle.