Automotive E-mag June 2015

embedded-computing.com/topics/automotive

2015 | Voume 2 | Number 1

Ensuring code quality for the automotive ď • PLUS On the cusp of change: IoT revolution Interview with Stefan Skarin, IAR Systems

Growth and evolution in the ADAS market Q&A with Derek Kuhn, QNX Software Systems

Sponsored by: IAR Software, QNX Software Systems, Rogue Wave Software, and Microchip Technology

2015 | Voume 2 | Number 1 embedded-computing.com/topics/automotive

Featuring

Driving cars and their wireless communication forward

By Rory Dear, Technical Contributor

Autonomous vehicles on the road: Delphi and Tesla Motors

By Monique DeVoe, Managing Editor

A holistic approach to V2X and autonomous driving

By Brandon Lewis, Asst. Managing Editor

The automotive Internet of Things revolution Interview with Stefan Skarin, CEO, IAR Systems

On the cusp of change: Growth and evolution in the ADAS market

Interview with Derek Kuhn, Vice President of Sales, QNX Software

Software as a process: Is your software supply chain secure?

By Rod Cope, Rogue Wave Software

Optimal solutions for innovation in the car of the future

An application brief from Microchip Technology

Sponsored By

Š 2015 OpenSystems Media, Š Embedded Computing Design, All registered brands and trademarks within the Automotive E-mag are the property of their respective owners.

#EmbeddedTechCon

TechCon

®

June 8-10, 2015 Moscone Center San Francisco, CA

Co-located with the Design Automation Conference Embedded TechCon, designed to educate today’s design engineers in the most critical embedded product and technologies, will be held at the Moscone Center in San Francisco, Calif., on June 9-10, 2015. The live event extends OpenSystems Media’s current online educational program, Embedded University. The classes, which will be taught by leading industry experts, will cover key embedded topics like IoT, automotive, and security, while drawing from the industry’s roots with topics like firmware development, debugging, and open source hardware and software.

Classes, speakers, schedules, and more at :

embeddedtechcon.com

Vehicle Networking/Communications

Driving cars and their wireless communication forward

By Rory Dear, Technical Contributor rdear@opensystemsmedia.com

The self-driving movement is gaining traction due to relaxed UK regulations, and so is the wireless technology that is behind this revolution.

Whilst the self-driving vehicle movement gains traction daily, the pace of implementation of this exciting revolution in the U.S. is hampered by strangling regulation and red tape. Laws governing the opening up of roads in the U.S. to selfdrive testing are determined at state rather than federal level, so a patchwork of ambiguous and contradictory rules exist either side of state lines. The public naturally remains nervous in handing over control of their steering wheels to a “computer,” and necessary long-distance testing is restricted by the state of U.S. regulations.

Conversely, the UK has taken the opposite approach. By this I do not mean any regulation at all as the automobile industry will always be life critical; our Department of Transport puts it beautifully, “The aim is to achieve a light-touch, non-regulatory approach which provides the clarity industry needs to invest in further research and development while maintaining safety”. Major car manufacturers invested in self-driving are now flocking to our shores and new players are getting in on the scene like Google, or even Apple.

4

With EmbeddedWorld 2015 a mere fortnight ago, this got me thinking about how the wireless protocols on show fit within the vehicular space, in fact some new protocols are even designed exclusively for this upcoming metamorphosis of our daily vehicles.

Intra-vehicle The need for intra-vehicle (in-vehicle) communication is born primarily from the expense and complexity of the current wiring loom – in a typical car this equates to around 5 miles of wiring! For vehicle manufacturers, specifying, purchasing and installing this vast array of copper massively impacts build times and, of course, cost. For car owners that have had suspected issues with their vehicle’s wiring loom, they’ll also know this complexity corresponds to titanic repair bills!

Tomorrow’s vehicles will do away with this predominantly CAN bus driven wiring loom, abolishing the “fly-by-wire” system popularized by aircraft and once the height of technology with a “fly-bywireless” – a term I hoped I’d just coined but it transpires not...

Vehicle Networking/Communications

Protocols you’re probably already familiar with are fighting for implementation within this sub-application, including IEEE 802.15.1 (Bluetooth), IEEE 802.15.4 (ZigBee), and IEEE 802.15.3 (UWB) – with varying ranges, bandwidths, and associated costs. As the land lies today UWB stands most cost-effective at $1 per chip, with ZigBee and Bluetooth at $2 and $5 respectively.

This would suggest that UWB is being deployed en-masse, but actually it appears Bluetooth, as the proven technology with voice and data transfer capability, will be the first to appear. Expect to see hybrid systems with localized wired clusters first emerge. There are also some fundamental concerns relating to wireless interference that must be satisfied before this is truly implemented – when controlling vehicle functions this is inherently more safety critical than the following two categories.

Inter-vehicle (V2V) Scenarios benefiting from V2V communication range from peer-to-peer arrangement of safe distances in motorway convoys to warning vehicles of a road traffic collision up ahead. Today V2V communication is restricted to warning lamps of potential danger, but tomorrow’s selfdriving vehicles must also take action.

A seamless combination of Wi-Fi (802.11P/AC), DSRC, and LTE are likely to be combined to produce the reliability and information integrity that is required to trust onboard computers to prevent collisions in fast moving traffic.

Naturally given the opportunity for a malicious party to cause such catastrophe by injecting rogue data, it’s critical that a combination of protocols, rather than purely the vehicles own P2P mesh, provide that redundancy to cross reference reported information – and all in fractions of a second else it’s too late!

Vehicle to infrastructure (V2I) Whilst vehicles’ satellite navigation systems are increasingly supporting 3G/ LTE access to provide traffic information, the connected infrastructure revolution connecting vehicle to roadside will increase bandwidths substantially using the 63 GHz band, enabling passengers in self-driven vehicles to work remotely, browse the web and video conference whilst on the move even in heavy traffic. The bottleneck of stopping for toll booths will also become a thing of the past with V2I allowing that transaction electronically at motorway cruising speed.

Self-driving cars may be tomorrow’s technology, but you can observe the wireless infrastructure appearing today.

Tracking Trends in Embedded Computing  embedded-computing.com/ magazine/tracking-trends-inembedded-technology

 @RoryDear  linkedin.com/profile/ view?id=75295562

5

Autonomous Driving

Autonomous vehicles on the road: Delphi and Tesla Motors

By Monique DeVoe, Managing Editor

It’s an exciting time for autonomous driving. Delphi’s Roadrunner automated driving vehicle recently completed a ~3,400 mile drive from San Francisco to New York City – a trip the first of its kind, the longest autonomous driving trip conducted yet. On completion of its journey, Delphi says the car was able to navigate through the mountains, traffic, trucks, road construction, heat, and even a rogue tumbleweed.

