CN112912809B

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

Info

Publication number: CN112912809B
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: 2025-06-03
Anticipated expiration: 2040-09-09
Also published as: CN112912809A; WO2021055205A1

Abstract

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

Description

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

Cross reference

The present application is a continuation of the section of the pending U.S. patent application Ser. No. 16/529,682 entitled "Intelligent controller and sensor network bus, system and method," filed 8/1/2019, 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 automatic driving automobiles, intelligent robots and factory automation, the field of machine automation is rapidly expanding. However, due to their diversification and high speed requirements, no bus or network architecture is currently available that can effectively meet all of these emerging technologies. In contrast, current networks have high latency, 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 shields 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) from edge node to edge node throughout the system.

Disclosure of Invention

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

A first aspect of the application relates to a machine automation system for controlling and operating an automation machine. The system includes a controller and sensor bus including a plurality of input/output ports, and a plurality of external machine automation devices operatively coupled together through ports of the bus. The bus includes a central processing core and a multimedia transmission intranet including one or more central transmission networks directly coupled to the core and including a plurality of nodes and one or more gates, and a plurality of subnets respectively coupled to different gates of the central transmission network, the subnets including a plurality of subnodes, wherein each node and subnode are coupled to one or more devices through one or more ports, receive messages from the one or more devices coupled to the one or more ports, encapsulate the messages into a Generic Encapsulation Mode (GEM) format for transmission to the central processing core, and decapsulate the messages received from the central processing core from the GEM format into a raw format of input data received from one of the devices.

In some embodiments, the header in GEM format includes a source/destination field identifying one of the ports as the source of the message or one or more nodes and child nodes as the destination of the message, and a GEM packet identifier field identifying one or more ports for which the message is intended. In some embodiments, when one of the ports is identified as the source of the 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 the 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 a third set of GEM identifier values, and each node identifier value is mapped to one or more epoch identifier values, each epoch identifier value being mapped to one or more GEM identifier values. In some embodiments, the header of the GEM format includes a GEM packet type field that indicates the original format and header type of the message encapsulated within the GEM format. In some embodiments, the header of the GEM format includes a source identifier field indicating the source of the message and a report message type field indicating whether the report data within the message is independent of the source of the message indicated in the source identifier field.

In some embodiments, the header of the GEM format includes a start time field indicating a time at which the licensed bandwidth window starts and a licensed size field indicating a size of the licensed bandwidth window. In some embodiments, the header in GEM format includes an authorization command field that indicates one or more types of messages allowed during the authorization 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 burst physical layer frames comprising 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 GEM formatted messages from multiple child nodes into a single larger message in burst physical layer frame format. In some embodiments, each gate omits the preambles of messages from multiple child nodes from a single larger message in the burst physical layer frame format. In some embodiments, the apparatus includes one or more of the group consisting of an ultrasonic sensor, a light detection and ranging sensor, an infrared sensor, a camera, a motor, and a microcontroller. In some embodiments, the automated machine is one of the group consisting of a robot and an autonomous vehicle.

A second aspect of the 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 coupled directly to the core and including a plurality of nodes and one or more gates, and a plurality of subnets coupled respectively to different gates of the central transport network, the subnets including a plurality of subnodes, wherein each node and subnode is coupled to one or more devices through one or more ports, receives messages from the one or more devices coupled to the one or more ports, encapsulates the messages into a Generic Encapsulation Mode (GEM) format for transmission to the central processing core, and decapsulates the messages received from the central processing core from the GEM format into a raw format of input data received from one of the devices.

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

A third aspect of the 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 transmission intranet including one or more central transmission networks directly coupled with the core and including a plurality of nodes and one or more gates, and a plurality of subnets respectively coupled with different gates of the central transmission network, the subnets including a plurality of subnodes. The method includes one or more nodes and sub-nodes receiving messages from one or more devices coupled to one or more ports associated with the one or more nodes and sub-nodes, encapsulating the messages into a Generic Encapsulation Mode (GEM) format for transmission to a central processing core, and decapsulating the messages received from the central processing core from the GEM format into a raw format of input data received from one of the devices.

In some embodiments, the header of the GEM format includes a start time field indicating a time at which the licensed bandwidth window starts and a licensed size field indicating a size of the licensed bandwidth window. In some embodiments, the header in GEM format includes an authorization command field that indicates one or more types of messages allowed during the authorization bandwidth window. In some embodiments, the method further comprises, after encapsulating the message into a GEM format, placing one or more messages in a burst physical layer frame format with each node and child node, and transmitting the message to the central processing core by bursting a burst physical layer frame comprising 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 comprises aggregating messages in GEM format from the plurality of 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, the preambles of messages from multiple child nodes from a single larger message in a burst physical layer frame format. In some embodiments, the apparatus includes one or more of the group consisting of an ultrasonic sensor, a light detection and ranging sensor, an infrared sensor, a camera, a motor, and a microcontroller. In some embodiments, the automated machine is one of the group consisting of a robot and an autonomous vehicle.

Drawings

FIG. 1 illustrates a machine automation system in accordance with some embodiments.

Fig. 2 illustrates an intelligent controller and sensor intranet bus in accordance with 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 the 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 in accordance with some embodiments.

Fig. 6C illustrates a detailed view of a GEM header format for a node report message in accordance with some embodiments.

Fig. 6D illustrates a detailed view of a first variant of a GEM header format for a root port bandwidth grant message, in accordance with some embodiments.

Fig. 6E illustrates a detailed view of a second variant of a GEM header format for a root port bandwidth grant message, in accordance with some embodiments.

Fig. 6F illustrates a detailed view of a GEM header format for a control message in accordance with some embodiments.

Fig. 7A illustrates a Broadcast-PHY-Frame in accordance with some embodiments.

Fig. 7B illustrates a Burst-PHY-Frame in accordance with some embodiments.

Fig. 7C illustrates a gate Burst-PHY-Frame in accordance with some embodiments.

Fig. 8 illustrates a method of operation of the intelligent controller and sensor intranet bus in accordance with some embodiments.

Detailed Description

Embodiments described herein relate to machine automation systems, methods, and apparatus for controlling and operating an automated machine. The system, method and apparatus include a controller and sensor bus including a central processing core and a multimedia transmission intranet for implementing dynamic burst for a broadcast transmission scheme. Wherein messages are bursty from a node to the central processing core and broadcast from the central processing core to all nodes. The system, method and apparatus therefore provide a unified software image of a complete intranet system including all gates, nodes and root ports, allowing for simplified software architecture, shorter product development cycles, and easier system level debugging, remote monitoring and troubleshooting, while still providing the advantages of high speed performance despite the incorporation of low speed network media. In particular, the systems, methods, and apparatus provide a unique intranet system architecture that is specifically defined and optimized for machine automation applications.

