Tag Archive for: automotive

When personal computers first came into common use in the 1980s, the closest a microchip came to an automobile was during transit to its final destination.

Few consumers could have predicted there would come a time when their automobiles would be controlled by computer chips, much less have integrated technologies to manage everything from cell phone calls to satellite radio to entertainment features, GPS mapping, and even drive controls.

The automobile of the 2020s hasn’t just transcended crank starters and wood paneling; today’s automobiles integrate multiple technologies developed by teams across industries all over the globe. The automobile market has evolved to include everything from self- or assisted-driving technology, automated safety features, and various green technologies, including electric and hybrid options.

These marketing forces are creating the following challenges:

Surge in connected cars
Autonomous vehicles (AV) disrupt regulations
Push to electrification of vehicles (EVs) balanced with high technology cost
Increased mobility services
Product quality that meets safety-critical standards

RELATED: Jama Connect^® for Automotive Solution

With all of these new market demands, it’s not uncommon for automobiles to require over 100 million lines of code. By 2030, a late model auto could require as many as 300 million lines of code. Connected cars can process 25 gigabytes of data per hour and generate over 4 terabytes of data per day.

All of this data means that today’s cars can fall prey to software malfunctions, connection interference, or even hacking. And because lives are in the balance, development teams have more incentive—and responsibility—than ever to get it right from beginning to end.

In this complex world of modern automotive development, many companies are adopting the ASPICE standard for software development to meet these new automotive safety challenges.

What is Automotive SPICE (ASPICE)?

ASPICE started as a variation of the ISO/IEC 15504, or SPICE, standard. SPICE stands for “Software Process Improvement and Capability determination.” The SPICE standard began as a way to provide a framework for independent assessors to evaluate an organization’s capability for software development.

As other teams and manufacturers looked for software suppliers, this SPICE score could serve as one way to evaluate whether the developer can meet certain standards for performance, safety, and quality. Though the SPICE standard didn’t gain much traction in other development fields, it did start to take hold in automotive as German auto manufacturers began using it.

As the standard became focused more toward automotive, the moniker “Automotive SPICE” or “ASPICE” took hold. As it stands now, ASPICE is a process assessment model and a process reference model for software development in the automotive industry. Software teams who design and develop software for the automotive industry should use ASPICE to document processes and measure the maturity of the organization’s processes.

The SPICE standard began as a way to provide a framework for independent assessors to evaluate an organization’s capability for software development.

Fundamentally, the goal of ASPICE is to define best practices for development of embedded software for vehicles.

Given that a modern vehicle can involve hundreds of millions of lines of code, creating some objective “best practices” can only benefit the teams working on this code. And it’s not just how much code is required that adds complexity — it’s also the fact that companies increasingly work across geographic and industry boundaries. When looking for suppliers, having some objective standards of assessment can be useful.

ASPICE is based on the V-Model — a model that requires logical decomposition of requirements and rigorous evaluation through testing at each stage of development. This model benefits both suppliers and system integrators by giving opportunity to eliminate problems in early development stages and providing a framework for ideation and development.

It also ensures continuous innovation and product development. On the left side of the V-Model are initial phases of product development.

Requirement Analysis: Discovering, listing, and prioritizing client requirements
System Design: Mapping client needs and putting them into a viable work model
Architecture Design: Organizing requirements into logical operations
Module Design: Creating software requirements that match system requirements and developing service units
Coding: Designing and implementing units; this is the point of the V

On the right side of the V-Model are the secondary phases of product development:

Unit Testing: Determining if code and design match and standards and requirements are met
Integration Testing: Evaluating software architecture and service units
System Testing: Integrating everything into the full system and testing
Acceptance Testing: Performing final tests

The advantage of the V-model is that it promotes testing and improvement throughout the development cycle. For each point along the V, there is a corresponding testing phase and additional traceability and management processes. Suppliers who follow this ASPICE model can earn certifications according to standardized achievement phases; the ASPICE standard is scored in levels from zero to five, which clients can use to evaluate the proficiency of the development team.

ASPICE levels are as follows:

LEVEL 0 | Basic

Teams at Level 0 are still developing processes or systems. They can, at most, “partially” achieve ASPICE requirements. These teams should focus most of their efforts on managing basic tasks.

LEVEL 1 | Performed

Teams achieving Level 1 either nearly or completely deliver standard ASPICE requirements, but likely have gaps in their processes.

LEVEL 2 | Managed

Level 2 teams can reliably deliver work products and almost or completely achieve ASPICE standards.

LEVEL 3 | Established

At Level 3, teams have established and set performance standards and are engaged in continuous improvement to constantly evaluate and learn.

LEVEL 4 | Predictable

Level 4 teams measure, record, and analyze outcomes; evaluate outcomes and processes objectively; and consistently meet performance standards.

LEVEL 5 | Innovating

Level 5 teams have reached a stage where they are not only consistently delivering high performance and quality products, but also engaging and investing in continuous improvement. These teams also analyze performance standards for quantitative feedback and causal analysis resolution.

ASPICE does not prescribe tools or techniques for teams, but rather gives a framework for examining the approach to internal development methods. The ASPICE standard is mostly generic and largely tool and process “agnostic” — that is, it gives a framework for evaluating the process and outcomes, but does not dictate the best processes or methods for every team. Because every team is different, this generic approach can help bring order and improvement to any team operating in any automotive system or space.

ASPICE levels look daunting, and for a start-up or young team, the idea of achieving Level 5 might seem out of the question. However, it’s important to note that Levels 4 and 5 are aspirational; most teams that achieve these levels are part of very large corporations. Level 2 is a more realistic initial target, and by the time teams are at Level 3, they are functioning at a standard broadly considered “excellent.”

How ASPICE Affects Automotive Development

The world of automotive development is only becoming more complex.

Some factors that are increasing complexity:

Consumer demand: A connected world means that consumers want seamless connectivity across their entire lives. The lines between work, home, and leisure are increasingly blurry, and consumers who still need vehicles to get from point A to point B will want all of those pieces of their lives to be integrated — even behind the wheel.