The Roadrunner vehicle made its debut at CES 2015, where Delphi showed off its six long-range radars, four short-range radars, three vision-based cameras, six lidars, a localization system, intelligent software algorithms, and a full ADAS suite.

Images and videos highlights of the drive are available at the Delphi site.

6

Autonomous Driving

Autonomous vehicle testing is amazing to see, but also exciting is the idea that very soon we’ll have autonomous driving features on vehicles already on the road. Last month real-life Tony Stark and CEO and Chief Product Architect of Tesla Motors Elon Musk says Tesla’s upcoming 7.0 software update this summer will allow Model S vehicles to drive autonomously.

Lucky Model S owners won’t be able to completely ignore the wheel, gas pedal, brake pedal, and roads on their way to work the morning after the software update, but some important baby steps will be available.

The “autopilot” mode will allow hands-free highway driving, summoning of the Model S with a smartphone, and self-parking in garages. These features will be added to Tesla’s toolbox of active safety systems – emergency braking, blind spot detection, front/side collision warnings, and lane assist (I believe an actual lane keeping feature will be coming out soon... Tesla Model S owners – feel free to confirm or correct!). Evan Ackerman at the IEEE Spectrum has an interesting point that the low-speed abilities of Tesla’s upcoming updates are actually the more unique autonomous driving feature to come out.

It’s questionable whether these features are technically legal – Tesla says their system doesn’t conflict with current regulations – but as long as drivers are vigilant in making sure their vehicle is behaving they can probably get away with it. Just don’t drink and autopilot yet – features that allow for all the sticky situations of city driving home from the bar aren’t ready yet! Tesla spokesperson Alexis Georgeson and Elon Musk himself have reinforced that drivers need to be paying attention – they’re still at fault if something goes wrong – they can’t blame the autopilot.

We’re still a ways off from completely autonomous vehicles, but it’s very exciting to see the automotive industry taking these steps to get autonomous driving features actually functional out on the road. I’m still saving up for my Tesla Model S or waiting for the more affordable model, but hopefully soon the basic autonomous functions are widely available. Though many people don’t trust a computer to drive, I think the roads will be a much safer place when the vehicle’s many sensor and safety systems can take over.

Embedded Computing Design  embedded-computing.com/topics/automotive



linkedin.com/profile/view?id=68881514

7

Autonomous Driving

A holistic approach to V2X and autonomous driving

By Brandon Lewis, Assistant Managing Editor

While much has been made of the potential of autonomous vehicles, a great deal less attention has been given to the underlying infrastructure on which driverless cars will someday commute. Vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) technology, collectively known as V2X, will serve as the foundation for transportation paradigms of the future, facilitating communications between vehicular subsystems, multiple vehicles, and vehicles and their surroundings to improve road safety, alleviate traffic congestion, reduce fuel/energy consumption, and enhance the overall passenger experience. Today, embedded software and networking vendors are working to realize that vision.

In many ways the recent releases of autonomous concept vehicles by the likes of BMW and Mercedes are putting the cart before the horse; though the achievements of Google’s driverless car are undeniable, they provide only a small snapshot of what is required for a fully autonomous transportation infrastructure.

Much more than these isolated glimpses of the future, a holistic deployment of vehicle-to-vehicle and vehicle-to-infrastructure, or V2X, technology will be required to drive autonomous cars from test labs and controlled environments to mass market adoption on the open road.

8

V2X architectures consist of elements that span all tiers of the automotive industry as well as network infrastructure (from in-car devices and applications to the cloud), and stitch together sensor information and big data with seamless connectivity to form systems of systems amidst the transit base.

Though still in its early stages, V2X is the product of decades of evolution in the automotive sector, and is now reaching a tipping point in industry and government that will help usher in a new era of automobiles and connected transport, says Meg Divitto, Vice President of Future Solutions and Technology

Autonomous Driving

within the Internet of Things group at IBM (www.ibm.com).

“As it relates to the growth of the automotive industry, it was a mechanical system that had some control logic in the early days,” Divitto says. “That moved to a mechatronic system in the 80s and 90s, which meant that it was a mechanical-electrical system that had many more electrical things going on in the automobile – from using a push button door lock to an electrical one, to use a very simple example. All of a sudden there were more electronics, and then the era of software in the car during the 90s. Software started becoming more sophisticated and moving from basic control logic to sophisticated modules and devices, and then everybody went function crazy.

“So you saw content coming in the vehicle at rapid rates, and automotive manufacturers, due to having individual architectures and no standards, were bolting things onto the vehicle just to put things on,” she continues. “And everyone’s heard this, but there are more lines of code in a car than in a jet fighter, primarily because it’s not architected and modules are being bolted on. This is causing a huge amount of complexity as it relates to software quality and the quality of the vehicle.

“As you look at that progression you say, ‘Okay, we have to do things differently,’” Divitto explains. “There’s been a movement to go from this kind of vehicle architecture to a functional architecture.

Some OEMs turned their designs on their heads starting in the 2000s to be able to go to a functional architecture

where you lay out the architecture and the partitioning of the vehicle modules in a way that makes sense and doesn’t allow this big hairball of code; AUTOSAR was born in 2004 to handle this and have all the OEMs come together around a standard, functional vehicle architecture that could provide common requirements for suppliers so that common methodologies could be used to build, rollout, test, and certify.

“But if you understand that, now enter the next wave, which is telematics,” she says. “Now, vehicles are connecting to each other and the infrastructure, and there’s far more complexity. My view of the industry is that this is going to cause a tipping point where architectures are going to have to go back to an abstraction layer methodology where you abstract basic mechanical, mechatronic, and software functions from all of the other things associated with telematics, the connected vehicle, and V2V. Once that tipping point occurs we’ll be able to see a different progression of the technology and a different progression of the way in which complexity is solved. That’s when things will be done more harmoniously.”

A holistic approach to V2X As the progression of automotive technology continues, one area in particular is helping fuel the development of V2X architectures – electronic control units (ECUs). With the advent of massive multicore processors, ECUs are evolving into domain controllers that provide more performance for advanced applications in the connected car, and enable more fine-grained control over various vehicle subsystems. Though on the surface this

9

Autonomous Driving could be perceived as a very small cog in the V2X wheel, advances in hardware technology are opening paths to innovation in software and the communications infrastructure that will serve as gateways to the connected vehicle, says Artur Seidel, Vice President of Elektrobit Automotive Americas Inc. (automotive.elektrobit.com).

