�ݺ�ߣshows by User: REALTIMEATWORK

�ݺ�ߣshows by User: REALTIMEATWORK / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: REALTIMEATWORK / Tue, 01 Oct 2024 09:30:15 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: REALTIMEATWORK AUTOMOTIVE SYSTEM REQUIREMENTS ON TRAFFIC SHAPING /slideshow/automotive-system-requirements-on-traffic-shaping/272123681 shapingbmwrtawtsna-241001093015-0c58d1fc
This presentation is benchmarking CBS and ATS traffic-shapers by evaluating their performance in terms of latency and memory-utilization in a BMW pre-series vehicle. The configuration complexity of both solutions as well as side-effects and limits of simplification measures like limiting shaping to end-nodes are also examined. Furthermore, we discuss use cases where more advanced shaping-schemes are needed. For vehicle-programming, e.g., all links should run at the highest possible capacity, while not overloading any link aggregating streams. We will show this problem in more details and look at a solution that allows for a topology-adequate traffic pre-conditioning by sending-side hierarchical traffic-shaping.]]>
This presentation is benchmarking CBS and ATS traffic-shapers by evaluating their performance in terms of latency and memory-utilization in a BMW pre-series vehicle. The configuration complexity of both solutions as well as side-effects and limits of simplification measures like limiting shaping to end-nodes are also examined. Furthermore, we discuss use cases where more advanced shaping-schemes are needed. For vehicle-programming, e.g., all links should run at the highest possible capacity, while not overloading any link aggregating streams. We will show this problem in more details and look at a solution that allows for a topology-adequate traffic pre-conditioning by sending-side hierarchical traffic-shaping.]]> Tue, 01 Oct 2024 09:30:15 GMT /slideshow/automotive-system-requirements-on-traffic-shaping/272123681 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) AUTOMOTIVE SYSTEM REQUIREMENTS ON TRAFFIC SHAPING REALTIMEATWORK This presentation is benchmarking CBS and ATS traffic-shapers by evaluating their performance in terms of latency and memory-utilization in a BMW pre-series vehicle. The configuration complexity of both solutions as well as side-effects and limits of simplification measures like limiting shaping to end-nodes are also examined. Furthermore, we discuss use cases where more advanced shaping-schemes are needed. For vehicle-programming, e.g., all links should run at the highest possible capacity, while not overloading any link aggregating streams. We will show this problem in more details and look at a solution that allows for a topology-adequate traffic pre-conditioning by sending-side hierarchical traffic-shaping. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/shapingbmwrtawtsna-241001093015-0c58d1fc-thumbnail.jpg?width=120&height=120&fit=bounds" /> This presentation is benchmarking CBS and ATS traffic-shapers by evaluating their performance in terms of latency and memory-utilization in a BMW pre-series vehicle. The configuration complexity of both solutions as well as side-effects and limits of simplification measures like limiting shaping to end-nodes are also examined. Furthermore, we discuss use cases where more advanced shaping-schemes are needed. For vehicle-programming, e.g., all links should run at the highest possible capacity, while not overloading any link aggregating streams. We will show this problem in more details and look at a solution that allows for a topology-adequate traffic pre-conditioning by sending-side hierarchical traffic-shaping.

AUTOMOTIVE SYSTEM REQUIREMENTS ON TRAFFIC SHAPING from RealTime-at-Work (RTaW)

]]> 1484 0 https://cdn.slidesharecdn.com/ss_thumbnails/shapingbmwrtawtsna-241001093015-0c58d1fc-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 What are the relevant differences between Asynchronous (ATS) and Credit Based (CBS) Shaper? /REALTIMEATWORK/what-are-the-relevant-differences-between-asynchronous-ats-and-credit-based-cbs-shaper tsn2023-atsvscbsethernoviartaw-231105075509-76233b47
The effects of CBS and ATS shapers (IEEE Std 802.1Q-2022, Annex L and V) are basically identical for a single flow in the highest priority Traffic Class. But the number of CBS instances is intrinsically limited by the number of TCs, while ATS instances can be numerous and are organized into Scheduler-Groups. We discuss how selecting ingress-flows for ATS instances can create different behavior from CBS. How does the ATS grouping-rule affect shaper performance? What benefit can shaping of lower priority TCs have? How are other non-shaped TCs affected by ATS vs. CBS?]]>
The effects of CBS and ATS shapers (IEEE Std 802.1Q-2022, Annex L and V) are basically identical for a single flow in the highest priority Traffic Class. But the number of CBS instances is intrinsically limited by the number of TCs, while ATS instances can be numerous and are organized into Scheduler-Groups. We discuss how selecting ingress-flows for ATS instances can create different behavior from CBS. How does the ATS grouping-rule affect shaper performance? What benefit can shaping of lower priority TCs have? How are other non-shaped TCs affected by ATS vs. CBS?]]> Sun, 05 Nov 2023 07:55:09 GMT /REALTIMEATWORK/what-are-the-relevant-differences-between-asynchronous-ats-and-credit-based-cbs-shaper REALTIMEATWORK@slideshare.net(REALTIMEATWORK) What are the relevant differences between Asynchronous (ATS) and Credit Based (CBS) Shaper? REALTIMEATWORK The effects of CBS and ATS shapers (IEEE Std 802.1Q-2022, Annex L and V) are basically identical for a single flow in the highest priority Traffic Class. But the number of CBS instances is intrinsically limited by the number of TCs, while ATS instances can be numerous and are organized into Scheduler-Groups. We discuss how selecting ingress-flows for ATS instances can create different behavior from CBS. How does the ATS grouping-rule affect shaper performance? What benefit can shaping of lower priority TCs have? How are other non-shaped TCs affected by ATS vs. CBS? <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/tsn2023-atsvscbsethernoviartaw-231105075509-76233b47-thumbnail.jpg?width=120&height=120&fit=bounds" /> The effects of CBS and ATS shapers (IEEE Std 802.1Q-2022, Annex L and V) are basically identical for a single flow in the highest priority Traffic Class. But the number of CBS instances is intrinsically limited by the number of TCs, while ATS instances can be numerous and are organized into Scheduler-Groups. We discuss how selecting ingress-flows for ATS instances can create different behavior from CBS. How does the ATS grouping-rule affect shaper performance? What benefit can shaping of lower priority TCs have? How are other non-shaped TCs affected by ATS vs. CBS?

What are the relevant differences between Asynchronous (ATS) and Credit Based (CBS) Shaper? from RealTime-at-Work (RTaW)

]]> 126 0 https://cdn.slidesharecdn.com/ss_thumbnails/tsn2023-atsvscbsethernoviartaw-231105075509-76233b47-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 TSN Timing QoS Mechanisms: What Did We Learn over the Past 10 Years? /slideshow/tsn-timing-qos-mechanisms-what-did-we-learn-over-the-past-10-years/263057962 tsn-qos-what-did-we-learn2023-231105074849-26f7ad34
t has been more than 10 years since the inception of the Time-Sensitive Networking Task Group (TG) in IEEE802.1. Since then, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. While IEEE 802.1CB, AS and Qci are natural choices for dependability, the designer has much more possibilities when it comes to timing QoS. The selection and configuration of a suitable TSN scheduling solution is not straightforward, as many mechanisms are available (priorities, preemption, CBS, TAS, CQF, ATS), most of them being complex to configure, and they can be used in a combined manner to meet the needs of applications comprising mixed types of traffic. In this talk, based on the academic literature and the observation of industrial practices, we review the well-understood and the emerging use-cases of the different timing QoS mechanisms and what we have learned in terms of their configuration. Ultimately, this talk aims at shedding new light on what to expect from TSN QoS mechanisms and how to introduce the least complexity needed to meet the application's timing requirements.]]>
t has been more than 10 years since the inception of the Time-Sensitive Networking Task Group (TG) in IEEE802.1. Since then, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. While IEEE 802.1CB, AS and Qci are natural choices for dependability, the designer has much more possibilities when it comes to timing QoS. The selection and configuration of a suitable TSN scheduling solution is not straightforward, as many mechanisms are available (priorities, preemption, CBS, TAS, CQF, ATS), most of them being complex to configure, and they can be used in a combined manner to meet the needs of applications comprising mixed types of traffic. In this talk, based on the academic literature and the observation of industrial practices, we review the well-understood and the emerging use-cases of the different timing QoS mechanisms and what we have learned in terms of their configuration. Ultimately, this talk aims at shedding new light on what to expect from TSN QoS mechanisms and how to introduce the least complexity needed to meet the application's timing requirements.]]> Sun, 05 Nov 2023 07:48:48 GMT /slideshow/tsn-timing-qos-mechanisms-what-did-we-learn-over-the-past-10-years/263057962 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) TSN Timing QoS Mechanisms: What Did We Learn over the Past 10 Years? REALTIMEATWORK t has been more than 10 years since the inception of the Time-Sensitive Networking Task Group (TG) in IEEE802.1. Since then, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. While IEEE 802.1CB, AS and Qci are natural choices for dependability, the designer has much more possibilities when it comes to timing QoS. The selection and configuration of a suitable TSN scheduling solution is not straightforward, as many mechanisms are available (priorities, preemption, CBS, TAS, CQF, ATS), most of them being complex to configure, and they can be used in a combined manner to meet the needs of applications comprising mixed types of traffic. In this talk, based on the academic literature and the observation of industrial practices, we review the well-understood and the emerging use-cases of the different timing QoS mechanisms and what we have learned in terms of their configuration. Ultimately, this talk aims at shedding new light on what to expect from TSN QoS mechanisms and how to introduce the least complexity needed to meet the application's timing requirements. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/tsn-qos-what-did-we-learn2023-231105074849-26f7ad34-thumbnail.jpg?width=120&height=120&fit=bounds" /> t has been more than 10 years since the inception of the Time-Sensitive Networking Task Group (TG) in IEEE802.1. Since then, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. While IEEE 802.1CB, AS and Qci are natural choices for dependability, the designer has much more possibilities when it comes to timing QoS. The selection and configuration of a suitable TSN scheduling solution is not straightforward, as many mechanisms are available (priorities, preemption, CBS, TAS, CQF, ATS), most of them being complex to configure, and they can be used in a combined manner to meet the needs of applications comprising mixed types of traffic. In this talk, based on the academic literature and the observation of industrial practices, we review the well-understood and the emerging use-cases of the different timing QoS mechanisms and what we have learned in terms of their configuration. Ultimately, this talk aims at shedding new light on what to expect from TSN QoS mechanisms and how to introduce the least complexity needed to meet the application's timing requirements.

