1 Introduction

Vehicles are transforming into antenna farms that connect to other vehicles and infrastructures through wireless media. The advancements in artificial intelligence, machine learning, deep learning, advanced driver assistance systems (ADAS) and autonomous drive (AD) make travelling an incredible experience. These improvements are proposed and designed by diverse industrial players and thus result in transitioning vehicle architecture from federated architecture to centralized service-oriented architecture (SOA). Developers and freelancers are developing new connectivity solutions, applications, features, machine learning algorithms and analytic software for vehicle platforms. This modularized SOA and over-the-air (OTA) updates bring the term ‘app’ to automotive software just as in mobile application development. This state-of-the-art transition overlaps the roles of software vendors, electronic control unit suppliers (Tier1s) and original equipment manufactures (OEMs). In this metamorphism, vendors go beyond the development of features, apps & software stacks, Tier1s invent features & apps and OEMs originate platforms, operating systems (OS), hardware abstractions & signal processing.

These new paradigm shifts along with homogeneous/heterogeneous multi-core controllers, that introduce changes in scheduling mechanisms, task models, workload models and resource models of mixed criticality (MC) OS. These MC systems with their impending needs of security, safety and certification in automotive applications bring out additional challenges to system designers and integrators. Ernst et al [1] observed the gap between the objectives, practice and directions of research community and industry. The upcoming research topics in automotive domain include MC systems specifications, architectures, platforms and designs along with security/safety requirements and faults [1]. Task models play an important role in addressing most of these challenges in MC systems. The existing task models in literature concentrate on specific aspects of study such as criticality, timing, resource usage and dynamic behaviour. These task models lack the completeness required for MC automotive applications and require consolidation of multiple perspectives. A comprehensive analysis of task parameters which accommodates all task parameters is required to address concerns in automotive MC systems. Considering these needs, this paper offers a comprehensive task parameter aggregator named TaskMUSTER to address this. The major contributions of this paper are summarized as follows:

  1. [1]

    An exhaustive literature survey to provide increased awareness pertaining to resource & communication, energy, fault tolerance, mode change, OS overhead and parallel processing for real-world schedulability analysis of automotive controlling domain.

  2. [2]

    A task parameter aggregator and its Backus-Naur form (BNF) grammar that contains super-set of task parameters existing in MC automotive systems research and usability of these parameters as per nature of study and usage scenario.

The structure of the paper is as follows: Section 2 puts forth an overview of automotive standards, communication protocols and software stacks prevailing in uni-core and multi-core automotive MC systems. Section 3 presents the literature survey on automotive MC systems and summarizes task models observed in existing literature for uni-core and multi-core MC systems. Section 4 proposes TaskMUSTER - a new task model for automotive multi-core MC systems with a set of widely used parameters for automotive controlling domain applications. Section 5 describes BNF grammar and railroad diagram of TaskMUSTER with usage scenarios of each attributes. Section 6 provides experimental evaluation of TaskMUSTER with - Automotive Safety Integrity Level (ASIL) B vehicle wake-up controller application and objective function based comparison with task models existing in literature. Section 7 winds up the work with concluding remarks and future directions.

2 Automotive mixed criticality systems

Electrical and electronic (E/E) architecture in automotive systems is transitioning from a federated architecture to domain controller based or integrated architecture. E/E architecture is in the process of transitioning to a software driven dynamic centralized architecture. This transition brings out huge challenges and opportunities in automotive MC controlling domains [2]. The four domains of automotive systems - namely, telematics & infotainment, power train & hybrid, chassis & safety and body - can be grouped as controlling domain and non-controlling domain. The former group consists of power train & hybrid, chassis & safety and body ECUs, where control systems applications are involved. The latter group substitutes the comfort features that does not have control systems applications and consists of telematics & infotainment ECUs.

Hundreds of ECUs in an automotive makes it a distributed heterogeneous communication and computing system. Communication protocols used extensively in automotive MC controlling systems are Controller Area Network (CAN), CAN Flexible Data-rate (CANFD), FlexRay and Switched Ethernet Precision Time Protocol (PTP). The message passing mechanism through communication medium introduces blocking time for tasks that consume data/control information from communication bus. This mandates the consideration of inter-core/intra-core blocking time as task parameter with respect to message passing.

In automotive industry, there is a tremendous push to integrate multi-core systems due to their isolation properties and to mitigate vehicle’s increasing computing needs. Traditionally, automotive ECUs were uni-core and it continues to be used for non-criticality/limited-function ECUs. For example, car parking sensor ECU uses single-core. But critical ECUs like brake systems or steering systems require complex functionalities and multi-core architecture. With the integration of multi-core to automotive systems, task model requires adaptations to incorporate the multi-core related system/task parameters for shared resources usage and core migration.

The integrated/software driven centralized multi-core architectures and functional safety ISO26262 standards pace the adaptation of MC to the automotive industry. But Esper et al [3] noticed that there is a mismatch in the interpretation of system criticality between academia and industry. In academic publications, criticality refers to the modes of execution and the switching of mode denotes the increase or decrease in system criticality level. However, in industry, criticality refers to the level of assurance i.e. design assurance level of safety critical applications. The risk classification scheme of ISO26262 [4] comprises of 4 ASILs from A to D with rising levels of importance. These criticality levels are used in the task model to signify the criticality of a MC System. The standard models followed are (a) increase in worst case execution time (WCET) [5] and (b) decrease in periodicity with increase in criticality [6]. ISO26262 is one of the highly recommended standards for all controlling domain ECUs in automotive systems. Few other existing and emerging automotive standards are ISO14229 unified diagnostic services, ISO14230 keyword protocols, ISO15031 on-board diagnostic, SAE vehicle electrification standards, ISO/ SAE21434 cyber security etc. These standards mandate system, software, energy, fault tolerant, resource and communication considerations to automotive systems which can be achieved by introducing additional task parameters to the task model. This may help in obtaining more realistic WCET and schedulability analysis for these systems. Few examples of those task parameters are criticality, power estimations, fault tolerant replication and distribution.

Open systems and their interfaces for the electronics in Motor Vehicles (OSEK/ISO17356) is an open standard published by automotive consortium for communication, network management and OS used in automotive applications.

The consortium Classic AUTomotive Open System ARchitecture (AUTOSAR) has taken it further with highly configurable software stacks consisting of basic software modules (BSWs), micro-controller abstraction layer (MCAL), run time environment and software components. Run time environment works as a virtual functional bus and facilitates exchange of information within ECU and between ECUs. The state-of-the-art automotive use cases such as highly automated driving, V2V, V2I, infotainment and digital cockpit triggers the development of a new adaptive AUTOSAR platform [7].

Controlling domain uses AUTOSAR as its operating system while non-controlling domain deploys general purpose OS like customized Linux variants, Adaptive AUTOSAR. Automotive software stacks and specifications [7, 8] contain knowledge on automotive task model for the practitioners and academicians on automotive domain. However, there is a requirement to incorporate mixed criticality system characteristics and task models. This work is an attempt to fill this gap.

3 Mixed criticality task models: literature survey

The literature review about the task model is thematically split into segments based on resource & communication model, energy model, fault tolerance, mode change, operating system (OS) overhead and parallel processing.

Ernst et al [1] provides a detailed literature on MC specification, architectures, and design processes for handling application and platform dynamics and change and challenges arising from the combination of security and safety requirements and faults.

3.1 Basic task models

The first MC task model was proposed by Vestal in 2007. Vestal’s [9] model observed the importance of conservative verification process for higher criticality tasks. This model was generalized in [10] with 4-tuple with elements period or minimum inter-arrival interval (T), deadline (D), computation time vector (C) and criticality level (L). A variant of this basic task model was proposed by Baruah and Chattopadhyay [6] where instead of computation time, period is represented as a vector. Few task models in literature represent both period and computation time as vectors [11].

3.2 Directed acyclic graphs

An alternative representation of task model prevailing in MC domain is Directed Acyclic Graphs (DAG). The usage of graph based task models in MC systems is discussed in [12]. It is useful to indicate data flow between dependent tasks of any criticality levels and control flow between same criticality level [13]. In this model, tasks are represented by vertices and dependencies are represented by directed edges. Ekberg et al [14], represented WCET/relative deadline/scenario of a job as vertices and periodicity as edges.

3.3 Distributed shared resources

Vehicles are distributed heterogeneous communication and computation platforms. There is a need for strict timing adherence, shared resource usage, resource synchronization, isolation and dynamic scheduling. The consideration of shared resources including communication media and their blocking times is a contemporary research area. Hassan and Patel [15] proposed Carb, an improvised bus arbiter. They also provided a task model that incorporates global and local shared resources. Nair et al [16] extended the basic sporadic model to include shared resources and their blocking times. They included additional parameters for cache misses and task/core/system level interference. Han et al [17] elaborated the usage of spin locks in AUTOSAR and proposed MC resource based analysis to achieve deterministic shared resource usage.

3.4 Communication protocols

Message passing using communication protocols is an alternative to shared memory to transfer data across cores/controller/ECUs in a multi-core automotive environment. CAN [18] is the defacto standard in automotive applications. Nager et al [19] provided a novel scheduling policy where higher criticality CAN messages were given higher priority at higher CAN bus load. FlexRay was introduced as an alternative to CAN for brake-by-wire and steer-by-wire automotive applications. Although FlexRay has been addressed extensively in literature [20], the future of FlexRay continues to dwindle due to its complex hardware requirements and global time stamped scheduling policies. By exploiting IEEE 1588 PTP, Switched Ethernet protocol is expected to grow exponentially in automotive domain for time critical applications and for applications with higher data volume transfer. Cros et al [21] integrated criticality with PTP and proposed a criticality change protocol for switched ethernet networks.

3.5 Energy management

Automotive systems have better energy reserve than hand-held devices. But it has complex critical features and energy demands. This motivates the need of energy management mechanisms in automotive MC systems. To address energy management, Awan et al [22] extended the basic task model with an energy consumption vector. Asyaban et al [23] put forward a probabilistic scheduling mechanism for a battery less dual criticality uni-core system. The task model was expanded with two additional parameters, one for power consumption and the other for success ratio constraint.

3.6 Fault tolerance

In automotive systems, fault tolerance aids to carry on operations even during fail/fail-safe/fail-secure/degrade modes of a system. Pathan et al [24] added three interrelated design constraints - honouring deadline, fault tolerance execution with backups and certification challenges. Thekkilakattil et al [25] in their work on fault tolerant MC scheduling, supplemented the basic task model with tuples for replication and distribution. Guo et al [26] augmented high criticality (HC) tasks with a failure probability parameter. Farrall et al [27] considered acceptance criteria, spatial and timing protection, fault isolation and middleware reconfiguration in AUTOSAR MC systems.

3.7 Mode switching & quality of service

Improved quality of service (QoS) in MC systems is achieved by carefully selecting the jobs to be dropped or by delaying their execution. For MC schedulability analysis, the parameters of mode switching needs to be considered. Fleming and Burns [28] extended Baruah and Chattopadhyay [6] with an importance parameter to decide on which job to drop during a mode change. To improve schedulability of non-critical tasks, Jan et al [29] added importance level and stretching factor to low criticality (LC) tasks. An elastic task model was presented in [29]

to accommodate more number of LC jobs. This was achieved by stretching the period of LC jobs. Evripidou [30] considered parameters such as context switching and priority level to achieve tighter upper bound and maximize QoS during mode change. Zhao et al [31] incorporated resource usage with nominal/active priority and used this information to make decisions during a mode change.

3.8 Parallel processing

Increased number of cores per chip, computational needs of systems and mixed criticality features demand parallel processing capabilities. There is a strong link between parallel processing and MCS. There has been potential research on parallel tasks and MCS [32,33,34].

In Gill et al [32], core and virtual deadline assignment of each task was evaluated for improving schedulability. Agrawal and Baruah [33] carried out task characterization for schedulability of parallel tasks by measuring WCET under different scenarios.

To obtain a practical schedulability analysis, a comprehensive task model is required with the inclusion of all finer task parameters. TaskMUSTER is an attempt to provide a comprehensive analysis of task parameters for automotive MC systems in terms of resource & communication, energy, fault tolerance, mode change, OS overhead and parallel processing. TaskMUSTER also includes system parameters required for automotive MC controlling domain.

