Re: CAN bus support

Hi. Commenting partially.

On Sun, 10 Nov 2024 12:57:13 +0100
Alexander Leidinger <Alexander@Leidinger.net> wrote:

> Am 2024-11-09 23:14, schrieb Kevin Bowling:
> > On Sat, Nov 9, 2024 at 3:06 PM Colin Percival <cperciva@tarsnap.com> 
> > wrote:
> >> 
> >> On 11/9/24 13:57, Kevin Bowling wrote:
> >> > A FreeBSD vendor is interested in interacting with CAN bus on FreeBSD.
> >> > [...]
> >> > Is there other interest or concern about the topic?
> >> 
> >> As release engineer, I'm interested in hearing more (perhaps off-list)
> >> about what they're doing, since the time scales for most devices which
> >> use a CAN bus are significantly longer than the time scales for 
> >> FreeBSD
> >> releases.
> > 
> > It is an amd64 appliance with a bus attached controller and not a
> > special SoC so it probably shouldn't be impactful to arch support
> > expectations.
> > 
> >> No obligation of course, and they're free to do whatever works for 
> >> them;
> >> this is purely a case of "knowing more about how FreeBSD is being used
> >> might help us support said uses better".
> > 
> > I'll find out some more information and see what is appropriate from
> > their perspective to share.
> 
> Not related to this, but based upon this thread I had a quick discussion 
> with someone who worked on an automotive headunit and some other stuff:
> 
> Currently a lot of the stuff which needs CAN bus support is either a 
> critical system (some sort of ECU, signal processing from sensors, ... 
> everything which influences the direct safety of a vehicle) which runs 
> on QNX and needs at least soft-realtime if not hard-realtime support, or 
> some kind of headunit where the industry has moved or is moving to 
> Android (more easy to integrate the app support and better support from 
> 3rd party vendors like Spotify and co), or a telemetry / gateway system 
> (no real-time requirements, but efficiency requirements, so we could be 
> a good fit), or some testing system in a lab (would also be an easy fit 
> for us).
> 
> The industry seems to be willing to move away form QNX, or at least 
> would like to have options. There was some interest to get Linux 
> certified into this area, but at least a while ago this wasn't feasible 
> (I did not get info about specifics).

(Micro)ITRON, the smallest variant of TRON project, can be an option,
and at least, Toyota uses it for ECU.

 https://en.wikipedia.org/wiki/ITRON_project


> So theoretically speaking, if a 3rd party wants to sell a test system to 
> a car manufacturer without releasing their code, we may be interesting, 
> and it may not need as much of a support timefame from us (if done right 
> on the vendor side). If a car vendor wants to build a test system for 
> their lab, they most probably stick with Linux (automotive linux has a 
> lot of stuff to offer and has support from big volume brands).
> 
> If the issues with the certification of Linux instead of QNX are in 
> areas which are more easily handled with our code, we may run into the 
> area where some kind of looong term support may be needed, but this 
> looks to me either like a case similar to Sony / Playstation or would 
> have as a pre-req some code drop to us in the sense of some kind of 
> "automotive FreeBSD".

Or FreeBSD as a process on RTOS.
IIRC, there were some Linux implementations (not a full distro) running
as such for mainly (G)UI. Critical things runs directly on the RTOS.


> The telemetry/gateway area seems to be an easy target to use FreeBSD 
> too, not as strict in the requirements as the critical stuff.
> 
> All of this is not only about the code, but also about legal stuff. Car 
> homologation in general is a big topic and the cost of it is not 
> negligible 
> (https://www.tuvsud.com/en/industries/mobility-and-automotive/automotive-and-oem/homologation-and-global-market-access).
> 
> The digital security by design Jessica mentioned together with CheriBSD 
> may also be some interesting aspect, but I'm not sure how much the 
> industry is willing to invest into this ATM (your speedometer and your 
> car keys are still not that hard to manipulate than they could be, there 
> are still to many keyless entry systems which aren't secure enough, and 
> more or less you can not be really sure about the mileage of any car in 
> the market).
> 
> Bye,
> Alexander.
> 
> -- 
> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>