No items found.
March 15, 2023

How to Accelerate Self Driving Vehicle Development using Model-Based Design

Accelerate Self Driving Vehicle Development using Model-Based Design

Self-driving: it’s the can that keeps getting kicked down the road.

As far back as the 1950s, people anticipated this would be a staple of the future. In 2023 the question of whether self-driving vehicles will ever achieve mainstream utility is still top of mind for many people. 

But it’s not obvious what the path from here to there looks like.

This is mainly because the engineering processes required are different for self-driving vs. traditional vehicles. A large operational design domain (ODD) requires more extensive testing and data than current processes allow. 

So what’s the solution? Generally, self driving car companies will choose between one of two engineering philosophies: 

  • Physical prototyping, typically solved through reducing the operational design domain (ODD) for testing
  • Model-based design, which circumvents most of the problems by moving testing to a virtual environment

In this article, we’ll weigh the pros and cons of these two approaches. Finally we will ask: which option presents the best path toward mainstream self driving vehicle utility? 

Why is self driving prototyping so complicated?

Before we dive into solutions, let’s briefly go over the problem we’re trying to solve: the complexity of the operational design domain (ODD).

Traditionally, automotive engineering companies emphasize real-world testing as their primary form of quality control. This involves designing and creating a prototype, then subjecting that prototype to different scenarios - including various terrains, courses, maneuvers, crashes, etc. - to test the various operational and safety features of the vehicle.

While physical prototyping has been effective in the past, it does have some drawbacks: 

  • Time-consuming. The real world can only move so fast. This means that every test happens in real time - which can be quite a lot given the number of necessary scenarios a vehicle has to encounter.
  • Cost. Physical vehicle testing involves manufacturing not only the prototypes, but also constructing testing facilities, engaging employees in the testing process, and the cost of prototype repair or replacement. 
  • Physical limitations of prototyping. Plus, let’s say you’re testing a safety feature that requires crashing the vehicle. That prototype then becomes unusable until you can repair or replace it, which further increases the cost and time. 

The problem is that for all the problems that arise with physical testing, self-driving vehicles exacerbate those problems. The main reason for this is that the standards for AV performance are high, both from a consumer and legal standpoint.

There’s good reason for this. Full self driving technology is in its infancy right now, and people simply don’t trust it as much as they trust their own two hands on the wheel. It is just not good enough yet. 

When considering how safe self-driving vehicles have to be to earn that trust, the general response is: “safer than a human driver”. The problem here is that traditional automotive engineers haven’t had to take charge of testing the driver. They’ve just had to test the vehicle, and trust that the driver has the experience, knowledge, and reflexes to handle emergency situations.

Self driving vehicles don’t have the luxury of a human driver to fall back on. So testing them is a much more extensive process. In fact, it requires exposure to practically as many environments as a vehicle could encounter - which means that the ODD of self driving vehicle testing has expanded astronomically. 

So all those problems we mentioned earlier - cost, time, etc.? With self driving prototyping, those issues are many times worse. 

READ MORE: If you want to read in more detail about the growing complexity of ODD as it relates to autonomy, check out our recent article on the topic

ODD reduction: How engineers address the problem

So how do engineers address this problem? As we mentioned, there are two primary solutions, the first of which we’ll address right now.

If ODD has become too large for physical prototyping to handle, then the solution is to simply reduce the ODD back to a manageable size. 

This can happen in a number of ways. 

Reduce use cases

One approach is to limit the number of use cases that an autonomous vehicle can be exposed to. This dramatically reduces the testing and sets expectations with consumers that the device is only suitable for use in specific environments.

Some examples of this are automated valet AVs or assisted parking services. These systems can address the problem in three ways:

  • Limited physical setting that’s painstakingly mapped and remapped so the autonomous vehicle knows its exact location at any point
  • Lower speeds (typically between 5-20 mph), where accidents lead to little damage and liability
  • Limited impact radius, where a vehicle can shut down safely without impacting other actors on the road

Another example are AVs set to drive on highways only, which have additional benefits like:

  • Relatively constant speeds, which can be safer than constant starts and stops
  • Limited external variables to complicate navigation
  • Reduced liability in the event of an accident (e.g. no pedestrians, fewer vehicles)

Reduce geography

One other way to reduce ODD for self driving cars is to limit the geography a vehicle operates in. Testing AVs in specific cities or urban areas can equip them to operate in those environments. 

Of course, this limits the vehicles transportability, as they’re only equipped to handle a specific locale. Additionally, changes in the shape and structure of the city - like construction, demolition, or road work - will require further testing so the vehicle can adapt. 

Augment autonomy with human correction

For most use cases, the solution to the autonomy problem is to eliminate the desire for full utility. Rather, the idea is to combine self-driving technology with human drivers to augment and improve their safety.

While this is a laudable and necessary step, it involves kicking the can down the road and avoiding the main issue at hand. 

Ultimately, the challenge with ODD reduction is that it fails to address the core issue underlying autonomous vehicle testing. That is, AV testing is ultimately an engineering process problem, not a business process problem. The best solution is to overhaul the engineering process to rise to the occasion without inflating costs too heavily. 

Model-based design (MBD): a scalable alternative to address ODD concerns

Enter model-based design: an approach to system design that moves the record of authority from paper, documents, and files to digital models managed in a data-rich environment. 

