Tag Archive for: AV

Functional Safety for Autonomous Driving

This post on functional safety for autonomous driving is Part III in our three-part series with automotive expert Patrick Freytag. If you haven’t already, please go back and read Part I, which talks about how the automotive sector is changing – and Part II, which discusses ways to address functional safety.


Since functional safety has a product lifecycle approach, it has a wide impact on all processes in a company. As a newcomer to functional safety, it’s challenging to focus on the most important aspects, especially for new entrants in the knowledge-intensive automotive sector. Here are best practices based on my observations and experience.

Functional Safety for Autonomous Driving – Best Practices for New Market Entrants 

Executive Management Team: Pay Attention to Functional Safety 

Product safety should be at topic of conversation for the Executive Management Team (EMT) because of the legal responsibilities placed upon the company by deploying a vehicle to customers. The EMT should understand that it needs dedicated resources to achieve product safety. One of the most important tasks of the EMT is to implement a Safety Engineering Management and to assure that roles and responsibilities for quality and safety are defined and communicated in the company. Members of the safety team need a specific skill set, so it is important to invest in functional safety education and qualification. It is important to foster a quality and safety culture in the company. For that reason, quality and safety should be part of goal agreement and performance evaluation. Quality and safety have to be recognized as a core responsibility and a performance indicator for employees.  

Project Management: Plan and Track Functional Safety 

Project management has to incorporate functional safety in the product concept and development plan. The Project Manager (PM) should consider the additional time and cost in the project plan and the project budget. Product development plans must include quality and safety milestones and the related work products. What should be done if the PM doesn’t receive proof that quality and safety milestones are reached at the gate reviews, for example? Well, that’s for sure a red flag. Situations like these may point to deeper rooted issues, and should not be brushed under the rug. The PM should start a GAP analysis and request an action plan. I recommend escalating the issue to the executive team ASAP in case there is missing proof of product safety. It won’t get better without commitment and planned actions, the longer you wait the worse the situation will get. Since safety considerations most typically permeate several layers of system design, it is not an attribute that can be tagged on shortly before the start of production, it has to be implemented from the beginning. 

Development & Functional Safety Team: Implement and Validate Functional Safety 

Industry experience shows that functional safety is not a topic you can assign to one responsible person. For example, a technical safety concept is created by a team of software, hardware, and system-level experts and moderated by a systems architect in collaboration with functional safety engineers. This means that the functional safety manager is a role that is played a few times in a company, while the role of a safety engineer can be assigned to even an entire team. As mentioned, functional safety requires specific domain knowledge and safety engineering expertise. But what can be done if this expertise is missing in-house? My recommendation is to compensate it with external resources as an interim solution. Start functional safety education and qualification as a long-term solution. Safety must be addressed in product development with adequate engineering methods and domain knowledge to define safety requirements. These safety requirements have to be implemented, tracked, managed, verified, and validated to make sure that risk reduction is realized, and the product is safe.  

The Evolution of Functional Safety for Autonomous Driving 

The functional safety focus is on avoiding and mitigating failures in E/E systems. That also works well for Advanced Driver Assistance Systems (ADAS). When a failure is detected, the driver gets alerted, and mitigation measures are performed to reach a safe state. These systems are called fail-safe. Let’s take Adaptive Cruise Control (ACC) as an example. When a failure is detected, a warning will be displayed in the Instrument Cluster. This visual warning is typically combined with an acoustical warning to get the attention of the driver. The ACC function will be switched off, and the driver is in charge to control the vehicle’s speed and keep a safe distance again.  

Additional Safety Considerations for Autonomous Driving 

The ADAS safety mechanism described above will not be sufficient for a fully autonomous vehicle. It’s not possible to switch off the automated driving system because there is no driver in the loop to take over. An Autonomous Vehicle (AV) has to work under all (failure) conditions, it has to be fail-operational. An AV without a driver in the loop also needs situational awareness, understand the surrounding world, decide, and act. This situational awareness is created by data fusion from a variety of complex sensor systems based on lidars, cameras, and radars. The combined data is then interpreted to plan and take action. This interpretation and planning are achieved by complex algorithms, driven by Artificial Intelligence (AI) and Machine Learning (ML).  

