SlideShare a Scribd company logo

Ethernet_Smart_Switches_ElektronikAutomotive_202306_PressArticle_EN.pdf

•
•
C
ChaosXia

Ethernet

Related slideshows

Secure remote protocol for fpga reconfiguration
Secure remote protocol for fpga reconfigurationSecure remote protocol for fpga reconfiguration
Secure remote protocol for fpga reconfiguration
 
Secure remote protocol for fpga reconfiguration
Secure remote protocol for fpga reconfigurationSecure remote protocol for fpga reconfiguration
Secure remote protocol for fpga reconfiguration
 
Project
ProjectProject
Project
 
1 of 4
Download to read offline
01 Future-Proof Smart-Ethernet Switches Efficient Use of the Available Resources In-vehicle communication with Ethernet has been estab- lished for years among vehicle manufacturers and suppliers and is constantly evolving. In the early days of automotive Ethernet, it was mostly point-to-point networks for dedi- cated stand-alone solutions, such as the connection to a diagnostic tester or a rear-view camera. Providing the required bandwidth was the main focus for these use cases. Together with the enhancements in the recent past, more and more Ethernet nodes have been added to the vehicle networks. Therefore, switches were required to real- ize the interconnection between the nodes. The introduc- tion of domain-based architecture in the vehicles favored the introduction of new functions such as an Ethernet backbone. Automotive Switches: Software and Hardware Architec- tures In the future, in-vehicle architecture will evolve from a domain-based approach to a zonal architecture. The main reason for this, is particularly the reduction of the complex wiring of domain architectures. With this evolutionary step, where all domains (body, powertrain, chassis, etc.) share the same backbone medium, a completely different Ethernet switches play an increasingly important role in the automotive environment. To reduce the load on the host microcontroller (µC), significant parts of the AUTOSAR stack are relocated to the switch. But what does such a software architecture look like in detail, and which requirements regarding workflow, tools and software distribution need to be considered during development? Insert figure Figure 1: In the future, redundancy will play an increasingly import- ant role in zonal architectures with Ethernet switches. This increases the complexity of configuring such distributed systems.
02 Technical Article / July 2023 approach and collaboration is required in the development phase. In zonal architectures of the future, redundancy will play an increasingly important role [Figure 1]. This will enor- mously increase the complexity of configuring distributed switches. The requirements go far beyond simply providing bandwidth. The vehicle manufacturers (OEMs) require a reliable and safe network with a flexible, dynamic, and ser- vice-oriented communication that works in parallel to con- trol functions and streaming traffic with Time Sensitive Networking (TSN) requirements. Switches are very important in such a communication net- work. They allow communication between Ethernet nodes and control the access to the network, latencies and band- width. They also play a central role in the implementation of TSN functions, such as time synchronization, as well as for the reliability and the safety of the entire network. It is already apparent that the number of switches in the net- work will rise significantly due to the increase of the func- tions in the vehicle network. In this context, the use of switches raises some questions: > How does the hardware and software architecture look like? > Which software functions are necessary on the switch? > How can the configuration consistency be ensured across all switches in the network? > How is the software of the switches updated? Automotive Switches and AUTOSAR From the hardware point of view, a switch IC is a subsys- tem of the ECU which is placed together with the µC on a printed circuit board (PCB). In the classic AUTOSAR approach, an AUTOSAR stack with a real-time operating system runs on the µC. This µC manages the switch and its PHYs by means of a driver via management interfaces, such as MDIO (Management Data Input/Output) or SPI (Serial Peripheral Interface) and controls the switch like a peripheral device [Figure 2]. Such an approach, however, quickly reaches its limits. For example, PTP (Precision Time Protocol) handling of switches with more than six ports is no longer useful, since the CPU load of the µC increases enormously with the number of ports. Such a solution approach is also no longer practical for use cases such as automotive firewall or software-based packet analysis due to the latency between switch and µC and the runtime of the µC. “Smart Switches” and AUTOSAR Most of the switches that are used nowadays already include their own CPU with (external) flash memory [Figure 3] from which the switch can be booted and therefore operated independently of the µC. This means that a switch IC with an included CPU works as a “smart switch” of the µC. The switch takes over relevant network-specific tasks and relieves the µC from network tasks, such as PTP handling. When using smart switch ICs in practice, there usually are two different kinds of approaches. None of them is optimal since the functions and resources of the switch are not suf- ficiently used. In the first approach, the switch is often used as a simple peripheral device and the AUTOSAR switch drivers continue to run on the µC. As a consequence, the switch CPU is deactivated, and the additional resources of the smart switch remain unused. Insert figure Figure 2: The performance of a µC-based switch management is limited. The limiting factor is the interface. Figure 3: A switch IC with integrated CPU acts as a smart switch of the µC and takes over important network tasks from the µC.
03 Technical Article / July 2023 stands for Media Access Control Security. This is a security standard specified in IEEE 802.1AE. It works on layer 2 of the OSI reference model, ensures the security of point-to- point Ethernet connections and prevents various threats and attacks such as spoofing, replay attacks, man-in-the- middle attacks or masquerading. Software Distribution Which software functions are ideally required on a smart switch and which software clusters can be sensibly offload- ed from the host µC to the switch ECU? It is clear that an operating system and a hardware abstraction are neces- sary. In addition, there are important functional blocks: > Switch initialization and basic configuration > PTP handling and further TSN functions > Provision of functions for software updates and diag- nostics via the µC > Network management > Security Figure 5 shows an AUTOSAR-like stack on a switch: In addi- tion to the operating system, AUTOSAR MAC, PHY and switch drivers, as well as an Ethernet interface are included. The most important benefit: hardware-independent and qualified software already available in AUTOSAR can be used directly on the switch without restrictions. For exam- ple, the EthTSyn module, which means the PTP implemen- tation with AUTOSAR extensions, can be integrated direct- ly in the switch. In order to include new tasks and functions, the switch can be scaled accordingly, and function and net- work modules can easily be integrated. By this, the func- The second approach is the elimination of the switch driver on the µC. In this case, the switch runs its own proprietary software. The disadvantage here is that the switch is com- pletely decoupled from the AUTOSAR workflow (configura- tion and updates) and the µC no longer has any influence on the switch. This approach, however, rises several questions: > How is the configuration consistency achieved? > How does the concept of the software updates and the UDS diagnostics look like? > How does the switch support automotive-specific proto- cols and extensions? Considered in detail, such a switch ECU is a multiprocessor system with a distributed function set [Figure 4]: On one side is the µC with the AUTOSAR real-time operating sys- tem and the basic software, on the other side the switch with integrated CPU and its own software. The goal is to create a distributed software architecture in which the functions are run on the most suitable system component for each case. On the one hand, this achieves a µC-indepen- dent fast startup and wakeup as well as a self-configura- tion of the switch. On the other hand, the PTP handling is executed locally via the switch. Another advantage of this concept is the execution of e.g. Partial Networking and AVB/TSN functions on the switch. With sufficient resources, even “firewalling” or OEM- specific use cases, such as variant provisioning, are possible directly on the switch. In the near future, even the use of MACsec on the switch is planned. The abbreviation MACsec Insert figure Figure 5: Even a switch in minimum configuration enables stand- alone operation. Porting further AUTOSAR software to the switch is done with little effort. Insert figure Figure 4: Software modules for PTP handling, TSN, firewall and di- agnostics are relocated from the µC to the switch.
04 Technical Article / July 2023 First AUTOSAR-Capable Ethernet Switches Vector has developed the first AUTOSAR-capable multi-gig Ethernet switch based on Marvell’s Bright- lane™ solution, available to suppliers and automotive manufacturers as Ethernet-Switch Brightlane 88Q5072 from Marvell. The new embedded software from Vector for Ethernet switches is available under the name MICROSAR Classic veSwitch. It uses the AUTOSAR workflow for essential functions such as port configura- tion, partial networking and PTP. Security functions such as automotive firewalls and MACsec can easily be integrated in the software architecture. The software has proven itself in practice and the effort required to develop intelligent switch ECUs has been significantly reduced. The workflow’s modular approach results in a hard- ware-optimized and flexible solution – ideal for auto- motive-compliant switches including firewall and safety applications. The developer workflow is optimally sup- ported by Vector DaVinci Tools. In a first version, the embedded software fulfills the quality requirements according to Automotive SPICE. In the future, the veSwitch will be available according to ISO 26262. An evaluation package is also available. tionality can be increased in accordance with the available resources of the switch. Another benefit is that the config- uration and the development tools for the switch are com- pletely identical to the AUTOSAR workflow already used on the µC and well established in practice. Future Challenges Since the hardware resources of the switch are limited, there are still some limitations in the software. For func- tions such as firewall and IDS (Intrusion Detection Sys- tem), the need for memory space and CPU resources is growing. The same is true for MACsec which requires key management and a crypto accelerator directly on the switch. In addition, questions regarding the workflow have not yet been definitely clarified. AUTOSAR XML could be a practicable solution or at least a good starting point for many OEMs. In addition to technical issues that still need to be clarified, the development process itself also requires a rethink in the use of such intelligent switches. Since these are completely autonomous systems with their own communication requirements, they need their own MAC, IP and diagnostic addresses. Splitting the software and the network and communication functions between µC and smart switch will therefore play an important role in the development of ECUs in the future and must always be kept in mind by those responsible for the components at OEMs. Outlook The efficient use of the available resources is one of the main reasons for the use of smart Ethernet switches. They also enable the implementation of new functions such as automotive firewalls and MACsec, which can only be exe- cuted locally or implemented much more efficiently on the switch. By shifting switch-relevant parts of the Precision Time Protocol (PTP), the network management and parts of the diagnostics to the switch, CPU resources on the host µC are made available for tasks that run there more effi- ciently. The software executed in the CPU of the smart switch fol- lows the AUTOSAR methodology in terms of model defini- tion, distribution, and creation of components. Therefore, the developers will benefit from the AUTOSAR workflow that has been established at automotive manufacturers and suppliers. In addition, AUTOSAR offers the advantage of reusing existing qualified software for communication, network management and diagnostics directly on the switch. The slogan “one tool environment, one workflow, one software architecture” makes the use of AUTOSAR- capable switches fit for the future and offers a faster mar- ket launch. Daniel Dausend is team leader in Vector’s embedded software department and is responsible for innovative topics and technologies in the field of communication and operating systems. He has experience in the embedded Ethernet development and product management. Translation of a German publication in Elektronik automo- tive issue June 2023 Image rights: Vector Informatik GmbH Axel Schäfer is product manager in Vector’s embedded software department and is responsible for innovative topics and technologies in the field of communication. He has experience in product develop- ment and integration of Vector’s embedded Ethernet compo- nents.