4 Task parameters for TaskMUSTER

Task parameters, OS features and schedulability analysis of controlling and non-controlling domains differ. For instance, controlling domain features include periodic/aperiodic/sporadic tasks invocation, shared resource handling, message passing mechanisms and timing protection. OS for controlling domain should have efficient real time (RT) properties. These OSs need to work with small memory footprints efficiently. Non-controlling domain needs to handle high volume data. Along with tasks, it manages memory and graphical user interfaces. The aim of TaskMUSTER is for performing realistic schedulability analysis with blocking and other overheads appearing during the execution, such that none of the HC tasks miss their deadlines. This work concentrates on identifying task parameters for automotive controlling domain and helps in estimating realistic bounds of response time with blocking and other overheads during analysis phase itself. It is possible to configure sufficient LC tasks, achieve practical resource utilization, handle faulty scenarios etc. This section consolidates a set of task parameters required for typical automotive controlling domain applications.

4.1 Basic mixed criticality task parameters

The controlling domain of MC automotive systems consist of periodic, aperiodic and sporadic tasks with differing criticality levels/ASILs that are implemented in homogeneous or heterogeneous multi-core processors. The task parameters differ based on task type, usage scenario and various aspects of schedulability analysis. Table 1 provides the basic set of task parameters for MC automotive applications.

Table 1 Basic task parameters of MC automotive applications.
Full size table

Irrespective of the task types, release time and computation time are basic task parameters. For periodic tasks, periodicity and alive monitoring interval are parameters whereas for sporadic tasks, minimum inter-arrival time and deadline monitoring are parameters. ASIL levels A to D are used to represent criticality levels of each controlling domain task. Vector type task parameters indicate varying values based on criticality levels and the scalar type parameters indicate the same value across criticality levels. The parameters T or C can be configured as scalar or vector based on the design of criticality mode change. If the criticality mode change is activated by increase in computing time [5, 35, 36], then C is represented as a vector and T is represented as a scalar. If the criticality mode change is based on increase in frequency of events [6], then T is represented as a vector and C is represented as a scalar. There exist task models where both T & C are regarded as vectors [11].

The vector sizes for T, D & C are as per number of criticality levels based on respective safety standards. In case of automotive applications, vector size can be up-to 4 as per ASIL ISO26262 [4]. For example, the size of computation time vector is 3 for an ASIL C application. If 3 tasks \(\tau _C\), \(\tau _B\) and \(\tau _A\) are considered with high, medium and low criticality levels respectively, then the computation time values for \(\tau _C\), \(\tau _B\) and \(\tau _A\) are - C\(_{\tau _C}\)(100, 200, 300), C\(_{\tau _B}\)(100, 200, -) and C\(_{\tau _A}\)(100, -, -). In practical scenario, low criticality jobs are dropped or delayed to accommodate the system criticality mode change that mandates additional safety validation of high criticality jobs, in turn it increases computation time of the high criticality jobs while executing in higher system criticality modes.

4.2 Resource related mixed criticality task parameters

Table 2 Resource related mixed criticality task parameters for MC automotive applications.
Full size table

Effective and optimized usage of constraint resources improve the performance and correctness of systems. Modelling of RT MC systems with constrained resources require careful selection of task parameters. The optimized usage of these resources brings the system to a safe state of functioning. A few important constraint resources are cache memories, IPC over UART/CAN/SPI/Ethernet, message boxes, shared memories, pipes, signals, displays, networked devices over CAN/FlexRay/Ethernet, locks, I/O ports, motors, interrupt controllers, communication buses etc. Automotive domain uses shared memory and message passing for data sharing within ECU. To have deterministic timing analysis in distributed systems, the contemplation of memory access timing is required, which requires special data management mechanisms. The impact of shared accesses on unified memory, non uniform memory and no remote memory and the impact of stack and heap allocation is mandatory to consider while arriving at deterministic timing models of MC systems. Pellizzoni et al [38] measured the effect of memory access interference on WCET. Ward et al [39] brought the importance of predictive computation in safety critical needs. Table 2 provides task parameters related to resource usage. It consists of number of memory accesses and blocking time due to resources. M1 and M2 indicate the worst case number of L1 and L2 cache misses respectively of a periodic/sporadic job when it executes without preemption. In [37], Burns and Davis incorporated criticality specific blocking times for resource synchronization and deadlock avoidance. Task parameter b indicates the inter-core-interference in multi-core systems or task-interference due to (a) resource locking & communication latency (b) peripheral bus and IPC, (c) I/O blocking time and (d) blocking due to low priority tasks. The task parameter B indicates the intra-core-interference in multi-core systems. Worst case execution time (E) indicates CPU computation time and resource access time of a periodic/sporadic job. In Hassan and Patel [15], they referred to inter-task interference, access latency and inter/intra-class scheduling latency. In AUTOSAR [8], the budget parameters for timing, memory and locks were used for invoking the protection hook and they provided mechanisms for protection and recovery. For example, if job crosses the timing budget Tb, the timing protection hooks invocation takes place [8].

4.3 Energy related mixed citicality task parameters

Huang et al [40] postulated energy efficiency needs in embedded systems for the optimum usage of battery power and efficient thermal management with increasing computing volume. Though battery power and space are not limiting factors in automotives, energy efficient techniques help in adding more functionalities and features in system.

Table 3 Energy related mixed criticality task parameters of MC automotive applications.
Full size table

Ever demanding need of fuel efficiency, irrespective of the type of the fuel i.e electric/hybrid/petrol/diesel, automotive applications mandate to follow the guidelines of size, weight, energy, power and time (SWEPT). The energy efficient design considerations include procrastination and energy optimization techniques. The energy optimization techniques can be categorized as dynamic-voltage-and-frequency scaling (DVFS) and dynamic-power-management (DPM).

