Marking and configuring devices deployed in communication network of vehicle

Abstract

A marking and configuration system for an apparatus for a vehicle to be marked comprises: an Ethernet switch comprising a port; the marking module is connected to the Ethernet switch, generates new identification information for each device, and sends the new identification information to the device through a corresponding port; and the devices connected to the ports, respectively, and including the RAM and the NVM. Each device is configured to: store corresponding new identification information for the device received from the marking module in the RAM, or replace identification information stored in the RAM of the device with the corresponding new identification information in the RAM; and receiving, based on the new identification information, a program from a test device external to the vehicle for reprogramming the device for a dedicated function character within the vehicle.

Description

[0001] introduce

[0002] The information provided in this section is for the purpose of generally presenting the context of the present disclosure. The work of the inventors currently listed (to the extent that it is described in this section) and aspects of the description that may not have been prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art against the present disclosure.

[0003] The present disclosure relates to devices within a communication network of a vehicle, and more particularly to labeling and configuring the devices for corresponding applications.

[0004] A vehicle may include various systems, such as: a body control system; a chassis control system, including a propulsion system, a braking system, a steering system; an infotainment system; a navigation system; and the like. Each system may include corresponding sensors, actuators, and controllers (electronic control units (ECUs)). Each controller has corresponding hardware and software for the application of the controller. For example, a chassis controller includes: i) hardware for receiving inputs from chassis-related sensors and ii) a driver for controlling one or more actuators (such as motors, pumps, etc.) based on the outputs of the sensors. Each system, including corresponding controllers, sensors, and actuators, has a dedicated function, and the controller is located at a dedicated location within the vehicle. Summary of the invention

[0005] A marking and configuration system for multiple devices of a vehicle to be marked is disclosed. The marking and configuration system includes: at least one Ethernet switch including multiple ports; a marking module connected to the at least one Ethernet switch and configured to: generate new identification information for each device and send the new identification information to the device via a corresponding one of the ports; and the devices are respectively connected to the ports and include a random access memory (RAM) and a non-volatile memory (NVM). Each device is configured to: i) perform at least one of the following: store the corresponding new identification information for the device received from the marking module in the RAM, and replace the identification information stored in the RAM of the device with the corresponding new identification information in the RAM, ii) based on the new identification information, receive programming from a test device outside the vehicle for reprogramming the device for a dedicated functional role in the vehicle, and iii) perform a confirmation process and store the corresponding new identification information and the programming in the NVM of the device based on the result of the confirmation process.

[0006] In other features, the devices include identical hardware and, prior to marking and configuration, identical software.

[0007] In other features, at least one device comprises different hardware than another device.

[0008] In other features, the tagging module simultaneously sends new identification information for the devices to the devices via an Ethernet switch.

[0009] In other features, the Ethernet switch is configured to route the new identification information and other messages to the device via the port based on ternary content addressable memory rules.

[0010] In other features, the Ethernet switch is configured to route the new identification information and other messages to the devices via the ports based on User Datagram Protocol identifiers of the ports, the ports being respectively dedicated to the devices as the devices are connected to the ports.

[0011] In other features, the port includes a first connector. The device is connected to the port via a cable. The cable includes second connectors that are respectively connected to the first connectors. Each second connector is compatible with only one first connector.

[0012] In other features, the tagging module is configured to transmit a multicast packet or a unicast packet to the device. The at least one Ethernet switch is configured to route the multicast packet or the unicast packet to the port based on a User Datagram Protocol identifier of the port.

[0013] In other features, during the discovery phase: the tagging module sends discovery requests to the devices; and each device, i) based on one of the corresponding discovery requests, checks whether there is valid identity information stored in the device's NVM, ii) if there is valid identity information, the device self-configures itself using the information stored in the device's NVM, and iii) if there is no valid identity information, the device loads a hardware identifier into the device's NVM and selects a media access control address, an Internet Protocol address, and a diagnostic identifier from a table stored in the device's NVM.

[0014] In other features, the tagging module is configured to send a tagging configuration request to the device after sending the discovery request to indicate new identification information of the device to the device. The device is configured to change the identification information of the device with the new identification information based on the tagging configuration request.

[0015] In other features, the tagging module is configured to receive a tagging status request from the test device and respond to the test device with a status of each device. The device is configured to reprogram the device based on a signal received from the test device in response to the status of each device.

[0016] In other features, the device receives a signal from the test device to reprogram the device according to a unified diagnostic services protocol.

[0017] In other features, a method for marking and configuring a device of a vehicle to be marked is disclosed. The device includes a RAM and an NVM. The method includes: generating new identification information for each device at a marking module, and sending the new identification information to the device via a corresponding port of at least one Ethernet switch, wherein the devices are respectively connected to the ports; and via each device, i) performing at least one of the following: storing the corresponding new identification information for the device received from the marking module in the RAM, and replacing the identification information stored in the RAM of the device with the corresponding new identification information in the RAM, ii) receiving programming from a test device outside the vehicle based on the new identification information for reprogramming the device for a dedicated functional role within the vehicle, and iii) performing a confirmation process and based on the result of the confirmation process, storing the corresponding new identification information and the programming in the NVM of the device.

[0018] In other features, the method further comprises simultaneously sending new identification information for the devices to the devices via the Ethernet switch.

[0019] In other features, the method further comprises routing the new identification information and other messages to the device via the port based on ternary content addressable memory rules.

[0020] In other features, the method further comprises routing the new identification information and other messages to the devices via the ports based on User Datagram Protocol identifiers of the ports, the ports being respectively dedicated to the devices as the devices are connected to the ports.

[0021] In other features, the port includes a first connector. The device is connected to the port via a cable. The cable includes second connectors that are respectively connected to the first connectors. Each second connector is compatible with only one first connector.

[0022] In other features, the method further comprises: transmitting a multicast packet or a unicast packet to the device; and routing the multicast packet or the unicast packet to the port based on a User Datagram Protocol identifier of the port via the at least one Ethernet switch.

[0023] In other features, the method also includes, during the discovery phase: sending a discovery request to the device; checking, via each device and based on one of the corresponding discovery requests, whether there is valid identity information stored in the NVM of the device, if there is valid identity information, self-configuring the device using the information stored in the NVM of the device, if there is valid identity information, loading the hardware identifier into the NVM of the device, and selecting a media access control address, an Internet Protocol address, and a diagnostic identifier from a table stored in the NVM of the device; after sending the discovery request, sending a tagging configuration request to the device to indicate the new identification information of the device to the device; and changing the identification information of the device with the new identification information via the device and based on the tagging configuration request.

