Car design defect - what’s reasonable?
Car design defect - what’s reasonable?
Author
Discussion

Heres Johnny

Original Poster:

8,167 posts

153 months

Monday 15th June 2020
quotequote all
The specific issues doesn’t really matter much but Tesla used a memory chip which has a finite life (designed for a number of reads after which they can start failing) resulting in some cars ending up with a bricked computer.

Under warranty, it’s no problem, they fix.
Out of warranty they want to charge, as they would, circa £1500.

Sone have pushed the argument using consumer law that it’s a design defect and as such Tesla should fix even out of warranty. The part was not automotive grade etc Some succeed with this. Tesla won’t admit liability however to it being a design flaw.

The question is how long can you make the argument? The warranty is 4 years/50k miles, whichever comes first. One would imagine 51k miles or 4 years and a day and you’d have a good case. But if the car had done 100k miles and was say 5 years old? Does the burden of proof change at some point? Tesla presumably can’t be liable for the part forever?

Jakg

4,040 posts

197 months

Monday 15th June 2020
quotequote all
Doesn't every part have a finite number of uses engineered into it? Thinking about obvious stuff like door lock mechanisms.

mmm-five

12,347 posts

313 months

Monday 15th June 2020
quotequote all
The customer will have one view of what's fair or a design flaw, and Tesla will have their's. Ultimately it'll be up to the courts to decide what's a fair 'life' for the part?

The diff in my Z4 needed replacement at 70,000 miles (5 years), BMW replaced it under my extended warranty. It went again at 140,000 miles (so sounds like a 70,000 mile lifespan), but it wasn't under warranty, so it was a £3k bill.

How long would you consider fair...6 years, 10 years, 20 years?

Do Tesla offer an extended warranty that covers this? If so, and with knowledge of this inherent fault, would it not have been wise to purchase such, or was it considered too expensive for the small risk?

If Tesla purposefully installed this part, knowing its limitations/lifespan then it might not be considered a flaw. Maybe Tesla consider it a 'wear & tear' part and as such is treated in the same way as tyres/brakes?

donkmeister

12,874 posts

129 months

Monday 15th June 2020
quotequote all
If you want a case of a manufacturer using a part that had a built in life, look into Mercedes and Bosch with the SBC braking system. The pump system had a cycle counter and once it reached a preset number the unit was declared out of life.
The resolution by Mercedes differed depending on various factors (not least the country the car resided in).
That's a slightly different situation but arguably both are latent defects. So you might find some precedents that help you argue your case.

Ransoman

884 posts

119 months

Monday 15th June 2020
quotequote all
The issue is not the memory chip itself, the issue is that the Linux OS of the Tesla carputer is configured to log everything. Every single OS event no matter how insignificant. When it fills up (Which happens pretty quickly) if then overwrites the older logs. Flash RAM chips such as those used in Solid State hard drives have a limited number of re-writes before the cell fails so the Tesla Carputer is literally wearing the chips out very quickly.

More info here:

https://www.youtube.com/watch?v=o-7b1waoj9Q

Heres Johnny

Original Poster:

8,167 posts

153 months

Monday 15th June 2020
quotequote all
Ransoman said:
The issue is not the memory chip itself, the issue is that the Linux OS of the Tesla carputer is configured to log everything. Every single OS event no matter how insignificant. When it fills up (Which happens pretty quickly) if then overwrites the older logs. Flash RAM chips such as those used in Solid State hard drives have a limited number of re-writes before the cell fails so the Tesla Carputer is literally wearing the chips out very quickly.

More info here:

https://www.youtube.com/watch?v=o-7b1waoj9Q
Yes I know the issue, and it can be argued as some have done that the choice of memory chip was a poor choice given the use it was put to. An extra $2 on the memory chip and the problem wouldn't exist. As a result there are a significant number of failures and Tesla have changed the logging to extend how long it will be before failing. But its still likely to fail when it runs out of rewrites.