Today, many connected and ADAS-equipped cars are already available. Connectivity features and information sharing are increasingly used for updating vehicle features, maintenance-related diagnostics, and traffic services. This development will also increase the attractiveness of an attack on vehicles by hackers with different motivations and it introduces additional risks for vehicle cybersecurity.  

Safety Concerns Due to System Limitations and Misuse 

What happens if an automated driving system has no system failure but doesn’t work as intended? Unsafe behavior could be triggered by limitations in the sensor systems, extreme conditions, or unforeseen situations. In addition, misuse could confuse the AI algorithms and result in unsafe behavior too.  

An example of misuse of an ADAS was showed by Consumer Reports. Consumer Reports reported in April 2021 that it was able to trick a Tesla into driving in autopilot mode with no one at the wheel. Real-life proof followed in May – Police arrested Tesla driver for operating his car from the back seat while traveling on a San Francisco Bay Area freeway. The officer confirmed the sole occupant was in the backseat, so he took action to stop the car and saw the occupant move to the driver’s seat before the car stopped. In response, Tesla activated the cabin camera with a software update to detect and alert driver inattentiveness while autopilot is engaged for Model 3 and Model Y end of May.  

Here a typical example of limitations, an AV is driving and confronted with black ice conditions. While an experienced driver should be able to comprehend the situation and respond properly, an AI-based AV might not. Without sensing the icy road condition, an AV might drive faster than is safe for the condition. 

As a result, there has to be an addition to functional safety considering safety violations that occur in absence of a system failure. 


RELATED: Watch a demonstration of the Jama Connect for Automotive Solution


Safety of Intended Functionality or SOTIF (ISO/PAS 21448) 

The publicly available specification ISO/PAS 21448, titled “Road vehicles — Safety of the intended functionality” was published in 2019. SOTIF is defined in the standard as: “The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons.” The goal of SOTIF is to avoid situations where vehicles are working as designed, but are failing under real-world scenarios. ISO 21448 provides guidance on the design, verification, and validation measures to achieve the SOTIF. The current version covers Advanced Driver Assistance Systems (SAE J3016 L1 and L2). It can be considered for higher levels of automation; however, additional measures will be necessary. 

 The Standard for the Evaluation of Autonomous Products (ANSI/UL 4600) 

The UL 4600 standard was issued in April 2020 with the scope of the Safety Evaluation of fully Autonomous Driving Systems that operate without human intervention. The goal of UL 4600 is to ensure that a comprehensive safety case is created, including safety goals, argumentation, and evidence. UL 4600 covers the safety principles, risk mitigation, tools, techniques, and life-cycle processes for building and evaluating a safety argument for vehicles that can operate in an autonomous mode without human supervision. Therefore, the ML-based system aspects of the autonomous operation are covered. UL 4600 works well with existing automotive safety standards such as ISO 26262 and ISO/PAS 21448 by building on their strengths while also filling their autonomy-specific gaps.  

Conclusion

The safety challenge for autonomous vehicles can’t be addressed with a single standard as of today. As we move on from existing Advanced Driver Assistance (L1 and L2+) to fully Automated Driving Systems (L5) the standards and methods will evolve too.  

Current state-of-the-art automotive safety is achieved with a combination of different engineering methods and processes: 

Functional Safety (ISO 26262)

Guards the E/E malfunction behavior due to systematic and random hardware failures for vehicles with a human driver present responsible for safe operation

Safety of the Intended Functionality (ISO/PAS 21448) 

Deals with the functional limitation regarding the absence of unreasonable risk due to hazards resulting from functional insufficiency of the intended functionality or reasonably foreseeable misuse by persons. SOTIF covers L1 & L2 ADAS vehicles with a human driver present responsible for safe operation. 

Cybersecurity engineering (ISO/SAE 21434)  

