<figure><img src="image_1.png" /></figure>

HAL
open science

# DREAMS: Cross-Domain Mixed-Criticality Patterns

Asier Larrucea, Imanol Martinez, Jon Perez, Vicent Brocal, Salvador Peiró, Hamidreza Ahmadian, Roman Obermaisser

<figure><img src="image_2.png" /></figure>

## To cite this version:

Asier Larrucea, Imanol Martinez, Jon Perez, Vicent Brocal, Salvador Peiró, et al. DREAMS: Cross-Domain Mixed-Criticality Patterns. WMC 2016, Nov 2016, Porto, Portugal. hal-01438832

HAL Id: hal-01438832

https://hal.science/hal-01438832

Submitted on 18 Jan 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
# DREAMS: Cross-Domain Mixed-Criticality Patterns

Asier Larrucea, Imanol Martinez,
Jon Perez

Embedded Systems Group
IK4-Ikerlan Technological Research Centre
Mondragon, Spain

alarrucea, imartinez, jmperez @ikerlan.es

Vicent Brocal, Salvador Peiró
Fent Innovate Software Solutions
Valencia, Spain

vbrocal, speiro @fentiss.com

Hamidreza Ahmadian,
Roman Obermaisser
University of Siegen
Siegen, Germany
hamidreza.ahmadian,

roman.obermaisser @uni-siegen.de

**Abstract**—The transition from conventional federated architectures to integrated architectures enables the integration of functionalities with different criticality (such as safety, security and real-time) on a single embedded computing platform. Many embedded mixed-criticality systems require distributed subsystems with networks to satisfy computational resource demands and installation requirements and ensure fault-tolerance. The broad trend of the integration of functionalities with different criticality on a multi-core embedded computing platform increases the complexity and challenges to certification, which is supported by the fact that today's safety-related standards are mostly focused on single-core devices and not on multi-core devices where resources are shared between more than one component. This paper analyses the commonly occurring problems in today's mixed-criticality systems and presents reusable generic solutions to tackle them, including solutions for hypervisors, commercial-off-the-self multi-core devices and mixed-criticality networks.

**Keywords**—cross-domain patterns, mixed-criticality systems, hypervisor, COTS multi-core processor, mixed-criticality network, certification, IEC 61508, IEC 61784-3

## I. INTRODUCTION

Embedded systems have commonly followed a federated architecture paradigm in which each Distributed Application Subsystem (DAS) is implemented on its own stand-alone distributed Hardware (HW) base with a well-defined functionality. However, the soaring demand for high performance and increasing functionality challenges the viability of this approach, leading to the increasing trend of moving towards integrated architectures [1]. As a consequence, system engineers aim at the integration of multiple functionalities with different criticality with respect to safety, security and real-time on the same embedded computing platform. These systems where functionalities with different criticality are integrated are often referred to as mixed-criticality systems [2]. The transition from single-core to multi-core architectures has further contributed to this trend. Multi-core architectures provide benefits in terms of cost, size and weight reduction as well as improved scalability. However, today's Commercial Off-The-Shelf (COTS) multi-core processors imply certification challenges, among others, due to the resource sharing. To tackle to these challenges, time and space partitioning (TSP) enabling technologies such as hypervisors are commonly used to limit the impact of changes to reduced areas of the system, enabling in turn the reusability of these areas and reducing the complexity. A hypervisor is a layer of Software (SW) or a combination of SW and HW that allows running several partitions on a single computer platform. The resulting partitions can be designed, developed and certified individually with different level of criticality (e.g.,

Safety Integrity Level (SIL) 1 to 4 according to the IEC 61508 safety standard).

