e-throttle support #457
Comments
|
It's come up a lot of times in the past but there has been much resistance because of the safety aspect of it. I'm not convinced that a vehicle with brakes (which I'd think was a vast majority) has much of an issue here, but it could be a thing. Having had sticking throttle cables in the past (at WOT) I don't think a malfunctioning throttle is anything exclusive to e-throttles. |
|
The danger is real. Especially for those who have mighty engine and automatic tranny. But ability to drive an e-throttle is a valuable bit for customizable ECU. |
|
I have to say I've only had one car that's an auto, but I seem to recall it had neutral? |
|
Correct. |
|
Implementing it is easy. Implementing it so that the safety issue is managed is something altogether different.
To mitigate the safety issues you would ideally need to undertake an FMEA and ensure that the code was based on the results.
/DM
… On 22 Sep 2020, at 6:18 am, XPbIM3 ***@***.***> wrote:
Correct.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#457 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXF35XUMKM2JSTJS2RKLHLSG63YJANCNFSM4RTZWCAQ>.
|
|
I think it is important to support electronic throttles. In my opinion it is much safer for the throttle to be controlled by the speeduino firmware as it is extensively tested and audited unlike something you hack together on a weekend with only your own limited testing. This would also open up compatibility with some engines that use don't use an idle bypass valve but rather just control the main throttle(for example 1ZZ in 04-08 corolla verso). You as the driver should have the ability to shut down the engine/decouple it from the rest of the drivetrain regardless of the ECUs state, especially when doing extensive modifications(like replacing the entire ECU). |
|
For safety purposes we can implement some stuff like:
E-throttle control alongside with ignition cutoff can became a rev-matching for gear-switching. |
|
Josh has already said he doesn't want to implement this because of the
safety drama.
I'm not sure if this means if he doesn't want to do it or if he is actively
against speedy being able to do it.
There are aftermarket controllers. I think one of the speedy retailers
actually have a kitset available.
Anyway, in a factory car there are multiple levels of systems in place in
software (and I assume a bunch of stuff in hardware on the ECU but its hard
to know).
The biggest thing is there is an H-bridge driver and a relay. If the driver
was to fail and come away from target for a small amount of time then the
relay will turn off and it will go into limp home mode (where the
throttle from there on out does not get driven and you only have the 10% or
whatever that it comes with.
I also don't think all the code will fit in an Mega.
I think there should at least be a completely standalone watchdog that can
switch the relay off
…On Wed, Sep 23, 2020 at 1:44 AM XPbIM3 ***@***.***> wrote:
For safety purposes we can implement some stuff like:
- having more than 10% deviation between TPS and PPS on non-idle for
more like 3s - shutdown e-throttle control
This can be a part of Engine Protection System maybe?
E-throttle control alongside with ignition cutoff can became a
rev-matching for gear-switching.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#457 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWB4PEYDQAEWWRCMUJAJQDSHCS27ANCNFSM4RTZWCAQ>
.
|
|
I started to write a reply before, but then decided I was waffling so didn't post it (it was late last night). The safety stuff is not trivial. Here's the reply I was going to send before. It will give you some idea of what's involved
This is why an FMEA analysis is critical. 'Stuff and maybes' are far too wooly and ambiguous to base control of safety critical devices on.
Essentially the FMEA process breaks the entire system up end to end and analyses each section against a set of failure modes - open circuit / short circuit / loss of control / unexpected control / false positive / false negative / over temp / under temp / over pressure / under pressure / etc / etc. You get the idea.
The failure modes can either be determined to suit the system being analysed or a standard set of failure modes adopted. You may also end up with two sets - one for the physical system and one for the software. Both need to be considered.
Therein also lies a potential minefield - how can you analyse physical systems when you don't even know what they might be? You may think that the physical installation falls into the domain of the end user and is not the responsibility of the software provider. This is not true at all, as ALL potential issues need to be considered 'as far as is reasonably practicable'.
So what is 'reasonably practicable'? (it's legal term BTW) That question has a completely different answer depending on when and where you ask it. When you're sitting up at 2am necking coffees writing code, you're going to think you've done all that is reasonably practicable. But when Johhny's moms expensive lawyer is pulling you apart in the dock because Johnnys mom wants someone to pay for the loss of little Johnny, you're going to wish you had done an FMEA because it's the standard analysis to do for a system like this. It is legally accepted as being as far as is reasonably practicable. It's what the OEMs do.
So this all sounds very scary and I suspect is the reason that it's not been included so far, but the FMEA process is more of a laborious one than a difficult one. Plan the process, execute it with a facilitator and a good cross-section of different skills. (this is not something that you do on your own) that span all relevant disciplines (software / electrical / automotive design / legal / etc). Then formally document the process, analyse the outcomes and discuss mitigation measures (you can also do this as you go along). What you will end up with is a list of design constraints that will drive the how the code is written and how the system is design.
For example a typical failure mode might be - loss of control of the reference signal between Speeduino to throttle controller - the outcome is that throttle controller is uncontrolled - mitigation measure may be that a watchdog signal is required, or that there is redundancy implemented i.e. two control wires that each operate independently but in sync with each other, or that the throttle controller automatically closes at a safe rate to allow the driver to bring the car to a controlled stop. Whatever the agreed control measure, that's what is implemented. This particular failure mode would also be very similar to an open circuit of that wire. In many cases the outcomes and mitigation measures are repeated many times.
Each risk will also be ranked in order of magnitude. Those risks that exceed a predetermined score or 'acceptable risk level' may need to have more than one control measure, so that it requires a failure of both controls before a critical failure occurs. Essentially to bring the score back to an acceptable level. This is how safety systems are constructed, not by simply guessing what might be a good control. There is no room for error. EVERYTHING needs to be considered - that's every possible situation - 'as far as is reasonably practicable'
Then once the code has been written you need to undertake testing to ensure that each of the identified risks has been suitably controlled. i.e. you physically test the open circuit and measure and document the results. Each individual control measure will need to be validated to ensure that they comply with the FMEA requirements. This may also require specific tests to be developed to test outcomes in real conditions.
Next, you need to consider what happens when you modify the code? Do you repeat the entire process again? Ideally yes, because as soon you change one small aspect of the system, it's no longer the same system. Be prepared to undergo a review process each time you make a modification to the system. This review will essentially go through the same process to validate the changes made.
With a continually developing system that has regular public releases this can soon end up being very tedious. it is much better to package up the controller as a black-box type solution that is never modified, where you only go through this process once to assess it for public release. This could be achieved using 'locked' code, which is how things like safety PLCs manage safety critical systems. The code is actually password protected to prevent future modification. It could probably be done with a checksum of some kind.
Overall it's a bit of a quagmire, both from a development and legal perspective, especially as Speeduino is used in many jurisdictions. So I can understand any reluctance to implement it.
/DM
… On 23 Sep 2020, at 3:39 pm, dascons ***@***.***> wrote:
Josh has already said he doesn't want to implement this because of the
safety drama.
I'm not sure if this means if he doesn't want to do it or if he is actively
against speedy being able to do it.
There are aftermarket controllers. I think one of the speedy retailers
actually have a kitset available.
Anyway, in a factory car there are multiple levels of systems in place in
software (and I assume a bunch of stuff in hardware on the ECU but its hard
to know).
The biggest thing is there is an H-bridge driver and a relay. If the driver
was to fail and come away from target for a small amount of time then the
relay will turn off and it will go into limp home mode (where the
throttle from there on out does not get driven and you only have the 10% or
whatever that it comes with.
I also don't think all the code will fit in an Mega.
I think there should at least be a completely standalone watchdog that can
switch the relay off
On Wed, Sep 23, 2020 at 1:44 AM XPbIM3 ***@***.***> wrote:
> For safety purposes we can implement some stuff like:
>
> - having more than 10% deviation between TPS and PPS on non-idle for
> more like 3s - shutdown e-throttle control
> This can be a part of Engine Protection System maybe?
>
> E-throttle control alongside with ignition cutoff can became a
> rev-matching for gear-switching.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#457 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACWB4PEYDQAEWWRCMUJAJQDSHCS27ANCNFSM4RTZWCAQ>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#457 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXF35QWTXJPYJ56HZHAXRLSHGGKDANCNFSM4RTZWCAQ>.
|
|
@dascons
If that's the case, maybe that module could be incorporated into the main pcb?
And if a feature that could potentially be seen as 'very dangerous when fails', it's only better if it's in such a large project where this is feasible to evaluate
Project is distributed as GPL-2.0 as far as i can tell, which strips the creator of any liability for failures/damages. |
|
"Project is distributed as GPL-2.0 as far as i can tell, which strips the creator of any liability for failures/damages."
Yes and also no. :D
The GPL does try to limit liability with its 'not fit for purpose' clause, but the thing with any law-suit is that it is a test of the law. If a case is raised, it will still be heard, and if the plaintiff can pose a strong enough case (i.e. did not exercise duty of care / unqualified to perform work / non-conforming / non-compliant / etc / etc) then they may well win. I've sat on jury service a number of times and TBH the way things are conducted in court is scary. it comes down to who has the best lawyer and that's it. Actual guilt seems to be largely irrelevant. Remember also this would likely be a civil damages case not a prosecution for manslaughter. Could you afford to go through a court case? Even if you came out the other side and won, it would have still taken up several years of your life and a bunch of your own money.
Of course this is all simply speculation and using extreme cases as examples, but when you want to protect yourself from such liabilities, then the simple solution is not to put yourself in the firing line in the first place.
It's an interesting topic for sure.
/DM
… On 23 Sep 2020, at 11:02 pm, digmorepaka ***@***.***> wrote:
@dascons <https://github.com/dascons>
There are aftermarket controllers. I think one of the speedy retailers
actually have a kitset available.
If that's the case, maybe that module could be incorporated into the main pcb?
@DeeEmm <https://github.com/DeeEmm>
FMEA analysis is critical
And if a feature that could potentially be seen as 'very dangerous when fails', it's only better if it's in such a large project where this is feasible to evaluate
But when Johhny's moms expensive lawyer is pulling you apart in the dock because Johnnys mom wants someone to pay for the loss of little Johnny
Project is distributed as GPL-2.0 as far as i can tell, which strips the creator of any liability for failures/damages.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#457 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXF35S4GE66Y54VRPDUAPDSHH2FDANCNFSM4RTZWCAQ>.
|
|
2019_ETC_FMEA_Template_(1).xlsx Maybe start here, fill this out and something could eventually start getting its bearings! |
|
Hi all, I've only just come across this project, but I've worked in automotive engine and transmission controls R&D for a good while and I wondered if some comments on this might be useful. The (D)FMEA is the right approach. What this would tell you is that you can easily detect sensor, actuator and wiring faults and create a safe reaction. A correctly configured MCU watchdog will protect for any processor hang/crash since a watchdog reset will switch off the external relay controlling 12v actuator supply. The remaining risk (which is very very unlikely) is that you get a hardware fault in the PWM driver module within the MCU or the actuator driver (can be an h-bridge, but since an intake throttle will be sprung closed it can just be a low-side or high-side driver), the worst case being a short to 12v (i.e., throttle stuck fully open). This can be monitored by measuring the output voltage of the h-bridge using an MCU ADC channel and comparing vs expected. The way the most recent OEM controllers handle this is to have a microcontroller that runs in lockstep - 2 cores running the exact same code in parallel and any variation monitored for (e.g., Bosch MED17 uses Infineon Tricore). The way I would handle this with something like Speeduino is to have an external supervisor monitoring the MCU and controlling the actuator supply relay. The MCU would generate an output square wave when it was running which the supervisor would monitor. If the signal stopped, the actuator supply would be switched off. I would generate the rising and falling edges of this signal inside the throttle position and actuator drive output functions (respectively) themselves. This way, if either didn't run for whatever reason, the throttle would be closed. The actuator supply enable outputs from the MCU and the supervisor would be run through an AND gate into the actuator supply relay so that both had to be happy (and working correctly) for the throttle to be driven. This above solution would go a long way to mitigating the biggest risk of implementing e-throttle into Speeduino - that of you using someone else's code base. Whatever the solution, extra testing would be required to ensure each code release worked safely under each of the failure cases from the (D)FMEA. This would need to be done by running the code on the target hardware rather than just abstract unit-testing. You would need test scripts to flash and run test cases on ECU hardware with a throttle body connected. Dedicated HiL rigs are used for this in a commercial setting, but the same could be achieved by extending the functionality of Ardustim a little. This is probably the biggest drawback of implementing e-throttle on Speeduino, since it is quite a bit of extra work. Finally, in case it's useful, OEM ECUs have the following diagnostic checks for e-throttle sensor, wiring and actuator faults:
All the above checks can be run through a leaky bucket or other type of filter so they don't react inappropriately to any incorrect readings caused by interference or otherwise. You also need to detect and adapt the fully open and fully closed positions of the throttle plate. The fully closed position is the critical one since it usually controls idle which is very sensitive to throttle position. This end-stop learning as it's called, usually happens after key-off and engine stop. You might hear it on your cars as the throttle cycles between fully-open and fully-closed positions a few times and the resulting voltages stored in NVRAM to be used on next engine start as the ends of the sensor range. The final things will be a pedal maps to calibrate throttle response. This is usually 1 2D map for each gear with X and Y scales as engine speed and pedal position. The values in the map will be load or torque depending on the chosen control quantity. You will also need a function to control the transition between the idle speed controller having control on the throttle to the pedal having control on the throttle as the engine speed drops down to the idle speed. As you can see from the above, this is a lot of work and rather changes the scope of your project as well a introducing significant extra testing requires for each release. There are significant benefits to having e-throttle control, but it's not an easy thing to implement. This might well explain any reluctance to go down this route. |
|
So why do aftermarket ecu manufacturers like haltech and others have the ability and let users decide whether they want to use electronic throttle bodies or not? Certainly there just has to be some form of liability recognition on behalf of the programmer/tuner when choosing to go this route! |
|
Cos they'll have implemented everything I mentioned above and they will have designed their hardware to be suitable from the start. This isn't taking anything away from the efforts here and other open-source controllers, but e-throttle (as well as others like cruise control and traction control) is a higher level of risk and development/testing effort. Commercial stuff has to meet safety standards regardless of waivers, etc. Plus, even then any failures could still be very bad for brand reputations. You still have options for your Honda. You can get standalone e-throttle controllers that you could use with speeduino. There are quite a few options, but this look like it could be a good pairing - https://lowcostracingsolutions.co.uk/fly-by-wire-controller/52-electronic-throttle-etc-fly-by-wiredrive-by-wire-standalone-controller.html |
|
Thanks eddnshoulders. I will look into the stand alone controllers as you suggest. |
|
https://speeduino.com/forum/viewtopic.php?f=15&t=4952&p=54505 Here's a good stop-gap solution as a separate module, sadly no cruise control or traction aids but that could be augmented with some extra work. |
|
I can also agree that TBW is needed to be added in the future sooner rather than later. |
|
Safety drama is IMO a hoax. |
I've been thinking for a while about e-throttle support.
Seems we have everything ready for that:
1)throttle body TPS sensor reading - already done.
2)Pedal sensor - easily doable - speeduino is capable of handling additional analog sensor
3)Two pwm outputs to control two FETs in full-H bridge. - already have idle1 and idle2 pins, both pwm controlled.
and code part required:
4)An algorithm logic: the simplest algorithm is: when accelerator pedal is operated by foot the TPS must follow pedal sensor position closely , so there is DELTA calculated between two sensor positions. And this delta mapped to PWM signal of two wires controling the H bridge for throttle blade motor. If DELTA is positive - the open FET is operated via pwm, if negative - close FET operated via PWM. When pedal is not pressed and idle conditions are meet the switchover to rpm maintainig algorithm is performed - simply the rpm as a target over coolant temp - as it already present in speeduino.
also a calibration routine should be present - pull throttle blade full open and full close - and flash those values in eeprom.
This would be very usefull on semi-electronic throttle engines like mercedes M111, several 1JZs and some others.
The text was updated successfully, but these errors were encountered: