Posts Tagged ‘global-top’

As IoT Expands, Automotive Software Innovates to Connect, Integrate and Ensure Functional Safety

Thursday, January 22nd, 2015

What steps led to the creation of a heterogeneous overall system that meets the functional safety requirements defined in ISO 26262?

The automotive industry and its suppliers are preparing cars for the Internet of Things. In the process, they are using a system architecture that supports better integration of functions and their connectivity to the outside. Using what it calls Interior Domain Integration, Continental Automotive (Figure 1) is developing this type of integrated platform for connected vehicles. The new system is based on a hypervisor that enables applications to be arranged in a new way.

Figure1

Figure 1. An automotive supplier is developing an integrated platform for connected vehicles that prioritizes the overall security of the automobile system while allowing for the integration of automotive and consumer electronics and infotainment.

Learning from Other Industries
In the 1990s, the aviation industry revolutionized aircraft electronics with Integrated Modular Avionics. This approach combined individual control units on a central platform for the first time in the Boeing 777 and Airbus A380 in order to save size, weight and power.

Today automotive electronics face challenges similar to those aviation encountered. Here, too, it is important to separate the rapidly expanding number of devices that usually have small, low-power processors from their isolated hardware and to represent their functions in software. As many as 120 processors per vehicle and 100 million lines of software code are to be combined on a powerful central processing unit. And we are only now witnessing the dawn of “intelligent” cars. A constant flow of new multimedia applications, safety functions and assistance systems are emerging all the time, which can be dynamically installed from app stores in the workshop or even by users themselves. The mobile communications industry is also pushing its way into automotive electronics and tapping into new business models such as Car-to-Go and insurance premiums based on usage and driving habits.

Interior Domain Integration
Continental Automotive is developing Interior Domain Integration as a central platform for a variety of functions. The Interior Domain Integration central platform that Continental is developing relies on the PikeOS hypervisor from SYSGO. Combining GENIVI, AUTOSAR, Android and POSIX applications on a single powerful ARM multicore hardware unit, this central platform links automotive electronics with consumer electronics and infotainment. This creates more space for additional applications, increases design flexibility and opens up opportunities for additional after-sales services and long-term business models over the life cycle of the vehicle. Employing such a platform also solves the associated security problems by separating the applications in the system architecture according to their security properties: untrustworthy Android applications run on the other side of the firewall, on a separate Core 4. Trusted but non-security-relevant GENIVI applications run behind the firewall, on Core 2 and 3. Both the trusted and security-relevant POSIX and AUTOSAR applications use Core 1, as Figure 2 shows.

Figure2

Figure 2. Interior Domain Integration separates the applications on the hypervisor according to the secure/insecure as well as trusted/untrusted criteria and runs them on different cores.

System Architecture for a Heterogeneous Software Landscape
PikeOS hypervisor features support the pooling of a heterogeneous software landscape consisting of existing as well as new applications according to their respective safety and security relevance. First, by means of partitioning, containers are set up for the instances of different guest operating systems with their respective applications (Figure 3). Interior Domain Integration requires that the containers be separated from one another so that they cannot interfere with each other.

Druck

Figure 3. Shown is an example of PikeOS system architecture for automotive electronics with partitions for heterogeneous software applications on a centralized platform.

Ensuring Functional Safety in Vehicles
The adoption of ISO 26262 in 2011 was essentially an automobile-specific version of IEC 61508 to standardize the functional safety of automotive electronics. Safety risks are classified separately for each application according to the ISO 26262 standard. A distinction is made here between QM (no risk) and ASIL A through D (low to high risk). The software of each application is then certified separately according to the risk determined by independent agencies.

Because all Interior Domain Integration applications are placed in separate containers on one platform, it’s the job of the separation kernel in PikeOS to ensure that this separation actually works. The kernel’s task is to create an environment that, from the perspective of the individual application, does not differ from a physically separated system. Time and space partitioning ensures that each application is autonomous and does not “see” the other applications. It uses only the hardware resources explicitly assigned to it by the separation kernel. These include memory areas, resources and application sets at precisely specified times. The inter-partition communication controls the flow of information with other applications by way of fixed channels and limits communication to known and accepted instances.

The integrated platform from Continental can host multiple applications, which are classified according to functional safety levels: non-critical (unsafe) to highly critical (safe). The PikeOS separation kernel separates these from each other so that they do not see and interfere with one another. All applications are certified according to their individual criticality. PikeOS itself must comply with these safety criteria as well. The heterogeneous overall system therefore meets the functional safety requirements defined in ISO 26262. If, for example, a non-critical multimedia system running on Android causes an error and crashes, this will not interfere with a high-priority, critical assistance system. Instead, the critical assistance system continues running normally.

Overcoming Vulnerabilities via Security Rules
The more entertainment and infotainment electronics find their way into the vehicle, the more vulnerable the integrated platform is to malicious attacks and deliberate manipulation. For this reason, it is important to define IT security rules for applications in cars, and the underlying system software must support these rules.

For this purpose, the Multiple Independent Levels of Security (MILS) concept, which originated in military applications, has been around for a long time. MILS organizes systems into three horizontal levels with different rights and levels of trustworthiness.

The lowest level is formed by the hardware with other platform and security modules. Level 2 contains the separation kernel, which controls all communication in the system and allocates computation time and memory access to the various applications. Only the separation kernel has hardware access privileges (kernel mode) and is considered trustworthy in terms of security (trusted). All other modules of the system software on the second level are also considered trusted, but do not have hardware access privileges. This methodology helps configure, organize and monitor the functionality of the entire system. All applications are assigned to the third level, are considered not trustworthy (untrusted) and run in user mode.

The PikeOS hypervisor supports a system architecture for Interior Domain Integration, allowing a combination of heterogeneous software applications in separate containers on a single platform. The separation kernel in PikeOS enables a strict separation of applications. It provides safety and security features that ensure the overall security of the automobile system and allows for the integration of automotive and consumer electronics and infotainment.


ChrisBergChris Berg is a solutions architect at SYSGO. He has been working in the embedded industry for more than 15 years. Graduating in Physics Mr. Berg initially worked as an IC design engineer at Siemens and Infineon. Prior to SYSGO Mr. Berg held a position as solutions architect at MIPS Technologies.