[0024] In other features, the method further comprises receiving, at the marking module, a marking status request from the test device and responding to the test device with a status of each device; and reprogramming the device based on a signal received from the test device in response to the status of each device.

[0025] A first aspect of the present disclosure provides a marking and configuration system for a plurality of devices of a vehicle to be marked, the marking and configuration system comprising:

[0026] at least one Ethernet switch including a plurality of ports;

[0027] a labeling module connected to the at least one Ethernet switch and configured to: generate new identification information for each of the plurality of devices, and send the new identification information to the device via a corresponding one of the plurality of ports; and

[0028] The multiple devices are respectively connected to the multiple ports and include a random access memory (RAM) and a non-volatile memory (NVM), and each of the multiple devices is configured to: i) perform at least one of the following: store the corresponding new identification information for the device received from the marking module in the RAM, and replace the identification information stored in the RAM of the device with the corresponding new identification information in the RAM, ii) based on the new identification information, receive programming from a test device outside the vehicle for reprogramming the device for a dedicated functional role within the vehicle, and iii) perform a confirmation process and based on the result of the confirmation process, store the corresponding new identification information and the programming in the NVM of the device.

[0029] According to the marking and configuration system of the first aspect of the present disclosure, the plurality of devices include the same hardware and include the same software before marking and configuration.

[0030] According to the marking and configuration system of the first aspect of the present disclosure, at least one device among the plurality of devices comprises hardware different from that of another device among the plurality of devices.

[0031] According to the marking and configuration system of the first aspect of the present disclosure, the marking module simultaneously sends the new identification information for the multiple devices to the multiple devices via an Ethernet switch.

[0032] According to the marking and configuration system of the first aspect of the present disclosure, the Ethernet switch is configured to: route the new identification information and other messages to the multiple devices via the multiple ports based on a ternary content addressable memory rule.

[0033] According to the marking and configuration system described in the first aspect of the present disclosure, the Ethernet switch is configured to: route the new identification information and other messages to the multiple devices via the multiple ports based on the User Datagram Protocol identifiers of the multiple ports, and since the multiple devices are connected to the multiple ports, the multiple ports are respectively dedicated to the multiple devices.

[0034] According to the marking and configuration system of the first aspect of the present disclosure, wherein:

[0035] The plurality of ports includes a first connector;

[0036] The plurality of devices are connected to the plurality of ports via cables;

[0037] The cable includes second connectors respectively connected to the first connectors; and

[0038] Each second connector is compatible with only one first connector.

[0039] According to the marking and configuration system of the first aspect of the present disclosure, wherein:

[0040] The tagging module is configured to transmit a multicast data packet or a unicast data packet to the plurality of devices; and

[0041] The at least one Ethernet switch is configured to route the multicast data packet or the unicast data packet to the plurality of ports based on User Datagram Protocol identifiers of the plurality of ports.

[0042] According to the marking and configuration system of the first aspect of the present disclosure, during the discovery phase:

[0043] The tagging module sends a discovery request to the plurality of devices; and

[0044] Each device of the plurality of devices, i) based on one of the corresponding discovery requests, checks whether there is valid identity information stored in the NVM of the device, ii) if the valid identity information is present, the device self-configures itself using the information stored in the NVM of the device, and iii) if the valid identity information is not present, the device loads a hardware identifier into the NVM of the device and self-selects a media access control address, an Internet Protocol address, and a diagnostic identifier from a table stored in the NVM of the device.

[0045] According to the marking and configuration system of the first aspect of the present disclosure, wherein:

[0046] The tagging module is configured to: after sending the discovery request, send a tagging configuration request to the multiple devices to indicate the new identification information of the multiple devices to the multiple devices; and

[0047] The plurality of devices are configured to change identification information of the plurality of devices with the new identification information based on the marking configuration request.

[0048] According to the marking and configuration system of the first aspect of the present disclosure, wherein:

[0049] The tagging module is configured to receive a tagging status request from the test device and respond to the test device with a status of each of the plurality of devices; and

[0050] The plurality of devices are configured to reprogram the devices based on signals received from the testing device in response to a state of each of the plurality of devices.

[0051] According to the marking and configuration system of the first aspect of the present disclosure, the plurality of devices receive signals from the test device according to a unified diagnostic service protocol to reprogram the devices.

[0052] A second aspect of the present disclosure provides a method for marking and configuring a plurality of devices of a vehicle to be marked, wherein the plurality of devices include a random access memory (RAM) and a non-volatile memory (NVM), the method comprising:

[0053] generating new identification information for each of the plurality of devices at a tagging module, and sending the new identification information to the device via a corresponding one of a plurality of ports of at least one Ethernet switch, wherein the plurality of devices are respectively connected to the plurality of ports; and

[0054] Via each of the plurality of devices, i) performing at least one of the following: storing corresponding new identification information for the device received from the marking module in a RAM, and replacing identification information stored in the RAM of the device with the corresponding new identification information in the RAM, ii) receiving programming from a test device outside the vehicle based on the new identification information for reprogramming the device for a dedicated functional role within the vehicle, and iii) performing a confirmation process and storing the corresponding new identification information and the programming in the NVM of the device based on a result of the confirmation process.

[0055] The method according to the second aspect of the present disclosure further includes: simultaneously sending the new identification information for the multiple devices to the multiple devices via an Ethernet switch.

[0056] The method according to the second aspect of the present disclosure further includes: routing the new identification information and other messages to the multiple devices via the multiple ports based on a ternary content addressable memory rule.

[0057] The method according to the second aspect of the present disclosure also includes: routing the new identification information and other messages to the multiple devices via the multiple ports based on the User Datagram Protocol identifiers of the multiple ports, and since the multiple devices are connected to the multiple ports, the multiple ports are respectively dedicated to the multiple devices.

[0058] The method according to the second aspect of the present disclosure, wherein:

[0059] The plurality of ports includes a first connector;

[0060] The plurality of devices are connected to the plurality of ports via cables;

[0061] The cable includes second connectors respectively connected to the first connectors; and

[0062] Each second connector is compatible with only one first connector.

[0063] The method according to the second aspect of the present disclosure further includes:

[0064] transmitting a multicast data packet or a unicast data packet to the plurality of devices; and

