Automotive Chip Shortage is as much about the "type of chips" as it is about overall capacity

[leadeater]

6 hours ago, RedRound2 said:

If the rest of the ECU remains the same, i dont see why extensive and thorough validation is required for the rest of the components.

Because your views on product testing and liability is incredibly naive which is why we have having this conversation in the first place. Product testing != component testing. A sum of automotive grade and validated components does not make an automotive grade product, a change of an automotive component for another automotive component doesn't mean you can forgo product testing.

 

Also you aren't testing "the rest of the components" you are testing the ECU product because the product had a component change and due to that it necessitates being product tested again. You're confusing components and their validation which is important for parts selection and the product itself which is the ECU.

 

We will forever go round in circles on this because of your fundamental lack of understand of product testing and your misguided belief that validation of the processor alone is adequate, which it is not. So unless you are able to realize this is not about chip validation this will go nowhere.

 

5 hours ago, CarlBar said:

Because thats the legal requirement to meet the specification and other legal ohh ahh.

I don't know how this wasn't abundantly clear 

[leadeater]

21 hours ago, RedRound2 said:

At what point did I even say that TSMC does crash tests? I said specs like temperature, vibration, etc usually are rated from foundry, but somehow you extrapolate that into TSMC testing car crash tests.

When you said only the processor needs to be validated to validate the ECU because you think changing out the processor for a new revision and not carrying out the product testing again is acceptable, therefore in your mind chip validation is functional equivalent and acceptable amount of testing for an ECU component change so why would I not extend this misguided belief to the extreme to illustrate the absurdity with such a thing. You constantly mistake parts validation, like for the process chip done by the foundry as acceptable enough for forgo the product testing again but the chip in isolation, not in the product, has passed it's validation.

 

The problem here is the assumption that this new processor revision will function exactly the same in circuit in the product and the product doesn't need updating for this new revision because of those changes in the processor revision, something you wouldn't know without testing the product again. Any number of things could change due to this parts change, this new processor revision could require more signal filtering because it's throwing errors.

 

This is why I gave that stupid example because it's equivalent to what you are saying. It is your belief that component validation alone is enough therefore product changes do not require product testing to validate the change to the product and means it's still operating correctly, which is just an assumption not a known.

 

Not doing this testing would be a direct violation of IATF 16949.

 

And for whatever reason you harp on about how the code that runs on an ECU is simple/basic and so the product testing will also be basic, completely not true. And no matter how basic the code/software is on these is has no bearing at all on the requirement to product test after a critical component change like the processor and is entirely unrelated to the specific first reply to you I made and what this conversation is about, not what you want it to be about.

 

So tell me what on earth your point about software has to do with the above origin of this conversation, zero for me. Validating the processor at the chip foundry doesn't validate the above, not at all. So please just stop it, you don't even know or remember what this was about in the first place. You bringing up Arduino like it matters was just a waste of time and my reply about it is specifically and still is that it would fail the product testing I was talking about. Anything else about that is irrelevant. If it wouldn't pass the above ECU product testing then it can't do it, end of story. It was end of story 1000 replies ago but you like to argue dead and wrong points.

 

21 hours ago, RedRound2 said:

And what point did I say no testing was required? Please be a little competant and answer that. I said a year of testing was more than enough for very basic modifications. Stop putting words in my mouth with your random delusions.

When you can't get past the fact that processor chip validation isn't enough and you keep banging on about how the chip is validated which yet again for the product validation is irrelevant. This is I think the third time I've had to repeat component validation only applies to parts selection.

 

Let me give you a really easy example, Gigabyte GP-P750GM & GP-P850GM power supplies. Parts were changed, the parts themselves were all validated and in spec, due to the parts change these power supplies no longer meet the 80 Plus Gold certification that the original design and test unit sent away for validation did. There were in fact many different internal parts changes (all capacitors), revisions, for these power supplies. Swapping out capacitors for different brand and model ones of the exact same capacity rating and temperature rating and listed as functionally equivalent when looking for parts supply means you are now making the very same mistake as Gigabyte because of the differences in manufacturing and composition means they react differently in an actual product in an actual circuit. 

 

So let me ask you, does a basic capacitor change in a PSU that is of the exact same specifications and rating as the one it replaced mean you only need to validate the capacitor, which has already been done by the manufacturer of that component, or do you need to test the entire product (the PSU i.e.  the ECU) again?

 

Are you going to give the same answer as Gigabyte? Will you make the same assumption? (like you have been)

 

21 hours ago, RedRound2 said:

Honestly, all my conversations with you have been a huge colossal waste of time. You can't admit when you're wrong and you cling onto some random ideas you come up with in my head just because two disconnected words were in your field of vision

How about you because you've been very wrong and misguided this whole time making huge assumptions based on naive beliefs like chip testing alone is enough. it's not period, end of discussion. If you want to reply or play off that you weren't wrong you can go ahead I'm done forever with you on this topic, go be another Gigabyte if you want, you're as wrong as they were (well their ODM but w/e). And if you think all my conversations with you have been a waste of time I probably won't disagree with that, you're almost always wrong or never actually figure out what the conversation was about and go down your own path, this conversation case and point on both counts.

[CarlBar]

7 hours ago, leadeater said:

I don't know how this wasn't abundantly clear 

 

Makes sense to me. You and i have some experiance of safety culture, and you given your self stated IRL responsibilities, you have probably had to write a risk assessment or two.

 

Safety culture when you get right down to it is really, really, really, anal retentive in a lot of ways about virtually everything. But it's like that because at some point in the past something went wrong and people got seriously hurt or killed. Every inane rule is written, quite literally in blood. It cares FAR more about catching that 1 in a million chance of something being off than it does about being convenient, cheap, or nice the other 999,999 times.

 

But if you've never experienced it and seen/been educated on some of the things behind a system like that's rules, it seems like usless crud just designed to be as obtuse and annoyingly unnecessary as possibble.

 

The hard part seems to be the issues us and him/her/it/? where having communicating this to each other. As someone with ASD i get communication issues.Even if it still annoys me no end.

 

 

 

In a lot of cases if you want to release a product containing some form of electronics you have to show that the assembled electronics package when inside the entire assembled product meets the specifications. But if you buy that electronics package from someone your only allowed to buy electronics that are certified to meet the specification when tested in isolation. So however your buying the electronics package from has to have certified it. And they're only allowed to buy certified components from foundries to assemble it out of.

 

So by the time the end user gets the product the electronics have gone through 3 different rounds of certification, (with typically required random inspections whilst in production, meaning every 1 in X parts is pulled off the production line and fault tested to destruction). It seems pointless to a layperson, but there's super rare edge cases that can and have killed or maimed people so they insist on all that testing to make sure such edge cases do not recur again.

[igormp]

2 hours ago, CarlBar said:

The hard part seems to be the issues us and him/her/it/? where having communicating this to each other. As someone with ASD i get communication issues.Even if it still annoys me no end.

My bet is that they're a software dev, and just can't get their head around how hardware/software dev for critical embedded systems can be so different and slower than your regular webapp, not even to mention all of the bureaucracy around it.

[CarlBar]

2 hours ago, igormp said:

My bet is that they're a software dev, and just can't get their head around how hardware/software dev for critical embedded systems can be so different and slower than your regular webapp, not even to mention all of the bureaucracy around it.

 

I don't know about them being a dev, but i hear you on the bureaucracy. To use a hyptotheticalsoftware example for anyone else still following along.

 