More Related Content

Ethernet_Smart_Switches_ElektronikAutomotive_202306_PressArticle_EN.pdf

  • 1. 01 Future-Proof Smart-Ethernet Switches Efficient Use of the Available Resources In-vehicle communication with Ethernet has been estab- lished for years among vehicle manufacturers and suppliers and is constantly evolving. In the early days of automotive Ethernet, it was mostly point-to-point networks for dedi- cated stand-alone solutions, such as the connection to a diagnostic tester or a rear-view camera. Providing the required bandwidth was the main focus for these use cases. Together with the enhancements in the recent past, more and more Ethernet nodes have been added to the vehicle networks. Therefore, switches were required to real- ize the interconnection between the nodes. The introduc- tion of domain-based architecture in the vehicles favored the introduction of new functions such as an Ethernet backbone. Automotive Switches: Software and Hardware Architec- tures In the future, in-vehicle architecture will evolve from a domain-based approach to a zonal architecture. The main reason for this, is particularly the reduction of the complex wiring of domain architectures. With this evolutionary step, where all domains (body, powertrain, chassis, etc.) share the same backbone medium, a completely different Ethernet switches play an increasingly important role in the automotive environment. To reduce the load on the host microcontroller (µC), significant parts of the AUTOSAR stack are relocated to the switch. But what does such a software architecture look like in detail, and which requirements regarding workflow, tools and software distribution need to be considered during development? Insert figure Figure 1: In the future, redundancy will play an increasingly import- ant role in zonal architectures with Ethernet switches. This increases the complexity of configuring such distributed systems.
  • 2. 02 Technical Article / July 2023 approach and collaboration is required in the development phase. In zonal architectures of the future, redundancy will play an increasingly important role [Figure 1]. This will enor- mously increase the complexity of configuring distributed switches. The requirements go far beyond simply providing bandwidth. The vehicle manufacturers (OEMs) require a reliable and safe network with a flexible, dynamic, and ser- vice-oriented communication that works in parallel to con- trol functions and streaming traffic with Time Sensitive Networking (TSN) requirements. Switches are very important in such a communication net- work. They allow communication between Ethernet nodes and control the access to the network, latencies and band- width. They also play a central role in the implementation of TSN functions, such as time synchronization, as well as for the reliability and the safety of the entire network. It is already apparent that the number of switches in the net- work will rise significantly due to the increase of the func- tions in the vehicle network. In this context, the use of switches raises some questions: > How does the hardware and software architecture look like? > Which software functions are necessary on the switch? > How can the configuration consistency be ensured across all switches in the network? > How is the software of the switches updated? Automotive Switches and AUTOSAR From the hardware point of view, a switch IC is a subsys- tem of the ECU which is placed together with the µC on a printed circuit board (PCB). In the classic AUTOSAR approach, an AUTOSAR stack with a real-time operating system runs on the µC. This µC manages the switch and its PHYs by means of a driver via management interfaces, such as MDIO (Management Data Input/Output) or SPI (Serial Peripheral Interface) and controls the switch like a peripheral device [Figure 2]. Such an approach, however, quickly reaches its limits. For example, PTP (Precision Time Protocol) handling of switches with more than six ports is no longer useful, since the CPU load of the µC increases enormously with the number of ports. Such a solution approach is also no longer practical for use cases such as automotive firewall or software-based packet analysis due to the latency between switch and µC and the runtime of the µC. “Smart Switches” and AUTOSAR Most of the switches that are used nowadays already include their own CPU with (external) flash memory [Figure 3] from which the switch can be booted and therefore operated independently of the µC. This means that a switch IC with an included CPU works as a “smart switch” of the µC. The switch takes over relevant network-specific tasks and relieves the µC from network tasks, such as PTP handling. When using smart switch ICs in practice, there usually are two different kinds of approaches. None of them is optimal since the functions and resources of the switch are not suf- ficiently used. In the first approach, the switch is often used as a simple peripheral device and the AUTOSAR switch drivers continue to run on the µC. As a consequence, the switch CPU is deactivated, and the additional resources of the smart switch remain unused. Insert figure Figure 2: The performance of a µC-based switch management is limited. The limiting factor is the interface. Figure 3: A switch IC with integrated CPU acts as a smart switch of the µC and takes over important network tasks from the µC.
  • 3. 03 Technical Article / July 2023 stands for Media Access Control Security. This is a security standard specified in IEEE 802.1AE. It works on layer 2 of the OSI reference model, ensures the security of point-to- point Ethernet connections and prevents various threats and attacks such as spoofing, replay attacks, man-in-the- middle attacks or masquerading. Software Distribution Which software functions are ideally required on a smart switch and which software clusters can be sensibly offload- ed from the host µC to the switch ECU? It is clear that an operating system and a hardware abstraction are neces- sary. In addition, there are important functional blocks: > Switch initialization and basic configuration > PTP handling and further TSN functions > Provision of functions for software updates and diag- nostics via the µC > Network management > Security Figure 5 shows an AUTOSAR-like stack on a switch: In addi- tion to the operating system, AUTOSAR MAC, PHY and switch drivers, as well as an Ethernet interface are included. The most important benefit: hardware-independent and qualified software already available in AUTOSAR can be used directly on the switch without restrictions. For exam- ple, the EthTSyn module, which means the PTP implemen- tation with AUTOSAR extensions, can be integrated direct- ly in the switch. In order to include new tasks and functions, the switch can be scaled accordingly, and function and net- work modules can easily be integrated. By this, the func- The second approach is the elimination of the switch driver on the µC. In this case, the switch runs its own proprietary software. The disadvantage here is that the switch is com- pletely decoupled from the AUTOSAR workflow (configura- tion and updates) and the µC no longer has any influence on the switch. This approach, however, rises several questions: > How is the configuration consistency achieved? > How does the concept of the software updates and the UDS diagnostics look like? > How does the switch support automotive-specific proto- cols and extensions? Considered in detail, such a switch ECU is a multiprocessor system with a distributed function set [Figure 4]: On one side is the µC with the AUTOSAR real-time operating sys- tem and the basic software, on the other side the switch with integrated CPU and its own software. The goal is to create a distributed software architecture in which the functions are run on the most suitable system component for each case. On the one hand, this achieves a µC-indepen- dent fast startup and wakeup as well as a self-configura- tion of the switch. On the other hand, the PTP handling is executed locally via the switch. Another advantage of this concept is the execution of e.g. Partial Networking and AVB/TSN functions on the switch. With sufficient resources, even “firewalling” or OEM- specific use cases, such as variant provisioning, are possible directly on the switch. In the near future, even the use of MACsec on the switch is planned. The abbreviation MACsec Insert figure Figure 5: Even a switch in minimum configuration enables stand- alone operation. Porting further AUTOSAR software to the switch is done with little effort. Insert figure Figure 4: Software modules for PTP handling, TSN, firewall and di- agnostics are relocated from the µC to the switch.
  • 4. 04 Technical Article / July 2023 First AUTOSAR-Capable Ethernet Switches Vector has developed the first AUTOSAR-capable multi-gig Ethernet switch based on Marvell’s Bright- lane™ solution, available to suppliers and automotive manufacturers as Ethernet-Switch Brightlane 88Q5072 from Marvell. The new embedded software from Vector for Ethernet switches is available under the name MICROSAR Classic veSwitch. It uses the AUTOSAR workflow for essential functions such as port configura- tion, partial networking and PTP. Security functions such as automotive firewalls and MACsec can easily be integrated in the software architecture. The software has proven itself in practice and the effort required to develop intelligent switch ECUs has been significantly reduced. The workflow’s modular approach results in a hard- ware-optimized and flexible solution – ideal for auto- motive-compliant switches including firewall and safety applications. The developer workflow is optimally sup- ported by Vector DaVinci Tools. In a first version, the embedded software fulfills the quality requirements according to Automotive SPICE. In the future, the veSwitch will be available according to ISO 26262. An evaluation package is also available. tionality can be increased in accordance with the available resources of the switch. Another benefit is that the config- uration and the development tools for the switch are com- pletely identical to the AUTOSAR workflow already used on the µC and well established in practice. Future Challenges Since the hardware resources of the switch are limited, there are still some limitations in the software. For func- tions such as firewall and IDS (Intrusion Detection Sys- tem), the need for memory space and CPU resources is growing. The same is true for MACsec which requires key management and a crypto accelerator directly on the switch. In addition, questions regarding the workflow have not yet been definitely clarified. AUTOSAR XML could be a practicable solution or at least a good starting point for many OEMs. In addition to technical issues that still need to be clarified, the development process itself also requires a rethink in the use of such intelligent switches. Since these are completely autonomous systems with their own communication requirements, they need their own MAC, IP and diagnostic addresses. Splitting the software and the network and communication functions between µC and smart switch will therefore play an important role in the development of ECUs in the future and must always be kept in mind by those responsible for the components at OEMs. Outlook The efficient use of the available resources is one of the main reasons for the use of smart Ethernet switches. They also enable the implementation of new functions such as automotive firewalls and MACsec, which can only be exe- cuted locally or implemented much more efficiently on the switch. By shifting switch-relevant parts of the Precision Time Protocol (PTP), the network management and parts of the diagnostics to the switch, CPU resources on the host µC are made available for tasks that run there more effi- ciently. The software executed in the CPU of the smart switch fol- lows the AUTOSAR methodology in terms of model defini- tion, distribution, and creation of components. Therefore, the developers will benefit from the AUTOSAR workflow that has been established at automotive manufacturers and suppliers. In addition, AUTOSAR offers the advantage of reusing existing qualified software for communication, network management and diagnostics directly on the switch. The slogan “one tool environment, one workflow, one software architecture” makes the use of AUTOSAR- capable switches fit for the future and offers a faster mar- ket launch. Daniel Dausend is team leader in Vector’s embedded software department and is responsible for innovative topics and technologies in the field of communication and operating systems. He has experience in the embedded Ethernet development and product management. Translation of a German publication in Elektronik automo- tive issue June 2023 Image rights: Vector Informatik GmbH Axel Schäfer is product manager in Vector’s embedded software department and is responsible for innovative topics and technologies in the field of communication. He has experience in product develop- ment and integration of Vector’s embedded Ethernet compo- nents.