Now mechanical parts you can accept have a wear and tear element, but I suspect (but don't know, hence the question) that few would expect a memory chip to wear out in 4 years and 50k miles. At an average speed of say 40mph the warranty runs out after 1,250 hours of use. If that was a mobile phone left on 24x7, thats only 52 days. (Of course a mobile phone isn't constantly writing to memory but nor is the car, and a car doesn't run 24x7 - except Teslas do run more than the average for software updates etc - but thats the sort of in service life expectancy before the warranty is gone which seems remarkably short for electronic components).

But that aside - consumer law - fit for purpose - is it simply a judgement of whats reaasonable to expect?






meatballs

1,140 posts

89 months

Monday 15th June 2020
quotequote all
Sounds like a design defect to me, could easily have designed it to take SDCard storage which has finite writes but extremely cheap and easy to replace.

Edit: Oh video 8:45 is the relevant bit. And they do use an SDCard for another part of the system. Muppets.

Edited by meatballs on Monday 15th June 19:01

Pegscratch

1,872 posts

137 months

Tuesday 16th June 2020
quotequote all
Heres Johnny said:
Yes I know the issue, and it can be argued as some have done that the choice of memory chip was a poor choice given the use it was put to. An extra $2 on the memory chip and the problem wouldn't exist. As a result there are a significant number of failures and Tesla have changed the logging to extend how long it will be before failing. But its still likely to fail when it runs out of rewrites.
One would argue you don't know the issue that well, as you confused me with your initial statement about it running out of reads. I'm not aware of a flash card that wears on read, but on write they all have a finite life. An extra $2 simply confirms to me that you do not understand the mechanics of this, as even enterprise SLC flash modules (probably a significant amount more than an extra $2) have a finite life which I would deem to be (on average) significantly lower than the lifespan of most cars.

Now, factoring in that they "could" have pushed this to a removable media is a possibility but bear in mind that removable media has varying levels of quality. Assuming you opt for an SD card style the chances of it lasting any reasonable amount of time is tending to zero as these are not inherently write-durable devices, and if you opt for a 2.5" hard drive (most sensible) you'll find people in there putting cheap drives in and reporting short lifespans again.

There's a middle ground somewhere, but it isn't a $2 more expensive chip and it isn't SD cards. I'm not sure what it is without spending some time working it through properly understanding DWPD and form factor constraints.

spookly

4,390 posts

124 months

Tuesday 16th June 2020
quotequote all
Pegscratch said:
Heres Johnny said:
Yes I know the issue, and it can be argued as some have done that the choice of memory chip was a poor choice given the use it was put to. An extra $2 on the memory chip and the problem wouldn't exist. As a result there are a significant number of failures and Tesla have changed the logging to extend how long it will be before failing. But its still likely to fail when it runs out of rewrites.
One would argue you don't know the issue that well, as you confused me with your initial statement about it running out of reads. I'm not aware of a flash card that wears on read, but on write they all have a finite life. An extra $2 simply confirms to me that you do not understand the mechanics of this, as even enterprise SLC flash modules (probably a significant amount more than an extra $2) have a finite life which I would deem to be (on average) significantly lower than the lifespan of most cars.

Now, factoring in that they "could" have pushed this to a removable media is a possibility but bear in mind that removable media has varying levels of quality. Assuming you opt for an SD card style the chances of it lasting any reasonable amount of time is tending to zero as these are not inherently write-durable devices, and if you opt for a 2.5" hard drive (most sensible) you'll find people in there putting cheap drives in and reporting short lifespans again.

There's a middle ground somewhere, but it isn't a $2 more expensive chip and it isn't SD cards. I'm not sure what it is without spending some time working it through properly understanding DWPD and form factor constraints.
They could start by using any type of storage that is replaceable and not soldered onto the board.
Then the importance of durability is reduced. If they used a pair of cheap hot swap 2.5 inch HDs then you could pull a failed one and replace it. Or a pair of micro sd sockets and do the same. If a card dies then simply replace it for a few quid.


Ransoman

884 posts

119 months

Tuesday 16th June 2020
quotequote all
spookly said:
They could start by using any type of storage that is replaceable and not soldered onto the board.
Then the importance of durability is reduced. If they used a pair of cheap hot swap 2.5 inch HDs then you could pull a failed one and replace it. Or a pair of micro sd sockets and do the same. If a card dies then simply replace it for a few quid.
I think RAID is a little overkill for a car, RAID controllers with hotswap capability are expensive and with 2x 2.5" drives would take up a lot of room.

Simply using an enterprise grade flash storage chip and turning down the logging to a reasonable level would solve the issue, Not permanently but certainly for the expected lifespan of the vehicle, whatever that is.

Pegscratch

1,872 posts

137 months

Tuesday 16th June 2020
quotequote all
spookly said:
They could start by using any type of storage that is replaceable and not soldered onto the board.
Then the importance of durability is reduced. If they used a pair of cheap hot swap 2.5 inch HDs then you could pull a failed one and replace it. Or a pair of micro sd sockets and do the same. If a card dies then simply replace it for a few quid.
The more you make it easily replaced, the more people will mess with it when they lack the qualifications to do so. If the car truly is logging everything then MicroSDs are unlikely to have the necessary write endurance to make it last even a year, they may not even have the write throughput to cater for it (although later Class 10 / U1/U3 have addressed it to the point where I'd be surprised if they couldn't keep up) or be able to sustain that throughput without overheating. Hot swap drives, great idea but then you fall into the trap of someone "hot swapping" them.

No matter the approach you are hitting a design problem. Packaging for a pair of 2.5" drives mean you'd be making compromises elsewhere to accommodate, you'd have the engineering headache and the support overhead of having that plus the software engineering complexities of making that possible. Then, by all accounts, 2.5" drives of any size, in pairs, and people are upset at the £1500 bill? You would probably push the cost of the vehicle up by at least that, then the cost of replacing them anyway would still probably be most of £1000 all labour included (as you wouldn't want them to be customer hot-swappable, cos they'll fk it up).

meatballs

1,140 posts

89 months

Tuesday 16th June 2020
quotequote all
The video explains that it's basically /var/ going to the chip, and that Tesla don't need to store/retrieve this anyway? The important logging data does goto and SDCard?

Most embedded devices mount /var on a tmpfs which uses volatile memory to prevent exactly these issues...

The SDCard would be buried fairly deep in the console so wouldn't be trivial for anyone to replace.

I know most embedded devices I've come across to last longer than 4 years.


Edited by meatballs on Tuesday 16th June 12:17

Pegscratch

1,872 posts

137 months

Tuesday 16th June 2020
quotequote all
meatballs said:
The video explains that it's basically /var/ going to the chip, and that Tesla don't need to store/retrieve this anyway? The important logging data does goto and SDCard?

Most embedded devices mount /var on a tmpfs which uses volatile memory to prevent exactly these issues...

The SDCard would be buried fairly deep in the console so wouldn't be trivial for anyone to replace.

I know most embedded devices I've come across to last longer than 4 years.


Edited by meatballs on Tuesday 16th June 12:17
Are those embedded devices you talk about designed to process enough data to drive a car all by itself down a road filled with other road users, whilst being completely disconnected from a reliable network which would enable them to offload any significant quantity of logging via stateless media onto a box designed to cater for that level of data?

Having done (a lot of) storage work, /var if used for temporary or rotational logging can generate spectacular amounts of IO. Bearing in mind that what some opinionated geek thinks who has tried to justify why it's a bad decision to do what they have done (which I haven't disputed, just that it is not an easy fix) as to what Tesla need to record to /var and what legally or functionally they're needing to write there are two different things. Tinfoil hatters (who are probably better off a long way away from Tesla) and their "I know my rights, you've no need to log these parameters" wibble would soon change their tune when Tesla need that information to potentially help identify any faults.

