SParK: Safety Partition Kernel for Integrated Real-Time Systems

“…While the former is not directly applicable in safety‐critical scenarios , the latter provides support for different scheduling policies at partition level, although strict cyclic scheduling is not yet supported for multicore systems . Furthermore, there are several works in the literature whose design is not based on the ARINC‐653 standard, such as in where customized versions of uC/OS‐II and RT‐Linux can be executed on top of the Safety Partition Kernel (SParK) for monoprocessor architectures. A comprehensive and complete survey on virtualization for real‐time embedded systems can be found in and .…”

Section: Related Workmentioning

confidence: 99%

Multiprocessor platform for partitioned real-time systems

Tijero

Rivas

Ortega

2016

Softw. Pract. Exper.

View full text Add to dashboard Cite

Two current trends in the real-time and embedded systems are the multiprocessor architectures and the partitioning technology that enables several isolated applications with different criticality levels to share the same computer. This paper presents a real-time platform for multiprocessor and partitioned systems, in which communication requirements are also considered. The paper describes the adaptation of MaRTE OS (a monoprocessor real-time operating system) to the XtratuM hypervisor for the multiprocessor Intel x86 architecture. This adaptation makes two contributions to ease the development process of future mixed-criticality applications: firstly, it integrates the hypervisor technology and the fully partitioned scheduling in a multiprocessor environment, and secondly, it provides the basis to interconnect partitioned and non-partitioned applications via a homogeneous communication subsystem.• Clock and timer management. Because clocks and timers are shared by all the partitions, MaRTE OS must access these services through the appropriate hypercalls. Although XtratuM provides support for two different clocks (a global monotonic clock and a local execution time clock for each virtual CPU), this first adaptation only uses the global clock and leaves the integration of the remaining clock for future work. INTERPARTITION COMMUNICATION EVALUATIONThis section aims at validating the proposed interpartition communication subsystem. To better evaluate its performance, a set of tests has been executed without using other high-level network protocols such as UDP/IP on top of our approach.The tests will measure the communication latency associated with a data flow between two partitions (i.e. the first partition writes data samples and the second partition reads them). The communication latency is defined as the time between the transmission and the reception of each data sample. This performance analysis includes two case-studies, which are detailed in the following: Overhead testThe first case-study aims at measuring the overhead of using the proposed interpartition communication subsystem on top of the hypervisor. To this end, the test defines one single data flow from partition 1 to partition 2 and with one disjoint core allocated to each partition. The test is executed with different payloads and two configurations: (1) by directly using the communication services provided by XtratuM and (2) through the interpartition communication subsystem implemented in MaRTE OS.The maximum latencies obtained for the Overhead test are reported in Figure 12. As can be observed, the interpartition communication subsystem adds an overhead lower than 15 ms to the communication services provided by XtratuM. This overhead can be explained by the software layer added to use the interpartition communication subsystem as a standard driver in MaRTE OS and the extra overhead in the handling of interrupts by the operating system. Finally, it is worth noting that maximum latencies are nearly constant for the selected payloads in both cases, ...

show abstract

“…Next, we briefly mention some virtualization solutions for safety-critical systems that are not specifically designed for the avionics domain, hence do not conform to the ARINC-653 standard. Authors from Indian Institute of Technology [23] developed SParK (Safety Partition Kernel), a Type-1 para-virtualization solution designed for safety-critical systems; an open-source RTOS uC/ OS-II and a customized version of saRTL (stand-alone RT Linux) are ported as guest OSes on SParK. Authors from CEA (Atomic Energy Commission), France [24] developed PharOS, a dependable RTOS designed for automotive control systems featuring temporal and spatial isolation in the presence of a mixed workload of both time-triggered and event-triggered tasks.…”

Section: Hard Real-time Virtualization For Safety-critical Systemsmentioning

confidence: 99%