Increasing regulation: With the increasing complexity of auto systems and a focus on reducing climate impact, auto manufacturers will have to comply with new and possibly shifting regulations across different entities.

Rapid innovation: Technology continues to change and innovate at a breakneck pace. With systems increasingly integrated into automobiles, manufacturers will have no choice but to keep up with innovation. In fact, as of 2019, 80% of product innovation in automotive comes through software development

Fortunately, ASPICE can help auto suppliers and original equipment manufacturers (OEMs) respond to this increasing complexity in multiple ways:

Control the process: ASPICE gives teams clear guidance for evaluating and controlling their development processes, which can help ensure product quality, shorten time to market, and reduce costs.

Streamline supplier selection: By clearly defining levels of achievement, ASPICE can help OEMs assess and evaluate suppliers. If suppliers achieve Level 2 or 3 in ASPICE, OEMs can be fairly certain they are getting quality products.

Reduce costs and improve time to market: Because ASPICE is more concerned with process than with specific regulations or safety guidelines, using the standard can help teams reduce costs and improve efficiency, thereby improving overall market competitiveness.

How to Ensure Compliance with ASPICE

Most automotive developers are rigorously working towards ASPICE compliance and there are many advantages to aiming for it.

1.) It’s possible that compliance will be required some time in the future, so working toward it now is a positive step in preparation.

2.) Automotive development is only getting more complicated, not less, and development will continue to require teamwork across industries, companies, and geographies. Working within the ASPICE standard will help ensure consistency.

3.) Working within ASPICE will give teams a competitive edge over other suppliers and OEMs who are not yet using the standard.

But knowing that compliance is desired and actually achieving it are two different things. How can teams ensure compliance with the ASPICE standard?

Start with an honest assessment.

Teams can’t know where to go until they know where they are. A good place to start is to draft current processes and compare them to the ASPICE V-model. This effort can provide good insights into current levels compliance and where improvements can be made.

Confront the gaps and missing pieces.

Most teams will have some gaps in their processes or procedures. Likewise, some teams will have unclear separation between steps in the V-Model. Look at the gaps and assess how to close them, and identify where additional steps should be introduced.

Include stakeholders.

Be sure that all stakeholders have complete visibility into the ASPICE compliance efforts, and clearly define the resources those stakeholders can provide where necessary.

Test every phase.

Testing is vital to ASPICE compliance. Be sure to include rigorous testing at every phase in the process.

Operate under the new guidelines.

Once the plan is in place, implement it immediately.

Reassess and improve.

After completing a new product under the new ASPICE compliant processes, reassess, evaluate, and look for ways to improve. This constant focus on improvement is what allows teams to achieve higher levels of ASPICE compliance.

2022 Automotive Predictions

In many ways, 2021 was a continuation of the changes brought about in 2020, a year that’s been described as “unprecedented” and “unparalleled.” In a unique way, 2021 has offered us an idea of evolving innovations and technology on the horizon for teams across industries. These changing conditions will present a variety of new landscapes and will offer unique challenges, opportunities, and more than likely, many surprises.

As we enter a new year of further changes, Jama Software asked select thought leaders – both internal and external – across various industries for the trends and events they foresee unfolding over the next year and beyond.

In the third part of our five-part series, we ask Adrian Rolufs, Director of Solutions Architecture from Jama Software, to weigh in on product and systems development trends he’s anticipating for automotive development in 2022.

Read our other 2022 Industry Predictions here: Part One – Engineering Predictions, Part Two – Medical Device Predictions, Part Four – Aerospace & Defense Predictions, and Part Five – Insurance Development Market Predictions.

Q: What product, systems, and software *development trends are you expecting to take shape in 2022?***

Adrian Rolufs, Jama Software:

2022 will continue much like 2021. Many established automotive companies are in the process of modernizing their development processes and tool chains. These companies are looking to adopt Agile principles to allow them to execute faster and adopt modern tools that better support their new process. Many of the startups established in the last couple of years are maturing and discovering a need to add more robust processes to ensure that as they bring products to market, they maintain compliance with the safety and quality standards in automotive.

Due to the global chip shortages in 2021 that had a huge impact on automotive OEMs, we’ll continue to see a focus on ensuring that there is a sufficient supply of automotive grade chips.

Q: In terms of product and systems development, what do you think will remain the same over the next decade? What will change?

Adrian Rolufs, Jama Software:

Over the next decade, I expect that automotive systems development will continue to place an emphasis on software defined features. OEMs will continue to heavily invest in their software development capabilities and an ongoing focus will be placed on quickly delivering new software features while maintaining quality.

A major change that I see coming is a wider adoption of vehicle variation through software differences rather than hardware differences. Tesla has already led with this approach, but I expect to see more manufacturers ship vehicles with a minimum variety of hardware, and options provided through software configuration instead.

Award Winning Automotive Software Developer Selects Jama Connect® to Shorten Development Time, Increase Efficiency, and Sail Through Audit Preparation.

Apex.AI, founded in 2017 in Palo Alto, California, is a mobility software company, and makers of the ISO 26262 ASIL-D safety-certified software framework Apex.OS. As a pioneer in modern C++ software development for safety, they are the first organization to certify a modern C++ open-source product to ASIL-D. Their client list is extensive and prestigious, and they are backed by some of the leading venture capital firms in the world, including Lightspeed Ventures, Toyota AI Ventures, Volvo Ventures, and Airbus Ventures.

More about Apex.AI:

Headquartered in Palo Alto, CA in the heart of Silicon Valley with offices in Munich, Berlin, and Stuttgart, Germany and with employees worldwide.
Founded in 2017 in Palo Alto, CA
Expertise: Building robust, reliable, safe, secure, and certified software for mobility systems
Recent Awards for Apex.OS, the safety-certified automotive OS:
- Apex.OS wins two awards from the German Design Council (June 2021): “Best of the Best” award and “Innovation of the Year” award
- Apex.OS honored with the CES Innovation Award (Jan 2021)

With a mission to enable automotive developers to implement complex AI software, and enable AI developers to implement safety-critical applications, Apex.AI is an innovator in the automotive industry.

