Electronic and Software Defects in NC Car Accidents

The Bottom Line

Modern vehicles depend on millions of lines of software code to operate safety-critical systems like braking, steering, and throttle control. When that software fails, the consequences can be catastrophic -- and proving what went wrong requires specialized expertise that most personal injury attorneys do not have. In NC, electronic and software defect claims follow the same product liability framework as mechanical defects, but the technical complexity and the challenge of accessing proprietary source code make these cases significantly harder to prove.

ADAS Accidents by the Numbers

ADAS-related crashes are no longer rare edge cases. NHTSA's Standing General Order (SGO) on Crash Reporting requires manufacturers and operators of vehicles equipped with Automated Driving Systems (ADS) and Level 2 Advanced Driver Assistance Systems (ADAS) to report crashes that occur while the technology is in active use. As of November 17, 2025, the SGO database contains 5,202 reported incidents involving ADS or ADAS vehicles nationally, including 451 injuries and 65 fatalities.

These figures almost certainly undercount real-world ADAS-related crashes because reporting is triggered by airbag deployment, fatality, or tow-away -- lower-severity incidents where an ADAS false activation caused a fender-bender but the driver did not recognize the system as the cause go unreported entirely.

For NC residents, the trend matters. ADAS-equipped vehicles are now a substantial share of the state's registered fleet. When an AEB system phantom-brakes on I-40, a lane-keeping system steers a driver off US-74, or an adaptive cruise control accelerates into stopped traffic on I-77, the resulting crash looks like driver error until someone downloads the EDR data and looks at what the electronic systems were doing.

The Software-Dependent Vehicle

Today's vehicles are not just mechanical machines -- they are rolling computers. A modern car contains 100 million or more lines of software code controlling everything from engine management and transmission shifting to automatic emergency braking and lane-keeping assistance. The average new vehicle has over 100 electronic control units (ECUs), each running its own software.

This dependence on software means a single coding error, a sensor miscalibration, or a flawed algorithm can cause the vehicle to accelerate when it should brake, steer when it should hold steady, or fail to warn the driver of an imminent collision.

When these systems work correctly, they save lives. When they fail, the crash can be devastating -- and proving what happened inside the software is far more complex than examining a broken brake line.

Types of Electronic and Software Defects

ADAS Failures

Advanced Driver Assistance Systems (ADAS) are designed to supplement the driver's control. When they malfunction, they can create the very dangers they were designed to prevent.

Automatic Emergency Braking (AEB) failures fall into two categories. False negatives -- the system fails to detect an obstacle and does not brake when it should -- can cause rear-end collisions at full speed. False positives -- the system detects a phantom obstacle and brakes hard when there is nothing there -- can cause the vehicle behind you to rear-end you or can cause a multi-vehicle pileup on a highway.

Lane-keeping assist malfunctions can steer the vehicle into oncoming traffic, off the road, or into an adjacent vehicle. These systems rely on cameras that read lane markings. Faded markings, construction zones, wet roads, and direct sunlight can all confuse the cameras. If the system's software does not handle these conditions gracefully, the result can be a violent steering input at highway speed.

Adaptive cruise control failures can cause the vehicle to accelerate toward a stopped or slow vehicle when the system loses track of the vehicle ahead. Sensor obstructions (dirt, ice, heavy rain) can cause the system to "forget" the car in front of you.

Electronic Throttle Malfunctions

Most modern vehicles use electronic throttle control -- there is no physical cable between the accelerator pedal and the throttle body. The pedal sends an electronic signal to the ECU, which commands the throttle. If the software misinterprets the pedal signal, or if the position sensor sends incorrect data, the result can be unintended acceleration -- the engine surging to full power without driver input.

Unintended acceleration cases gained national attention with large-scale investigations involving multiple manufacturers. The causes have included software bugs that misinterpreted sensor data, electromagnetic interference that corrupted throttle signals, and floor mat interference that the electronic system failed to override.

Infotainment System Interference

Modern infotainment systems are deeply integrated with vehicle control systems. A frozen touchscreen can disable climate controls, backup camera displays, and in some vehicles, critical vehicle settings. More dangerous, infotainment system crashes have been documented to interfere with the vehicle's CAN bus -- the internal communication network that connects all electronic systems. When the CAN bus is disrupted, safety-critical systems can lose communication with each other.

OTA Software Update Problems

Over-the-air software updates allow manufacturers to modify vehicle software remotely, without requiring a dealership visit. While this capability enables fast safety fixes, it also creates new risks.