TSN Timing QoS Mechanisms: What Did We Learn over the Past 10 Years? from RealTime-at-Work (RTaW)

]]> 72 0 https://cdn.slidesharecdn.com/ss_thumbnails/tsn-qos-what-did-we-learn2023-231105074849-26f7ad34-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Time-Predictable Communication in Service-Oriented Architecture - What are the challenges? /slideshow/timepredictable-communication-in-serviceoriented-architecture-what-are-the-challenges/256857623 aec23volvocognifyerultiming-predictability-230326075102-1bc481f4
Software defined vehicle puts the challenges not only on the computing systems in the vehicle but also on the network. To design a system that can exhibit the required level of determinism for a set of distributed control applications, it is not enough to have a network that is predictable from the timing perspective, one also needs proper real-time scheduling mechanisms in the operating system and in the communication stack, i.e. the interface between the application and the network. In this contribution, we present: - Overall concept, or what do we mean with a time-predictable system, - State of the art in deterministic real-time Ethernet communication, - The real-time scheduling mechanisms commonly used in Automotive, - Examples of challenging issues and practical use cases that OEMs need to address toward timing predictability in the system.]]>
Software defined vehicle puts the challenges not only on the computing systems in the vehicle but also on the network. To design a system that can exhibit the required level of determinism for a set of distributed control applications, it is not enough to have a network that is predictable from the timing perspective, one also needs proper real-time scheduling mechanisms in the operating system and in the communication stack, i.e. the interface between the application and the network. In this contribution, we present: - Overall concept, or what do we mean with a time-predictable system, - State of the art in deterministic real-time Ethernet communication, - The real-time scheduling mechanisms commonly used in Automotive, - Examples of challenging issues and practical use cases that OEMs need to address toward timing predictability in the system.]]> Sun, 26 Mar 2023 07:51:02 GMT /slideshow/timepredictable-communication-in-serviceoriented-architecture-what-are-the-challenges/256857623 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Time-Predictable Communication in Service-Oriented Architecture - What are the challenges? REALTIMEATWORK Software defined vehicle puts the challenges not only on the computing systems in the vehicle but also on the network. To design a system that can exhibit the required level of determinism for a set of distributed control applications, it is not enough to have a network that is predictable from the timing perspective, one also needs proper real-time scheduling mechanisms in the operating system and in the communication stack, i.e. the interface between the application and the network. In this contribution, we present: - Overall concept, or what do we mean with a time-predictable system, - State of the art in deterministic real-time Ethernet communication, - The real-time scheduling mechanisms commonly used in Automotive, - Examples of challenging issues and practical use cases that OEMs need to address toward timing predictability in the system. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/aec23volvocognifyerultiming-predictability-230326075102-1bc481f4-thumbnail.jpg?width=120&height=120&fit=bounds" /> Software defined vehicle puts the challenges not only on the computing systems in the vehicle but also on the network. To design a system that can exhibit the required level of determinism for a set of distributed control applications, it is not enough to have a network that is predictable from the timing perspective, one also needs proper real-time scheduling mechanisms in the operating system and in the communication stack, i.e. the interface between the application and the network. In this contribution, we present: - Overall concept, or what do we mean with a time-predictable system, - State of the art in deterministic real-time Ethernet communication, - The real-time scheduling mechanisms commonly used in Automotive, - Examples of challenging issues and practical use cases that OEMs need to address toward timing predictability in the system.

Time-Predictable Communication in Service-Oriented Architecture - What are the challenges? from RealTime-at-Work (RTaW)

]]> 157 0 https://cdn.slidesharecdn.com/ss_thumbnails/aec23volvocognifyerultiming-predictability-230326075102-1bc481f4-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Strategies for End-to-End Timing Guarantees in a Centralized Software Defined Vehicle Architecture Combining CAN With TSN Backbone /slideshow/strategies-for-endtoend-timing-guarantees-in-a-centralized-software-defined-vehicle-architecture-combining-can-with-tsn-backbone/256856422 aec2023renaultboschrtaweeastrategiessdn-230326074458-b4c5d35e
This presentation reports on design choices explored for next-generation zonal E/E architectures supporting mixed criticality traffic with strong timing constraints at the gateways between Ethernet and CAN: • We present methods to validate strategies for packing/unpacking CAN frames to be transmitted over an Ethernet backbone • We present a novel use-case for Time Aware Shaper (TAS), used to confine the traffic from Android applications into short, periodic transmission windows, shielding hence the rest of the traffic from their interference under any evolution scenario. System-level simulations are used to compare TAS with two alternative solutions based on priorities and Credit Based Shaper (CBS) • This study exemplifies how the collaboration between an OEM, a Tier1 and a timing analysis tool vendor built a timing-accurate model of the SDV architecture to explore design alternatives, reduce the time for prototyping and to provide new inputs for the 802.1DG Automotive profile]]>
This presentation reports on design choices explored for next-generation zonal E/E architectures supporting mixed criticality traffic with strong timing constraints at the gateways between Ethernet and CAN: • We present methods to validate strategies for packing/unpacking CAN frames to be transmitted over an Ethernet backbone • We present a novel use-case for Time Aware Shaper (TAS), used to confine the traffic from Android applications into short, periodic transmission windows, shielding hence the rest of the traffic from their interference under any evolution scenario. System-level simulations are used to compare TAS with two alternative solutions based on priorities and Credit Based Shaper (CBS) • This study exemplifies how the collaboration between an OEM, a Tier1 and a timing analysis tool vendor built a timing-accurate model of the SDV architecture to explore design alternatives, reduce the time for prototyping and to provide new inputs for the 802.1DG Automotive profile]]> Sun, 26 Mar 2023 07:44:58 GMT /slideshow/strategies-for-endtoend-timing-guarantees-in-a-centralized-software-defined-vehicle-architecture-combining-can-with-tsn-backbone/256856422 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Strategies for End-to-End Timing Guarantees in a Centralized Software Defined Vehicle Architecture Combining CAN With TSN Backbone REALTIMEATWORK This presentation reports on design choices explored for next-generation zonal E/E architectures supporting mixed criticality traffic with strong timing constraints at the gateways between Ethernet and CAN: • We present methods to validate strategies for packing/unpacking CAN frames to be transmitted over an Ethernet backbone • We present a novel use-case for Time Aware Shaper (TAS), used to confine the traffic from Android applications into short, periodic transmission windows, shielding hence the rest of the traffic from their interference under any evolution scenario. System-level simulations are used to compare TAS with two alternative solutions based on priorities and Credit Based Shaper (CBS) • This study exemplifies how the collaboration between an OEM, a Tier1 and a timing analysis tool vendor built a timing-accurate model of the SDV architecture to explore design alternatives, reduce the time for prototyping and to provide new inputs for the 802.1DG Automotive profile <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/aec2023renaultboschrtaweeastrategiessdn-230326074458-b4c5d35e-thumbnail.jpg?width=120&height=120&fit=bounds" /> This presentation reports on design choices explored for next-generation zonal E/E architectures supporting mixed criticality traffic with strong timing constraints at the gateways between Ethernet and CAN: • We present methods to validate strategies for packing/unpacking CAN frames to be transmitted over an Ethernet backbone • We present a novel use-case for Time Aware Shaper (TAS), used to confine the traffic from Android applications into short, periodic transmission windows, shielding hence the rest of the traffic from their interference under any evolution scenario. System-level simulations are used to compare TAS with two alternative solutions based on priorities and Credit Based Shaper (CBS) • This study exemplifies how the collaboration between an OEM, a Tier1 and a timing analysis tool vendor built a timing-accurate model of the SDV architecture to explore design alternatives, reduce the time for prototyping and to provide new inputs for the 802.1DG Automotive profile

