Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Real-timeness, frame dropping, and alarm detection latency
==Real-timeness, frame dropping, and alarm detection latency==
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:
# [R1REQ1] 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.# [R2REQ2] Maximum alarm detection latency has to be much smaller than the alarm buffer size.
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.
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 used to limit implementation effort and development timeutilized. 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. Basically, two different approaches were utilized for this verification.
# With regard to frame loss, a mechanism able to detect it was implemented at the application software level. Should a frame loss occur, this event is logged and reported. Incidentally, this mechanism exploits frame timestamps described in [[#Alarm recordings|this section]].
# Concerning alarm detection latency, a tailor-made testbed was built as illustrated in the next section.
