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 0zero.
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 will be explained with the help of Fig. 35.
[[File:MISC-TN-015-alarm-detection-latency.png|thumb|center|600px|Fig. 5: Alarm detection latency]]
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 instance, let's assume that the alarm was triggered by a failure 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 (t<sub>F</sub> precedes t<sub>B'</sub>) 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 considerable 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 experimental verification.
* With regard to frame loss, a mechanism able to detect this anomaly was implemented at the application software level. Should a frame loss occur, this event is logged and reported as shown by the example log below (see "Abnormal frame rate" messages). Incidentally, this mechanism exploits frame timestamps described in [[#Alarm recordings|this section]].
[[File:MISC-TN-015-latency-testbed.png|thumb|center|600px|Teastbed Fig. 6: Testbed used to verify the alarm detection latency]]
In essence, the basic idea consists of shooting a 5-digit 7-segment-display timer with 1ms resolution. The timer cycles repeatedly from 00.000s to 99.999s and also provides a digital signal that is used to emulate the alarm signal. Whenever the timer reaches 50.000s, this signal is raised for 1 second. In other words, the timer triggers an emulated alarm that is synchronized with the visualization of the 50th second on the displays. Referring to the Fig.X TBD, istants t<sub>B</sub>, t<sub>0</sub>, and t<sub>A</sub> can be easily associated with the time visualized by the timer as follows:
*t<sub>B</sub> = 50.000-8.000 = 42.000s
*t<sub>0</sub> = 50.000s
[[File:000000 -8.133780480.png|thumb|center|600px|Fig. 57: Frame associated with t<sub>B'</sub>]]
[[File:003332 +3.046812160.png|thumb|center|600px|Fig. 68: Frame associated with t<sub>A'</sub>]]
[[File:002424 +0.000000000.png|thumb|center|600px|Fig. 79: Frame associated with t<sub>0'</sub>]]
[[File:002425 +0.003355520.png|thumb|center|600px|Fig. 810: Frame following the alarm frame]]
