Bureaucrats, dave_user, Administrators
4,650
edits
Changes
no edit summary
One of the major concerns that were faced during the conception of the PoC was related to its real-timeness. In principle, two real-time requirements have to be met to achieve the desired functionalities:
# [REQ1] Regarding the acquisition of frames from the image sensor, such a PoC should guarantee that all frames are captured (i.e. no frame loss), no matter what processing the PP is performing simultaneously (encoding the live stream, serving a web page, etc.). Taking into account the frame rate and the fact that the sensor has no buffering capabilities, this implies that the processing platform has about 3ms to complete the acquisition of each frame.
# [REQ2] Maximum alarm detection latency has to be much smaller than the alarm buffer size, ideally 0.
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 top part shows the ideal recording buffer. As describedin 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 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 instance, the instant t<sub>F</sub> in the image. Let's assume that a failure causing the alarm took place 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 recording buffer and thus it is not available for the 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 by limiting implementation effort and development time.
