Industry standards tune up tomorrow's vehicles

February 1, 2014 OpenSystems Media

1Automotive systems are increasing in complexity as they connect with other consumer devices, assist drivers with safety features, and control more vehicle tasks. To facilitate interoperability and reliability, standards organizations are working with numerous Original Equipment Manufacturers (OEMs), integrators, and each other to develop system- and subsystem-level platforms for the vehicles of the future. Embedded Computing Design spoke with AUTOSAR's Rick Flores, Global Lead of Model-based Electrical System and Software Engineering at General Motors; Alan Ewing, President and Executive Director, CCC; GENIVI's Joel Hoffmann, Automotive Strategist at Intel; and Henry Muyshondt, Executive Director, MOST Cooperation about the challenges and strategic and technical considerations of creating standards for the fast-growing automotive electronics industry. Edited excerpts follow.



Q What are the key technology drivers in the automotive industry today?

Flores, AUTOSAR: Over the last few decades, electronics and software have become increasingly important for automotive applications, as they drive approximately 90 percent of all innovations and account for up to 40 percent of a vehicle’s development costs. Current examples of technology drivers in the automotive Electric/Electronic (E/E) architecture are functional safety, Ethernet-TCP/IP communication, multicore, security, and new diagnostics regulations.

Muyshondt, MOST: One of the key drivers for automotive electronics is the need to better integrate various domains in the vehicle, such as infotainment, driver assist, navigation, and communications outside the vehicle. This drives the need for communications standards between these domains, and also drives up the need for higher bandwidth as more data is transferred within the vehicle and to the world outside the car.

The challenge is that these systems are typically developed by totally different groups within a car maker’s organization, and those groups have different problems that they are trying to solve. The other challenge is finding a technology that fits a broad range of functions. In the case of video, an infotainment system requires higher and higher video resolution and wireless connections to the cloud, while a camera system has more critical latency and determinism requirements. It is necessary to have standardized interfaces to allow the independent development of various domains, while at the same time allowing those domains to easily transfer information between them.

Hoffmann, GENIVI: The growing expectation of always being connected with the same level of personalization that drivers enjoy on their smartphones and other consumer electronics is one of the key technology drivers in this area. This requires seamless transitions between home, office, and car with contacts or entertainment choices immediately accessible. As a complement to this, automakers, insurance companies, and others look at this notion of “always connected” as a great opportunity to gather data about the car and its drivers to proactively deliver useful and actionable information to the driver.

The greatest challenge facing automakers and their software suppliers is the exponential growth in the amount of software required to meet the growing demands of drivers. IVI systems are stretching to over 50 million lines of code and automakers simply cannot continue their historically slow software development and delivery practices.

Ewing, CCC: Driver distraction guidelines have been one of the most interesting things we’ve worked on in the CCC, and also one of the most challenging. Everybody’s a little different, and what’s distracting for this group of people is not necessarily distracting for that group. Issues include things like font sizes, complexity of menus, scrolling text, contrast, and how much time it takes to look at the screen and figure out what’s going on. The U.S. and EU have guidance for driver distraction, and OEMs are concerned about this because they have liability issues with distracted drivers. The guidelines need to be distilled into test cases for application developers so they know how big their font sizes have to be, how much contrast is needed, and the dimensions of the information. All this is very complex to test and very time consuming to undertake.

QHow do standards approach the lifecycle disparities between consumer and automotive technology, and how do standards benefit manufacturers, developers, and end users alike?

Muyshondt, MOST: Automotive systems focus more on being able to distribute information rather than providing static functions; they are the interface between the consumer and their digital world. While the particular kind of information that gets distributed can change more quickly than the vehicle can, the interface to consumer’s eyes, ears, and touch does not. Particular instantiations of consumer products change quickly, but larger trends are actually more in tune with the automotive industry. For example, the transition from cassette tapes to CDs, DVDs, and currently mp3/digital music took over a decade each. Car makers have the long-term vision to be able to integrate each technology wave in a timely manner.

The car industry is relatively small in comparison to the consumer industry. It also has much longer lifecycles, which in turn drive much more stringent quality requirements – a typical car platform takes 3-4 years of development; systems used in these cars have to be useful for 15-20 years, and they have to survive in all types of climates for that long. Having a standard that has been developed by the car industry assures that the systems based on it will meet the long lifecycle and quality requirements of the industry.