In distributed systems, processing, sensors, actuators and data are spread out over multiple devices (e.g., multi-core processors) using communication networks (e.g., Ethernet). The integration of functionalities with different criticality into a single embedded computing platform implies the use of communication systems that support different criticalities. These communication systems, which are usually referred to as mixed-criticality networks, are capable of supporting safe and predictable message exchanges between DAS with different criticality. Mixed-criticality networks are targeted as the natural replacement of legacy buses in modern system architectures due to their low-cost, high-speed and easy integration with existing network infrastructures. They can be divided into on-chip communication architectures for communicating the components of the integrated circuits such as the cores of a multi-core processor (e.g., AHB, ASB and APB), off-chip communication architectures for inter-node (device) communication (e.g., Ethernet) and local buses for chip-to-chip interconnect (e.g., PCI and PCIe). However, mixed-criticality networks also pose certification challenges related to the increasing safety, security and real-time constraints in demanding application domains such as automotive and railway. E.g., guarantee that non safety components of the network do not interfere in temporal and spatial domains to the safety-related components.

Certification is a procedure in which an accredited or authorized body assesses the requirements of a system in accordance with established requirements of a standard. In the safety domain, safety certification assesses the compliance of a system to the requirements of a safety standard (such as the IEC 61508 safety-related standard). The traditional approach to certification relies on the certification of the whole system, where a change of a safety aspect of the system implies the re-certification of the entire system. Instead, modularity enables the subdivision of the system into smaller parts, also called modules, which can be independently certified and re-used to compose a mixed-criticality system. A certification process is usually carried out by means of safety case documents. These documents include convincing and valid arguments that evidence the safety of a system for a given application in a given environment (e.g., automotive, railway and lift). On the other hand, in modular certification, modular safety cases are used for evidencing the safety of the components of a system in accordance with a safety standard. For instance, under the European project Distributed Real-time Architecture for Mixed Criticality Systems (DREAMS) the Modular Safety Cases (MSCs) for an IEC 61508 compliant hypervisor, partition,
COTS multi-core device and mixed-criticality network are
defined [3], [4].

As a result of the definition of the MSCs and associated
analysis of the IEC 61508 safety standard, the remarkable
components that imply challenges in the development and
certification of today's mixed-criticality embedded computing
systems have been identified. Moreover, it is identified that the
measures and diagnostic techniques recommended by today's
safety-related standard, including the IEC 61508 safety standard,
are mostly geared to single-core devices where resources are not
shared among more than one component. Therefore, the need
for further measures and diagnostic techniques that extend the
measures and techniques recommended by the safety-related
standards is identified. This paper presents an overview of
several cross-domain patterns defined in the European project
DREAMS to guide and support engineers towards solutions
to the certification challenges identified in today's mixed-
criticality systems. The paper is organized as follows. Section
II introduces the architecture style used in European project
DREAMS. Section III presents the certification challenges
identified in today's mixed-criticality systems. Section IV
defines the remarkable IEC 61508 compliant cross-domain
patterns for mixed-criticality systems and Section V summaries
the conclusions and future work.

II. DREAMS ARCHITECTURE STYLE

The European project DREAMS defines a cross-domain
system architecture that supports the execution of functionalities
with different criticality levels on top of a networked multi-core
chip. This system perspective shown in Figure 1 tackles the
challenges of today's mixed-criticality systems, providing an
architecture style based on a COTS multi-core chip (nodes)
that integrates resource management services and end-to-end
channels with on-chip and off-chip networks. In this architecture
style a node is composed of application tiles. The tiles can
access to the memory and the Inputs / Outputs (I/Os) through an
on-chip interconnect bus (Network-on-Chip (NoC)). In addition,
the tiles contain one or more application components (partitions)
with different criticality levels (such as SIL1 to 4 according
to IEC 61508). Partitions can use optional services such as
fault-tolerance techniques and encryption services and access
to the DREAMS core services such as the processor cores,
network interfaces and the local resource management (LRM).

<figure><img src="image_3.png" /><figcaption>Fig. 1. DREAMS architecture style – Overview. (Source [5])</figcaption></figure>

The blocks highlighted in grey are core platform services,

the blocks in dotted lines are the *optional platform services* and the blocks highlighted with points are the *application related platform services*. This architecture style results in higher flexibility, adaptability and energy efficiency. However, it increases the complexity of the mixed-criticality system due to a higher number of components and the use of partitioning and mixed-criticality networks (such as guaranteeing that the memory areas of critical partitions are not accessed by non safety-related partitions).