Strategies for End-to-End Timing Guarantees in a Centralized Software Defined Vehicle Architecture Combining CAN With TSN Backbone from RealTime-at-Work (RTaW)

]]> 1130 0 https://cdn.slidesharecdn.com/ss_thumbnails/aec2023renaultboschrtaweeastrategiessdn-230326074458-b4c5d35e-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Signal-Oriented ECUs in a Centralized Service-Oriented Architecture: Scalability of the Layered Software Architecture /REALTIMEATWORK/signaloriented-ecus-in-a-centralized-serviceoriented-architecture-scalability-of-the-layered-software-architecture aec22volvortawulsoa-220612061550-54a7ecc1
The industry is quickly moving away from a function/signal-oriented architecture towards Service-Oriented Architectures (SOA). To carry-over legacy signal-oriented ECUs during the transition phase, Volvo Cars has developed a layered software (SW) architecture based on the concepts of "device proxys" (i.e., one per legacy ECU), signal real-time database and service interface. This architecture, executing on the central computer on the TSN backbone, provides a clear separation of concerns between its components with a reduced additional complexity. In this presentation, we will review the main challenges faced in the integration of signal-oriented ECUs into SOA, and present the solutions explored at Volvo with a focus on layered SW architecture in the centralized E/E architecture and its 3 core components: o Device Proxies o Signal DataBase o Service Interface We then report on the performances of this architecture in terms of latencies and conclude on the maximum number of signal-oriented frames and legacy ECUs that can be handled. The performance evaluation is conducted by simulation, with sensitivity analysis to identify the performance bottlenecks. The E/E architecture under study is a prototype TSN-based central computing architecture targeted at next-generation models. The main questions that will be discussed throughout the presentation are 1) how to efficiently handle signal to service conversion? 2) The performance and the scalability of the SW architecture proposed and 3) the suitability of SOME/IP as the SOA protocol.]]>
The industry is quickly moving away from a function/signal-oriented architecture towards Service-Oriented Architectures (SOA). To carry-over legacy signal-oriented ECUs during the transition phase, Volvo Cars has developed a layered software (SW) architecture based on the concepts of "device proxys" (i.e., one per legacy ECU), signal real-time database and service interface. This architecture, executing on the central computer on the TSN backbone, provides a clear separation of concerns between its components with a reduced additional complexity. In this presentation, we will review the main challenges faced in the integration of signal-oriented ECUs into SOA, and present the solutions explored at Volvo with a focus on layered SW architecture in the centralized E/E architecture and its 3 core components: o Device Proxies o Signal DataBase o Service Interface We then report on the performances of this architecture in terms of latencies and conclude on the maximum number of signal-oriented frames and legacy ECUs that can be handled. The performance evaluation is conducted by simulation, with sensitivity analysis to identify the performance bottlenecks. The E/E architecture under study is a prototype TSN-based central computing architecture targeted at next-generation models. The main questions that will be discussed throughout the presentation are 1) how to efficiently handle signal to service conversion? 2) The performance and the scalability of the SW architecture proposed and 3) the suitability of SOME/IP as the SOA protocol.]]> Sun, 12 Jun 2022 06:15:50 GMT /REALTIMEATWORK/signaloriented-ecus-in-a-centralized-serviceoriented-architecture-scalability-of-the-layered-software-architecture REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Signal-Oriented ECUs in a Centralized Service-Oriented Architecture: Scalability of the Layered Software Architecture REALTIMEATWORK The industry is quickly moving away from a function/signal-oriented architecture towards Service-Oriented Architectures (SOA). To carry-over legacy signal-oriented ECUs during the transition phase, Volvo Cars has developed a layered software (SW) architecture based on the concepts of "device proxys" (i.e., one per legacy ECU), signal real-time database and service interface. This architecture, executing on the central computer on the TSN backbone, provides a clear separation of concerns between its components with a reduced additional complexity. In this presentation, we will review the main challenges faced in the integration of signal-oriented ECUs into SOA, and present the solutions explored at Volvo with a focus on layered SW architecture in the centralized E/E architecture and its 3 core components: o Device Proxies o Signal DataBase o Service Interface We then report on the performances of this architecture in terms of latencies and conclude on the maximum number of signal-oriented frames and legacy ECUs that can be handled. The performance evaluation is conducted by simulation, with sensitivity analysis to identify the performance bottlenecks. The E/E architecture under study is a prototype TSN-based central computing architecture targeted at next-generation models. The main questions that will be discussed throughout the presentation are 1) how to efficiently handle signal to service conversion? 2) The performance and the scalability of the SW architecture proposed and 3) the suitability of SOME/IP as the SOA protocol. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/aec22volvortawulsoa-220612061550-54a7ecc1-thumbnail.jpg?width=120&height=120&fit=bounds" /> The industry is quickly moving away from a function/signal-oriented architecture towards Service-Oriented Architectures (SOA). To carry-over legacy signal-oriented ECUs during the transition phase, Volvo Cars has developed a layered software (SW) architecture based on the concepts of "device proxys" (i.e., one per legacy ECU), signal real-time database and service interface. This architecture, executing on the central computer on the TSN backbone, provides a clear separation of concerns between its components with a reduced additional complexity. In this presentation, we will review the main challenges faced in the integration of signal-oriented ECUs into SOA, and present the solutions explored at Volvo with a focus on layered SW architecture in the centralized E/E architecture and its 3 core components: o Device Proxies o Signal DataBase o Service Interface We then report on the performances of this architecture in terms of latencies and conclude on the maximum number of signal-oriented frames and legacy ECUs that can be handled. The performance evaluation is conducted by simulation, with sensitivity analysis to identify the performance bottlenecks. The E/E architecture under study is a prototype TSN-based central computing architecture targeted at next-generation models. The main questions that will be discussed throughout the presentation are 1) how to efficiently handle signal to service conversion? 2) The performance and the scalability of the SW architecture proposed and 3) the suitability of SOME/IP as the SOA protocol.

Signal-Oriented ECUs in a Centralized Service-Oriented Architecture: Scalability of the Layered Software Architecture from RealTime-at-Work (RTaW)

]]> 5759 0 https://cdn.slidesharecdn.com/ss_thumbnails/aec22volvortawulsoa-220612061550-54a7ecc1-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Do We Really Need TSN in Next-Generation Helicopters? Insights From a Case-Study /slideshow/do-we-really-need-tsn-in-nextgeneration-helicopters-insights-from-a-casestudy/250341537 dasc2021presentation-210930113016
As Ethernet rapidly replaces legacy networks as the core high-speed network in helicopter’s avionics and mission systems, we ask in this paper the question of the technical benefits of migrating to Ethernet Time-Sensitive-Networking (TSN). Indeed, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. TSN is quickly becoming the prominent technology for wired high-speed communications in a variety of application domains like automotive, industry 4.0 and telecom. In this context, this work explores the use of TSN timing QoS mechanisms for helicopter’s avionics and mission systems on a case-study representative of the communication requirements of next-generation systems. This study aims to provide quantified insights into what can be expected from TSN in terms of timing, memory usage and extensibility. Paper available at http://hdl.handle.net/10993/48093]]>
As Ethernet rapidly replaces legacy networks as the core high-speed network in helicopter’s avionics and mission systems, we ask in this paper the question of the technical benefits of migrating to Ethernet Time-Sensitive-Networking (TSN). Indeed, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. TSN is quickly becoming the prominent technology for wired high-speed communications in a variety of application domains like automotive, industry 4.0 and telecom. In this context, this work explores the use of TSN timing QoS mechanisms for helicopter’s avionics and mission systems on a case-study representative of the communication requirements of next-generation systems. This study aims to provide quantified insights into what can be expected from TSN in terms of timing, memory usage and extensibility. Paper available at http://hdl.handle.net/10993/48093]]> Thu, 30 Sep 2021 11:30:16 GMT /slideshow/do-we-really-need-tsn-in-nextgeneration-helicopters-insights-from-a-casestudy/250341537 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Do We Really Need TSN in Next-Generation Helicopters? Insights From a Case-Study REALTIMEATWORK As Ethernet rapidly replaces legacy networks as the core high-speed network in helicopter’s avionics and mission systems, we ask in this paper the question of the technical benefits of migrating to Ethernet Time-Sensitive-Networking (TSN). Indeed, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. TSN is quickly becoming the prominent technology for wired high-speed communications in a variety of application domains like automotive, industry 4.0 and telecom. In this context, this work explores the use of TSN timing QoS mechanisms for helicopter’s avionics and mission systems on a case-study representative of the communication requirements of next-generation systems. This study aims to provide quantified insights into what can be expected from TSN in terms of timing, memory usage and extensibility. Paper available at http://hdl.handle.net/10993/48093 <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/dasc2021presentation-210930113016-thumbnail.jpg?width=120&height=120&fit=bounds" /> As Ethernet rapidly replaces legacy networks as the core high-speed network in helicopter’s avionics and mission systems, we ask in this paper the question of the technical benefits of migrating to Ethernet Time-Sensitive-Networking (TSN). Indeed, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. TSN is quickly becoming the prominent technology for wired high-speed communications in a variety of application domains like automotive, industry 4.0 and telecom. In this context, this work explores the use of TSN timing QoS mechanisms for helicopter’s avionics and mission systems on a case-study representative of the communication requirements of next-generation systems. This study aims to provide quantified insights into what can be expected from TSN in terms of timing, memory usage and extensibility. Paper available at http://hdl.handle.net/10993/48093

Do We Really Need TSN in Next-Generation Helicopters? Insights From a Case-Study from RealTime-at-Work (RTaW)

]]> 1803 0 https://cdn.slidesharecdn.com/ss_thumbnails/dasc2021presentation-210930113016-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 QoS-Predictable SOA on TSN: Insights from a Case-Study /slideshow/qospredictable-soa-on-tsn-insights-from-a-casestudy/243549094 aec21-some-ip-210227084246
This work is about the design and configuration of service-oriented communication on top of Ethernet TSN. The first objective is to present takeaways from the design and implementation of the Renault E/E Service-Oriented Architecture (SOA) called FACE. In particular, we discuss technological, design and configuration choices made for the SOA, such as how to segment messages (UDP with multiple events, TCP, SOME/IP TP), and the technical possibilities to shape the transmission of the packets on the Ethernet network. The second objective is to study how to ensure the Quality of Service (QoS) required by services. Indeed, services introduce specific challenges, be it only the sheer amount of traffic they generate and if there is a growing body of experiences in the use of TSN QoS mechanisms most of what has been learned so far is mostly about meeting the requirements of individual streams. Less is known for services that involve the transmission of several, possibly segmented, messages with more complex transmission patterns. We show on the FACE architecture how SOME/IP messages were mapped to TSN QoS mechanisms in a manual then automated manner so as to meet the individual requirements of the services in terms of timing, and the system’s requirements in terms of memory usage.]]>
This work is about the design and configuration of service-oriented communication on top of Ethernet TSN. The first objective is to present takeaways from the design and implementation of the Renault E/E Service-Oriented Architecture (SOA) called FACE. In particular, we discuss technological, design and configuration choices made for the SOA, such as how to segment messages (UDP with multiple events, TCP, SOME/IP TP), and the technical possibilities to shape the transmission of the packets on the Ethernet network. The second objective is to study how to ensure the Quality of Service (QoS) required by services. Indeed, services introduce specific challenges, be it only the sheer amount of traffic they generate and if there is a growing body of experiences in the use of TSN QoS mechanisms most of what has been learned so far is mostly about meeting the requirements of individual streams. Less is known for services that involve the transmission of several, possibly segmented, messages with more complex transmission patterns. We show on the FACE architecture how SOME/IP messages were mapped to TSN QoS mechanisms in a manual then automated manner so as to meet the individual requirements of the services in terms of timing, and the system’s requirements in terms of memory usage.]]> Sat, 27 Feb 2021 08:42:46 GMT /slideshow/qospredictable-soa-on-tsn-insights-from-a-casestudy/243549094 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) QoS-Predictable SOA on TSN: Insights from a Case-Study REALTIMEATWORK This work is about the design and configuration of service-oriented communication on top of Ethernet TSN. The first objective is to present takeaways from the design and implementation of the Renault E/E Service-Oriented Architecture (SOA) called FACE. In particular, we discuss technological, design and configuration choices made for the SOA, such as how to segment messages (UDP with multiple events, TCP, SOME/IP TP), and the technical possibilities to shape the transmission of the packets on the Ethernet network. The second objective is to study how to ensure the Quality of Service (QoS) required by services. Indeed, services introduce specific challenges, be it only the sheer amount of traffic they generate and if there is a growing body of experiences in the use of TSN QoS mechanisms most of what has been learned so far is mostly about meeting the requirements of individual streams. Less is known for services that involve the transmission of several, possibly segmented, messages with more complex transmission patterns. We show on the FACE architecture how SOME/IP messages were mapped to TSN QoS mechanisms in a manual then automated manner so as to meet the individual requirements of the services in terms of timing, and the system’s requirements in terms of memory usage. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/aec21-some-ip-210227084246-thumbnail.jpg?width=120&height=120&fit=bounds" /> This work is about the design and configuration of service-oriented communication on top of Ethernet TSN. The first objective is to present takeaways from the design and implementation of the Renault E/E Service-Oriented Architecture (SOA) called FACE. In particular, we discuss technological, design and configuration choices made for the SOA, such as how to segment messages (UDP with multiple events, TCP, SOME/IP TP), and the technical possibilities to shape the transmission of the packets on the Ethernet network. The second objective is to study how to ensure the Quality of Service (QoS) required by services. Indeed, services introduce specific challenges, be it only the sheer amount of traffic they generate and if there is a growing body of experiences in the use of TSN QoS mechanisms most of what has been learned so far is mostly about meeting the requirements of individual streams. Less is known for services that involve the transmission of several, possibly segmented, messages with more complex transmission patterns. We show on the FACE architecture how SOME/IP messages were mapped to TSN QoS mechanisms in a manual then automated manner so as to meet the individual requirements of the services in terms of timing, and the system’s requirements in terms of memory usage.

