System for network segment isolation with variable configurations in a vehicle

Abstract

System and method for an in-vehicle network comprising a microcontroller unit (MCU) located within the vehicle, which includes an internal Ethernet switch and an auxiliary core manager, wherein the MCU hosts one or more software builds and the auxiliary core manager manages the internal Ethernet switch and the software builds. An external Ethernet switch located within the vehicle connects one or more ports of the internal Ethernet switch to one or more devices through one or more virtual local area networks (VLANs), wherein, upon a reflash event, the auxiliary core manager generates a VLAN configuration and filter rule for the internal switch that associates the software builds with the MCU ports based on a MAC and IP address of each MCU port.

Description

[0001] Vehicles are rapidly integrating increasingly sophisticated technological components into their systems. Specifically designed microcontrollers, technologies, and sensors can be used in a wide variety of applications within a vehicle. Automotive microcontrollers and sensors can be used to enhance automated systems, providing customers with state-of-the-art experiences and services, such as body control, camera vision, information display, safety, and autonomous driving. Furthermore, functions like adaptive cruise control, lane departure warning, and vehicle proximity detection can utilize a variety of sensors, including light detection and ranging (LIDAR), radio detection and ranging (RADAR), ultrasound, and other wireless technologies, to perform their functions.

[0002] However, the productive use of such advanced systems may require periodic software updates to add and revise various functions. Furthermore, such updates can be performed more efficiently for various reasons, such as size, when distributed across multiple microcontrollers in a new distribution scheme. Therefore, the ability to reflash software builds within the microcontrollers is crucial for vehicle operation.

[0003] US 2023 / 0 360 448 A1 describes a network segment isolation system, specifically a device comprising a policy acquisition circuit, a parameter acquisition circuit, and a parameter storage circuit. The policy acquisition circuit interprets a vehicle policy data value with at least one requested vehicle property. The parameter acquisition circuit interprets vehicle parameter values ​​from providing endpoints, each located in at least one network zone of a vehicle. The parameter storage circuit selectively stores a portion of the vehicle parameter values. A first portion of the stored vehicle parameter values ​​is stored on a storage endpoint that is distinct from any associated providing endpoint for at least a first portion of the stored vehicle parameter values.The parameter memory circuit also determines a reserved amount of memory by specifying a set of data to be collected in order to support at least some of the vehicle parameter values.

[0004] It can be considered a task to specify an improved system for network segment isolation with variable configurations in a vehicle.

[0005] This document describes a network segment isolation system with variable configurations in a vehicle. As described herein, microcontrollers or microcontroller units, referred to as MCUs, can periodically receive software uploads or updates, which may be called reflash events. Software uploads may contain one or more software builds, where a software build may be associated with a specific function of the vehicle, such as a braking function, a body control function, a navigation function, etc. Such examples are not intended to be limiting but rather illustrate possible functionalities.

[0006] Furthermore, modern vehicle architecture, including software-defined vehicles, can consist of multiple MCUs with advanced functionality and cybersecurity capabilities. The MCUs can typically host multiple software containers, each dedicated to a specific vehicle function. End devices can be used to control sensors and actuators employed in vehicle operation. Each end device can only accept commands from one specific software container among those running on one or more MCUs. Network segmentation can be used to isolate traffic between end devices and authorized software containers from the rest of the network. Such segmentation and isolation are orthogonal to cryptographic authentication but can be used in conjunction with authentication methods if desired.Furthermore, such segmentation and isolation can be used when a software container changes its MAC addresses and location, either within an existing MCU or in the case of relocating the software container or software build to a different MCU.

[0007] A system according to the invention for network segment isolation with variable configurations in a vehicle is described, which includes a network within the vehicle. The network includes a microcontroller unit (MCU) located within the vehicle, which includes an internal Ethernet switch and an auxiliary core manager. The MCU is designed to host one or more software builds, and the auxiliary core manager is used to manage the internal Ethernet switch and the various builds running on the MCU. The system also includes an external Ethernet switch located within the vehicle to connect one or more ports of the internal Ethernet switch to one or more devices via one or more virtual local area networks (VLANs).Then, upon a reflash event, the auxiliary core manager executes filter rules to partition one or more VLANs by partitioning the network or communication paths. The auxiliary core manager also creates a VLAN configuration and filter rule for the internal switch based on an access control policy and identifies the association of one or more software builds with one or more MCU ports based on the MAC and IP address of each MCU port. The auxiliary core manager also updates a VLAN configuration and filter rule on the external switch to enable one or more VLANs based on the association of one or more software builds with one or more MCU ports.

