I have been involved with the design and integration of the software on a number of avionic embedded systems; from a Fault Detection, Recovery and Reporting perspective I have some observations and some questions.
1. Only reporting 'own' failures to ACARS: IIRC on A320 there was an Airbus requirement on avionic systems that they had to have a 90% confidence level for detecting and reporting an internal failure, down to 'sub-system' level. In order to avoid a 'cascade' of messages, it is obviously important not to generate a maintenance message when the fault is known to be external to that particular system. This is possibly significance with the the IR2 message and the TCAS FAULT message; these should not have been generated because of an external ADR problem, but because of internally detected faults. A question for an ISIS expert, would high 'g' loads cause an ISIS system to consider that outputs from its gyros or accelerometers were 'out of spec'? A question for a TCAS expert, what would cause TCAS to generate an ACARS message, a GPS derived value (such as speed or rate of change of heading) out of spec? An earlier post referred to TCAS using Doppler to determine relative speed between aircraft; would 'unbelievable' changes in relative speed cause an internal fault to be flagged?
2. Delay on ACARS messages: Once an Airbus avionic system detects a fault it should immediately mark its outputs as Invalid/Unavailable to its 'users' (including CFDS). However, there may be a significant delay before the system can determine if this fault is a 'hard' internal failure. Its recovery process might include retrying an input a number of times, resets (of sub-elements of the system, or the complete system) or diagnostics (such as running loop-back tests on the ARINC 429 Input Port). So depending on the type of detected fault there might be a significant delay before a system is confident in reporting a failure. For example, the loss of an external communication link for a minute or so may not be considered a 'hard' failure, loss for 10 minutes or so might be.
3. Timing sequence of ACARS messages: As pointed out in other posts, ACARS primary purpose is to provide maintenance data to Ground Crew. There is no particular urgency to providing maintenance data to the ground (as opposed to ASAP for fault information to the flight crew). As it is an inefficient use of processing power to provide data at a rate faster than it is needed, an aircraft system could be designed to schedule a task every couple of minutes to check the system's internal fault log to see if a maintenance message should be composed and sent to ACARS. So the sequence on messages generated by different systems could be quite random.
4. Failures unlikely to be caused by lightning: It is unlikely that any of the ACARS failure messages were due to damage by lightning as it is likely that the system's vulnerable processing capability (CPU, RAM, etc.) would also have been affected to such an extent that the system would not be able to compose and send any messages to the ACARS. It is an important 'fact' that the reporting systems are still running; the failure they are reporting is unlikely to be due to lightning, power supply loss, fire or being shaken to destruction.
5. Setting fault detection levels: Avionic system designers are well aware of the difficulties in getting the right balance between 'nuisance false fault reports' and 'not detecting marginal faults'. The limits within the software that are used to flag a fault on sensor input values (max/min, rate of change, comparison) are based on the 'expected' range of values during aircraft operation; persistent input values that are outside the aircraft's operational limits should be considered as more likely to be an internal fault and hence flagged as such. A system that flags itself as failed and needing maintenance might in fact be working, it is just that what its sensors are telling it is 'unbelievable'!