QoS-Predictable SOA on TSN: Insights from a Case-Study from RealTime-at-Work (RTaW)

]]> 2638 0 https://cdn.slidesharecdn.com/ss_thumbnails/aec21-some-ip-210227084246-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Simulation-Based Fault Injection as a Verification Oracle for the Engineering of Time-Triggered Ethernet networks /slideshow/simulationbased-fault-injection-as-a-verification-oracle-for-the-engineering-of-timetriggered-ethernet-networks/240806145 erts2018tte-210101113753
TTEthernet (TTE) is considered for use as high-speed backbone in the avionics of next-generation orbital space launchers. Given the key role of communication in launchers, the OEM must acquire a precise understanding of TTE’s functioning and its performances in nominal and error conditions. This holds especially true for the clock synchronization algorithm, the cornerstone of time-triggered communication in TTE, which involves complex distributed algorithms. In this study, we use both an experimental platform and fault-injection on a simulation model to gain quantified insights in these questions. We first describe a fine-grained simulation model of TTE model and discuss how it has been validated against communication traces recorded on the TTE platform. We then present experiments that evaluate the accuracy of the clock synchronization in TTE in the fault-free case as well as considering permanent link failure and transient transmission errors. Finally, we discuss what we have learned during the project in terms of development process and programming language support for complex simulation models used in the design of critical systems. ]]>
TTEthernet (TTE) is considered for use as high-speed backbone in the avionics of next-generation orbital space launchers. Given the key role of communication in launchers, the OEM must acquire a precise understanding of TTE’s functioning and its performances in nominal and error conditions. This holds especially true for the clock synchronization algorithm, the cornerstone of time-triggered communication in TTE, which involves complex distributed algorithms. In this study, we use both an experimental platform and fault-injection on a simulation model to gain quantified insights in these questions. We first describe a fine-grained simulation model of TTE model and discuss how it has been validated against communication traces recorded on the TTE platform. We then present experiments that evaluate the accuracy of the clock synchronization in TTE in the fault-free case as well as considering permanent link failure and transient transmission errors. Finally, we discuss what we have learned during the project in terms of development process and programming language support for complex simulation models used in the design of critical systems. ]]> Fri, 01 Jan 2021 11:37:53 GMT /slideshow/simulationbased-fault-injection-as-a-verification-oracle-for-the-engineering-of-timetriggered-ethernet-networks/240806145 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Simulation-Based Fault Injection as a Verification Oracle for the Engineering of Time-Triggered Ethernet networks REALTIMEATWORK TTEthernet (TTE) is considered for use as high-speed backbone in the avionics of next-generation orbital space launchers. Given the key role of communication in launchers, the OEM must acquire a precise understanding of TTE’s functioning and its performances in nominal and error conditions. This holds especially true for the clock synchronization algorithm, the cornerstone of time-triggered communication in TTE, which involves complex distributed algorithms. In this study, we use both an experimental platform and fault-injection on a simulation model to gain quantified insights in these questions. We first describe a fine-grained simulation model of TTE model and discuss how it has been validated against communication traces recorded on the TTE platform. We then present experiments that evaluate the accuracy of the clock synchronization in TTE in the fault-free case as well as considering permanent link failure and transient transmission errors. Finally, we discuss what we have learned during the project in terms of development process and programming language support for complex simulation models used in the design of critical systems. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/erts2018tte-210101113753-thumbnail.jpg?width=120&height=120&fit=bounds" /> TTEthernet (TTE) is considered for use as high-speed backbone in the avionics of next-generation orbital space launchers. Given the key role of communication in launchers, the OEM must acquire a precise understanding of TTE’s functioning and its performances in nominal and error conditions. This holds especially true for the clock synchronization algorithm, the cornerstone of time-triggered communication in TTE, which involves complex distributed algorithms. In this study, we use both an experimental platform and fault-injection on a simulation model to gain quantified insights in these questions. We first describe a fine-grained simulation model of TTE model and discuss how it has been validated against communication traces recorded on the TTE platform. We then present experiments that evaluate the accuracy of the clock synchronization in TTE in the fault-free case as well as considering permanent link failure and transient transmission errors. Finally, we discuss what we have learned during the project in terms of development process and programming language support for complex simulation models used in the design of critical systems.

Simulation-Based Fault Injection as a Verification Oracle for the Engineering of Time-Triggered Ethernet networks from RealTime-at-Work (RTaW)

]]> 2281 0 https://cdn.slidesharecdn.com/ss_thumbnails/erts2018tte-210101113753-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Practical Use Cases for Ethernet Redundancy /REALTIMEATWORK/practical-use-cases-for-ethernet-redundancy d305pannellpracticalusecasesforethernetredundancyfinal-201031112017
Autonomous driving requires safety considerations and the need of “fail operational” requires redundancy. In the networking portion of a car, this may mean separate networks, possibly of different technologies. Or it could mean a network topology and technology that supports scalable redundancy, like Ethernet TSN. This presentation focuses on IEEE 802.1CB-2017, which is the TSN standard that supports data redundancy through the network. Various network topologies are examined. The relative costs of adding TSN redundancy for these topologies (including some, or all of, the end-stations/ECUs & bridges) are examined for various bandwidth utilizations, along with the expected packet loss. Each topology and bandwidth will be modeled under various bit-rate error values with the results discussed. This presentation aims at providing a clear understanding of the TSN standards that support redundancy, and an understanding of the cost/benefit tradeoffs so proper engineering decisions can be made and proper expectations set.]]>
Autonomous driving requires safety considerations and the need of “fail operational” requires redundancy. In the networking portion of a car, this may mean separate networks, possibly of different technologies. Or it could mean a network topology and technology that supports scalable redundancy, like Ethernet TSN. This presentation focuses on IEEE 802.1CB-2017, which is the TSN standard that supports data redundancy through the network. Various network topologies are examined. The relative costs of adding TSN redundancy for these topologies (including some, or all of, the end-stations/ECUs & bridges) are examined for various bandwidth utilizations, along with the expected packet loss. Each topology and bandwidth will be modeled under various bit-rate error values with the results discussed. This presentation aims at providing a clear understanding of the TSN standards that support redundancy, and an understanding of the cost/benefit tradeoffs so proper engineering decisions can be made and proper expectations set.]]> Sat, 31 Oct 2020 11:20:17 GMT /REALTIMEATWORK/practical-use-cases-for-ethernet-redundancy REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Practical Use Cases for Ethernet Redundancy REALTIMEATWORK Autonomous driving requires safety considerations and the need of “fail operational” requires redundancy. In the networking portion of a car, this may mean separate networks, possibly of different technologies. Or it could mean a network topology and technology that supports scalable redundancy, like Ethernet TSN. This presentation focuses on IEEE 802.1CB-2017, which is the TSN standard that supports data redundancy through the network. Various network topologies are examined. The relative costs of adding TSN redundancy for these topologies (including some, or all of, the end-stations/ECUs & bridges) are examined for various bandwidth utilizations, along with the expected packet loss. Each topology and bandwidth will be modeled under various bit-rate error values with the results discussed. This presentation aims at providing a clear understanding of the TSN standards that support redundancy, and an understanding of the cost/benefit tradeoffs so proper engineering decisions can be made and proper expectations set. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/d305pannellpracticalusecasesforethernetredundancyfinal-201031112017-thumbnail.jpg?width=120&height=120&fit=bounds" /> Autonomous driving requires safety considerations and the need of “fail operational” requires redundancy. In the networking portion of a car, this may mean separate networks, possibly of different technologies. Or it could mean a network topology and technology that supports scalable redundancy, like Ethernet TSN. This presentation focuses on IEEE 802.1CB-2017, which is the TSN standard that supports data redundancy through the network. Various network topologies are examined. The relative costs of adding TSN redundancy for these topologies (including some, or all of, the end-stations/ECUs & bridges) are examined for various bandwidth utilizations, along with the expected packet loss. Each topology and bandwidth will be modeled under various bit-rate error values with the results discussed. This presentation aims at providing a clear understanding of the TSN standards that support redundancy, and an understanding of the cost/benefit tradeoffs so proper engineering decisions can be made and proper expectations set.