Driving The Digital Car With Analog Components

Friday, June 13th, 2014

The modern “digital car” includes analog components for timing and signal integrity alongside USB, PCI Express and others.

Today’s new cars get decent mileage, are relatively safe and are considered stylish, so auto OEMs must add something special to stand out. Car tech is the cornerstone differentiator of many automobile companies’ product offerings. Lately the “killer features” that consumers want and will pay extra for include tech packages such as: an in-vehicle infotainment (IVI) system with smartphone integration, rear seat LCDs, and all-around cameras for safety (Figure 1).

fig_1
Figure 1: “Car tech” in the digital car includes center console and rear seat “infotainment” (IVI) systems, plus cameras for safety features. Note the labyrinth of cables and wires of often high-speed digital channels like PCI Express, Ethernet and HDMI.


This onboard embedded “infotainment” tech includes the digital standards designers are familiar with like USB, Ethernet, PCI Express, GPS and video decoders. And just like any other embedded system, designers are also finding the need to add analog components that:

  • recover clock signals and reduce timing jitter,
  • increase digital fanout and output drive capability, and
  • provide high precision clock sources in compliance to specifications like PCI Express.

Beyond these requirements, USB charging is becoming a “must have” feature. Finally, the digital car is also harsh environment. Certified, automotive-grade components are needed with long life cycles.

Let’s take a look at how the digital car mixes analog and digital devices in this evolving market.

Growing Market; New Challenges
The digital car is stuffed with systems running processors from Altera, AMD, ARM, Intel, Freescale, Hitachi, Renesas, TI, Xilinx, and others. Each of these is at the center of an embedded system with one or more LCD displays, PCI Express, Gigabit Ethernet, GPS, and USB I/O (Figure 2). Not surprisingly, these “car tech” embedded systems mirror those running a point-of-sale (POS) terminal, a gaming console, a mobile device, and a closed-loop servo system—all in a car.

fig_2
Figure 2: The digital car’s embedded systems rely on analog components for clocks, data transmission and jitter improvement, and switches to improve fanout.

In other words: this is a typical, contemporary high-speed digital embedded system. There are challenges to provide: accurate timing (clock) generators for the processor/SoC and PCI Express (PCIe); maintain control of GHz signal jitter and “eye” margin; provide enough clock sources for all the peripherals; provide PCIe bridges and fanout; and maintain high quality video to/from remote sensors and displays. But different from other embedded systems, the digital car must also connect to and charge all of the driver’s and passengers’ high current mobile devices via USB.

The technical challenges here go beyond a “regular” embedded system because auto OEMs and their typical suppliers have not previously been expert in these kinds of high-speed, high data rate designs so it’s up to component suppliers to provide needed design expertise. And the car is a noisy EMI environment with long cable/wire runs that plays havoc on digital timing, as do the temperature extremes from winter to summer.

Re-Drivers to Drive Signals
Sub-micron leading-edge microprocessors, SoCs and FPGAs have limited output drive capability for long traces and inter-board connectors. In the high EMI environment of the digital car, long cable runs between boxed subsystems (or external cameras) further degrade signals through attenuation and noise. The end result is a closed “eye” for the very high speed signals—like PCI Express, USB, or HDMI—that define the latest digital car systems.

The solution to this problem is an active signal amplifier called a “redriver”. These marvels are designed to work with many different signal types, from PCIe to USB, HDMI and more. Redrivers at each end of a long signal trace or cable run return signals to within spec margins and are an essential part of the digital car (Figure 3).

fig_3
Figure 3: A Redriver is a repeater/amplifier that cleans up attenuated and degraded signals. The open “eye” on the left is nearly closed (middle) as a result of the long trace or cable run. The eye is again open on the right and signals are returned to normal.

The Time is Right for PCI Express
Digital components, especially those driving multi-gigaHertz signals like PCIe, GigE or USB 3.0, require one or more highly accurate clock sources. IVI systems, with their emphasis on real-time graphics and video, have started to use PCIe for high-bandwidth I/O connecting peripherals and on-board SSD storage. Every PCIe device requires an accurate 100 MHz clock generator to create the ultimate 2.5 to 5.0 GHz data rates for Gen 2 and Gen 3.

A PCIe clock generator used in automotive applications will ideally provide several 100 MHz outputs to drive multiple PCIe devices and save board real estate. Having multiple outputs eliminates the need for clock buffers and their inherent timing latency. Compliance to PCI-SIG specs for G2 or G3 is a given, with jitter under 3.1ps in order to maintain PCIe margin in such a harsh environment. PCIe clock generators also need to be automotive grade and qualified to Automotive Electronics Council Quality (AEC) Q100 standard.

Having multiple outputs allows driving the processor or SoC and other PCIe devices since most processors don’t provide PCI clocks (Figure 3). An exception is Intel CPUs, but they consume two pins for the differential signal; this adds routing challenges for large pinout devices. Providing multiple outputs eliminates buffers, as mentioned, while saves money for auto OEMs building millions of units.

fig_4
Figure 4: Typical use for a four-output (4) PCI Express clock generator in automotive infotainment.

The automotive grade Pericom PI6C557-03AQ/ PI6C557-05Q spread spectrum PCIe 2.0 clock generators, for example, drive two or four LVDS or HCSL outputs (25 MHz, 100 MHz, 125 MHz, or 200 MHz), have a phase jitter of 2.1ps that beats the PCIe spec, yet only require a low cost 25 MHz crystal next to the 16/20 pin TSSOP footprints. These particular PLL-based devices are interesting because of the multiple output frequencies, which allow designers to clock PCIe or Ethernet peripherals.

We’ve been describing how PCI Express is used as a common in-system communications channel between peripherals. In some cases, rear seat LCD subsystems may connect via PCI Express due to its high data rate. In other cases, PCIe may represent the only fast channel available in an era of SPI or I2C slow devices. In all of these instances, there’s a need to bridge a processor’s PCIe channel to multiple devices.

A PCIe (Packet) Switch bridges one PCIe channel to many, increasing a processor’s fanout. By adding intelligence to the bridge that chooses which packets to pass to what port, a simple one-to-many bridge becomes a packet switch. Qualified to AEC-Q100 (ICs) for automotive applications, this kind of intelligent bridging offloads the host CPU or SoC by allowing routing and communication decisions without processor intervention.

