Mixed-Criticality System Modelling with Dynamic Execution Mode Switching Philipp Ittershagen, Kim Grüttner
Wolfgang Nebel
OFFIS – Institute for Information Technology Oldenburg, Germany
Carl von Ossietzky University of Oldenburg Oldenburg, Germany
{ittershagen,gruettner}@offis.de
[email protected]
Design Entry Specification Capture & Validation
Capture Requirements 1
compile Specification Model
Refinement Flow
Abstract—In this paper, an executable system model for performing a functional simulation while observing the dynamic effects of mixed-criticality requirements regarding applications with different levels of assurance is proposed. The model provides the expression of dynamic execution modes and execution time estimates on each criticality level of the system. In a refinement step, it is possible to observe the effects of scheduling policies, dynamic criticality-, and execution mode switches on the functional behaviour of the system in a trace-based, simulative manner. An early evaluation of a quadrocopter platform consisting of a safetycritical flight control application and a video-based, performancecritical object detection is used to demonstrate the applicability of the design flow. Simulation results indicate that by defining multiple execution modes of the object detection algorithm, the run-time utilisation feedback allows the algorithm to run in a high-quality mode for more than 50% of the time, thereby increasing the overall system utilisation by two thirds compared to a static resource utilisation analysis.
Simulation Model
Validation/Analysis/ Estimation
Computation Refinement 3
2
Computation Model & Refinement
compile Computation Model
Simulation Model
Validation/Analysis/ Estimation
4
I. I NTRODUCTION In today’s embedded system development, the challenge of fully utilising the available hardware resources to reduce the cost, size, and power consumption has emerged the concept of mixed-criticality systems, where applications, containing different requirements regarding their levels of assurance, are integrated on a single platform. Due to the necessity of a pessimistic upper bound on the execution time of high-critical application-level components, the statically analysed temporal properties often significantly differ from the average execution time on the target platform. Mixed-criticality systems enable the designer to utilise the resources available in the average case, and provide on-line mechanisms to fall back to the worstcase scenarios when the assumptions on the average temporal behaviour have been violated. In this paper, we propose a mixed-criticality system model that can be used to express and evaluate the functional behaviour of the specified system using a simulation-based analysis. Our main contribution is a simulative approach to test the functional correctness of the specified system in the presence of dynamic mixed-critical properties, such as criticality- and execution mode switches. Fig. 1 depicts the typical designand refinement flow of an SoC, ranging from the initial specification to the implementation. The contributions in this paper can be incorporated into the design flow as follows. In the specification model, the proposed elements provide means for initially capturing the requirements regarding mixed-criticality
Communication Refinement (WIP)
Synthesis/Target Code Compilation (WIP)
Fig. 1.
System-on-a-Chip (SoC) design and refinement flow.
(1). An executable simulation model allows validating the functional behaviour specified by these modelling components (2). In the computation refinement step (3), it is possible to observe the actor’s resource usage behaviour by mapping them onto abstract processing resources. We support this by providing an RTOS model in Sec. III-C for an early, simulationbased estimation of the system’s dynamic behaviour regarding criticality- and execution mode switches (4). The following restrictions apply to the state of the proposed approach. The communication refinement by providing shared resources (shared memory/dedicated hardware) as mapping targets is not handled in this contribution. Instead, we assume that the targeted platform is able to guarantee the annotated execution times of the modelling elements, such that we can construct a lock-free access patterns at design time. Although not in the scope of our evaluation, we also assume a global, synchronous clock on the target platform, such that it is possible to maintain a system-wide, dynamic criticality level. The paper is organized as follows. In Sec. III, we present
the OSSS-MC system model components. Sec. III-C describes the semantics of the RTOS model implementation regarding the dynamic mixed-criticality and scheduling behaviour. In Sec. IV, we demonstrate the applicability of our approach by modelling a safety-critical quadrocopter flight control software along with a performance-critical application for video-based object detection. We mimic the uncertainty of the execution times on a safety-critical application with a statistical distribution, and allow the performance-critical application to alter its resource consumption by defining a high quality execution mode and a degraded, low quality mode. In high system load scenarios caused by the safety-critical task set exceeding their estimated execution times, we demonstrate that by switching to a degraded execution mode, the performance-critical application can still perform an object detection on a low-quality image source instead of completely exceeding its required maximum response time. As a result, switching between two execution modes of the object detection algorithm dynamically allows it to perform the high-quality mode in more than 50% of the frames. In Sec. V, we conclude the presented work and discuss future steps based on the limitations of the current approach. II. R ELATED W ORK Many approaches regarding RTOS modelling in discrete event simulators have been proposed throughout the literature [6, 18, 19]. This paper extends our host-based multitasking RTOS model based on SystemC [12, 13] by adding the capability of a global criticality state and the support of dynamic execution modes. Compared to other mixed-criticality aware RTOS frameworks, such as MC2 [14, 17], our RTOS model does not require an implementation on a specific target platform. Although an abstract RTOS model obviously limits the simulation details of the RTOS artefacts, it still enables an early estimation along with a simulation of the functional behaviour, without the need to port a full RTOS to the target platform. Initial challenges for modelling and analysing mixedcriticality systems were introduced by Vestal [20] with implications on the schedulability of these systems being further discussed in [1, 3, 5]. The mixed-criticality task model provides the possibility of defining attributes that depend on the task’s criticality level. This way, multiple execution time estimates, based on the level of assurance given by the analysis method, can be expressed for the same task. These values can range from estimated, average case values derived by a simulative approach to statically analysed, worst-case execution times (WCETs), defining an upper bound on the task’s computation time. An overview of different mixed-criticality system models and current efforts regarding schedulability analysis in the context of single- and multi-core systems is given in [7]. In our work, we adapt the emerging standard model for mixed-criticality systems and define a system model, based on the OSSS [11] methodology to support the notion of dualcriticality [2, 15] properties.
The proposed RTOS model defines a global, dynamic criticality state. To detect and perform a criticality switch, our approach uses an on-line execution time monitoring mechanism, similar to [2]. Currently, scheduling policies in our approach are limited to static mixed-criticality policies, where a higher criticality also implies a higher task priority. Baruah et al. [4] consider the schedulability analysis of adaptive mixedcriticality systems, where this restriction is lifted. However, it is assumed that tasks are terminated when their criticality level is below the dynamic system criticality mode. In our approach, the system designer is able to define a degraded mode for lesser critical tasks that will be executed in such scenarios. The mixed-criticality design flow specified as part of the CompSOC approach [10] features an incremental refinement step starting at a cyclo-static data flow application model. It is then converted to a performance model to provide estimates of the designer’s mapping decisions. However, it does not support dynamic criticality modes. Additionally, it is not possible to provide multiple criticality-dependant execution time estimates for the actors in the application model. Giannopoulou et al. [8, 9] propose a method to schedule mixed-criticality applications on multi-core systems. The tasks are scheduled using a flexible, time-triggered scheduling approach. Similar to our proposed approach, the task model features a degraded mode that can be executed depending on the current criticality level. In our approach, we propose explicit communication blocks to model inter-task dependencies. Although not in the focus of this paper, interferences on shared resources could then be derived from the mapping of the communication blocks to other platform components. Our work focuses on combining the mixed-criticality simulation model with the execution of the functional behaviour, thus enabling a trace-based, simulative analysis of the system, along with the possibility to test the functional correctness without a target platform implementation. We aim to provide an entry point for a seamless design flow, starting at an initial, functional specification and providing first estimation results regarding resource usage on a processing unit. III. OSSS-MC S YSTEM M ODEL The proposed OSSS-MC system model is an extension of the OSSS methodology [11] that aims at facilitating the notion of mixed-critical properties with a functional simulation. The OSSS methodology incorporates a design entry and multiple layers of abstraction, each of them aimed at supporting the designer to incrementally refine the description from an initial application-level model towards an implementation of the system. The entry point of designing the system with the OSSSMC flow is the application layer, as illustrated in Fig. 2. Here, the system’s behaviour is partitioned into runnables and interaction exposed via shared objects. Simulating the functional behaviour expressed by the application layer is supported by an executable implementation based on the SystemC discrete event simulator.
Application Layer Task
Performance-critical task set T4
Safety-critical task set T1
S1
T22
S2
T3
(Shared) Object
Virtual Resource Layer
Task Container
Task Container
RTOS Model
Fig. 2. OSSS-MC Application Layer with runnables, tasks, and shared objects, clustered using two criticality levels. In a refinement step, the application-level runnables are mapped to task containers on top of an RTOS model of the Virtual Resource Layer (VRL).
After modelling the system on the application layer, the designer is able to map the defined components to the Virtual Resource Layer (VRL). On this layer, the target platform resources are represented through resource models. Mapping tasks and shared objects from the application layer to VRL components and performing a simulation enables an early estimation of the resource consumption regarding the partitioning, scheduling, and mapping decisions. It is also possible to express temporal requirements along with the functional application layer model using source-level annotations. With the OSSS-MC approach, we introduce properties for defining the static criticality levels of each component on the application layer. Furthermore, a dynamic criticality level is introduced in the VRL, which describes the current criticality of the system during run-time. Definition 1 (Application Layer Configuration). An application layer configuration C is defined as a triple (R, S, L) consisting of a set of runnables R, shared objects S, and criticality levels Li ∈ L. In this work, we exemplarily define two criticality levels L = {PERF, SAFETY}, representing computation-intensive, low-critical jobs and safety-related, high-critical jobs. A. OSSS-MC runnables The notion of runnables within the OSSS-MC framework is based on the periodic task model [16] with the addition of properties for expressing a static criticality and structural connections to shared objects. The support of different views on the execution behaviour of a runnable is defined in a twofold manner. Each criticality level defines an overall execution time as well as an execution trace. The former addresses the possibility to describe criticality-dependant levels of assurance regarding the end-to-end runnable execution time. The latter allows for describing criticality-dependant runnable behaviour regarding the dynamic criticality level of the system. Definition 2 (OSSS-MC runnable). Let I be the set of all shared object interfaces in the application layer configuration C. A runnable ri ∈ R is a 5-tuple ~ L , ~ π, ξ, T, C,
consisting of • a period T , ~ • an execution time vector C, • a set of ports πi ∈ π, representing the connection to the associated shared object interfaces πi ⊆ Ii , and ~ with each element of the • an execution trace vector ξ vector representing an execution trace hν0 , . . .i, consisting of a series of activity nodes νk ∈ π ∪ R+ denoting either communication through a port πi ∈ π or computation with a given estimated execution time t ∈ R+ , and • a (static) criticality level L ∈ L. ~ i ) denotes the runnable beAn execution trace vector ξ(L haviour for the system criticality level Li . B. Communication between runnables Within the OSSS-MC modelling framework, communication is explicitly modelled using shared objects with access points to the shared object being explicitly modelled using interface method calls through runnable ports, which are structurally bound to a shared object interface at design time. A shared object has the ability to synchronise concurrent requests from multiple runnables with the help of a user-defined scheduling policy in order to guarantee mutual exclusion. Definition 3 (Shared Object). Let C be an application layer configuration defining the criticality set L. A shared object S is a 5-tuple (Σ, M, I, c, Φ) , containing • the state Σ, consisting of user-defined, abstract data types, • a set of methods or services M ⊆ Σ × Σ, representing operations on the object’s inner state, • a set of interfaces I ⊆ P(M ) the object provides, • a communication penalty time c describing the delay induced by accessing the object, • an arbitration policy Φ for serializing concurrent access to the shared object. Note that, as stated in Sec. I, due to the refinement flow being in an early work-in-progress state, we are currently not synchronising between concurrent runnable requests at runtime. Instead, we map all shared objects to processor-local memory and statically schedule synchronisation points that occur between the communicating runnables. Additionally, we map all communicating runnables to the same task container on the VRL (as depicted in Fig. 2). With a static schedule of the mapped runnables, as well as any communication nodes νi being defined in a sequential manner, we avoid the need of a run-time arbitration policy for now. We further assume that we are targeting a predictable architecture [10] which is able to guarantee the execution traces defined in the runnable model. In future work, we aim to provide support for expressing dynamic arbitration policies on shared objects and evaluate challenges regarding inter-criticality communication. In a refinement step, runnables and shared objects from the application layer are mapped to the VRL, consisting of
#define _MS(n) sc_time(n, SC_MS) #define _US(n) sc_time(n, SC_US)
1
Software Task
2 3
OSSSMC_RUNNABLE( sensor_data ) { sc_port< osssmc_shared_object_if > data_out;
period end
4 5 6
OSSSMC_RUNNABLE_CTOR( sensor_data ) { set_period( _MS(2) ); set_eet( PERF, _US(674.193) ); set_eet( SAFETY, _US(1114) ); set_criticality( SAFETY ); set_priority( 1 ); }
wait for next period
7 8 9 10 11
inactive
~ i) ξ~ ← ξ(L assign running ready ~ (execute ξ) deassign P ~ i) ν > C(L ~ ν∈ξ
12
increase criticality
13 14
void main() { void* data; // temporal behaviour modelled using a gaussian distribution // (average and variance are derived from the given WCET) OSSSMC_EET( gauss(_US(1114)) ) { data = /∗ query sensor data from sensors ∗/; } data_out->write( data ); } };
15 16 17 18
Fig. 3. State-based representation of the dynamic VRL criticality mode switch behaviour.
19 20 21 22 23 24
Listing 1. Example of an OSSS-MC functional description, execution time annotations and mixed-criticality properties.
task containers and an RTOS model. The task containers allow for defining a static schedule among a set of runnables. The RTOS model will then schedule each container according to a top-level scheduling policy, currently supporting static priority-based scheduling approaches. Currently, static mixed-criticality scheduling policies are supported, where the runnable priority does not change during criticality switches. C. OSSS-MC simulation model execution semantics Listing 1 shows an example of an annotated runnable with mixed-criticality properties. The estimated execution time (EET) behaviour of runnables (defined in Listing 1 line 4) and shared objects can be annotated to blocks of functional code using OSSSMC_EET directives (Listing 1, line 19). This simulated execution time was randomized using a gaussian distribution by deriving mean and average values from the given WCET. Furthermore, the system designer can specify the execution time boundaries for all defined criticality levels from lowest to highest (Listing 1, line 9). In this case, a safetycritical runnable was defined having an average, execution time budget for the criticality level PERF and a worst-case execution time annotated for the SAFETY level. The runnable budget for the PERF state was set to cover the 95 % quantile (674.193 µs) of the runnable’s WCET. The proposed runtime model will guard the observed execution time annotated by the EET blocks within the specified boundaries and adjust the current system criticality level accordingly. The state diagram depicted in Fig. 3 describes the RTOS model criticality switch behaviour in the context of a task. The RTOS model contains a monitor process for tracking the runnable’s execution time behaviour. If a runnable is ~ i ) is used to currently active, the execution time vector C(L define internal deadlines to track when the runnable should
have finished executing. If it has crossed the execution time ~ i ), the system criticality level is increased to Li+1 . As a C(L consequence, the behaviour of all runnables changes according ~ i+1 ) on their to the criticality-dependant execution trace ξ(L next period. In this paper, the criticality level is decreased again after a certain amount of task periods have been completed without crossing the runnable budget again. The concept of the proposed monitoring mechanism can be realised by dynamically reconfiguring a timer module to generate interrupts for the next virtual deadline and by providing an associated interrupt service routine on the target platform to handle any deadline overruns. IV. E VALUATION We demonstrate the efficiency of our approach with an example of a mixed-criticality system mounted on a quadrocopter platform. The quadrocopter should autonomously keep its current flight position, while a second application is recognizing an object using a camera mounted to the copter. We want to express the requirement of reliably controlling the flight process which is considered as safety-critical, while at the same time being able to process images from a camera as good as possible, thus representing a performance-critical objective. Usually, these trade-offs are estimated by performing an off-line analysis of the safety-critical runnable set and then deducing the remaining utilisation bound that can be allocated to the performance-critical runnables. If we assume that these execution times are only fully utilized in a worst-case scenario, we potentially limit our options for the performance-critical part of the system. With the proposed dynamic approach however, we are able to define an optimistic state where a lower, estimated execution time of the safety-critical runnables is taken into consideration. When the system detects a high computational demand for the safety-critical runnables due ~ to tasks exceeding their C(PERF) budget, the resulting criticality switch will change the performance-critical runnable behaviour (which we call degraded mode), such that it processes the images in a lower quality, resulting in a reduced computational effort while still being able to meet the desired deadline.
response time: 135.184 ms ν0 = 93.31 ms ~ rsensor (PERF) C
response time: 84.356 ms ν0 = 58.05 ms
robj ralt rcontrol rsensor 166
168
170
172
296
298
300
302
332 334
336
338
340
416
418
ms
Fig. 4. The increase of the system criticality at 296.78 ms causes an execution mode switch of robj , resulting in a degraded mode run for the next period and a reduced response time.
TABLE I P ROPERTIES OF THE SAFETY- AND PERFORMANCE - CRITICAL RUNNABLES . T (µs) rsensor rcontrol ralt
2000 2000 30 000
Distribution (µs) µ σ 557.0 57.5 3.1
139.250 14.375 0.775
~ i ) (µs) C(L PERF SAFETY 674.19 69.60 3.75
PERF robj
166 670
–
–
1114.0 115.0 6.2
ν0 (µs) SAFETY
93 310.00
58 050.0
In the evaluation setup, the system is partitioned into four runnables, as depicted in Fig. 2. Runnables rsensor and rcontrol perform flight sensor data reads and execute the necessary control steps. ralt is used to set the altitude value of the quadrocopter. Two shared objects are used to model the communication between the three runnables. The runnables rsensor,control,alt are categorized as safety-critical, because they are essential for a reliable flight behaviour. robj implements the object detection algorithm and is assigned the PERF criticality. As shown in Fig. 2, we map the safety- and performance-critical runnables to dedicated task containers. Furthermore, we statically schedule the runnables (rsensor < rcontrol < ralt ) and ignore any access delays of the shared objects. We assume that the system designer has already statically analysed the WCET of the safety-critical runnables. To demonstrate the applicability of our approach, we generate randomized execution times dynamically using a normal distribution (cf. Listing 1, line 19). This allows us derive lower, average execution times from the analysed WCETs. The normal distribution was configured such that the probability of reaching the WCET is practically impossible (≤ 1h) by setting σ = µ8 . ~ was then defined to cover The computation time vector C up to 95% (1.6649σ) of the occurring execution times below ~ ~ C(PERF). The maximum execution time C(SAFETY) was set to the statically analysed WCET of the runnable. The resulting computation time vectors of the safety-critical runnables are listed in Tab. I. The execution trace vectors ξ~ of the safety-
TABLE II C OMPARISON OF THE SYSTEM UTILISATION IN DYNAMIC AND STATIC MODE , AVERAGED ACROSS 100 SIMULATION RUNS . mode dynamic static
#degraded
#high−quality
system utilisation (%)
13(±3) 30
17(±3) 0
86.70 (±0.14) 65.54 (±0.16)
critical runnables are dynamically generated based on these values, as shown in Listing 1 and are the same for both criticality levels. The execution time of the object detection is modelled as a simple execution trace containing only one computation node ξ~ (Li ) = hν0 i, where ν0 is estimated in a simulative manner using different image quality settings. Additional evaluations indicated that a frame rate of six frames per second is the minimum value for accurately detecting an object, leading to a maximum period of 166.67 ms for detecting an object in each frame. As a reference for an upper bound on ν0 , the expected system utilisation caused by the safety-critical task container was calculated using the statically analysed WCETs, yielding 63.95 ms (38.37 %) of available computation time within each frame period. Assuming that the safety-critical runnable execution times are within the 95 % quantile, as specified above, the available computation time for each frame increases to 94 ms (56.40 %). Based on these values, two quality settings regarding the object detection were chosen. ~ The high-quality mode ξ(PERF) features a total computation time of ν0 = 93.31 ms per frame for an image the size of ~ 460×320 pixels, while in the degraded mode ξ(SAFETY), the algorithm will process a 300 × 200 image in ν0 = 58.05 ms. An overview of the safety- and performance-critical runnable configurations is given in Tab. I. Five seconds were then simulated, allowing a total processing of 30 frames with the object detection algorithm. The RTOS model was configured to increase the system’s ~ i (PERF) of any safety-critical criticality level as soon as C runnable has been consumed. After ten consecutive periods ~ i (PERF), the criticality mode with an execution time below C was decreased again. The number of degraded and high-quality execution traces is depicted in Tab. II. In a reference simula-
tion, where the simulation was set up to always execute the degraded mode of the object detection, we observe an overall utilisation of 65.54 %. By specifying additional criticalitydependant execution traces, it is possible to run the object detection algorithm in a high quality mode for more than half of the simulated periods (17 of 30 times, averaged over 100 simulation runs). The overall system utilisation thus increases by 75.6 % to a total of 86.7 %. Fig. 4 shows an excerpt of the trace generated from the simulation. At 166.67 ms, robj starts the object detection in the high-quality mode, resulting in a response time of 135.184 ms. ~ At 296.78 ms, rsensor exceeds its C(PERF) execution time and the system increases the criticality of the system. Starting with the next period at 333.34 ms, robj now executes in the degraded mode and executes the object detection with a response time time of 84.356 ms.
[4]
[5] [6]
[7] [8]
V. C ONCLUSION & O UTLOOK We have presented a mixed-criticality system model capable of expressing criticality-dependant execution times and dynamic execution modes. To support the computation refinement, an RTOS model was proposed which is able to monitor the task execution behaviour and change the system’s criticality level according to the dynamic behaviour of the system. An evaluation of a quadrocopter use-case consisting of a safety-critical flight application and a performance-critical video-based object detection demonstrated the applicability of our approach. By monitoring the system behaviour and dynamically switching between multiple execution modes, the object detection algorithm was able to run in a high-quality mode for more than 50% of the time. In the future, we want to extend the system model to support communication refinement regarding the estimation of shared resource contention and communication overhead in multi-core scenarios. In particular, we want to remove the current mapping limitation and offer semantics for mapping shared objects on shared memory components or dedicated hardware blocks. Additionally, we plan on including the ability to express communication between criticality levels. Finally, we would like to evaluate the accuracy of our resource models by providing an implementation of the proposed components on a target platform. ACKNOWLEDGMENTS This work has been supported by the EMC2 collaborative project (ARTEMIS, grant agreement 01IS14002R), funded by the German BMBF.
[9] [10]
[11] [12]
[13]
[14]
[15] [16] [17]
[18]
R EFERENCES [1] S. Baruah and S. Vestal, “Schedulability analysis of sporadic tasks with multiple criticality specifications,” in Euromicro Conference on Real-Time Systems (ECRTS). IEEE, Jul. 2008, pp. 147–155. [2] S. Baruah, A. Burns, and R. I. Davis, “An extended fixed priority scheme for mixed criticality systems,” in Workshop on RealTime Mixed Criticality Systems (ReTiMics), 2013. [3] S. Baruah, V. Bonifaci, G. D’angelo, H. Li, A. MarchettiSpaccamela, S. Van Der Ster, and L. Stougie, “Preemptive
[19]
[20]
uniprocessor scheduling of mixed-criticality sporadic task systems,” Journal of the ACM, vol. 62, no. 2, pp. 1–33, May 2015. S. K. Baruah, V. Bonifaci, G. D´Angelo, A. MarchettiSpaccamela, S. Ster, and L. Stougie, “Mixed-criticality scheduling of sporadic task systems,” Algorithms – ESA, vol. 6942, pp. 555–566, 2011. S. Baruah, A. Burns, and R. Davis, “Response-time analysis for mixed criticality systems,” in Proc. 32th IEEE Intl. Real-Time Systems Symposium (RTSS). IEEE, Nov. 2011, pp. 34–43. O. Bringmann, W. Ecker, A. Gerstlauer, A. Goyal, D. MuellerGritschneder, P. Sasidharan, and S. Singh, “The next generation of virtual prototyping: Ultra-fast yet accurate simulation of HW/SW systems,” in Proc. 2015 Design, Automation & Test in Europe (DATE), 2015, pp. 1698–1707. A. Burns and R. Davis, “Mixed criticality systems: A review,” Department of Computer Science, University of York, York, Technical Report, 2014. G. Giannopoulou, N. Stoimenov, P. Huang, and L. Thiele, “Scheduling of mixed-criticality applications on resourcesharing multicore systems,” in Proc. Int. Conf. on Embedded Software (EMSOFT). IEEE, Sep. 2013, pp. 1–15. ——, “Mapping mixed-criticality applications on multi-core architectures,” in Proc. 2014 Design, Automation & Test in Europe (DATE), 2014, pp. 1–6. K. Goossens, A. B. Nejad, A. Nelson, S. Sinha, A. Azevedo, K. Chandrasekar, M. D. Gomony, S. Goossens, M. Koedam, Y. Li, D. Mirzoyan, and A. Molnos, “Virtual execution platforms for mixed-time-criticality systems: the CompSOC architecture and design flow,” ACM SIGBED, vol. 10, no. 3, pp. 23–34, Oct. 2013. K. Grüttner, A. Herrholz, P. A. Hartmann, A. Schallenberg, and C. Brunzema, OSSS – A Library for Synthesisable System Level Models in SystemC(TM) – The OSSS 2.2.0 Manual, Sep. 2008. P. A. Hartmann, P. Reinkemeier, H. Kleen, and W. Nebel, “Modeling of embedded software multitasking in SystemC/OSSS,” in Languages for Embedded Systems and their Applications, M. Radetzki, Ed., 2009, vol. 36, pp. 213–226. P. A. Hartmann, K. Grüttner, A. Rettberg, and I. Podolski, “Distributed resource-aware scheduling for multi-core architectures with SystemC,” in Proc. 7th IFIP Conference on Distributed and Parallel Embedded Systems (DIPES), Sep. 2010. J. L. Herman, C. J. Kenna, M. S. Mollison, J. H. Anderson, and D. M. Johnson, “RTOS support for multicore mixed-criticality systems,” in 18th Real-Time and Embedded Technology and Applications Symposium (RTAS), Apr. 2012, pp. 197–208. H. Li and S. Baruah, “Global mixed-criticality scheduling on multiprocessors,” in Proc. 24th Euromicro Conf. on Real-Time Systems (ECRTS), Jul. 2012, pp. 166–175. C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogramming in a hard-real-time environment,” Journal of the ACM, vol. 20, no. 1, pp. 46–61, 1973. M. S. Mollison, J. P. Erickson, J. H. Anderson, S. K. Baruah, and J. a. Scoredos, “Mixed-criticality real-time scheduling for multicore systems,” 10th IEEE Int. Conf. on Computer and Information Technology, pp. 1864–1871, Jun. 2010. P. Razaghi and A. Gerstlauer, “Host-compiled multicore system simulation for early real-time performance evaluation,” ACM TECS, vol. 13, no. 5s, pp. 166:1–166:26, Dec. 2014. G. Schirner, A. Gerstlauer, and R. Dömer, “Fast and accurate processor models for efficient MPSoC design,” Trans. on Design Automation of Electronic Systems, vol. 15, no. 2, pp. 10:1– 10:26, Mar. 2010. S. Vestal, “Preemptive scheduling of multi-criticality systems with varying degrees of execution time assurance,” in 28th IEEE Int. Real-Time Systems Symposium (RTSS). IEEE, Dec. 2007, pp. 239–243.