It probably ought to be designed to last more than four years, but you don't know how the situation has come about. When they updated software to enable autopilot, did they increase the logging exponentially which - on newer cars - saw them install SLC chips on a newer board revision, or was this the result of a requirement from the NTSB? Was it unintended consequences of an update?

Calling it a design defect neglects the opportunity that this was a culmination of a series of actions resulting in unintended consequences? Is it of any significance if it's called a wear component costing just over 1% of the vehicle's purchase price, when precedent for a number of manufacturers is that is small fry (4% for brakes on an E63 AMG, before you put ceramic option on it?).

Just because we aren't used to these things wearing, doesn't mean they aren't wear components. I stand by my assertion that without potentially significantly increasing the cost of the vehicle for negligible service cost gain, the "defect" may not be easily fixed.

Edited by Pegscratch on Tuesday 16th June 12:44

deckster

9,631 posts

284 months

Tuesday 16th June 2020
quotequote all
meatballs said:
The video explains that it's basically /var/ going to the chip, and that Tesla don't need to store/retrieve this anyway? The important logging data does goto and SDCard?
The number one rule of logging is log everything. It is impossible to know ahead of time what is important.

Can you imagine the outcry if it got out that, say, there was a major fault but they were unable to diagnose it because they didn't think that particular bit of data was important enough to log?