Fig. 1 illustrates a machine automation system 100 in accordance with some embodiments. As shown in fig. 1, the system 100 includes one or more external devices 102, the one or more external devices 102 being operably 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 autonomous robot). Alternatively, the system 100 may be part of other machine automation applications. The device 102 may include one or more of a sensor device (e.g., ultrasonic, infrared, camera, laser RADAR (LIDAR), SONAR (SONAR), magnetic, RADAR (RADAR)), an internet device, 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 connected with bus 104 by one or more bus input/output (IO) ports (see fig. 2) either wired and/or wireless. Although as shown in fig. 1, system 100 includes discrete amounts of external devices 102 and buses 104, 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, central core 200 coupled with one or more gates 202, a plurality of edge nodes 204 (each edge node 204 having one or more external IO ports 99) through one or more central transport networks 206, and one or more edge child nodes 208 (each edge child node 208 having one or more external IO ports 99) through one or more subnets 210 extending from gates 202. Thus, as shown in FIG. 3, bus 104 forms a network tree topology in which central network 206 branches from central core 200 (e.g., core's root port 230) to edge node 204 and gate 202, and subnetwork 210 branches from gate 202 to child node 208 and/or child gate 202'. In this way, 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, without a node, one or more gates 202 are coupled directly with IO port 99 (e.g., to couple with an external CPU, GPU, AI core and/or a Solid State Drive (SSD)).

The ports 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 bus 104 includes discrete amounts 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 that is faster/has a lower latency than the connection medium of the subnetwork 210 coupled to the gate 202 of the central transport network 206. Similarly, the subnetwork 210 can include a connection medium that is faster/has a lower latency for the subnetwork 210 than the connection medium of the subnetwork 210 'coupled to the gate 202' of the subnetwork 210, and so on for each iterative subnetwork. This speed/latency relationship of the network/subnetwork connection media enables the processing of the overall bus 104 to be prevented from slowing, although the bus 104 still includes slower connection media, as described in detail below. Alternatively, one or more of the subnets 210, 210' and/or the central network 206 may have the same or other connection media speed/latency relationship.

In some embodiments, the connection medium of the central transmission network 206 includes an optical fiber cable 212, the optical fiber cable 212 being split using a splitter 214 (e.g., a 2-to-1 splitter) and having an optical transceiver 216 to couple to the nodes 204, 208 and receive data from the nodes 204, 208. In some embodiments, the connection medium of the subnetwork 210 includes fiber optic connection medium (e.g., connection medium similar to the central transmission network 206, but potentially lower in rank), wireless connection (e.g., radio frequency transceiver 218), copper cable connection (e.g., twisted copper pair 220 preferably split using analog splitter 222 (e.g., fanout exporter/multiplexer) and having serializer/deserializer (SERDES) 224 to couple to nodes 204, 208 and receive data from nodes 204, 208), and/or combinations thereof (e.g., hybrid fiber, copper cable, and/or wireless connection medium). Accordingly, the bus 104 supports multi-rate traffic transmission, wherein different nodes/networks can be used to couple to the bus 104, depending on latency/speed, connectivity, and/or distance requirements of the data/traffic/external device 102, while still providing the required throughput. For example, for high speed, low latency, and long distance requirements, an optical connection medium of a central network may be used by coupling to node 204. Otherwise, other networks 210 may be used according to cost, speed, connectivity, and/or distance requirements. In some embodiments, the central network 206 is a passive optical network and/or the copper subnetwork 210 is an active network. In some embodiments, as shown in FIG. 2, one or more nodes 204 are coupled to a Controller Area Network (CAN) 226 such that the nodes input 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 CAN's coupled to the central core 200 through a door 20.

Multi-layer bus addressing

Bus 104 can utilize a multi-layer addressing scheme in which root port 230, IO port 99, nodes 204, 208, 234, and/or gate 202 can use node, epoch (epoch), and GEM identification addresses to direct messages through bus 104. In particular, each of root port 230, nodes 204, 208, 234, and gate 202 can be assigned a node-ID identifier (node-ID), and nodes 204, 208, and gate 202 are also assigned at least one epoch-ID and at least one GEM-ID. The epoch ID can be used to identify the source/destination of the message (e.g., node/gate device and its IO port, embedded central processor, and/or other type of service) in the network 206, 210, while the GEM-ID can be used to identify the destination of the message (e.g., set and subset of node/gate device and its IO port, embedded central processor, and/or other type of service). 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 a received/broadcast message as its target.

According to a Service Level Agreement (SLA) profile of a node/gate (which can correspond to a device coupled to a port 99 of the node/gate), the node/gate can be assigned multiple epoch IDs and multiple GEM-IDs. Thus, the node IDs of each of nodes 204, 208 and gate 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 to two IO ports 99 can have a single node ID, two epoch IDs (one for each port 99), and ten GEM-IDs (one associated with a first epoch ID and a first port 99, nine associated with a second epoch ID and a second port 99). Furthermore, while the node ID and epoch ID are unique to each node/gate/port, GEM-IDs can be shared between nodes/gates/ports. For example, the ports 99 of the same node 204, 208 or different ports 99 of different nodes 204, 208 can each be associated with a matching or overlapping set GEM-IDs.

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

Each other node 234 and core 232 (which is directly coupled to core 200, such as an IO device and an embedded central processor core) can have one or more GEM-IDs and a global node ID, but need not be assigned an epoch ID, 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 kernel 232 can be determined based on SLA profiles of the node 234 or kernel 232 (which can correspond to devices coupled to port 99 of node 234). Each of the core switch 220, root port 230, nodes 204, 208, 234, and/or gate 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 cores themselves.

General packaging mode

The bus 104 may encapsulate all incoming data and internally generated data (e.g., control messages, operation 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 transmitting data between nodes and/or to the central core 200 over the bus 104 intranet. Thus, incoming data may be packaged into GEM format at each node upon entering bus 104 and passed through central core 200 (here unpackaged for processing and repackaged for transmission) and to its destination node, which unpacks the data into original format, and out to target external device 102 or other destination. The input data may come from various sources (e.g., device 102, CAN 226) entered through port 99 and/or embedded CPU core 232 at node 204, 208, 234 or gate 202.

The GEM format is of two types, GEM packets (packet) and GEM controls (control). The GEM packet format includes a GEM header (header) plus a GEM payload (payload) (e.g., 8 bytes to 4 kilobytes in length). Typically, GEM packet formats are used to encapsulate incoming port data, packets, and messages at portals (e.g., nodes, ports). The following are some examples of IO port data, packets, and message examples that may utilize the GEM packet format:

using GEM packet format, ethernet packets carried from local gate 202 and/or nodes 204, 208 are GEM encapsulated over bus 104 to remote gate 202 and/or node 204 (e.g., remote gate 202 and/or node 204 can be used for internet and Wi-Fi interfaces through ethernet ports or PCIe ports).

Using GEM packet format, the sensor data carried from local gate 202 and/or node 204 is GEM encapsulated over bus 104 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, carrying jumbo data and packets from the local nodes 204, 208 to the remote nodes 204, 208 through a fragmentation and defragmentation scheme. This can include fragmentation, defragmentation and re-ordering/retransmission functions.

Network control, operation and administration messages are carried between the core 200 and the nodes 204, 208 (and/or doors), including physical layer operation, administration and maintenance (PLOAM), node administration control interface (NMCI), and operation, administration and maintenance (OAM) messages, using GEM packet format.

Using GEM packet format, after encapsulation over bus 104GEM from core 200 and local gate 202 and/or node 204 to carry CPU/PCIe access CMD/DATA to 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, using GEM packet format, between the local node 204, 208 and the remote node 204, 208 via the bus 104 for VPN tunnel applications.

GEM control message formats include messages and extension messages (e.g., 8 bytes +8 bytes in length). At bus 104, the GEM control message format may be used for internal network management and control purposes, including Dynamic Bandwidth Allocation (DBA) reporting, DBA grant, GEM Reception (RX) acknowledgement, GEM flow control, GEM power management, GEM listening, GEM remote messages, and/or other types of control messages. As described above, node 204 is responsible for encapsulating/decapsulating data into/from the GEM packet format and the GEM control message format. The scheme may extend PCIe interface protocols from point-to-point topology to point-to-multipoint topology and interface distances 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, a GEM packet 600 can include a header 602 and a corresponding payload 604. As described above, for message packets, the header can be a fixed size (e.g., 8 bytes), the payload can vary in length (e.g., from 8 bytes to 4 kilobytes in length), and for control 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 in accordance with some embodiments. As shown in fig. 6B, the 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, an acknowledgement required field 620, a last fragment indication field 622, and a header error correction/verification (HEC) field 622. Optionally, one or more fields can be omitted and/or one or more additional fields can be added. In some embodiments, 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, transmission 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/verification (HEC) field 622 is thirteen bits. Alternatively, one or more of the above fields may be larger or smaller.

The GEM type field 606 indicates which type (and thus which type of packet) the header 602 of the GEM packet 600 is. 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. The encryption key index field 610 indicates the type of encryption used on the 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 the source node or destination node of data packet 600. For example, for a GEM packet 600 that bursts from a node to a core, field 612 can be or represent an epoch ID of the node to indicate the source of the packet 600. As another example, for GEM packets 600 broadcast from the root port 230 to nodes/gates within its network 206, 210, field 612 can be or represent a 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 a CAN message GEM-ID, a sensor data GEM-ID, and/or an ethernet packet GEM-ID). Thus, the GEM format provides the advantage of enabling bus 104 to identify a direct source and/or destination node through node/epoch ID field 612, while also enabling a target device/port/service to be identified using 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 Operation and Control Report (NOCR) message. The acknowledgement required field 620 can indicate whether an acknowledgement message in response to the message is required, and the transmission sequence identifier field 618 can identify the transmission sequence number of the data packet 600 (for a data packet that is bursty from the node to the core 200) within a set of data packets from the source node and/or its epoch ID. In some embodiments, an acknowledgement message from the receiving root port 230 is required when indicated by the acknowledgement required field 620. For data packets broadcast from the root port 230 to the node/gate, 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 when indicated by the acknowledgement required field 620. The last fragment indication field 622 can indicate whether the data packet 600 is the last fragment in a series of fragments of a large data packet, and the header error correction/verification (HEC) field 622 can be used to verify errors of the header 602.

Fig. 6C illustrates a detailed view of a GEM header format of a node report message in accordance with 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 report total size field 628, a report threshold size field 630, a report sequence number field 632, one or more source node Virtual Output Queue (VOQ) status fields 634 (e.g., CPU-IO, PLOAM, NMCI, CAN, sensors, ethernet, or other types), a report priority field 636, and a header error correction/verification (HEC) field 622. Optionally, one or more fields can be omitted and/or one or more additional fields can be added. In some embodiments, GEM type field 606 is two bits, report message type field 624 is two bits, source epoch ID field 626 is twelve bits, report total size field 628 is fourteen bits, report threshold size field 630 is eight bits, report sequence number field 632 is five bits, one or more source node virtual output queue status fields 634 are each one bit (or a single field of six bits), report priority field 636 is two bits, and header error correction/check (HEC) field 622 is thirteen bits. Alternatively, one or more of the above fields can be larger or smaller.

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

Report sequence number field 632 can indicate which number in the sequence the message is (e.g., whether there is a sequence of related report messages in order to determine whether 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 relative to particular functions/types of data (e.g., CPU/IO, PLOAM, NMCI, CAN, sensors, ethernet). The report priority field 636 CAN indicate what priority is given to the message (e.g., best effort, normal bandwidth request priority, CAN message request priority, power down alarm request priority).

Fig. 6D and 6E illustrate detailed views of two variants of GEM header formats for root port bandwidth grant messages, in accordance with some embodiments. As shown in fig. 6D, for a node grant message with the same node ID as the epoch ID, the header 602 can include a GEM type field 606, an epoch ID field 638, a start time field 640, an grant size field 642, an grant flag field 644, a report command field 646, an grant command field 648, a forced wake-up indicator (FWI) field 650, a burst profile field 652, and a header error correction/verification (HEC) field 622. Optionally, one or more fields can be omitted and/or one or more additional fields can be added. In some embodiments, GEM type field 606 is two-bit, epoch ID field 638 is ten-bit, start time field 640 is fourteen-bit, grant size field 642 is fourteen-bit, grant flag field 644 is one-bit, report command field 646 is three-bit, grant command field 648 is two-bit, forced wake indicator field 650 is one-bit, burst profile field 652 is two-bit, and header error correction/check (HEC) field 622 is thirteen-bit. Alternatively, one or more of the above fields may be larger or smaller.

The 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 an authorization window (e.g., an epoch of the node) that is authorized to the target node, and the authorization size field 642 can indicate the size/duration of the authorization window. The authorization flag field 644 can indicate whether the window is authorized. Report command field 646 can indicate what report is requested from the node/epoch/port. For example, report command field 646 CAN indicate one or more of a Request To Send (RTS) status report without node or a forced node reporting RTS message to a port for black box and diagnostic testing, a forced report of PLOAM and NMCI reporting only CPU-IO messages, CAN messages and sensor data, and PLOAM/NMCI, a forced report of Ethernet packets and CPU-IO/CAN/sensors and PLOAM/NMCI, and/or a forced complete report of PLOAM/NMCI/CPU-IO/CAN/sensors/Ethernet and Node Operation and Control Reporting (NOCR). The grant command field 648 can indicate what type of message/data is granted to the burst window. For example, the grant command field 648 can indicate one or more of windows not used for PLOAM and NMCI messages, grant windows used only for PLOAM messages, grant windows used only for NMCI messages, and/or grants for PLOAM, NMCI, and NOCR messages. The FWI field 650 indicates whether to force wake up the sleeping node, and the burst profile field 652 can indicate burst configuration (e.g., length, pattern, and/or other characteristics of the SOB delimiter, EOB delimiter, and/or preamble).

As shown in fig. 6E, for GEM grant messages with node IDs different from epoch IDs, the header 602 can be substantially the same as the header of fig. 6D, except that the command field 646 and FWI field 650 are not reported. 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 different types of GEM bandwidth grants. For example, field 648 CAN indicate bandwidth grant for all VOQ/CoS (class of service) set for CAN messages only, for sensor data only, for power down warning messages only, and/or for node-based output scheduling of CAN messages and sensor data. In addition, field 648 can force node ID power saving in the event that the node replies with an acknowledgement message.

Fig. 6F illustrates a detailed view of a GEM header format for a control message in accordance with 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, GEM type field 606 is two bits, control message type field 654 is four bits, one or more control message fields together are forty five bits, and header error correction/check (HEC) field 622 is thirteen bits. Alternatively, 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 for processing). In some embodiments, control message type field 654 indicates one or more of a report acknowledge message, a CAN acknowledge message, a flow control message, a power save message, and IO event message (e.g., a power down alarm), a runtime status message, and/or a timestamp update (e.g., from port to node). Control message field 656 can include various control message fields based on a control message type (as shown in control message type field 654).

Thus, the GEM format has the benefit of enabling the bus 104 to package various input data and messages for disparate types of networks (e.g., controller area network, optical network, sensor device broadcast network, wireless network, CPU access network) 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 for 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-header Delimiter (Start-of-Frame-deltaim er) +a Frame Payload (Frame-Payload), wherein the Frame Payload comprises a plurality of GEM Packet (GEM-Packet) data and GEM Control (GEM-Control) messages. 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 the central network 206 and the subnetworks 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 the root port 230 to the gate 202 and/or nodes 204, 208, 234 over the networks 206, 210, including fiber optic, copper, and wireless networks.

In some embodiments, the Burst message is formatted into a Burst-PHY-Frame defined by a preamble + a head-of-Frame Delimiter + a Frame payload + a tail-of-Frame Delimiter (End-of-Frame-deltaframe), wherein the Frame payload includes one or more GEM-Packet data and GEM-Control messages. The size of the Burst-PHY-Frame may vary depending on the size of the total Burst window of the nodes/gates 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 networks 206, 210 including fiber optic, copper, and wireless networks.

Fig. 7A illustrates a Broadcast-PHY-Frame700 in accordance with some embodiments. As shown in fig. 7A, the Broadcast-PHY-Frame700 includes a physical synchronization block (PSBbc) 702 for broadcasting and a Broadcast framing sub-layer Frame 704, the Broadcast framing sub-layer Frame 704 including a GEM control message 706, one or more GEM packets 600, and a framing sub-layer (FS) trailer 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 in accordance with some embodiments. As shown in fig. 7B, burst-PHY-Frame710 includes a physical synchronization block unicast start (PSBuc _sd) 712 of a Burst delimiter, a Burst Framing Sublayer (FS) 714, and a physical synchronization block unicast end (PSBuc _ed) 716 of the Burst delimiter. 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 an FS header 724, one or more epochs 726, and an FS tail 708. Each epoch 726 can include one or more GEM packets 600 having a header 602 and a payload 604 as described above. In some embodiments, the burst FS frame is FEC protected. In particular, by including EOB delimiters (in addition to the SOB delimiters and the size of the frames), structure 710 enables sniffers, analysis engines, or other elements to monitor traffic within bus 104, even if the size of the frames is not known/accessed, it enables elements to determine the end of each burst frame based on the EOB delimiters.

Fig. 7C illustrates a gate Burst-PHY-Frame728 in accordance with some embodiments. As shown in fig. 7C, the gate Burst-PHY-Frame728 can include one or more Burst-PHY-frames 710 that are combined together into a single combined Burst-PHY-Frame having a single preamble 729 and one or more slots 730. Specifically, 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, system 100 provides the advantage of more efficient message communication by combining 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 (which may be up to 256 bytes or more each).

Fig. 8 illustrates a method of operation of the intelligent controller and sensor intranet bus 103 in accordance with 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 kernel 200, then the kernel decapsulates, processes, and transmits the message to its destination without repackaging in step 806. Otherwise, if the destination of the incoming message is one or more other nodes 204, 208 (outside of the core 200), then 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 to the original format of the input data received from one of the devices 102. Alternatively, if the incoming messages are incoming from nodes 234 within core 200, they can be entered and processed by core 200 (without encapsulation), and if their destination is one or more nodes 204, 208 outside of core 200, encapsulated for broadcast only by core 200. This approach thus provides the advantage of enabling communication of many different types of data (e.g., sensor, controller bus, ethernet or other types of data), with more efficient messaging by combining burst frames, and with 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.

Kernel

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, the kernel 200 further includes a secure memory (e.g., secure Digital (SD) memory) node 236 for storing data in a black box memory 238. Alternatively, SD node 236 and/or memory 238 may be omitted. Kernel node 234 enables users to bypass networks 206, 210 and directly couple user plug-in modules (e.g., CPU kernel, WIFI LTE/5G, user application software) to kernel 200.

The core switch 228 includes forwarding engine elements, a queuing buffer manager, and a traffic manager. The forwarding engine element may include a plurality of forwarding engines. For example, the forwarding engine element may include one engine for an 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. In addition, 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 functionality 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 storage approach in combination with store-and-forward schemes and through-the-pass forwarding schemes. For delay sensitive GEM packets and GEM messages, a pass-through forwarding scheme may 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 run-time. The GEM traffic manager supports the dual token policing, single token limiting and output shaping functions of the GEM-ID and NODE-ID libraries, including associated Management Information Base (MIB) counters. GEM-ID library Weighted Random Early Detection (WRED) and tail drop functions 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 transmissions to avoid traffic congestion.

Accordingly, the core switch 228 may provide incoming functionality, the switch 228 receiving GEMs from one or more of the root port 230, the local node 234, the computer 232, and/or other IO ports, processing the GEMs and outgoing, forwarding and transmitting the received GEMs 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, modifying GEM headers and GEM payload ethernet headers (if necessary), and store forwarding (or through buffer storing) GEM packets to one or more hybrid automatic repeat request (HARQ) functional blocks and broadcast MACs of 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 GEMs and to provide a sufficiently large buffer for over-burst GEM traffic. In addition, the switch 228 may support on-the-fly flow control mechanisms within the bus 104, including hybrid dynamic bandwidth allocation and grant (granting) to ensure overall quality of service (QoS) on the bus 104. In addition, 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 buffering WRED/tail dropping, 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 burst mode SERDES IP. Alternatively, one or more of the above elements may be omitted. The transmit MAC of each root port 230 is responsible for receiving GEMs that are ready for outgoing by the switch 228 and/or HARQ, mapping and packing the GEMs into a Broadcast Frame format (e.g., broadcast physical layer Frame (Broadcast PHY-Frame) structure), and broadcasting the GEMs to all gates 202 and/or nodes 204 in the central transport network 206 to which the root port 230 is coupled (e.g., through the root SERDES and optical/copper network Broadcast domains). Instead, the receiving MAC of each root port 230 is responsible for receiving the GEM in Burst Frame format (e.g., burst-PHY-Frame structure) from Burst mode SERDES and gate 202 and/or nodes 204, 208, extracting the GEM from the Burst Frame format, parsing the GEM header of the GEM, and receiving the GEM addressed to the GEM header (e.g., based on the GEM header and system Service Level Agreement (SLA) profile settings), and then outputting the GEM/data to switch 228 for further processing and forwarding. In other words, each root port 230 is capable of receiving bursty traffic from node 204 and/or gate 202 (forwarded from node 208 in subnet 210 of gate 202), converting the bursty traffic into the correct format for processing by switch 228, and then reformatting and broadcasting (through gate 202) the output traffic to all nodes 204 and nodes 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, authorizing burst windows based on the NODE/port/device SLA profile associated with each report, the DBA report data itself, and the Committed Information Rate (CIR)/Peak Information Rate (PIR) feedback to perform HDBA analysis, and authorizing burst windows 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 subnetwork 210) and/or other sources of bandwidth occupancy/traffic congestion, and dynamically allocates a burst transmission window start time and/or size for each node 204, 208. In performing this assignment to node 208 within subnetwork 210, gate 202, which provides access to node 208, is transparent to the HDBA engine. Thus, as described in detail below, gate 202 receives the required data and performs burst transmissions within an allocation window for each node 208 of gate 202 of subnet 210. The HDBA engine may also issue a Report acknowledgement 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 operation, administration and maintenance (PLOAM) GEM messages between the nodes 204, 208, 234 and the root port 230, performing and completing activation and registration of the node 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 transmitting MACs. Alternatively, other encryption may be used. A Forward Error Correction (FEC) engine is used to control errors in data transmissions 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 proper reception of an appropriate burst message (e.g., burst-PHY-Frame). In some embodiments, a fast locking 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, the root port 230 receives a broadcast Data Distribution Service (DDS) message from the nodes 204, 208 informing the root port 230 that a new node/device has joined and registered with the bus 104. Accordingly, the Root Port 230 is configured to always listen for and receive these Data Distribution Service (DDS) messages from the switch 228 and the new nodes 204, 208 that are declared joining the bus 104, and update the Root Port (Root-Port) SLA profile database and settings to reflect the newly added nodes/devices.