“We’re currently in the early stages to get to that final goal, but the way we look at the final goal is that one has to take a pretty holistic approach to V2X,” Seidel says. “Currently when you look at some of the stories in the media where there was a system that was heavily hacked into, it tends to be a single system that was bolted somewhere to the car, added to the system. But the system itself in the car wasn’t built with connectivity in mind, so there has to be a holistic approach ­– that looks at the hardware, that looks at the software, that looks at the communications.

“Ultimately what we’ve seen, if you look a few years back, is that there have been lots of small ECUs that don’t have a whole lot of performance,” Seidel continues. “Now, things are shifting towards what we call domain controllers, which are much more powerful, and we see that for example in the driver assistance space; you saw at CES that NVIDIA launched a 256-core CPU called the X1, and that’s going to be used in driver assistance applications.

Now you have a domain controller with all these cores, so how do you now have a software layer on top of that that takes advantage?

“Elektrobit is very active in AUTOSAR, and we have a secure OS called the EB tresos Safety OS that in essence assigns functionality to these cores in different safety levels based on what the function is (Figure 1). That’s the software piece, and the third piece of course is the communications piece, and we envision a non-symmetric encryption like public key or private key, not just from the car, but from outside and between components within the vehicle. This is a combination approach, and it’s going to be a step-by-step approach to get there, but ultimately we’re going to see these Figure 1 kinds of systems with powThe EB tresos Safety OS is part of Elektrobit’s automotive product erful multicore domains, suite and capable of providing different levels of functional safety secure OS software that’s depending on the application. been structured by safety

10

Autonomous Driving

requirements within the car, and then strict encryption to and from the vehicle,” he says.

V2X safety and security compliance Though the consolidation of multiple ECUs into fewer, more powerful domain controllers based on multicore silicon serves to reduce hardware cost and complexity, it also highlights security concerns that have plagued connected cars since their inception. Where today and in the past vehicle subsystems have been primarily controlled by a single ECU, when introducing connectivity for a particular set of applications running on the same domain controller that also manages safety-critical functions, you introduce the possibility of Internet-borne threats to the entire system. While malicious software that makes its way onto a smartphone or laptop can disrupt dayto-day activities, malware or corrupt files in the context of the connected car can cause catastrophic failures that result in the loss of life.

Despite the availability of safety-critical OS solutions, securely partitioning infotainment applications from steering or braking functions on a single CPU is top of mind for V2X developers, as it must be architected in a manner that complies with stringent automotive safety regulations and additionally account for security risks associated with Internet connectivity. As a result, automotive suppliers are increasingly turning to industry standards that provide best practices for V2X software development, and also help promote a uniform approach to safety and security compliance.

“One thing that has always been discussed as an inhibitor going back to the days of the telematics market is if a car has been driving down the road going 60 miles per hour and gets hacked, what happens? So there’s been a public phobia as it’s related to this space in the area of security,” Divitto says. “One way around that is through standards associated with the architecture of the vehicle that create an abstraction layer.

Like in an airplane where the core of the plane functions are black boxed, other aspects above the abstraction layer are features and functions that would allow the vehicle to be connected. When you start talking about creating that abstraction layer, much like in an airplane today, the infotainment system does not share anything with the operation of the plane – not the bus, not the communication, not the devices, not anything. That’s where we will get to as an industry because it creates separation where “what do you want to secure” and “how do you want to secure it” can be secured at two different levels based on the way certain systems need to interact with the world around them.”

“Once you connect a system of course you have the possibility of security challenges, such as hacks and so forth,” says Seidel. “Therefore, communications have to be a) encrypted; b) have to meet requirements for functional safety because only certain subsystems within the car will be able to receive these updates; and c) in the same way that you have very basic system checks in a non-connected car when you start it up, with connected, more complex

11

Autonomous Driving vehicles these checks will have to be more sophisticated, more elaborate – for example, if someone introduces incorrect map data, a connected vehicle that has sensors communicating with a V2I interface should have multiple ways of validating information.

“As we see more and more powerful ECUs, we’re going to now have to combine the compartmentalization of various vehicle systems onto one physical CPU, which gets into the requirement of combining a safety OS with infotainment functionality,” he continues.

“So how do you safely implement that compartmentalization?

manage complexity because it clearly defines requirements so that when I deal with an ASIL D system, I don’t feed anything through shared memory or non-encrypted access (Figure 2).”

Beyond implementing a secure software architecture between vehicle subsystems, developers of V2X systems are also faced with the challenge of testing and validating how connected cars interact with other vehicles and the environment around them. Not only are these validation efforts complicated by the millions of lines of code in modern cars, but OEMs and Tier Ones also face the fact that it is practically impossible to test all of the scenarios a vehicle could encounter on the road. In response, organizations such as ETSI and the Car2Car Communications Consortium are actively working to define compliance tests and test scenarios for connected vehicles,

“We use ISO 26262, and put a lot of effort into that,” Seidel continues. “To deal with this multicore approach, it comes back to the fact that this is not your smartphone software or PC software with one big software load. These are differently compartmentalized pieces of software, which helps manage complexity. With different Automotive Safety Integrity Level (ASIL) requirements, if I have a steering system that has a life-threatening ASIL D requirement, I would treat and compartmentalize it Figure 2 very differently than The EB tresos AutoCore is based on AUTOSAR 4.x and can be certified up I would a part of the to ISO 26262 ASIL D to help segregate safety-critical functions from noninfotainment system. safety-critical applications.

ISO 26262 helps

12

Autonomous Driving

while software vendors are turning to simulation techniques to help cut costs and speed time to market, says André Rolfsmeier, Lead Product Manager at dSPACE GmbH (www.dspace.com). ”V2X applications like intersection assistance, collision avoidance, or hazard warning systems are typically developed by means of a model-based design approach and tested by means of simulation,” says Rolfsmeier. “dSPACE provides dedicated tools for testing V2V and V2I applications by means of virtual test drives using open-loop and closedloop simulations (Figure 3). By means of this, ECU software can be tested in the laboratory using realistic scenarios, and the associated software maturity level can be improved before starting real test drives. This approach allows development time and cost in the automotive industry to be reduced considerably.

“In addition, dSPACE rapid prototyping systems are widely established in the automotive industry (Figure 4). These systems allow, for example, V2X applications to be developed in short iteration cycles and experienced directly in the vehicle,” Rolfsmeier adds.

autonomous vehicles, a more clear picture of their environment. Subsequently, V2X connectivity architectures often demand latencies under 100 microseconds, especially if applied in applications such as collision avoidance.