An update that changes how the AEB system calibrates its sensors, how the electronic stability control responds to wheel slip, or how the throttle maps pedal input can introduce new defects into a previously functioning vehicle. Key legal questions in OTA update cases include:

• Adequate testing: Did the manufacturer run the update through the same validation process required for original software under ISO 26262, or was it pushed after abbreviated testing?
• Driver notice: Was the driver meaningfully informed that the update changed safety-system behavior, or did the update description say only "performance improvements"?
• Ability to decline: For safety-critical updates, can the driver postpone installation? Some manufacturers push updates automatically, removing driver choice.
• Post-update monitoring: Did the manufacturer track incident reports after the update's rollout and respond to early signals of problems?

If the answer to any of these questions is "no," the foundation for a negligence claim under § 99B-2 and a failure-to-warn claim under § 99B-4 is significantly strengthened.

NC's Reasonable Care Standard Under § 99B-2

North Carolina does not have strict products liability -- manufacturers are not automatically liable for every defect. Instead, NC applies a negligence standard: the manufacturer must have failed to exercise reasonable care in designing, manufacturing, testing, or warning about the product.

Applied to software, reasonable care under § 99B-2 requires:

1. Hazard analysis: The manufacturer must identify foreseeable ways the software could fail and assess the risk each failure mode poses. Under ISO 26262, this is a formal process called HARA (Hazard Analysis and Risk Assessment).
2. Testing to the hazard level: Safety functions classified at the highest ASIL level (D) must be validated against extremely stringent failure-rate targets. Shortcuts in software validation are evidence of unreasonable conduct.
3. Adequate response to known defects: When a manufacturer learns -- through internal testing, customer complaints, or NHTSA SGO reports -- that a system has a defect, it must act reasonably to fix the problem. Sitting on knowledge of a dangerous defect can support a punitive damages argument.
4. Clear warning of limitations: The owner's manual and any in-vehicle warnings must accurately describe what the system cannot do. Overstating capability -- saying a system "prevents collisions" when it only reduces collision severity -- can create a failure-to-warn claim.

Inadequate warning claims are particularly important in ADAS cases because the gap between how these systems are marketed and how they actually perform can be enormous. A system marketed as "Full Self-Driving" or "Autopilot" that requires continuous driver supervision creates a foreseeable risk that drivers will over-rely on the system -- exactly what § 99B-4 is designed to address.

The Statute of Repose

For most vehicle defects, the 12-year clock runs from the date of first sale. However, OTA updates may create a separate repose trigger: if the update itself introduced the defect into a previously safe vehicle, the 12-year period arguably begins when the manufacturer pushed the update, not when the vehicle was manufactured. This is an unsettled area of NC law worth discussing with your attorney if your vehicle is older than 12 years.

Proving a Software Defect Caused Your Accident

Software defect cases are among the most technically challenging product liability claims. The defect is invisible -- it exists in lines of code, not in a broken physical component. Proving what the software did wrong requires a specific investigative approach.

The Event Data Recorder

The vehicle's event data recorder (EDR) is the starting point. The EDR captures snapshots of data in the seconds before and during a crash, including throttle position, brake application, vehicle speed, steering angle, and in newer vehicles, the status of ADAS systems. This data can reveal whether an electronic system was active, whether it gave a command inconsistent with the driver's input, and what the sensors were reporting.

Preserving EDR data is time-critical. Some EDRs store data that can be overwritten by subsequent driving events. If the vehicle is started and driven after the crash -- even just onto a flatbed tow truck -- data may be lost. Your attorney should arrange for immediate EDR download by a qualified technician.

Expert Witnesses

Software defect cases require expert witnesses that most personal injury attorneys never encounter. You need:

Automotive software engineers who can analyze the vehicle's source code (if obtainable through discovery), identify the defect, and explain how the code deviated from its intended function. These experts must understand real-time embedded systems, sensor fusion algorithms, and automotive safety standards like ISO 26262.

Sensor and electronics experts who can evaluate whether the hardware (cameras, radar, lidar, wheel speed sensors) provided accurate data to the software. A software defect case may actually be a sensor defect case -- the software performed correctly, but the sensor fed it bad data.

Accident reconstruction specialists who can correlate the electronic data with the physical evidence of the crash to construct a complete picture of what happened and when.

The Source Code Challenge

The most significant obstacle in software defect cases is accessing the manufacturer's proprietary source code. Manufacturers guard their source code as trade secrets and will fight aggressively to prevent disclosure. Your attorney must obtain a court order compelling production, typically under a protective order that limits who can review the code and how it can be used.