[0065] The multicast data packet or the unicast data packet is routed to the plurality of ports based on User Datagram Protocol identifiers of the plurality of ports via the at least one Ethernet switch.

[0066] The method according to the second aspect of the present disclosure further comprises during the discovery phase:

[0067] sending a discovery request to the plurality of devices;

[0068] checking, via each of the plurality of devices and based on one of the corresponding discovery requests, whether there is valid identity information stored in a NVM of the device, if there is valid identity information, self-configuring the device using information stored in the NVM of the device, if there is valid identity information, loading a hardware identifier into the NVM of the device, and self-selecting a media access control address, an Internet Protocol address, and a diagnostic identifier from a table stored in the NVM of the device if there is no valid identity information;

[0069] After sending the discovery request, sending a tag configuration request to the plurality of devices to indicate new identification information of the plurality of devices to the plurality of devices; and

[0070] The identification information of the plurality of devices is changed with the new identification information via the plurality of devices and based on the marking configuration request.

[0071] The method according to the second aspect of the present disclosure further includes:

[0072] receiving, at the tagging module, a tagging status request from the test device and responding to the test device with a status of each of the plurality of devices; and

[0073] The devices are reprogrammed based on signals received from the testing device in response to a status of each of the plurality of devices.

[0074] Further areas of applicability of the present disclosure will become apparent from the detailed description, claims and drawings.The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] The present disclosure will be more fully understood from the detailed description and accompanying drawings, in which:

[0076] Figure 1 is a functional block diagram illustrating an example tagging and configuration process for devices within a vehicle having an Ethernet network topology according to the present disclosure;

[0077] Figure 2 is a functional block diagram of an example device to be marked and configured according to the present disclosure;

[0078] Figure 3 is a functional block diagram of a marking module, an Ethernet switch, and an unmarked device according to an example Ethernet network topology of the present disclosure;

[0079] Figure 4 is a signal flow diagram illustrating an example marking and configuration process according to the present disclosure;

[0080] Figure 5 An example marking method according to the present disclosure is illustrated;

[0081] Figure 6 are example methods of operating a device to be marked and configured according to the present disclosure; and

[0082] Figure 7 is a diagram of an example tagging message format according to the present disclosure.

[0083] Among the drawings, reference numerals may be repeated to identify similar and / or identical elements. DETAILED DESCRIPTION

[0084] Manufacturing vehicles with multiple controllers (or ECUs) with corresponding hardware and software is expensive. This is due to the number of different controllers and the different types of software involved, as well as the complexity of integrating the controllers into a single vehicle. Connecting the different controllers to each other and to sensors and actuators within the vehicle as part of a local area network (LAN) and configuring the controllers to communicate with each other, sensors, actuators, and test equipment outside the vehicle is complex.

[0085] Examples described herein include marking and configuration systems and methods for marking and configuring devices such as controllers and other electronic devices. Devices being marked are referred to as unmarked devices, while devices that have been marked are referred to as marked devices. Marking includes determining the intended application of each unmarked device and providing the device with correct identification information, such as a correct media access control (MAC) address, an Internet protocol (IP) address, a diagnostic identifier (ID), etc. The correct identification information replaces the default identification information stored in the unmarked device during manufacturing. In one embodiment, a vehicle is provided with multiple controllers having the same part number and therefore the same hardware and software. The controller is marked and configured for the corresponding intended application. When configured, the controller is provided with programming for the intended application. As an example, a body controller is provided with body programming, a chassis controller is provided with chassis programming, etc. This occurs in the vehicle after the controller is installed. The problem of configuring multiple devices with the same or similar hardware design re-instantiated in the same vehicle is solved by the disclosed marking method of dynamic device configuration after the device is inserted into the vehicle Ethernet network. This includes configuring the device with a device-specific and dedicated identity (such as a MAC address, IP address, and diagnostic identifier) ​​and with device-specific and dedicated software content (or programming) based on the specific functional role of the device within the vehicle. These examples also apply to vehicles with two or more controllers with different part numbers, calibrations, hardware, and / or software.

[0086] Dynamically tagging and configuring multiple devices (e.g., controllers) is a complex problem. At a high level, the examples disclosed in this article provide:

[0087] 1) A vehicle Ethernet network topology and the specific use of (one or more) Ethernet switches to support the marking and configuration process; 2) an overall marking and configuration strategy; and 3) software algorithms and detailed communication data for completing the marking and configuration process. With respect to item 1, a topology is disclosed that includes i) a marking module, ii) an Ethernet switch, iii) a device to be marked, which may be referred to as a marking client, and iv) an external test device. The test device is connected to the vehicle network and is used to provide specified programming when configuring the device. Each port of the Ethernet switch specifies the role of a marking client connected to the Ethernet switch, as further described below. The marking process can be triggered by the test device or automatically started by the marking module. The marking and configuration process includes discovery, reprogramming, and confirmation phases. In one embodiment, each device is reprogrammed simultaneously to reduce manufacturing time.

[0088] Software algorithms executed by a tagging module and a tagging client are disclosed. The present invention defines the Ternary Content Addressable Memory (TCAM) rules used specifically, including rules for Virtual Local Area Network (VLAN) membership and communication data payload transmission over a User Datagram Protocol (UDP) socket (or connector) for dynamically assigning MAC addresses, IP addresses, UDP port numbers and diagnostic identifiers using multicast and / or unicast Ethernet frames. The present invention also defines the request / response handshake between the tagging module and the tagging client.

[0089] Figure 1The marking and configuration process for devices within a vehicle 100 having an Ethernet network topology is shown. The vehicle 100 includes a marking module (which may be referred to as a marking manager) 102, an Ethernet switch 104, and devices 106, 108, 110, 112. Device 106 is connected to a sensor and / or actuator 114. Device 108 is connected to a sensor and / or actuator 116. Device 110 is connected to a sensor and / or actuator 118. Device 112 is connected to a sensor and / or actuator 120. The Ethernet switch 104 has a first port 130 connected to the marking module 102, a second port 132 connected to a test device (or diagnostic tester) 134, and ports AD connected to the devices 106, 108, 110, 112, respectively. In one embodiment, the devices 106, 108, 110, 112 are controllers with the same part number, the same hardware, and the same initial software. Any number of devices may be included on the vehicle and connected to corresponding ports of the Ethernet switch and tagged and configured as disclosed herein. In one embodiment, one or more devices have different part numbers, hardware, and / or initial software than one or more other devices being tagged and configured. In one embodiment, the vehicle 100 includes more than one Ethernet switch. Each Ethernet switch may be connected to a tagging module, a test device, another Ethernet switch, and / or one or more devices being tagged and configured.