Protects road vehicle systems and components from harmful attacks, unauthorized access, damage, or anything else that could interfere and compromise safety functions 

Evaluation of Autonomous Products (ANSI/UL4600) 

Proofs the safety of fully autonomous road vehicles that can operate without human supervision  

Take Away: The combination of different engineering methods is needed on the way to fully Autonomous Driving  

  • Functional Safety helps you to do things right 
  • Safety of Intended Functionality helps you to do the right things 
  • Cybersecurity helps to protect the safety functions from being compromised 
  • Evaluation of Autonomous Products helps you to provide proof that you did enough safety engineering work to achieve a safe autonomous product

This blog post concludes the 3-blog miniseries on automotive insights and best practices on the way to autonomous driving. Special thanks to Jama Software for the opportunity to share my observations and experience with you. I hope you enjoyed reading my thoughts and got useful insights into the complex and interesting world of automotive safety and autonomous driving.  



Editor’s Note: This posts on autonomous vehicle development was originally published here by EE Times and written by Junko Yoshida. While this post was published in 2020, the content is still relevant to AV development in 2021.


How many safety standards does it take to screw in the lightbulb in a highly automated vehicle? A few years ago, automotive market novices would have said, “None.” These days, the number seems to keep increasing as the industry finally comes to grips with the technical challenges of producing demonstrably safe autonomous vehicles.

Driven by the winner-takes-all Internet platform business model, autonomous vehicle (AV) zealots were racing to develop the industry’s first robocar. Their goal was simple. Dominate the AV platform so completely that everyone else in the industry would be forced to follow and license.

Fast forward to 2020. The go-it-alone, my-way-or-the-highway approach is driving on fumes. In contrast to a few years ago, leading automotive OEMs, Tier Ones and tech suppliers including chip vendors are more engaged in forming industry-wide coalitions to develop AV standards that have safety considerations at their core.

Close to ten industry initiatives are in the works, seeking to address different aspects of AV safety. Prominent among them are the existing ISO 26262 and SOTIF, and the newly-published UL 4600.

So, does this mean the automotive industry is finally coming together? Perhaps.

Collaboration is a new and alien concept for participants in the auto industry. When it comes to safety standards, of course, “everyone has different opinions,” said Stefan Poledna, CTO of TTTech Auto, in a recent interview with EE Times, but “this is the general direction.”

What changed?

The industry achieved Level 2 / Level 2+ autonomy so quickly that it vastly underestimated how much more difficult it would be to take the next leap to Level 3-5 technology. It has finally dawned on the AV industry that developing a safety-related computing system for Level 3-5 autonomy is “a grand challenge that shouldn’t be addressed by a single player, but in an ecosystem,” Poledna noted.

When an L3, L4 or L5 vehicle goes the wrong way on a one-way street, it’s no longer the driver who’s responsible — it’s the carmaker. Poledna, trumpeting the obvious, said, “That’s a big deal.”

New ISO standard on horizon

Remember SaFAD (Safety First for Automated Driving)? It turns out the white paper published last July by 11 industry leaders (Aptiv, Audi, Baidu, BMW, Continental, Daimler, Fiat Chrysler Automobiles, HERE, Infineon, Intel and Volkswagen) is on its way to becoming a new ISO standard.

The white paper outlined “a comprehensive approach to safety relevant topics of automated driving.” The objective of the publication, the authors said, “is to systematically break down safety principles into safety by design capabilities, elements and architectures and then to summarize the verification & validation methods in order to demonstrate the positive risk balance.”

The ISO accepted that premise, allowing the industry to develop this into an ISO standard.

But what does it take to turn a “comprehensive approach” into a workable ISO standard? We asked SaFAD member Intel.

Jack Weast, Intel senior principal engineer and vice president of standards at Mobileye, explained, “First, we take the original SaFAD paper, clean it up, get rid of any color commentaries and reformat the technical meat of the document into the ISO standard.”

Simon Fürst