Practical Use Cases for Ethernet Redundancy from RealTime-at-Work (RTaW)

]]> 2332 0 https://cdn.slidesharecdn.com/ss_thumbnails/d305pannellpracticalusecasesforethernetredundancyfinal-201031112017-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Towards Computer-Aided, Iterative TSN-and Ethernet-based E/E Architecture Design /slideshow/towards-computeraided-iterative-tsnand-ethernetbased-ee-architecture-design/239031974 ieee-tech-days-bmw-ul-rtaw-201031110608
Typical design goals of next generation architectures are future extensibility and cost optimization of the lowest-end. We propose to introduce guidance to an otherwise standard Monte-Carlo simulation by providing certain fixed points (e.g., mandated connections of ECUs to certain bridges, complete re-use of ECUs) and “hot spots” in the topology (e.g., ECUs with the highest variability pressure) that are known in advance from BMW’s experience with their vehicles in the field. Several important practical considerations must be integrated in the generation of candidate architectures: - Topological constraints: ECU proximity to sensors, daisy chain connections between ECUs to minimize cable length, number of switch ports in a certain ECU, etc. - Security and reliability requirements: segregation between mixed-criticality streams, proxy ECUs, and redundant paths. Our position statement explores the ability of algorithmic tools to synthesize Ethernet-based architectures based on a minimal fixed core TSN topology, design goals, design constraints, assumptions about next generation applications and data from past projects (capturing part of the OEM domain knowledge).]]>
Typical design goals of next generation architectures are future extensibility and cost optimization of the lowest-end. We propose to introduce guidance to an otherwise standard Monte-Carlo simulation by providing certain fixed points (e.g., mandated connections of ECUs to certain bridges, complete re-use of ECUs) and “hot spots” in the topology (e.g., ECUs with the highest variability pressure) that are known in advance from BMW’s experience with their vehicles in the field. Several important practical considerations must be integrated in the generation of candidate architectures: - Topological constraints: ECU proximity to sensors, daisy chain connections between ECUs to minimize cable length, number of switch ports in a certain ECU, etc. - Security and reliability requirements: segregation between mixed-criticality streams, proxy ECUs, and redundant paths. Our position statement explores the ability of algorithmic tools to synthesize Ethernet-based architectures based on a minimal fixed core TSN topology, design goals, design constraints, assumptions about next generation applications and data from past projects (capturing part of the OEM domain knowledge).]]> Sat, 31 Oct 2020 11:06:07 GMT /slideshow/towards-computeraided-iterative-tsnand-ethernetbased-ee-architecture-design/239031974 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Towards Computer-Aided, Iterative TSN-and Ethernet-based E/E Architecture Design REALTIMEATWORK Typical design goals of next generation architectures are future extensibility and cost optimization of the lowest-end. We propose to introduce guidance to an otherwise standard Monte-Carlo simulation by providing certain fixed points (e.g., mandated connections of ECUs to certain bridges, complete re-use of ECUs) and “hot spots” in the topology (e.g., ECUs with the highest variability pressure) that are known in advance from BMW’s experience with their vehicles in the field. Several important practical considerations must be integrated in the generation of candidate architectures: - Topological constraints: ECU proximity to sensors, daisy chain connections between ECUs to minimize cable length, number of switch ports in a certain ECU, etc. - Security and reliability requirements: segregation between mixed-criticality streams, proxy ECUs, and redundant paths. Our position statement explores the ability of algorithmic tools to synthesize Ethernet-based architectures based on a minimal fixed core TSN topology, design goals, design constraints, assumptions about next generation applications and data from past projects (capturing part of the OEM domain knowledge). <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ieee-tech-days-bmw-ul-rtaw-201031110608-thumbnail.jpg?width=120&height=120&fit=bounds" /> Typical design goals of next generation architectures are future extensibility and cost optimization of the lowest-end. We propose to introduce guidance to an otherwise standard Monte-Carlo simulation by providing certain fixed points (e.g., mandated connections of ECUs to certain bridges, complete re-use of ECUs) and “hot spots” in the topology (e.g., ECUs with the highest variability pressure) that are known in advance from BMW’s experience with their vehicles in the field. Several important practical considerations must be integrated in the generation of candidate architectures: - Topological constraints: ECU proximity to sensors, daisy chain connections between ECUs to minimize cable length, number of switch ports in a certain ECU, etc. - Security and reliability requirements: segregation between mixed-criticality streams, proxy ECUs, and redundant paths. Our position statement explores the ability of algorithmic tools to synthesize Ethernet-based architectures based on a minimal fixed core TSN topology, design goals, design constraints, assumptions about next generation applications and data from past projects (capturing part of the OEM domain knowledge).

Towards Computer-Aided, Iterative TSN-and Ethernet-based E/E Architecture Design from RealTime-at-Work (RTaW)

]]> 3575 0 https://cdn.slidesharecdn.com/ss_thumbnails/ieee-tech-days-bmw-ul-rtaw-201031110608-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Early-stage Bottleneck Identification and Removal in TSN Networks /slideshow/earlystage-bottleneck-identification-and-removal-in-tsn-networks/229444914 aec2020-ul-volvo-rtaw-web-200229092331
There has been a pivotal change in the design of E/E architectures, which is that we cannot assume anymore that the functions, and thus the communication requirements, are known in advance and fixed over time. It has become crucial for OEMs to be in the position to add further functions / services during the lifetime of the vehicle: OEMs need to design E/E architectures that are future-proof. We show how design space exploration, by answering a series of design questions and proposing solutions to the designers, helps to improve an automotive E/E architecture in several dimensions. We start by estimating the total "capacity" of a baseline architecture, then, by removing bottlenecks, we obtain an "enhanced capacity" architecture. The architecture is then further optimized in terms of costs and reliability. The work is conducted on Volvo's prototype centralized E/E and domain-based E/E architectures. ]]>
There has been a pivotal change in the design of E/E architectures, which is that we cannot assume anymore that the functions, and thus the communication requirements, are known in advance and fixed over time. It has become crucial for OEMs to be in the position to add further functions / services during the lifetime of the vehicle: OEMs need to design E/E architectures that are future-proof. We show how design space exploration, by answering a series of design questions and proposing solutions to the designers, helps to improve an automotive E/E architecture in several dimensions. We start by estimating the total "capacity" of a baseline architecture, then, by removing bottlenecks, we obtain an "enhanced capacity" architecture. The architecture is then further optimized in terms of costs and reliability. The work is conducted on Volvo's prototype centralized E/E and domain-based E/E architectures. ]]> Sat, 29 Feb 2020 09:23:31 GMT /slideshow/earlystage-bottleneck-identification-and-removal-in-tsn-networks/229444914 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Early-stage Bottleneck Identification and Removal in TSN Networks REALTIMEATWORK There has been a pivotal change in the design of E/E architectures, which is that we cannot assume anymore that the functions, and thus the communication requirements, are known in advance and fixed over time. It has become crucial for OEMs to be in the position to add further functions / services during the lifetime of the vehicle: OEMs need to design E/E architectures that are future-proof. We show how design space exploration, by answering a series of design questions and proposing solutions to the designers, helps to improve an automotive E/E architecture in several dimensions. We start by estimating the total "capacity" of a baseline architecture, then, by removing bottlenecks, we obtain an "enhanced capacity" architecture. The architecture is then further optimized in terms of costs and reliability. The work is conducted on Volvo's prototype centralized E/E and domain-based E/E architectures. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/aec2020-ul-volvo-rtaw-web-200229092331-thumbnail.jpg?width=120&height=120&fit=bounds" /> There has been a pivotal change in the design of E/E architectures, which is that we cannot assume anymore that the functions, and thus the communication requirements, are known in advance and fixed over time. It has become crucial for OEMs to be in the position to add further functions / services during the lifetime of the vehicle: OEMs need to design E/E architectures that are future-proof. We show how design space exploration, by answering a series of design questions and proposing solutions to the designers, helps to improve an automotive E/E architecture in several dimensions. We start by estimating the total "capacity" of a baseline architecture, then, by removing bottlenecks, we obtain an "enhanced capacity" architecture. The architecture is then further optimized in terms of costs and reliability. The work is conducted on Volvo's prototype centralized E/E and domain-based E/E architectures.

Early-stage Bottleneck Identification and Removal in TSN Networks from RealTime-at-Work (RTaW)

]]> 7810 0 https://cdn.slidesharecdn.com/ss_thumbnails/aec2020-ul-volvo-rtaw-web-200229092331-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Early-stage topological and technological choices for TSN-based communication architectures /slideshow/earlystage-topological-and-technological-choices-for-tsnbased-communication-architectures/177059942 ieee-ethernet-tech-days2019-190928083820
A main issue in the design of automotive communication architectures is that the most important design choices pertaining to the topology of the networks and the technologies to use (protocols, data rate, hardware) have to be made at a time when the communication requirements are not entirely known. Indeed, many functions only becomes available along the development cycle, and vehicle platforms have to support incremental evolutions of the embedded system that may not be fully foreseeable at the time design choices are made. The problem is becoming even more difficult and crucial with the introduction of dynamically evolving communication requirements requiring network re-configuration at run-time. We present how the use of synthetic data, that is data generated programmatically based on past vehicle projects and what can be foreseen for the current project, enables the designers to make such early stage choices based on quantified metrics. The proposals are applied to Groupe Renault's FACE service-oriented E/E architecture with the use of the “Topology Stress Test” feature implemented in RTaW-Pegase.]]>
A main issue in the design of automotive communication architectures is that the most important design choices pertaining to the topology of the networks and the technologies to use (protocols, data rate, hardware) have to be made at a time when the communication requirements are not entirely known. Indeed, many functions only becomes available along the development cycle, and vehicle platforms have to support incremental evolutions of the embedded system that may not be fully foreseeable at the time design choices are made. The problem is becoming even more difficult and crucial with the introduction of dynamically evolving communication requirements requiring network re-configuration at run-time. We present how the use of synthetic data, that is data generated programmatically based on past vehicle projects and what can be foreseen for the current project, enables the designers to make such early stage choices based on quantified metrics. The proposals are applied to Groupe Renault's FACE service-oriented E/E architecture with the use of the “Topology Stress Test” feature implemented in RTaW-Pegase.]]> Sat, 28 Sep 2019 08:38:20 GMT /slideshow/earlystage-topological-and-technological-choices-for-tsnbased-communication-architectures/177059942 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Early-stage topological and technological choices for TSN-based communication architectures REALTIMEATWORK A main issue in the design of automotive communication architectures is that the most important design choices pertaining to the topology of the networks and the technologies to use (protocols, data rate, hardware) have to be made at a time when the communication requirements are not entirely known. Indeed, many functions only becomes available along the development cycle, and vehicle platforms have to support incremental evolutions of the embedded system that may not be fully foreseeable at the time design choices are made. The problem is becoming even more difficult and crucial with the introduction of dynamically evolving communication requirements requiring network re-configuration at run-time. We present how the use of synthetic data, that is data generated programmatically based on past vehicle projects and what can be foreseen for the current project, enables the designers to make such early stage choices based on quantified metrics. The proposals are applied to Groupe Renault's FACE service-oriented E/E architecture with the use of the “Topology Stress Test” feature implemented in RTaW-Pegase. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ieee-ethernet-tech-days2019-190928083820-thumbnail.jpg?width=120&height=120&fit=bounds" /> A main issue in the design of automotive communication architectures is that the most important design choices pertaining to the topology of the networks and the technologies to use (protocols, data rate, hardware) have to be made at a time when the communication requirements are not entirely known. Indeed, many functions only becomes available along the development cycle, and vehicle platforms have to support incremental evolutions of the embedded system that may not be fully foreseeable at the time design choices are made. The problem is becoming even more difficult and crucial with the introduction of dynamically evolving communication requirements requiring network re-configuration at run-time. We present how the use of synthetic data, that is data generated programmatically based on past vehicle projects and what can be foreseen for the current project, enables the designers to make such early stage choices based on quantified metrics. The proposals are applied to Groupe Renault's FACE service-oriented E/E architecture with the use of the “Topology Stress Test” feature implemented in RTaW-Pegase.