[0090] The marking and configuration process includes an initial phase 140, when the device to be marked and configured is installed and in an initial default state with initial default identification information, software and programming. Then a discovery marking phase is performed and the device is marked, designated as phase 142. The marked device is then configured, designated as phase 144.

[0091] The vehicle Ethernet network topology supports the marking and configuration process. The device to be marked acts as a marking client, which is connected to the marking module 102 through one or more Ethernet switches (one Ethernet switch 104 is shown). Multiple Ethernet switches can be cascaded in the Ethernet network topology as long as the marking module 102, the marking clients 106, 108, 110, 112 and the test device 134 are connected. In one embodiment, (one or more) Ethernet switches are integrated as part of the marking module 102 or as part of one of the marking clients 106, 108, 110, 112. (One or more) Ethernet switches can be (one or more) independent switches in the vehicle Ethernet network. The test device 134 is connected to the same Ethernet network and communicates with the marking module 102 and the marking clients 106, 108, 110, 112 using a standard diagnostic protocol such as a unified diagnostic service (UDS). In one embodiment, the test device 134 learns the identification information of each of the devices 106, 108, 110, 112 based on at least one of the ports into which the devices 106, 108, 110, 112 are plugged. In another embodiment, the test device 134 does not necessarily know where a certain device is plugged in. In one embodiment, the test device 134 does not know where the devices 106, 108, etc. are plugged in but knows whether the devices 106, 108, etc. are present on the vehicle. The tagging module 102 ensures that the devices 106, 108, etc. are tagged with the correct ID so that the test device 134 can communicate with and program the devices 106, 108, etc.

[0092] The functional role of each of the tagging clients 106, 108, 110, 112 is determined by which switch port the tagging client is connected to. After being inserted into one of the switch ports (e.g., one of ports AD), the device is tagged and programmed to be the functional role associated with the port. In other words, the port of the Ethernet switch 104 specifies the functional role of the tagging client connected to the port. For example, port A can be dedicated as a body control port, port B can be dedicated as a chassis control port, port C can be dedicated as an infotainment port, port D can be dedicated as a navigation system port, etc. The devices connected to these ports perform the functional role associated with the port. As an example, device 106 performs the functional role as a body control module, device 108 performs the functional role as a chassis control module, device 110 performs the functional role as an infotainment control module, and device 112 performs the functional role as a navigation control module. In one embodiment, the functional roles of devices 106, 108, 110, and 112 span different domains. In another embodiment, the functional roles of the devices 106, 108, 110, 112 are domain independent and therefore designed to optimize specific vehicle areas, but still retain unique physical and functional partitioning and allocation strategies that distinguish them from each other. If a device is removed from one port of the Ethernet switch 104 and connected to another port, the device can be re-labeled and reconfigured.

[0093] Figure 2 Shown as Figure 1 Device 200 is a representative example of any of devices 106, 108, 110, 112. Device 200 may include a control module 202 and a memory 204. The control module 202 may include various circuits and components 206, drivers 207, inputs 208 and reference terminals 209, such as: high-side drivers; low-side drivers; discrete inputs; analog inputs; pulse width modulation (PWM) inputs; half-bridge rectifiers; return, reference, battery and ground terminals; serial data devices; dedicated terminals (e.g., audio terminals, antenna terminals or other terminals), etc. The control module 202 can receive analog inputs and / or discrete inputs. The memory 204 may include a random access memory (RAM) 210 and a non-volatile memory (e.g., flash memory) 212. The RAM 210 may be included in the control module 202. The control module 202 may include and / or be connected to any number of ports 220. One of the ports 220 may be connected to Figure 1The first port 130 of the Ethernet switch 104 of the control module 202. Other ports 220 can be connected to corresponding sensors and / or actuators. These other ports may include standard mechanical ports, controller area network (CAN) bus ports, local interconnect network (LIN) bus ports, etc. These other ports may include Ethernet ports or non-Ethernet ports. In one embodiment, these other ports include one or more Ethernet ports connected to one or more sensors or actuators. The sensors and actuators can be connected to corresponding ones of the following items, controlled and / or driven by corresponding ones of the following items: circuits and components 206, drivers 207, inputs 208 and / or terminals 209. As an example, a discrete switch can be docked with a discrete input of the control module 202. An analog switch (e.g., a ladder resistor) can be docked with an analog input of the control module 202. During the marking and configuration process disclosed herein, the device 200 can be reprogrammed for loads such as sensors and actuators.

[0094] Figure 3 An Ethernet network topology 300 is shown, which includes a tagged module 102, an Ethernet switch 302, and untagged devices 106, 108, 110, 112. The tagged module 102 includes a port 304, which is connected to a first port 306 of the Ethernet switch 302. The Ethernet switch 302 also includes a second port 308 and device ports 310, 312, 314, 316, which are connected to corresponding connectors of ports 318, 320, 322, 324 (also labeled AD) of the devices 106, 108, 110, 112 via cables 326, 328, 330, 332. Figure 1 Ports AD may be configured similarly to ports 318, 320, 322, 324. Cables 326, 328, 330, 332 include first connectors 334, 336, 338, 340 and second connectors 342, 344, 346, 348. Marking module 102 also includes a manufacturer's enable counter (MEC) 349, which is further described below.

[0095] The examples provided herein also include configuration guarantees defined by the physical system, leveraging error prevention and connector polarity to avoid swapping the locations of devices and ports. Each port is associated with a specific location of a device in the vehicle. For example, port A is associated with a first location of a device connected to port A, port B is associated with a second location of a device connected to port B, port C is associated with a third location of a device connected to port C, and port D is associated with a fourth location of a device connected to port D. Any device located at a location associated with port A is connected to port A. This is ensured by a cable that has a connector that is compatible with the connector of port A and that is located at a dedicated location within the vehicle. Cables for other devices connected to ports B, C, and D do not have connectors that are compatible with port A. This is true for each port AD that has a specified connector. As Figure 3 As shown in FIG. 1 , each of the first connectors 334 , 336 , 338 , 340 is compatible with a corresponding one of the connectors of one of the ports 310 , 312 , 314 , 316 , and is not compatible with another connector of another of the ports 310 , 312 , 314 , 316 .