[0008] In one embodiment, the system comprises a second MCU located inside the vehicle, which includes a second internal Ethernet switch and a second auxiliary core manager, wherein the second MCU hosts one or more software builds and the second auxiliary core manager manages the second internal Ethernet switch.

[0009] In one embodiment, the filter rules are applied to the external Ethernet switch, and each of the one or more software builds is associated with a fixed IP address and a location-dependent MAC address.

[0010] In one embodiment, the auxiliary core manager determines the location of one or more software builds using an Address Resolution Protocol (ARP).

[0011] In one embodiment, the filter rules are applied to the internal Ethernet switch, and each of the one or more software builds is associated with a fixed IP address and a location-dependent MAC address.

[0012] In one embodiment, the internal Ethernet switch is used to verify the communication between a software build and a device, and the verification involves comparing configuration data, including the location-dependent MAC address, with an associated VLAN.

[0013] In one embodiment, the configuration data is contained within an auxiliary core manager build.

[0014] In one embodiment, the external switch is coupled with an edge-to-bus device or a specialized electronic device.

[0015] In one embodiment, the auxiliary core manager is further used to verify a configuration update on the external Ethernet switch, which involves receiving a digital signature using a valid certificate.

[0016] In one embodiment, the auxiliary core manager is further used to verify a configuration update on the internal Ethernet switch, which involves either a subroutine-based challenge-response or a calibration file-based procedure. Fig. Figure 1 is an illustration of a variety of possible vehicle sensors as described. Fig. Figure 2 is an illustration of a system of MCUs with network segment isolation as described. Fig. Figure 3 is an illustration of a system of MCUs with network segment isolation as described. Fig. Figure 4 is an illustration of a system of MCUs with network segment isolation as described. Fig. Figure 5 is a flowchart of an ARP learning-based procedure for blocking VLANs as described. Fig. Figure 6 is a flowchart of a switching configuration procedure following a reflash event as described. Fig. Figure 7 is a flowchart of a network configuration retrieval procedure as described. Fig. Figure 8 represents a flowchart of a network segment isolation procedure with variable configurations in a vehicle as described.

[0017] With reference to the drawings, the leftmost digit of a reference number identifies the drawing in which the reference number first appears (e.g., a reference number "310" indicates that the element so numbered is the first to be labeled or first to be shown). Fig. 3 appears). Additionally, elements that have the same reference number followed by a different letter of the alphabet or another distinguishable marker (e.g., an apostrophe) indicate elements that may be the same in structure, operation, or form, but can be identified as being located in different places in space or recurring at different times (e.g., the reference numbers '110a' and '110b' may indicate two different input devices that may be functionally identical, but may be located at different points in a simulation arena).

[0018] Vehicles have become increasingly sophisticated in terms of computing technology, equipped with multiple microcontrollers, cameras, sensors, processors, and control systems. This includes, for example, autonomous vehicles and advanced driver assistance systems (AV / ADAS) such as adaptive cruise control, automated parking, automatic brake hold, automatic braking, evasive steering assist, lane keeping assist, adaptive headlights, reversing assist, blind spot detection, cross-traffic alert, local hazard warning, and automatic braking, which can rely on information obtained from cameras and sensors on the vehicle. Microcontrollers or microcontroller units (MCUs) can be used throughout a vehicle to host and execute code in software containers.Such software code can be updated periodically without requiring a physical replacement of MCUs.

[0019] Fig. Figure 1 illustrates a vehicle 100 with integrated sensors 110 according to an embodiment of the present description. Such sensors can support the use of automated functions such as autonomous driving and, as discussed, the control and management of vehicle functions within one or more MCUs. For example, the vehicle 100 may include a light detection and ranging sensor (LIDAR sensor) 115, an inward- or outward-facing camera sensor 120 (as shown by camera sensors 120-1 to 120-4), an ultrasonic sensor 125, an inertial measurement unit sensor (IMU sensor) 130, a steering angle sensor 135, and wheel speed sensors 140-1 and 140-2, to name just a few.The camera sensor 120 can also include multiple camera sensors positioned around and throughout the vehicle, for example, camera sensor 120-1 mounted through the forward-facing windshield, camera sensor 120-2 located at the front of the vehicle, facing forward, camera sensor 120-3 located on the left side of the vehicle (with another side-mounted camera sensor on the right side of the vehicle (not shown)), and camera sensor 120-4 located at the rear of the vehicle. Other additional cameras and sensors in other locations may also be included to provide additional views and / or operations.

