Lighting prop? SA says all clear.

[ard]

Originally Posted by montoya

No, just like hardware, firmware must take into account all conditions and all user operations. It is hardly unusual to enter in the passenger side and turn on accessories for one reason or another.

For what we do in electrical controls in my business, all firmware needs to go through rigorous safety checking. I'm sure BMW has their own set of standards and regs they must pass as well. It is amazing that something so simple is overlooked- but that is why things are required to be tested.

We will have to disagree on this point.

There can be competing priorities that cannot be resolved, and these are not necessarily 'faults'.

If there is an over-arching principle that 'the driver has higher priority' or 'the driver always controls', then you can imagine a scenario in the software in which there could be a rationale for this behavior.

Lets say the op opened and closed the driver door, walked to the passenger side, entered, put the key in, programmed and then left.

The car sees this as:
a 'driver entry'
and then a 'passenger entry'
and then perhaps within 10 seconds a 'key insert'.

The car thinks driver+ passenger+ key.

Programming ensues. Key out, passenger leaves.

Car thinks 'driver sitting in seat with key in hand'

Perhaps there is some state that is begun with a driver door entry? If something happens within X seconds that state then transitions to 'driver plus something'...if nothing happens that state may revert to 'just a door opened, return to state 0.

What we don't know is how the State diagrams/tables are constructed, and what rules are used to define these states....

Or it could be a software bug.



A

[montoya]

Originally Posted by ard

There can be competing priorities that cannot be resolved, and these are not necessarily 'faults'.

If there is an over-arching principle that 'the driver has higher priority' or 'the driver always controls', then you can imagine a scenario in the software in which there could be a rationale for this behavior.

Lets say the op opened and closed the driver door, walked to the passenger side, entered, put the key in, programmed and then left.

The car sees this as:
a 'driver entry'
and then a 'passenger entry'
and then perhaps within 10 seconds a 'key insert'.

The car thinks driver+ passenger+ key.

Programming ensues. Key out, passenger leaves.

Car thinks 'driver sitting in seat with key in hand'

Perhaps there is some state that is begun with a driver door entry? If something happens within X seconds that state then transitions to 'driver plus something'...if nothing happens that state may revert to 'just a door opened, return to state 0.

What we don't know is how the State diagrams/tables are constructed, and what rules are used to define these states....

Or it could be a software bug.



A

Exactly, it is an incomplete state diagram table, since the lights stay on indefinitely, one can only assume that this state was not covered in the firmware. Definitely not a feature!

[London Lad]

We will have to disagree then. It's a car not the space shuttle.

I can lock the car with key-less go, open the boot with the remote, toss in the keys and close to boot with the red button.

If I have not set up BMW assist then my keys are now locked in the car. It would not be a software bug, it would be my 'unusual use' just the same as the OP.

(PS Did you mean No IMHO :-))

[ard]

Originally Posted by montoya

Exactly, it is an incomplete state diagram table, since the lights stay on indefinitely, one can only assume that this state was not covered in the firmware. Definitely not a feature!

I'd have to agree if the light does, indeed, stay on 'forever'.

Now one might also need to consider bus traffic and communication as a contributor to this observation: if it is repeatable, then it is a software bug- but if it is rare, it may be a combination of a SW problem being triggered by something else. Collisions on a comm bus, or what have you....

In stuff I do, we often use a separate circuit that is a 'watchdog timer'...the software must strobe the timer every so often (each second lets say) so the timer knows the SW is 'alive'. If the SW looses control, the timer cuts power and resets.

In the car, this would be equivalent to a circuit that monitors battery drain and if it is over X milliamps after Y hours, it forces a hard shut down. Of course who cares if a car battery runs dead, from a FMEA or risk analysis perspective. I suspect this time of process is used on cars for critical control systems.

A

[montoya]

Yes, we have watchdogs on our firmware as well to reinitialize the system should an 'illegal' state occur. In the BMW I would assume there is a watchdog for the turning off the lights no matter the 'request' once the battery is drained as you suggest.

You are right as well that I may be jumping to a conclusion based on my car and the OP. It is easy enough to replicate- open the car from the passenger side, insert the key and start the accessories, remove the key and exit through the passenger door. In my car the welcome lights stay on- indefinitely I don't know, but at least more than the settings in IDrive- an hour or more. If you open the driver's door, the welcome lights go off immediately. Try it and we'll have another data point.