Comprised of alumni from top automotive, robotics, and software companies around the world, the Apex.AI team knew that development success starts with requirements management. That’s why they set out to evaluate the top requirements management solutions from the very beginning. The team had clear objectives and knew that their requirements management solution needed to:

Allow the team to create a centralized repository of requirements
Help them demonstrate compliance with stringent automotive standards like ISO 26262
Enable collaboration across a globally distributed team
Be a modern, cloud-based solution that all team members could use
Have industry acceptance and expertise

The team did not take the selection process lightly; they knew there was too much at stake. Apex.AI did an analysis of the full requirements management tools and software market and decided to evaluate Siemens Polarion and YAKINDU more in-depth.

After an in-depth analysis of these requirements management (RM) tools – including interviewing current users of these products – Jama Connect was selected as the solution of choice for the team for the following qualities:

End-to-end traceability from requirements all the way through to tests
Powerful, flexible solution that all team members can easily use
Industry-specific templates and expertise in automotive development
An easier path to compliance

“Why would an innovative automotive company consider Jama Connect? From my perspective, Jama Connect is the best of breed requirements analysis and requirements engineering tool… I would highly recommend it and I would use it again without any hesitation on any subsequent project. ”

Neil Langmead – Senior Functional Safety Engineer, Apex.AI

Jama Connect was also the only solution that had Living Requirements™ management, which allows teams to move away from static requirements trapped in disparate documents and creates a digital thread through upstream and downstream activities.

History and Future of the Automotive Industry

Cars have come a long way in the last 100 years. The first patented gas-fueled motor wagon of Carl Benz dates back to 1886. Electric Vehicles (EVs) date even earlier back to the 1830s. Although EVs disappeared between 1935 and 1960, they are back today while the internal combustion engine (ICE) will likely vanish in the future. There are obvious signs that the best times for ICE cars are over. Governments all over the world are paying subsidies for alternative energy vehicles and setting more restrictive greenhouse gas targets for the future. In Europe and Asia, cities are already restricting access to ICE vehicles. As a result, companies like GM, Ford, and VW are going all-in on electric now to assure their future growth.

Customer expectations are also shifting. Next-generation customers are expecting, for example, a connected, smartphone-like user experience. A McKinsey study shows that 36 percent of customers would willingly change brands for better digital and connected services. Another important point to mention is that flexible ownership and mobility services will likely replace traditional car ownership. For example, Tesla has a master plan to dominate the (automotive) world with robotaxis, and an army of startups are raising money to join the battle for future mobility. The rise of the mobility industry with buzzing Mobility as a Service (MaaS) might even make cars a commodity in the future.

New Revenue Models, New Technologies, and New Entrants

Automotive is a capital-intensive and small-margin business. What does capital-intense mean in this case? You need $1 billion to develop a car and another $1 billion to manufacture a car. So, the market is tough as a consequence. Tesla CEO Elon Musk recently tweeted: “Tesla & Ford are the only American carmakers not to have gone bankrupt out of 1000s of car startups. Prototypes are easy, production is hard & being cash flow positive is excruciating.”

No wonder the industry is aiming for a continuous revenue stream rather than a one-time sale. It’s apparent that technology is an enabler for new services and creates additional revenue sources in the industry. Connected car services, features on-demand, and upcoming automated driving subscriptions are examples of additional revenue sources.

Today’s most influential automotive technology is the electrification of the powertrain. It’s changing the industry because an electric powertrain is less complex than a combustion engine powertrain with all the moving parts and a catalytic converter system. Now EV entrants don’t have to catch up with 100 years of ICE development and have the advantage of a less complex and low-maintenance electric powertrain. This provides new EV entrants a lower barrier to enter the industry.

Today’s Automotive Industry Challenges

Most automotive industry players face distinct challenges caused by the ongoing changes. Here are the major challenges and struggles that key players experience in product development today.

Legacy OEMs

The development process in the automotive industry is still hardware-driven, resulting in a two- to six-year development cycle. To increase profitability and achieve a competitive advantage, OEMs are speeding up the development cycle. Because of the increasing number of features defined by software, this hardware-driven development process reaches its limitations. Shifting to an Agile development process with a shorter cycle is challenging for most OEMs because it needs a properly tailored Agile process for automotive. Another point to mention, there is often a disconnect between engineering, marketing, and customer expectations, or even resistance within the management to introduce features customers are looking for. As a consequence, legacy OEMs are struggling to switch to a more user-centric approach and prioritize features customer value.

Tiered Technology Supplier

In the past, OEMs wrote specifications for E/E systems and Electric Control Units (ECUs). At the next step, tiered suppliers developed the ECUs and verified them against the specifications. In the last step, the OEMs integrated ECUs from different suppliers and validated the system. That’s about 30-70 ECUs for a modern car, and it is quite a challenge. Today the cooperation model is changing, OEMs are challenging their suppliers to step up as technology partners. OEMs are now expecting system and technology co-development with partners to get a leaner process and save costs. As a consequence, suppliers are struggling to grow from a components supplier to technology partners and the related tackle for technology lead.

New Automotive Industry Entrants

New entrants in the industry join a capital-intensive and knowledge-intensive industry as described before. Besides, new entrants often develop E/E systems, domain controllers, and software in-house to differentiate their offering. This has its advantages, but one big disadvantage is the missing automotive engineering review by an external partner. Even if the executive management is aware of this challenge, they often have a hard time finding automotive experienced managers and developers for the required knowledge transfer. As a consequence, new entrants often struggle with implementing the quality and safety standards in the industry and the proper execution of the related automotive engineering methods.

Take Away

The automotive industry has changed a lot in the last few years, and this transformation is speeding up even faster today. Key drivers are changing regulations, new technologies, new revenue models, and new industry entrants. Connected vehicles, autonomous driving, the electrification of the power train, and shared mobility are mutually reinforcing developments in the automotive industry. Combined, these developments are changing the industry – some even call it the perfect storm to disrupt the industry.

To sum it up, the future of the automotive industry looks bright. Nevertheless, technology like autonomous driving, will bring new challenges like increased product complexity and safety concerns. It would be wise for all participants to use proper automotive engineering methods and tools.

