Vehicles with varying levels of autonomous driving capabilities are logging millions of miles on roadways. Still, a new survey, released recently by the Kelly Blue Book auto information service , finds that most people still want the ability to take control of the self-driving car when they feel the need. “The industry is still facing a lot of challenges, particularly in functional safety,” Charles Qi, a senior design engineering architect at Cadence, noted during a talk on Thursday, Sept. 22, at TSMC Open Innovation Platform® Ecosystem Forum. How the industry addresses these challenges will determine when we see fully autonomous cars on the road, he said. In Qi’s session, “Meeting ADAS SoC Safety Design Challenges with Active Safety Features Built in to IP,” he addressed how IP is designed to meet the functional safety requirements outlined in ISO 26262. There are six levels of self-driving automation defined in the SAE International Standard J3016 (see figure below, courtesy of the Linley Processor Conference), and we are currently at the level where vehicles in production have partial and conditional automation. The target is for vehicles in 2020 and beyond to have high and, finally, full levels of automation. “At level four and five, the vehicle is pretty much controlled by the machine, so safety is not an option anymore,” he noted, adding that safety design must be considered as early as possible in the overall system. The integrity of automotive IP contributes an important part in helping OEMs comply with ISO 26262. The newest iteration of the functional safety standard includes a chapter dedicated to defining the requirements of IP. Assuring design quality involves establishing formal quality flows and checkpoints, which Cadence follows from product requirement phase to final IP release. The company’s sites also adhere to the ISO 9001 standard, ensuring that all engineering projects, regardless of where they are untaken, follow the same quality management practices. “We’ve established very stringent testing and release criteria to assure our IP is developed with guaranteed quality management,” noted Qi. Addressing Safety Concerns Early Qi noted three key trends in safety design for ADAS: Increased safety impact: obviously, safety failures can result in fatalities, recalls, and lawsuits. An ADAS chipset comes with many potential points of failure. Simply put, vehicles must meet a fail-operational or not fail standard. Increased system/SoC complexity: designs tend to be highly intelligent, involving multiple vendors, as well as multiple sensors and memory hierarchies, multi-processor operation, and many I/O and network interfaces Safety is designed in early: when blackbox components are designed without safety principles, there’s no assurance of system safety “If the camera sensor interface is failing, you may not be able to capture the image, or the image becomes distorted,” Qi said. “But if we’re talking about memory failures, that has a much bigger impact because your entire ADAS software is running based on memory…so you can have the system completely crash.” Complying with the ISO 26262 standard comes with important implications for IP. An organization needs to maintain a safety-focused culture and processes, as demonstrated through tactics such as formal training, methodologies, and documentation. For safety product design, tactics such as safety goals analysis, protection mechanisms, safety testing, and qualitative/quantitative failure analysis are all critical. Clearly, while IP is typically developed as a safety element out of context (SEooC), well before final requirements are known, IP safety assurance and awareness impact overall system safety. Active Safety Features Integrated Into IP Cadence works with a third-party accredited company, gathering system-level requirements and making certain assumptions of usage models for its IP. Based on these models, the teams map system-level safety requirements into IP-level safety requirements, and identify certain safety mechanisms that must be in place in order to meet corresponding safety levels. The IP is broken down into sub-models associated with safety goals. The teams analyze system faults and the effectiveness of protection mechanisms. They also assume that random faults may occur in the IP, and conduct a level of coverage to ensure that safety goals are met at a certain confidence level, Qi explained. Active safety features are integrated into various Cadence IP, for example: The Tensilica Vision DSP features parity or error code correction (ECC) on cache or local RAM, high-priority interrupt, and exception handling Automotive Ethernet MAC IP features parity or ECC on packet/descriptor buffer, parity or redundancy of CSRs, failure status interrupt, DMA descriptor address range checking, parity protection at timestamp generation, and many other features Controller IP for PCIe features parity or redundancy on CSRs, bus and datapath parity, failure report interrupt, SECDED ECC or parity on memories, LCRC and ECRC, and advanced error handling for PCIe DDR controller IP has parity on AXI data and address, parity on the internal datapath, DRAM interface calibration and training, SECDED ECC or inline ECC support, and failure report interrupt “We’re seeing increased requirements on functional safety design, our customers are subject to more and more liability, and system complexity is increasing,” noted Qi. “That forces us to consider IP safety at a much earlier stage. Through our functional safety analysis for our IP products, we realize it’s important to have (safety mechanisms) in the design. It allows us to detect faults at lower levels much more effectively and also in real time. Having safety mechanisms also makes it easier to meet the ISO 26262 standard.” Christine Young![]()
![]()
↧