Without the source code, your expert may need to rely on "black box" analysis -- examining the inputs and outputs of the system without seeing the internal logic. This is possible but more difficult and may be less persuasive to a jury. Courts can also order in camera review, where the judge reviews the code privately to determine what portions are relevant and must be produced -- a process that balances the manufacturer's trade secret interests against your right to evidence.

Building the Evidence Chain Step by Step

1. 1

   Preserve the vehicle and do not drive it

   The moment an ADAS malfunction is suspected, the vehicle must be secured and not driven again. Every mile driven after the crash risks overwriting EDR data and altering the electronic system's state. Have it towed to a secure storage facility -- not a dealership lot where the manufacturer can access it unilaterally.

2. 2

   Download the EDR data within 48 hours

   Retain an EDR technician to download the event data recorder as quickly as possible. The Bosch CDR tool and similar equipment can retrieve ADAS system states, throttle and brake data, and steering inputs from the seconds before impact. This data is the foundation of your expert's opinion.

3. 3

   Send a spoliation letter to the manufacturer immediately

   Your attorney should send a written demand to the manufacturer, its dealer network, and any connected-vehicle service provider within 72 hours, requiring preservation of all vehicle data logs, OTA update records, sensor calibration data, and internal defect reports related to your vehicle's make, model, year, and software version.

4. 4

   Retain an automotive software expert before suit is filed

   An automotive software engineer can review the EDR data, identify whether the ADAS system behavior is consistent with a known defect, and determine what source code and internal testing records would be needed to prove the claim. Their preliminary opinion shapes the discovery strategy.

5. 5

   Pursue source code and internal testing records in discovery

   Once in litigation, request production of the system's source code, version history, internal defect reports, FMEA (Failure Mode and Effects Analysis) documents, ISO 26262 hazard assessment records, and OTA update release notes. Expect resistance; be prepared to file a motion to compel and argue for in camera review.

6. 6

   Search the NHTSA SGO database and complaint database for similar incidents

   Search NHTSA's complaints database (safercar.gov) and SGO database for reports of the same failure mode in the same vehicle make, model, year, and software version. Ten similar complaints filed before your crash is powerful notice evidence -- it shows the manufacturer knew or should have known about the defect.

Who Is Liable?

The chain of liability in electronic and software defect cases can be complex.

The vehicle manufacturer bears primary responsibility as the integrator. They selected the components, wrote or approved the integration software, tested the system, and sold the final product to the consumer. Under NC's product liability law, the manufacturer is liable if they were negligent in any of these steps.

Third-party software developers may bear separate liability. Many ADAS systems, infotainment platforms, and electronic control modules are designed by specialized technology companies, not by the vehicle manufacturer. If the software developer's code contained the defect, they can be named as a defendant.

Sensor and component manufacturers are liable if their hardware failed and provided incorrect data to the software system. A radar unit that misreads distance, a camera that fails in certain lighting conditions, or a wheel speed sensor that gives erratic readings can cause the software to make dangerous decisions based on bad data.

The Regulatory Landscape

NHTSA has been increasingly active in investigating electronic and software defects. The agency has opened investigations into automatic emergency braking failures, unintended acceleration events, and ADAS malfunctions across multiple manufacturers. NHTSA investigations and any resulting recalls are valuable evidence in your case because they demonstrate that the federal safety regulator identified the same type of defect you experienced.

The NHTSA SGO database is publicly searchable. If your vehicle's make, model, and software version appear in the SGO database with incidents matching your crash type, that record is admissible and substantially strengthens the notice element of your negligence claim.

For autonomous vehicle accidents involving SAE Level 3 and above technology -- where the vehicle itself (not a driver assistance feature) is driving -- the liability analysis becomes even more complex, as the vehicle manufacturer may bear liability comparable to that of a human driver.

What to Do If You Suspect an Electronic or Software Defect

1. Do not drive the vehicle again. Additional driving can overwrite EDR data and alter the electronic system's state.
2. Have the EDR data downloaded immediately by a qualified technician before any data is lost.
3. Document the electronic system's behavior. Write down exactly what happened -- did the brakes engage on their own? Did the steering pull suddenly? Did the throttle surge? Details matter.
4. Preserve the vehicle. The vehicle's electronic control units, sensors, and wiring must be available for expert examination. Read more about preserving evidence in defect cases.
5. Check for NHTSA complaints and recalls related to the electronic system you suspect malfunctioned.
6. Find an attorney with specific experience in electronic defect cases. These cases require technical expertise that goes beyond traditional product liability. Ask about their experience with EDR data, source code discovery, and automotive software experts. The technology section of this site covers how dashcam evidence and telematics data may also support your case.