To see more information specific to the automotive industry, we’ve compiled a handy list of valuable resources for you!

SEE MORE RESOURCES

Editor’s Note: This post about the high cost of failure when developing automotive electronics was originally published here on ElectronicDesign.com on June 5th, 2019, and was written by Jeff Darrow, who is involved with Automotive MOSFET Product Marketing at Infineon Technologies.

What’s The Price Tag on Failure in Automotive Design

The automotive market is driven by safety and reliability requirements. As vehicles rely more heavily on semiconductors for their functionality and safety-critical features, the concept of Zero Defects is gaining pace. This article will examine stringent quality requirements in the context of growing use of power MOSFETs. MOSFET device packaging is highlighted as a critical element in achieving the goal of Zero Defects.

Today, the scale of electronics in a typical car is staggering when compared to everyday items like mobile phones and notebook computers. Modern cars and trucks can have up to 100 networked microprocessors running 150 million lines of code with thousands of supporting active components.

Because nearly all automotive innovation requires electronic systems, semiconductors have become the fastest growing component in a modern vehicle, with cars containing more than $1,000 worth of semiconductor parts.¹ Electronic systems control all safety-critical functions such as engines, transmissions, steering, braking, and electric motors. With highly autonomous driving features coming to market now, complexity will further increase along with the risk for catastrophic electronic system failures.

Automotive Sets a High Bar for Quality

Early concerns about automotive component quality impacting vehicle safety were addressed with the formation of the Automotive Electronics Council (AEC)² Q100 and Q101 specifications. Established by OEMs Chrysler, Ford, and Delco Electronics, the AEC’s aim was to generate common standards in the automotive industry for the qualification of semiconductors.

These standards, along with those from the Society of Automotive Engineers (SAE), the Joint Electron Device Engineering Council (JEDEC), IEC/ISO, and the International Automotive Task Force (IATF), form the basis for component requirements in automotive applications. Many larger Tier 1 automotive manufacturers still have reservations about the adequacy of these standards and impose their own customer specific requirements (CSRs) on components.

AEC Q101 Standard Needs to Evolve

A feature of the AEC “Q” standards is that they’re only used for the one-time qualification testing of components in several categories (Fig. 1).

1. AEC Q standards are used for one-time qualification testing of components.

For example, testing is rigorously defined for discrete semiconductors, but this characterizes quality of samples and predicted reliability in service rather than setting defined limits for actual allowable rates of field failures. A failure rate that was acceptable in older vehicles with relatively few electronic components can be totally inadequate in a car with thousands of components.

Even with no defects identified in a qualification test, there’s no guarantee of reliability in typical environmental conditions from −40 to 250°F. Quality control and component reliability in the ongoing manufacturing process is left to the manufacturers’ internal quality system.

A typical AEC-Q101 qualification test uses 77 parts from each of three manufacturing lots. These are tested to defined hours or cycles with no failures, which represents lot Tolerance percent defective (LTPD) = 1% at 90% confidence level, or a maximum of 0.4% defective at 60% confidence level in production testing.

Such numbers would be an alarming yield in volume production and would signal an early-life product failure rate of 11 FITs (failures in 10⁹ hours) based on the Arrhenius equation with activation energy of 0.7 eV and 55°C use versus 175°C test temperature. A chi-squared distribution and 60% confidence level are assumed. In context, if the typical 30,000 electronic components in a vehicle all had this intrinsic failure rate, the vehicle population would have a mean time between failures (MTBF) of just three months.

Semiconductor Manufacturers Drive Toward Zero Defects

Power MOSFET use in vehicles has risen steadily and is predicted to increase from an average of a little less than 80 per car in 2017 to about 140 by 2025 (Fig. 2). Future EVs will contain around 400 MOSFET devices. MOSFETs are used in powertrain, body, safety and convenience applications, such as engine/transmission control, power distribution, automatic braking systems, power liftgate and window motors. Component failure in any of these applications could result in immobilization, injury, or, in worst case, loss of life.

2. Projected power MOSFET usage in vehicles. (Source: Infineon)

Assume the lot defect rate for power MOSFETs of 1% is screened-out in test to a residual rate of 0.001%. This would be 100 times better than the LTPD that’s tested with the Q101 specification. This 10-DPM (defect per million) failure rate would mean that about 700 cars in every million could be fitted with defective parts. With an estimated 1 billion plus cars on the roads today,³ the scale of the potential problem is again clear. Although 1 DPM has been seen in general market applications as a world-class target, 0.1 DPM heading to Zero Defects is the expected figure in automotive applications.

Quality Must be Designed In

To achieve the lowest defect rate, the manufacturer must have a quality culture that encompasses the entire product development and manufacturing process, from initial concept through design, production, and manufacturing, to final test and product fulfillment. People are central to the goal, as is full management commitment and training for all staff who are internally and externally audited to measure the trend toward Zero Defects.

An excellence program that emphasizes continuous improvement backed up with meaningful metrics must be put in place. A comprehensive datasheet and specific automotive design rules drive the product design and verification, with a validation plan to ensure that the part fits customer requirements and expectations.

Infineon, a leading supplier of automotive MOSFETs, is on its way toward Zero Defects for all of its products: DPM rates for automotive-grade MOSFETs are now proven to be less than 0.1 PPM, just below 50 PPB as of mid-2019.

he trend toward Zero Defects continues with the company’s adoption of leadless packages using internal top-side copper clips. The leadless MOSFETs are designed to meet the same reliability standards as Infineon’s leaded products and still offer higher power density. sTOLL, TDSON-8 (Super S08) and TSDSON-8 (S308) devices with this technology have exhibited high leadless-package reliability and low thermal resistance, along with having a smaller footprint and higher power density than a DPAK with equivalent R_DS(on).

The leadless package frame has a wide tin-plate area for good solderability and yields a best-in-class figure of merit for the ratio of chip R_DS(on)to package resistance (Fig. 3). Devices were analyzed in each package of the latest technology (SFET4/SFET5).

