How to design with extensibility in mind?

One of the major challenges in designing E/E (Electrical/Electronic) architectures is that critical decisions regarding topology and technology choices—such as processors, protocols, data rates, and hardware—must be made at a point when the workload (in terms of tasks and communication needs) and associated requirements (e.g., performance, safety, security, energy consumption) are not yet fully defined.

This has been an ongoing issue for years, as much of the software becomes available later in the development process, and new platform variants are introduced progressively throughout a product’s lifecycle. However, today’s vehicles (and likely aircrafts in the near future) will see much more frequent and significant software updates, with a wide range of new services being deployed post-production. OEMs’ business models are increasingly reliant on their ability to deploy new functionalities on existing E/E architectures. Therefore, it’s essential that these architectures, particularly communication architectures, are as “future-proof” as possible.

The Service-Oriented Architecture (SOA) paradigm, enabled in the automotive domain by protocols like Some/IP or DDS, provides a great deal of flexibility for software updates and associated business models. OEMs will likely aim to remain the central gateway for new services (see [1]), even when those services are developed and operated by third parties. However, for less critical services—such as those related to infotainment—it is quite possible that alternative solutions will emerge, especially with the involvement of major players like Google and their Android Auto and cloud infrastructure.

Approaches for Designing with Limited Knowledge of Future Requirements

Given the challenge of designing an E/E architecture without full knowledge of future applications and requirements, several strategies have been employed in the past:

  1. Envelope-Based Design: This approach involves designing for a “worst-case scenario,” or an envelope of all possible needs, such as a vehicle equipped with every available option (even if some options are incompatible with each other). While this method worked in the past, it is no longer sufficient in today’s environment, where not all options or services are known at design time.
  2. Virtual Functions, Messages, or ECUs: This strategy provisions for virtual functions, messages, or ECUs that are not yet present but are expected to be introduced later during the architecture’s lifetime. It works well when it’s known that the E/E architecture will support multiple phases of a platform (e.g., Phase I, Phase II) and when the roadmap for new functions and innovations is sufficiently well known.
  3. Sensitivity Analysis: In this approach, the load on a network or processor is gradually increased to identify the point at which performance constraints begin to break down. For example, consider a CAN bus currently operating at 55% load. Assuming traffic characteristics remain constant in the future, the question becomes: how much additional load can the system handle? Will it max out at 70% or 90%? While this approach is somewhat coarse, it can still provide valuable insights into how far a resource can handle increased workloads and help identify potential bottlenecks. An example of this approach in action is the ScaleLoad function available for CAN (FD, XL) and Ethernet networks in RTaW-Pegase.

Topology Stress Test: Design-Space Exploration on Synthetic Yet Realistic Networks

At Cognifyer, our focus is on making informed early-stage design decisions possible despite imperfect knowledge. To tackle this, we have been exploring more automated and fine-grained approaches that provide further valuable insights for designers. One such tool is the Topology Stress Test (TST) function available in the Generative Design module of RTaW-Pegase, specifically for Ethernet TSN networks.

TST evaluates the “total capacity” of a network configuration by determining how many streams it can support. This is done using Monte Carlo simulations on synthetic networks under increasing loads. The result is expressed probabilistically; for example, a result like “the network capacity is 200 flows at the 99% safety level” means that in 99 out of 100 cases, the architecture will meet performance requirements for 200 flows. The capacity of an Ethernet TSN network is influenced by various factors such as network topology, data rates, hardware performance, and QoS protocol choices, including priorities, frame preemption (802.1Qbu), time-triggered communication (IEEE 802.1Qbv), Credit-Based Shaper (IEEE 802.1Qav) and the more recent and powerful Asynchronous Traffic Shaper (IEEE 802.1Qcr). TST provides capacity estimates for each design variant and safety level, producing both visual and textual outputs (“abacuses”) that help designers make informed decisions.

The validity of TST results depends on the realism of the assumptions about communication needs. While the synthetic networks are random, they should be built using all the knowledge available to the designer. This knowledge is captured through different input templates, chosen based on how much the designer knows about streams and function allocations. In practice, while the characteristics of streams (e.g., audio, video, control) are typically well understood, their exact proportions can be uncertain. To account for this, TST considers a wide range of “possible futures,” often analyzing several hundred thousand network configurations during a single run.

TST was first field-tested with Renault Group’s FACE SOA E/E architecture. In this context, we demonstrated that adding just one 100Mbit/s link increased the architecture’s capacity to support Some/IP services by 54%, allowing it to handle 670 services at a 90% safety level with Credit-Based Shaping. For further details, you can consult the slides from this joint work with Renault Group, which were presented at the 2019 IEEE Standards Association (IEEE-SA) Ethernet & IP @ Automotive Technology Day in Detroit, MI, from September 23-25, 2019. [Download presentation slides here].

In a subsequent joint project with BMW, presented at the Ethernet & IP @ Automotive Technology Day 2020, we applied TST to explore the potential of algorithmic tools to synthesize Ethernet-based architectures. These architectures were based on a minimal, fixed-core Ethernet TSN topology, with design goals and constraints informed by next-generation applications and data from past projects, reflecting OEM domain knowledge. The figure below illustrates Pareto-optimal cost/extensibility trade-offs for different candidate E/E architecture solutions. [Download presentation slides here].

Since then, TST has been adopted by over 25 OEMs globally as a plugin for RTaW-Pegase. It has proven to be an invaluable tool for exploring network design options, enabling automotive designers to make more informed decisions in crafting robust, future-proof E/E architectures.

TST has also seen successful applications in the aerospace industry. For example, a study conducted with Airbus Helicopters, presented at DACS2021 (download paper, download presentation slides here), explored the use of TST to assess the evolutivity of a next-generation avionics helicopter network equipped with various TSN mechanisms. The study concluded that, for the specific avionics systems under analysis, advanced TSN mechanisms may not be necessary for future communication architectures.

Moving Beyond Bottleneck Identification: Proposing Solutions

TST serves as a foundation for higher-level generative-design functions developed at Cognifyer. One such function, “Topology Optimizer,” goes beyond merely identifying bottlenecks by offering local or incremental improvements that can significantly increase network capacity and, in turn, extend the operational lifespan of an E/E architecture.

Topology Optimizer not only suggests ways to enhance the capacity of an architecture but also provides cost-optimization solutions. These include reducing link speeds (e.g., from 1Gbit/s to 100Mbit/s) where feasible, and removing unnecessary ECUs by consolidating their functions into other ECUs. Additionally, Topology Optimizer addresses reliability by applying “patterns of dependability” based on fault-injection evaluations. This includes features such as frame replication and link redundancy to enhance safety and robustness.

An example of how Topology Optimizer can progressively optimize cost, capacity, and safety in a next-generation zone-based architecture was showcased in a joint presentation with Volvo Cars at the Automotive Ethernet Congress, held on February 12-13, 2020, at the Westin Grand Munich (download presentation slides here).

Interested in learning more? You are most welcome to contact us.

[1] Matthias Traub (BMW), “High-Performance Computing Architectures for Automotive”, Global Semiconductor Alliance Executive Forum 2019, Munich.