Addressing Automotive Safety Issues with Model-Based Systems Engineering
Did you know that a modern luxury car can require upwards of 150 computers to operate all of its features?
The systems we rely on are becoming increasingly complex, as more functionality from AI and automation is added. Engineers need tools that not only manage complexity but also help ensure safety—particularly in high-risk industries like automotive, aerospace, and tech.
MIT xPRO has explored how model-based systems engineering (MBSE) is being used to produce functional safety deliverables. Specifically, the Model-Based Systems Engineering: Documentation and Analysis course looks at how MBSE is used to undertake safety analyses and whether it can create safety-related deliverables in the automotive industry.
We spoke with lead instructor Dr. Bruce Cameron and industry expert Amardeep Sidhu from Magna International about how MBSE is helping engineers build safer, more reliable systems in an increasingly complex world.
A Focus on Automotive Safety
Amardeep, a key contributor to the course, explained that while machine learning-driven features like automatic emergency braking have become standard, the rise of advanced technologies like lanekeeping, speed maintenance, and automatic parking brings new layers of risk that engineers need to anticipate and design for from day one.
As the driver’s role shifts from direct control to a supervisory role, the stakes for AI decision-making grow. The Ford BlueCruise investigation, for example, is examining the potential role of automated driving features in two fatal collisions. A key safety concern is object misclassification—when a system misinterprets something in its environment. For instance, a driverless car mistaking a plastic bag for a solid object and braking abruptly could trigger a rear-end collision.
Scenarios like this one are foundational in hazard analysis, where engineers must assess the likelihood of such events and the potential consequences for everyone involved.
Safety even comes into play with technologies like generative AI-powered intelligent voice assistants. Distracted driving claims thousands of lives annually. Chatting with an AI assistant might not require averting one’s eyes from the road, but it still carries risks.
Beyond in-vehicle features, AI can also support hazard identification and risk assessment in the automotive industry, helping to generate a wide range of realistic operating scenarios. “AI is really good at generating those scenarios,” Amardeep said. “You can give it certain parameters, and it’ll output different conditions—city streets, highways, rainy weather, metro areas—and even provide images to visualize those environments.”
Exploring MBSE’s Potential in Real-World Contexts
The course includes two case studies to support participants’ understanding of how MBSE can enable system safety in real-world contexts: Toyota’s sudden unintended acceleration (SUA) incidents and Aurora’s highly autonomous self-driving technology.
“Toyota was a very public case, and so we took the opportunity in the course to build a model around it. That modeling can help examine the interplay between what really happened and how the system was designed to operate,” Dr. Cameron explained. “The case was analyzed by NASA and independent safety experts, and there’s a lot of documentation available for model development and analysis,” Amardeep added.
The case centers on Toyota’s electronic throttle control system (ETCS) and explores how hardware or software faults—individually or together—can contribute to catastrophic system failures like unintended acceleration. Participants engage in modeling, using SysML tools to perform analyses, and assess potential failure points in the ETCS architecture.
The second case study focuses on Aurora, a company developing self-driving trucks with high levels of autonomy. Aurora is particularly compelling because the company has publicly shared its safety argumentation, developed using goal structuring notation (GSN), a formal method used to organize and present the safety case.
“It gives an opportunity to see how a company trying to bring a highly autonomous product to market is structuring its argument to prove that the system is safe. Not many OEMs approach it that way,” Amardeep said.
In comparing these two cases—one retrospective, the other forward-looking—the course examines both the consequences of safety failures and the proactive measures being taken to prevent them.
“Participants have the chance to examine an existing model that we have built and determine its strengths and weaknesses. There is also a project whereby they build out a set of safety deliverables using an MBSE model on a system of their choosing,” said Dr. Cameron.
How MBSE Supports Functional Safety Analysis and Hazard Identification
While there are many ways to approach safety analysis and hazard identification, MBSE presents several advantages over traditional document-based systems engineering. “With document-based systems engineering, there is a different tool for requirements, different tools for analysis, and yet another set for testing and documentation. Everything is very distributed,” explained Amardeep.
MBSE aims to integrate these activities into a single environment. This holistic approach is valuable when safety is treated as a system property—something that spans the entire design and development process. “Safety touches every activity of the product design—from requirements elicitation all the way through testing, development, and production,” Amardeep said.
Consider a scenario where an OEM intends to offer the same ADAS features on both the gas and electric variants of its flagship SUV for a given model year. From the perspective of the ADAS functionality, this results in modifications such as the addition or removal of certain signals in the functional architecture related to the powertrain. These changes initiate what is known as an impact analysis—an evaluation of how the modification affects the broader system and its associated safety case.
Traditionally, an impact analysis would require combing through hundreds of documents—a time-consuming and error-prone process. With MBSE, it can be much more efficient. “You change a stakeholder requirement, and you can see the change propagate through the system—through the architecture, the software, the hardware, the production, the release notes, and the documentation that goes to the customer,” Amardeep said. “That’s a key way MBSE helps reduce errors and manage safety in increasingly complex systems.”
Defining system boundaries and operational situations
MBSE supports foundational elements of functional safety work, such as defining system boundaries and identifying operational situations. The value lies in how it integrates system architecture, regulatory requirements, and environmental factors into a unified modeling framework—one that informs the subsequent hazard analysis.
Engineers can use SysML (Systems Modeling Language) when defining system boundaries to create standardized diagrams that visually represent the system’s structure, interfaces, and requirements. These models provide a shared framework that encourages cross-team alignment and ensures safety considerations are built into the architecture from the start.
MBSE also supports the integration of regulatory requirements. For example, if a product is being launched in Europe and the US, certain regulations like FMVSS or ISO standards are documented as stakeholder requirements.
“It's not that these things were impossible before with document-based systems,” said Amardeep. “But what MBSE does is enable a common language. When I say ‘internal block diagram’ or ‘interface,’ my colleague knows exactly what I mean.”
Ultimately, the system boundaries and operational parameters defined through MBSE—including environmental conditions, performance requirements, and cost constraints—become essential inputs for the hazard analysis and risk assessment phase of the safety development process.
What Participants Can Expect to Take Away
The purpose of this new module on functional safety is to enable participants to have a deeper, systems-level exploration of what it means to design for safety in complex, real-world environments.
For Amardeep, the goal is to shift learners’ mindsets. “I want learners to develop a deeper appreciation for the balance between innovation and safety,” he said.
“There’s a tendency to focus on compliance—checking the boxes for required standards—but safety is more than regulation. It’s a design principle. It needs to be intentionally integrated at the very beginning, not added as an afterthought.”
Dr. Cameron framed the objective through the lens of system thinking. “Systems engineering is a search for completeness,” he explained. “We are not content to operate a system assuming everything works well—nor to solve subsystem problems in isolation. The whole purpose is to consider emergent properties, both good and bad, at the system level, and figure out a process by which these can be surfaced, triaged, and mitigated.”
Becoming an effective leader in model-based systems engineering requires more than knowing how the tools work. It requires knowing when and how to use them. If you’re an engineer looking to make better engineering decisions amid growing complexity, consider enrolling in MIT xPRO’s four-course program, Architecture and Systems Engineering: Models and Methods to Manage Complex Systems.