Currently there are several connectivity technologies that could be leveraged to facilitate the transmission of V2V and V2I data, however no definitive consensus has been reached on which, if any, will eventually be adopted on a national or global scale. This is driving industry

Figure 3 dSPACE virtual test drives enable testing of V2X applications by means of simulation.

V2X drives convergence in communications While V2V and V2I communications will not be used as the final control loop for safety-critical functions such as invasive braking, they will be essential for transmitting information about a vehicle’s immediate surroundings as well as upcoming road and traffic conditions that can be fused with other sensor data to give drivers, and someday

Figure 4 The dSPACE MicroAutoBox can be used to prototype V2X applications.

13

Autonomous Driving to investigate both established and emerging types of communication for use with connected vehicles, as the lack of government regulation could force automakers to support multiple wireless standards in the future.

“For V2V, and also partly for V2I, a direct, low latency ad hoc communication between devices is required as typically the associated applications are safety-related,” Rolfsmeier says. “V2V and V2I requires vehicles and traffic infrastructure such as traffic lights, beacons, and road work signs to be equipped with dedicated WLAN communication modules. Thus, if the introduction of this technology is not mandated, OEMs will have to think about business models and vehicle equipment options, for example by packaging V2V, V2I, and certain ADAS features together in one dedicated option.”

“In the U.S., EU, and Japan different automotive-specific WLAN ad hoc network implementations are used today, so there is no global standard,” Rolfsmeier continues. “V2V and V2I may be mandated in the US in the next couple of years, however a final decision has not been made yet. As matters stand today, administrations in the EU do not tend to regulate the introduction of this technology.”

“Currently outside of the vehicle it’s going to be 802.11p. That’s at least the standard around which people are planning,” says Seidel. “The good news is that’s the standard that’s currently being embraced by North America and

14

also Europe, but I’m also hearing that some of the cellular providers are starting to position what is called LTE Direct as an alternative. It’s early days, but this takes advantage of Wi-Fi and LTE modems, and we all know how fast those are advancing. So there we’ll see more options to increase speed and access to communication.”

“The harmonization of the individual automotive WLAN ad hoc network implementations is necessary to save development costs and time,” says Rolfsmeier. “Otherwise, automakers and tool suppliers like dSPACE might have to invest in all the different implementations if they intend to support V2V and V2I communication globally.

“We see regional-specific WLAN ad hoc network implementations as an intermediate solution for V2V and V2I,” Rolfsmeier says. “Vehicle-to-backend server (V2B) communication also seems to be an attractive use case for both automakers and car drivers. The associated V2B architecture consists of a 3G/4G LTE communication module in the vehicle, a backend server typically run by the OEM, and, for some features, an automotive cloud allowing the analysis and evaluation of thousands of vehicles using big data. In this context it is important to note that 3G/4G LTE is a common, non-automotive-specific worldwide standard, and associated communication modules will find their way into modern vehicles anyway due to the introduction of emergency call systems such as GM’s OnStar and BMW

Autonomous Driving

Assist. In addition, smartphones utilize 3G/4G, and a closer integration of smartphones in modern vehicles is imminent as well. Using mobile communication technology, vehicles are connected to backend servers in the cloud by means of which OEMs may provide specific services, over-the-air (OTA) software updates, or dynamic navigation data with the most recent information about maps, real-time traffic, road work, traffic signs, parking spaces, and other location-based services.

“Further, a new mobile communication network standard called 5G – the successor of 4G LTE – is currently being investigated,” he continues. “5G is supposed to be ready by 2020, and is said to also support low latency ad hoc device-to-device communication without requiring a mobile network supplier base station in between. If this comes true, 5G might be the technology of the future for V2V, V2I, and V2B.”

V2X and autonomous vehicles – A two-way street Though V2X architectures are still in their infancy, advances in technology, the evolution of standards, and collaboration across industry and government are converging to navigate the road to autonomous driving. Partnerships such as IBM and Continental’s Connected Electronic Horizon program, grassroots organizations such as Black Hat’s I Am The Cavalry (www.iamthecavalry.org), and industry consortia such as the Auto Alliance (www. autoalliance.org) are just a few examples of the synergies taking place around V2X technology in the automotive sector, the results of which are already being seen.

“At CES a term that was used by a few of the vendors was ‘swarm intelligence,’ Seidel says. “One of the applications that was shown by a few of the OEMs was parking space finders where a car used automatic parking to find a parking spot and automatic functions to leave the parking spot, and then communicated to other cars that there is now another parking spot available. So it’s not just a safety discussion, it’s an efficiency discussion – all of these things get enabled

by V2X. You don’t need an autonomous car to benefit from V2X, but V2X and autonomous driving go extremely well together because you can steer an autonomous car much better than a non-autonomous one.

“Of course this is a topic where just by definition you have to resolve the conflict of there being a need for standardization while at the same time there being a need for the OEMs to differentiate their products,” he continues. “I think we’re on a good track, and this will be accelerated as the benefits of V2X in combination with autonomous driving become more clear. V2X will be developed handin-hand with autonomous cars, and we’re definitely working with our customers in that space. In the next 10-20 years you’ll see these two develop in parallel.”

Automotive Embedded Systems  promos.opensystemsmedia.com/ ?automotive=april-2015

 @BrandonLewis13  linkedin.com/profile/ view?id=124006859

15

Automotive Internet of Things

The automotive Internet of Things revolution Q&A with Stefan Skarin, IAR Systems

The Internet of Things (IoT) represents a paradigm shift for auto manufacturers, as Internet-related safety and security concerns are a brave new world for vehicle systems that have historically been isolated and tightly controlled. This Q&A with Stefan Skarin, CEO of IAR Systems illustrates how today’s cars have begun moving into the IoT application space; discusses some of the challenges associated with Internet-enabling vehicles; and emphasizes the importance of functionality (both from a technical safety and industry mindset) in next-generation automobiles. he Internet of Things is everywhere now. How does the IoT relate to automotive?

T

If you look at the automotive industry today, a lot of applications are already connected and there are more to come.

The U.S. Department of Transportation recently announced that they will

Stefan Skarin, CEO, IAR Systems

16

bring forward legislation to make vehicle-to-vehicle (V2V) communications mandatory in new cars for safety reasons. This is really exciting and will bring new challenges as well as possibilities for the automotive sector.

Other applications you see that are not your typical automotive IoT but represent a new era in the car are ones that connect vehicles and the smart home. I read an article on a development platform for the NEST thermostat that gave the developer community access to the sensors and microcontrollers in the thermostat.

BMW used that to develop an application in the car that connects to the thermostat and opens the garage door when the car is in close proximity to the home.