Crystal Clear Timing
Most digital systems maintain a real-time clock, but there’s one in an automobile that’s visible to the user: it’s in the IVI system. While this is only one of many RTCs in the car that rely on crystal oscillators (XO) as the base timing reference, the one in the IVI remains critical. This RTC displays time-of-day, and it awakens systems the driver cares about most—such as the instrument cluster, outside temperature display, or back-up camera.

By far the most common reference oscillator is the “32 kHz” XO (32.768 kHz) and it provides the base time reference for RTCs, processors in Sleep, and other peripherals. In multi-million unit automotive applications, the temptation is to use ultra low cost tuning fork-based XOs. While industry-accepted and proven, tuning fork XOs have two key attributes not suitable for a car’s IVI system: temperature drift and a very long start-up time.

Figure 5 shows the frequency drift (called “ppm”) versus temperature between the common tuning fork crystal (left) and the “AT Cut” crystal (right). For the tuning fork XO, a ΔT of -20°C results in a 160 Hz ppm, which can be substantial for RTCs and other timing solutions that require more precision, or whose PLLs can’t tolerate this much variation. The AT Cut crystal (“AT” refers to the 35.25 degree angle of the crystal cut) varies only +25 ppm over about 40°C. This is at least a 5x improvement in temperature precision.

fig_5
Figure 5: Tuning fork XO (left) vs AT Cut XO (right). The tuning fork ppm (ΔF/F) varies greatly with temperature. AT Cut crystal oscillators from Pericom Semiconductor, for example, exhibit the ppm frequency precision shown in the right-hand curve.

As well, tuning fork XOs take a long time to start up—as much as 1000 ms, compared to AT Cut XOs. Devices from Pericom Semiconductor, for example, can start up in as little as 2 ms with a typical time of 10 ms. This makes a big difference in what the driver experiences if he/she is forced to wait several seconds as tuning fork XOs stabilize and a sequence of systems all boot up. The AT cut XO is the preferable choice.

Getting a Charge from Ubiquitous USB
No longer reserved for merely connecting peripherals like mice and keyboards to computers or synching an iPhone to iTunes, USB provides power to all kinds of consumer products. As mobile devices like smartphones and tablets migrate into the automobile, USB provides the umbilical cord for IVI connectivity and device charging while on the go.

The variations in USB for automobiles go beyond the data rates of USB 1.1, 2.0 and 3.0; in fact, there are various charging modes and current sourcing options, along with different international standards like Chinese Telecom Standard YD/T-1591. One key metric is the amount of current a USB connection can provide, from milliamps up to the 2.0A required by Apple’s iPad and many new Intel/Microsoft 2:1 devices. Consumers expect to use (and charge) all of these in their car.

Apple, for example, defines Apple-1A and Apple-2A communication modes in their USB chargers. This is why the smaller charger from an iPhone charges an iPad so slowly: not only is the source current different, but the charger knows this and adjusts the charge profile accordingly.

For the broader market, the USB Implementers Forum has defined the USB Charging Spec (USB Battery Charging 1.2) with multiple variations on a charging theme. Some of the modes are described in Table 1.

table_1
Table 1: USB Implementers Forum (USB-IF) Battery Charging specifications (from their 1.2 compliance plan document October 2011).

Referring back to Figure 2, the automotive IVI embedded system needs to support USB data communication plus multi-device charging. This includes all USB-IF charging standards shown in Table 1, plus non-standard (although widely used) charging profiles such as Apple-1A and -2A. For future-proofing today’s IVI system with tomorrow’s unknown devices, USB chargers should also have programmable current output limits, run off of a single 5V DC-DC converter input, and be AEC-Q100 qualified for rugged automotive applications.

One device that meets all of these criteria is Pericom’s PI5USB8000Q. It supports CDP for data and charge at 1.5A, SDP for data and charge at 500 mA, and DCP for 1.5A charging. The device also supports Apple-1A and -2A, and can determine when a device is plugged in (called PowerNAP) and ramp up the power. When a device is disconnected, current sensing will place the IC in a low power mode. This is important in always-on automotive “Power Port” (aka “cigarette lighter”) applications that are not disconnected when the ignition switch is off.

Driving the Digital Car
Digital technology is a key differentiator for automobile OEMs as they try to stand out from the crowd, and they’re rushing to add more IVI cabin tech with every model. As designers deploy more high-speed digital systems with standards like PCI Express, Ethernet, HDMI, USB and more, they’ll also need to add companion analog devices for timing, buffering, repeating, and redriving signals. As well, USB charging—in all of its flavors—is a “must have” with today’s car consumers.

Editor’s note: This article was sponsored by Pericom Semiconductor.


ciufo_chrisChris A. Ciufo is editor-in-chief for embedded content at Extension Media, which includes the EECatalog print and digital publications and website, Embedded Intel® Solutions, and other related blogs and embedded channels. He has 29 years of embedded technology experience, and has degrees in electrical engineering, and in materials science, emphasizing solid state physics. He can be reached at cciufo@extensionmedia.com.

For Cars, the Future is Here

Monday, November 11th, 2013

From in-vehicle infotainment systems and advanced driver-assistance systems (and the standards that support them) to the self-driving car, embedded automotive systems never looked so cool.

131111_auto_3

Some of the most exciting advances in embedded automotive systems are happening today, with plenty more in the nascent stages. With advanced sensor and user interface technologies coming out of the consumer arena, along with new connectivity standards and safety regulations, the stage is set. Maybe not for the flying car that George Jetson rode to work—just yet—but for a wide range of capabilities that will also drive societal expectations. We have a great panel of experts here to give their insight on where embedded automotive technologies are going—and what’s still needed. Many thanks to Andy Gryc, senior automotive product marketing manager, QNX Software Systems; Dan Loop, business development manager, automotive infotainment processors Freescale; Davide Santo, ADAS microcontroller product manager, Freescale; Warren Kurisu, director of product management, Mentor Graphics Embedded Systems Division; and Rob Valiton, senior vice president and general manager, Automotive, Aerospace and Memory Business Units, Atmel Corporation.