Taherin et al [41] presented DVFS schemes and compared pros and cons of their approach with respect to [40]. To manage QoS in MC systems, Juhász and Jantsch [42] discussed an effective power management mechanism. Narayana et al [43] observed the strife between safety and energy optimization. Table 3 provides the list of task parameters required for energy modelling in automotive applications. The task parameters include power consumption and it constitutes static power - leakage power, standby power - and dynamic power. The parameter success ratio constraint indicates the uncertainty in power management. These parameters are useful in implementing energy efficient task allocation schemes including various procrastination techniques.

4.4 Fault tolerance related mixed criticality task parameters

With the advent of highly autonomous vehicles where driving is detached from human and is handled by vehicles partially or completely, vehicles should be highly reliable, available and fault tolerant. It is mandated to work in no-fail or fail-safe modes of operations. Sundar et al [44] postulated a context-aware mixed criticality system model having task level degraded budgets, i.e. normal and safe budgets to handle controlled system degradation. The complexity and criticality of automotive applications aim safety analyses such as failure mode effects & criticality analysis, fault tree analysis, critical path analysis and freedom from interference analysis [45]. The tighter upper bound on worst case timing without system failure is a critical measure. MC system research concentrates on having higher computing power utilization with proper spatial, temporal and fault isolation. The fault has to be contained within a specific region without propagation and that region has to be isolated for the smooth functioning of the system. In fault tolerant MCS, tasks can be replicated or re-executed in order to enhance the reliability.

Table 4 Fault tolerance related mixed criticality task parameters of MC automotive applications.
Full size table

Table 4 tabulates fault tolerance related task parameters for automotive controlling domain applications. Check pointing and core migration requires the knowledge of available replicas (REP) and core distribution (Dist) parameters. Also a robust MC system has the luxury to skip few non executing HC jobs or allow overruns. Robustness flag (\(Rbst_{flag}\)) provides this feasibility without hampering the progress and successful functioning of MC systems. Choi et al [47] carried out a tighter upper bound on response times having a tolerance threshold number of faults and proposed task parameters such as reliability constraint (R), fault detection overhead (FD), roll-back overhead (RB) and voting (V) parameters contribute to achieve fault tolerance in critical applications.

4.5 Mode change related mixed criticality task parameters

Various mode change schemes are being researched extensively in MC systems [48]. It include mode change detection mechanisms, phased removal of dropping/delaying jobs, resuming tasks in critical mode and other QoS improvement schemes. The detection of mode change is triggered by either execution extension of jobs or frequent appearing of jobs than expected [37]. QoS improvement schemes after a mode change is achieved by either of the following: delayed dropping of LC jobs [49], retained importance jobs only [28] or resumed a new set of high importance jobs [50]. Gu et al [51] proposed dynamic budget management and budget reclaim schemes to avoid re-occurrence of mode-switch.

Ramanathan et al [52] explored semi-partitioned scheduling model and proposed LC tasks core migration strategy to improve QoS in HC mode.

Table 5 Mode change related mixed criticality task parameters of MC automotive applications.
Full size table

Mode change related task parameters of MC automotive applications are tabulated in table 5. The task parameter importance I is used to improve QoS by dropping LC jobs in an ordered fashion [28]. Parameter I can also be used to improve QoS by dropping less important tasks, instead of LC tasks and resuming with high important tasks after a criticality mode change; i.e critical jobs that triggers the mode switch can be different from important jobs that resumed after a mode switch [50]. The priority vectors include static fixed/nominal priority P of HC tasks [30, 31] and dynamic active priority \(_{p}\) for LC tasks [31]. These priority vectors enhances QoS by having an adaptive scheduling scheme using dynamically switching priority of LC jobs. The stretching factor parameter S\(_{factor}\) for LC jobs allows to accommodate additional LC jobs by switching to higher periodicity after a criticality mode change.

4.6 OS overhead related mixed criticality task parameters

A reasonable timing budget is determined through the assessment of task execution time, recovery time and overheads. Table 6 lists out timing related task parameters of MC automotive applications.

Table 6 OS Overhead related task Parameters of MC automotive applications.
Full size table

The list of timing overheads include intentional stop/sleep, context switching, page faults, ready queue waiting, jitter in job arrival, interrupt service routine execution, interrupt latency, interrupt suppression time, task blocking and I/O blocking. I/O blocking overhead includes the I/O processing time, queuing time to access the I/O device/bus and bus acquiring time.

4.7 Parallel processing related mixed criticality task parameters

With the introduction of autonomous drive and ADAS to automotive systems, rapid processing of visual images is mandated. This requires enormous amount of parallel processing within the system including controlling domain ECUs. Table 7 lists a set of task parameters required for modelling parallel processing.

Table 7 Parallel processing related mixed criticality task parameters of MC automotive applications.
Full size table

Liu et al [56] put forward the sequence of job segments (J\(^1\), J\(^2\),..., J\(^{i}\)) to represent the task to perform the parallel processing across cores. Agrawal and Baruah [33] and Gill [32] supporting suggested work and span parameters for parallel segments of a task. Work represents cumulative WCET of all parallel segments of a task. This indicates WCET of a task while running in a single core/processor. Span represents the critical path of a task, i.e, the execution time of longest segment.

4.8 System level mixed criticality task parameters

The practical schedulability analysis of a system requires system level parameters. Table 8 provides specific set of attributes that focuses on system level parameters.

Table 8 System level task parameters of MC automotive applications.
Full size table

Number of cores Sys\(_{NumCore}\) in a system can be used by task allocation algorithms and job migration mechanisms. Current criticality mode is used for switching back and forth between modes to increase/decrease QoS by incorporating more/less LC jobs. Fail operational/passive count Sys\(_{NumFO}\) and fail robust/active count Sys\(_{NumFR}\) assist in keeping the system robust by allowing few overruns of HC jobs without hampering the correctness of the system [46]. Sys\(_{NumFO}\) denotes maximum number of overruns allowed for HC jobs. This is to improve QoS by allowing few overruns of HC jobs without hampering system progress or criticality mode change [46, 58]. Sys\(_{NumFR}\) denotes maximum number of overruns allowed for HC jobs by dropping few non-executing HC jobs. This is to improve QoS by allowing few overruns of HC jobs with their infrequent dropping without hampering system progress or criticality mode change [46]. Note that fail active count is greater than passive count i.e, Sys\(_{NumFR}\) \(\ge\) Sys\(_{NumFO}\). System physical state Sys\(_{PhysState}\) provides information on the different physical states of system to perform critical operations [57]. The Sys\(_{PhysState}\) holds changing system configuration that are affecting the schedulability. For example, distance between two moving vehicles and their relative speed. The task execution time of can be correlated with a physical state, i.e, execution of velocity monitoring depends on distance from moving vehicle ahead.

