[HN Gopher] Why Carmakers Can't Transition to Newer Chips
___________________________________________________________________
Why Carmakers Can't Transition to Newer Chips
Author : lambdasquirrel
Score : 148 points
Date : 2021-10-02 14:45 UTC (8 hours ago)
(HTM) web link (jalopnik.com)
(TXT) w3m dump (jalopnik.com)
| anaganisk wrote:
| When a Power PC is perfectly capable for a MARS rover missions, I
| dont see any reason why they must run Snapdragons. Unless some
| evil company, starts ditching physical controls or starts shoving
| Ads into Speedometer. And everyone follows.
|
| Im thankful that automobile tech didn't discover electron yet.
| Imagine your speedometer consuming 200mb of ram.
| willhinsa wrote:
| Don't give them ideas!
| ericbarrett wrote:
| Too late: https://gizmodo.com/get-ready-for-in-car-
| ads-1846888390
| [deleted]
| [deleted]
| baybal2 wrote:
| > Im thankful that automobile tech didn't discover electron
| yet.
|
| Too late. I am well aware of a few car dashboard clients using
| it to their own detriment (imaging gluing CanBus I/O to
| electron.)
| sircastor wrote:
| Speaking from experience, I can tell you automakers are already
| shipping vehicles that some Infotainment apps are web
| technologies. Not electron, but a similar system to run an
| encapsulated web page.
|
| I'm doubtful of the cluster being run by a browser engine
| though.
| joezydeco wrote:
| Mazda has been using _Opera_ running JS for their
| infotainment since 2014...
| leroman wrote:
| Sounds like the auto-makers play down on the talent they have and
| prefer to push the work outside, probably fearing they are not
| able to execute.
|
| This reminds me of being a 3rd party selling service to some
| company and they constantly ask for us to implement features that
| they could easily add - but can't. They don't say that flat out
| but we all understand what's happening..
| baybal2 wrote:
| https://news.ycombinator.com/item?id=28709481
|
| > The aspect of the problem not talked about is that a lot of
| automotive chips are really, really old.
|
| > And they are old, because of many certification requirements
| set partially by the industry, and a few odd governments.
|
| > In reality, most of them are both less reliable, and harder to
| work with in comparison to open market parts.
|
| > The only two things I seen chips with micron scale nodes used
| in my life were: air conditioner boards, and car parts.
|
| For example, who in the world today makes PMOS TTL chips? I bet
| the few foundries who can still do that will bill car parts
| makers an arm, and a leg for keeping making something this old
|
| Want to migrate? Find somebody who can can translate hand-drawn
| TTL chip to moderately modern CMOS under 60 years old.
|
| At times, the cases about I heard of car makers were having
| troubles with were also nothing less of direct consequence of
| conscious overengineering: some BWMs have one STM32 per window
| switch just to blink the LED, and do ADC despite the switch
| having just 5 positions. And now they can't ship because of this
| single LED blinker.
| wcunning wrote:
| Window controls are safety regulated modules in modern
| vehicles. They detect the closing force and reverse direction
| off the required motor torque exceeds av threshold so that you
| can't accidentally or intentionally choke someone with the
| windows. This feature is required by standards bodies and some
| regulators.
|
| Why not put those smarts in one big module, say the Body
| Control Module which is always huge and already gets redesigned
| and uses more expensive, smaller feature chips anyway you ask?
| Well, we need to run a bunch of wires to the door, several for
| the switch, power and grind and Hall effect sensor for the
| motor and we need to account for the noise and power loss on
| the long wire run because as a safety feature the sensing has
| to be ASIL compliant to high fault tolerance. Turns out that
| that length of wire is several dollars more than putting the
| module in the door... These things are all done for a reason
| and the automotive engineers aren't solely stuck in the old
| ways. They're frequently penny pinched to death, but if you
| look at the constraints they're doing their best.
| baybal2 wrote:
| > Window controls are safety regulated modules in modern
| vehicles. They detect the closing force and reverse direction
| off the required motor torque exceeds av threshold so that
| you can't accidentally or intentionally choke someone with
| the windows. This feature is required by standards bodies and
| some regulators.
|
| All of this is achieved with a single <$1 part, fixed torque
| clutch... But who in the world wants to intentionally choke
| somebody with a power window? This add to the long list of
| absurd product liability regulations in the spirit of one
| demanding "do not operate the appliance with your genitals"
| to be printed on every stove.
| dharmab wrote:
| I remember watching A Faster Horse, a documentary on the
| Mustang. There was an interview with an accountant type at
| Ford who pointed out a three cent difference in part cost
| per car multiplied to millions of dollars at their scale. A
| $1 part might have given him a heart attack.
| imagi wrote:
| Kids/dogs plus automatic windows...
| HeyLaughingBoy wrote:
| Literally the thought I had :-) Been there, yelled at the
| kid!
| x0x0 wrote:
| > But who in the world wants to intentionally choke
| somebody with a power window?
|
| children. eg:
|
| https://abcnews.go.com/GMA/story?id=124854&page=1
|
| > _A 1997 government study by the National Center for
| Statistics and Analysis estimated power windows sent nearly
| 500 people to emergency rooms in one year, and that half
| the victims were small children._
| dragonwriter wrote:
| > > the sameso that you can't accidentally or intentionally
| choke someone with the windows.
|
| > But who in the world wants to intentionally choke
| somebody with a power window?
|
| Accidental is the more significant problem, particularly
| with children.
| lucidguppy wrote:
| This feels like lack of planning. The semiconductor industry was
| a known entity for many years before this level of integration
| came to vehicles. They should have known this would happen.
|
| Ultimately the industry will have to maintain their own
| production for consistent silicon.
| jes wrote:
| > _This feels like a lack of planning._
|
| In any complex undertaking, how can we know when enough
| planning has been done?
| dboreham wrote:
| As mentioned above there are folks who's entire job is
| maintaining the spreadsheet for said plan.
| hef19898 wrote:
| And you have to witness the mess without these people, or if
| they aren't allowed to do their job, in order to believe it.
| Better even, live the mess, I can assure you it is quite an
| experience.
| P24L wrote:
| These "low-tech" fabs are e.g. in Malaysia and they are often
| closed due to Covid..
| coryrc wrote:
| Texas power outages took down one of the few major US plants
| and a random fire took down another, at the same time as a
| global pandemic. We're almost at the level of "imports banned
| from China"-levels of implausibility here.
|
| Sometimes shit happens.
| AbbeSomething wrote:
| Is a part of the problem that the chips they are depending on are
| so trivial and small that you would end up losing more when
| cutting it up on a smaller process? I guess there is a limit to
| how many chips you could put on a single wafer even if the chip
| was only a single gate?
|
| Maybe the old nodes are efficient enough for the chips they need.
| Then again it would make sense to update designs frequently
| enough to stay at nodes that have plenty of capacity, perhaps
| every 5 or 10 years or so?
| coryrc wrote:
| Capital costs of a fab are the single highest cost of producing
| chips. So long as the fab is running it's cheap to keep running
| so little reason to spend money to put cheap things on other
| processes (which is an expensive design cost) when you can
| later switch to a more complex chip (which should allow you to
| reduce supporting components too) which takes advantage of the
| new process size.
| dale_glass wrote:
| Wouldn't the solution be planning better?
|
| Sure, I understand that making a new car in combination with
| making a new ECU or brake controller on a new process is going to
| be stupidly dangerous and troublesome. So just don't.
|
| Rather than doing it as a part of a single project, there should
| be a department or separate company making the ECU/controller.
| This way when the semiconductor company moves forwards, ECU Group
| starts a project targeting the new process, and releases the
| results when it's ready. And meanwhile what goes into the cars is
| the ECU built on the previous, well tested process.
|
| Also, are modern cars really in much need of custom silicon?
| Micro-controllers are stupidly powerful now. There has to be off
| the shelf hardware capable of handling what a car needs. There
| are long standing architectures like ARM that don't require
| starting from scratch every time somebody makes a better chip.
| coryrc wrote:
| Your comment displays a breathtaking amount of ignorance.
| dale_glass wrote:
| Then I welcome the opportunity to learn about something new.
| Please explain what's wrong, I'm most interested.
| coryrc wrote:
| Start reading IEEE, SAE, or other trade magazines; get an
| EE degree in the Midwest; get a job in the automobile
| supplier industry; go to industry conferences or just read
| their proceedings...
| m0llusk wrote:
| Can't is a really strong word. One potential solution that might
| open some paths to innovation would be to split up the product a
| bit more. Ship vehicles with extremely basic features only and
| some of those features intentionally designed to be swapped out
| in the short term. Use third party suppliers to swap in
| instrument clusters, engine controllers, and such and allow those
| to use all the latest chips.
| bellyfullofbac wrote:
| I look forward to the cyber-punkish future (real soon now?) where
| there's an old beige computer case with a Pentium MMX sticker on
| it on someone's passenger seat with wires snaking into the engine
| bay. "Yeah the ECU died, so I had to hack together this
| replacement...".
| tyingq wrote:
| There are cars where the enthusiast scene burns their own ECU
| EEPROMS to compensate air:fuel calculations after installing
| larger injectors, better flowing intakes, etc.
|
| Edit: There's also some "universal ECUs" from companies like
| Haltech. They sell a single ECU plus some adapter cables to
| make that single ECU run on a broad variety of cars from the
| 90's.
|
| Possible since the 90's cars all have the same rough
| types/numbers of sensors. Switchable software does the rest. I
| imagine this doesn't work past some year of make as the cars
| got more complex.
| _0ffh wrote:
| Yeah, but I think those enthusiasts are mostly just fixing up
| calibration values, not changing the actual control software.
| tyingq wrote:
| It is more than just a few values, it's maps to plot a
| curve.
|
| But they do actual control software too, though that's less
| common. https://en.wikipedia.org/wiki/MegaSquirt
| _0ffh wrote:
| Well I never wrote "just a few", but I did write
| "mostly".
|
| Also, disclosure: I'm intimately familiar with the ECU
| software of a major player in the industry, though
| primarily the part that governs the air system. It's
| surprisingly sophisticated and extremely configurable
| just by fiddling with those calibration values.
| mhh__ wrote:
| Maybe we'll have CMOS printers by then... (I can dream!)
| ChuckMcM wrote:
| The middle road is missed here.
|
| There are two problems, long duration supplies of a chip on the
| same process, and the cost of making chips.
|
| If the semiconductor companies can figure out an ASIC/FPGA type
| strategy that would allow any of the current chips in a car be
| produced "dynamically", then the semiconductor company could
| achieve their economies by just fabbing one design, and car
| companies could achieve longevity by getting commitments for
| production of that one design.
|
| Xilinx recently made some steps in a new direction by producing
| what they called an "RF" SoC. Where RF stands for radio
| frequency. Basically it had all of the analog to digitial and
| digital to analog bits on the chip in addition to some FPGA
| fabric and some ARM AARCH64 cores. Its expensive and small
| quantity but I think it will turn out to be important in the long
| run as the vanguard of chips that are not 'type specific' at the
| time of manufacture.
|
| Imagine a company that has the same basic FPGA architecture,
| packaged in a variety of automotive spec packages, with one-time
| programmability. That would reduce the number of SKUs
| considerably (basically by package type).
| schiffern wrote:
| > "We were able to substitute alternative chips, and then write
| the firmware in a matter of weeks," Musk said. "It's not just a
| matter of swapping out a chip; you also have to rewrite the
| software."
|
| https://www.theverge.com/2021/7/26/22595060/tesla-chip-short...
| echelon wrote:
| Why did car companies allow themselves to make such a strategic
| mistake? Shouldn't they be on a standard microcontroller
| architecture?
|
| Why not even use ARM, X86, etc? It'd save them money at this
| point. And there wouldn't be a supply risk.
| vvanders wrote:
| There's an incentive for chip vendors to not standardize
| since it makes migration hard and drives vendor lock-in. The
| CPU cores are one part but equally important is the
| peripherals and external featuresets.
| HeyLaughingBoy wrote:
| That incentive might exist, but what really drives the lack
| of standardization is that every application has different
| needs, so you end up with a common CPU and wildly diverging
| configurations tailored to various applications.
| HeyLaughingBoy wrote:
| Wouldn't really make any difference. The last company I
| worked for did pretty much everything with MCU's based on ARM
| Cortex-M.
|
| All that shit's still not in stock anywhere. And remember
| that ARM, x86, etc. only defines the processor architecture.
| The I/O is far more important in a control application and
| I/O is anything but standard across platforms.
|
| For one product we ended up buying a vendors entire supply
| and redesigning the product to use it, crossing our fingers
| that the supply chain would have unwound itself by the time
| we ran out of inventory.
| im_down_w_otp wrote:
| Tier 1 suppliers have an incredible amount of influence in
| that ecosystem, and Tier 1 suppliers have an incentive to not
| be easily replaceable. That'd be my guess.
|
| I mean, it's an entire MASSIVE industry that's comprised
| almost entirely of truly commodity technology, and so you get
| all the perverse outcomes that happen when trying to
| "differentiate" despite being commodity by inventing ways to
| be "special" to drive lock-in. Interoperability only really
| benefits the OEM, and the OEM isn't the only part of the
| chain.
| kevin_thibedeau wrote:
| Those processors aren't made on high reliability processes.
| You don't want your ECU built with the same media processor
| as the infotainment system.
| somehnguy wrote:
| Maybe I do! I've seen both fail just the same so it's not
| like ECUs are failure-proof or something.
| kevin_thibedeau wrote:
| Your radio dying won't kill you.
| somehnguy wrote:
| Correct, but you seem to have disregarded half my
| comment. ECUs are not failure-proof and fail all the
| time.
|
| I've never heard of anyone dying due to ECU failure
| either..I'm not sure how that would even happen given all
| the critical systems on a car are mechanical first with
| electronic assist. So you can't lose steering, braking,
| etc. The worst that happens is you lose power, which is
| about the same risk as a subpar standard transmission
| driver stalling out (and can also happen in a number of
| different ways). Can you expand on how an ECU failing
| might kill you?
|
| I would love if someone could elaborate on why I'm wrong
| instead of drive by downvoting. This isn't reddit.
| VLM wrote:
| Its easier and more realistic to kill the company via a
| recall.
|
| Take for example the Boeing 737-MAX. Eh, its bigger,
| needs a little more elevator movement to simulate the
| older model, just flex the software so it can wiggle a
| bit more what could possibly go wrong?
|
| Likewise, remember the VW Diesel emissions "scandal". You
| can nearly kill a company without actually killing
| anyone.
|
| So, the specified ECU chip (which is no longer in stock)
| could output 40 mA to the gas tank vacuum solenoid so we
| spec'd the solenoid to draw 30 mA on the coldest day of
| the year, usually it draws much less. Got a substitute
| chip only rated to 20 mA usually it'll work fine, what
| could possibly go wrong? Until it burns out and the
| vacuum solenoid fails open and nationwide millions of
| gallons of "excess" gas evaporate per year from sitting
| cars. Harmless on an individual scale but on a nationwide
| scale its a lot of ozone... Insert yet ANOTHER $35B
| recall to replace all the ECUs for willful emissions
| violations ...
|
| I'm just saying its not binary where either people die
| and it kills the company or people aren't even harmed and
| nothing bad happens at all. Plenty of "company killer"
| situations where "what could possibly go wrong" got the
| F-around and find out treatment.
| clairity wrote:
| i'd guess adding an abstraction layer (between a general
| purpose microcontroller and the custom interfaces it needs to
| support) is likely not worth the added complexity (and bugs),
| since cars are on development cycles of many years anyway
| (for the benefit of simpler software development, and the
| risk reduction of being able to swap out the microcontroller
| if need be).
| im_down_w_otp wrote:
| They actually _theoretically_ have a thing for this
| already. It 's called AUTOSAR (now AUTOSAR Classic). It's
| supposed to be a component architecture to write down the
| software against a framework that can be backed by
| different MCUs. Of course, in practice much of the
| underlying esoteria of any given MCU/board configuration
| bled up through the abstractions and/or produced custom
| extensions.
| RealityVoid wrote:
| And AUTOSAR is a nightmare of a framework where it's nigh
| impossible to understand what is going on because of the
| crazy abstractions.
| im_down_w_otp wrote:
| Indeed, it's a mess and the surrounding tooling ecosystem
| is a pile of weird Windows GUI tools of about the quality
| you'd expect for very expensive tools that do very little
| provided to a captive customer base. It's all very circa
| 1990s RAD-tool mania-esque still in many ways.
|
| That said, we're working with some groups in some
| automotive companies who are breaking this mold rapidly.
| RealityVoid wrote:
| Whom, if you don't mind me asking? I would.love to see
| stuff change in this field.
| im_down_w_otp wrote:
| I can't upset the NDA Gods on this one, unfortunately. I
| can say one is a traditional OEM that you wouldn't
| necessarily expect to be the sort to take vanguard steps
| like this and the other is a newer OEM that's not as
| encumbered by tradition (though due to the supply-chain
| also can't rid themselves of it).
|
| Shameless plug WARNING: we (https://auxon.io) are hiring
| for engineering, marketing, and BD if industrial &
| operational technology is your thing.
| VLM wrote:
| I never signed the NDA, although I follow the space
| distantly, and they went public on their own website a
| couple years ago with a list:
|
| BMW, Bosch, Continental, Daimler AG, Ford, General
| Motors, PSA Peugeot Citroen, Toyota, and Volkswagen.
|
| I always rooted for an older competitor GENIVI which
| (very handwavy in a general sense) boiled down to "make
| dbus great again". I just always have a soft spot for
| anything that replaces CORBA and DCOP. More or less
| GENIVI had the same players as AUTOSAR.
|
| I believe AUTOSAR suffers from trying to do too much;
| GENIVI's "all you need is a compatible bus" is the
| minimum you need so simplicate and add lightness and
| that's what should win; doesn't really matter if that guy
| runs QNX and that other guy runs FreeRTOS as long as the
| busses talk; whereas AUTOSAR tries to own and control
| everything top to bottom which just ends up stifling any
| productivity.
| im_down_w_otp wrote:
| If you look through the "Adaptive AUTOSAR" literature and
| documentation that's out there you can find that enormous
| chunks of it are lifted straight from GENIVI's
| stack/specs.
|
| However, GENIVI/Adaptive-AUTOSAR tends to serve a
| different function in the vehicle architecture. It's
| mostly cockpit and less control/platform. AUTOSAR Classic
| is still the champ on the MCU side of the house.
| [deleted]
| to11mtm wrote:
| As others have mentioned, the peripherals/etc related to a
| specific model of microcontroller and how you work with them
| play a big factor.
|
| But I'd also like to throw in:
|
| - 16 years or so ago, the US side of the Auto industry was
| trying to steer towards PPC. Motorola/Freescale's presence in
| the market probably had a bit of a play in this, as well as
| ARM's then-status of 'not quite powerful enough to be future
| proof.' A StackOverflow post from 2012 [0] seems to indicate
| they did indeed standardize, whether they moved on from there
| is another question.
|
| - Most Carmakers probably -don't- want to change designs
| outside of a refresh. There's a few reasons for this,
| including both external (updating documentation to repair
| network) and internal (when I worked at a place that did
| software/services for a US automaker, we had to submit
| _pages_ of documentation /paperwork to change a couple of
| items placement/wording in a dialogue box.)
|
| [0] - https://electronics.stackexchange.com/questions/26035/w
| hats-...
| hulitu wrote:
| Because the architecture is not so important. What is
| important is what periphereals are available. And even if you
| have the same architecture you still need to test if you
| change something. And things change rapidly also in
| automotive. 10 years ago you had a 100 pin micro at 32Mhz
| clock with 64kb ram, now you have a 384 pin micro running
| atva couple of hundred MHz with 256 MB ram.
| rootusrootus wrote:
| That's a fancy way of portraying big tech debt. They will pay
| for these decisions later.
| GeorgeTirebiter wrote:
| So much speculation here. Let me set the record straight(er).
| (I worked in Tesla FW, left 5 years ago.) Tesla does use
| industry best practices. All code must pass MISRA checkers,
| code is modular, and reused when possible. We used all sorts of
| chips (that were auto qual) of many different architectures. We
| had extensive tools for e.g. stack monitoring, diagnostic
| readouts, and much more. If you move from, say, one ST ARM chip
| to another one in a similar family, the peripherals may be a
| little different, but generally work the same way (with maybe a
| few more or fewer features). So reworking the I/O drivers _is_
| work, but given the excellent layering of Tesla "body control"
| FW, it's really quite straightforward to pick a different
| processor from a given family. It's for sure true that if you
| went from ST ARM to Freescale/NXP ARM the peripherals are diff,
| so yes, more time would be needed to write the I/O drivers. But
| the effort ongoing when I left was exactly to make the
| appropriate SW generalizations so it would be possible to do
| exactly this.
| hulitu wrote:
| If this is true, stay away from anything Tesla does. I work in
| the industry. 2 examples: 1) you have to change a transistor
| with one from a different supplier, same characteristics. You
| need to do some HW engineering tests. If the transistor is part
| of a safety relevant function, you need to do also system, SW
| and safety tests. And then environmental and EMC tests. Of
| course you can tailor but you need a very good justification.
| 2) You change the microcontroller. You need new SW, new tools
| (emulators - takes some time to be delivered), new sourcing,
| new HW design etc. It is from development perspective a new
| product so you need testing (HW, SW, System, Safety) and design
| validation (environmental tests, EMC) , maybe more than one
| loop.And when everything is passed and sourcing is done (i.e.
| you can buy the component) you can start production.
| baybal2 wrote:
| ARM M family cores can run each other's code more or less.
|
| Only the libraries for I/O need to be rewritten.
|
| In some cases, there are drop in replacements (Gigadevices
| STM32 clones)
| pwg wrote:
| Except that in some cases, the automakers are not using a CPU
| with external interface hardware, they are using
| microcontrollers similar to the PIC series, example here:
| https://ww1.microchip.com/downloads/en/DeviceDoc/40300C.pdf
| (Note, I'm not suggesting they use these exact chips, this is
| just an example of the level of onboard integration that is
| available for micro-controller chips).
|
| Single chip system, with built in analog comparators, timers,
| signal capture and PWM generation module, serial UART, etc.
| I.e., a whole "system on a chip" with the external world
| interfaces already built into the chip. Changing one of these
| for an ARM CPU with external analog comparators, timers, PWM
| modules, serial UART's, etc., is a redesign effort, not just
| a "change the chip" effort. If the clock speed possible via
| the internal clock oscillator is sufficient, then this chip
| needs only +5V and ground (plus programming) to be able to
| interface to and control some external analog or digital
| equipment.
| legulere wrote:
| That relies on I/O being written as replaceable units of code
| and not sprinkled throughout all of the code.
| im_down_w_otp wrote:
| Are there even any ARM Cortex-M chips that are ASIL-B rated
| or better?
| im_down_w_otp wrote:
| Looks like the Cortex-R52 and Cortex-R5, a CPU and MCU,
| respectively both have been ASIL-D (the highest rating)
| qualified. Which is fantastic frankly. There's a bunch of
| legacy PPC, MIPS, and TriCore tech that's just miserable to
| work with because of their ancient and/or bespoke &
| proprietary toolchains. So, really the automotive industry
| lacks excuses that I would buy for why they're not moving
| forward onto new platforms other than the institutional
| inertia and supply-chain entanglements that its
| prioritizing instead.
| detaro wrote:
| yes. ARM sells appropriate designs, and e.g. NXP offers
| some chips.
| TaylorPhebillo wrote:
| I think the Cortex-R chips are more targeted here- I think
| the V8-R chips are designed specifically for automotive
| use, so I assume they have appropriate ratings.
| baybal2 wrote:
| There are very lazy car companies which simply specify
| "automotive certified" car chips for everything,
| including MCUs running window switches. So, don't be
| surprised $20 ARM-R based MCUs being used to do something
| trivial like driving window motor.
|
| I seen a few dashboard where there is an STM32 sitting
| connected to a single button, whose only duty is to
| register a key press, and burp something on the CanBus in
| response.
| sbierwagen wrote:
| A big chunk of this crisis was _caused_ by car
| manufacturers being insanely focused on cost cutting.
| Doing obviously dumb things with BOM isn 't exactly a
| calling card of the automotive industry.
| hulitu wrote:
| Every component ( resistors, transistors,
| microcontrollers, etc ) must be Automotive qualified
| (AEC-Q ). That's how you have a minimum standard. A
| button cannot communicate on the CAN bus that's why you
| need the microcontroller.
| coryrc wrote:
| I guarantee you no one is running $20 MCUs in trivial
| applications (in normal times). They're very cost-
| conscious.
| kortex wrote:
| A) I doubt you need a $20 component to register a key
| press and do some canbus IO
|
| B) If you did have a $20 microcontroller for Canbus
| control of a window motor driver but it saved $19 in
| extra wiring/labor (driver controls usually route to all
| windows), provides reliable debounce, automated one-push-
| to-open, and allows things like holding keyless lock to
| close all windows, it's totally worth it.
| kube-system wrote:
| CPUs aren't the only silicon out of stock right now. Most
| silicon doesn't even run software.
| stefan_ wrote:
| What software can turn a MSP430 or 68 knockoff into a highly
| efficient power transistor? Take everything Musk says with some
| caution..
| JohnJamesRambo wrote:
| I feel like GM and Ford are at US Government and NASA size
| where getting any change through takes so long and so much
| middle management and red tape that it stretches to infinity.
|
| I'm sure Tesla is more agile than that. For better or worse
| sometimes...
| mathattack wrote:
| The bigger the company, the more effort that's needed to
| coordinate the parts. At some point one person can't keep the
| whole in the head and has to lean on process. Tesla is small
| enough, and has a CEO that can keep everything in his head.
| ulfw wrote:
| Tesla has over 70,000 employees. I know people think Elon
| is god, but come on, he can't have "everything in his
| head". Tesla isn't some mom and pop shop.
| jillesvangurp wrote:
| Tesla is much better at writing software than most of their
| competitors. That's how they can adapt so quickly.
|
| They also do a lot more in house than their competitors. That
| means they can optimize their development processes, and align
| with chip suppliers across different components. If you have to
| work with a multitude of suppliers that each ship their own
| hardware and software, life is a lot more complicated. Changes
| take years in such an environment. Even a simple thing such as
| over the air updates to software is still science fiction in a
| large part of the industry. VW famously struggled with doing
| that for the ID.3 only managing their first updates fairly
| recently.
|
| Of course, Tesla is still affected by supply issues as well.
| They can't switch suppliers every quarter.
| hulitu wrote:
| You cannot replace a Xeon with an Epyc without redesigning
| the motherboard. In reality is even worse. You replace a chip
| from ST with one from Renesas for example.
| IshKebab wrote:
| Are they better at writing software or do they just care less
| about how safety critical it is?
| coryrc wrote:
| I think you underestimate how poorly software development
| is done in traditional industries. Practice makes perfect
| and they mostly practice writing reports not software.
| hulitu wrote:
| It depends. If you want to sleep well at night you take
| care. Of course if you are VW you take risks.
| coryrc wrote:
| Taking a long time doesn't mean you've done more useful
| work.
| hulitu wrote:
| But a longer testing can find more bugs.
| coryrc wrote:
| So can a shorter one.
|
| (In a box at 120degC for a day is roughly equal to a
| thousand days at room temperature).
|
| Smarter not longer. Write in a memory-safe language and
| you don't need to pay people to maintain spreadsheets of
| memory allocations...
| kiba wrote:
| Agile does not mean less reliable. See Boeing versus
| SpaceX.
| filoleg wrote:
| It isn't that their engineers are inherently better at
| writing software. The parent comment explained exactly why
| their organizational and supply chain structure allows them
| to be more agile and better at writing software and
| delivering it.
| hef19898 wrote:
| I personally would rank Tesla's Supply Chain to high, so.
| jbverschoor wrote:
| Weeks? This has been going on for almost 100 weeks
| mkr-hn wrote:
| I assume the alternative chips are still in short supply, but
| less so than their first choice. Everyone else is looking for
| alternatives too.
| LennyWhiteJr wrote:
| To elaborate on this, the feature sets on these low level
| microcontrollers are no standardized. There is no common API
| for them to implement. Even chips coming from the same
| manufacturer will have different hardware capabilities, and
| although low-level drivers can abstract that way to a certain
| extent, there will always be differences.
|
| The biggest challenge is when you need to update your firmware
| to use a microcontroller from a different manufacturer. Often
| times these chips are specifically chosen due to the set of
| hardware functionality they offer, and the firmware is written
| to take advantage of that from the start. The two are coupled.
|
| Now you are forced to use a _different_ chip, and the firmware
| that was written for a specific set of hardware now has to be
| modified for a new chip that may have a different feature set.
| Things fine print on how things like Analog to Digital
| converters becomes _extremely_ important.
| Espressosaurus wrote:
| Even a single hardware iteration intended to be a drop-in
| replacement in some cases won't be due to relying on
| implementation-defined behavior that is not guaranteed by the
| datasheet and wasn't considered a constraint by the people
| designing the silicon. Sometimes it's a bug, sometimes it's
| just "didn't think that was important".
|
| Either way, you're left with something where the saturation
| behavior changed, or it's no longer possible to read out a
| value without risk of corruption since they assumed it can be
| treated as write-only, or some other hard to find and debug
| problem.
|
| Swapping out chips is an exercise in testing and risk
| management, and never should be done without care, even
| before we start talking about safety critical applications.
| AtlasBarfed wrote:
| I get that what Musk quoted is not a trivial task, and if
| accurate, is probably much quicker than OEMs and Big Auto could
| do since Tesla is presumably much better at software.
|
| The article quotes Intel at 16nm, which is, what, 10 years from
| cutting edge process node? At this point mature OEMs and Big
| Auto should have been on a refresh process to auto-migrate
| forward the chips. The semiconductor industry is 40-50 years
| old now. And new generations produce better chips (cost, power
| use, performance).
|
| As other comments say, it smacks of laziness and lack of
| forecasting.
|
| Tesla has other advantages, since they are so much more
| vertically integrated, they can probably manage migrations a
| lot more easily and centrally.
|
| Big Auto is more like "Big assemble OEM parts". OEMs make all
| the components, Big Auto just wants to screw them into place
| and wire them together. It's part of why they suck at software
| that integrates things: They don't make any of the components,
| and a dozen different departments order them from a hundred
| suppliers, so getting interfaces/protocols/specs is a lot more
| time consuming than for Tesla.
| 01100011 wrote:
| As far as I can tell, Tesla plays fast and loose, treating
| their product like a manufacturer of consumer electronics and
| not a manufacturer of a dangerous and durable good. That
| obviously allows them to out-compete other auto manufacturers
| who are more aware of things like product liability.
|
| See the Toyota accelerator-gate lawsuits. From
| https://en.wikipedia.org/wiki/2009%E2%80%932011_Toyota_vehic...
| :
|
| > However, on October 24, 2013, a jury ruled against Toyota and
| found that unintended acceleration could have been caused due
| to deficiencies in the drive-by-wire throttle system or
| Electronic Throttle Control System (ETCS). Michael Barr of the
| Barr Group testified[30] that NASA had not been able to
| complete its examination of Toyota's ETCS and that Toyota did
| not follow best practices for real time life critical software,
| and that a single bit flip which can be caused by cosmic rays
| could cause unintended acceleration. As well, the run-time
| stack of the real-time operating system was not large enough
| and that it was possible for the stack to grow large enough to
| overwrite data that could cause unintended
| acceleration.[31][32] As a result, Toyota has entered into
| settlement talks with its plaintiffs.
|
| Not following software best practices(i.e. ISO 26262) can
| expose your customers to unnecessary risk and leave your
| company vulnerable to lawsuits. Tesla may learn a very
| expensive lesson one day, or they may get lucky. Time will
| tell.
|
| ---
|
| Depending on the design of your system and software stack,
| switching SoCs can be anywhere from a massive effort to a
| simple recompilation. Even switching architectures could be
| trivial for some components(i.e. a UI written in HTML5 making
| REST API calls) or a nightmare for others(ECU, ABS or other
| real-time algorithm written to use bare metal modules on the
| SoC without an OS providing abstraction).
| baybal2 wrote:
| It is very troubling development when doing something so
| trivial even requires a computer.
|
| That's a matter readily solved by a PID controller made of a
| few dozen 74XXX parts. Possibly made n-times redundant.
|
| Even a more fancy LP solver probably wouldn't need a fully
| fledged computer.
| SkyPuncher wrote:
| It's really easy to over react because of the silicone
| shortage, but in many cars these chips are replacing
| physically manufactured parts or significantly increasing
| efficiency in a way that isn't possible with physical based
| components.
|
| Electronic fuel injection is a _great_ example. Much of
| modern fuel efficiency stems from the fact that an engine
| can accurately control fuel in the cylinder based on a
| bunch of factors. Not only does this system require
| physically fewer materials, it uses less gas (in turn
| saving production effort).
| baybal2 wrote:
| I think you are misunderstanding me.
|
| What I mean under a computer is a Turing complete
| machine. A circuit just doing some LP solving, or PID is
| not necessarily a computer.
| rcxdude wrote:
| Very little applications strictly _need_ a turing
| complete machine. However microcontrollers are ubiquitous
| because they are so flexible. One chip does the job of
| many, and without needing to be specialised, allowing all
| applications to take advantage of the economies of scale
| in semiconductor manufacturing. (Also as pointed out here
| you drastically underestimate the complexity of a modern
| ECU)
| SkyPuncher wrote:
| By that explanation, I actually 100% confident I'm
| understanding you correctly.
|
| Most of the functionality of these chips can be
| represented in some form of hardware. However, that
| hardware is often much more expensive, significantly less
| flexible, and likely significantly bulkier.
| avianlyric wrote:
| There's nothing trivial about a modern internal combustion
| engine. The throttle control system is doing quite a bit
| more work than just opening and closing a physical throttle
| valve.
| tziki wrote:
| Ah the classic HN "just use this things I just came up
| with".
|
| https://xkcd.com/793/
| cycomanic wrote:
| I actually believe programmers/software engineers are the
| new physicists in this regard.
| KZerda wrote:
| Okay, so you've designed it. Now, make sure it works with
| the dirty electrical signal of a typical car's power bus.
| Then make sure it fits in the space requirements of under
| the car's hood, or in the door, or any of the other tight
| places that these embedded systems go. Then make sure that
| it's verified to act over several years of vehicle life.
| Then, make sure your suppliers will guarantee you that they
| won't discontinue the part for at least 10-15 years because
| of legal requirements for spare parts. Just throwing
| discrete logic at the problem doesn't always help.
| dharmab wrote:
| ECUs are simpler to build than the mechanical components
| they replaced and do things impossible to do mechanically
| (given the space and weight limits of a car).
|
| Jadon Cammisa has a great series on this stuff. Here's just
| one episode on one topic, drive by wire throttle control:
| https://youtu.be/gKsCHx5NOMM
| joking wrote:
| Simpler to build, and even simpler to overbill for them.
| Is insane to charge over 1000$ for some replacement logic
| board.
| baybal2 wrote:
| Most drive by wire systems I seen are nothing, but a
| simplest closed loop PIDs.
|
| It's very close to what you are taught in the "How to
| write a PID controller" class without much extra
| creativity.
| kevin_thibedeau wrote:
| Deciding how much fuel will be injected each cycle is not
| just a simple PID. The throttle body control may just be
| a basic servo (although it probably isn't) but the system
| controlling it is more complicated.
| baybal2 wrote:
| A separate circuit to map fuel/gas ratio for a given
| sensor input is also not a rocket science.
| dharmab wrote:
| Have you looked at any vehicle from the past 3-5 years? I
| own one with drive by wire and you can feel and hear it
| reacting to variables when you push it to the limits
| (either in inclement terrain or on a closed course). The
| linked video has specific video examples from production
| vehicles as well.
| [deleted]
| HeyLaughingBoy wrote:
| Let's start by assuming that the engineers are at least
| basically competent, shall we?
|
| I mean, I could implement a PID controller without any
| 74xxx logic at all: a basic op-amp, a handful of resistors
| and capacitors and _boom_ I 'm done!
|
| But there's a reason that engineering doesn't do that these
| days and it's not that engineers don't know how. My PID
| control built from an opamp? In 2021 that's almost always a
| stupid idea. We use computers because doing it digitally
| has many advantages. We don't use 74xx (or any other logic
| family) for this because microcontrollers are far more
| flexible, allow for behavior changes without reworking
| hardware, allow inventories to scale (the same component
| can be used in hundreds of products) and more reasons I
| won't detail.
|
| The reality is that in 2021, often the simplest, most
| robust and cost-effective way to do something trivial _is_
| by using a computer to do it.
| baybal2 wrote:
| > The reality is that in 2021, often the simplest, most
| robust and cost-effective way to do something trivial is
| by using a computer to do it.
|
| Very much not. Complicated MCUs are a very risky single
| vendor supply, and as we see now, people are now paying
| for an engineering overkill.
|
| 74xxx are available in every shape, and form, from dozens
| of suppliers.
| kortex wrote:
| Ok, lets assume for a moment that throttle can be modelled
| by a PID plant (it can't) - is the circuit temperature
| stable? You don't want the characteristics changing as the
| engine. Now you need a compensator circuit. What about
| power supply stability and noise? Car power busses are
| hella noisy, due to alternator and spark coil. Now you need
| some serious conditioning and filtering. What about
| knocking? Modern ECUs adjust parameters on knock detection
| to reduce the damage from pre-ignition. Gotta put in a
| control system for that.
|
| Repeat for manifold air temp, exhaust temp, emissions, rev
| limiter, etc., and as you mention, make that 3x for
| redundancy. Now you have hundreds to thousands of
| components, in a high noise, vibration, and temperature
| environment, and you have something which is about as
| efficient as an 80s car. And you can't as easily simulate
| it cause it's analog.
|
| Or just use some digital chips and simulate all the tuning.
| agumonkey wrote:
| > That obviously allows them to out-compete other auto
| manufacturers who are more aware of things like product
| liability
|
| A lot of this era comes down to this. You have a legacy
| industry with tons of regulations, then a new guy comes up,
| steps on all the lines, and convinces people they're smarter
| for doing more for less. (up until regulations come back in
| the equation).
| shiftpgdn wrote:
| Toyota accelerator-gate is largely a farce. Almost all of the
| people involved with Toyota unintended acceleration were over
| the age of 65 and had the poorly designed loose floor mats in
| their cars.
|
| Even if they had perfect readable John Carmack tier coding
| they still would have lost.
| [deleted]
| jcampbell1 wrote:
| I worked for ford many years ago and I remember a really
| funny conversation between young engineers and MBA types.
| The issue was the Lincoln Towncar was designed to have
| extremely low pedal pressure because that is what the old
| buyers liked. Combine old people with limited hearing, no
| pedal pressure, and a quiet cabin it was a perfect recipe
| for old people to shift and send the car through the garage
| wall. Lol. The classic issue of when customers want
| something stupid, do you build it?
| wrycoder wrote:
| Easy to do. I stepped on the accelerator instead of the
| brake once. First impulse is to step harder, until you
| realize what's going on. If your realization is slow, bad
| things can happen.
|
| If bad things happen, the tendency is to blame someone
| else.
| andi999 wrote:
| One solid step on the accelerator easily let's bad things
| happen below 1s.
| WalterBright wrote:
| The pedals are close together in my car, and a couple times
| I have hit the accelerator rather than the break. But I
| knew immediately what was wrong and adjusted.
| radicalbyte wrote:
| It literally took me years to understand it - how can you
| accelerate by accident? Until someone mentioned that all of
| these cars were automatics.
|
| But every automatic I've ever driven (not many - I prefer a
| clutch) moves forward unless you're pushing the break in.
| In the rest state, it's in motion.
|
| The problem isn't Toyota, the problem is a broken system.
| gedy wrote:
| People panic and jam the wrong (or both) pedals. (There
| are quite a few people who use two feet to drive
| automatics, one foot for break, other for gas..)
| lostlogin wrote:
| > There are quite a few people who use two feet to drive
| automatics
|
| They are very irritating to drive behind. Some seem to
| keep pressure on the brake pedal, and the brake lights
| stay on as they accelerate. When they slow it takes
| longer to realise they are braking as the lights have
| been solidly on.
| frosted-flakes wrote:
| Are you sure they're not just driving a manual
| transmission car? I can keep my foot lightly on the brake
| and apply the clutch to accelerate, without touching the
| accelerator pedal (diesel engine has a lot of low-end
| torque). Not that I do this in practice, except in drive-
| through lines just for the fun of it.
|
| In first gear I can reach 8 km/h, but it's possible to
| get all the way to fifth gear while idling (takes a long
| time though).
| swiley wrote:
| I thought you would fail most driving tests doing that.
| mpyne wrote:
| That's a mechanical side effect of the torque converter
| used in automatics, which even at engine idle with no
| acceleration input is able to transfer power to the
| drivetrain.
|
| The Toyota case was an instance of the car's engine
| control software unexpectedly commanding acceleration not
| requested by the user.
|
| In principle it could happen on a manual car as well, but
| most of Toyota's vehicles in the U.S. are automatics.
| AlfeG wrote:
| Not sure how is this possible. Automatic cars almost
| always require You to push brake constantly if you not
| driving. You can't turn car on without pressing brake,
| can't change to drive mode from parking state without
| pressing brake. There should be something very broken in
| Toyota case.
| andi999 wrote:
| Automatic handbreak at a traffic light?
| 01100011 wrote:
| Sure but that's not related to the point I'm making. The
| point is that not following software design best practices
| can leave you open to liability, or at least put you in
| such a weak legal position that you are compelled to
| settle.
|
| If/when Tesla gets hauled into court over its software
| flaws, any lack of adherence to best practices will make
| the company appear negligent.
| thoughtstheseus wrote:
| This is a risk adverse culture then. Tesla is spending
| gobs of money specifically on building safer if not the
| safest cars out there.
| kevingadd wrote:
| How do you square that with them removing sensors from
| their cars and going all-in on doing self-driving
| exclusively using vision? If they were so passionate
| about spending money to make the safest cars, they'd be
| doing sensor fusion.
| tantony wrote:
| > If they were so passionate about spending money to make
| the safest cars, they'd be doing sensor fusion.
|
| That's your opinion. They have shown data where the
| information from radar was of a lower quality than what
| their vision stack was providing (e.g. lack of vertical
| resolution). Watch their AI day webcast for examples.
| Their current vision-only stack has been validated with
| LIDAR ground-truth data.
| heeen2 wrote:
| Is anyone arguing for replacing vision with lidar and
| radar instead of combining it?
| matz1 wrote:
| They specifically mention because camera is better than
| radar. It gives more information than radar.
|
| https://twitter.com/elonmusk/status/1380796939151704071?s
| =19
| giantrobot wrote:
| > building safer if not the safest cars out there
|
| Unless the car loses power and catches fire. Then you
| can't open the fucking doors [0].
|
| [0]
| https://www.washingtonpost.com/business/2019/10/23/man-
| died-...
| ahepp wrote:
| Isn't the fact that Toyota lost this case damning to
| traditional automotive software development practices, rather
| than evidence of their importance?
|
| The traditional players are already doing a bad job trying to
| write safety critical software the way things are now.
| pokerhobo wrote:
| See https://www.youtube.com/watch?v=w5c5KzpamiM by someone
| who worked for a number of auto OEMs including Tesla where he
| explains how Tesla does agile hardware
| rectang wrote:
| From earlier discussions here
| (https://news.ycombinator.com/item?id=9643551 "10,000 global
| variables"), Toyota's conservative, arguably antiquated
| approach to software architecture wouldn't necessarily prove
| reliable as that software evolves.
|
| Trying to assess whether thousands of global variables are
| still playing nice during a major rewrite to accommodate a
| new chip would be definitely be difficult and time consuming!
|
| Not that a fast-and-loose approach is ideal, either.
|
| Writing reliable software in the context of an organization
| is hard.
| finnh wrote:
| 10K global variables sounds insane, until i realize "oh,
| huh, we have that too, we just call it _config_".
|
| Almost every place we would have a constant (tuning
| parameters, etc) we instead have a configurable value with
| the likely default declared in code, but all overridable in
| config. Managing config can be a hassle, but the number of
| times we've merely had to tweak a value rather than roll a
| new build pays for itself every day.
|
| We have thousands of such "global variables"... of course
| they are read-only, so aren't used to share state.
|
| If Toyota is doing that: nbd. If they are using them to
| share state ... god have mercy on their souls.
| tremon wrote:
| I always interpreted the "10K global variables" to mean
| 10K directly accessible, heap-allocated symbols. It's a
| code reek. If you use a configuration object or other
| abstraction, the number of accessible variables may not
| change, but their scope and access method does.
|
| It's a matter of interpretation I guess, but I would not
| classify a wrapper object (like .Net's
| ConfigurationManager singleton) as "10K global variables"
| even if the accompanying config contained 10K items, or
| if the ConfigurationManager backing store was
| preallocated in the data section of the binary.
| delfinom wrote:
| >I always interpreted the "10K global variables" to mean
| 10K directly accessible, heap-allocated symbols. It's a
| code reek.
|
| Which to me on an old _accelerator_ design is suspect
| because that's alot of heap for the micros that would
| have been used back in the day. This isn't a Linux
| system. It was at best a micro with like 8KB of RAM. (I'm
| not actually sure what it is but there's no way it was
| impressive).
| [deleted]
| rightbyte wrote:
| If they used Simulink, the model output and input, aswell
| as state, are global variables when generated to C in
| some settings.
| jowday wrote:
| I mean they also just dropped certain feature, like radar on
| autopilot.
| nbernard wrote:
| But for the cost, couldn't (for instance) a 16nm fab produce 90nm
| chips?
|
| If not, how complex would it be to "port" an existing 90nm chip,
| to produce a 16nm revision? Impossible, or quite easy but not
| cost effective? From the POV of the car companies, could such
| revisions be used directly, or would they need to be qualified in
| the same fashion as new parts?
| coryrc wrote:
| No and about as expensive as having designed it in the first
| place. Given design costs are the largest portion of per-unit
| costs it's not a good investment.
| pedrocr wrote:
| Could you explain why not? Naively, having a much more dense
| process should allow automatic conversion. Going from 90nm to
| 16nm is 10x the density, that's a lot of margin for an
| automatic tool to use. Why doesn't that work?
| coryrc wrote:
| It's more than just a size change and there are features
| besides transistors. Say you have a 100 fF capacitor; is
| that because that's the right value based on an external
| constraint (say, interacting with a crystal) or because
| it's matching the inductance of a long internal path?
| Because you adjust them differently based on circumstance.
| And your transistors with a specific load must still supply
| the same current as before so they can't shrink as much as
| ones for internal logic.
|
| Also because the materials have changed the dialectic
| constant probably has and now the relative sizes of
| components need to adjust. And circuits are designed to
| minimize switching loss based on the old switching time and
| now they'll be wrong.
|
| Oh, and the breakdown voltage of the new process can't
| handle the voltage many of these old circuits use IIRC.
| VLM wrote:
| If you're bored you can go to mycmp.fr and check their process
| catalog and compare a typical 55nm run to a 160nm run. Its not
| quite as standardized as ordering PCBs over the internet.
|
| Different metallization (you usually don't get to choose Al or
| Cu) will have different resistances. Generally the smaller
| processes will be faster so a design with no race conditions or
| metastability problems on 160 might not run reliably or at all
| on 55. Some processes are analog oriented so they'll guarantee
| up to 60 volts or more, if you're trying to design power
| devices, other processes are logic oriented and they might have
| a standard voltage of 2.5, 1.1 etc.
|
| You can design something that'll run on a 55nm process and
| something that'll give similar performance on a 160nm process
| BUT they'll be different designs. I think the closest analogy
| would be changing processes is like changing manufacturing
| material. You can make a car piston out of steel or aluminum
| but you can almost never just swap materials in an existing
| assembly line.
| dboreham wrote:
| Admittedly it was a long time ago, but I worked in the semi
| industry and this isn't how things were done. We manufactured
| batches of totally obsolete EOLed devices for various customers
| when they had sufficient volume. Devices that are in volume
| production (e.g. for cars) are carefully managed by people who do
| nothing but ensure that they're available in the right place at
| the right time in the right volume. In order to not have product
| available to meet demand either a factory has to go on fire, or
| the customer has to screw up their forecast.
| UncleEntity wrote:
| Due to covid I'm back to driving trucks and they have the same
| supply problems as everyone else -- the dude I'm working for
| can't find a used truck to put me in because new trucks are
| taking 6-8 months to get.
|
| Used trucks sell as fast as they go up on the websites (with
| the lease returns from the company we're running for selling
| even before that) and the truck dealers apparently think this
| is the time to charge excessive finance fees (basically
| doubling the cost of the truck) because they can.
|
| Quite a stressful time...for him. I don't really care since I'm
| making money and team driving isn't as bad as I remember it
| from the last time I did it 23 years ago.
| mkr-hn wrote:
| The customers screwed up the forecast. That's a huge part of
| the problem. They assumed the pandemic would kill demand and
| cancelled orders, but it didn't, and the cancelled capacity was
| already sold to someone else.
| tyingq wrote:
| As I understand it, there's also the case that you can't just
| move from one fab to another of the same process size at
| will. There's different setup/software/procedures, so the
| capacity isn't instantly interchangeable. There may even be
| fabs with excess capacity, but no "ready" customers.
| zdragnar wrote:
| I know of dealerships that had sales drop by 95% in the
| initial months of the pandemic. What they got wrong was the
| duration of the drop and that sales would bounce back, rather
| than simply return to normal after a bit.
|
| Now some dealerships are selling new cars _above_ MSRP, just
| because supply is so low.
| slavik81 wrote:
| There was also a factory fire.
| https://news.ycombinator.com/item?id=26558359
| baybal2 wrote:
| What an irony. Car makers with their volumes can buy decades
| worth of these STM32s for the price of a single car...
| jnsaff2 wrote:
| Come on, let's say they get the STM32 for a quarter for a
| really high volume. There are tens if not hundreds of them in
| a car. 25k car would give you 100k stm32. 1k-10k cars is
| hardly decades.
| kube-system wrote:
| And that's just one component.
| [deleted]
| DarkmSparks wrote:
| Really well written investigative piece. Its so often forgotten
| that safety critical hardware like a car ecu dances to a
| different rhythm than consumer electronics that just has to not
| explode in your pocket..
| Azsy wrote:
| At the root is the question: "Do we make it more complex" or "Do
| we do try it 3 times".
|
| The carmakers have been making the wrong call for the past
| decades.
|
| One of their suppliers has eclipsed their impact on society,
| marking one of the first times in something like ~70 years that
| things didn't bend over to meet their needs.
|
| ----
|
| And before you ask. Yes i would rather have a pace-maker with
| triple redundancy and thrice redesigned.
| dotancohen wrote:
| The fine article quotes the Intel CEO: > "I'll
| make them as many 16 nanometer chips as they want"
|
| However, > Carmakers have bombarded him with
| requests to invest in brand-new production capacity for
| semiconductors > featuring designs that, at best, were
| state of the art when the first Apple iPhone launched.
|
| He then says of that: > "It just makes no
| economic or strategic sense"
|
| So if we look at this from a capitalistic standpoint, automakers
| are not offering enough money to convince Intel to continue
| supplying their "old" types of chips. Either the automakers need
| to supply a convincing amount of money, or they need to adapt as
| their suppliers change priorities.
| hef19898 wrote:
| Or Intel will loose that _entire_ market to some company that
| can make the business case happen.
| rasz wrote:
| >automakers are not offering enough money to convince Intel to
| continue supplying their "old" types of chips
|
| Like that time Apple was "not offering enough money to convince
| Intel to continue supplying their "old" types of chips" aka the
| StrongArm
| csense wrote:
| I always thought chips were dominated by fixed capital costs of
| fabs. If they were dominated by variable material cost of wafers,
| as the article seems to imply, it wouldn't make sense that we see
| 90nm microcontrollers that sell for $1 and a high-end 16nm PC CPU
| that sell for $1000.
|
| So the question is, what's the reason that 90nm microcontroller
| sells for $1?
|
| I'm trying, and failing, to figure out an economic model that
| explains the market dynamics we actually observe.
|
| If building a new 90nm fab costs $billions, almost as much as
| building a new 16nm fab, why does the 90nm microcontroller sell
| for 0.1% of the price of the 16nm Xeon?
|
| If building a new 90nm fab costs 0.1% as much as building a new
| 16nm fab, why can't existing chip companies, some startup or GM
| themselves spend $10's of millions building a fab that can
| unblock $100's of millions of product, and alleviate the
| shortage?
| sbierwagen wrote:
| Chips made on modern processes _are_ dominated by capital
| costs. Old chips are made on old foundries, which are fully
| depreciated and therefore have no capital costs. If you made a
| 90nm foundry today, then it probably couldn 't sell those
| microcontrollers for less than $100 each, just like a modern
| CPU.
|
| >why can't existing chip companies, some startup or GM
| themselves spend $10's of millions building a fab that can
| unblock $100's of millions of product, and alleviate the
| shortage?
|
| They can't do it fast enough. Standing up a new foundry takes
| years under the best circumstances, and today you couldn't do
| it all, since all the tooling is sold out and deeply
| backordered. If GM could snap their fingers today and magic a
| cleanroom into existence, they'd still be waiting a hell of a
| long time to put tools in it.
|
| Secondly on the price question, microcontrollers just have way
| fewer gates than a desktop CPU. A dozen registers, a thousand
| bytes of RAM, a few kilobytes of flash. This makes them
| physically smaller, which lets you put more on a wafer, and
| makes the unit price cheaper. The total die area of the ATmega8
| is just 7.9 square millimeters... at the 500nm node!
| https://zeptobars.com/en/read/atmel-atmega8 This gets you 8,100
| dies from a single 300mm wafer. (If there are any 300mm
| foundries at 500nm, which there probably aren't)
|
| Thirdly, what makes you think anyone could build a 90nm foundry
| at all?
|
| Take a look at a list of foundries:
| https://en.wikipedia.org/wiki/List_of_semiconductor_fabricat...
| I don't see anything making 90nm after 2014.
|
| Which makes sense. Fabs don't make all their tools in-house,
| that's done by vendors. As an example of one tool, by one
| vendor, the NXE:3400B EUV stepper by ASML. Unit cost, $175
| million: https://www.tomshardware.com/news/tsmc-euv-tools-order
|
| These are ultra-bespoke, super-low-volume machine tools. ASML
| makes a couple dozen or a hundred steppers of a given model,
| then shuts down production and starts upgrading to the next
| node. Is it even possible to buy a new 90nm stepper today?
|
| I'm sure they have all the documentation and could roll back to
| the previous generation easily enough, if they had to. (Which
| they don't! They are maxed out just supplying current-gen
| tools) But given all the voodoo in semiconductor lithography,
| people retiring etc, I bet that rolling back two decades would
| pretty much require starting from scratch.
| fidesomnes wrote:
| Just like how they can't build electric vehicles 10 years ago.
| Yeah sure. The automotive industry is run on room temperature
| IQ's.
| tbabb wrote:
| That website is unreadable on mobile due to ads.
| EastOfTruth wrote:
| Block ads?
| adamrmcd wrote:
| I'd love to see Ken Sherrif do a teardown of some vintage ECM.
|
| https://www.autotrader.com/car-news/when-did-cars-get-comput...
|
| (tldr)
|
| > So instead of one clear answer, we have three possibilities:
| 1957 Rambler, 1958 Chrysler or 1968 Volkswagen.
| csours wrote:
| Disclaimer up front: I work for GM. I don't work on chips or
| components for my day job. What follows is solely my own opinion.
|
| Some things to emphasize:
|
| OEMs (GM, Ford, Toyota, VW, etc) do not design components, and
| they do not want to. They design specifications for components,
| and then get suppliers to bid. This is great for efficiency in
| established ecosystems, not great for agility.
|
| To my knowledge, GM did not cancel any chip orders, because GM
| itself had no chip orders (this is oversimplified). The suppliers
| cancelled chip orders.
|
| For a 1st tier supplier to move to a different process/chip would
| also be difficult, because they do the same thing the OEM does -
| supply a specification, and get 2nd/3rd tier suppliers to bid on
| it.
|
| A wholesale migration to a modern architecture is risky and
| costly.
|
| Smaller process/feature size on a wafer is believed to be less
| resilient, for example to heat and vibration.
|
| The risk to large automakers is that something goes wrong and
| they have to do a recall. The risk to up and comers (Tesla) is
| failure to grow. Also, Tesla has a small product line and
| absolute loads of cash.
|
| If you were going to design a new car electrical architecture
| from scratch today, you would have something like a 40-60V system
| with a centralized controller (or pair of controllers in a safety
| redundant configuration).
|
| Even with a largely cleansheet design, Tesla uses 12V because of
| the sheer ubiquity of 12V components.
| sandGorgon wrote:
| > _If you were going to design a new car electrical
| architecture from scratch today, you would have something like
| a 40-60V system with a centralized controller (or pair of
| controllers in a safety redundant configuration)._
|
| Actually this point is something im curious about - it seems to
| be redundant to have a 3X redundant processor ..probably placed
| in different places on the car body for safety.
|
| Would that not be superior to current architecture..while being
| able to tap into the most modern chip architecture of the day ?
|
| I'm not a car engineer and dont understand CANBUS, etc. But
| just wondering if this is indeed possible.
| csours wrote:
| Do not take any of this as a particular endorsement of a
| safety system.
|
| Airplanes need 3x redundancy on safety critical components,
| because they carry a lot of people and are not fail safe when
| they are in the air. Cars can generally stop safely.
|
| As far as changing architectures - think about safety
| critical loops and real time computing. Some processes should
| never be pre-empted.
| perl4ever wrote:
| >Cars can generally stop safely.
|
| "Brake-by-wire is used in all common hybrid and electric
| vehicles produced since 1998 including all Toyota, Ford,
| and General Motors Electric and hybrid models."
|
| "Three main types of redundancy usually exist in a brake-
| by-wire system: Redundant sensors in
| safety critical components such as the brake pedal.
| Redundant copies of some signals that are of particular
| safety importance such as displacement and force
| measurements of the brake pedal copied by multiple
| processors in the pedal interface unit. Redundant
| hardware to perform important processing tasks such as
| multiple processors for the ECU"
|
| "The highest potential risk for brake system failure has
| proven to be the Brake Control System software. Recurring
| failures have occurred in over 200 cases documented in NTSB
| documents. Because each manufacturer guards the
| confidentiality of their system design and software, there
| is no independent validation of the systems.
|
| As of 2016 the NTSB has not directly investigated passenger
| car and light truck brake-by-wire vehicle accidents, and
| the manufacturers have taken the position that their
| vehicles are completely safe, and that all reported
| accidents are the result of "driver error"."
|
| https://en.wikipedia.org/wiki/Brake-by-wire
| formerly_proven wrote:
| Generally speaking those are not _purely_ brake by wire.
| The master cylinder is still mechanically connected to
| the pedal. However, in normal conditions the brake
| actuation will be performed over wire.
| perl4ever wrote:
| This is a question of semantics, but I don't understand
| your usage of "purely".
|
| How can it not be "purely" brake by wire, if, when
| depressing the brake pedal, the friction brakes are not
| always triggered?
|
| If electronics decide not to apply hydraulic force when
| everything is going fine, that there must be a potential
| failure mode where they ignore the pedal inappropriately.
|
| Can you explain further?
| formerly_proven wrote:
| In a brake-by-wire car, if you stomp on the brake pedal
| with all you've got you end up engaging a cylinder that
| can directly exert force on the front brakes, even if the
| electronics are fully dead. (Maybe there are some systems
| where the brake pedal is truly just a "dimmer switch",
| but I've not been able to find them).
| smolder wrote:
| Yeah, brakes that don't function when power is lost would
| just be too brittle. That'd be unacceptable in any market
| regulated by one or more working brains.
| tullianus wrote:
| Most SpaceX hardware works this way: off-the-shelf processor,
| triply redundant, using voting to figure out if one is wrong.
| api wrote:
| > OEMs (GM, Ford, Toyota, VW, etc) do not design components,
| and they do not want to. They design specifications for
| components, and then get suppliers to bid. This is great for
| efficiency in established ecosystems, not great for agility.
|
| There are some great stories about SpaceX trying to source
| components this way and then finally ending up having to DIY.
|
| What they found was that modern CAD and rapid prototyping made
| it easier than it used to be. Car companies would probably find
| the same thing, and have the luxury of doing it piecemeal at
| their own pace by gradually insourcing components in the order
| of necessity or benefit.
|
| The "do not want to" part probably points to these companies
| being run by Ivy League MBAs educated in the 1990s and 2000s
| when this was conventional wisdom. The world is changing.
| weinzierl wrote:
| I worked in aerospace for six years before changing into
| automotive. The difference could not be bigger.
|
| In aerospace cost didn't matter a lot and many things are
| custom built, even down to custom alloys and materials. Also
| the amount of planning, numerical analysis, simulation,
| preparation and especially testing is insane. Project
| timelines are sometimes more than a decade.
|
| In automotive 'cost down' is _the_ mantra and is often enough
| measured in fractions of cents. Almost nothing is customized
| and parts reused for different product lines whenever
| possible.
| BuyMyBitcoins wrote:
| I wish company leadership knew that conventional wisdom is
| time-bound and has an expiration date. Of course, actually
| trying to figure out if the conventional wisdom still holds
| involves risking time and money on R&D. And, the larger the
| institution the more risk averse the leadership will be. It's
| a real shame that the companies you would think have the most
| ability to absorb risk are the most averse towards taking
| them.
| roughly wrote:
| It's not just science that advances one funeral at a time.
| cainxinth wrote:
| > A wholesale migration to a modern architecture is risky and
| costly.
|
| I have no doubt that your company and all the other big
| automakers are running the numbers and trying to weigh those
| risks and costs with the risks and costs of not updating.
|
| Given that the chipmakers and supply chain experts are not
| making rosy predictions for things to drastically improve in
| the next 12 months or longer, I wonder if the balance is
| shifting towards taking action.
| csours wrote:
| > "I wonder if the balance is shifting towards taking
| action."
|
| I can't find a public source, but some actions are being
| taken. Bear in mind that any major shifts would happen in a
| new product, that is, something 5-7 years out.
| mwint wrote:
| Fundamentally, what is it that prevents the established
| auto makers from making changes mid lifecycle? Seems like
| Tesla keeps pulling it off; why can't GM?
|
| Is it that the component specification+acquisition cycle
| you describe is optimized to take as long as the
| development cycle of a new car?
| willcipriano wrote:
| That would be disruptive to the fiefdoms and all put all
| the feudal lords into a tizzy.
| syntaxing wrote:
| Disclaimer: I work and worked for subsidiaries of big
| automakers but this opinion is of my own.
|
| I would guess it's a mixture of culture, cost, and scale.
| Culture wise, Tesla is extremely vertically integrated so
| that gives them a lot more breathing room. Cost wise,
| Tesla pretty much still sells car at a loss and relies
| heavily on carbon offset subsidies for income. When your
| revenue is established, trying to change margin or
| anything is probably much more difficult. Lastly, it's
| scale, while Tesla is trying to catch up, the throughput
| of the major automakers is absolutely mind defying. The
| whole system is an oil machined that any sort of downtime
| is detrimental and difficult once the line is
| established. To put into perspective, Tesla "monumental"
| Q2 quarter shipped 200K cars or so. GM in the US only
| sold 200K per month.
| panick21 wrote:
| > Cost wise, Tesla pretty much still sells car at a loss
| and relies heavily on carbon offset subsidies for income.
|
| I'm sorry but that is just straight up complete nonsense.
| Like seriously, you are directly disagreeing with public
| financial statements. We know exactly how much margin
| Tesla has, with and without carbon offset.
|
| The simple fact is, Tesla has leading automotive margins
| even when you exclude any carbon credits.
| mcguire wrote:
| Hmm. I'm not sure I'd go strongly either way.
|
| According to reports
| (https://www.cnn.com/2021/01/31/investing/tesla-
| profitability...) Tesla received $1600M in regulatory
| credits and had a net income of $721M.
|
| If you look at the 10K (https://www.sec.gov/Archives/edga
| r/data/1318605/000156459021...), Tesla received $27,236M
| in automotive revenues (which includes sales of
| regulatory credits, thanks Elon). The corresponding cost
| of sales is $20,259M giving gross profit of $6,977M and
| gross margin of 26%. But after that, you have operating
| expenses ($4,636M) (blah, blah, interest, taxes, other,
| blah) and a final net income of $721M.
| brianwawok wrote:
| You need to read their financials closer. They are
| profitable without offsets.
| csours wrote:
| Small company risk is failure to grow. Big company risk
| is every other failure.
|
| Tesla is valued as a growth/tech company. As long as
| people believe in their growth, they get more cash.
|
| I don't personally understand how Tesla hasn't had more
| problems with their apparently uncontrolled engineering
| changes. At least part of it is customer enthusiasm for
| the product papering over any drawbacks.
|
| It's not that GM can't make changes like this, it's that
| GM WON'T make changes like this.
|
| All of this is, again, solely my own opinion.
| kjksf wrote:
| Alternatively, maybe just like SpaceX has faster
| development cycle AND greater safety and reliability of
| rockets, Tesla has faster development cycle AND greater
| safety and reliability of cars?
|
| Judging by the number of recalls, Tesla doesn't seem to
| be doing worse than GM, Porsche or Ford.
| vvanders wrote:
| Their EMMC issue on the S was pretty egregious, that's
| something you get right in even basic consumer
| electronics. They also had numerous issues with door
| handles(I had two fail once the car was outside of
| warranty).
|
| There's things they do well but I don't know if I'd
| qualify them as having better reliability.
| optimiz3 wrote:
| Tesla is past the cash raising phase though - they are
| massively profitable and actively retiring debt early.
|
| https://www.sec.gov/ix?doc=/Archives/edgar/data/1318605/0
| 000...
|
| "On July 16, 2021, we issued a notice of redemption to
| the holders of the 2025 Notes informing the holders that
| we will redeem the notes in full in August 2021 at a
| redemption price equal to 102.65% of outstanding
| principal amount, plus accrued and unpaid interest, if
| any."
| csours wrote:
| They are raising money by selling stock.
| perl4ever wrote:
| >Tesla is past the cash raising phase though
|
| It appears to me that they are steadily issuing stock at
| the rate of about 20% of their market cap per year, or
| roughly at the rate of $10 billion per month.
|
| It looks like the number of (diluted) shares outstanding
| increased by over 20% between 2019 and 2020.
|
| What did that consist of? Their annual report says
| mainly: - Issuance of common stock for
| equity incentive awards - Issuance of common stock
| in public offerings
|
| e.g. "On February 19, 2020, we completed a public
| offering of our common stock and issued a total of 15.2
| million shares (as adjusted to give effect to the Stock
| Split, as described in the paragraph below), for total
| cash proceeds of $2.31 billion, net of underwriting
| discounts and offering costs of $28 million."
|
| "On September 1, 2020, we entered into an Equity
| Distribution Agreement with certain sales agents to sell
| $5.00 billion in shares of our common stock from time to
| time through an "at-the-market" offering program. Such
| sales were completed by September 4, 2020 and settled by
| September 9, 2020, with the sale of 11,141,562 shares of
| common stock resulting in gross proceeds of $5.00 billion
| and net proceeds of $4.97 billion, net of sales agents'
| commissions of $25 million and other offering costs of $1
| million."
|
| "On December 8, 2020, we entered into a separate Equity
| Distribution Agreement with certain sales agents to sell
| $5.00 billion in shares of our common stock from time to
| time through an "at-the-market" offering program. Such
| sales were completed by December 9, 2020 and settled by
| December 11, 2020, with the sale of 7,915,589 shares of
| common stock resulting in gross proceeds of $5.00 billion
| and net proceeds of $4.99 billion, net of sales agents'
| commissions of $13 million and other offering costs of $1
| million."
|
| Also, as of their 2020 annual report, roughly a billion
| shares were authorized to issue, which is on the order of
| another 100%, or double the current outstanding.
|
| https://www.sec.gov/ix?doc=/Archives/edgar/data/1318605/0
| 001...
|
| You might dismiss this as "way back in 2020", but it does
| seem to be their latest annual report.
|
| Their latest quarterly report is as of June 30, 2021, and
| guess what? Shares outstanding are up about 4.6%.
| Compounded over a year, that's going to be just about 20%
| again.
|
| 10-Q:
| https://www.sec.gov/ix?doc=/Archives/edgar/data/131860
|
| "Stock-based awards" seem to have been 93 million in the
| last three months. TSLA is around $775/share.
| oceanghost wrote:
| > I don't personally understand how Tesla hasn't had more
| problems
|
| It's that nobody cares and the media doesn't cover it. A
| friend of mine-- his Tesla has broken down a dozen times
| and he still happily pre-ordered the cyber truck.
|
| My 10-year-old Honda has never had any work done to it
| other than maintenance-- but that doesnt make the news
| either.
| brianwawok wrote:
| And if we go for antidotes, my current Tesla has had 0
| problems or recalls, my previous Honda had many many
| recalls and issues.
|
| This is not a useful way to look at a product.
| hef19898 wrote:
| Tesla has yet to do even a face lift on its Model S. In
| the meanwhile most incumbent OEMs either came up with EVs
| based on existing platforms or completely new EV
| platforms.
| rootusrootus wrote:
| The little changes are going to end up as technical debt
| they will pay for later. And notice that they haven't
| come out with any meaningful refresh of any of their
| cars, some of which have been on the market quite a
| while. It's definitely too soon to suggest they have a
| good, effective update strategy.
| raverbashing wrote:
| Yeah, I remember some talk about moving car buses to 24V or
| maybe even 48V but that didn't seem to have gained ground.
| hinkley wrote:
| The suppliers are running in pretty thin margins aren't they?
| Did they really have any choice but to cancel those orders or
| potentially go bankrupt?
|
| If you sit on someone's shoulders and forget that they're doing
| most of the work, you can be shocked all you want when they
| collapse out from under you but nobody on the ground is going
| to have any sympathy at all for you.
|
| I've worked for software subcontractors and it's always
| frustrating when the customer is so excited about all the
| things we're going to accomplish together, all the plans that
| hinge on our mutual success, and isn't it so wonderful that
| they're getting such a great deal on it too?
|
| Meanwhile we're slowly going broke because we can't make money
| on that sweetheart deal loaded with scope creep not spelled out
| properly in the contracts. Good luck with those plans when we
| go under.
| novok wrote:
| I don't think money is a problem in this specific case.
| Because of car shortage conditions they can afford to add a
| few hundred dollars to the MSRP and pay more for non-cutting
| edge chips and still come out fine.
| alfiedotwtf wrote:
| > If you sit on someone's shoulders and forget that they're
| doing most of the work, you can be shocked all you want when
| they collapse out from under you but nobody on the ground is
| going to have any sympathy at all for you.
|
| Ajax Fasteners where a small manufacturer in the name of
| Division of Labour, and when they went into receivership, it
| took down Australia's entire car industry. Let me repeat -
| Australia no longer has a car industry.
| tablespoon wrote:
| > Ajax Fasteners where a small manufacturer in the name of
| Division of Labour, and when they went into receivership,
| it took down Australia's entire car industry. Let me repeat
| - Australia no longer has a car industry.
|
| Holy crap:
| https://www.abc.net.au/worldtoday/content/2006/s1719988.htm
|
| You'd think the car companies could have just bought the
| manufacturing assets of the supplier if it was this
| critical (that's assuming they weren't looking for a back
| door excuse to shut down their own Australian production,
| that is).
| alfiedotwtf wrote:
| Holy crap indeed
|
| ... but the Australian car industry was nothing more than
| rent seeking anyway, so it was a good thing we stopped
| funding a non-utility.
| MichaelZuo wrote:
| ' sweetheart deal loaded with scope creep not spelled out
| properly in the contracts' That sounds more like a problem to
| take up with your lawyers?
| syshum wrote:
| Automotive is notorious in MFG for being one of the WORST
| industries to be a supplier in (at least for US Based
| Suppliers). Low Margins, and unrealistic demands by the big
| brands.
| syshum wrote:
| >>>To my knowledge, GM did not cancel any chip orders, because
| GM itself had no chip orders (this is oversimplified).
|
| Come on, Really? So GM cancelled the orders for all the tings
| that the chips go in, and you want to spin that as "well
| technically GM did not cancel the chips"
|
| That is bullshit.... The supply chain does not work like that,
| if GM cancels an order for 100,000 ECM's the supplier for the
| ECM is going to cancel their order for 100,000 chips for them
| to make the ECM for GM, it is unrealitic to believe anything
| else would happen.
| baybal2 wrote:
| > If you were going to design a new car electrical architecture
| from scratch today, you would have something like a 40-60V
| system with a centralized controller (or pair of controllers in
| a safety redundant configuration).
|
| Aircrafts historically been using high frequency AC, on both
| sides of the iron curtain (as both sides were copying each
| other.)
|
| Old analog instruments actually benefited from AC availability.
|
| And when SMPS were big, and heavy, transformers were much more
| reliable, and smaller (and they are still are, depending on the
| frequency)
|
| 3 phase power was also giving some interesting cost cutting
| benefits at the time
| snthd wrote:
| >40-60V system
|
| What makes that voltage a better trade off?
| optimiz3 wrote:
| Thinner wires can be used, which significantly reduces
| weight, complexity, and cost.
| zh3 wrote:
| Power is volts x amps. The more amps, the thicker the wires
| need to be (volts are irrelvant).
|
| So to minise weight/wire size, use the highest voltage
| possible (and thus the lowest current). Losses are purely
| related to current (I^2*R) so the incentive is to squeezee
| the current (so needing to increases the voltage).
|
| There's a reason the high-voltage overheads are 432 kilovolts
| (or more); 10 amps at 432kV = 4.3MW (MegaWatts) while 10amps
| from a stock AC outlet is 1.2KW (KiloWatts). The wire
| thickness required for both is the same (though the HV wires
| need to be better insulated, out of the way of crazy fools
| etc).
|
| So a 60V system for a car carries 1/5 the current of a 12v
| system, and the wires can have 1/5 the cross-sectional area.
|
| (yes, I know there are caveats when it comes to AC).
| a1369209993 wrote:
| > The more amps, the thicker the wires need to be (volts
| are irrelvant).
|
| Nitpick: the wire as a whole includes insulation, which
| technically does need to be thicker at high voltage (though
| at 40-60V, and maybe even at 40-60kV, it's probably
| dominated by tolerances for erosion and abrasion and such).
|
| High voltage power lines use air, which is actually a
| fairly good insulator _per se_ , but has the problem that
| wires tend to pass through it on their way to a short
| circuit if not well-restrained.
| a9h74j wrote:
| Recent TIL:
|
| Wire _guage_ follows a 10log10 of ohms per 1000ft, relative
| to 0.1 ohms per 1000ft:
|
| 0ga .. 0.1 ohms per 1000 ft
|
| 10ga .. 1.0 ohms per 1000 ft
|
| 20ga .. 10 ohms per 1000 ft
|
| 30ga .. 100 ohms per 1000 ft
|
| http://www.interfacebus.com/AWG-table-of-different-wire-
| gaug...
| csours wrote:
| Other comments pointed out why higher is better. The cap at
| 60v is somewhat arbitrary, but as others said, higher voltage
| is harder to switch, and above 60v DC it is easy to kill
| people.
| R0b0t1 wrote:
| Voltage levels sometimes arise from the geometry of
| semiconductors, capacitors, etc. 60V is a common cutoff,
| usually to give some slack to a 48V design voltage.
| formerly_proven wrote:
| Siblings covered why 12 V is annoying, let's talk about why
| 12 V was chosen in the first place.
|
| 6 and 12 V electric systems in vehicles came about because
| lead-acid batteries made sense in this application, and
| cetpar. a higher voltage lead-acid battery is overall
| costlier to manufacture, because it contains more individual
| cells. Another big thing is that there are many switches and
| relays in a car, and those often switch significant power.
| E.g. the light switch for the headlights has to deal with
| around 200 Watts total for incandescent/halogen headlights,
| indicators are like 15 Watt each front and back, the starter
| motor requires a tremendous amount of power, and has a very
| robust power switch built into it.
|
| All of those switches become much more expensive when you
| increase the voltage. DC at 12 V and sizable currents is
| something you _can_ reliably switch with mechanical contacts
| without costs going through the roof.
|
| Being able to use 48 V for everything in a car is more or
| less dependent on using silicon switches for everything, not
| something that was possible in the past. The reason why
| legacy ICE cars (all ICE cars are now legacy) stick with 12 V
| is because everything is 12 V, and everything would have to
| change for the new voltage.
| mcguire wrote:
| I seem to recall, several years ago (when stopping the
| engine at traffic lights and restarting as soon as the
| driver released the brake), at least one company was
| exploring moving to 24V. However, the effort failed
| precisely because the lifetime of 24V switches was
| significantly shorter.
|
| Naturally, I can't find any links to the info...
| winrid wrote:
| FWIW Almost no switches in a modern car (turn signals,
| wipers, door switches) carry a significant amount of
| current as they are controlled via confuzers.
|
| Just built a car without a single relay. I used PMUs
| (basically boxes of mosfets and current sensors AFAIK).
| perl4ever wrote:
| >All of those switches become much more expensive
|
| Wouldn't a more important question be _how does the failure
| mode change_?
| tuatoru wrote:
| Above 30V - 50V DC, contact arcing becomes a huge
| problem. (It's a problem below that, but less huge.)
|
| With AC, the arc will self-extinguish a half-cycle after
| the switch opens. With DC there is no cycle, and contacts
| can be completely vaporised in tens of milliseconds.
|
| Commodity switching components are usually rated "30V DC,
| 250V AC" for this reason.
|
| It is possible to design switches so that even DC arcs
| self-extinguish, but the result is expensive and not as
| reliable as one could wish.
|
| If cars had been invented after 1980, they would probably
| use solid-state switches except for the very high current
| circuits such as the starter solenoid and headlights.
| (Transistors were around a lot earlier than that, but
| engineers are sensibly cautious about new technologies.)
|
| Edit: To answer your question directly: no. Cost is
| prime.
| grecy wrote:
| Plenty of older diesel road vehicles like Land Cruisers run
| 48V for everything. They've been that way since the 80s
| (maybe 70s).
|
| Note: These were never sold in the North American Market,
| but they're extremely common in Australia, South Africa,
| etc.
| orthoxerox wrote:
| Lower amperage.
| dotancohen wrote:
| I'm not the OP nor an electrical engineer, but I believe that
| you can get higher DC power with less resistance losses using
| higher voltage and lower amperage. Additionally, this allows
| the use of thinner wire (lighter, cheaper, easier to package
| in tight locations).
| acranox wrote:
| Another factor I haven't seen mentioned in the responses yet
| is safety to human bodies. You (or your kid) can stick a wet
| finger in a 12V DC charger socket in your car and not get an
| electric shock, including any of the exposed contacts under
| the hood, including the battery terminals. But once you're up
| to 40-60V, the risk of electric shock to humans is actually
| something that needs to be factored in.
| R0b0t1 wrote:
| You'll get a shock if wet slightly below 9V. It just stays
| on your skin. Voltage penetrates dry skin at around 50V,
| and this is the legal definition of high voltage.
| HeyLaughingBoy wrote:
| Something I learned around 12 years old, licking the
| terminals of a 9V battery :-)
| YZF wrote:
| 40V is still fine IIRC. I think 48V is the threshold.
| oehtXRwMkIs wrote:
| What amperage are we talking about here? Discussions of
| electrical safety solely in terms of voltage is nonsense.
| buescher wrote:
| One of the big issues with 40-60V systems, which have been
| right around the corner for 20 years now, maybe more, has
| been that typical relay contacts arc over at about 28V DC.
| Yes, there are ways to adress this. No, none of them are as
| practical as relays yet.
| idiotsecant wrote:
| This isn't really a fundamental problem. It just means
| using relays with contacts rated for higher voltages. It's
| probably the _easiest_ part of the bom on a typical vehicle
| to move to a higher voltage range. I use 125VDC contact
| /coil rated relays all the time.
| formerly_proven wrote:
| It _is_ a fundamental problem (it 's physics). The
| current rating for relays drops off sharply as the DC
| voltage increases; you might see 125 V DC rating, but the
| current will be a fraction of the nominal current at the
| rated _AC_ voltage. If you 're using an relay rated for
| up to 250 VAC/DC, then the breaking capacity with DC
| might be as low as 1 % compared to AC. Bad relay
| datasheets don't mention this at all, or maybe only for
| 30 V. Good datasheets have plots of capacity vs. voltage
| and current vs. life (rated capacity of relays is
| generally for around 100k cycles).
| idiotsecant wrote:
| I am an engineer in a field that has been using >100VDC
| relays for _a hundred years_. There is a sizable supply
| chain out there for these things. You can buy them in
| whatever amperage you need, they just use different
| construction from typical low frequency AC relays. Wipers
| are often high quality metallurgy to extend life and they
| make use of simple passive magnetic snubbers to 'blow
| out' the arc that is self-extinguishing in AC circuits.
| They aren't substantially more expensive than regular
| high quality AC relays and use standard form factors.
| OliverJones wrote:
| Vehicle electronics have some real environmental challenges as
| well.
|
| They have to function correctly * after they've
| been parked outdoors in Death Valley all day. * after
| they've been parked at -40 degrees for a long time. *
| when doused with slush containing road salt. * when
| their wiring harnesses deteriorate after a couple of decades of
| hard use. * at least for a few seconds after a
| catastrophic crash.
|
| It takes the kind of risk-taking guts that Tesla exhibits to push
| new, better, electronic parts into test and production. Most car
| companies' executives, designers, and test engineers just don't
| want to take those risks.
| cma wrote:
| > risk-taking guts that Tesla exhibits to push new, better,
| electronic parts into test and production.
|
| After their delaminationg non-automotive grade screens I'd be
| wary.
|
| Their solution to it was to make the air conditioner always run
| in the sun when parked and promote it as a feature, wasting
| untold megawatt hours of electricity.
| Ekaros wrote:
| That sounds like possible death trap. Drive Tesla to some
| place without range, stay out there for week. Then come back
| an notice car is dead and you can't reach next charging
| station.
|
| Maybe this is why Musk is making Starlink...
| useful wrote:
| you can tow charge an electric car with another car or
| truck
| Ekaros wrote:
| How do you order an other car or a truck if you can't
| make phone calls?
| burntwater wrote:
| I looked into this a few weeks ago while exploring
| purchasing an electric car, and from what I could find
| "tow charging" was experimented with but has basically
| been given up on. The expectation is that if you lose
| power, you will need a flatbed truck to cart the car to a
| charging station.
| rampant_ai wrote:
| Charging efficiency isn't 100%, so you'd have to tow it
| further than the range you need. Seems like it'd make
| more sense to just tow it to a charger.
| tantony wrote:
| > Charging efficiency isn't 100%, so you'd have to tow it
| further than the range you need
|
| That's not how it works. You basically get 5 mpg or less
| on the truck, while the car charges at significantly
| higher rates than the speed of the truck (in mph),
| because the car is more efficient at using the energy.
|
| https://insideevs.com/news/514727/tesla-towing-70mph-
| fast-ch...
|
| Towing at 70mph in the above example was charging the car
| at 65 kW. That's equivalent to ~260-270 mi/hr of charging
| rate assuming 250Wh/mi.
| seabrookmx wrote:
| The comment you replied to is still correct though.
|
| Distance wise, tow charging makes no sense. Energy wise,
| maybe it does.
| phkahler wrote:
| Give me a microcontroller with between 32K and 2MB of onboard
| flash, some eeprom, multiple CAN peripherals, ADC, SPI, good
| timers, and some specialized peripherals - synched PWMs with dead
| time for driving power electronics, and some other special
| things. Dual-core lockstep for safety critical things (like the
| fronk latch). Some combination of all that at a price starting
| under a dollar.
|
| Oh, and a temperature range of -40 to +125C ambient.
|
| Can Intel do that on their obsolete 16nm multipatterning process
| for anywhere near the price target? Didnt think so.
| YetAnotherNick wrote:
| ESP32 satisfies each of your requirement. They are available
| for $1(without BT sensor) in bulk pricing, have 4MB flash, have
| eeprom, have CAN, ADC, SPI, goof timers, good PWM, good DAC, is
| realtime, dualcore, and ambient temperature range of -40 to
| +125 C.
| dvh wrote:
| Aren't all esp32 out of stock on digikey?
| phkahler wrote:
| ESP is close. I was poking at Intel claiming they could help
| when they dont have anything close and wouldn't want to for
| the price.
| kazinator wrote:
| Any discussion about why you can't transition to newer chips that
| doesn't mention the software is incomplete.
|
| Chips are not fungible in part because of software compatibility.
|
| OK, so you got a newer chip, and have redesigned the board and
| everything to fit. Now you have to get all the old firmware
| running on it and validate it.
|
| If the new chip isn't a 100% backwards compatible version of the
| old one, including all the peripherals, that could be a
| considerable effort, fraught with risk.
| VLM wrote:
| In the long run we'll only use FPGAs and soft cores.
|
| In 2050 if your old 2035 Ford needs a new ECU you'll just stuck
| a somewhat newer and larger FPGA on it, and if the 2035 ECU
| needs three hardware I2C bus with clock stretching, one of
| which bus has to do 10 bit I2C addrs and it also needs three
| hardware PWM pins with 11 bit resolution and two 8051 cores
| running at 5.25 MHz each and two CANBUS, you (or more likely
| Ford) will just compile the brand new FPGA to have exactly and
| precisely all that stuff and it'll work fine.
| noir_lord wrote:
| I think you are probably right, economies of scale mean that
| using a ridiculously powerful modern process to emulate an
| old processor often makes sense.
|
| The C64 mini runs a modern(ish) arm processor and an emulator
| to pretend to be a C64 - that's a machine that is literal
| multiple orders of magnitude more powerful than the original
| system.
| etaioinshrdlu wrote:
| Can we manufacture designs for larger/older process nodes on
| newer ones? I understand it's a little bit like the DPI on a
| printer. I imagine there are many other changes, and expense, but
| would it work?
| IshKebab wrote:
| Why can't they just make pin-compatible versions of the chips
| using new processes? That would take time, but surely easier than
| investing in new fabs for old processes?
| uvesten wrote:
| I did a short stint in the automotive industry ~10 yrs ago (on
| the software/safety side) at one of GM's brands. The lack of
| forward-thinking was absolutely horrible, as was the constant
| insistence that anything new would never work (you remember the
| constant doomsaying about tesla?). I got out as fast as I could,
| I seriously think that being in that environment might cause
| serious mental impairment... So, not in the least bit surprised
| about this. Just nice to hear that the world is moving on whether
| the big auto brands wants it to or not.
___________________________________________________________________
(page generated 2021-10-02 23:01 UTC)