How to design with extensibility in mind?

A main issue in the design of E/E architectures is that the most important design choices pertaining to the topology and the technologies (i.e., processors, protocols, data rate, hardware) have to be made at a time when the workload, in terms of tasks and communication needs, and associated requirements (performance, safety, security, energy consumption, etc) are not entirely known.

It has been the case for years as much of the software become available later in the development process, and as new variants of a platform are progressively introduced during its lifetime. But in today’s vehicles (and probably in aircrafts too in the future), software will be much more frequently and importantly updated, to an extent that has not been seen before, with a plethora of new services being deployed aftermarket. The business model of OEMs will increasingly be depending on their technical capability to deploy new functions on an existing E/E architecture. For that reason, E/E architecture, and specifically communication architectures, the focus of this post, must now be as “future-proof” as possible.

The Service Oriented Architecture paradigm, whose implementation is made possible in the automotive domain by the Some/IP protocol or DDS, brings a lot of flexibility in software update implementation and associated business model. Probably OEMs will try to remain the single entry point for new services (see [1]), even if those services have been developed and are operated by third-parties. However,  for the less critical services, e.g. related to infotainment, and given the weight of players like Google with their Android Auto and cloud infrastructure, it is very possible that other solutions are implemented.

Enveloppes, virtual functions and sensitivity analysis

Now, how to make sound design decisions with an imperfect knowledge of the applications the E/E will have to support? Here are some approaches which have been used in the past:

  • Considering an “enveloppe” of all possible needs, typically considering a car with all options that are offered to the customers (even if some options are incompatible). It used to work fine but it is not suited to today’s context where all options / services are not known at design time,
  • Considering “virtual” functions, messages or ECUs: the design is conducted provisioning for some functions / messages / ECUs which are not present yet but will be introduced during the  lifetime of the architecture. It is well suited when we know that the E/E architecture will have to support several successive evolutions of a platform (e.g., phase I, phase II) and when the roadmap in terms of new functions / innovation is reasonably well known,
  • Sensitivity analysis: the idea is to progressively increase the load on a network or on a processor, and to identify the threshold at which performance constraints start being violated.  For instance, considering today’s CAN bus with a load of 55%, assuming the traffic characteristics will remain unchanged in the future, how far can it go? is it 70 or 90%? This approach, though coarse grained, is still useful to get an estimate of the extent to which a resource will be able to cope with an increased workload, and to identify “bottleneck resources”. An implementation of this approach is available as the ScaleLoad function for CAN (FD) buses in RTaW-Pegase.

Topology Stress Test: design-space exploration on synthetic yet realistic networks

Developing the technologies to secure and optimize early stage design decisions is our focus at Cognifyer, and we have been exploring other approaches, more automated and more fine-grained in terms of the information they provide to the designers. A technology available in the generative-design module of RTaW-Pegase is the Topology-Stress-Test (TST) function for Ethernet TSN. What TST does is measure the “total capacity” of a network configuration in terms of the number of streams it can support. This is performed by Monte-Carlo simulations conducted on synthetic networks of increasing loads. The capacity is expressed in probabilistic terms, e.g. “the network capacity is 200 flows at the 99% safety level” means that in 99 cases out of 100, the architecture will be able in the future to meet the performance requirements of 200 flows. The capacity of an Ethernet TSN network depends on the layout of the network, the data rates, the hardware performance, but also on the set of protocols used: priorities, frame preemption (802.1Qbu), time-triggered communication (IEEE802.1Qbv), Credit-Based-Shaping (IEEE802.1Qav), etc. TST provides the capacity for each design variants selected and each safety level selected, generating visual and textual abacuses that the designers can use to support their actual design choices.

The results of TST are valid as long as the assumptions on the communication needs are realistic. The synthetic networks are random, yet they should be created with all the knowledge the designers possesses. Capturing this knowledge is done with different input templates, chosen based on the level of knowledge the designer has on the streams and the allocations of functions. In practice, the characteristics of streams (audio, video, control, etc) tend to be well known but their proportion is often more unsure. That is why a wide range of “possible futures” is explored by TST, typically several hundred of thousands of network configurations are analyzed during a TST run.

TST was first field-tested for Renault Group’s FACE SOA E/E architecture. We showed that, in the specific context of FACE, adding a single 100Mbit/s link allows to increase by 54% the number of Some/Ip services that the architecture successfully supports, reaching 670 services at the 90% safety level with the Credit-Based-Shaping. Further details in the slides of this joint work with Renault Group presented at the 2019 IEEE Standards Association (IEEE-SA) Ethernet & IP @ Automotive Technology Day, Detroit, Mi, September 23-25, 2019 – download presentation slides here.

Beyond bottleneck identification, proposing solutions

TST serves as a basis for a set of higher level generative-design functions currently under development at Cognifyer or already being tested. One such function is “Topology Optimizer”, which goes beyond identifying bottlenecks by proposing local/incremental improvements that make a difference in terms of the network capacity, that is ultimately in terms of how long an E/E architecture will remain operational. Topology Optimizer not only propose solutions to increase the capacity of an architecture, it also provide solutions to cost-optimize the architecture: link speed reduction (1Gbit/s to 100Mbit/s) wherever, and removing ECUs by relocating their functions into other ECUs. Another dimension addressed by Topology Optimizer is reliability, based on fault-injection evaluation it applies “patterns of dependability” to the architecture: frame replication, link redundancy, etc.  The use of Topology Optimizer to progressively cost-, capacity- and safety-optimize a next-generation zone-based architecture was presented in a joint work with Volvo Cars at the Automotive Ethernet Congress, 12-13 February 2020@Westin Grand Munich. – download presentation slides here.

Interested to know more? You are welcome to contact us.

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