3. Leadless copper-clip termination yields the lowest chip to package resistance ratio.

The copper-clip termination approach also has the advantage of minimum inductance for reduced voltage overshoots and excellent EMI behavior to boost robustness in real applications (Fig. 4).

4. Leadless copper-clip termination has the lowest source and drain inductance.

Another marker for quality is the ability of the MOSFET encapsulation to adhere internally under temperature stress. Infineon’ OptiMOS devices have demonstrated the ability to withstand any delamination after 260°C preconditioning and 1000 thermal cycles (Fig. 5).

5. Infineon’s MOSFETs showed no delamination after preconditioning and temperature cycling.

Process Control and Stability is Key to Quality

High-performance design features are worthless without a production process control system that maintains quality and stability in manufacturing. Advanced statistical process control methods give real-time monitoring of key process parameters such as metal thickness and its line width, as well as resist coating and its line width. Outgoing product quality screening includes intelligent Part Average Testing with trend analysis of the effects of “outliers”—parts that meet the upper and lower specification limits but are beyond the expected distribution of results.

Yield loss in the various manufacturing processes is analyzed using statistical bin limits (SBL) for abnormally high (and low) figures. Wafers are optically inspected with pattern recognition to identify “at risk” die around areas where clusters of defects are occurring (Good Die, Bad Neighborhood).

Should a systematic defect be identified, the industry standard 8D (8 Discipline) problem solving sequence is invoked to prevent recurrence with systematic rollout to all locations and long-term follow-up of preventive actions (Fig. 6).

6. The “8D” problem-solving process.

Summary

With the volume of cars on the road only set to increase with a rapidly growing number of electronic components built in, traditional levels of component reliability are simply not sufficient when the consequence of failure could be loss of life. Zero Defects is the goal, and semiconductor manufacturers have leveraged AEC stress test qualification with internal design and manufacturing controls and testing to achieve the target.

Is Zero Defect possible? It is, as years of history showing more than 70% of automotive production running at Zero Defect has been achieved by Infineon. Is it worth the effort and cost? For driver and passenger safety, it’s worth every cent.

To learn more about how Jama Connect for Automotive can help your team simplify compliance, streamline development, and speed time to market, download our solution overview.

DOWNLOAD NOW

Today we’re excited to introduce Jama Connect for Automotive, a new solution designed specifically to accelerate product development for automotive engineering teams in the autonomous, electric, and traditional vehicle space. This new solution is designed to assist engineering teams in improving development lifecycles and to better manage requirements, risk, hazard analysis, and test management, while simplifying alignment to safety-critical standards, including ISO 26262.

The average life of vehicles on the road today exceeds 12 years, increasing the impact to the business of safety recalls and associated expenses to repair. Continued innovation in automotive product development, coupled with the need to meet safety-critical standards, creates a development environment where engineering teams must balance speed-to-market with product quality in support of functional safety standards.

As the requirements management platform for six of the top 10 electric vehicle startups on the frontlines of innovation, we recognize these challenges and have been working closely with companies in the automotive industry to offer an all-in-one solution. Jama Connect for Automotive helps engineering teams get set up quickly, allowing them to focus on product design and innovation, while reducing the costs and effort required to align their development processes to functional safety standards.

“Developers are balancing safety-critical standards and regulations with getting innovative products to market faster and in a highly disruptive and competitive climate,” said Josh Turpen, Chief Product Officer at Jama Software. “We’re excited to introduce our new solution designed specifically for automotive development teams, which will help facilitate the development process from the start. Jama Connect allows developers to hit the ground running with preconfigured templates and best practices built for automotive teams, saving critical time in the development process. This will be hugely beneficial for them especially now as teams continue to navigate the complexities of a remote work lifestyle.”

Jama Connect for Automotive accelerates the development lifecycle with key features including:

Automotive framework aligned to key industry standards and regulations: ISO 26262:2018, Automotive SPICE (ASPICE) and SEBoK
Best practices including procedure and configuration guides for automotive manufacturing activities
Document export templates including requirements specifications
Functional safety kit with TÜV SÜD certificate and report
Supply chain collaboration to enable an ongoing exchange of requirements between customers and suppliers
Training and documentation aligned to automotive regulations, that provide accelerated onboarding to set developers up quickly

The built-in templates and best practices guides provided in Jama Connect enable engineering teams to reduce development cycle times. Jama Software is helping to streamline development processes, ultimately accelerating new product launches to market while ensuring customers meet safety-critical standards and regulations for the highly evolving automotive industry.

Register for our upcoming webinar with Ansys to learn more about bridging the gaps in safety-critical product development.

How to Choose the Right Tool for ASIL D Requirement Management ISO 26262 / IEC 61508

Editor’s Note: This posts on tool selection around ASIL D requirement management for ISO 26262 / IEC 61508 was originally published here by LHP Engineering Solutions and written by Steve Neemeh. When the options for choosing a requirements management tool are endless, what factors should you be looking at to help make your decision? This article provides some concrete considerations you may use to guide your selection.

Which tools should I use for ASIL D requirement management ISO 26262 / IEC 61508?

There are a multitude of requirements management tools in the marketplace (e.g., IBM DNG, Siemens Polarion, Jama Software, Helix). How does an organization make the important decision of which is best for its needs when the options are endless or when using Microsoft Word/Excel or Google Docs for requirements management can be considered? Is there even one tool that can meet all of the organization’s needs? This blog will describe why selecting a tool based on one specific departmental need, such as requirements management, might be impractical.

To begin the search, here are five items that might be considered:

1. Cost of Tools

The range of costs can vary significantly. For a small organization, some of the larger toolchains may not be affordable. On the other hand, some of the smaller tools may not address parts of requirements management that are critical for ASIL D development.

2. Size and Distribution of the Organization

How many engineers need the tools and in how many locations? Some license agreements are floating so utilization could be optimized if the tools are used across multiple time zones (e.g. India and USA).

3. Number of Requirements and Requirements Hierarchy

Are there 100 safety-critical requirements or 5,000? Out of these requirements, how many of them are related to software, hardware, or test cases? How large is the HARA and how many safety goals are there? This will define the size of the requirements hierarchy.

