3 ms·

> That will require a major overhaul of technologies like the above-mentioned CAN-bus that is four decades old and employed in every car (including, believe it

by LeonM 6y ago

> That will require a major overhaul of technologies like the above-mentioned CAN-bus that is four decades old and employed in every car (including, believe it or not, in a Tesla). I don't understand why the author keeps banging on about CAN bus being an old standard. So what? CAN bus is used in the automotive industry because of it reliability and low wire count. Why should it be changed?

upofadown 6y ago
I also got the sense that the author didn't know exactly what CAN bus was and how it is used.
throw0101a 6y ago
> CAN bus is used in the automotive industry because of it reliability and low wire count. Why should it be changed? I don't know this space, but depending it may be there are more messages going to and fro, and so perhaps more bandwidth is desired? IEEE 1394 ("FireWire") seems to have a bunch of 'industrial' uses: * https://en.wikipedia.org/wiki/IEEE_1394#Common_applications https://en.wikipedia.org/wiki/IEEE_1394#Common_applications The marine folks went from a CAN-like NMEA 0183, to a more bus-like NMEA 2000, and are not looking at an Ethernet-based system: * https://en.wikipedia.org/wiki/NMEA_2000 https://en.wikipedia.org/wiki/NMEA_2000 * https://en.wikipedia.org/wiki/NMEA_OneNet https://en.wikipedia.org/wiki/NMEA_OneNet If all you're doing is getting sensor values at a few Hertz, then CANbus is probably fine, but if you need to distribute the images of a read-view camera, a bunch sonars, a bunch of radars, etc, then the 500 kbit/s in J1939/14 may not be enough. Even the 'CAN folks' recognize this: * https://en.wikipedia.org/wiki/CAN_FD https://en.wikipedia.org/wiki/CAN_FD * https://en.wikipedia.org/wiki/CANopen https://en.wikipedia.org/wiki/CANopen
drcross 6y ago
I always downgrade people in my estimations when I see they correlate old with being bad without a good reason.
- pandler 6y ago
  I agree, but I try to stick to downgrading the comment/argument instead of the people themselves, because I’ve found it to be a pretty ubiquitous line of thought since I started noticing it.
  - m463 6y ago
    I was listening to an episode of Joe Rogan, and the guest considered himself a conservative. Discussing the differences between a conservative and a liberal he used an analogy of a fence, where a liberal would want to take it down and a conservative would want to leave it up. It got me thinking if this was true or not. A little digging and I found this page: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence "Although the purpose of this fence is not obvious, there may be valid reasons for its presence." (I'd like to think I'm in the mindful middle somewhere)
- mhh__ 6y ago
  Sure it's tried and tested and fit for purpose, but at what cost?
mc32 6y ago
Also makes it easier for a mechanic to trace and fix issues. Imagine something more complicated where you need specialized knowledge to troubleshoot things. It’s like they want to complicate things so the average person can’t fix things themselves. They look at John Deere not in askance but in admiration for making things irreparable by ordinary folks.
dbcurtis 6y ago
CAN is great for real time control, and a huge number of embedded components support it. I don’t see it going away any time soon. That said, it does not have a lot of bandwidth. There will need to be something higher bandwidth to support modern info-tainment systems. A second, high-bandwidth network with less strict real-time requirements.
- annoyingnoob 6y ago
  Why would you want to mix control and entertainment? I'd argue that you want control separated, for safety and security if no other reason. You don't want an app taking over your car.
- kazen44 6y ago
  what high bandwith requirements do exist for an infotainment system that you would want in a car? Navigation and playing music? Both are done by other systems as CAN already.
  - mrwesleycrusher 6y ago
    I mean, if you just cant stream video over CAN, but for infotainment MOST is fine. But you need something faster and better for your surround cameras (even if its just to stream to the driver for parking assistance)
  - qznc 6y ago
    Cars are getting more sensors (radar, video, lidar, ultrasonic) and increasingly fuse the information. I guess the future here is a hybrid though. "Big" data via Ethernet and status via CAN.
kumarvvr 6y ago
Yup. I don't get why people love to berate older tech. I mean, HTTP is quite old. and CAN is a solid piece of tech. Ultra reliable, fast and low wire count. It's controllers are cheap and reliable.
- derefr 6y ago
  HTTP1.0 is old. But we're nearing HTTP3.0 now. Not that HTTP1.0 has gone away, nor would it need to; but for the devices that need the features it offers, the newer versions are better. I think the author is pointing at that concept, with the idea that CAN hasn't evolved over time in the same way as HTTP. Ideally there'd be a CAN2.0 for the cars that want it, that's backwards-compatible with CAN1.0 readers/etc.
  - throw0101a 6y ago
    > I think the author is pointing at that concept, with the idea that CAN hasn't evolved over time in the same way as HTTP. If he works in this space, I would think he'd know that there are new things being worked on: * https://en.wikipedia.org/wiki/CAN_FD https://en.wikipedia.org/wiki/CAN_FD * https://en.wikipedia.org/wiki/FlexRay https://en.wikipedia.org/wiki/FlexRay Not that these seem to work differently at the OSI Layer 1/2 layer, so while older messages can be sent over the newer transport, it is not wire compatible.
    - derefr 6y ago
      Right, you'd likely have to connect your old CAN-bus reader to the new system through an active PHY-to-PHY adapter dongle, sort of like a VGA-to-HDMI adapter, or (presumably, once it happens) a MIDI1.0 to MIDI2.0 adapter. As long as the new version of the protocol is still formatted on the higher OSI layers in terms of reusing the core messages from the old version, and then adding new messages that are optional to the understanding of what's going on from a CAN1.0 perspective, then a change in the PHY layer still isn't really throwing the baby out with the bath-water.
na85 6y ago
>Why should it be changed? The cynic in me believes that Apple is so bought-in to its own hype that they have a need to change it for change's sake alone. Just like their pathological desire for thinner laptops with no practical benefit, they'll rail on about how this unnecessary churn is progress. I think the Apple Car will be a buggy, unreliable, unrepairable mess that the buyers won't ever truly own.
mrwesleycrusher 6y ago
Because Flex Ray is better for real time systems and has been around over 10 years. Don't get me wrong, CAN and LIN have their place but CAN has a lot of jitter, especially in a car when you can kinda guess how often an ECU is going to spit out messages to the other ones. The only thing you lose with FlexRay is now your controllers have to speak flexray, which is a more complex standard.
- zbrozek 6y ago
  I would never voluntarily design Flexray into anything. It's not especially fast, it's conceptually convoluted, the resulting bus is brittle, and there's very few choices for silicon. I spent a flight to Germany reading a book about the bus (I was working on a project that needed to interface with it). Traditionalists like to point to its latency guarantees, but you can do just as well with a thoughtful Ethernet implementation. And there are single pair PHYs. Others argue in favor of the multidrop topology, but I see it as a common failure point. Plus it erodes the utility of the bandwidth. For multiple drops I like CAN a lot better.
- deleted 6y ago
  [deleted]

by LeonM 6y ago

upofadown 6y ago

I also got the sense that the author didn't know exactly what CAN bus was and how it is used.

throw0101a 6y ago

> CAN bus is used in the automotive industry because of it reliability and low wire count. Why should it be changed? I don't know this space, but depending it may be there are more messages going to and fro, and so perhaps more bandwidth is desired? IEEE 1394 ("FireWire") seems to have a bunch of 'industrial' uses: * https://en.wikipedia.org/wiki/IEEE_1394#Common_applications https://en.wikipedia.org/wiki/IEEE_1394#Common_applications The marine folks went from a CAN-like NMEA 0183, to a more bus-like NMEA 2000, and are not looking at an Ethernet-based system: * https://en.wikipedia.org/wiki/NMEA_2000 https://en.wikipedia.org/wiki/NMEA_2000 * https://en.wikipedia.org/wiki/NMEA_OneNet https://en.wikipedia.org/wiki/NMEA_OneNet If all you're doing is getting sensor values at a few Hertz, then CANbus is probably fine, but if you need to distribute the images of a read-view camera, a bunch sonars, a bunch of radars, etc, then the 500 kbit/s in J1939/14 may not be enough. Even the 'CAN folks' recognize this: * https://en.wikipedia.org/wiki/CAN_FD https://en.wikipedia.org/wiki/CAN_FD * https://en.wikipedia.org/wiki/CANopen https://en.wikipedia.org/wiki/CANopen

drcross 6y ago

I always downgrade people in my estimations when I see they correlate old with being bad without a good reason.

pandler 6y ago
I agree, but I try to stick to downgrading the comment/argument instead of the people themselves, because I’ve found it to be a pretty ubiquitous line of thought since I started noticing it.
- m463 6y ago
  I was listening to an episode of Joe Rogan, and the guest considered himself a conservative. Discussing the differences between a conservative and a liberal he used an analogy of a fence, where a liberal would want to take it down and a conservative would want to leave it up. It got me thinking if this was true or not. A little digging and I found this page: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence "Although the purpose of this fence is not obvious, there may be valid reasons for its presence." (I'd like to think I'm in the mindful middle somewhere)
mhh__ 6y ago
Sure it's tried and tested and fit for purpose, but at what cost?

mc32 6y ago

Also makes it easier for a mechanic to trace and fix issues. Imagine something more complicated where you need specialized knowledge to troubleshoot things. It’s like they want to complicate things so the average person can’t fix things themselves. They look at John Deere not in askance but in admiration for making things irreparable by ordinary folks.

dbcurtis 6y ago

CAN is great for real time control, and a huge number of embedded components support it. I don’t see it going away any time soon. That said, it does not have a lot of bandwidth. There will need to be something higher bandwidth to support modern info-tainment systems. A second, high-bandwidth network with less strict real-time requirements.

annoyingnoob 6y ago
Why would you want to mix control and entertainment? I'd argue that you want control separated, for safety and security if no other reason. You don't want an app taking over your car.
kazen44 6y ago
what high bandwith requirements do exist for an infotainment system that you would want in a car? Navigation and playing music? Both are done by other systems as CAN already.
- mrwesleycrusher 6y ago
  I mean, if you just cant stream video over CAN, but for infotainment MOST is fine. But you need something faster and better for your surround cameras (even if its just to stream to the driver for parking assistance)
- qznc 6y ago
  Cars are getting more sensors (radar, video, lidar, ultrasonic) and increasingly fuse the information. I guess the future here is a hybrid though. "Big" data via Ethernet and status via CAN.

kumarvvr 6y ago

Yup. I don't get why people love to berate older tech. I mean, HTTP is quite old. and CAN is a solid piece of tech. Ultra reliable, fast and low wire count. It's controllers are cheap and reliable.

derefr 6y ago
HTTP1.0 is old. But we're nearing HTTP3.0 now. Not that HTTP1.0 has gone away, nor would it need to; but for the devices that need the features it offers, the newer versions are better. I think the author is pointing at that concept, with the idea that CAN hasn't evolved over time in the same way as HTTP. Ideally there'd be a CAN2.0 for the cars that want it, that's backwards-compatible with CAN1.0 readers/etc.
- throw0101a 6y ago
  > I think the author is pointing at that concept, with the idea that CAN hasn't evolved over time in the same way as HTTP. If he works in this space, I would think he'd know that there are new things being worked on: * https://en.wikipedia.org/wiki/CAN_FD https://en.wikipedia.org/wiki/CAN_FD * https://en.wikipedia.org/wiki/FlexRay https://en.wikipedia.org/wiki/FlexRay Not that these seem to work differently at the OSI Layer 1/2 layer, so while older messages can be sent over the newer transport, it is not wire compatible.
  - derefr 6y ago
    Right, you'd likely have to connect your old CAN-bus reader to the new system through an active PHY-to-PHY adapter dongle, sort of like a VGA-to-HDMI adapter, or (presumably, once it happens) a MIDI1.0 to MIDI2.0 adapter. As long as the new version of the protocol is still formatted on the higher OSI layers in terms of reusing the core messages from the old version, and then adding new messages that are optional to the understanding of what's going on from a CAN1.0 perspective, then a change in the PHY layer still isn't really throwing the baby out with the bath-water.

na85 6y ago

>Why should it be changed? The cynic in me believes that Apple is so bought-in to its own hype that they have a need to change it for change's sake alone. Just like their pathological desire for thinner laptops with no practical benefit, they'll rail on about how this unnecessary churn is progress. I think the Apple Car will be a buggy, unreliable, unrepairable mess that the buyers won't ever truly own.

mrwesleycrusher 6y ago

Because Flex Ray is better for real time systems and has been around over 10 years. Don't get me wrong, CAN and LIN have their place but CAN has a lot of jitter, especially in a car when you can kinda guess how often an ECU is going to spit out messages to the other ones. The only thing you lose with FlexRay is now your controllers have to speak flexray, which is a more complex standard.

zbrozek 6y ago
I would never voluntarily design Flexray into anything. It's not especially fast, it's conceptually convoluted, the resulting bus is brittle, and there's very few choices for silicon. I spent a flight to Germany reading a book about the bus (I was working on a project that needed to interface with it). Traditionalists like to point to its latency guarantees, but you can do just as well with a thoughtful Ethernet implementation. And there are single pair PHYs. Others argue in favor of the multidrop topology, but I see it as a common failure point. Plus it erodes the utility of the bandwidth. For multiple drops I like CAN a lot better.
deleted 6y ago
[deleted]