[0096] The second connectors 342, 344, 346, 348 are identical and may be connected to any of the devices 106, 108, 110, 112. While each of the devices 106, 108, 110, 112 may be connected to any of the connectors 342, 344, 346, 348, one of the devices 106, 108, 110, 112 located at a designated location of one of the connectors of one of the ports 318, 320, 322, 324 is connected to the connector and assumes the functional role associated with the one of the ports 310, 312, 314, 316 to which the one of the ports 310, 312, 314, 316 is connected via a corresponding one of the cables 326, 328, 330, 332. In other words, the functional roles of devices 106, 108, 110, 112 depend on where the devices 106, 108, 110, 112 are placed within the vehicle, respectively, and therefore on which of cables 326, 328, 330, 332 the devices 106, 108, 110, 112 are connected to.

[0097] In conventional systems, the connection between the cable of the device and the port of the Ethernet switch may be swapped during manufacturing with a high probability. To prevent this, ports 310, 312, 314, 316 have different connector designs that match and are compatible with the designs of connectors 334, 336, 338, 340, respectively, to minimize the risk of incorrect device connection during and / or after vehicle manufacturing. Due to the specific location of the device in the vehicle, the probability of swapping the device and the cable connector is low.

[0098] The Ethernet switch disclosed herein implements TCAM rules for determining the destination port of a received frame. Figure 3 , the Ethernet switch 302 sends frames received from the marking module 102 to ports 310, 312, 314, 316 via port 306 based on TCAM rules. These frames can be multicast frames or unicast frames. In an embodiment, the TCAM rules direct multicast frames and unicast frames to only one selected from ports 310, 312, 314, 316. This can be done based on the UDP destination indicated by the frame. For example, frames intended to mark a device connected to port 310 are only sent to port 310. In another embodiment, the TCAM rules direct multicast frames or unicast frames to ports 310, 312, 314, 316. Each of ports 310, 312, 314, 316 receives multicast frames or unicast frames for the port. In this example, each of devices 106, 108, 110, 112 only accepts frames directed to the port of the device. Each of the devices 106, 108, 110, 112 may listen to all frames (or packets) transmitted from the marking module 102, but may only receive frames (or packets) intended for the port into which the device is plugged.

[0099] exist Figure 1 and 3 In the example of , the marking module 102 is shown as sending two multicast frames (or signals) to two UDP ports. Figure 1 In , the signal is designated as 150, 152. Figure 3 , the signals are designated as 350, 352. The UDP ports may have UDP identifiers such as "101" and "104." Frames for UDP port 101 are sent to the Ethernet switches 104, 302, which then transmit them to a corresponding one of ports AD associated with UDP ports 101, 104 (e.g., ports A and D), as shown.

[0100] Figure 4A signal flow diagram illustrating an example labeling and configuration process is shown, which includes a self-identification phase 400, a discovery phase 402, a reprogramming phase 404, and a confirmation phase 406. Although primarily referring to Figure 1-3 The process is described using the example of , but the process is applicable to other in-vehicle Ethernet network topologies. The marking module 102 is programmed at the factory with software and calibration that provides knowledge of how to mark devices (e.g., devices 106, 108, 110, 112). Each device may be a microcontroller unit (MCU).

[0101] During the self-identification phase 400, each device (e.g., devices 106, 108, 110, 112) connected to the Ethernet switch (e.g., Ethernet switch 104, 302) checks the hardware part number and / or NVM partition of the device, which indicates the initial default address and identifier of the device, including MAC and IP addresses and diagnostic identifiers. For purposes of example, the labeling and configuration process is described with respect to a single device 407, which may be any one of the devices 106, 108, 110, 112 or other devices. This is designated as 410.

[0102] During the discovery phase 402, Figure 1 and Figure 3 The tagging module 102 tags the device with a unique hardware ID, the same hardware ID, or a combination of both. The discovery phase automatically runs when the MEC 349 of the tagging module is greater than 0. For example, when the vehicle is not with the customer and is being manufactured, being shipped to a dealer, or is at a dealer, the MEC 349 may be greater than zero. When the MEC 349 is zero, the tagging module 102 is only triggered by a routine ID (RID) designated as signal 412 from the test device 134.

[0103] The tagging module 102 sends a multicast discovery request to each device, one of which is designated as 414. The tagging module 102 sends the discovery request to ensure the existence of the device and to retrieve the current identifier of the device. Each multicast request includes a unique UDP port number and is only routed to a specific Ethernet output switch port based on TCAM rules defined in the Ethernet switch and / or Ethernet output switch port. Since each request has a corresponding unique UDP port number, when the request arrives at device 407, device 407 knows what UDP port should be used to respond to the tagging module 102 in response to the received request. The discovery response from device 407 is designated as 416.

[0104] The device 407 checks whether there is valid identity information (e.g., MAC address, IP address, and diagnostic ID) in the NVM of the device 407. If there is valid identity information stored in the NVM, the device 407 uses the identity information stored in the NVM to configure itself. If there is no valid identity information stored in the NVM, the device 407 loads the hardware ID of the device 407 from the NVM, and then selects the corresponding MAC address, IP address, and diagnostic ID from the lookup table stored in the NVM of the device 407. The device 407 responds to the discovery request 414 of the tagging module with the self-selected tagging identity of the device 407 using the UDP port number received from the discovery request. The UDP port number is included in the discovery response 416. The discovery response 416 may include a MAC address, an IP address, a diagnostic ID, a status bit, and a hardware ID. The status bit indicates whether the device has been programmed or not. The device 407 operates in a boot mode during the discovery phase 402, and runs in an application mode when the vehicle is with the customer and powered on.

[0105] The tagging module 102 receives responses from the devices and then sends multicast tagging configuration requests to the devices to let the devices know their expected identities (e.g., MAC addresses, IP addresses, diagnostic IDs, and / or other identification information). Each multicast tagging configuration request is routed only to specific switch ports based on TCAM rules defined in the Ethernet switch. Configuration request 418 is shown and may include a MAC address, IP address, diagnostic ID, and status bits. The status bits may indicate that the device is not programmed. Each device receives the multicast tagging configuration request and will change its identity (e.g., MAC address, IP address, diagnostic ID, and / or other identification information) accordingly, but the new identity information is initially stored in RAM and not in the NVM of the device. This is because: if the reprogramming phase for one of the devices fails later, the device reverts back to its original untagged state or the previous tagged state. Each device sends a configuration response back to the tagging module 102 after matching its identity with the new configuration request to confirm the completion of the tag discovery phase. The configuration response is designated as 420 and may include a MAC address, IP address, diagnostic ID, and status bits. A status bit may indicate that the device has not been programmed.

