This is almost a philosophical or emotional question. Industries which have historically depended on strictly synchronized techniques, and this includes the telephone industry, and automotive too, have a difficult time accepting that the speed advantages of non-synchronous techniques can overcome any supposed need for strict timing. That's why CAN and FlexRay are in the past, and Internet Protocol and Ethernet seem to be where everything has been heading.

The way synchronization is managed, with asynchronous IP/Ethernet, is to provide a central time source, see for example NTP, RFC 5905, and then transmit an NTP time stamp, or similar time stamp, with the data packets. Also, Real Time Protocol, RFC 3550, will show you how one can actually run synchronous streams on an unsynchronized IP/Ethernet infrastructure.

If the network infrastructure is much faster than the speed requirements of the most time-critical applications riding on the network, and the network infrastructure is not heavily loaded, nothing more sophisticated will be required of the network. In short, it is cheaper and more practical to build in plenty of excess bandwidth in the network than it is to attempt to strictly synchronize the network. It's a lesson from the days when the telecom industry was backing schemes like Asynchronous Transfer Mode (ATM), in favor of IP and Ethernet, or other strictly unsynchronized and purely packet-switched schemes. In fact, for many years, people have also advanced ideas to create some synchronism in Ethernet, but never with any measure of great success or widespread use, as far as I can tell.

A practical approach to your automobile network design might be to provide separate networks, for infotainment and for critical control systems. And then if they need to be tied together, use firewall/gateways that strictly filter, and limit, the packets that can go between these networks. The idea would be to keep the critical network(s) lightly loaded, at all times. Meaning, just throw cheap bandwidth at those networks, and don't worry that the bandwidth is not "fully utilized." You can even do some statistical analysis on the probability of queues forming at network nodes, and on the time to process these queues.

Chances are, your critical controls IP packets will be short. But take a worst-case 1500 byte Ethernet payload, on a 100 Mb/s Ethernet. If that packet were to be delayed by one other similar max-size packet, in a queue, we're only talking about 123 microseconds of delay. The probability of any amount of queue forming is going to be low, in a lightly loaded network, and the probability of more than one packet being in any queue will drop quickly. Use 1 Gb/s Ethernet, instead of 100 Mb/s, and now that max size IP over Ethernet packet would be delayed only 12.3 microseconds, worst case, if another packet was right in front.

Then, on top of that, you can look at IEEE 802.1Q "tagged frames," to give the really critical communications priority over the others.

As to cyber security, once you have adopted IP and Ethernet for your infrastructure, now you have at your disposal plenty of research and plenty of cyber solutions, all the way from layer 1 techniques, to layer 2 MACsec, layer 3 IPsec, and layer 4 TLS.

Here's a short paper discussing security issues related to this topic: https://www.ics.uci.edu/~gts/paps/attestation-ESCAR15.pdf

Albert Manfredi : Really helpful. Several questions answered. Thanks!

I want specific claarification on how can we reduce latency and jitter to negligible.

In case of centralized gateway, CAN, Flexray and Ethernet communication can be established. For Ethernet, TSN is applied but still we find latency and jitter to measurable level. What should be considered to reduce it to the minimum?

Jai, check out how streaming protocols manage jitter. The short answer is, they send a timestamp with each data packet, they buffer a few of these data packets in each receiver, and then they decode the packets at the required time intervals. Jitter becomes a non-issue, because your strict inter-packet timing is now managed only at the receive end.

As to latency, again, if the network is fast enough, latency won't be an issue. More likely, it is the buffering requirement which creates some extra latency.

So, you have to see what actually matters. For example, when voice over IP started, people were worried about the same things. How do we manage jitter and latency, without that strictly synchronous, traditional telephone infrastructure? Well, measurements showed that in a telephone conversation, latency could cause problems, but only beyond a certain value. I don't remember exactly what that value is right now, but it was something on the order of 150 msec. Anything beyond that becomes noticeable. Which meant that it is usually possible to buffer a few short voice packets at the receiver, each one time stamped, and then feed them to the decoder at the receive end, on schedule.

Of course, the digital network between source and sink has to be very fast, so the voice packets can be delivered quickly. But with this kind of design, you don't need the much more complicated cell interleaving schemes, such as those used when sending ATM over SONET/STM. In short, figure out ways where you do not need the extremely low jitter in the network itself.

Take the case of a network that can send 1 Mb/s streams with very low jitter, because the network interleaves different streams and uses synchronous clocking. To send 1500 byte packets, from source to destination, will result in at least 12 msec of latency, due to the 1 Mb/s speed of each individual stream, and very low jitter inherent in that synchronous clocking.

Now instead, use a cheaper, unsynchronized, 1 Gb/s network, such as Gigabit Ethernet, and send time stamps with every 1500 byte packet. The packets are delivered with only 12 microseconds of latency! Much less than the previous fancy network. So you can easily afford to buffer many packets at the destination side, and send them to the user at precisely the right schedule, determined by the time stamp. You can end up with a cheaper network, and yet achieve low latency and low jitter.