Frequently Asked Questions

Frequently Asked Questions

What are common electronic and software defects in vehicles?▾

Common defects include automatic emergency braking (AEB) failures or false activations, lane-keeping assist malfunctions that steer you into oncoming traffic, electronic throttle control issues causing unintended acceleration, infotainment system glitches that freeze or disable critical controls, adaptive cruise control failures, and OTA (over-the-air) software updates that introduce new bugs. These systems rely on sensors, processors, and code that can all fail.

How do I prove a software defect caused my accident in NC?▾

You need expert witnesses in automotive software engineering, access to the vehicle's event data recorder (EDR or "black box"), and often the vehicle's source code. The expert must demonstrate what the software was supposed to do, what it actually did, and why the deviation caused or contributed to your crash. NC requires proof of negligence under § 99B-2, so you must show the manufacturer failed to exercise reasonable care in designing, testing, or updating the software.

Who is liable when a software defect causes a car accident in NC?▾

Potentially liable parties include the vehicle manufacturer (who integrates and sells the final product), the software developer (if a third-party company wrote the code), the sensor manufacturer (if a sensor provided incorrect data to the software), and the company that pushed an OTA update. NC product liability law applies to all parties in the chain of design and manufacture.

Can an OTA software update that causes an accident create liability?▾

Yes. If a manufacturer pushes an over-the-air software update that changes how the vehicle's safety systems operate and that change causes or contributes to an accident, the manufacturer can be liable. This is a relatively new area of product liability law. Key issues include whether the update was adequately tested, whether the driver was informed of the changes, and whether the driver had the ability to decline the update.

What role does the event data recorder play in a software defect case?▾

The event data recorder (EDR) -- the vehicle's "black box" -- captures data in the seconds before, during, and after a crash. This data may show throttle position, brake application, steering angle, AEB activation, and other electronic system states. In a software defect case, the EDR data can reveal whether the electronic system malfunctioned. Preserving and downloading this data before it is overwritten is critical.

If my ADAS system braked for no reason and I was rear-ended, who is at fault?▾

The manufacturer of the ADAS system may be primarily liable if the system created a phantom-braking event. Under NC law, a manufacturer that designs a system with a known false-positive rate without adequate safeguards can be found negligent under § 99B-2. The driver behind you who failed to maintain a safe following distance may also bear some fault. NC's contributory negligence rule means your attorney must carefully evaluate whether the manufacturer can argue you were responsible for not disabling the system or failing to warn following drivers.

Can I get access to the manufacturer's source code to prove my case?▾

You can seek production of source code through discovery in litigation, but manufacturers vigorously resist these requests by claiming trade secret protection. Courts can order in camera review -- a judge examines the code privately and determines what must be produced. Your attorney can also seek a protective order that limits who can view the code and how it can be used. Without source code, your expert may need to rely on "black box" analysis of EDR inputs and outputs, which is more difficult but still possible.

What is the statute of repose for a software defect claim on a car I bought several years ago?▾

N.C. Gen. Stat. § 1-46.1 provides a 12-year statute of repose running from when the product left the manufacturer's control. For most vehicles, that is the date of first sale. However, if an OTA update introduced the defect into a previously safe vehicle, the 12-year clock may begin from the date of that update -- not the vehicle's manufacture date. This distinction matters significantly for owners of older vehicles that received recent software updates.

Does a NHTSA investigation into my car model help my NC product liability claim?▾

Yes, significantly. A NHTSA investigation or recall is admissible evidence that the federal safety regulator identified the same defect you experienced. It establishes that the manufacturer had notice of the problem, which is relevant to whether warnings were adequate and whether the failure to act was willful. Even if no recall was issued, NHTSA consumer complaint data showing dozens of similar incidents before your crash can establish the manufacturer knew or should have known.

What is ISO 26262 and why does it matter in my case?▾

ISO 26262 is the international standard for functional safety of automotive electrical and electronic systems. It requires manufacturers to classify hazards by risk level and design safety-critical systems like AEB to meet strict failure-rate targets. If a manufacturer failed to follow ISO 26262 during design or testing, that failure is powerful evidence of unreasonable conduct under NC's § 99B-2 negligence standard. Your software engineering expert will likely frame their opinion around what ISO 26262 required and where the manufacturer fell short.