Early-stage topological and technological choices for TSN-based communication architectures from RealTime-at-Work (RTaW)

]]> 3539 3 https://cdn.slidesharecdn.com/ss_thumbnails/ieee-ethernet-tech-days2019-190928083820-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Insights into the performance and configuration of TCP in Automotive Ethernet Networks /slideshow/insights-into-the-performance-and-configuration-of-tcp-in-automotive-ethernet-networks/121434175 tcp-on-tsntechdays2018-181101152728
The idea of using TCP in cars has been around for some time, as the first specification of Autosar TCP/IP stack dates back from early 2013. However, TCP has not been popular yet in cars and there has not been much published works on using TCP for in-vehicle communications so far. TCP – the Transmission Control Protocol – provides connection-oriented reliable transmission between network applications. TCP is the cornerstone of the Internet – a hugely successful protocol over the last 40 years – if it is certainly a fine piece of engineering but it is definitely a complex one. The question we explore in this study is what can we expect from TCP for on-board in-vehicle communication in terms of latencies & throughput and how to best configure TCP in a context for which it has not been conceived. In particular, we will show that TCP configuration on the ECU sides should consider the amount of memory available in the switches and that traffic shaping policy, as available in TSN, can provide a nice performance boost for TCP communication.]]>
The idea of using TCP in cars has been around for some time, as the first specification of Autosar TCP/IP stack dates back from early 2013. However, TCP has not been popular yet in cars and there has not been much published works on using TCP for in-vehicle communications so far. TCP – the Transmission Control Protocol – provides connection-oriented reliable transmission between network applications. TCP is the cornerstone of the Internet – a hugely successful protocol over the last 40 years – if it is certainly a fine piece of engineering but it is definitely a complex one. The question we explore in this study is what can we expect from TCP for on-board in-vehicle communication in terms of latencies & throughput and how to best configure TCP in a context for which it has not been conceived. In particular, we will show that TCP configuration on the ECU sides should consider the amount of memory available in the switches and that traffic shaping policy, as available in TSN, can provide a nice performance boost for TCP communication.]]> Thu, 01 Nov 2018 15:27:28 GMT /slideshow/insights-into-the-performance-and-configuration-of-tcp-in-automotive-ethernet-networks/121434175 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Insights into the performance and configuration of TCP in Automotive Ethernet Networks REALTIMEATWORK The idea of using TCP in cars has been around for some time, as the first specification of Autosar TCP/IP stack dates back from early 2013. However, TCP has not been popular yet in cars and there has not been much published works on using TCP for in-vehicle communications so far. TCP – the Transmission Control Protocol – provides connection-oriented reliable transmission between network applications. TCP is the cornerstone of the Internet – a hugely successful protocol over the last 40 years – if it is certainly a fine piece of engineering but it is definitely a complex one. The question we explore in this study is what can we expect from TCP for on-board in-vehicle communication in terms of latencies & throughput and how to best configure TCP in a context for which it has not been conceived. In particular, we will show that TCP configuration on the ECU sides should consider the amount of memory available in the switches and that traffic shaping policy, as available in TSN, can provide a nice performance boost for TCP communication. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/tcp-on-tsntechdays2018-181101152728-thumbnail.jpg?width=120&height=120&fit=bounds" /> The idea of using TCP in cars has been around for some time, as the first specification of Autosar TCP/IP stack dates back from early 2013. However, TCP has not been popular yet in cars and there has not been much published works on using TCP for in-vehicle communications so far. TCP – the Transmission Control Protocol – provides connection-oriented reliable transmission between network applications. TCP is the cornerstone of the Internet – a hugely successful protocol over the last 40 years – if it is certainly a fine piece of engineering but it is definitely a complex one. The question we explore in this study is what can we expect from TCP for on-board in-vehicle communication in terms of latencies & throughput and how to best configure TCP in a context for which it has not been conceived. In particular, we will show that TCP configuration on the ECU sides should consider the amount of memory available in the switches and that traffic shaping policy, as available in TSN, can provide a nice performance boost for TCP communication.

Insights into the performance and configuration of TCP in Automotive Ethernet Networks from RealTime-at-Work (RTaW)

]]> 2799 2 https://cdn.slidesharecdn.com/ss_thumbnails/tcp-on-tsntechdays2018-181101152728-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Insights on the Performance and Configuration of AVB and TSN in Automotive Applications /REALTIMEATWORK/insights-on-the-performance-and-configuration-of-avb-and-tsn-in-automotive-applications ieee-tech-daysrtaw-180216203808
Switched Ethernet is profoundly reshaping in-car communications. To meet the diverse real-time requirements in automotive communications, Quality-of-Service protocols that go beyond the mere use of priorities are required. In this work, the basic questions that we investigate on a case-study with diverse and demanding communication requirements is what can we expect from the various protocols aimed at providing a better timing Quality of Service on top of Ethernet? And how to use them? Especially how to use them in a combined manner. We will focus on the Credit-Based Shaper of AVB, the Time-Aware Shaper of TSN and the use of priorities as defined in IEEE802.1Q. The performance metrics considered are the distributions of the communication latencies, obtained by simulation, as well as upper bounds on these quantities obtained by worst-case schedulability analysis. If there have been over the last 5 years numerous studies on the performance of AVB CBS, the literature on comparing AVB to TSN and other candidate protocols is still sparse. To the best of our knowledge, this empirical study is the first to consider most protocols currently considered in the automotive domain, with the aim to gain insights into the different technological, design and configurations alternatives. In particular, an objective of this study is to identify key problems that need to be solved in order to further automate network design and configuration. ]]>
Switched Ethernet is profoundly reshaping in-car communications. To meet the diverse real-time requirements in automotive communications, Quality-of-Service protocols that go beyond the mere use of priorities are required. In this work, the basic questions that we investigate on a case-study with diverse and demanding communication requirements is what can we expect from the various protocols aimed at providing a better timing Quality of Service on top of Ethernet? And how to use them? Especially how to use them in a combined manner. We will focus on the Credit-Based Shaper of AVB, the Time-Aware Shaper of TSN and the use of priorities as defined in IEEE802.1Q. The performance metrics considered are the distributions of the communication latencies, obtained by simulation, as well as upper bounds on these quantities obtained by worst-case schedulability analysis. If there have been over the last 5 years numerous studies on the performance of AVB CBS, the literature on comparing AVB to TSN and other candidate protocols is still sparse. To the best of our knowledge, this empirical study is the first to consider most protocols currently considered in the automotive domain, with the aim to gain insights into the different technological, design and configurations alternatives. In particular, an objective of this study is to identify key problems that need to be solved in order to further automate network design and configuration. ]]> Fri, 16 Feb 2018 20:38:08 GMT /REALTIMEATWORK/insights-on-the-performance-and-configuration-of-avb-and-tsn-in-automotive-applications REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Insights on the Performance and Configuration of AVB and TSN in Automotive Applications REALTIMEATWORK Switched Ethernet is profoundly reshaping in-car communications. To meet the diverse real-time requirements in automotive communications, Quality-of-Service protocols that go beyond the mere use of priorities are required. In this work, the basic questions that we investigate on a case-study with diverse and demanding communication requirements is what can we expect from the various protocols aimed at providing a better timing Quality of Service on top of Ethernet? And how to use them? Especially how to use them in a combined manner. We will focus on the Credit-Based Shaper of AVB, the Time-Aware Shaper of TSN and the use of priorities as defined in IEEE802.1Q. The performance metrics considered are the distributions of the communication latencies, obtained by simulation, as well as upper bounds on these quantities obtained by worst-case schedulability analysis. If there have been over the last 5 years numerous studies on the performance of AVB CBS, the literature on comparing AVB to TSN and other candidate protocols is still sparse. To the best of our knowledge, this empirical study is the first to consider most protocols currently considered in the automotive domain, with the aim to gain insights into the different technological, design and configurations alternatives. In particular, an objective of this study is to identify key problems that need to be solved in order to further automate network design and configuration. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ieee-tech-daysrtaw-180216203808-thumbnail.jpg?width=120&height=120&fit=bounds" /> Switched Ethernet is profoundly reshaping in-car communications. To meet the diverse real-time requirements in automotive communications, Quality-of-Service protocols that go beyond the mere use of priorities are required. In this work, the basic questions that we investigate on a case-study with diverse and demanding communication requirements is what can we expect from the various protocols aimed at providing a better timing Quality of Service on top of Ethernet? And how to use them? Especially how to use them in a combined manner. We will focus on the Credit-Based Shaper of AVB, the Time-Aware Shaper of TSN and the use of priorities as defined in IEEE802.1Q. The performance metrics considered are the distributions of the communication latencies, obtained by simulation, as well as upper bounds on these quantities obtained by worst-case schedulability analysis. If there have been over the last 5 years numerous studies on the performance of AVB CBS, the literature on comparing AVB to TSN and other candidate protocols is still sparse. To the best of our knowledge, this empirical study is the first to consider most protocols currently considered in the automotive domain, with the aim to gain insights into the different technological, design and configurations alternatives. In particular, an objective of this study is to identify key problems that need to be solved in order to further automate network design and configuration.