Node

Within the bus 104, the edge nodes 204, 208, 234 provide bridging functionality, connect to the external device 102 through the IO port 99 on one side, and connect to the bus intranet 104 through the other side. To provide data from the device 102 coupled to the port 99 of the node 204, 28, the node 204, 208, 234 constructs and transmits a burst message (e.g., a 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 of the subnetwork 210 to which it belongs). Further, in order 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 of data encapsulated as GEM) from the other nodes 204, 208 through the root port 230 (of the network 206 or sub-network 210 thereof to which it belongs), extracts data from 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, encapsulation/decapsulation engines, HARQ blocks, and node MACs. Each port 99 may be one of a CPU interface (e.g., PCIe, SB, and UART), a sensor interface (e.g., MIPI, analog-to-digital converter (ADC), GPIO), an internet interface (e.g., ethernet, etherCAT, and CAN bus), and a motor module interface (e.g., pulse Width Modulation (PWM), I2C, ADC, and GPIO). The encapsulation/decapsulation engine receives input data from port 99 and encapsulates packets, commands (CMD), and messages received from internet ports (e.g., ethernet, wi-Fi), sensor interfaces, motor module interfaces, and CPUs (e.g., PCIe and USB) into GEM format at the ingress. The nodes 204, 208 may then output the encapsulated message (e.g., GEM) to the HARQ and/or the node transmission MAC (described below). At the egress, it receives the GEM packet from the node (from the root port 230 and/or from the other node 204, 208, 234) and decapsulates the GEM back to the original data format (e.g., the data format received from the junction device 102) for output to the device 102 via one of the ports 99. Similar to the root port 230, HARQ of the nodes 204, 208 performs a hybrid automatic repeat request function to ensure successful transmission of GEM packets to one or more of its destination nodes 204, 208, 234. Specifically, HARQ may have built-in retransmission timers, a transmit GEM list flag table, and a receive acknowledgement checking function (e.g., GEM receive acknowledgements) to trigger GEM retransmission if the timers time out without receiving acknowledgements.