There are also tons of different applications where you can post data that can be loaded into the vehicle. For example, today when you buy a new car you often get an app with it so you can compare fuel consumption,

Automotive Internet of Things

mileage, service, and almost anything else that has to do with the car.

Basically, the car is sending its data through the Internet itself. Another example is if you get an email on your smartphone and it’s a customer you want to visit, you create a calendar notice with the location of the meeting and when you get into the car the data about your meeting is automatically transferred to the car’s navigation system. This is a good example of the car being a gateway for information.

Location-based services are already applied to the automotive sector, so that you, for example, know where your car is if it is lost or stolen. Another area is identity recognition, where the identity of the car and identity of the drivers can be used to create customized keys for each driver so that one key can be turned off through an app – insurance companies are using this type of technology to recover cars or check mileage. These are good examples of the automotive industry generating a huge amount of data that can be used to protect, to secure, to communicate, to improve, etc.

at kind of challenges does h this more connected world pose for the automotive industry?

W

A couple of car manufacturers told me recently that cars have to live for 25 years these days, and that is not a mechanical problem anymore, it’s an electronic/application data problem.

The IoT is introducing a world to the automobile where traditionally there has been less demand for security, more memory usage because on the Internet there is plenty of memory, and a much more flexible environment in terms of what information you can present to the user. The challenge for developers is the fact that the car is still a vehicle that should be used to transport people, and not an entertainment system on wheels. It should be safe, and it should not be possible to reprogram or change the use of the car.

The biggest challenges are the security concerns and functional safety and all that comes with that, but also the different demands of the IoT versus the automotive industry. My impression is that within the automotive industry, projects are becoming more and more complex and development times are getting longer. The demand for shorter time to market is definitely there as well, so everybody wants to be more ready with their product in earlier and earlier phases. An automaker can have 200 developers on smaller projects and 2,000 developers on bigger projects for cars that will be released four years from now.

Some manufacturers predict this will equate to about 10,000 million lines of code (MLOC). We’ve seen some integration work where customers want maximum flexibility and maximum integration, and that’s quite tough when it comes to adopting automotive standards. This is where there is a major conflict between the

17

Automotive Internet of Things demands of IoT vers theus those of the automotive industry.

iven the vast amount of code involved in the modern vehicle as well as the desire for tighter integration, what types of tools are available to meet the needs of automotive manufacturers developing next-generation vehicles?

G

A clear trend we’ve seen is the need for code analysis and code quality control, including runtime analysis and static analysis. To meet these demands, we at IAR Systems have added tools to our product portfolio.

Of course, we have the normal set of tools we’ve been doing for the last 30 years – the complete development toolchain including compiler and debugger – but in the last three years we’ve also released functional safety versions of our tools both for the ARM environment and for Renesas environments. To be fair, what we still lack is perhaps more on the test tool side.

We have seen some demand from customers in the automotive industry for not only tools on the analysis side, but also to get software and protocol integration out of the way and get complete testing for their product.

But from a development point of view, we’re fairly fine, and the fact that we are completely independent in supporting most of the architectures out there is another added advantage. For example, a couple

18

of European suppliers want to move from 10, 11, or 12 different microcontroller architectures down to four or five. If they can use our technology and reuse code in their development efforts, they save a lot of time and money. That’s the key for us – to keep enough in the product in terms of performance but also to provide broad support for different MCUs. You can connect that back to the IoT because the IoT is not entirely an amazing new thing. In many ways it’s simply adding communication to an already developed application or product. In those cases, one challenge is what kind of communication protocol you should use. There are numbers of them depending on what you want to do (if you want to have Bluetooth or if you want to have Wi-Fi to get to the cloud, etc.), and then you have the security aspect as well.

That is something we’re also working on today: how to solve the communication piece for IoT. Apart from that, we will one day provide integrated testing tools for our customers.

hat do you see as some of the possibilities of the IoT in the automotive sector?

W

The increasing information flow is a huge thing. Vehicles will become a gateway for information into and out of the car. This will play a bigger role as cars are controlled more and more by something other than human drivers in order to prevent accidents and move efficiently around road obstructions.

Automotive Internet of Things

Safety and security is what’s holding this back for the automotive industry.

Car manufacturers are worried about the fact that the car is so full of features that it’s become distracting. Because we’re used to getting everything on our phones, we now want everything in the car: Facebook, emails, Internet, or whatever else. We want to be pinged when someone updates Facebook while we’re driving. All of these things are putting too much emphasis on the entertainment side without enough focus on safety and security. From my point of view, I would say that these issues will be resolved within the next 5-10 years.

our global automotive plan. That person is based in Japan since the automotive sector for us is largely driven by Japanese customers. To outline our complete offering will take some time, but the thing that will keep us on the right path is continuing to listen and focus on our customers and their needs. As I see it, the IoT revolution of the automotive industry has just started and I am sure that the future will bring many exciting possibilities for the market.

We at IAR Systems will always be there to support our customers as much as we can.

For IAR Systems, the biggest challenge is not on the technology side, it’s on the implementation and business model side. It’s a question of how to implement our technology into an environment that is more Internet-centric, that demands more security, and that is more flexible in terms of customization. The first step towards this is that we recently appointed a person responsible for

IAR Systems

Stefan Skarin is CEO at IAR Systems.  iar.com

 @iarsystems  linkedin.com/company/iarsystems

 facebook.com/iarsystems  youtube.com/user/ IARSystemsUSA

Watch Video

19

Advanced Driver Assistance Systems

On the cusp of change: Growth and evolution in the ADAS market Q&A with Derek Kuhn, QNX Software Systems and BlackBerry Technology Solutions

As current ADAS technology progresses towards piloted driving and, eventually, fully autonomous vehicles, conversation in the automotive industry has turned to the transition from passive systems to active control.

In this Q&A with Derek Kuhn, Vice President of Sales Derek Kuhn, VP of Sales, for QNX Software Systems and BlackBerry Technology QNX Software and BlackBerry Technology Solutions Solutions, he discusses some of the innovations in hardware, software, and the supply chain that will usher in a generation of selfdriving cars. e transition from passive h systems to active control is on the cusp of taking off. What is happening in the market that will move ADAS to piloted and self-driving systems?

T

It wasn’t that long ago that “vehicle safety” was restricted to passive systems, like airbags, with the focus on protecting a driver and passengers only after a crash had occurred. Today, however, that is changing. First, vehicle safety standards are evolving to a point where regulatory bodies are mandating ADAS systems in new cars. The U.S. National Highway Transportation Safety Authority (NHTSA) is evaluating the safety benefits of autonomous emergency braking, vehicle-to-vehicle (V2V) communications, and other technologies, and has already determined that by May 2018 all new vehicles under 10,000