### III. CERTIFICATION CHALLENGES FOR MIXED-CRITICALITY SYSTEMS BASED ON DREAMS ARCHITECTURE

In different domains such as avionics, railway, automotive,
industrial control and healthcare, the integration of functionali-
ties with different criticality into a single embedded computing
platform is a common requirement. These systems, usually
referred to as mixed-criticality systems [6], may require on-
chip, off-chip and chip-to-chip communication architectures for
communicating their components (e.g., cores, partitions and
memories), connect them with external systems and for chip-
to-chip communication. In the particular case of the DREAMS
architecture style shown in Figure 1, it implements on-chip
communication systems (NoCs) for communicating the nodes
and the application tiles that contain the partitions. Network-on-
chips (NoCs) enable avoiding the problems associated with the
use of the shared memories [7]. E.g., memory inconsistency
and cache coherency problems. However, the use of NoCs
increment the complexity of the system and imply challenges
to certification such as guaranteeing that the critical memory
assigned to the mixed-criticality network is not accessed by the
hypervisor or the safety and non safety-related partitions. NoCs
are a predictable communication networks with inherent non
interferences among their components (e.g., processing cores,
peripherals and memories). They can be implemented for safety-
related applications, providing support for Time-Triggered (TT),
Rate Constrained (RC) and Best-Effort (BE) traffic [8]. The shift
towards NoCs leads to challenges such as supporting multiple
types of communication as well as supporting applications
with different criticality level [9]. For instance, Time-Triggered
Network-on-a-Chip (TTNoC) communication system does not
support the transmission of Event-Triggered (ET) messages
[10] and *AEtheral* NoC does not support the transmission
of RC messages [11]. Furthermore, the architecture style
shown in Figure 1 uses off-chip communication systems for
communicating the nodes with the Global Resource Manager
(GRM). The use of those communication systems requires
protection mechanisms such as NoC-Memory Protection Units
(MPUs) [12] for avoiding interferences in both spatial and
temporal domains.

In relation to the HW architecture, the certification chal-
lenges for COTS multi-core processors have also been analysed.
COTS multi-core devices are low cost and complex solutions
with short time-to-market. They are commonly used devices
in real-time embedded computing systems due to the low
power consumption, size, cost and weight and better scalability.
However, these devices contain components such as shared
memories, interconnection management units and coherency
management units which may cause drawbacks and may
jeopardize the safety of the system. I.e., simultaneous running
of tasks or/and the sharing of the resources between more than
one component. Different research studies propose techniques to
improve the performance of the multi-core devices by reducing
the memory interferences of the applications [13] [14] [15]
and to control the mapping of application's data to memory
channels [16]. Some of these techniques focus on scheduling
policies which provide request prioritization and reduce the
inter-partition interferences.

Certification challenges stated in this section are not covered
at all by today's safety-related standards such as they are
focused on single-core devices. It is assumed that some of the
measures and diagnostic techniques recommended by these
standards are reusable for multi-core architectures. However,
these measures and technique must be extended by extra
measures and diagnostic techniques for guaranteeing the safety
of partitioned and networked multi-core systems.

## IV. CROSS-DOMAIN PATTERNS

Cross-domain patterns are widely used to guide and support
engineers towards solutions that solve commonly occurring
problems in the development of mixed-criticality system from
design to validation. This section defines an overview of
the cross-domain patterns defined in the European project
DREAMS, including reusable generic solutions for the hypervi-
sors, COTS multi-core devices and mixed-criticality networks.

### A. Hypervisor

#### 1) NoC accessible memory area diagnosis pattern

In partitioned multi-core mixed criticality systems, NoCs
are widely implemented communication systems to avoid Point-
to-Point (P2P) individual communication paths between the
components and enable creating logic paths for data interchange
[17] [18] [19] [5]. However, on-chip networks may access to
critical memory areas in use by the components that compose
a system. Non-authorized memory accesses of a NoC may
jeopardize the safety of the system. The most significant
impact of the memory access that can be performed by a
NoC communication system is the breaking of the temporal
isolation, which can also be endangered due to delays caused
by a high amount of traffic in the NoC. This pattern defines the
following generic design solutions for detecting and avoiding
the failures in the critical memory areas shared between the
hypervisor and the NoC.