jet_noise

6,091 posts

211 months

Tuesday 16th June 2020
quotequote all
As others have pointed out it's writes that wear out memory devices.

HJs question is what's "reasonable". Whether it is fixable by alternate part spec. (a higher write capability) or usage (lower the number of writes required) is not the issue. A part that is failing (often AIUI) within the warranty period is clearly not fit for purpose.

It is normal automotive (and other industries too) practice to analyse and validate the st out wink of such systems to ensure they will survive the warranty period as a minimum and usually some other lifetime target e.g. 10yrs/100k miles (random target).
The observation that these parts do not do this suggests a failure in the design process. Could be as simple as the steps being missed or more complex such as the actual number of writes in real use exceeding design estimates.

Edit - I've jumped to the assumption that units are failing within the warranty period. HJ is this so?

Edited by jet_noise on Tuesday 16th June 12:56


Edited by jet_noise on Tuesday 16th June 12:56

xjay1337

15,966 posts

147 months

Tuesday 16th June 2020
quotequote all
Heres Johnny said:
Yes I know the issue, and it can be argued as some have done that the choice of memory chip was a poor choice given the use it was put to. An extra $2 on the memory chip and the problem wouldn't exist. As a result there are a significant number of failures and Tesla have changed the logging to extend how long it will be before failing. But its still likely to fail when it runs out of rewrites.

Now mechanical parts you can accept have a wear and tear element, but I suspect (but don't know, hence the question) that few would expect a memory chip to wear out in 4 years and 50k miles. At an average speed of say 40mph the warranty runs out after 1,250 hours of use. If that was a mobile phone left on 24x7, thats only 52 days. (Of course a mobile phone isn't constantly writing to memory but nor is the car, and a car doesn't run 24x7 - except Teslas do run more than the average for software updates etc - but thats the sort of in service life expectancy before the warranty is gone which seems remarkably short for electronic components).

But that aside - consumer law - fit for purpose - is it simply a judgement of whats reaasonable to expect?
My opinion is that a chip that wears out in around 4 years and has an average cost of replacement of £1500 or so is not in any way fit for purpose.

Poor chip choice or poor choice to constantly write logs.

BertBert

21,260 posts

240 months

Tuesday 16th June 2020
quotequote all
I think we have gone precisely round in circles to argue that it's a design flaw - stating the blindingly obvious, but missing the question. What liabiity do Tesla have for it? Is 4 years reasonable for component failure that is not designed to be a service item?
Bert

Baldchap

9,624 posts

121 months

Tuesday 16th June 2020
quotequote all
Tesla should have done what many Raspberry Pi users do (filesystem is on an SD card) - cache logging all the nonessential bits to operating memory and write en masse to the solid state chip at far less frequent intervals.

Sheepshanks

40,992 posts

148 months

Tuesday 16th June 2020
quotequote all
BertBert said:
I think we have gone precisely round in circles to argue that it's a design flaw - stating the blindingly obvious, but missing the question. What liabiity do Tesla have for it? Is 4 years reasonable for component failure that is not designed to be a service item?
Bert
There isn't a black and white answer - ultimately it'd be up to a Court to decide.

In the UK various laws say things about products being durable etc, but, and people often overlook this, they don't say the product shouldn't need repair (at customers' cost) during that time. Those lifetime laws really are only relevant if the product can't be repaired, or repair would be uneconomic.


Having said that, surely Tesla is being spanked over this in the US?

Durzel

12,999 posts

197 months

Tuesday 16th June 2020
quotequote all
Pegscratch said:
meatballs said:
The video explains that it's basically /var/ going to the chip, and that Tesla don't need to store/retrieve this anyway? The important logging data does goto and SDCard?

Most embedded devices mount /var on a tmpfs which uses volatile memory to prevent exactly these issues...

The SDCard would be buried fairly deep in the console so wouldn't be trivial for anyone to replace.

I know most embedded devices I've come across to last longer than 4 years.


Edited by meatballs on Tuesday 16th June 12:17
Are those embedded devices you talk about designed to process enough data to drive a car all by itself down a road filled with other road users, whilst being completely disconnected from a reliable network which would enable them to offload any significant quantity of logging via stateless media onto a box designed to cater for that level of data?
Probably not, but neither is all of the syslog crap that Linux logs there. It seems to be an obvious design flaw to write this log to flash storage, or to write it at all if it's unneeded.