5 TaskMUSTER: Backus-Naur form grammar & usage scenarios

TaskMUSTER grammar consists of task model and system model as shown railroad diagram [59] in figure 1.

Figure 1
figure 1

BNF railroad diagram of TaskMUSTER.

Full size image
figure a

System model is used for elaborating system behaviour pattern based on environmental conditions like vehicle speed, number of cores in deployment platform and system reliability factors. Task model aggregates the task parameters required for profiling tasks in a system based on functional attributes. The tables 1 to 8 form a super set of task parameters and system parameters that can be used in automotive applications. For realistic schedulability, it is required to consider subset of practical parameters listed in these tables based on the purpose of study. For example, if resource impact on schedulability is to be analyzed, then resource related parameters need to be considered.

5.1 Task model

BNF grammar of task model consists of basic parameters and optional parameters. Figure 2 shows the railroad diagram of task model.

figure b

The basic parameters include Time Period (T), Deadline (D), Criticality(L) and Computation Time (C). Basic task model parameters shall be considered for basic schedulability analysis. One such example of task model proposed by Baruah et al [60] has modelled sporadic tasks as \(\tau\)j = {Tj, Dj, Lj; Cj}. This model does not consider the impact on resources, OS overhead and mode changes. Optional parameters are based on functional attributes related to resources, energy, fault tolerance, mode change, OS overhead and parallel processing.

Figure 2
figure 2

BNF railroad diagram of task model.

Full size image

5.1.1 Resource related task parameters

The railroad diagram of resource related parameters is shown in figure 3. It consists of resource type, number of memory misses, resource related timing parameters and budget parameters. Resource type includes specific resources and its number of instances. Number of memory misses include the number of L1, L2 and L3 cache misses. Budget is upper threshold parameter with respect to timing, memory and locks for timing protection, memory protection etc.

figure c

The grammar for resource timing include inter-core interference (B), intra-core/inter-task interference (b) and worst-case execution time (WCET). WCET of a computational task is the maximum duration the task could take to execute on a specific hardware platform which includes CPU computation time along with resource access time such as L1/L2/L3/Memory access time and I/O access time. Few examples of task models with resource related parameters are (i) Hassan and Patel [15] modelled tasks as \(\tau\)j = {Lj; Tj; Dj; Ej; bj; Bj; M1j} and (ii) Nair et al [16] modelled tasks as \(\tau\)j = {Lj; Rj; Tj; Dj; Ej; M1j; M2j; bj; Bj}. To analyze the effect of memory miss or to provide an optimized solution to honour deadline of HC jobs, parameters such as worst case number of L1/L2 cache misses (M1/M2) need to be considered [15, 16]. Offline or dynamic profiling of misses can be considered for predictive computation of critical tasks as well as for throttling the cache memory accesses for HC and LC jobs.

Figure 3
figure 3

BNF railroad diagram of resource parameters.

Full size image

5.1.2 Energy related task parameters

The railroad diagram of energy related task parameters are shown in figure 4.

figure d

Energy related task parameters can be grouped as power consumption (pow) and success ratio constraint (\(\alpha\)). The power consumption of a task includes static power (\(S_{pow}\)) and dynamic power (\(D_{pow}\)). Static power consists of leakage power (\(L_{pow}\)) consumed by transistors and standby power (\(Sby_{pow}\)) due to standby constant current from VDD to ground. Success ratio constraint (\(\alpha\)) is a probabilistic measure of energy to perform remaining jobs of the task. These parameters can be used for energy-aware/energy-efficient task scheduling and for implementing procrastination and other energy optimization techniques.

Figure 4
figure 4

BNF railroad diagram of energy parameters.

Full size image

5.1.3 Fault tolerance related task parameters usage

The railroad diagram of fault tolerance related task parameters are shown in figure 6.

figure e

The Parameters are failure probability (f), availability related parameters replication (Rep) and distribution (Dist), reliability related parameters and robust flag (\(Rbst_{flag}\)). The parameters replication (Rep) and Distribution (Dist) are used to specify number of replicated nodes and distribution scheme of replicas. The reliability related parameters are reliability constraint (R) and timing overhead like fault detection (FD), rollback (RB) and voting (V). Reliability constraint (R) indicates the constraints to achieve required reliability of the system. Some examples of reliability constraints are honouring deadline for all HC tasks, maximum number of faults permitted in a task and system level fail counts. Fault detection overhead (FD) indicates timing and resource overhead to detect the fault and roll-back overhead (RB) timing overhead for moving to last stored status, i.e checkpoint. Degree of replication (Rep) with an odd number larger than two allows to perform majority voting (V). For having high reliable system, Iacovelli et al [61] improvised the basic task model with an importance (I) parameter i.e, utility to re-assign the tasks to other cores, in case of core failures.

Figure 5
figure 5

BNF railroad diagram of fault tolerant parameters.

Full size image

5.1.4 Mode change related task parameters

The railroad diagram of mode change related task parameters are shown in figure 6.

figure f

The task parameters are importance (I), stretching factor (S factor) and priority information. Priority information consists of statically assigned fixed or nominal priority (P) and dynamically assigned active priority (p). The importance factor with dynamically changing active priority assist to control dropping of low criticality tasks. For example, when a high critical task overruns its budget, mode switching can be enabled. However to avoid a drastic QoS degradation, it is feasible to accommodate maximum possible LC jobs. The LC jobs need to be identified based on the importance factor and by dynamically increasing the priority of those jobs. Similarly, the decision to drop LC jobs can be either using the importance parameters (I) based on energy estimation of LC jobs (pow) or by jobs having higher success ratio constraint (\(\alpha\)). If any of the running LC jobs that are consuming shared resources (R\(_{type}\)) or resource blocking time increases for a HC job with dropping of any particular LC jobs, those LC jobs can be identified as high important LC jobs during the execution. QoS can be carried out by dropping or delaying LC jobs using task parameters like importance, mode management, energy consumption, resource blocking times or combination of these factors.

Figure 6
figure 6

BNF railroad diagram of mode change parameters.

Full size image

5.1.5 OS overhead related task parameters

The railroad diagram with respect to OS overhead related parameters is shown in figure 7.

figure g

It consists of timing overhead due to OS related parameters, interrupt related parameters and page fault penalty (pf). OS related timing parameters are context switch (cs), release time jitter (J) and ready queue waiting period (QW). Interrupt latency (\(I_{int}\)), interrupt suppression time (\(L_{int}\)) and interrupt execution time (\(E_{int}\)) contribute to interrupt related timing parameters. These parameters heavily depends on OS and instruction set architecture (ISA). The designers may need to consider few of these parameters for realistic timing profile of tasks scheduling. Davis et al [54] observed increase in switching cost between tasks of differing criticalities than of the same criticality. They proposed different context switch parameter values while performing schedulability analysis.

Figure 7
figure 7

BNF railroad diagram of OS overhead related parameters.

Full size image

5.1.6 Parallel processing related task parameters

In connected vehicles and autonomous driving systems, there is a requirement to perform complex computations within stipulated duration. This paradigm shift leads to the adoption of parallel processing into automotive domain. The railroad diagram for parallel processing related parameters is shown in figure 8. Ahmed Bhuiyan et al [32] and Gill et al [34] considered number of cores available for each task as a parameter. Ahmed Bhuiyan et al [34] considered number of cores required for each task while Gill et al [32] extended it as vector parameter with respect to criticality levels for facilitating job migration and core reclamation during the mode change.

figure h

The parallel processing parameters are Cumulative WCET (work), Critical Path (span) and CoresPerTask (). Cumulative WCET (work) is the sum of WCET of all parallel threads and it gives the total computing power required for a task while running in a single core without threading i.e, total duration of work. Critical path is the longest path duration of multiple segments i.e longest span of a task. These parameters give total duration and longest thread duration which makes it feasible to perform PERT analysis of tasks and efficient allocation tasks within available CoresPerTask ().

Figure 8
figure 8

BNF railroad diagram of parallel processing parameters.

Full size image

5.2 System level parameters

The railroad diagram for system model is shown in figure 9. Some of the system parameters are used for task profiling where as some others influence directly.

figure i

The NumOfCores (\(Sys_{NumCores}\)) parameter indicates the total number of cores in ECU and is used for task-to-core mapping. SysCriticalityMode (\(Sys_{CurMod}\)) parameter can be used for the implementation of mode switching. The scaling of passive (\(Sys_{NumFO}\)) and active (\(Sys_{NumFR}\)) fail counts at system level is used for estimating failure in time (FIT) rate and reliability of the system. Choi et al [47] provided a tighter upper bound on response times by keeping track of the number of faults that can be tolerated based on system fault count values. The system physical state (\(Sys_{PhysState}\)) parameter can be used to decide switching task configurations, schedule tables and system configurations. Few use cases of system physical state include controlling speed to maintain a safe distance while cruising by adaptive cruise control (ACC) ECU and collision avoidance steering by vehicle steering (AVS) ECU. It can also be used for capturing resource demands of ECUs like engine control module (ECM) and in vision camera ECUs. There is a strong correlation between physical state to resource demand like engine crankshaft rotation speed in ECM and field of view vision images in camera. System physical parameter can also be used to minimize the number of LC job drops without compromising schedulability of HC jobs.

Figure 9
figure 9

BNF Railroad diagram of system parameters.

Full size image

6 Wake-up controller: a case study

TaskMUSTER is analyzed using a case study on automotive wake-up controller application. Wake-up controller follows ASIL B and serves as an energy efficient startup automotive ECU especially for edge ECUs such as Infotainment/Telematic ECUs. This is a controlling domain ECU which provides the connectivity to vehicle network over CAN/CANFD.

6.1 Wake-up controller BNF grammar

BNF grammar for standalone wake-up controller is shown in figure 10. It consists of subset of system model parameters and task model parameters.

Figure 10
figure 10

BNF railroad diagram of wakeup controller.

Full size image

Task model parameters consists of all basic parameters where release time, time period and criticality are considered as scalar values. Other parameters like deadline and computation time are considered as vectors with size of 4 to represent values for each ASIL criticality levels A, B, C and D. System parameters NumofCores and SysCriticalityMode are considered. The parameters related to resources such as memory miss parameters - NumL1Misses, NumL2Misses and NumL3Misses, resource timing related parameters inter-core (B)/intra-core (b) interference times and WCET are modelled as part of the task model. WCET profiled for each task is based on computation time (C) and memory access time (MAT).

Resource overhead parameters such as context switch, release time jitter, interrupt related latency, suppression time and ISR execution time are also modelled as part of the task model. Number of cores in this case is configured as 2 cores as per chosen hardware. This parameter is considered for online profiling and task-to-core mapping. The parameter - current criticality mode - is used for transiting to new task configuration when criticality overrun occurs.

6.2 Wake-up controller configuration

The real world software implementation is carried out using preemptive OSEK specification version 2.2.2 RTOS and deployed in a dual core RENESAS RH850 controller with 80MHz clock.

The applicable task parameters related to basic, resource and OS Overhead from TaskMUSTER as shown in section 6.1 are considered in this analysis.

The system consists of 7 tasks and 2 interrupts. The tasks are Program Supervision (T_PS), On Off (T_OO), Inter-processor Communication (T_IPC), CAN Communication (T_CAN), Environmental Data Collection    (T_ENV), LIN Communication (T_LIN), and System Performance (T_SYS).