Imagine when Bethesda released Skyrim there was a written up legal requirement it had to have zero bugs, (bad balance sure, but no actual bugs). If that was handled safety culture style every possible game element would have a written test procedure that would have to be completed on every possibble hardware configuration it will run on and repeated several time on each hardware configuration and every step of it has to be documented down to the smallest detail. And if you want to then release any kind of patch (even if it's just swapping one texture for a higher quality one), the entire test series has to be re-run from scratch complete with every scrap of documentation. And neither the original release nor any of the patches can be released until the regulatory agency has seen and signed off on the associated paperwork.

 

And if that sounds completely unreasonable. Well now you know why safety critical stuff likes to stick to a very limited ranges of hardware with an equally limited range of software. because it's the only way to get things to the point where it is physically possibble to run the tests you need to do before you can release the product.

[RedRound2]

19 hours ago, leadeater said:

You bringing up Arduino like it matters was just a waste of time and my reply about it is specifically and still is that it would fail the product testing I was talking about. Anything else about that is irrelevant. If it wouldn't pass the above ECU product testing then it can't do it, end of story. It was end of story 1000 replies ago but you like to argue dead and wrong points.

Again on the Arduino

Maybe there's a bit of my fault here, but someone pointed out about the rewriting the code, or software on newer node. With that pretense, I talked about Arduino being able to do the basic function of an ECU, with implication being the code is easy to rewrite and the whatever logics they use will remain the same. The comparison is supposed to end here, but you drag into the validation part which was never my intent. And you keep insisting that that's what I meant, when it's not. And about validation, I will write below

19 hours ago, leadeater said:

When you can't get past the fact that processor chip validation isn't enough and you keep banging on about how the chip is validated which yet again for the product validation is irrelevant. This is I think the third time I've had to repeat component validation only applies to parts selection.

And doesn't this get covered in a year of testing? Can you show me something that says it take x amount of hours to test.

 

I will lay out my understanding here

 

For example I need to change the ECU that controls the fuel injection system. And all I need to change is the processor, because the older one is harder to get and my source moved on from the old tech.

For a worst case scenario, I will also assume that it's a huge jump and the PCB layout has to be tweaked as well and the microcode needs to be rewritten

Rewrite the code for the new platform and tweak PCB (~probably 2 weeks, if im being generous) and procure ssamples to be tested

Conduct a lab test to see if it does what it is supposed to do. Leave it running under various throttle positions, accelerations, break, etc (basically unit test the whole thing - which I should assume they already have). Maybe leave it running for a month 24/7 stress test (I dont know how these sensors are rated to last under sustained - but im taking the worst here)

Now this is ready to be field tested. Procure more of the same. Swap existing test mules with just the new ECU and run tests. For months, two months, three, six months, whatever. (again I assume they already have a detailed test procedure and plan laid out). Towards the end of testing prepare and submit all paperworks and documentation. A geneorus six months to whatever body wants to do the test.

 

I dont think they're going to submit the car to the NHTSA to do a crash and airbag test, because one ECU was revised.

 

Now tell me what part of this I got it wrong? Maybe I didnt add cases where things do go wrong. Okay, then delay it by a year. Whatever it is. You can't be lagging the industry by more than 5-10 years worst comes worst. 

 

What goes on in the real world (the main arguments I brought out for this whole topic)

 

And ECUs frankly dont matter to the user experince. In fact you dont get any benefits from better efficient processors. But what about things like infotainment? It is correct to assume, that isolated systems like infotainment doesn't have such extensive validations. Yet, they still used technology from 5-10 years ago.

 

Car companies, like Tesla iterate much faster than any of these I described above. They frequently change small componets and aspects of the car all the time. They literally seem to just randomly swap parts in the manufacturing plant. They wouldn't be legally allowed to do this if there was iron clad restrictions on any of these things like flight systems and rocket engines

 

19 hours ago, leadeater said:

How about you because you've been very wrong and misguided this whole time making huge assumptions based on naive beliefs like chip testing alone is enough. it's not period, end of discussion. If you want to reply or play off that you weren't wrong you can go ahead I'm done forever with you on this topic, go be another Gigabyte if you want, you're as wrong as they were (well their ODM but w/e). And if you think all my conversations with you have been a waste of time I probably won't disagree with that,

Says the person who literally just cherry picks two three lines off my replies and extrapolates completely out of context items.

19 hours ago, leadeater said:

you're almost always wrong or never actually figure out what the conversation was about and go down your own path, this conversation case and point on both counts.

"Always wrong" - I chuckled a bit here. Rather than proving me wrong, you take tanget and and assume that I said something that I never did. Your main forefronts of argument was how the Arduino would not pass envrionment tests and how I at some point claimed that nothing needs to be tested and validated, both of which I did not assert at any point. Rather question your logic with my observation of what the actual reality is with cars today on the road. Upon which you kept harping on the Arduino and insults "because I dont know or understand". And you keep writing the same thing with more words and in a more covoluted way and I end up falling for this trap and waste my time replying to things I never even claimed. That's the pattern with you I've always had

 

 

[igormp]

36 minutes ago, RedRound2 said:

Rewrite the code for the new platform and tweak PCB (~probably 2 weeks, if im being generous)

More like 2 months, being generous. Again, that kind of environment is way slower than your usual software dev one.

 

38 minutes ago, RedRound2 said:

But what about things like infotainment? It is correct to assume, that isolated systems like infotainment doesn't have such extensive validations. Yet, they still used technology from 5-10 years ago

Infotainment systems isn't what's holding car manufacturing back, and those are already being swapped every year. What you complain about old tech is just older or lower end models.

On the other hand, the remaining of the microcontrollers are old, like 20 years old or so because there's NO NEED for newer stuff, it simply makes no reason and those are usually more expensive.

40 minutes ago, RedRound2 said:

Car companies, like Tesla iterate much faster than any of these I described above. They frequently change small componets and aspects of the car all the time. They literally seem to just randomly swap parts in the manufacturing plant.

My guess it that they simply have a single platform that is meant to be iterated upon. With your regular car platforms, that's not doable because they're shared between different manufacturers and meant to last 4~10 years due to R&D costs. They also have far fewer models than other manufacturers and are not as modular AFTER DONE as other cars (see something like RichRebuilds, getting parts and exchanging those in a tesla is a royal pain).

My bet is that tesla is still using the same platform since day 1.

 

[RedRound2]

8 minutes ago, igormp said:

More like 2 months, being generous. Again, that kind of environment is way slower than your usual software dev one.

I'm not entirely convinced over this. While my experience with embedded has been mostly limited to microcontroller programming, and I do know that embedded C can get very complicated, I still find it quite hard to believe it would take this long to rewrite.

And this is assuming it's all very bare metal coding, and if it isn't, most of the same things should work as they will likely order the same family of components.

 

But anyways for argument sake, let that be the case. Still they change to new nodes at least when they do a full car revamp that happens every 5 years.

8 minutes ago, igormp said:

Infotainment systems isn't what's holding car manufacturing back, and those are already being swapped every year. What you complain about old tech is just older or lower end models.

On the other hand, the remaining of the microcontrollers are old, like 20 years old or so because there's NO NEED for newer stuff, it simply makes no reason and those are usually more expensive.

It's not lower end cars. Higher end cars still have pretty sub-par infotainment. These days mostly because of CarPlay and Android Auto we can sort of ignore it. But honestly my experience with both of those also pretty much suck and it's only when Tesla came out it was even imaginable to think of something as feature rich.

 

The super high end ones have good infotainment, since Tesla. The S class and BMWs do have. But still, to keep putting 5-7 year old processors in low end cars takes real effort tbh.

8 minutes ago, igormp said:

My guess it that they simply have a single platform that is meant to be iterated upon. With your regular car platforms, that's not doable because they're shared between different manufacturers and meant to last 4~10 years due to R&D costs. They also have far fewer models than other manufacturers and are not as modular AFTER DONE as other cars (see something like RichRebuilds, getting parts and exchanging those in a tesla is a royal pain).

My bet is that tesla is still using the same platform since day 1.

 

But according to leadeater, even if a capacitor is changed the whole car needs to be tested again and whatever certifications they got before are rendered invalid.

 

The word platform here is starting to get confusing. But I'm pretty sure Tesla has changed enough with their internals that the new plaid S is nothing like the 2012 one. Heck there are a lot of difference between the 2021 Model 3 and the initial 2018 one, apart from the exterior design

[igormp]

29 minutes ago, RedRound2 said:

But anyways for argument sake, let that be the case. Still they change to new nodes at least when they do a full car revamp that happens every 5 years.

They don't care about actual process nodes, they care about what's the cheapest piece of ECU that can get the job done. If the company that sells those (such as bosch) updated, validated it and manages to sell it to them for a good price, so be it.

 

Also I posted many pages ago that there are still MANY fabs doing processes in >45nm, and most microcontrollers use those processes because they're cheaper and they don't need the performance/power consumption that lower nodes offer.

 

31 minutes ago, RedRound2 said:

It's not lower end cars. Higher end cars still have pretty sub-par infotainment. These days mostly because of CarPlay and Android Auto we can sort of ignore it. But honestly my experience with both of those also pretty much suck and it's only when Tesla came out it was even imaginable to think of something as feature rich.

 

The super high end ones have good infotainment, since Tesla. The S class and BMWs do have. But still, to keep putting 5-7 year old processors in low end cars takes real effort tbh.

Tesla is not a thing in my country, but GM, Renault and Audi cars have had excellent infotainment systems for more than a coupler years now IMO. Still, that has nothing to do with the thread point about manufacturing issues, it's just some manufacturers cheaping out or non on a non-essential feature.

 

35 minutes ago, RedRound2 said:

But according to leadeater, even if a capacitor is changed the whole car needs to be tested again and whatever certifications they got before are rendered invalid.

Tesla may do that in parallel with their existing product line. Having fewer products being made means that you can get more done with each of those.

36 minutes ago, RedRound2 said:

The word platform here is starting to get confusing. But I'm pretty sure Tesla has changed enough with their internals that the new plaid S is nothing like the 2012 one. Heck there are a lot of difference between the 2021 Model 3 and the initial 2018 one, apart from the exterior design

Yeah, even though I said they probably have a "single platform", I don't believe it's actually the same thing as the initial 2018 one, but I don't think they have "fixed" model numbers for each and just keep incrementing continuously until it's a totally different thing, and you can't exactly say when the "version change" happened.

Other manufacturers just have a single versions that stays the same for 4~10 years, with minor changes during that time (infotainment systems and some facelifts, usually).

[leadeater]

2 hours ago, RedRound2 said:

And doesn't this get covered in a year of testing? Can you show me something that says it take x amount of hours to test.

I didn't actually say it takes more than a year, already agreed that it would be done within a year. The total amount of product test hours can likely to be more than a year but that really does depend on how many ECUs they require to test as part of their end to end testing procedures.

 

Give this a read, it'll probably answer many questions you have or at least is a good basis of understanding.

 

https://assets.vector.com/cms/content/know-how/_technical-articles/diagnostics/DiVa_GME_ATZelektronik_200811_PressArticle_EN.pdf

 

Quote

A total of about 350 test sequences are defined in the GM Diagnostic Specification. The test sequences cover both “good case” and “bad case” tests. A large share (approx. 80%) of the test procedures are covered by fully automated tests in DiVa. An application-specific user input is required for 45 (15%) of the test procedures defined in the GM Diagnostic Specification. In such cases, DiVa pauses test execution and asks the user to put the ECU in the required state. The remaining 5% of test procedures are not supported by DiVa and must be tested either manually or by other means. This includes tests that would put the rest of the test procedure at risk (e.g. generate EEPROM errors and detect them) or would cause long-term changes to the ECU (e.g. an ECU without calibration data).

 

 

Note above: Simple things still require A LOT of test cases, hence how simplistic the code/software is isn't a good indicator of how much testing is required.

 

 

What I can't tell you and they don't actually state in the document is how many of each ECU they actually test for the entire end to end process, neither do they mention long term reliability testing but that's probably only going to happen on the original ECU revision and no revisions of it later, just the above testing which would likely be measured in months end to end.

 

Pulling a number out of my ass, with all the testing and documentation along with the sign offs etc probably like 3 months I guess. Really depends on how much of the full entire process you want to account for when talking about how long it takes to test an ECU, the actual technical test phase of actually doing it isn't long.

 

2 hours ago, RedRound2 said:

I dont think they're going to submit the car to the NHTSA to do a crash and airbag test, because one ECU was revised.

I never said that had to be done, literally all I said was the above testing in the linked document needs to be done because the only thing you ever talked about was processor chip validation at the foundry which is not the above testing. My point was if you change the processor then you have to repeat the above testing, nothing more nothing less.

 

That and this kind of testing actually is a big deal, that was my other point.

 

2 hours ago, RedRound2 said:

how I at some point claimed that nothing needs to be tested and validated, both of which I did not assert at any point.

You literally did multiple times when you stated, over and over, that the processor is validated at the foundry to automotive grade so the above ECU testing wouldn't be required if they put this new processor in the ECU. Am I wrong because that exactly what you wrote?

 

2 hours ago, RedRound2 said:

Says the person who literally just cherry picks two three lines off my replies and extrapolates completely out of context items.

I pick and reply to sections only pertinent to the original conversation, anything else I will ignore, actively. I do read them in context but if the context has nothing to do with the conversation then it gets removed.

 

If I reply to you about something and you reply back saying what I said was wrong I'm going to stick to my discussion point and will only discuss that part of it. Anything else will get discarded until I'm satisficed that this discussion point has been addressed, reaching agreement is not a requirement only that I get the feeling that you actually understood what was being said.

 

If you think above said testing only takes 4 weeks then so be it, if it looks like you have no idea that I'm talking about the above testing and go on about something else I'll repeat what I said until you realize it's about the above.

[Beerzerker]

On 9/19/2021 at 9:53 PM, Kisai said:

Power Steering has been on ALL vehicles since the 90's,

 

1: It's simply impossible to drive a vehicle that doesn't have it because the amount of muscle strength needed to turn at low speeds is too high for most people who didn't grow up on it. Even then, that's not an IC thing, that's a hydraulic system. (try steering a car at 5-30kph, and then try the same thing with a riding lawntractor or forklift, typically the steering is MUCH harder than a car.)

 

2: I don't think people realize that all vehicles that have a steering wheel are a mixture of hydraulic "by wire" systems, not electronic (like in an air plane.) Even from a safety POV, never mind cost, you still want to be able to pull the parking brake, put the transmission in Park/Neutral, and Steer even if all the electronics fail, otherwise you won't be able to tow it without destroying the entire drivetrain (which is why tow trucks lift the front/rear of a vehicle instead of simply dragging it.) 

 

Now with EV's, like not hybrids, but full EV's, you have the potential option of being entirely electric just to be more reliable than a typical ICE vehicle, but vehicles that use this (Tesla's) have multiple redundancies. I'm not sure if I would trust a "cheap" vehicle that is entirely by wire with no redundancy, but then I remember that the Skytrain has been a fully electric, fully autonomous system since the 1980's and it's never had an accident attributable to the automation, where as cheaper at-grade human-driven light-rail systems tend to have daily accidents ranging from over-shooting the stop to dragging people to their death caught in the doors.

 

3: Then you have the hacking problem. Yes, all computer driven systems can be hacked, it's not a question of IF, but when/where. Using the previous Skytrain example, despite it using rather off-the-shelf RF technology, has never been "hacked". Where as again, human drivers have managed to speed and over-apply brakes, overshooting stops and causing excessive wear on the braking systems. (When the Skytrain is manually driven during extreme cold weather events, it's a completely different over-cautious low-speed experience.) Automated vehicles are more likely to be vandalized than hacked.

 

4: So I think we can trust automation for driving, we can trust drive-by-wire, but we need to have a long talk with vehicle manufacturers to standardize on ONE, and only ONE standard that takes into redundancy of both the city's traffic control system and onboard systems as well as talks to neighboring cars to make sure it gets as much advanced notice as possible before passing vehicles that are turning and such, and I feel it's this is where vehicle manufacturers are going to drop the ball and rely too much on optical machine learning rather than just having the car go "I need to turn in 100m, watch out."

 

A few points I'd like to address and why - Agree or disagree in whole or part is entirely up to whomever: 

1: No it's not, simply growing up with or without it doesn't mean jack except you know what it's like to not have it and I did grow up without it.
My first car didn't and it drove just fine, kinda easy to drive in fact - Even the ladies back then didn't have too much trouble either with them, they just drove it and no one has ever been born to drive a manual or power steering vehicle.

If as a people/society we've become that wimpy since that time, there are more pressing issues than a simple lack of power steering going on here.
On the flip-side it may be a good thing because it's harder to text and drive without it.
Doable but not as easy to do.

The biggest advantage it has is when you're driving really slow or turning the wheel while not moving, that CAN be tough to do depending on the vehicle, the tires (How big/wide they are) and such. Had it go out on an  old 71 Chevelle SS I had years ago and that is a heavy car (Full frame and almost all metal) - And of course it had wide tires on it.
That was one case I did build up muscle from driving a vehicle.

 

2: In general:
Only the ones made from about 2000 and onward are or may be like that and perhaps the new all electric ones like a Tesla. Even if you have the hydraulics in place it's just an assist to the driver, not the actual means of making it work. If speaking to it being hydraulically actuated as it is with industrial equipment such as forklifts, you CAN still steer it with the engine not running but of course it's not as easy to do and even alot of that is an assist, not the actual means of making it work.

As for ones like a Tesla this is probrably right on target and for the record I've never had a chance to peek under the hood of one (Yet).

 

3: This is one thing that really bothers me - Not alot to describe since everyone already knows what it could mean when it happens and it doesn't have to be a single vehicle targeted for the hack at the same time either.

 

4: I've no choice but to strongly disagree with you on this.
If you've ever worked on vehicles and mobile equipment for a living like I have you'll begin to understand why and that did include some electrics along the way.
In fact the bulk of what I was working on WAS electric and some of the things I've had to deal with and the reasons why makes me say you can trust all automation/wireless if you want because it's your choice to but I'm not.

[Kisai]

1 hour ago, Beerzerker said:

A few points I'd like to address and why - Agree or disagree in whole or part is entirely up to whomever: 

1: No it's not, simply growing up with or without it doesn't mean jack except you know what it's like to not have it and I did grow up without it.
My first car didn't and it drove just fine, kinda easy to drive in fact - Even the ladies back then didn't have too much trouble either with them, they just drove it and no one has ever been born to drive a manual or power steering vehicle.

If as a people/society we've become that wimpy since that time, there are more pressing issues than a simple lack of power steering going on here.
On the flip-side it may be a good thing because it's harder to text and drive without it.
Doable but not as easy to do.

The biggest advantage it has is when you're driving really slow or turning the wheel while not moving, that CAN be tough to do depending on the vehicle, the tires (How big/wide they are) and such. Had it go out on an  old 71 Chevelle SS I had years ago and that is a heavy car (Full frame and almost all metal) - And of course it had wide tires on it.
That was one case I did build up muscle from driving a vehicle.

That's just the direction things are going. Low-quality vehicles are that much harder to drive because they lack the assist features, and todays cars have a lot of features that older drivers want turned off because they don't want to accidently activate them. My mom, for example had half the features (including things like auto-park, and the lane-departure vibration thing) turned off because she didn't like it or want it to be accidently activated.

 

Where as I'm sure if you forced someone under the age of 30 to drive any vehicle with no power steering they'd complain quite vocally, and dealerships will never sell any, just like most standard transmission vehicles no longer exist.

1 hour ago, Beerzerker said:

2: In general:
Only the ones made from about 2000 and onward are or may be like that and perhaps the new all electric ones like a Tesla. Even if you have the hydraulics in place it's just an assist to the driver, not the actual means of making it work. If speaking to it being hydraulically actuated as it is with industrial equipment such as forklifts, you CAN still steer it with the engine not running but of course it's not as easy to do and even alot of that is an assist, not the actual means of making it work.

As for ones like a Tesla this is probrably right on target and for the record I've never had a chance to peek under the hood of one (Yet).

I haven't owned a vehicle in 20 years and have driven rentals or relatives vehicles on occasion, and you could not sell me on a vehicle that can't turn the wheels with the engine off.

1 hour ago, Beerzerker said:

3: This is one thing that really bothers me - Not alot to describe since everyone already knows what it could mean when it happens and it doesn't have to be a single vehicle targeted for the hack at the same time either.

I think the big potential for hacking is not the vehicle being hacked to cause an accident, but hacked to be stolen. Why break into the car when you can just have it drive itself out of the owner's garage unmanned.

 

1 hour ago, Beerzerker said:

4: I've no choice but to strongly disagree with you on this.
If you've ever worked on vehicles and mobile equipment for a living like I have you'll begin to understand why and that did include some electrics along the way.
In fact the bulk of what I was working on WAS electric and some of the things I've had to deal with and the reasons why makes me say you can trust all automation/wireless if you want because it's your choice to but I'm not.

 

The Vancouver Skytrain has had no accidents caused by the automation, they've all been human-caused (Eg someone deliberately turning off the power at the control building during an upgrade to said system, caused the trains to all stop on the tracks and time-out.)  This is what I would expect of any driverless system, where if the car can't communicate with the city traffic system, that it requires the humans in the car to have one hand on the stop button, and not just keep driving as though there are no cars on the road. Even if it's relying on cameras and lidar to detect obstacles, current driving assist features haven't exactly prevented accidents while the vehicle is at speed, mostly just parking/storage situations.

 

Compared to all the human-driven vehicles and rail vehicles which have literately millions of more accidents due to the nature of mixing vehicles on the same right of ways.

 

We can trust vehicles when they have redundancy, not when they depend on only themselves.

 

[Beerzerker]

2 hours ago, Kisai said:

That's just the direction things are going. Low-quality vehicles are that much harder to drive because they lack the assist features, and todays cars have a lot of features that older drivers want turned off because they don't want to accidently activate them. My mom, for example had half the features (including things like auto-park, and the lane-departure vibration thing) turned off because she didn't like it or want it to be accidently activated.

Yeah, I must agree this is the direction things are headed. There is driving a vehicle, and then there's driving a vehicle and I can deal if certain things aren't there.  I've driven about anything you can name on the road and a few that's too big for the highway too (Earth mover/coal mining dump truck as an example), that's just the experience I've had along the way.
I don't want that stuff either like your mom and can't blame her for it.

Quote

 

Where as I'm sure if you forced someone under the age of 30 to drive any vehicle with no power steering they'd complain quite vocally, and dealerships will never sell any, just like most standard transmission vehicles no longer exist.

I haven't owned a vehicle in 20 years and have driven rentals or relatives vehicles on occasion, and you could not sell me on a vehicle that can't turn the wheels with the engine off.

It depends on a few things, the individual, the situation and so on. I can promise you, alot will get over and on with it in a "Must Do" situation and for those that just refuse to, well.... it's their problem, not mine.

I'll deal - They'll squeal.

Quote

I think the big potential for hacking is not the vehicle being hacked to cause an accident, but hacked to be stolen. Why break into the car when you can just have it drive itself out of the owner's garage unmanned.

Actually both are equally applicable and you are correct, car thefts will certainly be part of it with the hacks but what about the ones that just want to cause chaos?
We both know how that can be done, either by taking control of the vehicle or causing it to not run/function. So-Called "Services" like OnStar can do that and have been able to for years now IF they want, including unlocking and shutting down/locking out a vehicle. A good hacker with access to anything that's OnStar-related can do alot with it along those same lines and the access itself, like all other things hacked doesn't have to be given to them. 

Quote

 

The Vancouver Skytrain has had no accidents caused by the automation, they've all been human-caused (Eg someone deliberately turning off the power at the control building during an upgrade to said system, caused the trains to all stop on the tracks and time-out.)  This is what I would expect of any driverless system, where if the car can't communicate with the city traffic system, that it requires the humans in the car to have one hand on the stop button, and not just keep driving as though there are no cars on the road. Even if it's relying on cameras and lidar to detect obstacles, current driving assist features haven't exactly prevented accidents while the vehicle is at speed, mostly just parking/storage situations.

Trains MUST follow a rail by function and design but cars don't have that in their favor. It's true even a train can come off the tracks but not simply for the sake of it, usually it's either too much speed or a faulty section of track that does it, with a car it can either veer off road or go straight when it should turn to stay on the road. Don't forget mistakes in the software too that can exist.
Here's an example:
I went once to a place to work on an electric forklift coding out, refusing to do anything and it was throwing a code 19. I checked and that meant the battery was low on water according to the system so it locked out. Turns out it's a dummy or "Ghost" code because while the guys had included that piece of code in the software of it's control module, that function was never actually implemented in the final design of the lift so it was just a left-over piece of code that was never removed.
However there was an actual problem - Namely a randomly blown 5 amp fuse and turns out if that fuse goes bad it will trigger the code to pop up and lock it down.
Replaced it, cleared the code and all was well.

Quote

 

Compared to all the human-driven vehicles and rail vehicles which have literately millions of more accidents due to the nature of mixing vehicles on the same right of ways.

 

We can trust vehicles when they have redundancy, not when they depend on only themselves.

 

Mostly goes back the last comment I made, nothing is perfect and things can happen, be it us causing it directly or from a mistake in the software/firmware. That's why I also don't trust anything that's fully auto or has the capability to "Step In" and assume control. Some form of manual control has to be present at the very least, even if there are other auto-redundancy's built-in. 
I've seen, driven and worked on too much of it to believe otherwise.

[RedRound2]

On 9/23/2021 at 11:06 PM, leadeater said:

I didn't actually say it takes more than a year, already agreed that it would be done within a year. The total amount of product test hours can likely to be more than a year but that really does depend on how many ECUs they require to test as part of their end to end testing procedures.

So this what I have been saying the whole damn time. I honestly at this point dont know why we wasted so much time on this

Quote

You literally did multiple times when you stated, over and over, that the processor is validated at the foundry to automotive grade so the above ECU testing wouldn't be required if they put this new processor in the ECU. Am I wrong because that exactly what you wrote?

No, I never said no testing was required. You repeatedly told me that it needs to pass envrionment and temperature tests to which I said it will be tested at the foundry. Afterall they sell it calling automotive grade. There is a minimum spec to it. Just like your EEPROM example, the auto manufacture doesnt run it through millions of cycles. It's the foundries that do that, and whatever extra tests that required for grading it automotive.

 

And after the auto manufacturers recieve, the manufacturer tests in similar method I described in the previous reply. And that this whole thing would take probably about year or two max.

 

My original reason to reply here was somone said these things will take 4 years to test and that why no one updates their chips. Which I find very hard to believe because companies like Tesla always swap out components on the fly. In fact that's how they avoided a brunt of the chip shortage. Upgrade everything to the newer node

https://electrek.co/2021/05/03/how-tesla-pivoted-avoid-global-chip-shortage/

 

So, based on the above two of your replies, it's abudnatly clear to me that you never understood what I was trying to say. And you wasted your time connecting and understanding the wrong things while I like an idiot spent time replying to things I never claimed

Quote

I pick and reply to sections only pertinent to the original conversation, anything else I will ignore, actively. I do read them in context but if the context has nothing to do with the conversation then it gets removed.

Debatable. You leave out a lot my direct replies. I dont have the patience nor time to go and specifically call you out on it. And, even if you probably see me as an asshole, I do have some humanity to not feel the need to just go and scream out that i was right and you are wrong

 

Quote

If you think above said testing only takes 4 weeks then so be it, if it looks like you have no idea that I'm talking about the above testing and go on about something else I'll repeat what I said until you realize it's about the above.

At what point did i say the entire testing will take only four weeks? Stop making up random shit.

You clearly have not understood a single thing I've been trying to say. Just leave it. I understood that we have been agreeing on the same thing all the time. Please dont feel compelled to reply, at least not without rereading the whole thing and trying to understand what I've been saying all along

[leadeater]

3 hours ago, RedRound2 said:

No, I never said no testing was required. You repeatedly told me that it needs to pass envrionment and temperature tests to which I said it will be tested at the foundry.

Ok look what is the foundry to you? Because if you mean the chip foundry yet again then no, yet again foundry chip testing is literally not the testing I just linked you of the actual ECUs. Why are you repeatedly bringing up a point I've told you many times is not what this is about, are you incapable of stopping and thinking? If someone says it's not about that then maybe it's not and it's about something else, what does this chip go in to? Maybe it's about that device/product 

 

This "device" or "product" is called an ECU. This ECU has many components in it, one of which is a processor. Changing a critical component in a product necessitates that product testing is carried out again. This really should not be hard, this should have been obvious, in fact it was to everyone but you...

 

I brought up environment and temperature testing as a reply to your assertion that an Arduino could do what an ECU could, that's never been the only ECU testing I was talking about nor specifically the testing I was referring to in my original reply.

 

Or maybe you think an ECU only consists of the processor/SoC this entire time, in which case this was doomed from the start if that's what you think an ECU is.

 

3 hours ago, RedRound2 said:

Afterall they sell it calling automotive grade. There is a minimum spec to it. Just like your EEPROM example, the auto manufacture doesnt run it through millions of cycles. It's the foundries that do that, and whatever extra tests that required for grading it automotive.

You didn't read the documentation about literal ECU testing did you?

 

Why are you replying? Yet again so wrong, I gave you the benefit of the doubt and replied to you because it seemed reasonable but you went completely off base again and didn't even read anything at all from an automotive ECU testing document summary description. If you won't read a primary source on a matter then you don't deserve to be part of the conversation. What I say is merely opinion, a primary source on the other hand is factual information from someone or something the topic is about and there can be no better.

 

3 hours ago, RedRound2 said:

And after the auto manufacturers recieve, the manufacturer tests in similar method I described in the previous reply. And that this whole thing would take probably about year or two max.

Up until your last reply, or the one before that (forget and doesn't matter at this point) you never talked about anything like this at all and especially not so in the context of testing the actually ECU product itself. Two things you've only ever talked about, chip validation which is irrelevant, and the software that runs on the ECU which is also mostly irrelevant if you had not made the additional claim that since it's simple software the testing must be simple which is wrong.

 

I have to conclude from this that you only finally bring it up now because you realize you were wrong this whole time and are trying to pass it off. Maybe it was before my Gigabyte example or maybe it was because of that but I get a very strong feeling you've realize you were wrong and just can't accept it.

 

3 hours ago, RedRound2 said:

No, I never said no testing was required.

Yes you have, multiple times. If you reply again expect that every single one of these instances shall be collected, quoted, put back in front of you and then you can attempt to explain how all these times where you said it wasn't required somehow isn't what you said.

 

3 hours ago, RedRound2 said:

At what point did i say the entire testing will take only four weeks? Stop making up random shit.

That's not what I said, I said I wouldn't care IF you said it took 4 weeks. I said the testing I just linked you HAS to be done. This reply alone here proves you can't or aren't reading anything.

 

3 hours ago, RedRound2 said:

I understood that we have been agreeing on the same thing all the time

No we have not. Refer to my very first post to you I have had to show you again before to remined you what this conversation is and refer to the top part of this post. Chip foundry testing is not enough. I've explained why with the Gigabyte example but you were seemingly unable to comprehend the example that a PSU is equivalent to an ECU not the entire vehicle (PC).

 

If you do not think ECU revisions require the kind of testing I linked you, from a literal automotive manufacturer (Opel/General Motors) then you are just simply wrong.

 

And I know what your original comment was, I was addressing your claim in that comment that ECU testing was not hard or not a big deal, as per my first reply to you, yes it is. I have never addressed any part of your post than this specific section of it, hence why I quoted only that section of it originally.

 

As per the document a single ECU test session could take anywhere from 7 hours to 50 hours and if they do that more than once, they will, and test more than one sample, they will, then total combined product testing hours will easily be thousands. Most of it is automated so they can do as many at once as they have Diagnostic Testers and ports on the DLC for each Diagnostic tester.

 

For example you setup one Diagnostic tester, plug 10 of the same ECU in to the DLC which connects to the tester. You run the test suite which takes 15 hours, you have just completed 150 hours of testing. Repeat this 10 times and you've completed 1500 hours of testing (in 150 hours).

 

You can connect more than 10 ECUs in to the Diagnostic Tester and you can connect different ECUs at the same time as well, in to different port on the DLC.

 

You haven't been able to comprehend what this conversation was ever about or the difference between chip validation at the foundry and product testing of the ECU and still deny it even with direct evidence proving you wrong.

 

Like I said last post, I do not care about anything else you've been saying, never objected to it, never addressed it, I only care that you said something that was wrong (enough to require pointing it out), I replied to that section and addressed it and then you came back and said I was wrong about something that I was emphatically correct about.

 

3 hours ago, RedRound2 said:

Debatable. You leave out a lot my direct replies.

Again if it has nothing to do with the conversation then it gets removed, not addressed, ignored. However you choose to see it. I will not go down a fork in the road to discuss something you want to talk about if the original path has not been satisfactorily addressed.

 

3 hours ago, RedRound2 said:

I do have some humanity to not feel the need to just go and scream out that i was right and you are wrong

If I'm right I'll say I'm right, there is absolutely nothing wrong in that. I am right about this. At least I have the decency to actually address the actual topic at hand and not go on irrelevant tangents when you know you were wrong the whole time and try and distract from it like you have been doing this entire time. Admit it or not that is what you have been doing, or the weight of crushing evidence has broken something, I don' know.

 

As my last reply I literally do not care about anything else you have been trying to say, you made I claim and I replied to it and addressed that what you said was wrong. If you want a conversation about anything else wrap this original part up before hand. I'll never address anything else until that has been done

 

[RedRound2]

9 hours ago, leadeater said:

Ok look what is the foundry to you? Because if you mean the chip foundry yet again then no, yet again foundry chip testing is literally not the testing I just linked you of the actual ECUs. Why are you repeatedly bringing up a point I've told you many times is not what this is about, are you incapable of stopping and thinking? If someone says it's not about that then maybe it's not and it's about something else, what does this chip go in to? Maybe it's about that device/product 

You're hopeless. WHy do you bring up entire ECUs, when I'm only talking about the chip that is tested in the foundry?

You still dont contexts do you? I'm not going to beat a dead horse at this point. 

9 hours ago, leadeater said:

This "device" or "product" is called an ECU. This ECU has many components in it, one of which is a processor. Changing a critical component in a product necessitates that product testing is carried out again. This really should not be hard, this should have been obvious, in fact it was to everyone but you...

This is what ive been saying the whole time. What more do you want from me. I did say that they would need to test it but said it's not some insanly hard process that would take at least 4 years to do.

9 hours ago, leadeater said:

I brought up environment and temperature testing as a reply to your assertion that an Arduino could do what an ECU could, that's never been the only ECU testing I was talking about nor specifically the testing I was referring to in my original reply.

Oh my god. Are you limited in any way? How many times do I have to keep pointing out that Arduino was to not be compared to devices that has been certified for the particular use case. 

9 hours ago, leadeater said:

Or maybe you think an ECU only consists of the processor/SoC this entire time, in which case this was doomed from the start if that's what you think an ECU is.

You're pretty stupid if thats what you think it was. As I alluded to before, you're comprehension skills are garbage. QUOTE MY Exact words of wheverever you deduced that from. Come at me.

9 hours ago, leadeater said:

Up until your last reply, or the one before that (forget and doesn't matter at this point) you never talked about anything like this at all and especially not so in the context of testing the actually ECU product itself. Two things you've only ever talked about, chip validation which is irrelevant, and the software that runs on the ECU which is also mostly irrelevant if you had not made the additional claim that since it's simple software the testing must be simple which is wrong.

CHip validation points became relevant when you suddenly came up and lost your shit about envrionemt test. Just because they replace to a newer node with one ECU processor, doesn't mean they're going to take it to death vally or alaska and test the entire caar there again. Nobody does that, unless there are significant changes. And the change that I've only been talking about is the an updated manufacturing method, that;s it. That's it ever was all about

9 hours ago, leadeater said:

I have to conclude from this that you only finally bring it up now because you realize you were wrong this whole time and are trying to pass it off. Maybe it was before my Gigabyte example or maybe it was because of that but I get a very strong feeling you've realize you were wrong and just can't accept it.

No, You really like stroking yourself, dont you. I always knew the testing procedure i described above. Maybe do a plagarism test to see if i copied that from anywhere. I outlined it because I had a feeling that you didnt know that I knew that adn you kept misinterpreting everything I said

9 hours ago, leadeater said:

Yes you have, multiple times. If you reply again expect that every single one of these instances shall be collected, quoted, put back in front of you and then you can attempt to explain how all these times where you said it wasn't required somehow isn't what you said.

QUOTE ME. Come at me. I never said at any point that no testing was required. I may have said something along the lines of minimal testing (that may take about a year)

9 hours ago, leadeater said:

That's not what I said, I said I wouldn't care IF you said it took 4 weeks. I said the testing I just linked you HAS to be done. This reply alone here proves you can't or aren't reading anything.

So now you're openly making up claims I never said and just premetively replying to some hypothetically wrong thing I said. That actually explains your entire behaviour here.

9 hours ago, leadeater said:

No we have not. Refer to my very first post to you I have had to show you again before to remined you what this conversation is and refer to the top part of this post. Chip foundry testing is not enough. I've explained why with the Gigabyte example but you were seemingly unable to comprehend the example that a PSU is equivalent to an ECU not the entire vehicle (PC).

Chip foundry tests specs it is rated. Then the chip is integrated with rest of ECU and tested in lab. Then the ECU is integrated with entire vehicle and field test. This is the pipeline. This is literally a part of any product manufacturing. I'm sorry, whatever you think of me, you're pretty much wrong about it because of your very poor comprehension skills

9 hours ago, leadeater said:

And I know what your original comment was, I was addressing your claim in that comment that ECU testing was not hard or not a big deal, as per my first reply to you, yes it is. I have never addressed any part of your post than this specific section of it, hence why I quoted only that section of it originally.

An automanufacture. Who has 100s of ECUs in each car. If ECU test are so hard, god fucking knows how they made a car.

If Tesla can do this shit very frequenctly (a point you keep ignoring because it doesnt support your narrative) then the legacy automakers, who have manufacturing and proper testing nailed for past 100 or so years, must be really incompetant.

9 hours ago, leadeater said:

As per the document a single ECU test session could take anywhere from 7 hours to 50 hours and if they do that more than once, they will, and test more than one sample, they will, then total combined product testing hours will easily be thousands. Most of it is automated so they can do as many at once as they have Diagnostic Testers and ports on the DLC for each Diagnostic tester.

What the fuck was I saying the whole time? Exactly this.

7 to 50 hours is way less than my estimate of a month or two on 100 or so test mules. And I also gave the benefit of the doubt that it may not be automated which is highlt unlikely

9 hours ago, leadeater said:

For example you setup one Diagnostic tester, plug 10 of the same ECU in to the DLC which connects to the tester. You run the test suite which takes 15 hours, you have just completed 150 hours of testing. Repeat this 10 times and you've completed 1500 hours of testing (in 150 hours).

Same as above. I've always said this but you like to live in alternative reality

9 hours ago, leadeater said:

You haven't been able to comprehend what this conversation was ever about or the difference between chip validation at the foundry and product testing of the ECU and still deny it even with direct evidence proving you wrong.

Thats what you think hotshot. Everyone else that replied to my understood what I was talking about and let it go, You're the one clinging on this

9 hours ago, leadeater said:

Like I said last post, I do not care about anything else you've been saying, never objected to it, never addressed it, I only care that you said something that was wrong (enough to require pointing it out), I replied to that section and addressed it and then you came back and said I was wrong about something that I was emphatically correct about.

In other words you cant acknowledge when you've been proved wrong, but rather pretend it never happened and in effect probably get angry and twist my words even further to appear as some sort of all knowing being

9 hours ago, leadeater said:

Again if it has nothing to do with the conversation then it gets removed, not addressed, ignored. However you choose to see it. I will not go down a fork in the road to discuss something you want to talk about if the original path has not been satisfactorily addressed.

Nah, I cant believe you're making me do this but I'll list out things you never replied to

- Ive continously brought upto if the infotainment system was subjected to any of this. Because infotainment system still lag behind an iPad from 2012. This is a direct result of my inital assumption being correct that auto makes just wanna stick with older nodes because its better for them financially in the short term

- I've talked numerous times about how Teslas frequently change their components and dont do any elaborate multi year testing. Which you kept ignoring because it doesnt fit your narrative about how a simple ECU replacement is a task akin to personally go an attack God himself

- I at some point said there are mechanical fallback system in place for braking and steering - to which you claimed that steering was done by a motor. And then I specifically had to explain to you how a modern steering system worked and that all motors and hydrallics were in parallel. Something that even the dumbest of the dumb person can prove by try to steer a car when its turned off or if the battery is dead

 

These are just a few examples fea examples. And unlike you I have a life to not waste my time going through all your replies based on misinterpretations

 

9 hours ago, leadeater said:

If I'm right I'll say I'm right, there is absolutely nothing wrong in that. I am right about this. At least I have the decency to actually address the actual topic at hand and not go on irrelevant tangents when you know you were wrong the whole time and try and distract from it like you have been doing this entire time. Admit it or not that is what you have been doing, or the weight of crushing evidence has broken something, I don' know.

What was the irrelvant tagent? Again come at me. You're the one who keeps insiting that I claimed that no tests were required and Arduino would somehow pass envrionement tests.

All my original reply to this topic was that auto manufacturers were lazy in updating chips to modern manufacturing methods and they're suffering for it now. But companies like Tesla avoided the brunt of it by rapidly migrating to newer methods

9 hours ago, leadeater said:

As my last reply I literally do not care about anything else you have been trying to say, you made I claim and I replied to it and addressed that what you said was wrong. If you want a conversation about anything else wrap this original part up before hand. I'll never address anything else until that has been done

 

Why do you keep repeating the same thing again and again in your same reply. Do you just have time to burn away in your life?

[RedRound2]

On 9/23/2021 at 10:31 PM, igormp said:

Also I posted many pages ago that there are still MANY fabs doing processes in >45nm, and most microcontrollers use those processes because they're cheaper and they don't need the performance/power consumption that lower nodes offer.

This is what my inital conclusion was. They were cheaping out on ECUs with older process nodes (which is fine by itself in vaccuum - but unfortunately that also extended to user experience in terms of infotainment, smart features, etc which all only recetnly became a thing) and hence now the're potentially losing billions of dollars becasue the chips they require are so outdated. It doesn't benefit anyone from keeping those old fabs running isntead of upgrading it to new ones. I'm sure 22nm is still quite cheap enough, or will be cheap enough to match their previous rates once at scale. Short term greed cost them issues in long term. 

And that is why company like Tesla just came out so far ahead in the game when it came to software and user experience. And they still do and the auto manufacturers just couldn't handle the sudden shift to cars becoming entirely software driven. It's not the EV aspect that got Tesla off the grounds, but it was actually how a car was more like a phone and got people actually excited about cars that were otherwise till then a boring commodity item

[leadeater]

12 minutes ago, RedRound2 said:

You're hopeless. WHy do you bring up entire ECUs, when I'm only talking about the chip that is tested in the foundry?

Because you're the one that for whatever reason thinks that taking an existing design, retooling it for a new node and then having the chip foundry manufacture it is enough that it doesn't require any more validation than chip validation at the foundry which is not true. I've already explained why this is the case, given you real world example, what more do you do you need?

 

Your belief that chip validation in this situation is adequate just wrong which is a statement or assentation you have made multiple time. This is what the conversation has been about the entire time along with your naive belief that ECU code is basic so therefore the testing is simple.

 

Am I wrong in this assessment? Because that is what you've been saying over and over.

 

The entire ECU is the only thing that is important to the discussion, if you want to know why automakers and auto parts makers don't update their ECU with new processor revisions on new nodes this ECU testing is why, not chip validation. And as I've already explain due to the way their business works, their supply chains, their entire business model such parts are only done when they do platform updates to their vehicles. They don't do changes like this, GM only did something similar when they couldn't get parts required for features like auto stop/start like I've linked, certain 2020/2021 models no longer have that feature.

[RedRound2]

1 minute ago, leadeater said:

Because you're the one that for whatever reason thinks that taking an existing design, retooling it for a new node and then having the chip foundry manufacture it enough doesn't require any more validation than chip validation at the foundry which is not true. I've already explained why this is the case, given you real world example, what more do you do you need?

No i did not say this. I said that validation of specs like temperature tolerances, vibration, or memory register testing were all done at the foundry.

That sentence above by no way of form negates the sentence that I said that the car manufacturers then has to plop into onto the ECU mainboard, run lab tests, integrations tests and put it on test mules.

 

 

1 minute ago, leadeater said:

Your belief that chip validation in this situation is just wrong which is a statement or assentation you have made multiple time. This is what the conversation has been about the entire time along with your naive belief that ECU code is basic so therefore the testing is simple.

I did not say that. Again quote me.

1 minute ago, leadeater said:

Am I wrong in this assessment? Because that is what you've been saying over and over.

Yes you are. It is very clear. And if I have been saying it over and over, please quote me. And do yourself a favoru and also read the surrounding context around ti because I have zero doubt in my mind you will take something out of context and assume some deranged crap

[leadeater]

2 minutes ago, RedRound2 said:

No i did not say this. I said that validation of specs like temperature tolerances, vibration, or memory register testing were all done at the foundry.

That sentence above by no way of form negates the sentence that I said that the car manufacturers then has to plop into onto the ECU mainboard, run lab tests, integrations tests and put it on test mules.

 

 

I did not say that. Again quote me.

Yes you are. It is very clear. And if I have been saying it over and over, please quote me. And do yourself a favoru and also read the surrounding context around ti because I have zero doubt in my mind you will take something out of context and assume some deranged crap

 

On 9/21/2021 at 5:17 PM, RedRound2 said:

The only thing to be tested is the new processor node itself, whether it works relaibly or not. And given that the same sort of architectures and chips are likely to be used, we already sort of have data for it from the vendor itself like Nvidia, or AMD or Intel, or ARM

Now do you want me to pull up the other instances or not? Think hard before digging the hole deeper.

[igormp]

11 hours ago, RedRound2 said:

which all only recetnly became a thing) and hence now the're potentially losing billions of dollars becasue the chips they require are so outdated.

That's not the issue, we have a global supply shortage. If you read the article:

Quote

The shortage only became acute following a chain of unrelated events that limited supplies of raw chip wafers right at the source. First, a winter cold snap caused rolling blackouts at Texas chip fabs operated by Infineon, NXP, and Samsung, before a freak fire in March at key Japanese supplier Renesas compounded the problem. Finally a COVID outbreak brought downstream supply to a halt in Malaysia and Vietnam, a low-wage hub where chips are packaged into finished products for final shipping.

The problem is not the node itself, but that the fabs that produce those have problems. Intel want people to move to newer processes because, guess what, they're only one of the 3 or 4 fabs that produce such small nodes.

11 hours ago, RedRound2 said:

It doesn't benefit anyone from keeping those old fabs running isntead of upgrading it to new ones.

It doesn't make sense to upgrade. You keep complaining about infotainment systems, but those are just a minority and isn't what's holding back manufacturing. Upgrading to newer nodes would make everything more expensive, reduce output and yields, and make the supply for other things even worse (have you seen how packed TSMC's 7nm is?).

 

Upgrading to smaller nodes also wouldn't have made a difference if the fab you're buying from exploded anyway 

11 hours ago, RedRound2 said:

And that is why company like Tesla just came out so far ahead in the game when it came to software and user experience. And they still do and the auto manufacturers just couldn't handle the sudden shift to cars becoming entirely software driven. It's not the EV aspect that got Tesla off the grounds, but it was actually how a car was more like a phone and got people actually excited about cars that were otherwise till then a boring commodity item

You really sound like a huge tesla fanboy.

[leadeater]

1 hour ago, igormp said:

You really sound like a huge tesla fanboy.

 

1 hour ago, igormp said:

It doesn't make sense to upgrade. You keep complaining about infotainment systems, but those are just a minority and isn't what's holding back manufacturing. Upgrading to newer nodes would make everything more expensive, reduce output and yields, and make the supply for other things even worse (have you seen how packed TSMC's 7nm is?).

 