Rather than place the physical prototype as the primary method of testing, model based design prioritizes the testing of central digital models that are subjected to scenarios and use cases in virtual environments.

In model-based design, engineers create highly detailed maps of hardware and embedded software components, organizing them into subsystems and units. The model may be described in a hierarchical, event-based, or layered manner to outline the flow of communication and interdependencies within a system. 

Engineers use modeling and simulation tools to create mathematical or physics-based representations of all subsystems, parts, components, pathways, and algorithms.

The purpose of a digital model is to capture design and manufacturing behavior to evaluate performance, costs, and other considerations before kicking off a new program. The model can be used to eliminate risks, which can include:

  • Mean time before failure
  • Reliability
  • Cost
  • Probability of success

Because the model is entirely digital, engineers can make iterations in real time with virtually no additional costs. This, combined with virtual simulations and testing, allow engineers to identify and solve the vast majority of problems before they even arrive at a physical prototyping stage. 

Model-based design enables virtual implementation of all aspects of vehicle development, including:

  • Tracking
  • Design specifications
  • Implementation
  • Verification and Validation
  • Deployment

By using a virtual model and testing in virtual environments, model-based design helps to overcome key challenges in automotive engineering processes generally. However, for cars with self driving capabilities, it is a critical solution to the problems mentioned earlier. 

The benefits of model-based design, specifically for autonomous vehicle development, including the following. 

Increased engineering productivity

Model-based design streamlines engineering processes to mitigate waste, risk, and increase overall productivity. This can be realized in a number of ways:

  • Reduce the number of physical prototypes that need to be developed, as engineers can verify and optimize system design before hardware prototyping
  • Accelerate the development process by catching bugs and failures early in the development process, before they can impact other parts of the design 
  • Streamline and coordinate communication among various teams and functions, ensuring a single source of truth and that every change propagates down to the various teams
  • Improve functional safety, as virtual prototyping and testing across numerous edge cases can be performed efficiently, safely and cost effectively

Decreased costs

With physical prototyping, every aspect of the testing process incurs its own costs. Because it’s entirely digital, model-based design is a much more cost-effective testing process. 

That’s not to say that model-based design doesn’t have its own unique costs. For instance, the process only works when every team is on board. This requires extensive training and onboarding, not only for new methodologies, but new tools and technologies as well.

However, without model-based design, creating viable mainstream AVs is cost prohibitive. That, plus the net cost savings in the areas mentioned above, make it a no-brainer in terms of ROI. 

Shorter development timelines

Most companies that adopt model-based design/model based development find their development time reduced by at least 30%. In some cases, it’s as high as 50%. There are a number of reasons why this is the case:

  • Better communication across groups
  • Catching errors earlier in the process
  • Minimized financial impact of necessary changes

What’s more, model-based development enables the primary testing environment to be virtual. This means that engineers can run thousands of tests in the time it would take to do a single test of a physical prototype. 

While traditional waterfall testing methods struggle to handle the expansive ODD of autonomous vehicle development, model-based design can collect all the necessary data and make necessary changes without breaking a sweat. 

Based on time and cost efficiency alone, model-based design is by far a better approach to self driving car development. 

How to adopt model based design effectively

As with any engineering process, model-based design is far from a silver bullet. It requires intentional action and investment to realize the benefits we listed above. 

If you want to adopt model-based design within your organization, here are some steps to set yourself up for success:

  • Make the upfront investment. New training, onboarding, and technologies don’t come cheap. However, if you make the effort to bring your entire team up to speed, you’ll find they’ll become more efficient, communicative, and efficient. 
  • Prepare for complexity. Self driving vehicles require a large number of subsystems and components, which makes it difficult to fit all the components together into a single model. This will require creative solutions from your engineering team. 
  • Invest in the right tools. This is key! There are a number of underwhelming model-based design tools on the market, many of them with limited integration options, high set-up time, and prohibitive costs. Make sure you’re choosing a solution that works for your needs. 
  • Develop written processes and policies. Model-based design is a relatively nascent technology. There are no set rules for the process. So be sure to document your organizational preferences, expectations for each team, etc. Intelligent and thorough documentation is critical to ensure validation and verification later on. 
  • Communicate early and often. Model-based design projects fail because teams don’t communicate at key points throughout the process. Encourage and empower each team member to come up with as many ideas as possible in the early states to facilitate thoughtful discussions. 
  • Build for continuous improvement. The beauty of model-based design is its scalability. Lean into this strength, and incorporate continuous improvement into your engineering process and culture. 

Also, remember that simplicity is key. The goal of your models should be to highlight key areas of risk that need to be resolved. Overcomplicating the process is counterproductive and will only slow you down. 

Final thoughts on model-based design

Model-based design offers engineering teams the processes, technologies, and tools necessary to rise to the occasion and create products that are viable in a variety of scenarios and environments. 

Rather than throw in the towel by limiting your ODD for autonomous vehicle development, be sure to use a comprehensive autonomous vehicle solution that will enable you to meet your rollout objectives.

The self-driving revolution is here. Are you ready to lead the charge? 

Learn more about Collimator’s model-based design tools—including high performance computing, seamless integrations, code generation and ready-to-use function blocks. Plus, feel free to schedule a demo with our engineering team. 

Frequently Asked Questions

See Collimator in action