The node MACs include a transmit MAC (TX MAC), a receive MAC (RX MAC), a security engine (e.g., AES), a Forward Error Correction (FEC) engine, a DBA-report engine, and SERDES IP. The TX MAC is responsible for mapping/packing GEM into a Burst structure (e.g., burst-PHY-Frame structure) and sending Burst messages to the root port 230 and/or nodes 204, 208, 234 during a Burst window for a node authorized for that node by the dynamic Burst allocation engine of the root port 230. The RX MAC is responsible for receiving and terminating Broadcast messages (e.g., broadcast-PHY-frames) from the root port 230 and/or nodes 204, 208, 234, extracting GEMs from the Broadcast message format, parsing and receiving GEMs addressed to the root port 230 and/or nodes 204, 208, 234 (e.g., addressed to the root port 230 and/or one of the ports 99 of the nodes 204, 208, 234) based on the node's SLA profile settings, and then outputting the data to the encapsulation/decapsulation 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 HDBAs of the associated root port 230 and/or the DBAs of the associated gate 202 and prepares the nodes to send MACs to construct Burst messages (e.g., burst-PHY-frames) with GEMs stored in a queue (e.g., an EPOCH queue).

The node activation processor is responsible for executing and completing 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 receive and transmit MACs. Alternatively, other encryption may be used. FEC engines are used to control errors in data transmissions 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) lock mode to ensure fast fiber cut, fast failover, and protection flip chip recovery.

