-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safety improvements: Periodically check the fix parameters #37
Comments
We also have the parameters stored to flash, so we could simply periodically check against these. There needs to be an exception though. As soon as a parameter is mapped to the CAN bus it is intended to change at runtime. Same goes for SDO writes. Maybe this could be redefined to check against unintended parameter modification. E.g. if the Param::Change() function is called for a particular parameter we could add it to a list of user intended parameter changes and not throw the error. We wouldn't even need parametrization mode then. |
The goal should be, that at least single faults are detected. The single fault "unintended call to param::Change()" shall not hide itself from beeing detected. So, yes, comparing with flash is good, also an exception list, but no extension of the exception list during road use phase. |
What I meant to say it might be "legal" to change parameters during road use. For example I receive idcmin/idcmax from the VCU in 10ms period to reflect the BMS limits. Likewise I receive throtmin/throtmax for traction control. |
We should define the terms, to avoid confusion.
|
Yes
|
Discussed here: https://openinverter.org/forum/viewtopic.php?p=58345#p58345
Goal: The software shall detect an unintended change of a parameter. (E.g. caused by wild pointer or bit flip in RAM).
Solution idea: Create a kind of "parametrization mode", where all parameters are allowed to be changed without consequences. After this parametrization phase, turn the mode to "road use", where parameters are checked. If unintended change is detected, turn-on the MIL and enter limp-mode with reduced torque.
The unintended modification could be achieved by either a redundant storage of the relevant parameters, or via a checksum over the relevant parameters.
The text was updated successfully, but these errors were encountered: