I2C Central Error Handling

Question

I am hoping to get some more opinions to supplement my own.

I am hoping to optimize my system to use I2C to handle all of my error reporting.

My system may be understood by the following photo.

My system is made up of only Arduino UNO's and each of them has their own internal processes, however I want warnings and errors to be reported to the a central error handling UNO as the attached diagram shows. The "Worker" UNO's have their own processes and will continue about their individual business as long as the "All Good Flag" is High(A HIGH GPIO read on the "Workers" side) .

If the Central UNO detectes a catastrophic error it would shut the entire system down by pulling the "All Good Flag" Low.

I am anticipating the I2C lines to remain decently quiet. I am looking to make use of the I2C on the "Workers" side so that whenever there is an error on one of the "Worker" Processes the "Worker" will send the error to the "Central" Board where it catalogs which board sent the error and decides what to do with the said error.

I believe that to best achieve this I would make the "Central Error Handler" as the Master(Listener) and the "Workers" as the Slave(senders), however I am a bit unsure as to how to implement a this sort of system.

Note: All Uno's are within 2 feet of each other.

Any Guidance is extremely appreciated.

Thank you all in advance, Carlo

Answer 1

When using UNOs you have direct controlability. With I2C you need a master and a bunch of slaves (you already know this).

A good place to start is having the master ask the slaves periodically for an error report. If a slave sends an error or a slave does not respond the master shuts down the system.

For an even more robust system (but much harder to set up) is that the connection is bidirectional. The master must hear from the slaves with no errors, if it does not it will shut down the system. The problem is that if the master fails the system can run out of control. If the slaves have to periodically also hear from the master to stay up then there is redundancy. In this way if the master fails the slaves will automatically shut down. This is hard to set up because setting up link and keep it stable can be problematic.

My suggestion would be to bring the system up in disable mode. Then when the link is up and stable push a button on the master to enable the system.

Answer 2

A pure I²C bus doesn't have additional alert and interrupt lines. On such bus, the I²C slave can't initiate transactions, and the I²C bus master can't be a pure listener. However, the bus master can poll the slaves for the error flag. Besides, it looks like you are planning to have an alert line outside of the I²C.
(Somewhat related threads: this and this.)

While you may be able to make the I²C work with 2-foot connections, a bus with multiple 2-foot connections may end up being be too large for plain I²C, and you will have a hard time making it work reliably. A kind of distributed control system which you are describing is often done with CAN. It was designed to work through long cables, and it's peer-to-peer, so any node can initiate transactions. (At the same time, I'm not sure if you want to open the CAN of worms, because CAN is more complex than I²C. Then again, if you don't look into CAN, you might end up like this guy with an overgrown I²C bus.)