Living in Michigan, it’s not uncommon to wake up on a cold winter morning and find that an automobile just doesn’t want to start. However, it’s relatively uncommon for this to occur right in the middle of summer! As you can guess, the car wouldn’t start this morning and I had no idea that it was going to lead me to an interesting corner case that made me wonder “Is this a bug or a feature?”.
As it turned out, a little investigation led me to discover that the 2014 Honda Odyssey’s battery needed to be changed. It was still sporting the original manufacturers battery after 7 years and 100k miles, so it was long overdue. After picking up a new battery, I left my driver side sliding door open, just in case I needed to get in while the battery was pulled. (Everything on these vehicles is electronic these days and doors are no exception!).
I swapped out the battery, started the van, and everything looked good. The navigation system even came up, automatically entered the security password, and managed to figure out where on the planet the vehicle was! What fun for a software guy getting to play mechanic! The only thing left to do was close the sliding door and put the car back in the garage. After pressing the door close button several times, I discovered that the door would no longer close!
Dismayed, I got from the driver seat and walked over to the sliding door. Yep, the buttons in the back of the vehicle wouldn’t close the door either! How on Earth am I going to close this door without the buttons responding? Well, I was forced to manually release and close the door. Once the door was closed, the buttons once again began to respond, and I was able to control the sliding door without any issues.
As far as I can guess, the electronic control unit (ECU) that manages the doors was powered on with the doors in an unexpected state. Instead of just recognizing the door was open and responding to a close command, it just did nothing! Only after the door was returned to the expected state, was the ECU willing to command and control the doors again.
So, the question is, “Is this a bug in the firmware or a feature?”
(I suspect that it was a failure to test boundary conditions on the controller such as what happens when the controller is powered up with the doors in the wrong state. Or a decision that it was a rare corner case and not worth adding the conditional case to recover the controller when it occurred).
I have been developing hardware, firmware, and software for 40 years, I love to analyze the operation of vehicles I drive. This sounds like the intialization of the door state variable was a fixed value and not based on scanning all the door switches to determine the initial state.
Thankfully it wasnt your drive-by-wire throttle control! (Toyota)
Agreed! I thought it was a fun example how boundary conditions aren’t always handled as one might expect! It’s the kind of bug I can live with!
It might also be a feature, to keep you from locking yourself out while tinkering with the on-board power supply aka battery.
It’s definitely a feature. Door ECU after reset needs to see doors in their initial position. Otherwise they won’t be powered – they are in “degraded” mode. In some cars (mine for example) LEDs inside buttons will blink indicating that doors are in an unknown state. Similarly with windows – after POR you shouldn’t be able to open and/or close them automatically until doing so manually by keeping buttons pressed/retracted for a full sliding cycle.
Interesting. Given that they can read the door position, I would think they would read the position at start-up and then initialize the states based on that and provide user control. I’m sure there’s a good reason for this behavior, but I never could understand why automotive specs are the way they are. Personally, I’m sticking to flight software!
I wonder if perhaps the sliding door was not all the way open when the battery was replaced.
I am assuming that the sliding door has “Fully Open” and “Fully Closed” limit switches, and that there is NOT an absolute position sensor to determine where it is along the length of travel (just TRY to propose that additional component at even a tiny cost!)
So if the door position was unknown at boot-up (neither “Fully Open” nor “Fully Closed”, it MAY be a safety feature to NOT try to open or close the door if the starting position is unknown.
It could be, if the door was NOT fully open, that if you had manually OPENED the door all the way it would have started working again.
It was fully open, but it could be as you say, a safety feature. Perhaps anything but the initial state results in the user safely intervening. In any event, I thought it was interesting behavior.
I use to design doors for buses (around 2003), there always has been a requirement to save every penny. So software would be used to dead reckon door positions.
In this case there may be a fully closed switch only. The door fully open is based on the operating time and the motor current. ie if the door has been moving long enough and a stall current is detected, then the door is in an open state. if the stall current happens at any other time there is an obstruction.
As others have said, the ECU only has absolute knowledge of fully closed, as this is where the position switch is (and is required for safety). So the ECU waits until this state occurs then will take control.
I have a similar control on my electric windows on my car,. the window control switches are 5 position, stop, up/down, open fully / close fully. disconnect the battery and the open / close fully function do not work until they have been manually opened and closed using the up /down controls. (to be fair, this is mentioned in the manual, and I forgot until it happened to me)
This is another example of where ‘implied’ sensing is being used to determine position. ie motor current and dead reckoning based on operating time.
What could go wrong?.. well lets see how long I have to wait until the windows no longer open / close properly.