Finally, after the activation process (e.g., after the registration process is complete), the nodes 204, 206, 234 may broadcast a DDS message to the entire bus 104 to inform 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 and registered with the bus 104 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 that are declared joining the bus 104, and update their global SLA profile databases and settings based on the DDS messages.

Door

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 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 a virtual node processor and/or groups (e.g., one group for each node within the subnet 210), virtual node profiles and settings, and associated MIB counters and reporting logic. The sending MAC receives the GEM from the gate ADB and then sets a map based on the gate's virtual node SLA profile database and packages it into its associated virtual node Burst structure (e.g., burst-PHY-Frame structure). 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-frames) and transmits Burst messages to root port 230 over network 206 based on the authorized Burst windows for those nodes 208 received from the HDBA of root port 230. The node receiving MAC receives Broadcast messages (e.g., broadcast-PHY-Frame) from the root port 230, extracts GEMs from the messages, parses the GEM's header, determines which messages are messages for the nodes 208 within the subnet 210 of the gate 202 based on the GEM header and virtual node SLA profile database settings, and outputs these messages to the ADB.

The ADB performs a bridging function between the node MAC and the root MAC of gate 202. Specifically, in the broadcast direction (from root port 230 to node 208), the ADB receives the MAC receive GEM from the node and performs a GEM header lookup based on the gate virtual node profile database to perform the checking and filtering functions to receive GEM of node 208 belonging to subnet 210 of gate 202. The ADB may then output these GEMs 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 receive MAC, stores the GEM in its associated virtual node buffer memory, and outputs the GEM to the virtual node transmit MAC when its burst window start time arrives.