EECatalog: The buzz today is the in-vehicle infotainment (IVI) system and its ability to provide a smartphone-like experience to the driver and passengers. What technologies are still likely to find their way into the automobile’s IVI system—and what technologies will never be appropriate for the “connected car”?

Andy Gryc, QNX Software Systems: For front seat applications while the vehicle is in motion, just about the only prohibitions would be games (excepting auto-centric games like “beat your fuel mileage”), video conferencing, and news tickers. Just about everything else—apps or technology—is possible, and could be adapted to a safe in-vehicle experience with appropriate modifications to display and user interaction. Even intensely engaging graphical experiences can be provided while the vehicle is in park or for rear-seat. NFC and augmented reality have been demoed; QR code reading and fingerprint recognition have reasonable applications.

Dan Loop, Freescale: Vehicle OEMs will ultimately determine the answers to these questions based on their view on the value of the technology to the driver and its impact on driver and passenger safety. As we move toward a higher penetration of connected vehicles, the amount of technology available for integration increases dramatically and we will see new vehicle-specific functions emerge that one may never see in a smartphone. This gives a wide array of technology options for the OEM to align with their brand and each vehicle’s value proposition. Ultimately, this drives the need for flexible and scalable solutions in the IVI space. What one OEM may see as valuable another may see as not appropriate, yet similar hardware and software may be utilized in both systems. Also, as we move into an era of autonomous vehicles we are likely to see that technologies that were once viewed as not appropriate become acceptable in certain autonomous driving situations, which will only intensify the need for more flexible and scalable IVI platforms.

Warren Kurisu, Mentor Graphics: The technologies that will work their way into vehicles will reflect key characteristics of smartphones, namely: media, connectivity and application availability. Of course, media-rich systems are already commonplace. The abundance of accessible and inexpensive connectivity options such as Wi-Fi, 4G/LTE, GPS, satellite and others will become increasingly integrated in the vehicle and pull in technologies for app store access, firmware over-the-air updates and web- and cloud-based technologies. Of course, with connectivity come security concerns. Commercial hardware-based technologies such as ARM TrustZone will be required, as will software complements such as type-1 hypervisors. These technologies together can help to create secure zones within the system, and minimize attack surfaces by keeping applications within those zones secure from each other and from attacks via external connections. Broadly speaking, anything that isn’t efficient in terms of space, weight, power and cost—or creates unmitigated security, safety or driver-distraction issues—will not be appropriate for the connected car. With that qualification, given the increasing pace of technology advancement, it’s difficult to definitively exclude any specific technology from eventually making it into the car if it serves an important function.

Rob Valiton, Atmel Corporation: There are a wide variety of technologies that will continue to find their way into IVI systems. Undoubtedly, capacitive touchscreens will be one of the fastest-growing. The current dominant touchscreen technology in automotive is resistive. However, resistive technology does not allow consumers to interact with their car the way they interact with their smartphone, tablet and Ultrabook, resulting in a frustrated user. The superior user interface, including common gesture recognition utilizing pinch/zoom and swiping motions is enabled by the adoption of capacitive technology.

Some newer features such as hover and proximity may also have the potential to create a less-distracted user environment than what exists today. Hover and proximity can be used in combination to ensure that the drivers’ eyes stay on the road for as long as possible and changing basic setting does not require several menu changes.

In terms of connecting devices in the car, Bluetooth has traditionally been viewed as the ultimate solution in the automotive sector, with Wi-Fi technology being closely examined as an alternative. Automobiles today allow users to stay connected to their smartphones in a hands-free manner, meaning users can stay connected while they are in-transit from their home to the office.

It is somewhat difficult to identify specific technologies that aren’t appropriate for the “connected car,” whether now or in the future. Clearly, the connected car is only limited by one’s imagination and safety concerns.


EECatalog: What standards are needed to unify the IVI experience between onboard systems and the products the consumer connects to the car?

Gryc, QNX Software Systems: USB and Bluetooth right now provide much of what is needed for a “standard” experience. For higher-quality experiences, a transport (USB 3.0, WiFi/WiFi Direct, BTLE) and a protocol (H.264, Airplay, Miracast, MirrorLink, DLNA) are needed.

Loop, Freescale: Due to the rapid pace of innovation in consumer devices, the automotive market struggles to stay aligned with consumer device connectivity. While creating standards will certainly streamline the introduction of connectivity technologies into vehicles, the key ingredient is for the big consumer technology companies such as Apple and Google to have a more open dialog with the auto industry in order to close on standards that can be adopted at a quicker pace or even allow older vehicles to be upgraded in the field. This will ultimately provide a better in-vehicle user experience with new devices that typically have a lifespan of one to two years versus a vehicle lifetime of three to five-plus years. While we are now seeing an emergence of new smartphone integration technologies such as Apple’s iOS in the car, a deeper commitment is needed to keep the standards stable and supported in future devices to account for the disconnect between consumer technology and vehicle life spans.

Kurisu, Mentor Graphics: There are a few perspectives from which to address this question. For manufacturers who are not seeking to differentiate for high margins, a simple standard to mirror the smartphone on the IVI system is good enough. A good example is the Connected Car Consortium’s MirrorLink technology. For higher-end models, delivering a branded, differentiated solution is paramount. One such standard could be HTML5, which could allow applications to be run locally, on the smartphone or in the cloud, yet allow the OEM to deliver a branded user experience in the vehicle. Broadly speaking, GENIVI as a standard is important as it continues to consider and create projects related to consumer electronics technologies such as application frameworks, Qt graphics, HTML5 and app stores.

Valiton, Atmel: There are a number of standards to consider for unification of the IVI experience between on-board systems and connectable consumer products. Standards range from security and software considerations, to technology such as Bluetooth and Wi-Fi.

Standards identified by technology standards bodies, such as the Bluetooth SIG or Wi-Fi Alliance, are required in order to unify the IVI experience on-board, specifically in relation to consumer products. These are required to ensure a smooth and seamless connection, as well as a positive experience for the end user. Firmware specifications are identified within a car to ensure connectivity is established flawlessly. In addition, continued development of standards such as those being developed by the Connected Car Consortium will ensure that drivers can continue to control their devices using existing in-vehicle equipment.