4. Existing tools

The selection and integration of a new tool will inevitably impact the use of the exiting toolchains.

5. Full ISO 26262 workflow

Refer to V diagram.

requirements management ISO 26262 / IEC 61508

LHP’s requirements management V diagram for the Application Lifecycle Management toolchain

When researching tools for an organization, it is a common discovery that there is not one tool that meets all of the needs. The tools industry has not caught up with the complexity of the safety lifecycle. What is found in the marketplace are versions of Application Lifecycle Management (ALM) tools, but what is really needed is an LHP ecosystem-based Safety Lifecycle Management (SLM) toolchain. This SLM is based on guidelines for safety-critical development as defined in the 700+ pages of requirements, work products, and methods in standards such as ISO 26262 or the Safety of The Intended Functionality (SOTIF).

What is the Workflow for Functional Safety, ASPICE, and Other Safety-Critical Applications?

The V diagram covers the foundational items that need to be considered in addressing a standard like ISO 26262: project management, task management, and change management. In this particular case, four tools have been considered: ANSYS Medini, Jama Software, Atlassian JIRA, and National Instruments. All four tools provide partial solutions to meeting the needs of functional safety.

ANSYS Medini: HARA and systems-level modeling, as well as hardware metrics calculations (Parts 3 & 5 of ISO 26262)
Jama Software: Requirements management (required by ISO 26262, emphasized in Part 8)
Atlassian JIRA: Project management and change management
National Instruments Tools: Automated test and test scripting

By combining the engineering best practices with the tools’ strengths and considering an organization’s main drivers, a workflow can be defined; one that optimizes tool usage and reduces the load on engineers. Ultimately, to be successful within safety-critical development, an organization needs to develop against a standard while also reducing the labor associated with engineering and testing.

Without the latter, the cost and time for development escalate exponentially. Are engineers going to copy and paste data across tools? Are they going to have multiple versions of the same information across different toolchains? As the complexity of systems increases, a non-optimized toolchain can paralyze an organization and its development process.

In the absence of a commercial off-the-shelf fully-compliant SLM tool, the solution of integration tools can provide the same functionality. For this purpose, the tools provide methods of connectivity with REST (Representational State Transfer) API. An example of a REST API between Jama Software and JIRA is shown in the appendix.

Conclusion

When selecting a requirements management tool, it is crucial to consider the needs of the organization as a whole, the safety workflow, and the customization and connectivity for optimization of the tools. In a typical implementation of a safety-critical system, most organizations just consider one, or parts of one, of these critical items, causing large rework and tool spend that can otherwise be avoided.

Take-a-Ways

There is no one tool that meets the needs of requirements management in compliance with functional safety.
The tool capability varies greatly based on cost, and there is feature overlap between tools.
The holistic organization, not just a single department, needs to be involved in making the tool selection. The needs of each department: management, engineering, IT, manufacturing, regulators, and even certification agencies all must be considered.
The tool must be appropriate for the size and scale of the organization.
There are methods of automating data transfer that significantly reduce labor and cost on development programs (as shown in the appendix).
Successful organizations are going to get ahead by creating efficient workflows that allow them to release products faster and more economically in the new electric vehicle/autonomous vehicle (EV/AV) world of transportation.

Appendix: More Details About REST API

Both Jama Software and JIRA provide access to their cloud resources via Representational State Transfer (REST API). REST is a web-based application programming interface that exposes a set of Uniform Resource Locators (URLs) with which to carry out Create, Read, Update, Delete (CRUD) operations in the tool. LHP Engineering Solutions has implemented a Domain Object Model (DOM) connection for both Jama Software and JIRA with a third integration piece to connect the two. The integration piece is a configurable application that implements the customer use cases.

Benefits of Using REST API

Ease of implementation
- REST is a standard specification of how to access web resources
- All web and cloud-based tools expose REST APIs
- Returns data, as well as metadata, which allows for conditional and iterative processing
- Implemented in a JAVA wrapper making it configurable and portable to any system
Customizable authentication feature
- Simple user and password authentication if desired
- Simple user and access token authentication if more security is desired
- OAuth authentication is also available but not required
Portability of output to Web and other tool frameworks
- XML/JSON that any tool can consume
- XML/JSON are standard serialized data formats for web resources
- Web applications typically take XML/JSON as input files for data exchange, data migration, report building, etc.

REST API Complexities

Requires a non-standard mapping of attributes from Jama Software to JIRA and vice-versa. Each customer mapping will need to be customized.
- The REST specification defines what the API should do but not how it should do it. No standardization of data schema. Therefore, tools will have disparate data models.
- Attribute A in Tool A must be mapped via a mapping file to Attribute B in Tool B etc. This goes for attributes, links, attachments, and all data elements in each data model.
- A UI will have to be developed to allow for the mapping creation and management.

Standard Feature Set of REST API

Mapping and transfer of attributes and attachments from one tool to the other
- Data models are mapped as closely to 1:1 as possible
- UI to build and manage mappings
Scheduled and on-demand synchronization
- Synchronization data between toolsets via UI
- Synchronize data between toolsets by scheduling a task
Intermediate transformations (e.g., risk calculations)
- Calculating or transforming the data from the source tool before reaching the target tool
Linking from one tool to the other via hypertext links
- URLs from source resources to target resources and vice versa for traceability
Reports
- Since the REST APIs produce a consumable output, any reporting tool that can consume XML/JSON can be used to produce reports.
  - Jama Software reports
  - JIRA reports
  - Requirements gap analysis
  - Test coverage gap analysis
  - Requirements Traceability Matrix
  - Bug reports
  - Customized reports

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

Whether you’re just entering the automotive market or looking to improve your development process, you’ll need to become extremely familiar with the ISO 26262 standard.

In 2011, ISO 26262 was created to set the standard for the automotive industry and its suppliers around functional safety in electrical and electronic systems development. To address the industry’s rapid evolution and to ensure that these new electronic functions remain functionally safe in the new environment, the International Organization for Standardization (ISO) recently introduced a second edition of ISO 26262 in December 2018.

