E/E architecture enabling technologies

By Brendan Morris

Picking up my series about E/E architectures I thought it worth completing the promised detour a little deeper into some of the enabling technologies that have allowed what has come so far, and enable the current trends. I covered a little about each of these topics as we’ve worked through the series, including usually focusing on the why, but I wanted to dig into a little more detail about the what of the technologies and again provide more links for further understanding. A couple of these maybe quite old now, or seem so, but through either their proven nature, continued investment in relevant capabilities, or both, continue to be of use in most new E/E architectures.

CAN bus

I discussed some aspects of CAN bus in the my history of E/E architecture blog previously, I don’t want to repeat what’s there but it’s worth expanding on what came before, not so much the network technologies, but the lack of standardization, and what that meant. I covered a bit about the technologies in that blog, and before, but I was not aiming for this series to be technical deep dive, more about why and how these technologies have enabled change, I aim to link to deeper technical sources for those who want to understand more.

Before CAN bus there were many network technologies, in many cases OEM’s had their own proprietary technology, which mattered somewhat less in a world where many OEM’s designed and manufactured their own ECU’s. This vertically integrated world didn’t last long however, and was never universal, so standardizing on a common network technology made sense, the economies of scale at the silicon level could be substantial, if the Tier 1 suppliers could even supply the same basic ECU to several OEM’s this increased, common silicon, PCB, enclosure, limiting changes to minor components populated on the PCB, and software applications.

Modern vehicles are designed around a collection of standards, for a long time operating at a nominal 12v, and now with increasing use of 48v components, the traditional (non-smart) fuses are to a common standard, through to wheels and tires with their curious mix of millimeters and inches in their size definition. As a note, metric tires of a few types were a thing, but this signified different shape mounting of tire to wheel, such as Michelin TRX, with the differing wheel sizes used to avoid fitment of incorrect tire to wheel.

The combination of ECU’s running on a 12v supply, connected by CAN has been so successful that the same basic recipe has lasted from introduction in the 1980’s through to the 2020’s when CAN bus data rate has become a challenge for many functions. Other network technologies have come along, few have anything like the popularity of CAN bus, hence the introduction of CAN FD with a simplified upgrade path, albeit not total compatibility.

AUTOSAR

I’ve also gone deeper into the history of AUTOSAR before, but it’s worth revisiting the effects it has had, somewhat similar to CAN bus allowing for some more economies of scale in the basics of the modern vehicle. AUTOSAR Classic Platform continues to have use cases in the latest E/E architectures, built on significant version releases such as R20-11 and the next milestone, of which more to come soon in a future blog.

The AUTOSAR consortium collaborates with multiple standards bodies to ensure interoperability, and avoid duplication of capability where it need not exist, developing not just a standard for the software, but also those needed for development, enabling interoperability between tools used in development. Further discussion of the SDV Alliance and AUTOSAR collaborations can be found in recordings from the 15th AUTOSAR Open Conference.

Heterogeneous Silicon

Automotive ECU’s have a long history of using proven micro-controller families, hardened to the Automotive environment, suitable for traditional embedded software, offering Real Time controls to function. There have been use cases that need more compute and less strict Real Time processing for some time, Infotainment being the most prominent, bringing more powerful micro-processors into the Automotive industry. However these ECU’s still need to interact with traditional ECU’s and increasing functionality means that compute power needs to be added to more ECU’s, in parallel the silicon vendors have become much more interested in supplying Automotive with advanced silicon, suitably developed for the Automotive environment.

Heterogeneous software stack with AUTOSAR

Now there are an increasing range of heterogenous silicon offerings in market, which combine micro-controller and micro-processor compute on the same silicon, which support the concentration, or centralization of the compute into fewer more powerful ECU’s. Where as in times past the Tier 1 would have the main relationship with the silicon vendors, with the OEM often having limited influence, it has become normal for the OEM and silicon vendors to work closely together, some OEM’s even designing their own silicon for certain purposes, leveraging the availability of Fab’s, ability to license standard design elements, and modern tools.

Automotive Ethernet

The first applications of Ethernet to Automotive were to solve specific use cases, as a main diagnostic connection to accelerate software download in production, now standardized into SAE J1962 diagnostics connection, and related to Infotainment, which led to the adoption of AVB (Audio Visual Bridging) and adaption for Automotive requirements, when combined with other high integrity use cases this bought us TSN (Time Sensitive Networking) developed witin the IEEE 802.1 Working Group. For much more detail on Automotive Ethernet, the history of Automotive Networking, and the history of Ethernet I can recommend a pair of books, most recent editions linked at the end of this section, usually available from the usual variety of sources.

Excepting the diagnostic connection, ethernet onboard cars is almost always Automotive Ethernet, with its physical layer cost and mass optimizations, however, the software layers are or are compatible with standard ethernet software layers, allowing adoption of decades of IT development. AUTOSAR supports Ethernet and includes the protocols and technologies the industry needs, such as SOME/IP (Scalable service-Oriented MiddlewarE over IP) and DDS (Data Distribution Service standardized by the OMG) to handle data in approaches towards or achieving Service Orientation, enabling a move away from pre-designed communication schedules in some cases.

Book links:

Other steps along the way

CAN bus has continued to evolve with CAN FD in common usage, and CAN XL being standardized to compete with 10Base-T1S automotive ethernet, which also now has multiple standardized versions for different data rates and topologies. AUTOSAR has also continued to evolve, increasingly with collaborations to support software factories for Software Defined Vehicles (SDVs), enabling AUTOSAR to be part of heterogenous software stacks and support new use cases.

However along the way other technologies have been introduced, such as FlexRay which found use in many OEM’s in a range of chassis domain, powertrain domain and occasionally as a backbone network, but is now slowly fading away as automotive ethernet supports the use cases it was introduced to support, with the data rate surpassed, and the high integrity features designed to support safety related functions now supported, largely through adding technologies from the TSN (Time Sensitive Networking) toolbox to automotive ethernet. MOST bus, and many others have come along to support specific domains or use cases, and the industry has learnt from each of these steps.

Summary

Software Defined Vehicles have been enabled by several technologies, some new to automotive, some which have been around longer but which still function, through updates or well understood use-cases. A physical layer built of modern silicon and Automotive Ethernet still commonly includes CANbus, and very likely AUTOSAR Classic Platform delivering some of its core automotive functionality, but the real changes are now in the software development flow’s and Software Factories, but that’s another story, part of which is here.

If you want to learn more now, the following reading and watching are a good place to start.

On-demand webinar: Master the design challenges of automotive Ethernet communication
Blog: 3 Questions on Capital Embedded AR Classic
E-Book: Multi-domain challenges in the automotive, aerospace, and heavy equipment industries
Whitepaper: Master the challenges of software-defined vehicles with a unified development flow