[0106] During the reprogramming phase 404, the test device 134 sends a tagging status request designated as 422 to the tagging module 102. The tagging module 102 responds to the test device 134 with the status of all devices (i.e., all taggable devices or devices to be tagged). The tagging status response is designated as 424. The tagging status response 424 indicates which devices are ready to be programmed. If one of the devices is invalid, meaning that the device should not be programmed, the tagging status response 424 indicates this information. The status information was previously collected during the discovery phase 402.

[0107] Based on the marking status of the device reported by the marking module, the test device 134 simultaneously initiates a device flash reprogramming operation for each device that has not been programmed to configure (or program) the device. This may include, for example and for each device: storing identity information and software in the NVM of the device, the software including a program for the functional role of the device. The program is then executed by the device when the functional role is implemented. The programming is represented by signal 426 and may include diagnostic programming as well as calibration and switch binaries. Since the device has been configured with appropriate identity information (e.g., MAC address, IP address, diagnostic ID and / or other identification information) in the RAM of the device, the test device 134 is able to communicate with each device using UDS through a statically defined socket (or connector) to perform flash reprogramming. After flash reprogramming, the device has been marked with identity information stored in its flash (i.e., NVM) memory. At the end of the flash reprogramming phase, the test device 134 issues a reset request to each device. The reset request is designated as 428. Resetting may include powering off and backing up the device.

[0108] During the confirmation phase 406, the test device 134 reissues the tag discovery RID and the tag module 102 collects the tag status of the device again. The RID request signal is shown and designated as 430. Another discovery request signal is sent from the tag module 102 to the device, one of which is designated as 432. The device responds with a discovery response signal, one of which is designated as 434. The discovery response signal may include the MAC address, IP address, diagnostic ID and status bit of the device. The status device of the programmed device indicates that the device is programmed. Then, the test device 134 sends a tag status request 436 to the tag module 102, and the tag module 102 reports the collected tag status to the test device 134. A tag status response signal 438 is shown. The test device 134 determines whether all devices have been successfully tagged and programmed and whether reprogramming should be performed for any device. If reprogramming should be performed for any device, the tagging, reprogramming and confirmation phases 402, 404, 406 can be repeated for the devices that have not been successfully tagged and reprogrammed.

[0109] Additional Discovery Phase Details

[0110] Reference again Figure 1 and Figure 3 , the marking module 102, the test device 134, and the device being marked include software algorithms for performing the marking and configuration process. The marking module 102 and the device to be marked communicate on a dedicated marking VLAN (e.g., VLAN2). The marking module 102 sends multicast IP-UDP messages, such as discovery and configuration requests, to the device to be marked. The destination UDP port number of the marking message is selected by the marking module 102 based on the physical location of the device to be marked (e.g., 01:00:5e:40:00:00-239.192.0.0-101). The device to be marked opens a set of IP-UDP sockets (or connectors) to listen for discovery and configuration requests sent by the marking module 102 (e.g., 239.192.0.0-101 / 102 / 103 / 104 / etc.). The discovery request is used to ensure the existence of the device and receive knowledge of the current configuration of the device. The configuration request is used to instruct the correct MAC address, IP address, diagnostic ID, and tag and configuration status.

[0111] The Ethernet switch forwards each of the multicast requests from the tagging module 102 only to the specified Ethernet switch port based on the destination address and UDP port number for the multicast request. This is achieved according to the TCAM rules stored inside the Ethernet switch. The Ethernet switch checks and determines the tag multicast and UDP port number of the received frame based on the TCAM rules, and guides the frame to the corresponding egress port of the Ethernet switch. When a discovery request is received, the device sends a discovery response indicating the currently configured MAC address, IP address, diagnostic ID and tagging status to the tagging module 102. When a configuration request is received from the tagging module 102, the device modifies and confirms its configuration as instructed, and then sends a configuration response indicating the newly configured / confirmed MAC address, IP address, diagnostic ID and tagging status to the tagging module 102.

[0112] Other marking status details

[0113] The status of the labeling and configuration process is indicated throughout the process. For example, a device will maintain a labeling status tag in the device's NVM while it is being labeled. A labeling status of "unlabeled" indicates that the device has never been modified from its initial default configuration. A labeling status of "temporary / ready to program" indicates that the device has temporarily modified its configuration as instructed due to a received labeling configuration request, but that the configuration will not be saved to the device's NVM and used in subsequent power cycles until diagnostic programming and calibration occurs.

[0114] A tagging status of "confirmed / ready to program" indicates that the configuration of the device has been matched to the configuration instructed via the tagging configuration request, but diagnostic programming and calibration have not yet occurred. A tagging status of "programmed" indicates that the device has undergone diagnostic programming and calibration to save the new configuration to the NVM of the device. The device may contain a list of valid possible IDs that the device may be marked with. If the tagging request commands an unknown / invalid ID, the device detects that the unknown / invalid ID is not in the list of possible IDs and responds to the tagging module 102 with the status "invalid request". The tagging module 102 collects and maintains a list of tagging status responses from all devices and stores them in the memory of the tagging module 102.

[0115] Additional reprogramming phase details

[0116] The test device 134 requests the marking module 102 to report the marking status of the devices to be marked. The test device initiates the reprogramming of the devices that still need to be marked using predefined sockets (or connectors) that contain the correct MAC and IP addresses and diagnostic IDs for these devices. The test device 134 reprograms the devices simultaneously because each communication with one of the devices uses a separate, different and designated socket (or connector). The test device 134 reprograms the software and calibration values ​​of the devices. In one embodiment, if the device has its own firmware and configuration, it will be reprogrammed after the device's software and calibration are updated. After reprogramming, the device also updates its marking tag in the device's NVM.

[0117] Additional Confirmation Phase Details

[0118] After all reprogramming is completed, the test device 134 issues a device reset command to the reprogrammed devices. After the reset, the test device 134 and the marking module 102 collect the marking status again to confirm that the marking process of the device is successful, that is, all devices to be marked have identities and functional roles that match the expected identities and functional roles of the Ethernet switch ports to which the devices are connected.