20

pounds must have a rear-view camera.

Crash-worthiness comes with rewards as well: Consumers are increasingly paying attention to New Car Assessment Programs (NCAPs), which exist around the globe and include rewards programs that give vehicle models a safety rating and are now beginning to include results based on the use of scientifically proven ADAS systems.

Second, software and hardware advances are facilitating the move from passive to active autonomous control in the vehicle.

Sensors that are networked to communicate with one another over vehicle-to-vehicle and vehicle-to-infrastructure (V2X) communications will enable more comprehensive, reliable situational awareness for cars on the road. Advanced decision making algorithms will contribute to the sophistication of the self-driving vehicle’s response in complex surroundings, such

Advanced Driver Assistance Systems

as a busy urban intersection. Purposebuilt systems on chip (SoCs) are being developed that can support the activity of these smarter, consolidated multisensor systems in real time.

Last, but definitely not least, as ADAS systems come into the mainstream and proliferate throughout vehicle lines, industry standards are coming into play to ensure greater consistency and safety. The automotive functional safety standard ISO 26262, as well as software development, architecture and testing standards such as AUTOSAR, MISRA, and AEC Q100, are all criteria that must be considered — and, in some cases, are required — in the increasingly autonomous systems that auto manufacturers are putting into their vehicles.

a ny technologies must work in concert to facilitate a safe, feature-rich, and enjoyable driving experience. What developments in hardware and software are facilitating the growth of ADAS as a core part of the driving experience?

M

The automotive industry’s increasing interest in and adoption of advanced safety systems is a direct result of technological breakthroughs in ADAS over the past few years. Auto manufacturers are now seeing a level of maturity in these technologies that is spurring unprecedented research and development in ADAS-related hardware and software.

On the hardware side, the number and types of periphery sensors being

integrated into the vehicle is on the rise. It will not be uncommon to see upwards of half a dozen camera sensors, ultrasonic sensors, mid- and long-range radar, and LiDAR (which is gaining traction due to its compactness and cost effectiveness) in every car. However, the real benefit that comes from this vast assortment of amassed data lies in the ability of a centralized compute system to “fuse” the data in order to interpret the state of the vehicle and its surroundings more accurately. This fusion of data from multiple heterogeneous sensors ultimately allows the driver assistance system to make more reliable decisions. The combination of all sensor technologies working together will yield far better results than discrete systems operating independent of one another. Additionally, as mentioned before, the advent of new purpose-built SoCs that can support these multiple sensor technologies and handle the high data throughput in real time is a major advancement. This evolution gives automakers increased flexibility and control over how their ADAS systems are architected, and what features to include that provide a commercially attractive and differentiated system.

Software development is playing an equally important role in the proliferation of ADAS technologies across all vehicle segments. The move toward a centralized approach to ADAS means not only new hardware, but new software, too.

The software decision-making algorithms that represent the “brains” of the system will integrate numerous applications, such as forward collision warning,

21

Advanced Driver Assistance Systems traffic sign detection, pedestrian detection, and V2X communication. These systems could be required to analyze up to 1 GBps of data in real time in order to allow the vehicle to react intelligently to changes in its surroundings in only a fraction of a second. Extensive research is also underway to implement driver interfaces and driver-vehicle handoff software in the form of “assistive” user interfaces. This software must be able to anticipate a driver’s needs and provide the right subset of data at the right time. After all, the intent is to shield the driver from information overload as this could result in high cognitive workload, reducing situational awareness and countering the efficacy of ADAS.

i ght now, many auto manufacturers are integrating discrete ADAS systems together and moving towards active control of vehicles. What challenges are you aware of that they are facing, based on your involvement with the Tier 1 and OEM communities?

22

an entire new set of hardware and software requirements emerge. The trend towards using multiple data-generating sensors (cameras, radar, and LiDAR) places a large computing requirement on the ADAS system. In hardware, this requirement can be addressed by purpose-built accelerators on the newest ADAS SoCs. These advanced computing requirements are also pushing the limits of software design and software components that have traditionally needed to meet only the requirements of discrete ADAS systems. The challenge we see here is how to handle the high information processing loads expected of these next-generation systems while providing the requisite level of safety.

s a key player in the automotive supply chain and a proponent of innovation, what does QNX Software Systems believe is required take ADAS to the next step?

R

A

Tier 1s and OEMs face a number of driver interaction and system design challenges when moving to active control of the vehicle. If the vehicle provides some level of autonomy, such as traffic jam assist, then it becomes crucial to ensure the driver is able to take back control when necessary. This human factor must be designed into the system interaction to ensure a safe driving experience. From a technical design perspective, as ADAS moves from informational displays and alerts towards functional safety, then

ADAS systems have become too complex to be built by a single company; their success depends on a thriving marketplace of suppliers that provide software platforms, hardware, vision and sensor algorithms, the sensors themselves (vision, radar, LiDAR, V2V), cryptographic libraries, and other complementary technologies. A market with many competing suppliers can drive down costs — critical to widespread adoption of ADAS — and drive innovation. We’ve already seen this approach work in the infotainment market, where it has sped time-to-market and brought infotainment to mainstream vehicles.

Advanced Driver Assistance Systems

Consider, for example, the safety certification of ADAS systems, which is by nature a long, arduous, and expensive process. By using pre-certified components from reputable suppliers, ADAS development teams can reduce this effort significantly, minimize risk of project failure, and even achieve a greater level of safety. Also, in many cases teams can reuse pre-certified components, and their expertise in using those components, across multiple projects. The QNX OS for Automotive Safety, for example, has been certified for systems that comply with ISO 26262 up to ASIL D, which makes it suitable for a variety of ADAS systems, from PRNDL displays to parking assistance systems.

Of course, an outsourced supply chain can carry its own risks, including the potential for counterfeit or illegitimately repurposed components – unacceptable in systems designed to enhance

or ensure safety and security. There is, then, a growing need for members in the ADAS supply chain to use secure asset management systems (AMSs). These can provide secret key provisioning, serialization, anti-cloning, anti-counterfeiting, and other measures to ensure a safe and trusted ecosystem.

Derek Kuhn is Vice President of Sales for QNX Software Systems and BlackBerry Technology Solutions.

QNX Software Systems  qnx.com

 @QNX_News  linkedin.com/company/9889  facebook.com/ QNXSoftwareSystems

 youtube.com/user/QNXcam

Watch Video

23

Automotive Software Supply Chain

Software as a process: Is your software supply chain secure?