The root port MAC of gate 202 includes a transmit MAC, a receive MAC, a security engine (e.g., AES), an FEC engine, a gate DBA, and a burst mode SERDES module. The transmit MAC is responsible for receiving GEMs from the ADBs, mapping and packing the GEMs into a Broadcast format (e.g., broadcast-PHY-Frame structure), and outputting frames of the Broadcast format to the burst mode SERDES. The receiving MAC is responsible for receiving Burst messages (e.g., burst-PHY-frames) from Burst mode SERDES (e.g., remote nodes), extracting GEMs from the messages, parsing and receiving only GEMs targeted by nodes 208 within the subnet 210 of the gate 202 (as indicated based on parsed GEM headers and SLA profile settings), and then outputting the GEMs to the ADBs of the gate 202. The DBA of gate 202 is the extended HDBA of root port 230. Gate DBA grants and allocates a node burst window based on 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), a SLA profile table of node identifiers for the portal DBA functions, 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 nodes 208 in a subnet 210. In the receive direction, burst mode SERDES receives Burst messages (e.g., burst-PHY-Frame) from node 208 over subnet 210 and outputs the Burst messages to the root receive MAC for message/Frame termination and GEM extraction.

The primary function of the gate 202 is to extend the central transport network 206 of one of the root ports 230 by bridging to one or more subnets 210 (and nodes 208 therein) adaptively. In particular, gate 202 may burst messages from node 208 and/or other gates 202' within its subnetwork 210 to the root port 230 of the network 206 in which it resides, as if the burst traffic were from a node within the central transport network 206. Similarly, gate 202 may broadcast messages received from other nodes 204, 208, 234, switch 228, and/or root port 230 to other gates 202 'within node 208 and/or sub-network 210 in which it resides, as if node 208 and/or other gates 202' were within 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 burst/broadcast communication methods within the central transport network 206.

In more detail, in the transmission burst direction (e.g., from node/gate to root port/switch/core), the burst window authorization mechanism from node 208 to gate 202 to root 230 can include the following steps. First, the DBA of gate 202 is a subset of the HDBA of root port 230 (root port 230 of network 206, gate 202 being part of network 206), and is therefore transparent to root port 230 and node 208. Second, when gate 202 receives a burst window grant message (e.g., GEM grant message) broadcast from its root port 230, gate 202 uses the message header (e.g., GEM header) to look up the gate SLA profile database to obtain GEM forwarding information. In other words, as indicated in the gate SLA profile database, the gate 202 uses the header data to determine whether the authorization message is for any node 208 within its subnet 210. If the authorization message is not for any node 208 of its subnet 210, gate 202 discards the authorization message, otherwise, the gate stores the message in its virtual node database, updates the database and broadcasts a new window authorization message (e.g., GEM authorization message) to all nodes/gates in its subnet 210 that point to the node 208 to which the original authorization message is directed. In response, node 208 provides a burst message to gate 202, and gate 202 formats the message 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 obtain optimal throughput bandwidth, high burst bandwidth efficiency, and/or low transmission delay, the gate 202 may adjust the grant window indicated in the new grant message to be advanced by at least a predetermined amount of time from the grant window indicated in the original grant message. In particular, this amount of time provides time for gate 202 to receive and format the burst data from node 208 before the data is burst from gate 202 to root port 230 at the time indicated by the original window grant message. In practice, by performing this operation for multiple nodes 208 simultaneously, GATE 202 may aggregate messages (e.g., multiple Burst-PHY-frames) from multiple different nodes into a single larger Burst message (e.g., GATE Burst-PHY-Frame).

