(I've waited a while until I had the time to go look everything up properly before replying to this thread.)
I would summarize the kill switch safety concern as a lack of fail-safe consideration in the design.
Fail-safe principle:
https://en.wikipedia.org/wiki/Fail-safeAny safety mechanism should have fail-safe considerations built in.
For example, the Sevcon Gen4 controllers have switch concepts built in like FS1, deadman, and seat switches.
- FS1 locks out the throttle, and helps implement an interlock when switching between forward and reverse modes.
- A deadman switch to lock out drive mode and engages a brake (which they recommend against for highway vehicles).
- A seat switch can also lock out drive mode / throttle operation.
- Wire-off detection for the throttle which the 2015+ Bitron throttle probably supports more directly than the older
According to
https://en.wikipedia.org/wiki/CAN_bus, CAN is a serial "multi-master bus", meaning that more than one node must initiate a transfer.
The choice to route the kill switch (and the kickstand switch to a lesser extent) through the MBB means that an MBB deadlock or livelock prevents activation of the interlock.
- The design flaw is in requiring an active element of forwarding a signal from the MBB to the controller.
- The cutout switch should just have been a digital signal to the controller; I can't think of a critical reason for the MBB to be directly in the loop.
- One could argue why not make it sort of a DPDT switch to send signals to both at once in case the MBB needed to react as quickly as the controller, but that does introduce another unnecessary point of failure.
- I'm guessing that Zero engineers felt that the Sevcon couldn't manage the shutdown itself for some reason (where the MBB would have been notified by the controller of the event secondhand).
- Maybe there was a decision based on information we don't have (technical or political), but no real answer is going to be satisfactory.
Now, this is relevant to anything we discuss doing on our Zero's systems!
- As is now clear, downloading logs in drive mode is a heavy batch operation and we can easily advise against this.
- However, the category of live telemetry operations by calling the MBB directly is inherently risky (and I've heard hints about that as a direct experience).
- Complicating matters, we can't test this without putting the bike on a (dyno?) stand and trying polling rates and backoff strategies while trying to operate the bike at various RPMs.
In short, live telemetry will require a careful mix of tuning polling rates against the data volume requested; so more signal values will require a lower polling rate. And it's likely that one would want to batch the requests or something and only let one telemetry app operate at a time (as in: don't run the OEM app concurrently with any other telemetry app).
It just occurred to me that perhaps the instrument cluster only gets sent messages for values it's configured to display. So, it's hypothetically testable that one could reduce the load on the MBB for another telemetry app by selecting values to display on the dash that are configured to update less often. Maybe.
It's rumored that 2017+ model years' MBBs are more robust (with faster CPUs and larger RAM capacities), but running out of buffer or I/O dispatch capacity or such on a small board could still happen. Also, I'm gathering that every year's MBBs have different physical connectors which precludes any reasonable retrofitting for older models.
I have no answers to this, but it seems responsible to spell out the implications. I've updated the MBB section a bit for this:
https://zeromanual.com/index.php/Unofficial_Service_Manual#Main_Bike_Board
Author
Topic: canbus (technical) (Read 3279 times)