* Provide complete HW isolation of the NoC

This solution proposes the assignment of a dedicated
RAM memory to the NoC communication system for
buffering the incoming and outgoing messages and for
its internal operations. In addition, in order to achieve a
complete HW isolation from the processing cores, this
solution proposes to allocate to the NoC an independent
bus for accessing to the memory. This solution scheme
can be implemented using a dual-port RAM memory
where one port is accessible by the NoC and the other
port is connected to the bus where the processing cores
are connected.

* Use an Input/Output MMU

Memory Management Unit (MMU) controls the access
of Direct Memory Access (DMA) transfers programmed

by the bus-master capable Input / Output (I/O) devices.
Consequently, the DMA transfers do not overwrite
or read from the restricted memory addresses. These
addresses may contain the code and the data of the
safety critical tasks. The I/O MMU may enforce the
spatial isolation and avoid the overwritten of the safety
sensitive memory regions by the NoC.

* Additional monitoring mechanisms

See next design pattern "*Critical partition diagnosis*".

#### 2) Critical partition diagnosis pattern

A partitioned mixed-criticality architecture limits the impact
of changes, allows reusability of partitions and reduces the com-
plexity. When dealing with partitioned systems with different
criticality, failures caused by the interchange of information are
quite probable. The lower criticality functionalities can lead
to interferences on the higher criticality functionalities. This
pattern analyses two possible sources of interferences. The
first source refers to the occurrence of temporal interferences
generated by multiple accesses in parallel to the shared memory
(e.g., interferences caused by the cores of a multi-core device).
The concurrent accesses can compete for accessing to the shared
memory cache, possibly leading to interferences in the temporal
domain. On the other hand, the failures in the spatial domain
provided by the hypervisor are also analysed by this pattern.
These failures can also be found in mono-core architectures
that use a hypervisor. This cross-domain pattern proposes
the following generic scalable design solutions to measure
and detect interferences caused by non critical partitions on
critical partitions and guarantee the systems temporal and spatial
independences.

* Limit the concurrency

This solution considers that critical tasks are executed
without concurrency and that when a critical task is
running in a certain core, the other cores do *idle* only
for the duration of the task. This consideration enables
avoiding contention. The limitation of the concurrency
can be achieved by appropriately configuring at design
time the partition execution windows for all the cores.
The loss in performance can be leveraged by tuning
the amount of time that a core (running a critical task)
executes without concurrency. The maximum amount
of interference suffered by one core due to accesses to
shared memory and the bus bandwidth used by the other
cores can be calculated by means of off-line analyses.
The concurrent execution can be guaranteed up to a
certain safe time limit based on the temporal constraints
of the safety critical tasks and the maximum amount of
interferences.

* Assess the spatial isolation

This solution presents a diagnostic partition that periodi-
cally checks the data of the critical memory areas, includ-
ing the hypervisor's code and the partitions' code and
data. Checksum and similar mechanism recommended
by the IEC 61508 safety standard (see Annex A of IEC
61508-2-3 [20] [21]) can be individually implemented
by the partitions for checking their own code and data.
In addition, this pattern assumes that the code of the hypervisor is checked by at least one partition to ensure that it is not unexpectedly modified.

* Assess the temporal isolation

The measures and diagnostic techniques recommended in Annex A of the IEC 61508-2-3 safety standard [20] [21] can also be implemented to diagnose the temporal isolation. For instance, the *Program temporal sequence monitoring* technique defined in IEC61508-7 section A.9 [22] may be implemented to monitor the execution of safety critical tasks in terms of temporal response and ensure that the temporal isolation is not compromised due to a failure of the hypervisor. This solution aims to detect failures that may jeopardize the temporal isolation in the hypervisor and in the configuration of the partitions' execution windows. The task scheduling inside the partitions is out of the scope of this solution and therefore it is not analysed.

### 3) Digital Input/Output Server Pattern