[0020] Fig. Figure 2 illustrates a configuration 200 utilizing multiple MCUs, according to one embodiment of the present description. The configuration 200 is shown to include two MCUs, MCU 210-1 and MCU 210-2. Both MCUs include an internal Ethernet switch, shown as internal switch 220-1 in MCU 210-1 and internal switch 220-2 in MCU 210-2. The internal switches can also be controlled by an auxiliary core manager, with auxiliary core manager 215-1 controlling internal switch 220-1 and auxiliary core manager 215-2 controlling internal switch 220-2. The auxiliary core manager can also coordinate the installation and configuration of software builds, including installation in the correct locations as specified in a VLAN configuration and filter rule. Also shown are several different software builds residing within each MCU.For example, Bodybuild 212-1 is highlighted as the currently authorized build within MCU 210-1, but MCU 210-1 may also contain additional builds, such as XXX Build 212-2 and YYY Build 212-3. Similarly, MCU 210-2 may also contain additional builds, such as ZZZ Build 212-4 and ABCD Build 212-5.

[0021] Configuration 200 can also include an external switch, such as the external switch 240, to connect one or more MCUs, e.g., the MCU 210-1 and the MCU 210-2, to other devices, such as end devices, including the edge-to-bus (E2B) devices 250-1, 250-2 through 250-N. The end devices can also include specialized electronic devices (SE devices or SE-DEV), such as SE-DEV #1 255-1. In some embodiments, an SE device may include a processor and the ability to support cryptographic capabilities, including authentication. In other embodiments, E2B devices may not include a processor.

[0022] As shown in configuration 200, MCU 210-1 and MCU 210-2 can be connected to an external switch, such as external switch 240, using virtual local area networks (VLANs), such as VLAN 230-1, VLAN 230-2, VLAN 230-3, VLAN 230-4, VLAN 230-5, and VLAN 230-6. As discussed later, different VLANs can be configured so that authorized builds are able to communicate with one or more end devices, while other builds are blocked from accessing such end devices. Such VLAN configurations can be determined by creating a VLAN configuration and filter rule based on an access control policy. For example, configuration 200 illustrates that the VLANs associated with XXX build 212-2, YYY build 212-3, ZZZ build 212-4 and ABCD build 212-5 are isolated from end devices 250-1 and 250-2.Such blocking or filtering can be achieved at the internal switch level, the external switch level, or both. Additionally, each build can be associated with a fixed IP address and a location-based MAC address, which, as shown, can be used to filter and enable / disable different VLANs on specific communication links. This allows an authorized build, such as bodybuild 212-1 in configuration 200, which can move within or between MCUs, to communicate with devices it is authorized to communicate with.

[0023] Fig. Figure 3 illustrates a configuration 300 that uses the same multiple MCUs as configuration 200, according to one embodiment of the present description. Configuration 300 illustrates moving bodybuild 212-1 within MCU 210-1, which changes the MAC address associated with bodybuild 212-1. When a build is moved within one MCU or across another as a result of a reflash event, the VLANs can be updated to reflect the change of location, allowing an authorized build to communicate with the appropriate end device while blocking unauthorized builds. Thus, in configuration 300, YYY-Build 212-3, ZZZ-Build 212-4 and ABCD-Build 212-5 can be isolated and blocked from communication with the end devices 250-1 and 250-2, either at the internal switch level or the external switch level or both.Additionally, VLANs can be reconfigured so that the bodybuild 212-1, the end devices 250-1 and 250-2 are part of the same VLAN, for example by using VLAN 330-1, VLAN 330-2, VLAN 330-3, VLAN 330-4 and VLAN 330-5.

[0024] The term isolation in this context may not mean that a node is prevented from communicating at all. Instead, it can partition the entire group of network nodes into a set of disjoint subgroups, so that the nodes configured to communicate with each other are part of the same subgroup. Each subgroup can be assigned one or more VLANs, allowing each to be associated with a specific functional area. For example, the same subgroup might have one VLAN used for data and a second one used for control. If nodes in this subgroup wanted to send a control message, they would tag the message with the ID of the control VLAN for that subgroup. If they wanted to send a data message, they would tag it with the ID of the data VLAN.