Software considerations are also important. Since the infotainment lifecycle of an automobile is typically much longer than in the home, future cars must consider software standards along with the ability to upgrade.


EECatalog: What technologies—in the car, terrestrially and wirelessly—are needed to connect the car to roadway and municipal infrastructures, as well as to make vehicle-to-vehicle communications a reality?

Gryc, QNX Software Systems: V2V/V2I capabilities are usually envisioned through DSRC or WiMax, however, these technologies and their implementation for any V2V or V2I system will require governmental regulation to proliferate and are still likely years out. The most likely short-term form of V2V would be through an LTE carrier network—the vehicle contacts a cloud-based “big data” service to report its position (anonymously), and any other connected vehicles can get aggregate crowd-based information like traffic density, road speeds or localized weather.

Loop, Freescale: As vehicles establish themselves as another node on the ubiquitous Internet of Things (IoT), multiple data pipes both fat and thin will become critical to future driver experiences. We are already seeing the emergence of 4G connectivity for data and in-vehicle hotspots, and OEMs will find new ways to monetize this fat data pipe into vehicles. V2I will rely on thin pipes similar to what is emerging in IoT sensor networks that are already being deployed by municipalities to streamline management of utility infrastructures. As V2V emerges, we will likely see similar technologies employed with specific tweaks to ensure quality of service of communication between moving vehicles. Within the vehicle, consumer technologies such as USB, HDMI and 802.11ac will dominate as they will be the most visible and valuable to the vehicle purchaser. The key question in the incorporation of all of these technologies is how intrusive they will be to the vehicle owner, as privacy concerns will rise as information is routed over networks that can ultimately move data from the car to the cloud.

Kurisu, Mentor Graphics: GPS combined with dedicated short-range communication (DSRC) standards, including 802.11p, is very promising. The allure of DSRC is that localized networks of vehicles communicating with each other and the infrastructure are inherently more efficient and real-time than a systemic, Internet-based broadcast of notifications and status. Interestingly, I don’t think the problem is so much the technology, but rather that for such a system to be truly effective, the standards would need to be compatible internationally, and all vehicles would need to connect to the network. As an example, consider a simple efficiency use case. If my car were connected to the traffic light grid and was able to exploit that connection to avoid red lights, I might not be able to take advantage of that efficiency if the car in front of me wasn’t also connected, and as a result was driving too fast or too slow. I also dream of the day where I can zoom along a highway in a caravan of connected vehicles, but that only works if all vehicles are somehow communicating with each other.

Valiton, Atmel: There are a number of technologies that are required to connect a car to the roadway and municipal infrastructure, along with vehicle-to-vehicle communications. These technologies require a microcontroller (MCU), numerous sensors, a connectivity solution which can range from Wi-Fi such as 802.11p, GPS and 3G or 4G networks and security. The combination allows cars to connect to roadway and municipal infrastructures such as Fastrak, toll payment or Onstar security systems—all of which are connected to terrestrial and/or wireless connectivity.

Security in automobiles is very important. Remember, we are all used to having virus protection readily available on our PCs, but are unlikely to think that much about how secure our software is in the modern automobile. Until now, the software has been part of a closed system and not subject to hacking. With the new V2V and V2X systems, we will need technology to ensure secure firmware updates and prevent hackers from communicating with unsuspecting drivers and their vehicles.


EECatalog: Where do you see opportunities for next-generation advanced driver-assistance systems (ADAS)? What technologies fill the gaps—and what’s still needed?

Gryc, QNX Software Systems: ADAS is a hot area, and will continue to grow and evolve over the next couple years. Safety features are becoming part of the European buying decision (encouraged through Euro NCAP), and will spread globally to address continued public emphasis on enabling elderly drivers with aging populations, alleviating increasingly crowded roads and enforcing safety with distracted drivers. ADAS technology will need to rely on inexpensive sensors (cameras being cost-reduced by inclusion in mobiles), merger of multiple ADAS systems into single module/single processor and massively parallel image-processing software.

Davide Santo, Freescale: Advanced driver-assisted systems are among the most interesting innovation areas for automotive today. ADAS will help increase both the comfort and the safety of our autos, while reducing the fuel consumption for a greener mobility and helping us to live better in an increasingly complex and crowded automotive environment. From simple systems that help the driver to compensate for his accidental distraction, such as warning systems, to the systems that can reduce the driver’s stress in traffic or congested areas, ADAS is progressively developing to lead us into a world of autonomous mobility within certain limitations and legal boundaries. Algorithms, microcontrollers, system integration tools, sensors are all developing under the main trend of integration and help manage this complex problem by separating it into manageable subunits.

Santo, Freescale: Many technologies are already available today:

  • Vision camera sensors, which are following in the path of consumer cameras by expanding their depth of colors and the numbers of pixels, complemented with more sophisticated image signaling processing (ISP)
  • Radar units capable of faster modulation of frequencies based on 76-81 GHz and with the possibility to add easy-to-integrate, low-level digital functions to distribute the computational load
  • Infrared technology for night vision
  • Laser-scanning sensors and the already highly fitted ultrasonic sensors for park assist.
    In addition, two sensor classes are emerging as perfectly complementary and beneficial for sensor fusion; the combination of radar and camera, which will dominate development efforts over the next three to five years.

Kurisu, Mentor Graphics: Currently there are hundreds of deployed ADAS technologies and hundreds more in advanced R&D. Among the most interesting opportunities from my view are those that leverage signal- and image-processing techniques that have been used in military and industrial applications for years. Recent advances in heterogeneous system-on-chip (SoC) architectures that combine multiple powerful application processors and FPGA fabrics, such as those found in the Xilinx Zynq processor, can create the technical foundation for such capabilities. Automotive device manufacturers can utilize the fabric for computationally intensive image pre-and post-processing, image manipulation, motion estimation and object classification, and then leverage that information as input to advanced ADAS systems. Other interesting technologies include heads-up displays, voice recognition and even gesture recognition, all of which could be used to minimize driver distraction and simplify the operation of the increasingly complex vehicle. While not a technology per se, but critically important nonetheless, safety standards such as ISO 26262 will be required for these systems as needed.