Digital I/Os are widely used among different system architectures for communication purposes (e.g., sensors and actuators). This pattern considers that a Digital I/O (DIO) can be managed by partitions with different criticality (e.g., safety, non safety and real-time) but not at the same time. The simultaneous access to a DIO from more than one partition may jeopardize the safety of the system such as the temporal and spatial independences may be affected [23]. On the other hand, from a product line perspective, the number of Digital I/Os (DIOs) which may be requested by a product sample might change. This may lead to the scalability problems in SW due to the management complexity of such I/Os.

This cross-domain pattern proposes the implementation of a reusable generic Digital I/O Server (DIOS) partition for managing the digital I/Os of a mixed-criticality system. The DIOS is a consistent and concurrent manager of digital I/Os abstracted from the underlying HW and hypervisor. It periodically updates the values of the digital inputs associated with the digital outputs and refreshes the information of the partitions where the inputs are required. Afterwards, the server periodically checks the Cyclic Redundancy Codes (CRCs) of the register's values associated to the DIOs against the values pre-stored. The comparison period is determined by the minimum refreshing period of the digital outputs. It is checked that the partitions in charge for updating the digital outputs refresh the values of the DIOS partition. To that end, the server implements a token that is updated every time that the communication is refreshed, always agreeing with the expected values in DIOS. This solution can also be applied in the remaining partitions of the system, but with the inputs, for assuring the communication between the partitions and the DIOS. Each digital input is checked under a pre-configured time-out to detect whether their values are able to be changed. If the time-out value is not specified, the default value will be used (a month) and the developer shall integrate an output to change the values of the inputs in a controlled non safety way for testing purposes. In the case that a failure is detected, the digital outputs will be refreshed with their safe value instead of with the value provided by the partitions. Furthermore, in the case that different partitions try to update the same output

with different values, the partitions will be moved to a safe state and the outputs will be updated to the default value.

In safety-related applications, the configuration of the digital I/Os of the server like the configuration of partitions is established by means of off-line T3 qualified tools. These tools generate outputs that can directly or indirectly contribute to the executable code of the safety-related system (e.g., engineering tools, translation tools and configuration tools).

## B. COTS Multi-Core devices

### 1) Shared memory diagnosis pattern

The sharing of resources is a habitual implementation in today's multi-core mixed devices for improving the performance. Modern multi-core devices integrate cache memories which can be applied for private use (e.g., L1 cache) or memories which can be shared between more than one component at the same time (e.g., L2 cache). In single-core architecture domain, the IEC 61508 safety standard covers the failures caused by memory sharing such as the causal factors of the execution interference between components of a single computer platform (see Annex F of IEC 61508-3 [21] "Techniques for achieving non interference between SW components on a single computer"). However, in multi-core architectures a resource can be accessed at the same time from multiple components (e.g., cores and soft-core processors) through regular memory operations and requests, causing interferences in general that can imply deviations in the safety behaviour. This cross-domain pattern proposes the following reusable generic solutions to detect, evict and manage the failures related to shared memories in multi-core devices.

* Limit the use of shared memories

This solution proposes to limit as much as possible the use of the shared memory and in the case that it is implemented to control its access for avoiding parallel accesses. For instance, the shared memory of the ZYNQ 7000 processor can be disabled [24]. On the other hand, as shown in Figure 1, the shared memories can be replaced by NoC systems, thus avoiding interferences caused by the use of shared memories and enabling the establishment of spatial and temporal segregation between subsystems with different criticality.

* Cyclic redundancy check with comparison:

This solution proposes a Cyclic Redundancy Code (CRC) based diagnosis with comparison to detect failures in the shared memory. This solution is shown in Figure 2 where the application data of the processor's cores calculate the CRCs. These CRCs are sent through the shared memory to different memory locations of memory B (e.g., DDR). In addition, the *golden CRCs* of the data are calculated and stored in memory A (e.g., On-Chip Memory (OCM)). The golden CRCs are the results of the first calculations of the CRCs. These CRCs are used to perform the comparison against the CRC values of the data that are sent through the shared memory and detect failures in the shared memory. The CRCs can be calculated at the beginning or at the end of the execution of the tasks, although, in the case that the CRCs are calculated at the beginning, a synchronization mechanism
may be required to synchronize the calculation and the comparison of the CRCs.