[Standards] also allow suppliers a common way to communicate between the various subsystems they make for different car makers, without having to develop a new system for each car maker. Consumers benefit from the high quality and long life that these systems provide to them, and also from a lower cost point as development costs are spread over a larger number of vehicles from many car companies.

Flores, AUTOSAR: In state-of-the-art vehicles, the complexity of the electronics/electronic architecture and the Electronic Control Unit (ECU) software is rapidly increasing, so the use of proprietary solutions becomes less competitive. Uniform and open standards are needed to master this growing complexity.

By relying on standard products available on the market, extensive software reuse and software sharing with different suppliers, standards such as AUTOSAR provide improved development costs and quality. Thus, it is possible to achieve faster time to market for new features, and to integrate software functions from multiple suppliers into a single ECU.

Ewing, CCC: With a clear idea of problems and talented engineers and software development folks from throughout the industry, we can sit down and bang through the problems with about 90 percent effective discussion. And with 102 member companies, there’s a lot of overlap with other standards groups. We have really good insight into GENIVI, JASPAR, and liaison relationships with the Wi-Fi Alliance, Miracast, and Bluetooth SIG. One of the strengths of a consortium partnered with OEMs and other vendors is you bring in all those visions from your member companies who are putting stuff on the ground, and by doing that you typically are able to find the right path through the maze.

QWhat are the standards your organization is currently working on?

Flores, AUTOSAR: AUTOSAR Release 4.1.1 specifies a TCP/IP protocol suite over Ethernet as a new general communication mechanism. It includes the support for application protocols such as onboard diagnostic communication with software and hardware and service discovery. Additional application protocols will be needed to support automotive use cases, such as support of worldwide harmonization of On-Board Diagnostics (OBD) on Ethernet (ISO 27145), support of upcoming vehicle-to-grid communications protocol ISO 15118, streaming interface, as well as support for safety-related communication over the TCP/IP protocol suite. In addition, concepts are currently being developed, for example, for the configuration of switched systems as well as the efficient handling of large data types in the communication stack of an ECU.

Muyshondt, MOST: [MOST] technology includes not only the physical interconnection between devices, but also the necessary network management software and interfaces to control various devices attached to it. It offers a robust optical physical layer that greatly simplifies dealing with electromagnetic interference issues, as well as easier scalability between different speed grades – the same optics and light sources/detectors can be used in 25 Megabit per second (Mbps) to 150 Mbps systems, and the network management software is also the same. There is also an electrical system that uses Unshielded Twisted Pair (UTP) or Shielded Twisted Pair (STP) wiring for more modular design than optical systems, but requires more work to switch between speed grades. A coaxial wire physical layer is also emerging to bridge the gap between optical and UTP solutions.

Hoffmann, GENIVI: The GENIVI software platforms provide a starting point for producing an IVI development environment that any organization can use to produce a full IVI software platform or individual application. The baselines are actually open source projects hosted at projects.genivi.org, and completely open for use by anyone. They form the basis of a Linux-based automotive software platform that can provide a jump-start to anyone interested in producing IVI software. These baselines represent the collective experience and knowledge of more than 180 GENIVI members, many of whom are leading suppliers of production IVI software in the market today.

Ewing, CCC: The CCC’s focus is on MirrorLink, which is a technology standard for connecting to and controlling smartphone apps from a vehicle dashboard display or steering wheel controls. It’s currently in version 1.1, which supports wireless connectivity using Wi-Fi and Miracast, building on USB 1.0’s connectivity.

Everything in MirrorLink is backward compatible, and we’re working on version 1.2 to add some refinements to 1.1, like refining Miracast, HSML, and a few other technologies that augment the mirroring of the screen. Discussions for future revisions are in the very, very early days, but after 1.2 it’s probably reasonable to say that once a year on average either refinements or something big will be included in an update.

Q How do you address security concerns in your standards?

Ewing, CCC: Head units are becoming more and more tightly integrated into the vehicle. That’s both a curse and a blessing for us. You get a lot of data access that we can take advantage of, but you have to be really careful. From the smartphone perspective back to the head unit, one of the ways we put up the appropriate guards, roadblocks, caution, firewalls, and so on, is through certifying the device. Only those phone and head units that are certified carry with them information that says, “I am a valid MirrorLink session/device/application, you’re a valid MirrorLink head unit, we’re allowed to talk and exchange information.” For man-in-the-middle attacks, you can never eliminate them, but you can make them so difficult to do that it’s impractical, which is what we’ve done. We have a series of audits that we do on our device manufactures to grant device certifications, and we have a security infrastructure for the app that is banking-quality kind of security.