[0025] Different subgroups can have their own control and data VLANs. Certain subgroups may have functional VLANs that other subgroups might not. Accordingly, a VLAN can be a way to identify a subgroup and a channel dedicated to a specific type of communication (e.g., data, control, etc.).

[0026] Fig. Figure 4 illustrates a configuration 400 that uses the same multiple MCUs as configuration 200, according to one embodiment of the present description. Configuration 400 illustrates moving bodybuild 212-1 outside of MCU 210-1 and across MCU 210-2. When a build is moved within one MCU or across another as a result of a reflash event, the VLANs can be updated to reflect the change of location, allowing an authorized build to communicate with the appropriate end device while blocking unauthorized builds. Thus, in configuration 400, YYY build 212-3 and ABCD build 212-5 can be blocked, either at the internal switch level, at the external switch level, or both.Additionally, VLANs can be reconfigured so that the VLANs of bodybuild 212-1 share one or more VLANs with end devices 250-1, 250-2 to 250-N. For example, VLANs 430-2, 430-3, and 430-4 can include bodybuild 212-1 and end devices 250-1, 250-2 to 250-N respectively, while VLAN 430-1 cannot include devices 250-1, 250-2 to 250-N, thus blocking the builds located in MCU 210-1 from communicating with these end devices.

[0027] Fig. Figure 5 is a flowchart of a Method 500 that uses the Address Resolution Protocol (ARP) for VLAN network segment isolation, according to one embodiment of the present description. As mentioned earlier, a build can be associated with a location-dependent MAC address and a static IP address. Thus, in the event of a reflash, i.e., a software update, the location of a build can change on an MCU. There can be a number of reasons for a change in the location of a build, such as the size of the software build, compatibility between an MCU and an end device, etc. For example, if a vehicle can be manufactured, a particular build can reside in one MCU, e.g., body build 212-1, which resides in MCU 210-1, as shown in Figure 5. Fig. 2 shown, but for some reason it is desirable to move this build to a different location, e.g., bodybuild 212-1, which is located in MCU 210-2, as shown in Fig. Figure 4 shows that while the IP address associated with Bodybuild 212-1 remains constant, the MAC address and corresponding VLANs associated with Bodybuild 212-1 may need to be updated due to its change in location. Such an update can be achieved by filtering on the external switch using ARP learning, as described below.

[0028] Table 1 below is an example of four builds residing in four different MCUs at different site ports within each MCU. These are presented as examples and are not intended to be restrictive. As shown, prior to ARP learning, each build site is associated with a specific MAC address and unknown IP addresses. Additionally, the four VLANs associated with the builds are enabled for each build. Table 1 - ARP - before learning Port MAC-Adresse IP-Adresse VLANs aktiviert MCU #1 Port 10 02:00:00:01:6f:11 unbekannt Build 1, Build 2, 02:00:00:01:6f:12 unbekannt Build 3, Build 4 MCU #2 Port 12 02:00:00:01:70:21 unbekannt Build 1, Build 2, 02:00:00:01:70:22 unbekannt Build 3, Build 4 MCU #3 Port 6 02:00:00:01:71:31 unbekannt Build 1, Build 2, 02:00:00:01:71:32 unbekannt Build 3, Build 4 MCU #4 Port 7 02:00:00:01:73:51 unbekannt Build 1, Build 2, 02:00:00:01:73:52 unbekannt Build 3, Build 4

[0029] Fig. Procedure 5 begins at step 510 by enabling each of the VLANs, as shown above in Table 1. If the ARP table is not populated, as in the example in Table 1, Procedure 500 ends at step 515 until the table is populated. In one embodiment, the switch host, or, as shown in Fig. The auxiliary core manager 215-1 for MCU 210-1 and / or the auxiliary core manager 215-2 for MCU 210-2 send a command to each detected MAC address to retrieve the associated IP addresses and assigned VLANs. The result of such a request is shown in Table 2, with the ARP table now populated. Table 2 - ARP - filled Port MAC-Adresse IP-Adresse VLANs aktiviert MCU #1 Port 10 02:00:00:01:6f:11 10.22.1.119 Build 1, Build 2, 02:00:00:01:6f:12 10.22.1.132 Build 3, Build 4 MCU #2 Port 12 02:00:00:01:70:21 10.22.1.129 Build 1, Build 2, 02:00:00:01:70:22 Build 3, Build 4 MCU #3 Port 6 02:00:00:01:71:31 10.22.1.130 Build 1, Build 2, 02:00:00:01:71:32 10.22.1.124 Build 3, Build 4 MCU #4 Port 7 02:00:00:01:73:51 10.22.1.130 Build 1, Build 2, 02:00:00:01:73:52 10.22.1.127 Build 3, Build 4