Valiton, Atmel: There are a number of applications in cars that we are currently seeing and others which we’ll see in the next five to 10 years for ADAS. These include adaptive light control, cameras, in-vehicle navigation, body electronics, access systems, lighting and entertainment applications that will help fill the gap. These applications are already changing the way we interact with our vehicles in more ways than we realize. From advanced lighting to in-vehicle entertainment, our vehicles are already on their way to becoming the connected car that drivers desire.

In order for these applications to be successful in ADAS in the next five to 10 years, there are a number of technologies that must be achieved, including distributed processing, sensors in the car and real-time processing. In addition, applications must support small designs and offer a high level of integration to fit the limited space available in automotive environments. Developers also need to meet compliant automotive qualification demands while offering a wide range of products and services.

Finally, manufacturers must work with developers to create solutions that:

  • Use standards-based connectivity for intelligent networked solutions
  • Allow compatibility and protection including robust electromagnetic compatibility (EMC); electrostatic discharge (ESD) protection
  • Offer resistance to high-temperature and low-power consumption for maximum efficiency

EECatalog: We have to close with this one: the self-driving car. Google’s initiative is one effort, though DARPA has been “challenging” teams to do this for years. Are we ready for a self-driving car? What embedded technologies and software are needed to make this a reality?

Gryc, QNX Software Systems: Technology will be ready before society is ready. Technology advances have allowed several OEMs to draw a line in the sand for production release of some phase of autonomous driving before the close of the decade. What is needed is a focus on turning $100K or more proof-of-concept vehicles into systems with consumer-acceptable price tags. Societal changes will be widespread, and will impact many aspects of modern life: liability of autonomous driving systems, human adaptation/dependence/skepticism, municipal infrastructure changes to roads and parking, shifting car-ownership/car-sharing models, occupant-less courier and taxi vehicles, changes to (or phasing out of) existing mass-transit systems, new charging/fueling infrastructures, etc. Technologies and software are needed for all of these aspects of the autonomous revolution, not just the pieces going into the car.

Santo, Freescale: The self-driving car, a chimera only ten years ago, is now within reach. The need for such mobile systems is evident and goes behind simple comfort during traffic jams. It helps enable a new model of life with more and more people spending long parts of their day in a commuting parade and increasingly needing to find time for themselves or their work. Google opened up the competition by accelerating the race toward the perfect self-driving car. Now manufacturers ranging from Audi to Daimler and other OEMs are in the game to win and convince consumers that it is possible to let a car drive us, within solid technical and legal boundaries. Much remains to be done but the first step is clear: integration of fusion with front vision (which has already started) and secondly, active 3D surround sensing and seeing. Lots of legal issues still need to be considered and resolved, but the impossible is now possible…actually probable.

Kurisu, Mentor Graphics: We’ve already discussed a few of the essential components including GPS, DSRC and ADAS technologies. Additionally, the self-driving car depends on advanced mapping, radar, laser and imaging technologies. Navigation information must include current and precise data, covering local traffic, construction and emergency vehicle activity for example. These systems also will need to be capable of computer vision leveraging very powerful signal-processing, image-mapping and decision-making algorithms. Security technologies to ensure safety will need to be designed into the vehicle and infrastructure. All that being said, the increasingly rapid innovation of microprocessors, GPUs, FPGA fabrics, hardware devices, connectivity and software makes this a realistic vision. These technical advances bring enormous computing power into the automobile, and enable consolidation of functionality into fewer, more powerful computing systems. Are we ready for the self-driving car? Not today, but I eagerly anticipate my first ride in one!

Valiton, Atmel: According to a survey conducted by ORC International, only 18 percent of consumers said they would consider buying a self-driving car.

Despite this survey, we believe consumers do not have a full understanding of self-driving cars. There are a number of technologies today that are baby steps towards a self-driving car (think automatic braking). One example is the safe park, where the vehicle parks itself. Another example is autopilot, a system used to guide a vehicle without assistance from a person, developed in 1912. Autopilots are used in aircraft, boats (known as self-steering gear), spacecraft, missiles and other vehicles.

However, if you think of an aircraft with autopilot, it still requires human intervention—a pilot and a co-pilot—to ensure that if anything is amiss, they can be sure to steer the plane to safety.

With self-driving cars, drivers will have the option to set the car in drive and not worry about a long trip or traffic. Similar to cruise control, the self-driving car can be turned off or if there is an emergency, the driver can still have full control of the car.

However, with strict automotive standards currently in place, to make this idea a reality, hardware and software must work closely together to achieve a safe and reliable self-driving car and one that is not hackable. Embedded technologies such as microcontrollers, sensors and touch solutions, encryption and even technologies such as 3D scanning are already in place to enable an autonomous vehicle.

We are ready for self-driving cars; the real question is whether both manufacturers and drivers are ready to embrace it.

 


Cheryl Berglund Coupé is managing editor of EECatalog.com. Her articles have appeared in EE Times, Electronic Business, Microsoft Embedded Review and Windows Developer’s Journal and she has developed presentations for the Embedded Systems Conference and ICSPAT. She has held a variety of production, technical marketing and writing positions within technology companies and agencies in the Northwest.

Smart Antennas Drive Evolution in M2M and Automotive Applications

Monday, October 7th, 2013

Smart antennas provide the capability to co-locate the antenna and black-box functionality for better performance and lower cost.

The power of machine-to-machine (M2M) technology is driving towards a more connected world. All kinds of machines are getting connected to the Internet of Things to deliver the promise of enhanced productivity and to bolster the performance of businesses.

The evolving realms of technology are revolutionizing many industries. The automotive industry is trending towards intelligent cars that are fully connected in order to achieve vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication for improved safety. Fleet management companies are utilizing M2M systems to monitor operational performance and service efficiency using real-time fleet tracking. Smart technology is enabling improved supply chain systems in industries such as vending and service.

Reliable non-stop connectivity requires that these systems support a wide array of wireless capability. This means machines are getting packed with Bluetooth, Bluetooth Low Energy (BLE) and Wi-Fi for personal or local network connection; Cellular protocols such as 2G, 3G, 4G and LTE for wide-area network connection; and global navigation satellite systems (GNSS) such as GPS, Galileo, Glonass and Beidou to support location-based services. This demand for added capability pushes toward higher system-level sophistication which can create challenges.

Challenges of Traditional M2M Systems