Upgrading to smaller nodes also wouldn't have made a difference if the fab you're buying from exploded anyway 

Tesla's had wide problems with quality control and production output since forever and still does, so trying to say Tesla has done better than other manufacturers with the chip shortages is nothing but Tesla PR spin. Hell I love Tesla cars but they have problems, always have, but they are getting better and I still intend to buy one knowing all their problems.

 

On to the actual point, Tesla struggles to make 200,000 vehicles each year while Ford alone will do anywhere from 6 million to 8 million in a year (VW Group 10mil +). The simple fact is because Tesla manufactures less cars, by a huge margin, they will have less supply issues than other car brands who all share a lot of upstream parts suppliers and have vehicle base platforms across many different car brands i.e. VW Group.

 

A company like VW Group sells in to so many different countries and regions that they have to maintain region specific models to comply with all sorts of regulations, many that do not apply to EV's or EV's are currently exempt from. An Australasia VW Polo is not the same vehicle as an EU VW Polo, any changes to components used has to be tested and documented, tracked, assigned to vehicle VINs and all registered with vehicle safety authorities in each region and jurisdiction. This is because if there is a fault that requires a recall, like those airbags, they need to know who to contact, actual letters to the current owners of the vehicles get sent to them. At all times everyone involved must know what is being used in every part and component, where, when and for how long and these extends past the car manufacturers warranty period as their safety requirements do not end when their mechanical warranty ends.

 