By Rod Cope, Rogue Wave Software The past year was a tipping point for the software industry, where the impact of code faults in the field were felt far beyond the limited confines of our own development teams. Widespread automotive recalls and events such as Heartbleed and GHOST hit home for all walks of life, linking real safety and security issues to the phrase “it’s a software bug.” There were plenty of good stories (the Rosetta space probe landing on a comet) to go with the bad stories (the Target data breach, costing shareholders $148 million), yet the overall responsibility is on the industry to do better.

To provide some context, in the past 10 years the number of data breaches in the United States has climbed steadily and will reach a predicted peak of 800 instances in 2015 (Figure 1). In the automotive industry, over 900,000 vehicles are affected by recalls each year, according to The Automobile Association in Britain. These trends

Figure 1 Security breaches continue to grow (Source: Identity Theft Resource Center, analysis: Rogue Wave IMSL Numerical Libraries).

24

Automotive Software Supply Chain

are not entirely surprising. As companies try to one-up each other with continual innovation and more features, with outsourcing overtaking in-house development, software complexity has gone far beyond our ability to find bugs effectively.

How defects are introduced The cornerstone of embedded development is software, and software is where most errors are introduced. Not only has the volume of delivered code increased, the complexity and variety of architectures, platforms, and protocols has increased too.

This pushes the number of permutations of state, behavior, interactions, and outputs well beyond our capabilities to test. And it’s not just the code What really amazes me is the sheer number itself; other influences have affected our ability to deliver of lines of code of software running on solid, reliable products:

“

all these electronic control units (ECUs), especially if compared to other products and computer software. A modern high-end car features around 100 million lines of code, and this number is planned to grow to 200-300 million in the near future.

– Andrea Busnelli

õõ

The software supply chain – Today’s software products are the result of many suppliers, vendors, open-source repositories, and legacy code coming together in a mix of different processes, standards, and cultures. Each input offers a chance to introduce safety, security, or performancerelated errors. While some integrators are good at enforcing consistent standards and quality guidelines, most struggle to achieve comprehensive testing across all inputs that fits into tight timelines and cost constraints. Trust and enforcement are the key differentiators when it comes to the software supply chain.

õõ

Changing the way we work – Whether it’s the shift towards agile continuous integration or the adoption of new standards, embracing new ways of developing software hits organizations where it counts: the delivered product. It takes time for teams to understand and normalize new processes and, for companies with limited resources, it’s very likely that either quality or quantity (or both) suffer.

When you add in the risks associated with different teams using different processes, the possibility of a defect reaching the field is even higher.

The Internet of Things – a relatively new source of increased complexity is the Internet of Things (IoT). No longer do software vendors have to worry only about their own products, they need to account for the potentially untested or unvalidated inputs coming from other systems as well. For example, the connected car opens up new opportunities for attacking automotive systems, such as remote connections through in-vehicle infotainment systems and wireless vehicle services.

õõ

25

Automotive Software Supply Chain

With these fault vectors and more, it’s no wonder that software bugs are making the headlines. The good news for automotive is that other industries have figured out strategies that can help stop defects from getting out into the open.

1. Adopt proven, accepted standards – While some industries are very familiar with coding and safety standards, others are just beginning to adopt them, recognizing that standards give valuable goals to achieve and measures of how to improve. Automotive companies have been using coding and safety standards such as MISRA C and ISO 26262 for some time now, but they are just starting to investigate how security standards can help protect against hackers. Adopting common, community-driven security standards such as the Open Web Application Security Project (OWASP), the Common Weakness Enumeration (CWE), and Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) are essential for both educating development teams on what makes code secure and measuring how secure their code actually is.

2. Understand open source – Most companies use open source to optimize their engineering costs without realizing the potential risks to security, technical quality, or licensing liability. Moreover, many companies may not even know where open source is used or delivered, as it’s fairly easy for any developer or supplier to include code without anyone knowing about it.

To minimize the risks, companies should adopt open-source policies and governance platforms that formalize the acquisition, provisioning, and tracking of open-source code. This helps eliminate inconsistencies in versioning and licensing and tracks where packages are deployed so issues can be isolated faster. Organizations can also adopt open-source scanning tools to identify where both the known and unknown packages are, identify potential risks, and better inform testing activities.

It’s also important to ensure that policies and tools are consistent across the supply chain, otherwise the weak link may give rise to an issue.

3. Find security flaws earlier – The threat of hackers, data loss, and system downtime persists across all industries, and, with the advent of more communications and connections, embedded systems are not as protected as they once were.

The challenge is two-fold: educating development teams on how code can be exploited and adding testing techniques to find potential security flaws before they’re released.

26

Automotive Software Supply Chain

The most important point to remember when it comes to security: be paranoid.

Don’t trust inputs coming into the system, place strict controls on suppliers, and ensure that all inputs are validated and restricted to protect code from malicious data and control.

One method that has proven to be successful in mitigating security risks is using automated code analysis to look for potential flaws. Capers Jones of Namcook Analytics found that, without tools such as static code analysis (SCA) in particular, developers are less than 50 percent efficient at finding bugs in their own software.

SCA is adept at understanding patterns and behaviors in code across multiple compilation units and developers to reveal security holes such as buffer overflows, suspicious incoming data, and unvalidated inputs. More sophisticated SCA tools can also compare code against common security standards such as OWASP and CWE to determine gaps in coverage or generate compliance reports. Rather than convincing teams to spend more effort on security testing, use tools to reduce the effort for you and your suppliers.

4. Deploy automatic, agile testing – The benefits of continuous integration and testing have proven to be effective for many organizations, allowing them to deliver more robust features at a faster pace. This is the result of putting the burden of common or complex development tasks onto tools that perform in the context of frequent check-ins and builds.

When switching from traditional testing methods to continuous integration, it’s critical to adopt these kinds of tools to keep defect rates low and developer frustration to a minimum. It’s also important for these tools to be as comprehensive as possible, testing not only for technical defects but security flaws and standards compliance as well. Using the static code analysis example, adopting a tool that covers all the programmatic, security, and standards bases and also fits into a continuous integration model means additional, more costly tools won’t be necessary.

5. Stay on top of things – Complementary to continuous integration is continuous improvement: how effective are these measures and how can they be made better? The first step is to establish metrics and develop reports that help track defect trends (both number and source), compliance to standards, and developer activities to better understand where the problems are and where effort is being spent. Ideally, this data is collected and reported automatically by the development tools so the teams don’t have to worry about it.

The second step is to monitor trends, issues, and activities regularly to be able to respond as quickly as possible. For open source, using a governance platform that alerts teams to security vulnerabilities in open-source packages is an effective method for identifying problems early and preventing flaws

