New initiatives are opening the lid on the black box of autonomous-driving AI. Who’s doing what, and why?
In 2020, a host of new industry standardization initiatives for artificial intelligence will roll out in earnest. Their common mission is to develop safety standards for AI-driven systems in autonomous vehicles and robotics.
With so many efforts pursuing the same critical goal, big questions loom. How much overlap will there be among the emerging safety standards? How well are these efforts coordinated? Will they leave any safety gaps unfilled? The answers aren’t yet clear, but the rollout announcements offer some clues, and EE Times has reached out to people close to the efforts for insight.
IEEE alone is kick-starting several freshly approved working groups aimed at AV safety: IEEE P2846, IEEE P2851 and IEEE P1228.
IEEE P2864, initiated by Intel/Mobileye, seeks a “formal model for safety consideration in automated vehicle decision-making.” IEEE P2851’s job, meanwhile, is a much-needed interoperable “data format for safety verifications of IP, SoC and mixed-signal ICs,” according to the working group. Just for good measure, IEEE has reactivated an IEEE standard originally developed for nuclear power plants. IEEE P1228 now will address AV software safety throughout the vehicle’s life cycle.
IEEE isn’t alone. Underwriters Laboratories’ draft of UL 4600 is currently on the ballot. Billed as “The First Comprehensive Safety Standard for Autonomous Products,” it is a little different from other industry standards.
Instead of prescribing how to do safety by following certain steps, UL 4600 offers a guide to “build the safety case” for an AV design. Intel’s Jack Weast, chair of IEEE’s new P2864 working group, sees UL 4600 complementary to IEEE P2864, calling UL 4600 the “low-hanging fruit.” The standard offers a checklist against which AV designers can argue the safety case for their design elements.
Finally, there are existing safety standards. One is ISO/PAS 21448 (SOTIF) covering the “safety of the intended functionality.” The standard focuses on guaranteeing the safety of the intended functionality in the absence of a fault. It thus stands in contrast to traditional functional safety described in ISO 26262, which aims at mitigating risk due to system failure.
This sudden rush to set standards for safety and reliability in AI-based systems is a marked departure from the practices of the very recent past. AV developers have long kept their methods close to the vest, disclosing scant data to the public (except for miles driven and disengagements — deactivation of the autonomous mode when a failure of the autonomous technology is detected) and treating safety in self-driving vehicles as a wedge for competitive advantage.
Today, neither industry nor government can assess the safety of self-driving cars. Without tools or common yardsticks, tech suppliers are working in the dark. By extension, the media and the public are told to take AV developers’ word that self-driving cars are safe.
Here’s the 64 million-dollar question: Are these developers finally acknowledging that the safety of autonomous vehicles must be a collaborative affair?
EE Times recently asked Riccardo Mariani, vice president of industry safety at Nvidia, to walk us through each of the newly proposed IEEE standards. Mariani is an IEEE senior member and is the 2020 first vice president of the IEEE Computer Society.
Further, Mariani is in an ideal position to see advancements by a variety of working groups in IEEE. He is the chair of the P2851 and the co-chair of IEEE Special Technical Community. He is also the proposed chair of Industry Connection Activity.
We wanted Mariani to explain the changes in the AV industry’s attitude, and how — or if — these new standards are supposed to work together.
First, Mariani reminded us that in addition to these emerging industry standards, a few private initiatives were launched in 2019.
For example, Safety First for Automated Driving (SaFAD) is led by Aptiv, Audi, Baidu, BMW, Continental, Daimler, FCA US LLC, HERE, Infineon, Intel, and Volkswagen. The group published a white paper last summer on how to build, test, and operate a safe automated vehicle.
Separately, SAE International, along with Ford, General Motors (GM), Toyota, and Uber, launched the Automated Vehicle Safety Consortium. The members are “working on the development of a series of safety principles for SAE Level 4 and 5 automated driving systems focusing on testing before and during operation of AVs on public roads; data collection, protection and sharing; and interactions between AVs and other road users,” according to the consortium.
Standardization gaps
While some of these private consortia provide best practices, their work product tends toward higher-level guidance. “The market needs more detailed instructions” to implement safety in autonomous systems, said Mariani.
Those could be forthcoming in the emerging standards, which appear to be pursuing different aspects of safety for AI-based systems. But a formal process to investigate potential overlaps or gaps in the standards might have to wait until IEEE establishes a new working group called “Industry Connection Activity.” Mariani is the proposed chair of Industry Connection Activity.
Recommended
Intel Gets IEEE to Ask ‘How Safe Is Safe Enough’ for AVs
The industry wants to ensure that all standards and a suite of practices “will be created without overlap,” said Mariani. To achieve that goal, he said, the IEEE Standards Association (IEEE-SA) is drafting an Industry Connection Activity on the “assessment of standardization gaps for safe automated driving.”
The IEEE Industry-SA Connection Activity is expected to become a formal working group soon — “maybe in two months or so,” said Mariani. Its mission is to “identify, analyze and assess existing standards and ongoing standardization activities.”
The planned working group hopes to connect the dots for industry by looking into the work of all related IEEE societies, including Vehicular Technology Society (VTS), Computer Society (CS), Intelligent Transportation Systems Society (ITSS). It will also connect with the relevant standards organizations, including the Society of Automotive Engineers (SAE), International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and Underwriters Labs.
The goal is “mapping different standards for autonomous vehicles,” said Mariani. “This is very important because such a mapping can help experts or corporations decide where to invest their time and resources.”
New initiatives are opening the lid on the black box of autonomous-driving AI. Who’s doing what, and why?
Hurdles beyond AI
IEEE P2864 is likewise working to make the process more transparent. According to Intel, the new working group is needed “because the decision-making capability of the AV’s computer is mostly hidden from observation,” controlled by proprietary AI algorithms. This black-box nature of the approach “makes it nearly impossible to comparatively judge the safety of the different vehicles,” according to Intel.
AI adds complexity to AV safety analysis, but it isn’t the only hurdle, said Mariani. “There is a strong desire in the market to reduce cost and share data from one company to another and from one standard to another.”
The AV industry is looking for “interoperability of their systems,” he said. This will, in turn, help industry players advance their technologies. “Meanwhile, newcomers [to AVs] want to have guidance from the industry in order to accelerate their efforts to design new technologies.” The endgame is achieving efficiency in technology development.
“IEEE hopes to play a role of bridging the gap and accelerating standards-setting in a coordinated way,” said Mariani. “This market cannot afford” to have disparate multiple safety standards that are not connected. Failing in this objective, he added, “will make [ensuring] AV safety expensive and risky.”
Mariani shared the following working-group activities with EE Times.
Special Technical Community
IEEE has formed a Special Technical Community (STC), within the IEEE Digital Reality Initiative. Its first plenary meeting convened on Dec. 6th.
Its goal is to “address in a combined way the aspects of reliability, safety, security, and time determinism in AI-based systems for applications like autonomous vehicles [and] robots,” explained Mariani, the co-chair of IEEE STC.
IEEE P2846
Chaired by Intel’s Jack Weast, the IEEE P2846 working group will hold its kickoff meeting Jan. 30–31 in San Jose, Calif.
Jointly sponsored by the IEEE Vehicular Technology Society and IEEE Computer Society, the group plans to “define formal rules-based mathematical model for automated vehicle decision-making using discrete mathematics and logic,” according to Intel. The model will address “the planning and decision-making functions of an SAE Level 3–5 automated vehicle.”
The standard will cover specified driving scenarios and cases, such as highway driving and full urban driving. It will describe a test methodology and tools to verify an AV’s safety and assess its conformance with the standard.
The group further states that the proposed standard “does not address the host vehicle navigation system implementing the logic or anything relating to perception, object detection, recognition, verification and/or classification, free space detection, etc.”
IEEE P2851
IEEE formed the P2851 standardization working group to develop “Exchange/Interoperability Format for Safety Analysis and Safety Verification of IP, SoC and Mixed Signal ICs.” The group, chaired by Mariani, will meet for the first time on Jan. 29 in Santa Clara, Calif.
Mariani noted that methodologies and data formats vary among IP and SoC vendors and system companies, impeding OEMs’ and Tier 1 suppliers’ effort to conduct cohesive safety analyses and safety verifications. The new working group, sponsored by IEEE Computer Society/Design Automation (C/DA) within the IEEE Computer Society, focuses on safety analyses and related safety verification activities for IPs, SoCs and mixed-signal ICs, such as fault injection. It will define a data format for sharing the results of these activities with system integrators.
More specifically, according to the group, “the format will define languages, data fields and parameters with which the result of those analyses and verification activities can be represented, in a technology-independent way.” The group described the goal of the standard as “providing a common ground for EDA, SoC and IP vendors in needs of developing tools, SoC and IP for safety critical applications.”
Mariani noted that IEEE P2851 does not conflict with recently proposed functional safety working group of Accellera Systems Initiatives. Accellera, the electronics industry organization focused on creating and adopting electronic design automation (EDA) and intellectual property (IP) standards, launched a proposed working group (PWG) in October that seeks “a standard to enable tool interoperability between failure modes, effects, and diagnostic analysis (FMEDA) for functional safety and the design and verification flow of electronic circuits and systems,” according to a Accellera’s statement. While the PWG is still evaluating its standard, Mariani expects Accellera’s work to feed into the new IEEE standard.
IEEE P1228
IEEE P1228, sponsored by the Software & Systems Engineering Standards Committee within the IEEE Computer Society, is working on a standard for automated-driving–software safety.
This is the same group that was tasked to work on software safety for nuclear power plants several years ago, said Mariani. It was “reactivated” in November. “It is now retargeted to develop software safety for broader safety-critical systems including automated driving systems,” he added.
As its focus is on system safety “throughout the [AV] software lifecycle,” the IEEE P1228 will cover safety “during the development, procurement, maintenance, and retirement of safety-critical software,” according to the working group’s documentation.
Safety-critical software refers to “software products whose failure could cause loss of life, [inflict] serious harm, or have widespread negative social impact,” according to the working group.
The standard is limited to the “only safety aspects of the software,” but that includes aspects of software safety “related to interoperation with other systems or constituents of a system of systems,” according to the IEEE P1228 standardization working group.
Fonte: EE Times