Traditionally, embedded M2M systems come with a black box containing connectivity features, control circuitry, power supply circuitry, wireless radios and other functions. The black box then connects to the bus system and/or a power source within the machine to allow the M2M system to run. Many connected machines in the field are metallic (examples include vehicles, vending machines, generators and containers). On these metallic structures, the antenna for the M2M system must be installed on the outside of the machine to maximize the system performance. As such, the antennas for the M2M system are in a different physical location than the black box and are connected to the black box via RF cables (as seen in Figure 1).

131007_automotive_1
Figure 1: Vending machine in a traditional M2M system

Even though this architecture is used on many M2M systems, it poses several potential system concerns. First, RF cables inherently have loss; the longer the cable, the more antenna gain lost between the black box and the antenna negatively affecting system performance. Second, there are two cost implications. Running multiple RF cables increases the total cost of the system, especially if the distance between the black box and the antenna is large. Additionally, as more technology gets added to the M2M system, more cables need to be run, which also adds cost and complexity. Finally, with more cables and more connectors within the system there are increased installation costs and higher risk of intermittent connection failures. For example, in heavy equipment and automobiles that are prone to vibration, there could be higher instances of connector or cable damage resulting in loss of data.

Smart Antennas Maximize Efficiency, Minimize Cost

One way to reduce system cost and improve efficiency in embedded M2M applications is to re-think the architecture of an embedded M2M system. Instead of depending on the black box to perform all of the critical tasks of the system, a system designer could pull the wireless portion of the design in to the antenna. This concept can be referred to as a smart antenna design.

131007_automotive_2
Figure 2: Smart antenna architecture for vehicle

Smart antennas provide an option to co-locate the antenna and some of the black box device functionality (mainly radios) into the antenna package. A single digital cable can then be run from the smart antenna to the depopulated black box. See Figure 2 for an example of how a smart antenna could be architected to work in a vehicle environment.

The embedded M2M system then becomes more efficient as the loss of data between the antenna and the black box is minimized with a digital cable versus multiple coaxial cables. Digital signals can utilize error-correction software and are more resistant to electromagnetic noise and signal attenuation than analog signals. Additionally, cellular systems are evolving quickly and other wireless standards continue to get updated. Customers not only want to upgrade their systems from 2G to 3G and 4G but also want to add the most cutting-edge wireless functionality (i.e., BLE and Wi-Fi Direct). When the technology evolves, it drives hardware and software changes. These hardware and software changes then need to be re-validated and re-certified. By moving the wireless functionality into the antenna, the core black box no longer needs to evolve as quickly as the wireless market pushes. The smart antenna can truly act as the data pipe and the black box can focus on its key functionality.

131007_automotive_3
Figure 3: Example of smart antenna for vending machine

Finding the Right Fit

While a number of market players provide smart antenna solutions, not all of them are successfully able to address all of the challenges. Getting the design right is the first step.

Because the smart antenna packages additional components into the antenna, the size of the smart antenna may be larger than a regular antenna. Space and styling constraints on certain equipment will not allow larger smart antenna packages than typical antenna sizes. For instance, the styling of a vehicle is very important to vehicle OEMs. It is critical that the smart antenna is created with the customer’s or system integrator’s guidelines in mind.

Depending upon where the smart antenna is located on the subject equipment, there could be more stringent environmental challenges. Electronics that were once hidden inside of the equipment are now located outside of the equipment in the antenna package This may create additional challenges with temperature, humidity, water ingress or a variety of other environmental factors.

Moving the radios from the black box into the antenna could pose firmware challenges. Typically the black box has been seen as the brain of the system with the antenna being the afterthought. When moving some of the electronics away from the black box to the antenna, it is critical to understand how information will be passed from the smart antenna to the black box. No longer is there just an RF signal coming from the antenna. Depending on the complexity of the smart antenna design, there could be RF data, location data and machine bus information passing over a digital line. In this case, there will be some firmware required within the smart antenna. If these issues are not addressed correctly during the system design phase, persuading system integrators to adopt smart antenna architecture will be a challenge.

Although challenges exist, the adoption of smart antenna technology in to the embedded M2M system space could lead to more efficient systems for companies looking to maximize performance while controlling initial capital expense and long term system evolution costs.


furr_jason

Jason Furr is global sales manager for Laird, where he focuses on generating new business in the growing telematics & M2M markets. Jason holds a bachelor’s degree in business from The University of Michigan-Dearborn and an MBA from Michigan State University.




dharmarajan_vidhya

Vidhya Dharmarajan is a technical writer for Laird, where she is responsible for creating, refining and maintaining product documents and writing white papers, market research and competitor analysis for the Telematics business group. Vidhya holds a master’s degree in VLSI Design from San Jose State University in California.

Automotive Ethernet Moves to the Fast Lane

Monday, July 8th, 2013

The consortium’s objective is to help producers of BroadR-Reach devices and auto manufacturers bring their products to market faster, while ensuring there is broad market appeal for devices through interoperability and conformance testing and demonstrating product readiness.

The University of New Hampshire InterOperability Laboratory (UNH-IOL) recently announced the launch of the Automotive Ethernet Consortium, which hopes to pave the way for semiconductor companies to address automotive industry requirements for next generation in-vehicle networking. We talked to Dave Estes, Ethernet manager and research and development engineer for UNH-IOL, and Jeff Lapak, UNH-IOL senior manager for Ethernet technologies, to get more background and to understand what the announcement means for developers of embedded automotive systems.

First, some background. A year ago, the OPEN Alliance (One-Pair Ether-Net) Special Interest Group (SIG) was announced by Broadcom, NXP, Freescale and Harman International, along with founding automotive members BMW and Hyundai, to encourage wide-scale adoption of 100Mbps Ethernet connectivity as the standard in automotive networking applications. The approach is based on Broadcom’s BroadR-Reach technology to allow multiple in-vehicle systems (such as infotainment, automated driver assistance and on board-diagnostics) to simultaneously access information over unshielded single twisted pair cable. By eliminating shielded cabling, the group expects automotive manufacturers can significantly reduce connectivity costs and cabling weight.

121002_cc_1
Figure 1: Broadcom’s BroadR-Reach® Ethernet solutions power the next-generation connected car. Image provided by Broadcom Corporation