27

Automotive Software Supply Chain from getting into the released product. This is especially important for open source as most developers don’t think twice about the robustness of opensource code and rarely subject it to the same rigorous testing as their own code.

The rapid growth in automotive complexity, connectivity, and the software supply chain emphasizes the importance of getting security, safety, and reliability under control as soon as possible. Embracing techniques and adopting tools that are proven in other industries will help create systems that stay out of the headlines and deliver a solid path for future innovation.

Rod Cope is Chief Technology Officer at Rogue Wave Software.

Rogue Wave Software  roguewave.com

  

@RogueWaveInc linkedin.com/company/rogue-wave-software facebook.com/roguewaveinc

 youtube.com/user/roguewavesoftware

Watch Video

28

Functional Safety

Optimal solutions for innovation in the car of the future An application brief from Microchip Technology, Inc. The automotive industry continues to be a challenging environment. Intense competition drives automotive OEMs to seek innovative solutions to differentiate their vehicles, which in today’s market are not only required to provide safe and reliable transportation, but must also offer the functionality to entertain, inform, and connect to the outside world. Advanced technology is required to enable the delivery of these new features without compromising cost and weight.

As automotive system suppliers race to address the rigorous and constantly changing requirements of automotive OEMs, the evolution of alternatives for the electrical/electronic (E/E) architecture also continues. The demands of global automotive customers create many new challenges and opportunities for innovation.

To meet these demands for the car of the future, E/E subsystem designs must command a broad portfolio of products, development tools, and development support that enable creative and advanced solutions in order for automotive OEMs to deliver vehicles that offer reduced fuel consumption and lower emissions, as well as a safer, more comfortable experience on the road for vehicle occupants. The starting point for these solutions: industry standards and functional safety.

Functional safety and ISO 26262 With their ever-increasing use in automotive designs, electronics play an essential role in vehicle operation, user convenience, and the protection of human life.

Given the widespread use of electronic systems in automotive applications, it can be difficult to understand how essential their correct operation is to the control of the vehicle. As long as these electronic systems work properly, the safety of the people in and around the vehicle depends primarily on the driver’s skill and driving practices. But what happens when the electronics malfunction and prevent the driver from maintaining proper control?

For example, an airbag may suddenly deploy while the vehicle is in motion, without being triggered by a crash. What if the driver doesn’t even know that the electronics are malfunctioning, as might be the case when the image is frozen on a rear view camera? All electronics are susceptible to random failures. Although the failure rate may be quite low for individual components, the incremental use of electronics in a vehicle significantly increases the potential for failures to occur. Most software engineers will also agree that eliminating bugs is becoming more difficult as software grows in size and complexity. Functional safety is the ability of an electronic system to detect when there is a fault, make the driver aware of the fault, and put the vehicle in a

29

MOST Technology: Infotainment and driver assist backbone Media-Oriented Systems Transport (MOST) is the accepted standard for high-bandwidth automotive multimedia networking. This synchronous network provides excellent quality of service and seamless connectivity for audio/video streaming through a variety of multimedia interfaces. MOST technology:

õõ õõ õõ õõ õõ

Uses a single interconnection to transport audio, video data, and control information Supports fiber optic, shielded, or unshielded twisted pair wires and coax as its physical layers Supports 25, 50, and 150 Mbps speed grades Provides an automotive-proven physical layer for Ethernet Supports a variety and combination of topologies: Star, daisy chain, ring

Sidebar 1 The Media-Oriented Systems Transport (MOST) architecture is an automotive industry standard designed to provide the highest possible bandwidth for invehicle multimedia applications.

30

mode that allows the driver to maintain safe control. Returning to the example of the airbag, the diagnostics should identify the fault, disable deployment, and turn on a warning light to inform the driver that the system is not working properly.

Recognizing the need to focus on the functional safety of electronic systems, the automotive industry has adopted ISO 26262, which is a derivative of IEC 61508. This automotive-specific standard applies not only to the design and test of E/E systems, but to the entire lifecycle of the product, from concept to eventual disposal and recycling of the vehicle. The implementation of ISO 26262 supports the ability of component suppliers, system suppliers, and automotive OEMs to discuss, evaluate, design, measure, and ensure an appropriate level of functional safety for E/E control systems.

Ensuring a functionally safe system requires a comprehensive analysis of the hazards and risks. A robust system design, development, and validation process is also required, with proper selection and usage of both hardware and software components. ISO 26262 defines a series of steps to assign an acceptable level of risk for a system, to minimize errors during the product development process, and to determine if the end product achieves the required level of functional safety. The utilization of this common standard also enables a team of people working together

Functional Safety

on a project who are distributed around the world to more easily discuss complex functional safety topics.

To ensure functional safety in automotive embedded designs – from electronic door handles to electronic steering systems – OEMs need the building blocks to create a system that

meets the most stringent requirements, as well as partners with extensive experience in creating robust applications that can deliver components with the right combination of hardware and software features, plus development tools, suitable for the most demanding automotive applications.

Partnering for automotivegrade quality assurance An ISO/TS 16949-certified supplier since 2003, Microchip Technology supports various automotive quality initiatives, including:

õõZero defect õõAdvanced product/process quality planning (APQP) õõAEC-Q100 stress testing õõProduction part approval process (PPAP) õõ8D reporting õõProduct change notification

Microchip’s support for functional safety doesn’t stop at the component level.

We can provide system designers with detailed information on any specific feature in a given device, including advice about the proper usage of a feature, its relevant statistical reliability

Table 1 Microchip Technology provides a range of functional safety-rated building blocks and components for automotive deployments.

31

Functional Safety

data, its signature when something goes wrong, methods for detecting malfunctions, and possible safe modes when problems arise.

With two decades of experience in serving the demanding requirements of the automotive market, Microchip Technology has a proven track record of successfully delivering cost-effective and reliable total product solutions to our valued customers. It’s time to start building the car of the future.

Microchip Technology, Inc.  microchip.com

  

@MicrochipTech linkedin.com/company/microchip-technology facebook.com/microchiptechnology

 youtube.com/user/MicrochipTechnology

Watch Video

32

IoT EVOLUTION

Developers Conference Powered by Embedded Computing Design

• IoT Security • IoT for Automotive • Industrial IoT • Wearables • M2M • Cloud • Microcontrollers August 17-20, 2015 Caesars Palace Las Vegas, Nevada

iotevolutionexpo.com/developers-conference/west/

embedded-computing.com/topics/automotive

SPONSORS

Š 2015 OpenSystems Media, Š Embedded Computing Design. All registered brands and trademarks within the Automotive E-mag are the property of their respective owners.