<figure><img src="image_4.png" /><figcaption>Fig. 2. Shared memory diagnostic pattern– CRC with comparison.</figcaption></figure>

The implementation of this pattern is dependent on other components of the system, including the cores, timer, interrupt controller, coherency management unit, interconnection management unit and the memories. Therefore, in order to achieve the optimum implementation of this solution, it is assumed that all those components are checked in advance and that they do not interfere with the shared memory. This design solution considers two implementation scenarios where it could be implemented to diagnose a shared memory. The first scenario is based on a COTS multi-core device provided as it is by the device manufacturer, whereas the second scenario presents a partitioned COTS multi-core device where functionalities with different criticality levels are executed on top of partitions (e.g., safety, security and real-time). The term as it is refers to a device that is provided without modifications (e.g., without partitioning) that alter its properties (e.g., safety-related properties).

## 2) Cache coherency management diagnosis pattern

Cache coherency is the consistency of shared resource data that ends up stored in multiple local caches (such as the L1 cache and L2 cache). For example, a coherency mechanism can store the copies of the data saved in several caches. When one copy of the data is modified, the other copy shall be also changed, otherwise an inconsistency is arisen. Today's mixed-criticality systems based on multi-core devices implement a coherency management unit for managing, among others, the coherency of the processors, the memory and the Programmable Logic (PL) (if applicable). For instance, the ZYNQ 7000 processor implements a snoop control unit (SCU) for managing the memory coherency [24]. However, the snooping technique does not fully guarantee the coherency of the memories. For example, the CPU0 of the Figure 2 has a copy of a memory block from a previous read and CPU1 changes the memory block. Consequently, in the case that the coherency management unit fails, the data of CPU0 is not updated, leading to an inconsistency of data that can jeopardize the behaviour of the system. Here is where this cross-domain pattern is focused, defining different solutions for ensuring that changes of data are propagated through the device and if not, detecting whether a coherency failure occurs.

* **Check the configuration of the coherency unit**

The configuration of the coherency management unit shall be performed in a safe manner for ensuring the minimum possible interferences. Wrong or incorrect

configuration may lead to the loss of the coherency and the resultant failure of the system. Consequently, this first solution periodically checks the configuration of the coherency unit, comparing it with the expected configuration or the last valid configuration set. In addition, this solution assumes that the configuration is free of systematic faults and to that end a set of measures and diagnostic techniques recommended by IEC 61508-2 Annex A and B for controlling and avoiding systematic failures are implemented [20].

* **Diagnose random failures**

SW has the ability to manage the memory regions shared among certain sets of coherent masters. In addition, it ensures that the shareability mappings between the masters is consistent to avoid unexpected behaviours and inconsistencies. For instance, a protection mechanism such as a MMU can be used to control the memory, manage permissions to blocks of the memory and translate the virtual addresses to physical addresses. In addition, this solution assumes that the coherency management unit implements a set of measures and diagnosis techniques [20] to detect and control random faults such as the wrong addressing, partial update or single bit errors faults. For example, watchdog timers (WDT) can be used for detecting the temporal deviations, a CRC with comparison (see pattern "Shared memory diagnosis" in sub-section IV-B) for detecting unexpected data modifications and an Error Correction Code (ECC) and/or a parity bit technique can be implemented to detect data consistency violations, including partial update or single bit error failures.

* **Diagnose systematic failures**

Systematic faults can also affect the coherency management unit. These faults can be sourced from the HW design, the environmental stress, external influences and operational failures. This third solution considers the implementation of the measures and diagnostic techniques recommended in tables A.15 to A.17 and Annex B of IEC 61508-2 [20] for managing and avoiding the systematic faults in the coherency unit. The selection of the measures and techniques depends on the HW available and the SW supported by the system architecture, giving rise to different combinations of measures and diagnostic techniques.

## C. Mixed-Criticality Networks

### 1) Network-on-Chip pattern