Muyshondt, MOST: The data pipes provided by MOST Technology use data transports that employ industry standard security mechanisms, like AES128 encryption, or various Internet standards like SSL and the like. MOST actually multiplexes several different types of transports, including Ethernet frames and streaming protocols that each have security requirements set by content owners. Commercial video can be protected using Digital Transport Content Protection (DTCP) or High-bandwidth Digital Content Protection (HDCP).

For Internet traffic, one of the MOST channels – MOST Ethernet Packet (MEP) – can transport Ethernet frames without any need to modify them. Thus all security standards developed for the Internet can be run unmodified to protect data traffic running over the network. The network is transparent to the applications running above it.

Flores, AUTOSAR: With a new concept group started in 2013, AUTOSAR addresses the increasing demand to make vehicle networks secure and to reduce vulnerability. The activities focus in particular on message authenticity (identification of a trusted sender for messages received over the in-vehicle communication bus), message integrity (detect if a message has been manipulated during transmission), as well as message confidentiality (encryption of data before sending it over the in-vehicle bus for confidentiality and privacy reasons).

QWhat features or abilities do you see emerging in automotive embedded systems that will need standardizing?

Flores, AUTOSAR: Energy efficient technologies have become a key driver in automotive electronics during the last years due to increasing power consumption by new, complex electronic functions, a CO2-based vehicle tax, and increasing fuel costs.

One of the concepts facing this issue is partial networking. Today, all ECUs in a car are active even if they are not needed. The goal of partial networking is to reduce power consumption of such ECUs by temporarily shutting down groups of them during active bus communication. The concept of pretended networking introduced with release 4.1.1 achieves power saving with an approach that reduces runtime power consumption by increasing the idle time of the MCU. This ECU-local approach allows an easy integration into existing networks. Further aspects to reduce power usage in automotive applications are to be identified and supported.

Muyshondt, MOST: The next big thing in terms of networking technology is the integration of sophisticated Advanced Driver Assistance Systems (ADAS), with multiple cameras to see around the vehicle and image recognition for the vehicle to interpret signs, traffic lanes, and other things outside the vehicle. These systems can also serve as a base to develop more autonomous driving functions for vehicles.

ADAS systems will provide a second set of eyes to watch for lane departures, signs on the road, speed limits, cars ahead, people or other objects, etc. Parking will become simpler. The car will be fully integrated into the owner’s digital world. Standards are needed to integrate cameras and sensors, and also to distribute and use the data that results from all these sensors working together.

Hoffmann, GENIVI: Features are constantly changing in the IVI space. The lines between infotainment and car safety are beginning to blur with an increasing wealth of driver assistance capabilities. This is an interesting growth path to consider. The management of car and driver information is another area of growth and is related to an interest in cloud technologies and the Internet of Things (IoT) movement.

AUTOSAR

www.autosar.org

@AUTOSAR

www.linkedin.com/groups/Autosar-1445227

Car Connectivity Consortium

www.mirrorlink.com

@MirrorLink

www.linkedin.com/groups/ Car-Connectivity-Consortium-4283188

GENIVI

www.genivi.org

@GENIVIAlliance

www.linkedin.com/company/ genivi-alliance

MOST Cooperation

www.mostcooperation.com

@MOST_Tech

Panel Discusson (AUTOSAR, Car Connectivity Consortium, GENIVI, MOST Cooperation)
Previous Article
Regulation, consumer demand drive future IVI and ADAS markets
Regulation, consumer demand drive future IVI and ADAS markets

IHS analysts project how consumerism, regulation, and software will mold the future of IVI and ADAS systems.

Next Article
Choosing a processor is a multifaceted process
Choosing a processor is a multifaceted process

The days are over when selecting a processor was a relatively simple task, in light of today’s conver...

×

Follow our coverage of automotive-related design topics with the Automotive edition of our Embedded Daily newsletter.

Subscribed! Look for 1st copy soon.
Error - something went wrong!