Re: CAN bus support

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).

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".

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