[0030] However, as shown in Table 2, at this point each of the detected MAC addresses has enabled its associated VLANs. Thus, procedure 500 can proceed to disable VLANs that are not associated with and authorized by a particular build on a specified MCU and port. Then, once the ARP table is populated and determined in step 515, as shown in the example in Table 2, in step 520 the variables N, X, and Y are set to a minimum value. The variable N can represent an MCU identifier, the variable X represents an IP address associated with MCU #N, and the variable Y represents a VLAN in the set of available VLANs. In step 525, a comparison can be made to determine if the IP address of a particular MCU, identified by its MAC address, is associated with a specific VLAN.If not, then at step 530 a determination can be made as to whether X has reached a maximum value. If not, the variable X is indexed by one at step 535 and returned to step 525. If, at step 525, the IP address of a specific MCU, identified by its MAC address, is associated with a specific VLAN, then at step 545 a determination can be made as to whether Y is maximized; if not, Y is indexed by one at step 547 and returned to step 525.

[0031] If X is maximized at step 530, then VLAN Y can be disabled from the MCU #N port at step 532, and the procedure can proceed to step 545. The procedure continues in this way, testing whether Y is maximized at step 545, whether X is maximized at step 550, and whether N is maximized at step 555. Furthermore, if X is not maximized at step 550, the procedure proceeds to step 540 with Y set to a minimum value, and continues to step 535 with X indexed. Similarly, if N is not maximized at step 555, the procedure proceeds to step 560 with X and Y minimized and N indexed, and continues to step 525.

[0032] The result of procedure 500 can be shown in the example below in Table 3. Table 3 - ARP - after learning / deactivating Port MAC-Adresse IP-Adresse VLANs aktiviert MCU #1 Port 10 02:00:00:01:6f:11 10.22.1.119 Build 1, 02:00:00:01:6f:12 10.22.1.132 MCU #2 Port 12 02:00:00:01:70:21 10.22.1.129 02:00:00:01:70:22 Build 4 MCU #3 Port 6 02:00:00:01:71:31 10.22.1.130 Build 2, 02:00:00:01:71:32 10.22.1.124 MCU #4 Port 7 02:00:00:01:73:51 10.22.1.130 02:00:00:01:73:52 10.22.1.127 Build 3,

[0033] Table 3 illustrates an example where a single VLAN is now associated with each port of the switch and thus with each detected build. It is possible that in some cases more than one VLAN may be enabled on a particular switch port. The disabled VLANs are also referred to as a breakthrough, as these VLANs are not used by the associated MCU / port.

[0034] Fig. Figure 6 illustrates a Method 600 with filter rules on the internal switch according to an embodiment of the present description. Method 600 is directed to use the internal switch to verify that traffic tagged with a VLAN tag originates from the correct MAC address associated with that VLAN. In case of a mismatch, the internal switch can drop the associated traffic. Since builds can change locations, the switch can learn new MAC addresses and update VLAN port associations each time a build changes locations. Such associations can be described by VLAN configuration and filter rules based on an access control policy.

[0035] Starting at step 610, a reflash event can occur. If the reflash occurs, the VLANs and MAC addresses associated with each build can be retrieved at step 620. In some implementations, two options may be offered. The first is where network configuration data, which may be contained in or embedded within code, is flashed to the auxiliary core manager, for example, auxiliary core managers 215-1 and 215-2, which are included in Fig. 2. This information is discussed and then subsequently read by the appropriate local helper core manager. Secondly, the helper core manager can use an algorithm / subroutine to retrieve information from specific locations in the code flash of each build.

[0036] In step 630, the VLANs on each MCU switch can be configured based on the data retrieved in step 620. Then, in step 640, an access control policy can be set on each MCU to specify which source MAC addresses can transmit on which VLAN.

