How clearing of Diagnostic Trouble Codes(DTC) or Fault Codes work in typical embedded systems ?

Let's say application is Third Row Power Folding Minivan seat.  User
presses a button.  Seat starts moving.  There is a obstruction which
causes DC motor moving the seat to stop turning almost immediately. 
Embedded controller attached to seat detects a motor stall or block.  It
activates a fault code.  What happens next?

Probably embedded software application won't allow seat to move because
there is a fault.  How does the DTC clear and what triggers the seat
movement again?  Usually fault codes are uploaded to CAN based tool. 
Service Technician sees active DTC.  It removes the obstruction.  Then,
how does the fault code clear?  What sequence of steps take place to
restore movement of seat?
---------------------------------------
Posted through http://www.EmbeddedRelated.com

On Tue, 22 Sep 2015 08:29:17 -0500, learn wrote:

> Let's say application is Third Row Power Folding Minivan seat.  User
> presses a button.  Seat starts moving.  There is a obstruction which
> causes DC motor moving the seat to stop turning almost immediately.
> Embedded controller attached to seat detects a motor stall or block.  It
> activates a fault code.  What happens next?
> 
> Probably embedded software application won't allow seat to move because
> there is a fault.  How does the DTC clear and what triggers the seat
> movement again?  Usually fault codes are uploaded to CAN based tool.
> Service Technician sees active DTC.  It removes the obstruction.  Then,
> how does the fault code clear?  What sequence of steps take place to
> restore movement of seat?

There is not enough uniformity of requirements or application for there 
to be a "typical" embedded system in this regard.

In any safety-related application, though, the the entire project team, 
lead by the system designer, should cooperate on figuring out the safest 
outcome.  There will be no "typical" answer: for a power seat that may 
have a person trapped behind it, refusing to keep pushing in the 
direction of the obstruction is good, but refusing to back off is bad;  
for a fly-by-wire system, locking up at the first hint of an error would 
be a Very Bad Thing.  Basically, each project brings its own constraints, 
and applying cookbook answers is often the short road to failure.

For something cheap and not at all safety related, like a watch or a toy 
cat, not having any built-in-test may be the best approach.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

learn wrote:
> Let's say application is Third Row Power Folding Minivan seat.  User
> presses a button.  Seat starts moving.  There is a obstruction which
> causes DC motor moving the seat to stop turning almost immediately.
> Embedded controller attached to seat detects a motor stall or block.  It
> activates a fault code.  What happens next?
>

If it has a place to send the fault, it goes there. If not, nothing
happens.

> Probably embedded software application won't allow seat to move because
> there is a fault.

Right.

> How does the DTC clear and what triggers the seat
> movement again?

I'd clear 'em on powerup or have them age out after an hour or so.

>  Usually fault codes are uploaded to CAN based tool.

I would hope a seat controller would not be CAN connected.

> Service Technician sees active DTC.  It removes the obstruction.  Then,
> how does the fault code clear?  What sequence of steps take place to
> restore movement of seat?

Tech must have some means of clearing the faults if this is to be
how it's done. There are extended message blocks in J1939. You send a
code and it clears the fault.

> ---------------------------------------
> Posted through http://www.EmbeddedRelated.com
>

-- 
Les Cargill