The data-logging memory must understand what happens when vehicles have issues and provide the insights necessary to improve the ADAS features, so it doesn't happen again.
Autonomous driving is changing the landscape of not just automotive but the whole transportation industry. As many expect fully autonomous driving vehicles to arrive soon on the road, the challenges in making it a safe reality are proving to be more difficult than assumed. The car companies and regulators have realized just what an incredibly difficult problem it is to solve in a truly reliable way.
So, instead of solving the problem as a whole, the focus has been to break it into multiple milestones, spanning from Level 1 to Level 5. Today, we can find autonomous driving capabilities on freeways with highly standardized layouts and an ambition to continue improving those capabilities and, eventually, apply them to more challenging driving situations such as country roads.
As a step toward fully autonomous driving, automakers are adding increasingly sophisticated advanced driver assistance systems (ADAS) to their vehicles. That offers features such as automated parking, automated lane changing, adaptive cruise control with station keeping, blind-spot monitors, driver monitoring system, collision avoidance, traffic-sign recognition, and many more. Automakers like these features because they provide product differentiation. Drivers find many of the features genuinely useful. And regulators like them because they can improve road-user safety now and provide a platform for mandating additional safety features in the future.
Developing ADAS features
Developing ADAS features is also becoming part of a steady progression toward true vehicle autonomy. It begins with breaking down that very large overall challenge into a series of point challenges that can be addressed separately. Many of these solutions share a common thread: they have an almost unquenchable thirst for data derived from multiple sensors. This data provides the raw material fused by powerful onboard computers to create an internal, real-time model of the surroundings through which the vehicle is moving. That, in turn, can be used as the basis for making decisions about how to react to that model. Once the decisions have been finalized, commands can be executed to implement the chosen reaction in the real world.
All this data gathering, sensor fusion, modeling, decision-making, and command execution must happen in real-time with very high levels of determinism and the highest regard for safety. And so, one of the practical challenges of implementing ADAS features is finding parts that have the functionality, speed, and quality levels necessary for use in safety-critical systems in cars.
Figure 1 Specialized chips are required to deal with a plethora of smart sensors in ADAS designs. Source: Infineon
The parts working in real-time scenarios in ADAS for vehicles include power management ICs (PMICs) designed to provide a well-regulated supply to safety-relevant sensors, transceivers, and microcontrollers. And microcontrollers must provide more computing horsepower for sensor fusion applications.
There are also LIN and CANbus transceivers, specialist power regulators and protection switches, and smart power switches that can be used to replace mechanical relays. Many of these parts are available in variants that meet the requirements of the Q100 Grade 1 component validation scheme of America’s Automotive Electronics Council (AEC). Some of the microcontrollers have also been shown to meet the the ASIL-D functional safety specification requirements, the most rigorous level of this scheme.
All these parts must be backed up with rich documentation, tool support ranging from compiler tool chains and autocode generation for the microcontrollers to third-party support for debuggers, timing analysis, calibration, simulation, modeling, and more.
Many aspects of ADAS features can be implemented using standard components that have been adapted and qualified for automotive use. Some, however, have design requirements that can be met using new components developed to meet that specific need.
One of the most important requirements is data logging that keeps track of the floods of information that flows through ADAS computers to give them a rich view of the environment through which the vehicle is moving. Some developers are using large solid-state devices (SSDs) as a venue to dump all this data. However, SSDs have slow write speeds and wear-out mechanisms, which may not offer the appropriate performance and reliability.
FRAM for data logging
One of the key reasons for doing mass, real-time data logging in vehicles with ADAS features is to capture what happens if something goes wrong. So, developers can learn from it and stop it from happening again. For example, some ADAS implementations are not good at identifying pedestrians, especially at night. Rigorous data logging, in which all the relevant sensor data is captured, timestamped, and stored in real-time, can provide a snapshot of what was happening at the time of an incident. It can then be used to drive a process of continuous model refinement that improves the ADAS implementation.
The non-volatile ferroelectric random-access memory (FRAM) can serve this purpose. Unlike traditional non-volatile memory technologies such as flash and EEPROM, FRAMs, also known as FeRAMs, have fast write times, support instant non-volatility, are as easy to address as SRAMs and, crucially, have almost unlimited endurance, reaching 1014 read/write cycles.
Their one drawback is that they don’t have as much density as other memory types. However, in practice, this issue is mitigated by using the FRAM as a rolling buffer for ADAS data streams. If a vehicle loses power, the FRAM data log will hold a snapshot of the data available to the ADAS computers up to that point.
Figure 2 FRAM fits well into data logging needs in an ADAS design. Source: Infineon
Moreover, there aren’t yet any mandates about how much data a vehicle should log if it has a catastrophic failure. However, SAE International is already offering guidelines about what type of data should be stored. Similar specifications are in development in Europe. But it seems likely that developers will be asked to ensure that their vehicles can capture and store 5 seconds worth of data about issues such as acceleration, braking effort and seatbelt status, as well as four images per second for 5 seconds from each of the onboard cameras.
The data-logging memory must understand what happens when vehicles have issues and provide the insights necessary to improve the ADAS features, so it doesn’t happen again. One such memory chip is EXCELON F-RAM; it’s targeted at data logging applications in ADAS and has been qualified to the ASIL-B functional safety standard.
Safety comes with design rigor
Many ADAS features are designed to increase the safety of vehicles and their passengers by using sophisticated sensor-fusion and machine-learning techniques to avoid hazardous issues. It’s worth remembering, though, that these safety features are an outcome of the rigor with which chipmakers develop manufacturing processes, products, and supporting tools and software. That also includes ensuring that components meet the relevant standards and qualifications.
It’s true for ADAS now, and it will be equally true further down the road when autonomous driving becomes a reality.
This article was originally published on EDN.
Medu Harsha is principal applications Engineer at Infineon Technologies.
Karthik Rangarajan is senior staff product marketing specialist at Infineon Technologies.