[0037] Fig. Figure 7 illustrates a method 700 relating to retrieving network configuration data according to an embodiment of the present description. Fig. Step 620 represents the retrieval of VLAN and MAC addresses associated with each build. Procedure 700 begins by identifying a list of builds, or cohorts, and proceeds through this list in step 710. In step 720, a harmonization identifier, also known as a transaction identifier, can be read from the list of builds. In step 730, the harmonization identifier can be mapped to a real-time unit (RTU). An RTU can be hardware used to run software that provides the mapping using a decoding algorithm. In step 740, the RTU can then be used to identify IP addresses, and in step 750, these IP addresses can be used to identify the VLANs. Thus, in steps 730, 740 and 750, the harmonization identifier can be used to map to the identified VLANs.In step 760, the harmonization identifier can be mapped to a virtual switch interface, and in step 770, the virtual switch interface can be mapped to a MAC address. Thus, in steps 760 and 770, the harmonization identifier can also be mapped to a MAC address. At what point in step 780 can the mapping table be updated, and then the process continues with the next element in the list in step 790?

[0038] Fig. Figure 8 presents an exemplary embodiment of a flowchart of Method 800, a method for network segment isolation with variable configurations in a vehicle according to an embodiment of the present description. Method 800 begins at step 805 with hosting, within a microcontroller unit (MCU) located within the vehicle, one or more software builds, the MCU further comprising an internal Ethernet switch and an auxiliary core manager to manage the internal Ethernet switch and the associated software builds. As shown in Figure 800, the MCU is further divided into three parts. Fig. As discussed in section 2, configuration 200 can include multiple MCUs, each of which can contain one or more software builds and an internal switch. For example, the MCU can include an internal Ethernet switch, shown as internal switch 220-1 in MCU 210-1 and internal switch 220-2 in MCU 210-2. The internal switches can also be controlled by an auxiliary core manager, with auxiliary core manager 215-1 controlling internal switch 220-1 and auxiliary core manager 215-2 controlling internal switch 220-2. Furthermore, the auxiliary core managers can also coordinate the installation and configuration of software builds, including installation in the correct locations as specified in a VLAN configuration and filter rule.

[0039] Procedure 800 can proceed to step 810, which may involve coupling an external Ethernet switch located inside the vehicle to the internal Ethernet switch, wherein the external Ethernet switch couples one or more devices to the internal Ethernet switch through one or more virtual local area networks (VLANs). As described in Fig. As discussed in section 2, configuration 200 can also include an external switch, such as external switch 240, to connect one or more MCUs, e.g., MCU 210-1 and MCU 210-2, to other devices, such as end devices, including edge-to-bus (E2B) devices 250-1, 250-2 through 250-N. The end devices can also include specialized electronic devices (SE devices or SE-DEV), such as SE-DEV #1 255-1. In some embodiments, an SE device can include a processor and the ability to support cryptographic capabilities, including authentication. In other embodiments, E2B devices may not include a processor.Additionally, VLANs can be shown to connect, for example, trunk ports 235-1 and 235-2 to other access ports of the external switch 240, from which end devices can be coupled to these access ports of the external switch, for example, access ports 237.

[0040] In step 815, procedure 800 can proceed with generating a VLAN configuration and filter rule for the internal switch based on an access control policy. As discussed in configuration 200, VLAN configurations can be determined by generating a VLAN configuration and filter rule based on an access control policy. For example, configuration 200 illustrates that the VLANs associated with XXX build 212-2, YYY build 212-3, ZZZ build 212-4, and ABCD build 212-5 are isolated from end devices 250-1 and 250-2. Fig. 6, where at step 640 an access control policy can be set on each MCU to specify which source MAC addresses can transmit on which VLAN.

[0041] In step 820, procedure 800 can proceed by identifying an association of one or more software builds with one or more MCU ports based on a MAC and IP address of each MCU port. As discussed in Table 2 and in Fig. As discussed in section 5, the process begins at step 510 with the activation of the VLANs, as shown above in Table 1. If the ARP table is not populated, as in the example in Table 1, the procedure ends at step 500 until the table is populated. In one embodiment, the switch host, or as in Fig. 2 designates the auxiliary core manager 215-1 for the MCU 210-1 and / or the auxiliary core manager 215-2 for the MCU 210-2 to send a command to each detected MAC address to retrieve the associated IP addresses and assigned VLANs.