T_PS is the monitoring task that continuously verifies the successful invocation of every task in the system. T_OO task controls wake-up, sleep, start-up and shutdown operations of ECU. It also performs node monitoring to keep ECU alive if CAN communication is active. T_IPC is for inter-processor communication between redundant ECUs. T_CAN is used for transmitting and receiving CAN messages to the vehicle bus and it provides the states of other ECUs in the vehicle. T_ENV performs measurement of critical environment data such as temperature, current and voltage. It feeds this information to T_OO task to carryout ECU state transition. T_LIN is for LIN communication. T_SYS is used for stack monitoring and system performance measurements. T_PS is a high priority LC task. T_OO, T_IPC and T_CAN are moderate priority HC tasks. T_ENV is a low priority HC task. T_LIN and T_SYS are low priority LC tasks. Wake-up controller software also has two high priority HC interrupt tasks - DMA interrupt (T_DINT) for data transfer and CAN interrupt (T_CINT) for CAN message transfer. The tasks are statically partitioned into two groups and assigned to two different cores. The tasks T_OO, T_CAN and T_LIN are allocated to one core and the remaining tasks including interrupts are allocated to the other core. From the definition of EDF-VD schedulability [62], the estimated \(\lambda\) values(x1 and x2) of the task set for core1 and core2 is 0.74 to 0.91 and 0.78 to 0.96 respectively.

In this experiment \(\lambda\) is taken as 0.9 for both cores.

6.3 EDF-VD schedule in LC mode

The schedule produced by EDF-VD for the task set in LC mode is presented in figure 11. The scheduler assumes that all tasks are in-phase and only an active job of a task is available for schedule. Table 9 provides the detailed performance metrics while running in LC mode.

Table 9 Performance metrics in LC mode.
Full size table
Figure 11
figure 11

Schedule in LC mode.

Full size image

All jobs are scheduled using their virtual deadlines. In LC mode, the HC jobs’ use virtual deadline \(\le\) absolute deadline. As none of the HC jobs exceed their low criticality WCET (\(E_{low}\)) system completes its execution in low mode. The utilization is calculated using virtual deadlines. The task set is scheduled in both cores as the utilization is 85% in core1 and 92% in core2, which satisfies the schedulability criterion of EDF-VD in LC mode.

To measure the error margin with respect to real world implementations, the wake-up controller software implementation is carried out in dual core RH850 controller using OSEK OS 2.2.2. The response time of tasks in RH850 software is measured using stub code. It is observed that the measured response time is marginally lower than the worst case response time estimated by TaskMUSTER. In TaskMUSTER, the higher estimation of response time is due to the worst case consideration of blocking and other overheads. It is observed that the variation of response time with respect to actual implementation of RH850 controller is within 4% and 2% in LC mode for core1 and core2 respectively. Schedules produced by TaskMUSTER guarantees successful completion of all HC jobs without deadline miss. Ward et al [39] confirmed predictive and pessimistic computation for safety critical certification needs. As per ASIL ISO26262 part 6 and clause 7.4.13 [4], mandates an upper estimation of required resources including timing to accommodate safety criticality needs. The pessimistic response time and guaranteed HC job execution by TaskMUSTER justifies its deployment for safety certification needs in automotive controlling domain.

6.4 EDF-VD schedule in HC mode

The schedule of tasks in HC mode depicting mode change scenario is presented in figure 12. In HC mode, all jobs with ASIL B level successfully complete their executions at the cost of ASIL A jobs. Table 10 provides the detailed performance metrics in HC mode with EDF-VD as the scheduler.

At t = 151\(\mu\)s, the job of task T_OO exceeds its low WCET E\(_{low}\). The system level parameter Sys\(_{CurMod}\) is updated to HC mode. During this mode change, LC jobs (ASIL A) in both cores are dropped. The HC jobs continue to execute with their virtual deadlines same as absolute deadlines. The utilization is calculated with respect to absolute deadline in-case of HC tasks. Though the utilization is 102% and 101% for core1 and core2, the task sets are schedulable because of the dropping of the LC tasks. The task set is schedulable for HC tasks in both cores as the utilization is 88% in core1 and 65% in core2, which satisfies the schedulability criterion of EDF-VD in HC mode.

Figure 12
figure 12

Schedule in HC mode.

Full size image
Table 10 Performance metrics in HC mode.
Full size table

The error margin is measured with respect to real world implementation in dual core RH850 controller using OSEK OS 2.2.2. It is observed that the response time measured is marginally lower than the worst case response time estimated by TaskMUSTER. The positive error margin is due to the worst case consideration of blocking and overheads in HC mode, even after suspending LC low priority blocking jobs. TaskMUSTER guarantees the execution of all HC jobs in its high WCET with blocking. The results confirm the suitability of TaskMUSTER for safety certification purpose in HC mode.

6.5 TaskMUSTER usability analysis

A comparative analysis of TaskMUSTER with respect to basic task model [63] and burns blocking model [49] is carried out. The comparative objective function eq(6.5) aims to maximize successful completion of HC tasks h(w), where w is the number of HC tasks and accommodate as many number of LC tasks l(u), where u is number of LC tasks. If all the configured HC tasks complete without deadline miss, h(w) sum up to 1. Similarly, if all configured LC tasks complete successfully, l(u) sum up to have a maximum value of K where 0 \(\le\) K \(\le\) 1. K is a configurable parameter for the system designer based on the relative importance of LC tasks. Function g(x) is the sum of functions h(w) and l(u) where x = f(w,u), i.e x=w+u. If all the HC tasks and LC tasks complete without deadline miss, function g(x) will offer its maximum value which is 1+K.