The two primary reasons Tesla avoided issues were.

• They sell less by a huge margin
• EV vehicles are more simplistic to make and more integrated in to singular computer systems

It's not because Tesla was more agile and changed fab node it's because they have low volume and had discussions with their fab partners and moved to a node that at the time could supply them what they needed for their volume of vehicles.

 

Going below 45nm reduces the number of silicon fabricators you can partner and source from, going below 28nm reduces that to an even greater minority and also restricts that fabrication facilities within the companies that you can work with that have those silicon processes. Going below 45nm probably lowers the total wafers per month by a factor of 10x, maybe more. Neither would you want to design many of these chips to utilize the smaller nodes so they would be wasted making large transistors, not achieve even close to 10x dies per wafer and greatly increase the production and chip packaging cost.

 

Tesla was able to do what they did because they are Tesla, Ford/GM/VW can't do what Tesla did because they are not Tesla. Small scale problems have small scale solutions, it's purely a numbers game at the heart of this.

[RedRound2]

 

On 9/25/2021 at 12:36 PM, leadeater said:

Now do you want me to pull up the other instances or not? Think hard before digging the hole deeper.

This was the actual quote. You know how you just stripped off the context completely. When I was specifically talking about the envrionement ratings.

Second, what is "testing the chip itself" mean in this context. Do the same thing the foundry does? No, to test the chip and see if it is compatible with the rest of the things. I will admit, that I may have not been crystal clear here. But that always the meaning behind it. Whether you choose to belive it or not is up to you. But maybe read everything I wrote with the backhend knowledge of knowing these things. I do work in a product based company as well, so even I know the ABCs of replacing any single component (in fact just a replacing diode from SS14 to U1J due to supply issues casued issues in the fucntionalities of the end product

 

On 9/21/2021 at 10:47 AM, RedRound2 said:

Envrionment hardening is done at manufacturing so it's pretty much already applied and very less likely to go wrong. The only thing to be tested is the new processor node itself, whether it works relaibly or not. And given that the same sort of architectures and chips are likely to be used, we already sort of have data for it from the vendor itself like Nvidia, or AMD or Intel, or ARM

[RedRound2]

12 hours ago, igormp said:

That's not the issue, we have a global supply shortage. If you read the article:

The problem is not the node itself, but that the fabs that produce those have problems. Intel want people to move to newer processes because, guess what, they're only one of the 3 or 4 fabs that produce such small nodes.

Global chip shortage aside, they wouldn't face the extra shortages pertaining to using the old node, genius. And I never said to use 5nm or even 7nm. Probably 22nm/32nm is good enough and is still be prooduced at good numbers for low end electronics.

In fact because Tesla used better nodes, they were able to avoid a lot of the issue. You're the one that mentioned it

Quote

It doesn't make sense to upgrade. You keep complaining about infotainment systems, but those are just a minority and isn't what's holding back manufacturing. Upgrading to newer nodes would make everything more expensive, reduce output and yields, and make the supply for other things even worse (have you seen how packed TSMC's 7nm is?).

Sticking with ancient technology because there is scale and is cheap is not the reason to always stick with it. We have to take in accound of the changing technological landscape

Quote

You really sound like a huge tesla fanboy.

After repeatedly complaining about them randomly changing parts and stealing 10K for FSD that was supposed to be out in 2017-2018. Sure man

 

I like their cars, and I recongize what they did and I'll probably think of getting one if they're still the EV leaders in the next 5 years (but I really hate how the Model Y looks)

[leadeater]

1 hour ago, RedRound2 said:

I will admit, that I may have not been crystal clear here

It really wasn't, because I brought this issue up many times and all I got from you was repeating the same thing about the foundry doing chip validation and how if the chip can do an instruction (your 1 + 1 examples or w/e) then it really did not imply that you meant further testing after that would be required. That's why I repeatedly pointed out specifically ECU testing if you revised the processor chip used in it.

 

Nothing you ever said up until about 3 posts ago even appeared at all like actual ECU product testing was ever in your conversation or thinking process at all. Why else would I be so insistent on pointing you towards ECU product testing and nothing else? Surely that was enough of a clue that if you were intending to say ECU product testing would also have to happen that is wasn't evidently clear in your wording.