There are plenty of updates to sort through in the ISO 26262 2018 version, from building motorcycles to providing more guidance for the semiconductor industry.

Given that the first edition of ISO 26262 hung around for roughly seven years before it received an update, you can expect the most recent version to be the standard for driving quality and reducing risk in automotive functional safety for at least the foreseeable future.

What follows is a non-comprehensive overview to help familiarize you with important ISO 26262 second edition updates. However, it’s imperative that developers for the automotive electronics industry independently study and understand the updates and how their process must evolve to accommodate.

Expansion of the ISO 26262’s Scope

With the implementation of the second edition of ISO 26262, all road vehicles are now included – not just those with four wheels and a maximum vehicle gross mass of up to 3500 kg, as was the case in the first edition.

Motorcycles, trucks, buses, trailers and semi-trailers are now all covered in detail. Your development teams will need to familiarize themselves with the specifics. This webinar from Automotive World provides a good summation of the major changes with a particular focus on motorcycle and commercial vehicle development, and we’ll quickly touch on some of the key points.

Whereas passenger vehicles must adhere to an Automotive Safety Integrity Level (ASIL), the latest version of ISO 26262 introduces a Motorcycle Safety Integrity Level (MSIL). And, as such, the hazard analysis and risk assessment for motorcycles been altered to account for the differences. One thing worth noting is since motorcycles are so unique in their performance, there’s a larger emphasis placed on the responsibility of the rider versus the machine itself. For instance, whereas most cars are expected to still perform well in ice and snow, motorcycles are not, and so if a rider makes the choice to drive in those conditions, they are purposely accepting a higher degree of risk.

Since trucks and buses, on the other hand, are primarily defined by their larger size and mass, those factors tie into their controllability and, therefore, exposure to risk. For example, when a large truck is loaded with cargo, it’s going to have few issues with things like wheel spin on a steep hill than when it’s completely empty. And because different trucks, buses and semi-trailers all have unique purposes for use (for instance, long-haul semi-trucks versus city buses) and are typically exposed to different conditions and environments, the second edition of ISO 26262 makes distinctions between the base vehicle types of each. In terms of controllability, for example, concrete trucks should be able to withstand something like an unpaved construction site, whereas buses don’t regularly encounter that sort of terrain.

Software Tools Confidence Levels

Development software that’s used to create components for automotive systems must be qualified to do its job in a functional safety design environment. The qualification and classification requirements are described in Clause 11 of ISO 26262, Part 8. Software tools receive a certified qualification report if they are fit for purpose.

It’s worth noting that Jama Connect™ has already been certified fit for developing safety-related products according to ISO 26262 (up to ASIL D) by internationally-recognized testing body TÜV SÜD. That means Jama customers can use the TÜV SÜD certificate as an argument for software solution qualification in projects, instead of having to spend time qualifying it themselves. Jama is the first vendor that is both SaaS and Agile to receive the certification. You can read more about the benefits of this distinction here.

Learn how Jama Software worked with TÜV SÜD on our ISO 26262 certification process, and how you can lower the costs and risks of complying with functional safety standards, by watching our webinar.

Functional Safety and Cybersecurity

In response to increasing security concerns in connected devices in automobiles, ISO 26262 now requires a management plan that incorporates effective communication channels between functional safety and cybersecurity. These necessary channels have been identified at both the functional safety management level and at the system level for product development.

Guidelines for Semiconductors

The first edition of ISO 26262 did not include specific guidelines for semiconductors used in automotive application. This caused some confusion and led many automotive teams to create their own functional safety requirements for their semiconductor suppliers.

Now, a new section provides guidelines on and definitions for semiconductor components and semiconductor technologies used in automotive application. This should not only eliminate uncertainty, but also create uniformity when it comes to the design, verification and validation of semiconductors for the automotive industry.

What’s Not Included

One thing that was left out of the second edition is “the non-systematic and random safety issues that will occur with autonomous systems using neural networks.” Semiconductor Engineering explains that this is because a new standard coming later this year – SOTIF, Safety Of The Intended Functionality – will include new automation technologies for things like autonomous vehicles not covered in ISO 26262:2018.

To further assist in mitigating risks in the development process and maintaining compliance with automotive functional safety standards, learn how to mitigate common ISO 26262 mistakes with our whitepaper, “Top 15 ISO 26262 Snafus.”

Caption: Hyundai MOBIS showcases its latest infotainment and cockpit experience at CES 2019. Photo courtesy of Hyundai MOBIS.

Autonomous vehicles and related technologies were once again in the spotlight at the Consumer Electronics Show (CES) in Las Vegas. Here’s a roundup of some of the more notable announcements.

Nvidia and Mercedes-Benz Collaborate on Next-Gen Vehicles

Chipmaker Nvidia announced that Mercedes-Benz has selected the company to help realize its vision for next-generation vehicles.

In front of a crowd at CES, Sajjad Khan, Mercedes-Benz executive vice president, and Jensen Huang, Nvidia founder and CEO, outlined their plans for next-generation cars supported by artificial intelligence (AI) and the new breed of mobility products they will enable.

Nvidia is “creating a computer that defines the future of autonomous vehicles, the future of AI and the future of mobility,” Huang said at CES. The system will provide self-driving capabilities and smart-cockpit functions that will replace dozens of smaller processors inside current cars.

The partnership between the companies builds on a long-term collaboration. At CES 2018, the pair unveiled the cockpit of the future, Mercedes-Benz User Experience, which “infuses AI into everyday driving.” The feature is now included in seven car models and nine more are being added this year.

Hyundai MOBIS Introduces New Autonomous Driving Technologies

Automotive supplier Hyundai MOBIS introduced several new autonomous driving, eco-friendly, intelligent lighting, and infotainment and cockpit experience technologies.

Among the new innovations from the company are Virtual Touch Technology, interior infotainment controls capable of recognizing a driver’s gestures in the air instead of requiring a touch-screen. For example, in one given scenario, a driver could watch a movie on autonomous driving mode and use tap gestures in the air to select other movies or adjust the volume.