Looking for a faster turnaround, Simon Fürst, principal expert autonomous driving technologies at BMW Group, who heads the committee, announced in a webcast called “The Autonomous,” that his group is shooting for mid-2020 to publish its ISO Draft Technology Report (DTR) 4804.

Weast described the DTR as the first step for ISO standardization.

Several auto industry sources told us the new ISO standard might be a step in the right direction, but the caveat is that it takes years before it becomes the final standard. Further, they said that they find it too generic and too high-level to help automotive OEMs in the short term.

Intel’s Weast acknowledged the scope of the [ISO] document is “pretty broad.” But Weast defended it as “a big umbrella” covering discussions of “How would you define, derive, develop and test an automated driving system end to end.”

Noting that the document offers “a useful structure,” Weast said, “We are obviously supportive of the safety by design principles,” and the document provides “a very well-thought-out way of doing things.” Weast added, “This is why it’s great to have an ISO document, which explains, ‘hey, here’s a good methodology in doing so.’”

Stefan Poledna

‘The Autonomous’: Going one or two levels down


TTTech Auto, which specializes in safe software and hardware systems for advanced vehicles, launched the initiative called “The Autonomous” (the webcast was named after the initiative).

TTTech Auto’s CTO Poledna told EE Times that TTTechAuto is convening many players in the automotive ecosystem at its own event to “brainstorm and discuss” development of  “a proving ground” for car OEMs, Tier Ones and chip vendors to test out the safety of their AV systems. “They need to have certain exchanges amongst themselves,” he said, at a time when everyone is struggling to figure out what it takes to bring L3 and L4 cars that are safe to the market.

Poledna said that The Autonomous is fully aware of the many approaches — including different computing architecture, software algorithms and sensor fusions — pursued by different companies to ensure safety.

That’s part of the reason for launching The Autonomous. TTTech Auto contends that players in the automotive industry need solutions much more specific, more concrete and quicker on the trigger. The aim of The Autonomous is to go one or two levels downs from the upcoming ISO DTR 4804 standard, to conceive “a reference design implementation” the AV industry can use.

The goal isn’t about picking the winning black box, though.

(Source: The Autonomous)

Instead of building AVs around black boxes, carmakers would like to be able to mix and match different modules from different suppliers — safety modules, ‘checker’ modules (as in a ‘doer-checker’ model), calculation modules, etc. Assume one OEM opts for a safety module from Supplier A, which bears no resemblance, posing critical compatibility issues, to a safety module from Supplier B? Poledna argued that the AV industry must have “a common understanding of what the safety architecture would look like.” The industry should have a common approach and common understanding on “interfaces” and “data structures,” he explained.

(Source: The Autonomous)

On one hand, the ISO standard deemed too generic. On the other hand, too many players in the AV industry are already implementing different safety solutions on their own. How does The Autonomous plan to succeed as a “middle ground” solution?

Poledna said, “If we agree on ‘doer-and-checker’ as a generally acceptable safety approach, I’d consider it as a huge achievement.” Further, he noted that he’d like to see the industry come to a collegial understanding on data structure, interfaces, and a definition of free space.  The Autonomous is holding a series of workshops focused on such issues as computing architecture, AI, security and regulation. While encouraging participants to share best practices, the goal for The Autonomous group is to foster amity among key automotive players and publish documents and technical papers reflecting state-of-the-art solutions in the industry.

 


Jack Weast

Narrowly focused

If The Autonomous is clicking one or two levels down from the ISO standard, Weast said that IEEE P2846, a group that Weast chairs, is boring down farther into the details, with specific focus on “a very narrow area of decision-making capability.”

The benefit of being narrowly-focused is that “we can go much deeper,” he explained. In examining the decision-making process, “we also look at ‘what kinds of assumptions we’d make about other road users,” he said. Depending on the city where an AV is driving or on a situation (an intersection with an occluded view, for example), knowledge of the assumptions that apply in those specific cases is essential to creating a safety model for a decision-making block.