Insights on the Performance and Configuration of AVB and TSN in Automotive Applications from RealTime-at-Work (RTaW)

]]> 4991 5 https://cdn.slidesharecdn.com/ss_thumbnails/ieee-tech-daysrtaw-180216203808-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Timing verification of real-time automotive Ethernet networks: what can we expect from simulation? /slideshow/timing-verification-of-realtime-automotive-ethernet-networks-what-can-we-expect-from-simulation/70768391 sae-simulation-170107104941
Switched Ethernet is a technology that is profoundly reshaping automotive communication architectures as it did in other application domains such as avionics with the use of AFDX backbones. Early stage timing verification of critical embedded networks typically relies on simulation and worst-case schedulability analysis. When the modeling power of schedulability analysis is not sufficient, there are typically two options: either make pessimistic assumptions or ignore what cannot be modeled. Both options are unsatisfactory because they are either inefficient in terms of resource usage or potentially unsafe. To overcome those issues, we believe it is a good practice to use simulation models, which can be more realistic, along with schedulability analysis. The two basic questions that we aim to study here is what can we expect from simulation, and how to use it properly? This empirical study explores these questions on realistic case-studies and provides methodological guidelines for the use of simulation in the design of switched Ethernet networks. A broader objective of the study is to compare the outcomes of schedulability analyses and simulation, and conclude about the scope of usability of simulation in the desi gn of critical Ethernet networks]]>
Switched Ethernet is a technology that is profoundly reshaping automotive communication architectures as it did in other application domains such as avionics with the use of AFDX backbones. Early stage timing verification of critical embedded networks typically relies on simulation and worst-case schedulability analysis. When the modeling power of schedulability analysis is not sufficient, there are typically two options: either make pessimistic assumptions or ignore what cannot be modeled. Both options are unsatisfactory because they are either inefficient in terms of resource usage or potentially unsafe. To overcome those issues, we believe it is a good practice to use simulation models, which can be more realistic, along with schedulability analysis. The two basic questions that we aim to study here is what can we expect from simulation, and how to use it properly? This empirical study explores these questions on realistic case-studies and provides methodological guidelines for the use of simulation in the design of switched Ethernet networks. A broader objective of the study is to compare the outcomes of schedulability analyses and simulation, and conclude about the scope of usability of simulation in the desi gn of critical Ethernet networks]]> Sat, 07 Jan 2017 10:49:41 GMT /slideshow/timing-verification-of-realtime-automotive-ethernet-networks-what-can-we-expect-from-simulation/70768391 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Timing verification of real-time automotive Ethernet networks: what can we expect from simulation? REALTIMEATWORK Switched Ethernet is a technology that is profoundly reshaping automotive communication architectures as it did in other application domains such as avionics with the use of AFDX backbones. Early stage timing verification of critical embedded networks typically relies on simulation and worst-case schedulability analysis. When the modeling power of schedulability analysis is not sufficient, there are typically two options: either make pessimistic assumptions or ignore what cannot be modeled. Both options are unsatisfactory because they are either inefficient in terms of resource usage or potentially unsafe. To overcome those issues, we believe it is a good practice to use simulation models, which can be more realistic, along with schedulability analysis. The two basic questions that we aim to study here is what can we expect from simulation, and how to use it properly? This empirical study explores these questions on realistic case-studies and provides methodological guidelines for the use of simulation in the design of switched Ethernet networks. A broader objective of the study is to compare the outcomes of schedulability analyses and simulation, and conclude about the scope of usability of simulation in the desi gn of critical Ethernet networks <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/sae-simulation-170107104941-thumbnail.jpg?width=120&height=120&fit=bounds" /> Switched Ethernet is a technology that is profoundly reshaping automotive communication architectures as it did in other application domains such as avionics with the use of AFDX backbones. Early stage timing verification of critical embedded networks typically relies on simulation and worst-case schedulability analysis. When the modeling power of schedulability analysis is not sufficient, there are typically two options: either make pessimistic assumptions or ignore what cannot be modeled. Both options are unsatisfactory because they are either inefficient in terms of resource usage or potentially unsafe. To overcome those issues, we believe it is a good practice to use simulation models, which can be more realistic, along with schedulability analysis. The two basic questions that we aim to study here is what can we expect from simulation, and how to use it properly? This empirical study explores these questions on realistic case-studies and provides methodological guidelines for the use of simulation in the design of switched Ethernet networks. A broader objective of the study is to compare the outcomes of schedulability analyses and simulation, and conclude about the scope of usability of simulation in the desi gn of critical Ethernet networks

Timing verification of real-time automotive Ethernet networks: what can we expect from simulation? from RealTime-at-Work (RTaW)

]]> 2870 5 https://cdn.slidesharecdn.com/ss_thumbnails/sae-simulation-170107104941-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Insights on the Configuration and Performances of SOME/IP Service Discovery /slideshow/insights-on-the-configuration-and-performances-of-someip-service-discovery/70768362 sae-someip-web-170107104713
Scalable Service-Oriented Middleware on IP (SOME/IP) is a proposal aimed at providing service-oriented communication in vehicles. SOME/IP nodes are able to dynamically discover and subscribe to available services through the SOME/IP Service Discovery protocol (SOME/IP SD). In this context, a key performance criterion to achieve the required responsiveness is the subscription latency that is the time it takes for a client to subscribe to a service. In this paper we provide a recap of SOME/SD and list a number of assumptions based on what we can foresee about the use of SOME/IP in the automotive domain. Then, we identify the factors having an effect on the subscription latency, and, by sensitivity analysis, quantify their importance regarding the worst-case service subscription latency. The analysis and experiments in this study provide practical insights into how to best configure SOME/IP SD protocol.]]>
Scalable Service-Oriented Middleware on IP (SOME/IP) is a proposal aimed at providing service-oriented communication in vehicles. SOME/IP nodes are able to dynamically discover and subscribe to available services through the SOME/IP Service Discovery protocol (SOME/IP SD). In this context, a key performance criterion to achieve the required responsiveness is the subscription latency that is the time it takes for a client to subscribe to a service. In this paper we provide a recap of SOME/SD and list a number of assumptions based on what we can foresee about the use of SOME/IP in the automotive domain. Then, we identify the factors having an effect on the subscription latency, and, by sensitivity analysis, quantify their importance regarding the worst-case service subscription latency. The analysis and experiments in this study provide practical insights into how to best configure SOME/IP SD protocol.]]> Sat, 07 Jan 2017 10:47:13 GMT /slideshow/insights-on-the-configuration-and-performances-of-someip-service-discovery/70768362 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Insights on the Configuration and Performances of SOME/IP Service Discovery REALTIMEATWORK Scalable Service-Oriented Middleware on IP (SOME/IP) is a proposal aimed at providing service-oriented communication in vehicles. SOME/IP nodes are able to dynamically discover and subscribe to available services through the SOME/IP Service Discovery protocol (SOME/IP SD). In this context, a key performance criterion to achieve the required responsiveness is the subscription latency that is the time it takes for a client to subscribe to a service. In this paper we provide a recap of SOME/SD and list a number of assumptions based on what we can foresee about the use of SOME/IP in the automotive domain. Then, we identify the factors having an effect on the subscription latency, and, by sensitivity analysis, quantify their importance regarding the worst-case service subscription latency. The analysis and experiments in this study provide practical insights into how to best configure SOME/IP SD protocol. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/sae-someip-web-170107104713-thumbnail.jpg?width=120&height=120&fit=bounds" /> Scalable Service-Oriented Middleware on IP (SOME/IP) is a proposal aimed at providing service-oriented communication in vehicles. SOME/IP nodes are able to dynamically discover and subscribe to available services through the SOME/IP Service Discovery protocol (SOME/IP SD). In this context, a key performance criterion to achieve the required responsiveness is the subscription latency that is the time it takes for a client to subscribe to a service. In this paper we provide a recap of SOME/SD and list a number of assumptions based on what we can foresee about the use of SOME/IP in the automotive domain. Then, we identify the factors having an effect on the subscription latency, and, by sensitivity analysis, quantify their importance regarding the worst-case service subscription latency. The analysis and experiments in this study provide practical insights into how to best configure SOME/IP SD protocol.