Another feature is Emotional Recognition Technology, an AI platform that automatically categorizes a driver’s or passenger’s emotions and alters the interior ambiance of the vehicle accordingly, catering to various moods while sharing the emotions of drivers or passengers in nearby vehicles also equipped with the same technology. The company says this can help avoid potential accidents among disengaged or distracted drivers.

In other lighting news, Hyundai MOBIS showcased its latest Communication Lighting concept. Communication Lighting uses an “Indicating Lighting Zone” to indicate when an autonomous vehicle is operating in self-driving mode. It includes a Communication Lighting Zone that uses LED, digital boards, headlamp projection and sound to communicate with nearby pedestrians and vehicles during a variety of driving scenarios. The company says it’s developing the concept to reduce the number of accidents related to use of autonomous vehicles.

Lastly, Hyundai MOBIS unveiled Hydrogen Fuel Cell Technology that generates electricity by combining hydrogen injected with fuel and oxygen, to power a vehicle that emits only pure water.

Udelv Unveils Latest Self-Driving Delivery Van

Udelv introduced the latest model of its Newton self-driving delivery vans and announced strategic partnerships with Walmart, Baidu, Marubeni and others.

The newest model of Newton is an advanced autonomous delivery van (ADV) that is the result of close collaboration between Udelv and Baidu, which also released its latest open autonomous driving platform at CES, Apollo 3.5.

Udelv says it will continue to leverage future versions of the Apollo platform modules to create its own autonomous driving algorithms for a variety of delivery applications. Already, Udelv’s first generation ADV model has successfully completed more than 1,200 deliveries in the San Francisco Bay Area for multiple clients, according to the company.

Daimler Rolls Out Enhanced Automated Truck

Daimler Trucks North America (DTNA) announced what it says is the first SAE Level 2 automated truck in series production in North America. Level 2 automation means the truck can perform lateral (steering) as well as longitudinal (acceleration/deceleration) control.

Automating acceleration, deceleration and steering reduces the likelihood of human error and collisions, the company says. The new technology in the trucks can also enhance driver experience by making the task of driving easier, and thereby improving comfort, DTNA says.

The company’s expertise in automation is backed by affiliate Daimler Trucks, which announced at CES that it’s investing more than half a billion dollars and creating more than 200 new jobs in its global effort to put highly automated trucks — those at SAE Level 4 — on the road within a decade.

Author Bob Violino is a freelance writer who covers a variety of technology and business topics. Follow him on Twitter.

The expansion of autonomous driving technology is surging, and new information on companies like Alphabet and Apple signal what we can expect in the years ahead.

Waymo’s California DMV Application Reveals New Technology Details

In April, California’s DMV began accepting applications for testing fully driverless cars. As of now, according to IEEE Spectrum, just two companies have applied so far: Alphabet’s Waymo and U.S./China startup JingChi.ai.

Through a public records request, IEEE got a hold of Waymo’s application to the DMV and it had a trove of interesting information. For starters, Waymo is asking for permission to test 52 fully driverless vehicles, all of which are Chrysler Pacifica hybrid minivans. For comparison, JingChi — the other company that has applied for the same permit in California — is shooting to just test a single vehicle, according to IEEE.

The DMV also necessitated that applicants outline some operational elements of their driverless vehicles. According to IEEE, Waymo says its cars are capable of navigating a majority of roads and parking lots, and speeds of up to 65 mph. They can also endure fog and light rain, but should the vehicles hit anything too intense, such as a monsoon or snow, they’ll typically pull over to the side of the road. (We’re guessing that’s to wait out the conditions.)

Another eyebrow-raising bit is how Waymo driverless vehicles interact with emergency services. Aside from yielding to ambulances, for instance, if a Waymo car gets approached from behind by a police car with flashing lights, the vehicle has the capability to pull over, unlock its doors, and roll down a window so the officer can safely approach and then communicate with Waymo’s remote support team. There’s also some details about how law enforcement can completely disable the vehicles, if necessary.

If you’re interested, head on over to IEEE to check out their full report, as it’s an extremely interesting read.

How Does an Autonomous Vehicle Navigate Unmapped Roads? Like This.

Many of us rely on some sort of mapping software, typically on our phones, to get us around these days, and driverless cars are no different. And that’s part of the reason why companies are testing driverless vehicles in urban and suburban areas, as they provide ample access to mapped roads.

But what if a driverless car needs to venture off into the many miles of a country where Google or Waze hasn’t meticulously mapped? Whether the roads are unpaved, unmarked or just way out in the backwoods, some researchers at MIT believe they may have the answer for when an autonomous vehicle needs to navigate these areas.

MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL), in a collaboration with Toyota Research Institute, has created MapLite, which is a framework that enables self-driving cars to navigate roads they’ve never seen before without relying on 3-D mapping technology.

According to MIT, MapLite uses GPS data and a number of sensors that observe conditions on the road for autonomous vehicles. When tested on unpaved roads in Massachusetts, MapLite reliably detected the terrain more than 100 feet in advance.

“The reason this kind of ‘map-less’ approach hasn’t really been done before is because it is generally much harder to reach the same accuracy and reliability as with detailed maps,” CSAIL graduate student Teddy Ort told MIT News. “A system like this that can navigate just with on-board sensors shows the potential of self-driving cars being able to actually handle roads beyond the small number that tech companies have mapped.”

Check out the technology in action below:

Apple Doubles Its Fleet of Self-Driving Cars

Apple is pressing the gas on its stable of autonomous vehicles.

Mac Reports has learned that Apple now has 55 self-driving test cars in California, which is up from 27 earlier this year.

That leaves Apple with the second largest fleet of self-driving cars in the state, behind GM Cruise which has a whopping 104. There’s not a lot of reliable information on what the notoriously secretive Apple has planned for the driverless car space, but any area where the Cupertino-based company is involved draws immediate interest.

To be clear, Apple’s permit to test self-driving cars in California still requires a driver to be present in the vehicle, unlike the applications from Waymo and JingChi mentioned earlier. Given Apple’s aggressive rate of scale right now in the autonomous vehicle space though, we wouldn’t expect them to be too far behind.