[0042] In step 825, procedure 800 can proceed by updating a VLAN configuration and filter rule on the external switch to enable one or more VLANs based on the association of one or more software builds with one or more MCU ports. As discussed in Table 3, the table describes an example where a single VLAN is associated with each port of the switch and thus with each detected build, and that it may be possible in some cases for more than one VLAN to be enabled on a given switch port. The disabled VLANs are also referred to as a breakthrough because these VLANs are not used by the associated MCU / port.

[0043] Procedure 800 can then end.

Claims

[1] Network segment isolation system with variable configurations (200, 300, 400) in a vehicle (100), comprising: a network within the vehicle (100) that includes the following: a microcontroller unit (MCU, 210-1) located inside the vehicle (100), which includes an internal Ethernet switch (220-1) and an auxiliary core manager (215-1), wherein the MCU (210-1) is configured to host one or more software builds (212-1, 212-2, 212-3, 212-4, 212-5), and the auxiliary core manager (215-1) is configured to manage the internal Ethernet switch (220-1) and the one or more software builds (212-1, 212-2, 212-3, 212-4, 212-5); and an external Ethernet switch (240) located inside the vehicle (100) and configured to couple one or more ports of the internal Ethernet switch (220-1) to one or more devices via one or more virtual local area networks (VLANs, 230-1, 230-2, 230-3, 230-4, 230-4, 230-5, 230-6); characterized by , that the auxiliary core manager (215-1) is configured, upon the occurrence of a reflash event, to generate a VLAN configuration and filter rule for the internal switch (220-1) based on an access control policy and to associate one or more software builds (212-1, 212-2, 212-3, 212-4, 212-5) with one or to identify multiple MCU ports based on the MAC and IP address of each MCU port; and wherein the auxiliary core manager (215-1) is further configured to update a VLAN configuration and filter rule on the external switch (240) to enable one or more VLANs (230-1, 230-2, 230-3, 230-4, 230-4, 230-5, 230-6) based on the association of one or more software builds (212-1, 212-2, 212-3, 212-4, 212-5) with one or more MCU ports. [2] System according to claim 1, further comprising a second MCU (210-2) located inside the vehicle (100) which includes a second internal Ethernet switch (220-2) and a second auxiliary core manager (215-2), wherein the second MCU (210-2) is configured to host one or more software builds (212-1, 212-2, 212-3, 212-4, 212-5) and the second auxiliary core manager (215-2) is configured to manage the second internal Ethernet switch (220-2). [3] System according to claim 1, wherein the filter rules are applied to the external Ethernet switch (240) and wherein each of the one or more software builds (212-1, 212-2, 212-3, 212-4, 212-5) is associated with a fixed IP address and a location-dependent MAC address. [4] System according to claim 3, wherein the auxiliary core manager (215-1) is configured to determine the location of one or more software builds (212-1, 212-2, 212-3, 212-4, 212-5) using an Address Resolution Protocol (ARP). [5] System according to claim 1, wherein the filter rules are applied to the internal Ethernet switch (220-1) and wherein each of the one or more software builds (212-1, 212-2, 212-3, 212-4, 212-5) is associated with a fixed IP address and a location-dependent MAC address. [6] System according to claim 5, wherein the internal Ethernet switch (220-1) is configured to verify the communication between a software build (212-1, 212-2, 212-3, 212-4, 212-5) and a device, and wherein the verification includes matching configuration data including the location-dependent MAC address with an associated VLAN (230-1, 230-2, 230-3, 230-4, 230-4, 230-5, 230-6). [7] System according to claim 6, wherein the configuration data is contained within an auxiliary core manager build. [8] System according to claim 1, wherein the external switch (240) is configured to be coupled to an edge-to-bus device (250-1, 250-2 - 250-N) or a specialized electronic device (255-1). [9] System according to claim 3, wherein the auxiliary core manager (215-1) is further configured to verify a configuration update on the external Ethernet switch (240) which includes receiving a digital signature using a valid certificate. [10] System according to claim 5, wherein the auxiliary core manager (215-1) is further configured to verify a configuration update on the internal Ethernet switch (220-1) which includes either a subroutine-based challenge-response or a calibration file-based procedure.

Images