@All: Ethernet with right services can support design of highly integrated systems and generic architectures, supporting hard RT, RT and soft-time functions. It is about Ethernet as an synchronous/asynchronous backbone (i.e. deterministic unified Ethernet) using completely open standards, integrated on an Ethernet switch chip.
Critical functions cannot be affected by traffic flooding, and their communication is absolutely congestion-free. You can compare it to FlexRay-like behavior in an Ethernet network, but @ Ethernet aggregate bandwidth (100MBit/s or higher). The Ethernet bandwidth not used for vehicle-critical functions can be used for all other diagnose and multimedia functions (or something else).
@Bert22306 You are right about - Real world experience brings confidence, In integrated systems there is another important reason why the determinism of communication is required. You want to virtualize a generic embedded system so that critical and non-critical functions share common resources (IO, CPU, ..,) and execute smoothly without interferences. It is a different challenge in comparison to design of simple distributed controls, and cannot be done easily just by statistical multiplexing and overprovisioning.
And finally if you get absolute guarantees for deterministic communication for free at zero effort, why spending many Person-Years (PYs) to get it right on your own for every new project?
@All Join "Deterministic Ethernet Group" @ LinkedIn to learn more about what is Ethernet, what it can be, and what is required to build advanced integrated systems with Ethernet.
I agree with @Bert22306. Most of the features which go into the design considerations regarding the speed, the redundancy, the error correction methodologies and so on are underutlised in the final products or may not even get implemented in the products.
@Rick, I wouldn't describe as such that NXP is taking a different route. NXP is one of the early supporters of Open Alliance Sig (http://www.opensig.org/), originally started by Broadcom, and NXP's solution is compliant to BroadR-Reach spec. It's just that NXP is getting help from TTTech, a developer of Ethernet IPs, for this particular automotive Ethernet IP.
My observation in this field is that initially, many people have a gut reaction that you "must have determinism," for control system message traffic. So they insist on adding bells and whistles to supposedly achieve this determinism, even though the mechanisms may not work as they imagined. An example of this might be the old FDDI "synchronous mode," which ultimately did not guarantee anything from the actual client system's point of view, and I doubt it was ever put to effective use.
Real world experience brings confidence, however. You design the control algorithms intelligently, adequately over-provision the network, test it out, and eventually forget about those early obsessions about "determinism."
As I understand FlexRay has its own advantages over Ethernet to have its place in automotive functional applications excepts its speed not more than 10Mbits/s. If we talk about connecting in-car "info media" devices using a Ethernet backbone, Ethernet makes sense because of the speed, For connecting automotive control devices Ethernet needs to have some extension which would be certified per ISO26262, isn't it? Also security is another aspect when everything will eventually get connected to outside world.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.