$$\begin{aligned}& \mathop{{\text{maximize}}}\limits_{{w,u}}{g(x) = h(w)+ l(u) \;\; where \, x = w+u} \\ &\quad {\text {s.t.}} \sum _{i=1}^{N}h(w_i) \le 1 h(w_i)\quad {\left\{ \begin{array}{ll} 1/N, if \; all\; jobs \; of \; \\ \; \, HC \, task \; i \\ \; \, honoured \; deadline.\\ 0\; Otherwise \end{array}\right. } \\ &\qquad\sum _{j=1}^{M}l(u_j) \le K l(u_j)\quad \!{\left\{ \begin{array}{ll} K/M, if \; all\; jobs \; of \; \\ \; \, LC \, task \; j \\ \; \, honoured \; deadline.\\ 0\; Otherwise \end{array}\right. } \\ \end{aligned}$$
(1)

6.5.1 Comparative analysis on realistic schedule

In wake-up controller case study, we assume K as 0.2 to attach 20% weightage for completion of LC tasks. In wake-up controller, there are 4 HC tasks and 2 LC tasks configured in core 1. If all the jobs of an HC task complete without deadline miss, then h(w\(_i\)) is 0.25. Similarly if all the jobs of an LC task completes then l(u\(_j\)) is 0.1. In core2, there are 2 HC tasks and 1 LC task, hence h(w\(_i\)) is 0.5 and l(u\(_j\)) is 0.2. As all jobs complete successfully in core1 and core2, g(x) is 1.2 for both cores. With the utilization of 85% in core1 and 92% in core2 in LC mode, it is observed that g(x) is 1.2 for TaskMUSTER. The same results are obtained for Basic task model [63] and burns blocking model [49].

Figure 13
figure 13

Usability analysis in Core 1 for K = 0.2.

Full size image
Figure 14
figure 14

Usability analysis in Core 2 for K = 0.2.

Full size image

Further, the models are evaluated by enhancing the core utilization. In LC mode, with 95% utilization at core 1, TaskMUSTER accepts all HC tasks and only one LC task. This is because TaskMUSTER considers blocking and OS overheads for acceptance. In comparison, basic task model [63] does not consider any overheads whereas burns blocking model [49] considers only the blocking overhead.As a result, both these task models accept all tasks in both cores and fail to accommodate HC jobs during execution. Applying the objective function, TaskMUSTER offers g(x) of 1.1 in core1. Burns blocking model [49] fail to schedule one of the HC tasks in core1, resulting in g(x) of 0.95. Basic task model [63] fail to schedule one of the HC tasks and one of LC tasks in core1, resulting in g(x) of 0.85. At 96% core2 utilization, TaskMUSTER offers g(x) of 1.2 as all accepted tasks complete successfully. Burns blocking model [49] offers g(x) of 1.0 as both HC tasks complete honouring deadline and the basic task model [63] offers g(x) of 0.7 as one of the HC tasks misses its deadline.

If the utilization is extended to 100%, TaskMUSTER offers g(x) of 1, as core1 complete all HC tasks successfully, but fails to accommodate LC tasks in core1. Both basic task model [63] and burns blocking model [49] fail to schedule one of the HC tasks and one of the LC tasks in core 1 which results in g(x) of 0.85 for core 1. At 100% core2 utilization, TaskMUSTER offers g(x) of 1, as core2 completes all HC tasks successfully, but fails to accommodate LC tasks. Burns blocking model [49] fails to schedule one of the HC tasks in core2, resulting in g(x) of 0.7. The basic task model [63] fails to schedule one of the HC tasks and one of the LC tasks in core2, resulting in g(x) of 0.5. The graphs in figure 13 and figure 14 represent g(x) of TaskMUSTER, basic task model [63] and burns blocking model [49] with respect to utilization in core1 and core2 respectively.

If the utilization is extended beyond 100% by increasing the utilization of LC jobs, TaskMUSTER is aware of blocking and overheads, hence decide not to accommodate LC jobs to allow the successful completion of HC jobs, resulting g(x) of 1 in both cores. However, both basic task model [63] and burns blocking model [49] accommodate LC jobs and fails to honour the deadline of HC jobs, resulting in reduced g(x). TaskMUSTER drops g(x) only if the utilization of HC jobs increases beyond 100%. TaskMUSTER recommends a system configuration for successful completion of HC jobs during offline analysis itself by considering blocking and overheads.

6.5.2 Variation in g(x) with weightage of LC task(K)

The graph in figure 15 represents g(x) variation with K values 0 \(\le\) K \(\le\) 0.6 for 95% core1 utilization. The ratio of HC tasks to LC tasks in both cores is 2:1. Hence the tipping point of K is 0.5, after which LC tasks get higher g(x) value than HC task. The realistic value of K is \(\le\) 0.5 in this use case. The objective function g(x) of TaskMUSTER tends to achieve a minimum value of 1 by scheduling all configured HC tasks and 1 LC task, while Burns model completes 3 HC tasks along with 2 LC tasks, resulting in higher g(x) for K >0.5. Basic task model fails to complete 1 LC task and 1 HC task resulting in lower g(x) values. The feasibility and usability analyses confirm that TaskMUSTER recommended system configuration honour deadlines of all HC jobs and accommodates as many LC jobs as possible. The results justify the recommendation of TaskMUSTER as scalable task model based usage scenarios for certifiable safety criticality automotive controlling domain.

Figure 15
figure 15

g(x) variation with weightage of LC task(K) with 95% utilization in Core 1.

Full size image

7 Conclusion

TaskMUSTER is an attempt to consolidate task parameters with uniform nomenclature by considering resource & communication, mode change, OS overhead, energy, fault tolerance and parallel computing in MC automotive controlling domain. An exhaustive research on MC task parameters existing in literature is carried out. After synthesizing the state-of-the-art knowledge in the domain, the work proposes TaskMUSTER that consists of super set of task parameters considering all the required attributes for an MC automotive controlling domain. BNF grammar and railroad diagram of TaskMUSTER is provided for the clarity and usability of the framework. This exhaustive model is suitable for performing schedulability/sensitivity analysis of usage scenarios in academia and industry. Industry relevant TaskMUSTER bestows clear definition of a task model to automotive designers for performing realistic schedulability analysis. As future work, we will develop a design friendly task aggregator ’TaskMUSTER Analyzer’ to configure systems using Task- MUSTER.

Though the scope of this work is limited to controlling domain of automotive systems, the same can be applied to avionic and robotic platforms. Fly-by-wire avionics follow the guidelines given by DO-178 B/C. Robotic systems like personal care humanoids /industrial humanoids use ISO1348 and ISO10218 safety standards. Even though, there are stringent certification requirements to follow in avionics /robotics, there are many similarities with steer-by-wire /brake-by-wire automotive systems in terms of quality, criticality, electronics and embedded systems, networked controller units, structures, engines etc. Due to the commonality of task/system parameters across these embedded controlling domains, it is feasible to customize the usage of TaskMUSTER across these domains. TaskMUSTER is the flexible, design friendly and industry relevant task model aggregator for designers and researchers in embedded controlling domain.