By Bob Chabot, Contributing Editor

The Bus is Full

Ethernet-based OBD communication architecture will be a game-changer

This article is based on information gethered from presentations given at this year's SAE OBD II Symposium.

On-board diagnostics (OBD) is on the cusp of major architectural change. The sheer volume and complexity of data being communicated is one key driver. Moving that data faster is another. As a result, the limited data transfer speed and bandwidth of controller area network (CAN) architecture could be overwhelmed in just a few years. Internet Protocol based replacements are now under development, most notably Ethernet. When implemented, scan tool manufacturers and service/repair facilities will be impacted.

The regulation of emissions, vehicle complexity, functionality, telematics, safety and worldwide harmonization are just some of the factors causing a surge in the amount and nature of data that is communicated. Not only is the volume of data going vertical, it is also becoming richer in nature. It’s also important to note that OBD is not limited to emissions only. Telematics, in-vehicle multimedia content, performance upgrades, emerging complex safety systems and other applications are driving OBD into nonemission areas, a field known as enhanced OBD.

There’s an app for that!
Telematics is like a giant elephant in the room that many are trying to ignore. Besides the lack of common standards, like many aspects of the automotive industry, the rise and scope of telematics is accelerating and fragmented – many manufacturers, providers and products with stand-alone solutions that have little compatibility between them. Current applications span vehicle OBD, service and repair information, navigation, logistics management, safety systems, music, video, Internet, emergency applications and more.

For an example of the fragmentation, consider these two divergent paths. Ford has announced they are developing an application program interface (API) that will allow developers to create applications for smart devices that can be controlled through its Sync system’s voice and steering wheel controls. Continental’s AutoLinQ plans to distribute a open-source operating system software development kit (SDK) that will allow developers to create automotive specific applications for android-based platforms only.

But here’s the rub. Ford’s approach is more universal, as it will enable developers to interact with the vehicle from multiple smart device platforms regardless of operating system; the Continental approach, while not as universal, potentially provides better integration between the vehicle and the apps. Why not combine the best of both approaches, if proprietary safeguards could be assured?

Research firms say that telematics is still in its infancy and that the automotive telematics market is poised to get even more crowded. For instance, Frost & Sullivan expects the telematics market to grow from $80 million annually in 2008 to over $700 million by 2015. Another consultant, ABI Research, projects that the 37 million telematics users in 2010 will climb to over 211 million by 2015. In addition, the nature of telematic content is broadening and getting richer. Moving that data requires increasing bandwidth.

Moving towards a common, compatible solution
For automakers, suppliers, toolmakers, service professionals and motorists, this staggering growth rate has pace and cost implications. The need for a single, open and compatible telematics platform, rather than multiple stand-alone systems, is clear. Fortunately, it may even be possible, as open-standard telematics platforms, such as the Next Generation Telematics Protocol (NGTP, developed by BMW Group, WirelessCar  and Connexis), Openmatics (developed by ZF Friedrichshafen AG  and Intel Corp.) and others gain momentum.

“The end-user wants a single solution” claims Thomas Rösch, director of ZF’s Openmatics business unit, which is set to begin operation in January 2011. “Openmatics provides the means to integrate multiple telematics stand-alone applications. It will turn competitors into partners. The idea is to develop and offer Openmatics apps for OBD and the delivery of other telematic products and services.” He adds that the concept is similar in nature to how apps are developed by many providers and then delivered universally to personal devices (e.g. smartphones, tablets, in-vehicle systems, etc.).

Vehicles would have a single ‘on-board unit’ (OBU) and a software platform, which will cover all telematics services and products. Using APIs and SDKs to protect their competitive advantage, Rösch  says providers can freely develop their own apps, which can be deployed universally to any smart user device, and they can set their own prices. Data security and separation are a top priority: App providers will be able to define user-groups and determine the level of access within the app. Openmatics also takes care of payment processing between users and providers, as well as any further handling of the app.

Consider the potential, positive impacts on the automotive industry.

• The solution lowers costs, as it significantly reduces the redundancy of multiple telematics systems hardware installed into vehicles.
• It also opens doors to new industry initiatives. Need an automaker’s service information? Tooling?  OBD reflashing?  Imagine if there was an app for that!
• For automakers that currently employ their own self-determined structure and system requirements allowing technicians to access service information, an app-based delivery has huge potential. Basic, as well as security- or theft-related, service information could be delivered by an app, with the level of access tiered and determined via vetted bonafides.
• For tool manufacturers, the possibility that scan and other electronic tools could be like smartphones — with automaker-specific tooling information and feature sets delivered and activated via apps — is also attractive.For service professionals, being able to use a ‘smart tool’ capable of downloading vehicle-based apps would improve productivity and help maintain competencies.

CAN is becoming a bottleneck
CAN is becoming increasingly problematic and limiting. “On all 2008 and newer model year automobiles CAN is the only allowed protocol for legislated diagnostics says Christof Saalfeld, manager for Advanced Engineering Vehicle Diagnostics at Daimler AG. “Today, however, CAN is a data link layer that may not be the best for us.”