Fourth, because of the protocol between gate traffic DBA reporting and root port 230 window authorization, root port 230 and gate 202 may maintain a group member list table and be aware of each gate 230 below as a group's virtual node 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, gate 202 may combine report messages from nodes in its subnet 210 to make reporting more efficient.

Furthermore, when the HDBA of root port 230 is issuing an entitlement message (e.g., a GEM entitlement message) to nodes 208 in subnet 210, because root port 230 is aware of all nodes 208 in subnet 210 (e.g., via a virtual node database), the HDBA of root port 230 may ensure that the entitlement windows belonging to the same gate 202 and/or nodes 208 of subnet 210 are in order/sequential order, such that gate 202 is able to combine and/or burst messages (e.g., burst-PHY-frames) of all virtual nodes except the burst message of the first virtual node, without requiring each burst message to have a preamble. This provides the benefit of reduced preamble overhead and increased burst bandwidth efficiency (especially for small bursts of GEM control messages).

In other words, for the data path, gate 202 receives burst messages (e.g., burst-PHY-frames) from burst mode SERDES and remote NODEs 208, extracts GEMs from messages in the root-receive MAC of gate 202, stores the GEMs in their associated virtual NODE buffer memory, and waits for virtual NODE burst window grants to enter from the root port 230 of those virtual NODEs 208. Gate 202 can then map and package the stored GEMs for that node 208 and other nodes 208 back into a burst message format, thereby aggregating multiple burst messages together into one larger burst message in the node-sent MAC of gate 202. Finally, gate 202 can send the larger burst message to SERDES and to root port 230 over network 206 based on the granted 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/core to node/gate), gate 202 is also able to extend central network 206 to subnetwork 210 while being transparent to both root port 230 of its network 206 and nodes 208 in its subnetwork 210. To achieve this, gate 202 can act like a virtual node and receive a Broadcast message (e.g., broadcast-PHY-Frame) from root port 230, extract GEM from the message, discard any GEM that is not directed to one of nodes 208/gates 202' in its subnet 210 (e.g., as indicated by the message header and gate SLA profile database). Conversely, gate 202 can use store-and-forward schemes and/or pass-through schemes to pack and map GEMs 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, wherein all data messages from nodes 204, 208, 234 (and gate 202) are aggregated to core 200 using a burst transmission method, wherein a transmission window that can be dynamically resized (by core 200) is granted to nodes 204, 208, 234 such that nodes 204, 208, 234 (or gate 202 on behalf of nodes 204, 208, 234) can transmit their data messages as a "burst" within the granted window. If the sending node is in subnet 210, gate 202 (as the root port of this 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 the burst communication, gate 202 may aggregate burst messages from multiple nodes 208 within subnet 210, thereby improving efficiency and reducing the impact of subnet 210 that may increase latency relative to central network 206. Even more, 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. Furthermore, in this process, gate 202 may be transparent to kernel 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 coupling the core 200 to each central network 206), processes the messages (including modifying and/or determining the target destination of the messages), and broadcasts the messages (and any messages originating from the core 200) onto the target nodes 204, 208, 234 (or gates 202 on behalf of the target nodes 208) at whichever central transport network 206 is located. Like the bursty communication above, if the target node 208 is within a subnet 210, the gate 202 bridging to that subnet 210 may receive/intercept messages from the kernel and rebroadcast the messages to all nodes 208 (and/or gate 202') on the subnet 210. Any broadcast messages for a target node 204 that are not on the subnet 210 (or a subnet of the subnet 210) may be discarded by the gate 202 to increase efficiency. Again, the process is transparent and can be repeated by the gate 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 sub-network 210 coupled to network 206) receive all messages broadcast on that network 206 from the core 200, and only need to find which messages are directed to nodes 204, 208, 234 (and gates 202), while other messages are discarded.

