{'fraction_non_alphanumeric': 0.02399409376153562, 'fraction_numerical': 0.0022148394241417496, 'mean_word_length': 5.076233183856503, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Non-Intrusive SWIFI technique for RTOS robustness testing

Systems-on-a-chip (SoCs) technologies offer a great promise by shrinking an entire computer to a single chip. Real-time operating systems (RTOS) enable SoC applications to cope with more sophisticated control tasks. These operating systems are supposed to guarantee a correct service despite the existence of design application faults. Robustness can be defined as the capacity of a system to operate correctly in presence of exceptional inputs or stressful environmental conditions. Accordingly, RTOS robustness testing is a way to obtain indications on the OS capacity to resist/react to the manifestation of faults [1], design application faults in our case. It is worth mentioning that robustness testing claims for target systems to be considered as black boxes. This is thus the vision of the RTOS we adopt for rest of this paper. Software-implemented fault injection (SWIFI) is a well-known technique to emulate design faults [2]. Several authors have proposed SWIFI techniques that rely on solutions requiring the clock of the system to be stopped during fault injection [3]. Others claim for solutions in which, although the system clock is physically stopped, the system virtual time is not [4]. These approximations are acceptable when the target RTOS is tested using a model of its execution environment. However, they cannot be admitted when it is checked under real life experimental conditions. Strong encapsulation promoted by SoCs imposes observability and controllability impairments to fault injection, especially when low intrusion is a requirement. The work in [5] shows that low intrusion level can be achieved when emulating hardware faults affecting the memory of a SoC. The approach relies on the use of the on-chip debugging capabilities defined by the standard Nexus interface [6]. The SWIFI technique presented in this paper explores the possibility of exploiting SoC debugging mechanisms to emulate design faults for evaluating their impact on the robustness of a RTOS. Requirements of the technique are: (i) it must enable robustness testing to be carried out in real operational conditions, i.e. without stopping the SoC; (ii) it must minimize the interference between the experimentation process (fault injection and observation) and the real time behavior of the RTOS under study, and (iii) it assumes that both application and RTOS source codes are not available. One may reason that application design faults lead to misbehaviors that can eventually affect the RTOS on top of which such applications run. We consider that it exist an RTOS API that centralizes all operating system calls offered to the application