CAN’s lower data transfer speeds and smaller bandwidth results in a communications pipeline that is too constricted to manage the complexity, high volume and rich nature of data today. For instance, CAN transfer speeds are typically between 125,000 and 500,000 bits/second; in contrast, Flexray offers 10 million bits/second, Media Orientated Systems Transfer (MOST) typically offers 50 and 75 million bits/second, while Ethernet delivers 100 million bits/second or more. Factor in the bandwidth attribute for each, and CAN is once again dwarfed by Flexray and MOST, which in turn, have narrower bandwidth than Ethernet.

Functionality and interdependence continues to ramp up as modern vehicles feature an evolving mix of automotive systems, consumer infotainment and comfort systems. In addition, these emerging features and functions require increased memory capacity, faster data transfer rates and wider bandwidth communication networks than CAN is able to provide.

Engine control units (ECUs), for example, are used for multiple interdependent applications today. “This is a world where the ECU is a protocol machine,” Saalfeld explains. “It implements several different communication protocols to observe OBD data, which can be emissions-related diagnostics or concerned with enhanced diagnostics (related to non-emission aspects for performance, comfort or amenities).” This increased functionality means that modern ECUs require more memory and quicker data transfer. Even building the gateways (i.e. interfaces) to connect various communication networks in vehicles requires space, weight and dollar considerations that could be better used elsewhere.

An interim step provides breathing room
With CAN being increasingly viewed as the weakest link in vehicle data communication, automakers are seeking ways to keep pace with accelerating complexity and data diversity. Simplifying architecture, optimizing data transfer speed and bandwidth, as well as seeking open, harmonized standards globally are central to this quest.
 
“Communication protocols are the wrappers around data,” notes Saalfeld. At one time, automakers each developed their own protocols, but the advent of emissions regulation led to some standardization regionally, although differences between the North American, European and Asian jurisdictions exist.

Automakers typically employ one protocol specification for emissions diagnostics only, while a different specification is used for enhanced (non-emission) diagnostics. Saalfeld says there is a strong interest in the short term for using the same protocol specification for all OBD, whether emissions-based or otherwise.
 
“They expend a lot of effort on both, so simplifying to one protocol specification would have merit,” notes Saalfeld. “In the interim, Daimler will use an archtitecture known as Unified Diagnostic Services (UDS) over CAN.” He adds that the concept has received feedback from 30 automakers already, most of it favorable.

UDS over CAN architecture employs an ISO15031-compliant three-byte (i.e. 24-bit) diagnostic identifier, comprised of a two-byte (16-bit) Diagnostic Trouble Code (DTCs) and a one-byte Fault Type Byte or Fault Mode Identifier. Switching from emissions-based OBD to UDS over CAN OBD messages offers several advantages. For example, UDS over CAN:

• Incorporates all current CAN parameter identifiers and DTCs.
• Enables one set of timings and one set of data addresses.
• Provides a means to help harmonize U.S. and European emissions regulations.
• Lets scan tool manufacturers avoid having to implement two feature sets for tools to get essentially the same data.

Ethernet will be the game-changer
As an interim step, UDS over CAN buys time for next-generation Internet Protocol-based solutions, such as Flexray, Media Oriented Systems Transfer (MOST) and Ethernet to get established. Compared to these alternatives, CAN is much slower and has a much smaller bandwidth, which can limit or even prevent richer, more descriptive data from being communicated.

Moore's Law, developed by Intel co-founder Gordon E. Moore, states that the number of transistors that can be placed inexpensively on an integrated circuit has doubled approximately every two years. Vehicle electronics and computerization follow computer chip development by a lag of seven years,” notes Saalfeld. The lag between the two industries provides both security, surety and efficacy benefits for the automotive industry.

Due to the bandwidth and data limitation of CAN, Flexray and MOST, Saalfeld believes that over the long term, Ethernet will become the dominant communications system for OBD. “Imagine you have a CAN connection to your gateway [interface] and then after the gateway, you have a Flexray BUS,” Saalfeld suggests. “If you want to flash reprogram the ESP, a camera system or an engine retooler, you may not be able do this because the CAN slows you down or stops you cold.”

The computer industry has already developed well-established standards and in-market product experience in debugging software glitches that typically occur early after product launches. On the one hand, this would require OEMs and scan tool manufacturers alike to abide by computer world rules, not just auto industry rules. On the other, the lag allows adoption of proven technology into vehicle applications.

Besides already having well-established standards, Ethernet connections can handle more data as it has a higher data transfer rate and bandwidth. Ethernet has huge market penetration across a number of industries. Simply put, it works. Ethernet technology is also backwards compatible — new Ethernet technology can accommodate older verisons.

In addition, the explosive growth of telematics is tethered to increasing bandwidth. Current in-car telematics technologies are limited by low bandwidth. Ethernet’s increased bandwidth advantage will provide opportunities to leverage richer, more disparate data to significantly increase the interaction between the in-vehicle technology and the outside world. Apps will evolve in tandem with the increased bandwidth.

Saalfeld acknowledges that some Ethernet-related concerns need to be resolved while there is time. The 2008 exclusive mandate granted to CAN architecture has to be revisited. Developing and utilizing shielded Ethernet cables to prevent electromagnetic interference is one area. Collaborating to adopt common, compatible standards to avoid redundant duplicity is another. Finalizing a shape for automotive Ethernet connections that are distinct from consumer products is another safeguard the industry has to address, as is ensuring the security.

But even with these hurdles Saalfeld concludes, “The Ethernet is the future for vehicle OBD.”

###