Skip to content
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

Open
uhi22 opened this issue Oct 20, 2023 · 5 comments
Open

Safety improvements: Periodically check the fix parameters #37

uhi22 opened this issue Oct 20, 2023 · 5 comments
Labels
safety Enhancement for operational safety

Comments

@uhi22
Copy link

uhi22 commented Oct 20, 2023

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.

@jsphuebner
Copy link
Owner

jsphuebner commented Oct 23, 2023

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.

@jsphuebner jsphuebner added the safety Enhancement for operational safety label Oct 23, 2023
@uhi22
Copy link
Author

uhi22 commented Oct 23, 2023

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.

@jsphuebner
Copy link
Owner

jsphuebner commented Oct 24, 2023

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.
EDIT: now I understand. Calls to Param::Change() during off phase add to the exception list, while calls to Param::Change() during Run mode do not.

@uhi22
Copy link
Author

uhi22 commented Oct 24, 2023

We should define the terms, to avoid confusion.

  1. When I say "fix parameter", I mean the parameter which never change in car life. More precise, they change during the Initial bringup, and afterwards are frozen. I think there need to be a clear criteria to distinguish between the bringup and the road use.
  2. What is Off Phase and what is run mode? When is the transition from the one to the other?

@jsphuebner
Copy link
Owner

jsphuebner commented Oct 24, 2023

Yes

  1. ok, so there could either be a static or a dynamic whitelist. Dynamic as described above
  2. Off-Mode is opmode==0==Off, Run-Mode is opmode==1==Run
    The inverter always starts in off mode and transitions to Run mode when various criteria is met, e.g. precharge target hit and user sends start signal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
safety Enhancement for operational safety
Projects
None yet
Development

No branches or pull requests

2 participants