This pattern defines a reusable generic solution that manages communications with different priorities and traffic types such as TT and ET (BE and RC). It guarantees the periodical transmission of TT messages for achieving predictable timing with minimal latency and no jitter. Instead, BE messages do not have timing restrictions and does not fulfil the requirements of non safety applications. RC messages offer a reasonable trade-off between resource reservation and latency. In addition, this pattern supports hard-real time applications. It ensures by a scheduler that messages of the system meet the pre-specified deadlines in all situations defined in [25]. On the other hand,
the communication of applications with different criticality
level that interact and coexist on a shared computing platform
requires protection mechanisms that establish chip-wide segrega-
tion. The use of partitioning mechanisms such as hypervisors is
not enough because non safety partitions can influence to safety-
related ones. Therefore, this pattern implements a rigid temporal
and spatial partitioning by establishing a chip-wide partitioning
[26]. In accordance with the IEC 61508 safety standard, this
pattern can be considered as an Safety Communication Layer
(SCL) network that implements IEC 61784-3 or IEC 62280
compliant measures and diagnostic techniques to ensure the
failure performance of the communication process. The safety
network is implemented on top of a NoC (e.g., STNoC)
and together constitute a black-channel network [20]. In a
black channel network it is assumed that not all parts of the
communication channel are designed and validated according
to the IEC 61508 safety standard.

V. CONCLUSIONS

This publication presents an overview of the mixed-
criticality cross-domain patterns defined and implemented under
the European project DREAMS [27]. These cross-domain
patterns give rise to reusable generic solutions that solve com-
monly occurring problems in today's mixed-criticality systems.
They will be integrated into the wind turbine, aeronautic and
healthcare use cases of the project DREAMS. It is foreseen
that the patterns proposed in this paper may be refined and
that extra cross-domain patterns may be implemented, with or
without other cross-domain pattern dependency, to tackle to
current and future challenges in mixed-criticality systems.

ACKNOWLEDGEMENT

This work has been supported by the European project
DREAMS under project No. 610640. Any opinions, findings
and conclusions expressed in this article are those of the authors
and do not necessarily reflect the views of funding agencies.

REFERENCES

[1] R. Hammett, “Flight-Critical Distributed Systems - Design Considerations [avionics],” *Aerospace and Electronic System Magazine, IEEE*, vol. 18, no. 6, pp. 30–36, 2003.

[2] C. Baumann, T. Bormer, H. Blasum, and S. Tverdyshev, "Proving memory separation in a microkernel by code level verification," in *Object/Component/Service-Oriented Real-Time Distributed Computing Workshops (ISORCW), 2011 14th IEEE International Symposium on*, March 2011, pp. 25–32.

[3] A. Larrucea, J. Perez, I. Agirre, V. Brocal, and R. Obermaisser, “A modular safety case for an IEC 61508 compliant generic hypervisor,” *Euromicro Conference on Digital System Design (DSD)*, p. 4, August 2015.

[4] A. Larrucea, J. Perez, and R. Obermaisser, “A modular safety case for an IEC 61508 compliant generic COTS processor,” *The 13th IEEE International Conference on Dependable, Autonomic and Secure Computing (DASC)*, p. 8, 26-28 October 2015.

[5] "FP7 DREAMS: Distributed Real-time Architecture for Mixed-Criticality Systems," 2013. [Online]. Available: http://www.uni-siegen.de/dreams/home/

[6] J. Perez, D. Gonzalez, S. Trujillo, T. Trapman, and J. M. Garate, “A safety concept for a wind power mixed-criticality embedded system based on multicore partitioning,” in *11th International TÜV Rheinland Symposium “Functional Safety in Industrial Applications”*, 2014.

[7] W.-C. Kwon and L.-S. Peh, "A universal ordered noc design platform for shared-memory mpsoC," in *Proceedings of the IEEE/ACM International Conference on Computer-Aided Design*, ser. ICCAD '15, 2015, pp. 697–704.

[8] A. Burns, J. Harbin, and L. S. Indrusiak, "A wormhole NoC protocol for mixed criticality systems," in *Real-Time Systems Symposium (RTSS), 2014 IEEE*, Dec 2014, pp. 184–195.