While the IEEE P2846 is focused on that decision-making block, AV safety standards in the end are likely to require close to a dozen different technical blocks for the industry to define and implement safety, Weast speculated. “We will need, for example, a safe operation block,” which could be addressed by ISO 26262 and SOTIF standards, for example. Others include a behavior and traffic block, “which maps well with what IEEE P2846 offers,” and things like a data recording block.

It is clear that “standards and interoperability are essential” to enable an ecosystem on which an entirely new market like AV can be built, Weast explained. However, he acknowledged that setting industry standards is always a balancing act. You need to create a robust market, but companies must feel free to differentiate.

Asked on what specific technologies the AV industry must come to agree, Weast said, it’s something — from different suppliers when made commonly available — that will benefit everyone and lift all boats equally.

Take, for example, IEEE P2846.

If AV companies can’t agree on what safety means (including a safe distance between cars, for example), they won’t be able to make convincing arguments to government regulators for the safety of autonomous vehicles, he explained. The same goes for operational design domains (ODD). If a common template isn’t applied to define ODD, the industry can’t explain what exactly a certain vehicle is capable of doing where, in what conditions.

Despite an epidemic that prevents many standards organization members, including IEEE P2846 members, from traveling, Weast said the group still wants to complete its draft by the end of this year or by early 2021.

To expedite the process, the group has broken the work into four subgroups. One is identifying safety-related scenarios in which there are assumptions about other road users. Another is examining the attributes of safety models used within decision making. The third group is aligning definitions and taxonomy with those used by other standards as the best possible. The fourth group is documenting how the standard fits or complements other standards, “so that we can resolve some confusion and questions” about IEEE P2846, explained Weast.

A bit of the good news on IEEE P2846 is the election, added Weast. While Weast is the chair, the group elected a person from Waymo to be the vice chair and an Uber representative as secretary. For Waymo, this is a first; until now the company has opted to go it alone.  “We now have a good representation from the chip industry, companies in the mobility as a service business, to car OEMs, Tier Ones and robotics companies,” said Weast.

Its 20 members include: Aptiv, ARM, Baidu, Denso, Exponent, Fiat Chrysler (FCA), Google, Huawei, Horizon Robotics, Infineon, Intel, Kontrol, National Taiwan University, Nvidia, NXP, Qualcomm, Uber ATG, Valeo and Volkswagen.

Safety case
Separately, earlier this month, Underwriters Laboratories has completed its first standard for Autonomous Vehicles. Called UL 4600, it is published and now available at ULstandards.com.

Phil Koopman

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, according to Phil Koopman, CTO of Edge Case Research, one of the authors of the standard. Acknowledging that no single standard can solve the world’s autonomous product problem, the authors of UL 4600 have fixed a starting point by asking autonomous product designers to make a safety argument.

Koopman stressed that Underwriters Laboratories created a diverse body of international stakeholders on its Standards Technical Panel (STP) to develop the document. The STP consists of 32 members with voting rights, including representatives of government agencies, academia, autonomous vehicle developers, technology suppliers, testing & standards organizations and insurance companies. Its STP members include: Uber, Nissan, Argo AI, Aurora Innovation, Locomotion, Zenuity, Intel, Infineon, Bosch, Renesas, Ansys, Liberty Mutural, AXA, US Department of Transportation, and others.


We’ve compiled a list of helpful resources for requirements management in automotive development, click the button to learn more!

SEE MORE RESOURCES


Autonomous Vehicle Development

Developing autonomous vehicles requires an incredible number of moving pieces to communicate with one another. From sensors, to computers, to the automatic braking system, vehicles today require a complex system that leaves no room for error in communication.

In this blog post, we take a look at Arteris IP’s top challenges in autonomous vehicle development and why they selected Jama Connect to help.

Managing Complexities Across Remote Semiconductor IP Development

In a world of increasing automotive complexity and connectivity, developing the world’s most innovative semiconductor IP comes with a set of challenges. Arteris IP turned to Jama Software to help address these critical business challenges:

1. Adapting to Increasing Complexities in Semiconductor Development