UNH-IOL is the first laboratory to be endorsed by the OPEN Alliance to provide neutral testing for the BroadR-Reach standard, but is no stranger to this approach: the lab was founded in 1988 to do Ethernet 10Base-T testing. The lab employs about 100 undergraduates and 10 graduate assistants, plus about 20 full-time staff members, and has 20-22 consortia doing testing for different technologies at any given time. Consortia membership varies from year to year, but the lab typically works with more than 200 companies. These organizations’ year-long memberships allow access to testing and equipment throughout the year. While the lab is affiliated with the University of New Hampshire, all projects are funded by industry through membership and testing fees. The lab is active in IEEE 802.3 working groups and the Ethernet Alliance.

121002_cc_2
Figure 2: Representatives from companies participating in a University of New Hampshire InterOperability Laboratory (UNH-IOL) plugfest assemble at the laboratory in Durham, New Hampshire.  UNH-IOL plugfests allow participating companies to test their products and identify interoperability issues early, speeding go to market time for products.

For embedded developers of automotive systems, the lab offers the confidence that Ethernet-based products are interoperable and conformant to the customer’s expectations. Developers should be able to reduce time to market by having an existing set of test beds available for them to come in and test against, as well as the potential competitive advantage of an Ethernet-based system that is proven compliant and interoperable. The lab is careful to maintain third-party independence and neutrality to make sure that even direct competitors can use the lab for testing, knowing the results will stay completely confidential.

lapak_jeff

According to Jeff Lapak, auto manufacturers who are part of the Open Alliance are looking towards Ethernet as the way of the future. Most of the big automotive players are consortium members, including BMW, Mercedes, Volkswagen, GM, Ford, Hyundai and Toyota, and new members are joining all the time. Although testing is currently only available to semiconductor companies, the UNH-IOL plans to open membership to parts suppliers and automotive manufacturers as adoption of the BroadR-Reach standard progresses. Dave Estes provided the following responses via email.

EECatalog: What was the objective for establishing the Automotive Ethernet Consortium? What does “success” look like a year from now? Five years from now?

estes_dave

Dave Estes, UNH-IOL: The objective is to help producers of BroadR-Reach devices and auto manufacturers bring their products to market faster and to ensure there is broad market appeal for these devices through interoperability and conformance testing and demonstrating product readiness. In a year we hope to have several members including semiconductor companies, parts suppliers and auto manufacturers. Success would also mean having tested a reasonable number of products and showing proven interoperability. In five years we hope to have even more members and to be testing the next generation of in-car Ethernet being standardized by the IEEE, which is called Reduced Twisted Pair Gigabit Ethernet (RTPGE).

EECatalog: Are there key semiconductor (or other technology) vendors who are taking alternative approaches?

Estes, UNH-IOL: I am not aware of any other Ethernet technologies that are targeted for the automotive industry. There are several other in-car technologies that vendors may be invested in. Additionally, not all vendors will have become members of our consortium at this time, as it is still in an early-adopter state.

EECatalog: How will this group interact with other relevant in-vehicle networking standards groups, such as the IEEE 802.3 Ethernet Working Groups?

Estes, UNH-IOL: This group will be actively participating in the IEEE802.3 RTPGE working group which is defining the Gigabit Ethernet PHY that is expected to be used in the automotive industry. We will also be working with the OPEN Alliance and the AVnu Alliance.

EECatalog: What’s holding back the broad use of Ethernet in in-car networks? What issues still need to be addressed?

Estes, UNH-IOL: Prior to BroadR-Reach, Ethernet was not widely used in in-car networks simply because the auto manufacturers had to use shielded cables to meet the automobile EMC requirements. Shielded cables are heavier and more expensive. BroadR-Reach is able to meet the EMC requirements over a single unshielded twisted pair, saving weight and cost. Additionally there was no alliance or forum that had formed to select a single automotive Ethernet standard, therefore the market could not easily select a single approach. As for issues that still exist, this is the main reason we launched our effort. At this point a standard is selected and the technology will be adopted faster by proving that it works.

EECatalog: How will the migration from multiple “closed” systems to a single Ethernet-based network play out for developers? Are there challenges they’ll need to address as this evolution proceeds?

Estes, UNH-IOL: By using a standardized version of Ethernet and proper testing, auto manufacturers will have access to a wide variety of products from multiple suppliers while guaranteeing that the networking interfaces will work together. However as in all technology deployments, each individual auto manufacturer will need to address how best to migrate into using this technology.

EECatalog: Some of the advantages of this standard include more cost-effective safety and driver-assistance applications as well as advanced power savings that may be especially important for electric cars. What other opportunities for innovation do you expect to see as this approach gains momentum?

Estes, UNH-IOL: Some other advantages are reducing the weight of the cable harnesses in cars, which should reduce cost and increase performance (fuel-efficiency). Also the nature of Ethernet networks means that by using packet switching an appropriate amount of bandwidth can be allocated to different systems. There are far too many other potential applications to comment on what may be actually developed (car safety systems like radar, cameras, infotainment systems, drive-by-wire, etc.).

EECatalog: There’s already a lot of talk about security concerns with connected cars. Is that an issue you’re addressing?

Estes, UNH-IOL: This issue will not be immediately addressed by our Automotive Ethernet Consortium; however this is an area that we can explore in the future because our lab has a lot of expertise in security protocols such as MACsec and IPsec. Also currently this technology is a wired solution; connected cars, on the other hand, I believe refers to wireless communication between vehicles, which is not currently part of this effort.

EECatalog: Are there any common misunderstandings about the consortium’s approach that you continue to run into? What questions do you find yourself answering regularly (or not often enough)?

Estes, UNH-IOL: The common misunderstandings are very similar to what we would have in any consortium. They generally revolve around the membership model, although we also offer pay-per-test services, and how they can access our test bed. There are also general questions about what kind of products we can test.


coupe_cheryl

Cheryl Berglund Coupé is editor of EECatalog. com. Her articles have appeared in EE Times, Electronic Business, Microsoft Embedded Review and Windows Developer’s Journal and she has developed presentations for the Embedded Systems Conference and ICSPAT. She has held a variety of production, technical marketing and writing positions within technology companies and agencies in the Northwest.


Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.