[0119] Figure 5 A marking method that may be implemented by the marking module 102 during the marking phase is shown. At 500, the marking module 102 determines whether the MEC is greater than 0. If not, operation 502 is performed, otherwise operation 504 is performed.

[0120] At 502, the tagging module 102 determines whether the RID has been received from the test device 502. If yes, operation 504 is performed. At 504, the tagging module 102 generates a tag discovery request (multicast or unicast request) and sends the request to the device to be tagged using different UDP ports. The request is routed to the corresponding port based on the TCAM rules.

[0121] At 506, the tagging module 102 determines whether the discovery time period has passed since the discovery phase began. If so, operation 508 is performed. At 508, the tagging module 102 generates or updates an existing information table of devices connected to the Ethernet switch and that have been tagged or are being tagged, including generating or updating identity information for each device. At 510, the tagging module 102 issues a tagging configuration request to the device being tagged based on the static information in the NVM of the device and / or the NVM of the tagging module 102.

[0122] At 512, the marking module 102 determines whether the marking configuration period has expired. If so, operation 514 is performed. At 514, the marking module 102 generates or updates the marking status table and responds to the RID as needed. The method can end after operation 514.

[0123] Figure 6 A method of operating a device to be marked and configured is shown. The following operations may be performed by any device being marked. During the marking phase, the following operations may be performed by the control module of the device being marked.

[0124] At 600 , the control module determines whether a valid tag ID (eg, MAC address, IP address, diagnostic ID) has been provided to the device during calibration. If not, operation 602 is performed, otherwise operation 606 is performed.

[0125] At 602, the control module obtains the local hardware ID of the device from the NVM of the device. At 604, the control module selects a tagging ID from a lookup table based on the hardware ID. The lookup table may have been provided by the tagging module 102 and / or stored in the NVM of the device.

[0126] At 606, the control module stores the tag ID in a memory stack of the device's RAM. At 608, the control module determines whether a tag discovery request has been received. If so, operation 610 is performed. At 610, the control module selects a connector (or socket) of an Ethernet switch having a UDP port identified in the tag discovery request. At 612, the control module responds to the tag discovery request with the tag ID via the selected connector.

[0127] At 614, the control module determines whether a tag configuration request has been received. If so, operation 616 is performed. At 616, the control module reconfigures the memory stack with a new tag ID, which may be stored in the RAM of the device. This includes replacing a previously stored tag ID and / or a previously stored ID with the new tag ID received from the tag module. At 618, the control module responds to the tag configuration request with the new tag ID.

[0128] Figure 7A tagging message format diagram 700 is shown, which illustrates an example format of a tagging message sent between the tagging module 102 and one of the devices being tagged. The tagging message may include a layer 2 Ethernet frame header 702, a destination MAC address 704, a source MAC address 706, a VLAN ID 708, a layer 3 Internet Protocol header (IPv4) 710, a source IP address 712, a destination IP address 714, a layer 4 UDP datagram header 716, a source port ID 718, a destination port ID 720, a tagging message 722, a message type 724, a MAC address 726, an IP address 728, a diagnostic ID 730, and a tagging status 732. The message type indicates whether the message is a discovery request, a discovery response, a configuration request, or a configuration response. The tagging status indicates whether the corresponding device is tagged, is in a temporary and ready-to-program state, is in a confirmed and ready-to-program state, is programmed, or has received an invalid request. This format can be used in Figure 1-3 Any of the above frames, data packets and signals sent between the marking module 102 and the device. This format can also be used in Figure 1-3 The messages sent between the test device 134 and the device.

[0129] The above examples allow multiple devices (e.g., ECUs) to have the same or similar hardware and be dynamically configured, i.e., labeled, configured, and programmed when inserted into the vehicle architecture. Labeling, configuration, and programming allow the devices to perform their own distinct functional roles. This process significantly reduces hardware design and manufacturing costs and minimizes software variation and complexity. The disclosed examples also allow multiple devices to be labeled simultaneously to reduce manufacturing time. These examples also provide robust fault recovery if any failure occurs during reprogramming.

[0130] The described process can be used during vehicle manufacturing or when the vehicle is serviced. During vehicle service, one device can be replaced with a new device and / or two devices can be exchanged. The above process can be performed to mark and reprogram the new device and / or to remark and reprogram the exchanged device. The process can be implemented when a new device with stored default software content is inserted into the vehicle for the first time. As an example, the process can be performed when a short-range radar module is inserted into the vehicle Ethernet network and operates as a left-front radar device for collision avoidance applications. In this case, the radar module is marked as a "left-front position radar device" using specific identity information, calibration and software content. The process can also be implemented when an already configured, i.e., marked device is exchanged from one functional role to another and is therefore re-marked with a different identity and functional software content.

[0131] The foregoing description is essentially merely illustrative and is in no way intended to limit the present disclosure, its application or use. The broad teachings of the present disclosure can be implemented in a variety of forms. Therefore, although the present disclosure includes specific examples, the true scope of the present disclosure should not be so limited, because other modifications will become apparent after studying the drawings, descriptions and appended claims. It should be understood that one or more steps in the method can be performed in different orders (or simultaneously) without changing the principles of the present disclosure. In addition, although each embodiment is described as having specific features above, any one or more of those features described with respect to any embodiment of the present disclosure can be implemented in any other embodiment and / or combined with the features of any other embodiment, even if the combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and the arrangement of one or more embodiments to each other is still within the scope of the present disclosure.

