Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Real-timeness, frame dropping, and alarm detection latency
The first requirement is obvious, but it can be relaxed a little bit in the sense that it has to be satisfied while when the system is waiting for an alarm to happen and until the alarm buffer is filled. After that moment, a fame loss can be tolerated because it does not compromise system functionalities. In other words, following the detection of a new alarm say A1, it is acceptable that the system ignores new possible alarms until the buffer associated with A1 is stored on the SSD. Once storing is completed, the system is ready to detect and process a new alarm again.
The second requirement is a little more subtle and it will be explained with the help of Fig. 3.
The top part shows the ideal recording buffer. As described in section [[#Sizing the alarm buffer|''Sizing the alarm buffer'']], the recording is supposed to start 8 seconds (t<sub>B</sub>) before the occurrence of the alarm event (t<sub>0</sub>) and end 3 seconds afterwards (t<sub>A</sub>)). As a matter of fact, the recording system takes some time to recognize that the alarm signal is asserted—we refer to this time as ''alarm detection latency''. The fact that this latency is greater than 0 leads to the actual situation illustrated in the bottom part of the picture. Let t<sub>0'</sub> be the actual instant when the PP detects the assertion of the alarm signal. Consequently, the beginning and the end of the recording buffer (t<sub>B'</sub> and t<sub>A'</sub> respectively) are delayed as well. Of course, alarm detection latency should be minimized in order to get the actual recording buffer as close as possible to the ideal one. If the latency is too large, in fact, the recording could miss essential events for the post-mortem analysis. See, for For instance, the instant t<sub>F</sub> in the image. Letlet's assume that the alarm was triggered by a failure causing the alarm took place occurring at time t<sub>F</sub> as shown in the picture. Because of the alarm detection latency, this instant is before the start of the actual recording buffer and thus it is not available for the post-mortem analysis.
In light of these requirements, it is clear that the processing platform should be engineered as a real-time system. Despite these considerations, however, a platform not specifically designed with real-time capabilities was utilized. Rather, it was decided to use a platform providing enough headroom in terms of processing power and to verify experimentally the fulfillment of requirements. This approach allowed to meet the budget available for the PoC by limiting implementation effort and development time.
Basically, two different approaches were utilized for this verification.
===Alarm detection latency verification===
The following diagram shows how the specific testbed used for this verification looks like.
*t<sub>0</sub> = 50.000s
*t<sub>A</sub> = 50.000+3.000 = 53.000s
Ideally,
==Future work==