[9] A. Kritikakou, C. Rochange, M. Faugère, C. Pagetti, M. Roy, S. Girbal, and D. G. Pérez, "Distributed run-time w cet controller for concurrent critical tasks in mixed-critical systems," in *Proceedings of the 22Nd International Conference on Real-Time Networks and Systems*, 2014, pp. 139–148.

[10] C. Paukovits and H. Kopetz, "Concepts of switching in the time-triggered network-on-chip," in *2008 14th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications*, Aug 2008, pp. 120–129.

[11] K. Goossens and A. Hansson, “The AEthereal network on chip after ten years: Goals, evolution, lessons, and future,” in *Design Automation Conference (DAC), 2010 47th ACM/IEEE*, June 2010, pp. 306–311.

[12] J. Porquet, A. Greiner, and C. Schwarz, "NoC-MPU: A secure architecture for flexible co-hosting on shared memory MPSoCs," in *2011 Design, Automation Test in Europe*, March 2011, pp. 1–4.

[13] J. Gustafsson, A. Betts, A. Ermedahl, and B. Lisper, "The Mälardalen WCET benchmarks past, present and future," in *Worst-Case Execution Time Analysis (WCET), International Workshop on*, B. Lisper, Ed., vol. 15. Schloss Dagstuhl, Conference Proceedings, pp. 136–146.

[14] M. Paolieri, E. Quiñones, F. J. Cazorla, and M. Valero, "An analyzable memory controller for hard real-time cmps," *Embedded Systems Letters, IEEE*, vol. 1, no. 4, pp. 86–90, 2009.

[15] Y. Kim, D. Han, O. Mutlu, and M. Harchol-Balter, "A scalable and high-performance scheduling algorithm for multiple memory controllers," in *High-Performance Computer Architecture (HPCS), International Symposium on*, Conference Proceedings, p. 12.

[16] H. Shah, K. Huang, and A. Knoll, "Timing anomalies in multi-core architectures due to the interference on the shared resources," in *Design Automation (ASP-DAC), Asia and South Pacific Conference on*, Conference Proceedings, pp. 708–713.

[17] R. Obermaisser and H. Kopetz, GENESYS: A candidate for an ARTEMIS cross-domain reference architecture for embedded systems. Sdwestdeutscher Verlag fr Hochschulschriften (SVH) Aktiengesellschaft & Co. KG, 2009, no. 202, FP7 ARTEMIS.

[18] S. Trujillo, A. Crespo, and A. Alonso, "MultiPARTES: Multicore virtualization for mixed-criticality systems," pp. 260–265, September 2013.

[19] "ARTEMIS EMC2 - Embedded multi-core systems for mixed-criticality applications in dynamic and changeable real-time environments," 2014. [Online]. Available: http://www.artemis-emc2.eu/

[20] *IEC 61508-2: Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems*, Standard, April 2010.

[21] *IEC 61508-3: Functional safety of electrical/electronical/programmable electronic safety-related systems - Part 3: Software requirements*, Standard, Rev. 2.0, April 2010.

[22] *IEC 61508-7: Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures*, Standard, April 2010.

[23] B. Motruk, J. Diemer, R. Buchty, R. Ernst, and M. Berekovic, "IDAMC: A many-core platform with run-time monitoring for mixed-criticality," in *High-Assurance Systems Engineering (HASE), 2012 IEEE 14th International Symposium on*, Oct 2012, pp. 24–31.

[24] XILINX, "ZYNQ-7000 All programmable SoC: Technical reference manual," XILINX, Report, September 2014.

[25] H. Kopetz, *Real-Time Systems: Design principles for distributed embedded applications*. Springer, 2011.

[26] A. Larrucea, H. Ahmadian, R. Obermaisser, J. Perez, and C. F. Nicolas, "A realistic approach to a network-on-chip cross-domain pattern," *Digital System Design (DSD), Euromicro Conference on*, p. 8, 31 August - 2 September 2016.

[27] "FP7 DREAMS: Distributed Real-Time Architecture for Mixed-Criticality Systems: Cross-Domain Mixed-Criticality Pattern, D5.3.1," p. 81, July 2016.