Database in EEPROM, with ASM

Go To Last Post
105 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You were talking about faulty chips. As a faulty chip does what it wants (worst case) or nothing (best case), you cannot handle it. Imagine a faulty chip always pulling down the bus lines. No communication anymore. You can't handle this but with a fallback µC on every module. This is redundancy.

That statement is totally untrue. I know what redundancy is - my latest product is for a critical application - it has redundancy on many levels and can be theoretically proven to fail once in >1E9 hours.

In your instance where you have a common bus, it is possible for the bus driver to fail killing the bus and the system doesn't work = this we agree on. Now, if you wanted some protection in this instance we could put a relay for sake of argument and have a watchdog circuit driving it so that the micro has to tickle the watchdog in order for the relay to activate - if the micro dies or detects the bus is stuck it stops tickling the watchdog, the relay drops out. We've added redundancy with no micro and the odds of both the relay and the micro failing are much lower. In your application, I would suggest this would be excessive and add cost. For this type of application I would just ensure I have adequate protection circuitry for the drivers so that the likelyhood of a failure due to external influences is minimised. You've suggested this. Where I have a RS485 bus strung for 1km outdoors I use RS485 transceivers that are ESD rated and have 60V tolerance (my apps put 24V down the same cable). I add MOVs to add a bit more resilience. Using a LT1785 device vs a 75176 adds cost, in my case the cost of repair far outweighs the cost of the board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tolerant drivers are something that'll come once the prototype proves I'm on the right way. Relays for each module, as you said, are something that's just too pricy for this bus.

And relays are not redundancy. Relays are error-detection and avoiding the killing of all modules attached. Redundancy would be having the relay switch to a backup µC.

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Markus, relays are not error detection! They detect nothing - they simply connect/disconnect the bus, it is the watchdog and the processor software that does the error detection. Sure, the relays could switch to another processor if you wanted to ensure uptime.

Redundancy can mean many things. In this instance redundancy is extra hardware to cope with failure. Refer to the standard IEC61508 (I think! It gets hard to remember all the standards. Anyway, the standard in reference to machine safety). For the FMEA, you would define the failures - which ones are critical and which ones are acceptable.

As for the bus, for a commercial system, one would accept that a single point failure could cause the system to stop normal operation. This was the case with the coax ethernet connections - one cable error would kill the network. Nowadays there's 10BaseT with switches/hubs to limit the error propagation. So for a lighting/home control system, one would minimise the likelyhood of a failure with protection for compliance (CE) and the expected faults one would expect in the field. For my stuff, the likelyhood of 24VDC being connected to the RS485 bus causing a failure was high, for CE compliance I could've ignored this, but it would be prudent as an engineer to design the system to tolerate such an event.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do know relays are no smart elements. All I wanted to say is using a relay (triggered by a clever circuit doing awesome things you'll usually never see unless a circuit fails) means detecting an error (and then switching the unit offline or switching to a backup one).

The bus will be externally pulled up, so as long as a module doesn't die while pulling a line down, it doesn't affect the bus. Sure, a watchdog circuit using for example an ATtiny and disabling the bus driver if it didn't react is an option. Maybe an option I'll actually implement. I'm not sure yet how to drive the bus, once these drivers or the driver circuit is fixed, I can think about adding failure detection and disabling all pulling-down at the bus.

All good ideas! But before I have the protocol I'll use to send and receive data, before I have an actually working prototype on a breadboard that proves the protocol works and is a good choice, before that's done, I don't need any bus driving circuits with ESD tolerance etc.

Markus

Pages