As semiconductors get larger with more processing power and more functionality, they also become more complex and more connected. In addition to the standard complexity of semiconductor IP, Arteris IP was the first to add state-of-the-art functional safety mechanisms directly into the on-chip interconnect semiconductor IP, compounding their product development complexity.

In conjunction with their response to increasing complexity in semiconductor development, Arteris IP was also expanding their product lines from one to four, and therefore greatly increasing the number of requirements they’d need to manage.

“I find it really interesting that as the automotive industry becomes more complex, it’s becoming much riskier to base a product development process on static requirements trapped in documents. You need a living requirements thread through the end-to-end process to minimize the risk of negative outcomes and maximize productivity.”

– Kurt Shuler Vice President of Marketing Arteris IP

2. Collaborating Across Distributed Teams

With teams spread across the United States, Europe, and Asia, having clear communication and collaboration is crucial to Arteris IP’s success. The team found that sending documents and spreadsheets over email made it nearly impossible to maintain version control, and spending hours in a room reviewing requirements was not only ineffective, it was inefficient.

And while developing semiconductor IP was never an easy task, the global COVID-19 pandemic of 2020 added new challenges to Arteris IP as engineering teams shifted to be fully remote.

The challenge of engineering teams working remotely across multiple time zones made communication and collaboration even more vital, emphasizing the need for a solution that enabled everybody to collaborate seamlessly on a project virtually, regardless of physical location.

Jama Connect is our single source of truth. If it’s not in Jama Connect, it’s not happening. If it’s not in Jama Connect, it didn’t happen. When I tell people in the automotive industry we use Jama Software, they all know what it is. If you’re using anything other than Jama Software in the automotive industry, you’re going to get more questions.”

– Kurt Shuler Vice President of Marketing Arteris IP

3. Managing Document and Tracking Disparities Lacking in Traceability

With just Word Documents, email, and Excel spreadsheets, the Arteris IP team found themselves struggling to keep track of things due to the lack of traceability and a central source of information.

Macro-level traceability is key to the Arteris IP development process, and their current system did not provide end-to-end traceability — all the way from requirements to verification and validation. Atlassian Jira also played an important role in their development process, and the team needed a way to seamlessly link requirements to Jira and keep those in sync as things shifted.

As an innovative leader in the automotive industry, other organizations were looking to Arteris IP for guidance on development processes, quality management, and adherence to ISO 26262. They knew there must be a better way than spreadsheets and documents.


RELATED: Watch a demonstration of the Jama Connect for Automotive Solution


4. Proving Compliance and Providing an Audit Trail

With many of the most important Arteris IP clients being in the automotive industry, and some also in aerospace and industrial machinery, meeting regulatory standards is a critical challenge for the organization. ISO 26262 is the most important functional safety standard for Arteris IP, and proving compliance is critical. And as previously mentioned, their current solution did not provide the level of traceability necessary to prove compliance with ISO 26262.

The team needed a solution that both enables traceability and helps demonstrate that functional safety standards and industry regulations like ISO 26262 have been met during the development process.

Arteris IP Selects Jama Connect to help Develop Connected Semiconductor IP for Autonomous Vehicle Development

After considering all market options, including IBM® DOORS® Next Generation, Arteris IP selected Jama Connect as their requirements, risk, and test management solution. The decision, Kurt Shuler, VP of Marketing, said, ultimately came down to the semiconductor and automotive industry’s trust in Jama Software as an industry-leading solution.

He explained that after speaking with many of his semiconductor company and automotive Tier-1 customers, the majority of whom were replacing their outdated, legacy systems and adopting Jama Connect, he knew this was the right path for Arteris IP.

Download the full customer story to see how Jama Connect helped Arteris IP manage the complexity of developing highly sophisticated semiconductor IP by simplifying their requirements management and review processes and improving communication and visibility across distributed teams.


Read the full customer story to see how Jama Connect helps industry leader Arteris IP with autonomous vehicle development.

SEE THE FULL STORY