[0132] The spatial and functional relationships between elements (e.g., between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including "connected," "engaged," "coupled," "adjacent," "next to," "on top of," "above," "below," and "disposed." Unless explicitly described as "directly," when describing the relationship between a first element and a second element in the above disclosure, the relationship can be a direct relationship, in which there are no other intermediate elements between the first element and the second element, but can also be an indirect relationship, in which there are one or more intermediate elements (spatially or functionally) between the first and second elements. As used herein, the phrase "at least one of A, B, and C" should be interpreted to mean a logical (A or B or C), using a non-exclusive logical "or," and should not be interpreted to mean "at least one of A, at least one of B, and at least one of C."

[0133] In the drawings, the direction of the arrows, as indicated by the arrows, generally demonstrates the flow of information (e.g., data or instructions) of interest to the illustration. For example, when component A and component B exchange various information, but the information transmitted from component A to component B is relevant to the illustration, the arrow may be directed from component A to component B. This unidirectional arrow does not mean that no other information is transmitted from component B to component A. In addition, for information sent from component A to component B, component B may send a request or a receipt confirmation of the information to component A.

[0134] In this application, including the definitions below, the term "module" or the term "controller" may be replaced with the term "circuit". The term "module" may refer to, be part of, or include: an application specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor circuit (shared, dedicated, or group) that executes code; a memory circuit (shared, dedicated, or group) that stores code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system on a chip.

[0135] The module may include one or more interface circuits. In some examples, the interface circuit may include a wired or wireless interface connected to a local area network (LAN), the Internet, a wide area network (WAN), or a combination thereof. The functions of any given module of the present disclosure may be distributed between multiple modules connected via the interface circuit. For example, multiple modules may allow load balancing. In a further example, a server (also referred to as a remote or cloud) module may perform some functions on behalf of a client module.

[0136] The term "code" as used above may include software, firmware, and / or microcode, and may refer to a program, a routine, a function, a class, a data structure, and / or an object. The term "shared processor circuit" encompasses a single processor circuit that executes some or all of the code from multiple modules. The term "group processor circuit" encompasses a processor circuit that executes some or all of the code from one or more modules in combination with an additional processor circuit. References to multiple processor circuits encompass multiple processor circuits on discrete dies, multiple processor circuits on a single die, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above. The term "shared memory circuit" encompasses a single memory circuit that stores some or all of the code from multiple modules. The term "group memory circuit" encompasses a memory circuit that stores some or all of the code from one or more modules in combination with additional memory.

[0137] The term "memory circuit" is a subset of the term "computer-readable medium". As used herein, the term "computer-readable medium" does not cover transient electrical or electromagnetic signals propagated through a medium (such as on a carrier wave); therefore, the term "computer-readable medium" may be considered to be tangible and non-transitory. Non-limiting examples of non-transitory, tangible computer-readable media are non-volatile memory circuits (such as flash memory circuits, erasable programmable read-only memory circuits, or mask read-only memory circuits), volatile memory circuits (such as static random access memory circuits or dynamic random access memory circuits), magnetic storage media (such as analog or digital magnetic tape or hard disk drives), and optical storage media (such as CDs, DVDs, or Blu-ray discs).

[0138] The apparatus and methods described in this application may be implemented in part or in whole by a special purpose computer created by configuring a general purpose computer to perform one or more specific functions embodied in a computer program. The above-mentioned function blocks, flow chart components and other elements serve as software specifications, which can be translated into a computer program by routine work of a skilled technician or programmer.

[0139] The computer program includes processor executable instructions stored on at least one non-transitory tangible computer readable medium. The computer program may also include or rely on stored data. The computer program may include a basic input / output system (BIOS) that interacts with the hardware of the special-purpose computer, device drivers that interact with specific devices of the special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0140] A computer program may include: (i) descriptive text to be parsed, such as HTML (Hypertext Markup Language), XML (Extensible Markup Language), or JSON (JavaScript Object Notation), (ii) assembly code, (iii) object code generated by a compiler from source code, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. By way of example only, source code may be written using syntax from a language including: C, C++, C#, Objective C, Swift, Haskell, Go, SQL, R, Lisp, Fortran, Perl, Pascal, Curl, OCaml, HTML5 (Hypertext Markup Language Fifth Edition), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Visual Lua, MATLAB, SIMULINK, and

Claims

1. A marking and configuration system for a plurality of devices of a vehicle to be marked, the marking and configuration system comprising: at least one Ethernet switch including a plurality of ports; a labeling module connected to the at least one Ethernet switch and configured to: generate new identification information for each of the plurality of devices, and send the new identification information to the device via a corresponding one of the plurality of ports; as well as The multiple devices are respectively connected to the multiple ports and include a random access memory (RAM) and a non-volatile memory (NVM), and each of the multiple devices is configured to: i) perform at least one of the following: store the corresponding new identification information for the device received from the marking module in the RAM, and replace the identification information stored in the RAM of the device with the corresponding new identification information in the RAM, ii) based on the new identification information, receive programming from a test device outside the vehicle for reprogramming the device for a dedicated functional role within the vehicle, and iii) perform a confirmation process and based on the result of the confirmation process, store the corresponding new identification information and the programming in the NVM of the device.

2. The marking and configuration system of claim 1, wherein the plurality of devices comprise identical hardware and, prior to marking and configuration, identical software.

3. The marking and configuration system of claim 1, wherein at least one device of the plurality of devices comprises different hardware than another device of the plurality of devices. 4 . The marking and configuration system according to claim 1 , wherein the marking module sends the new identification information for the plurality of devices to the plurality of devices simultaneously via an Ethernet switch.

5. The marking and configuration system of claim 1, wherein the Ethernet switch is configured to route the new identification information and other messages to the plurality of devices via the plurality of ports based on ternary content addressable memory rules.

6. The marking and configuration system of claim 1 , wherein the Ethernet switch is configured to route the new identification information and other messages to the multiple devices via the multiple ports based on the User Datagram Protocol identifiers of the multiple ports, and since the multiple devices are connected to the multiple ports, the multiple ports are respectively dedicated to the multiple devices.

7. The marking and configuration system according to claim 1, wherein: The plurality of ports includes a first connector; The plurality of devices are connected to the plurality of ports via cables; The cable includes second connectors respectively connected to the first connectors; and Each second connector is compatible with only one first connector.

8. The marking and configuration system according to claim 1, wherein: The tagging module is configured to transmit a multicast data packet or a unicast data packet to the plurality of devices; as well as The at least one Ethernet switch is configured to route the multicast data packet or the unicast data packet to the plurality of ports based on User Datagram Protocol identifiers of the plurality of ports.

9. The marking and configuration system of claim 1, wherein during the discovery phase: The tagging module sends a discovery request to the plurality of devices; and Each device of the plurality of devices, i) based on one of the corresponding discovery requests, checks whether there is valid identity information stored in the NVM of the device, ii) if the valid identity information is present, the device self-configures itself using the information stored in the NVM of the device, and iii) if the valid identity information is not present, the device loads a hardware identifier into the NVM of the device and self-selects a media access control address, an Internet Protocol address, and a diagnostic identifier from a table stored in the NVM of the device.

10. The marking and configuration system according to claim 9, wherein: The tagging module is configured to: after sending the discovery request, send a tagging configuration request to the multiple devices to indicate the new identification information of the multiple devices to the multiple devices; and The plurality of devices are configured to change identification information of the plurality of devices with the new identification information based on the marking configuration request.

Images