In more detail, when a node 204, 208, 234 receives data from one or more external devices 102 through its one or more IO ports 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, gate 202 may collect report messages from multiple nodes 208 (and/or gates 202') in its subnet 210 and aggregate the report messages into a single larger report message that gate 202 can burst more efficiently to root port 230 during the burst window of those ports 208.

Meanwhile, the nodes 204, 208, 234 can encapsulate the input data into GEM format (segment GEM beyond 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 pack the GEM into 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 of each node, the node bursts 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 gate 202) and performs DBA analysis on each node 204, 208 based on the SLA profile database, latency 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 of each node 204, 208. Once the authorized burst window is determined for one or more nodes 204, 208, the root port 230 broadcasts the window to each node, to all nodes 204, 208 in the associated central network 206 and/or any subnetwork 210 (through gate 202) in a broadcast grant message (e.g., GEM grant). As described above, the broadcast messages from root port 230 are of the same size, while the burst window from nodes 204, 208 to root port 230 can change in size as dynamically allocated by the HDBA.

Upon receiving a broadcast grant message for nodes 208 in its subnet 210 (or a subnet of subnet 210), gate 202 broadcasts a new grant message to all nodes 208 of subnet 210. In particular, these new grant messages can specify burst windows that occur before the time indicated by the original/root port grant window. This is to ensure that gate 202 receives (e.g., "bursted") incoming data/GEMs from port 208 prior to the original/root grant window, thereby allowing gate 202 time to aggregate data/GEMs from multiple nodes 208 and/or ports 99 into a single larger message for bursting to root port 230 upon arrival of the original/root port grant window. Thus, the gate 202 can compensate for the inefficiency and/or slower aspects of the subnet 210 such that the subnet 210 does not slow down the efficiency of the central transport network 206.

Upon receiving a burst message including GEM (including 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 source node security keys), bypass the GEM segmentation block, and pass the GEM to switch 228. For each GEM, the switch 228 may then perform a GEM-header lookup, parse and sort the ethernet L2/L3 addresses and headers, process the GEM forwarding flow diagram and determine GEM forwarding destination information, store the GEM in (pass-through) buffer memory, and output the GEM to the HARQ and target root ports 230 (e.g., root ports 230 of which the network 206 or subnetwork 210 includes the 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 subnetwork 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 directed to nodes 208 within its subnet 210 (or a subnet of subnet 210) and broadcasts broadcast messages directed to only one of those nodes 208. Alternatively, gate 202 can rebroadcast all broadcast messages to nodes 208 within subnet 210 of gate 202 without determining whether the message is related 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 other messages. Specifically, for an undelivered message, the nodes 204, 208 decode and error correct the message (e.g., FEC RS (255,216) decode), extract GEM from the broadcast message format (e.g., BC-PHY-Frame), decrypt the extracted GEM (e.g., using AES-128/256 and the destination node's security key), decapsulate the data from the GEM format back to the original IO-Port data format, and output the data to the external device 102 through the designated IO Port 99. Thus, bus 104 and system 100 provide the benefit of being able to combine multiple different networks with different input data, different processing speeds, and data constraints while still maintaining the low latency and high throughput required by a machine automation system. 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 the system 100, in accordance with some embodiments. In addition to the features described above, the external device 102 may also include some or all of the features of the device 400 described below. In general, hardware structures suitable for implementing computing device 400 include a network interface 402, memory 404, processor 406, I/O devices 408 (e.g., readers), bus 410, and 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, so long as the appropriate processor with sufficient speed is selected. Memory 404 may be any conventional computer memory known in the art. Storage 412 may include a hard drive, CDROM, CDRW, DVD, DVDRW, a 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 a keyboard, mouse, monitor, display, printer, modem, touch screen, button interface, and other devices. Operating software/applications 430 or functions/modules thereof may be stored on 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, machine 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 the machine automation system 100 including the 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 the plurality of external devices 102 through one or more ports 99 of the bus 104. In step 504, nodes 204, 208 burst the input data as a burst message to core 200 in a variable size burst window. In some embodiments, for each node 204, 208, the HDBA of the root port 230 dynamically adjusts the burst window start time and size of the variable burst window, and allocates 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, gate 202 may omit a portion (e.g., preamble) of the received burst message to increase the efficiency of 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, prior to the window granted by root port 230, node 208 bursts its data to gate 202, enabling gate 202 to combine multiple burst messages together and burst them in the subsequent original time window. In step 506, the core 200 processes and broadcasts the incoming data as a broadcast message to each node 204, 208 within the central network 206 and the subnetwork 210 that needs to reach the destination 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. This approach thus has the advantage of enabling the bus 104 to remain high speed despite the use of a lower speed network medium.

The system 100 and machine automation controller and sensor bus 104 that implement dynamic burst-to-broadcast transmission networks have a number of advantages. In particular, benefits are provided in terms of simplifying cable systems and connections, greatly reducing electromagnetic interference (EMI) effects using optical fibers, ensuring low latency for node-to-node communications, high throughput bandwidths (10, 25, 100 or higher Gbps) for node-to-node transmissions, being extendable from node to node devices and up to 20km, low power consumption due to passive optical network architecture, industrial level QoS due to centralized DBA scheduling mechanisms that does not cause traffic congestion, built-in HARQ mechanisms that ensure successful node-to-node and GEM transmissions, and one unified software image for the entire intranet system including all gates, nodes and root ports, thereby simplifying software architecture, shortening product development cycles, and simplifying system level debugging, monitoring and troubleshooting.

The 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. The specific embodiments and details thereof are 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 selected embodiments 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 devices thereof to facilitate communication between the devices.

Claims

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

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

A plurality of external machine automation devices operably connected together through ports of the bus, wherein the bus includes a central processing core and a multimedia transmission intranet, the multimedia transmission intranet including:

one or more central transport networks directly coupled to the core and comprising a plurality of nodes and one or more gates; and

a plurality of subnetworks, each subnetwork being connected to a different gate of the central transmission network, the subnetwork comprising a plurality of subnodes;

Wherein, each of the nodes and the subnodes:

Connect to one or more devices through one or more ports.

receiving a message from the one or more devices coupled to the one or more ports;

Encapsulating the message into a general encapsulation mode (GEM) format for transmission to the central processing core; and

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

The GEM format header includes:

a source/destination field identifying one of the ports as the source of the message, or identifying one or more of the nodes and the subnodes as the destination of the message; and

a GEM packet identifier field identifying one or more of the ports to which the message is directed;

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

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

3. The system of claim 2, wherein the header of the GEM format includes a GEM packet type field, the GEM packet type field indicating an original format and a header type of a message encapsulated within the GEM format.

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

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

6. The system of claim 5, wherein the GEM formatted header includes a grant command field indicating one or more types of messages allowed during the granted bandwidth window.

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

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

9. 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 a burst physical layer frame format.

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

11. 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.

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

13. A controller and sensor bus, the bus comprising:

a plurality of input/output ports for interfacing with a plurality of external machine automation devices of the machine automation system,

central processing core; and

A multimedia transmission internal network, the multimedia transmission internal network comprising:

A plurality of subnets, each subnet being connected to a different gate of the central transmission network, the subnet comprising a plurality of subnodes, wherein each of the nodes and the subnodes:

Connect to one or more devices through one or more ports.

The GEM format header includes:

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

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

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

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

18. The bus of claim 17, wherein the GEM formatted header includes a grant command field indicating one or more types of messages allowed during the granted bandwidth window.

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

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

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

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

23. The bus of claim 13, 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.

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

25. A method for operating a controller and sensor bus, the controller and sensor bus comprising a plurality of input/output ports for connecting to a plurality of external machine automation devices of a machine automation system, a central processing core, and a multimedia transmission intranet; the multimedia transmission intranet comprising one or more central transmission networks and a plurality of subnets; the one or more central transmission networks are directly connected to the core and comprise a plurality of nodes and one or more gates; each of the plurality of subnets is respectively connected to a different gate of the central transmission network, the subnet comprising a plurality of subnodes, the method comprising:

One or more of the nodes and the subnodes:

receiving a message from one or more devices coupled to one or more ports associated with the one or more nodes and sub-nodes;

The GEM format header includes:

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

27. The method of claim 26, wherein the header of the GEM format includes a GEM packet type field, the GEM packet type field indicating an original format and a header type of a message encapsulated within the GEM format.

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

29. The method according to claim 25, wherein the header in the GEM format comprises a start time field and an authorized size field, the start time field indicating the time when the authorized bandwidth window starts, and the authorized size field indicating the size of the authorized bandwidth window.

30. The method of claim 29, wherein the GEM formatted header includes a grant command field indicating one or more types of messages allowed during the granted bandwidth window.

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

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

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

34. The method of claim 33, further comprising omitting, using each of the gates, preambles of messages from the plurality of child nodes from a single larger message in the burst physical layer frame format.

35. The method of claim 25, 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.

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