Insights on the Configuration and Performances of SOME/IP Service Discovery from RealTime-at-Work (RTaW)

]]> 3345 5 https://cdn.slidesharecdn.com/ss_thumbnails/sae-someip-web-170107104713-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Timing verification of automotive communication architecture using quantile estimation /slideshow/timing-verification-of-automotive-communication-architecture-using-quantile-estimation/31540174 ertss2014-quantiles-140223112437-phpapp01
�ݺ�ߣs of a paper at ERTSS'2014 co-authored by Nicolas NAVET (University of Luxembourg), Shehnaz LOUVART (Renault), Jose VILLANUEVA (Renault), Sergio CAMPOY-MARTINEZ (Renault) and Jörn MIGGE (RealTime-at-Work). Early stage timing verification on CAN traditionally relies on simulation and schedulability analysis, also known as worst-case response time (WCRT) analysis. Despite recent progresses, the latter technique remains pessimistic especially in complex networking architectures with gateways and heterogeneous communication stacks. Indeed, there are practical cases where no exact WCRT analysis is available, and merely upper bounds on the response times can be derived, on the basis of which unnecessary conservative design choices may be made. Simulation, on the other hand, does not provide anyguarantees per se and, in the context of critical networks, should only be used along with an adequate methodology. In this paper, we argue for the use of quantiles of the response time distribution as performance metrics providing an adjustable trade-off between safety and resource usage optimization. We discuss how the exact value of the quantile to consider should be chosen with regard to the criticality of the frames, and illustrate the approach on two typical automotive use-cases. ]]>
�ݺ�ߣs of a paper at ERTSS'2014 co-authored by Nicolas NAVET (University of Luxembourg), Shehnaz LOUVART (Renault), Jose VILLANUEVA (Renault), Sergio CAMPOY-MARTINEZ (Renault) and Jörn MIGGE (RealTime-at-Work). Early stage timing verification on CAN traditionally relies on simulation and schedulability analysis, also known as worst-case response time (WCRT) analysis. Despite recent progresses, the latter technique remains pessimistic especially in complex networking architectures with gateways and heterogeneous communication stacks. Indeed, there are practical cases where no exact WCRT analysis is available, and merely upper bounds on the response times can be derived, on the basis of which unnecessary conservative design choices may be made. Simulation, on the other hand, does not provide anyguarantees per se and, in the context of critical networks, should only be used along with an adequate methodology. In this paper, we argue for the use of quantiles of the response time distribution as performance metrics providing an adjustable trade-off between safety and resource usage optimization. We discuss how the exact value of the quantile to consider should be chosen with regard to the criticality of the frames, and illustrate the approach on two typical automotive use-cases. ]]> Sun, 23 Feb 2014 11:24:37 GMT /slideshow/timing-verification-of-automotive-communication-architecture-using-quantile-estimation/31540174 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) Timing verification of automotive communication architecture using quantile estimation REALTIMEATWORK �ݺ�ߣs of a paper at ERTSS'2014 co-authored by Nicolas NAVET (University of Luxembourg), Shehnaz LOUVART (Renault), Jose VILLANUEVA (Renault), Sergio CAMPOY-MARTINEZ (Renault) and Jörn MIGGE (RealTime-at-Work). Early stage timing verification on CAN traditionally relies on simulation and schedulability analysis, also known as worst-case response time (WCRT) analysis. Despite recent progresses, the latter technique remains pessimistic especially in complex networking architectures with gateways and heterogeneous communication stacks. Indeed, there are practical cases where no exact WCRT analysis is available, and merely upper bounds on the response times can be derived, on the basis of which unnecessary conservative design choices may be made. Simulation, on the other hand, does not provide anyguarantees per se and, in the context of critical networks, should only be used along with an adequate methodology. In this paper, we argue for the use of quantiles of the response time distribution as performance metrics providing an adjustable trade-off between safety and resource usage optimization. We discuss how the exact value of the quantile to consider should be chosen with regard to the criticality of the frames, and illustrate the approach on two typical automotive use-cases. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ertss2014-quantiles-140223112437-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> �ݺ�ߣs of a paper at ERTSS'2014 co-authored by Nicolas NAVET (University of Luxembourg), Shehnaz LOUVART (Renault), Jose VILLANUEVA (Renault), Sergio CAMPOY-MARTINEZ (Renault) and Jörn MIGGE (RealTime-at-Work). Early stage timing verification on CAN traditionally relies on simulation and schedulability analysis, also known as worst-case response time (WCRT) analysis. Despite recent progresses, the latter technique remains pessimistic especially in complex networking architectures with gateways and heterogeneous communication stacks. Indeed, there are practical cases where no exact WCRT analysis is available, and merely upper bounds on the response times can be derived, on the basis of which unnecessary conservative design choices may be made. Simulation, on the other hand, does not provide anyguarantees per se and, in the context of critical networks, should only be used along with an adequate methodology. In this paper, we argue for the use of quantiles of the response time distribution as performance metrics providing an adjustable trade-off between safety and resource usage optimization. We discuss how the exact value of the quantile to consider should be chosen with regard to the criticality of the frames, and illustrate the approach on two typical automotive use-cases.

Timing verification of automotive communication architecture using quantile estimation from RealTime-at-Work (RTaW)

]]> 5684 5 https://cdn.slidesharecdn.com/ss_thumbnails/ertss2014-quantiles-140223112437-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 CAN in Automotive Applications: a Look Forward /slideshow/can-in-automotive-applications-a-look-forward/12151253 canconference2012color-120325152942-phpapp01
There is today more than 20 years of experience in automotive CAN applications, and CAN has certainly proven very successful as a robust, cost effective and all-around network technology. But the use of CAN in vehicles is evolving, in particular because of more complex and heterogeneous architectures with FlexRay or Ethernet networks, and because of recent needs like hybrid, electric propulsion or driver assistance that involves more stringent real-time constraints. Besides, there are other new requirements on CAN: more fine-grained ECU mode management for energy savings, multi-ECU splitted functions and huge software downloads. In parallel, safety issues request more and more mechanisms to protect against potential failures and provide end-to-end integrity. The development process is also evolving with the advent of multi-domain cooperation, Autosar, ISO2626-2 and the always shorter time-to-market requirements. In this landscape, CAN has now to be used at much higher bus load level than in the past, and there is less margin for error. What does it imply in terms of verification and validation? What are the characteristics of the communication stacks that should be paid attention to? This article is intended to shed some light and share our views on these issues.]]>
There is today more than 20 years of experience in automotive CAN applications, and CAN has certainly proven very successful as a robust, cost effective and all-around network technology. But the use of CAN in vehicles is evolving, in particular because of more complex and heterogeneous architectures with FlexRay or Ethernet networks, and because of recent needs like hybrid, electric propulsion or driver assistance that involves more stringent real-time constraints. Besides, there are other new requirements on CAN: more fine-grained ECU mode management for energy savings, multi-ECU splitted functions and huge software downloads. In parallel, safety issues request more and more mechanisms to protect against potential failures and provide end-to-end integrity. The development process is also evolving with the advent of multi-domain cooperation, Autosar, ISO2626-2 and the always shorter time-to-market requirements. In this landscape, CAN has now to be used at much higher bus load level than in the past, and there is less margin for error. What does it imply in terms of verification and validation? What are the characteristics of the communication stacks that should be paid attention to? This article is intended to shed some light and share our views on these issues.]]> Sun, 25 Mar 2012 15:29:41 GMT /slideshow/can-in-automotive-applications-a-look-forward/12151253 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) CAN in Automotive Applications: a Look Forward REALTIMEATWORK There is today more than 20 years of experience in automotive CAN applications, and CAN has certainly proven very successful as a robust, cost effective and all-around network technology. But the use of CAN in vehicles is evolving, in particular because of more complex and heterogeneous architectures with FlexRay or Ethernet networks, and because of recent needs like hybrid, electric propulsion or driver assistance that involves more stringent real-time constraints. Besides, there are other new requirements on CAN: more fine-grained ECU mode management for energy savings, multi-ECU splitted functions and huge software downloads. In parallel, safety issues request more and more mechanisms to protect against potential failures and provide end-to-end integrity. The development process is also evolving with the advent of multi-domain cooperation, Autosar, ISO2626-2 and the always shorter time-to-market requirements. In this landscape, CAN has now to be used at much higher bus load level than in the past, and there is less margin for error. What does it imply in terms of verification and validation? What are the characteristics of the communication stacks that should be paid attention to? This article is intended to shed some light and share our views on these issues. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/canconference2012color-120325152942-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> There is today more than 20 years of experience in automotive CAN applications, and CAN has certainly proven very successful as a robust, cost effective and all-around network technology. But the use of CAN in vehicles is evolving, in particular because of more complex and heterogeneous architectures with FlexRay or Ethernet networks, and because of recent needs like hybrid, electric propulsion or driver assistance that involves more stringent real-time constraints. Besides, there are other new requirements on CAN: more fine-grained ECU mode management for energy savings, multi-ECU splitted functions and huge software downloads. In parallel, safety issues request more and more mechanisms to protect against potential failures and provide end-to-end integrity. The development process is also evolving with the advent of multi-domain cooperation, Autosar, ISO2626-2 and the always shorter time-to-market requirements. In this landscape, CAN has now to be used at much higher bus load level than in the past, and there is less margin for error. What does it imply in terms of verification and validation? What are the characteristics of the communication stacks that should be paid attention to? This article is intended to shed some light and share our views on these issues.

CAN in Automotive Applications: a Look Forward from RealTime-at-Work (RTaW)

]]> 7259 4 https://cdn.slidesharecdn.com/ss_thumbnails/canconference2012color-120325152942-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation White http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 PEGASE – a robust and efficient tool for worst-case network traversal time evaluation on AFDX /slideshow/pegase-a-robust-and-efficient-tool-for-worstcase-network-traversal-time-evaluation-on-afdx/9994721 slidespegasesaeaerotech-111102115021-phpapp01
]]>
]]> Wed, 02 Nov 2011 11:50:18 GMT /slideshow/pegase-a-robust-and-efficient-tool-for-worstcase-network-traversal-time-evaluation-on-afdx/9994721 REALTIMEATWORK@slideshare.net(REALTIMEATWORK) PEGASE – a robust and efficient tool for worst-case network traversal time evaluation on AFDX REALTIMEATWORK <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/slidespegasesaeaerotech-111102115021-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" />

PEGASE – a robust and efficient tool for worst-case network traversal time evaluation on AFDX from RealTime-at-Work (RTaW)

]]> 7525 3 https://cdn.slidesharecdn.com/ss_thumbnails/slidespegasesaeaerotech-111102115021-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-REALTIMEATWORK-48x48.jpg?cb=1727774996 Mission — today’s technologies allow for better ways to develop critical embedded systems through timing-accurate simulation, design space exploration on virtual platforms and generative design – our commitment to you is to bring you top-level design tools that drastically reduce time-to-market and costs by automation and ressource usage optimization. Industry — Customers of RTaW include OEMs such as Mercedes, FCA, Renault, PSA, Airbus companies, ArianeGroup, Thales, CNES, ABB, Huawei, tier-one suppliers as R. Bosch and Aptiv. Our ability to produce highly applicable solutions is proven by our success in helping our clients design automotive, aerospace and industrial systems. www.realtimeatwork.com https://cdn.slidesharecdn.com/ss_thumbnails/shapingbmwrtawtsna-241001093015-0c58d1fc-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/automotive-system-requirements-on-traffic-shaping/272123681 AUTOMOTIVE SYSTEM REQU... https://cdn.slidesharecdn.com/ss_thumbnails/tsn2023-atsvscbsethernoviartaw-231105075509-76233b47-thumbnail.jpg?width=320&height=320&fit=bounds REALTIMEATWORK/what-are-the-relevant-differences-between-asynchronous-ats-and-credit-based-cbs-shaper What are the relevant ... https://cdn.slidesharecdn.com/ss_thumbnails/tsn-qos-what-did-we-learn2023-231105074849-26f7ad34-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/tsn-timing-qos-mechanisms-what-did-we-learn-over-the-past-10-years/263057962 TSN Timing QoS Mechani...