Asier Larrucea
email: alarrucea@ikerlan.es

Imanol Martinez
email: imartinez@ikerlan.es

Vicent Brocal
email: vbrocal@fentiss.com

Salvador Peirò
email: speiro@fentiss.com

Hamidreza Ahmadian
email: hamidreza.ahmadian@uni-siegen.de

Jon Perez
email: jmperez@ikerlan.es

Roman Obermaisser
email: roman.obermaisser@uni-siegen.de

Salvador Peiró Fent

DREAMS: Cross

Keywords: Domain Mixed-Criticality Patterns cross-domain pattens, mixed-criticality systems, hypervisor, COTS multi-core processor, mixed-criticality network, certification, IEC 61508, IEC 61784-3

come

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 [START_REF] Hammett | Flight-Critical Distributed Systems -Design Considerations [avionics[END_REF]. 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 [START_REF] Baumann | Proving memory separation in a microkernel by code level verification[END_REF]. The transition from single-core to multi-core architectures has further contributed to this trend. Multi-core architectures provide benefits regarding cost, size and weight reduction as well as improved scalability. However, today's Commercial Off-The-Shelf (COTS) multicore processors imply certification challenges, among others, due to the resource sharing. To tackle 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 processing 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-tochip interconnect (e.g., PCI and PCIe). However, mixedcriticality 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 safetyrelated components.

Certification is a third-party attestation related to products, processes, systems or persons [3]. An attestation is the issue of a statement, based on a decision following review, which fulfilment of specified requirements has been demonstrated. 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 using 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 by 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 1 defined [START_REF] Larrucea | A modular safety case for an IEC 61508 compliant generic hypervisor[END_REF], [START_REF] Larrucea | A modular safety case for an IEC 61508 compliant generic COTS processor[END_REF].

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 focused on single computers 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 mixedcriticality systems. The paper is organised 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 summarizes 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). 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 nonsafety-related partitions do not access the memory areas of critical 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 functionalities with different criticality into a single embedded computing platform is a common requirement. These systems, usually referred to as mixed-criticality systems [START_REF] Perez | A safety concept for a wind power mixed-criticality embedded system based on multicore partitioning[END_REF], may require onchip, off-chip and chip-to-chip communication architectures for communicating their components (e.g., CPUs, partitions and memories), connect them with external systems and for chipto-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-onchips (NoCs) enable avoiding the problems associated with the use of the shared memories [START_REF] Kwon | A universal ordered noc design platform for shared-memory mpsoc[END_REF]. 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 safetyrelated applications, providing support for Time-Triggered (TT), Rate Constrained (RC) and Best-Effort (BE) traffic [START_REF] Burns | A wormhole NoC protocol for mixed criticality systems[END_REF]. The shift towards NoCs leads to challenges such as supporting multiple types of communication as well as supporting applications with different criticality level [START_REF] Kritikakou | Distributed run-time wcet controller for concurrent critical tasks in mixed-critical systems[END_REF]. For instance, Time-Triggered Network-on-a-Chip (TTNoC) communication system does not support the transmission of Event-Triggered (ET) messages [START_REF] Paukovits | Concepts of switching in the time-triggered network-on-chip[END_REF] and AEtheral NoC does not support the transmission of RC messages [START_REF] Goossens | The AEthereal network on chip after ten years: Goals, evolution, lessons, and future[END_REF]. 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) [START_REF] Porquet | NoC-MPU: A secure architecture for flexible co-hosting on shared memory MPSoCs[END_REF] for avoiding interferences in both spatial and temporal domains.

In relation to the HW architecture, the certification challenges 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 [START_REF] Gustafsson | The Mälardalen WCET benchmarks past, present and future[END_REF] [15] [START_REF] Kim | A scalable and highperformance scheduling algorithm for multiple memory controllers[END_REF] and to control the mapping of application's data to memory channels [START_REF] Shah | Timing anomalies in multi-core architectures due to the interference on the shared resources[END_REF]. 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 the mixed-criticality system from design to validation. This section defines an overview of the cross-domain patterns identified in the European project DREAMS, including reusable generic solutions for the hypervisors, 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 Pointto-Point (P2P) individual communication paths between the components and enable creating logic paths for data interchange [START_REF] Obermaisser | GENESYS: A candidate for an ARTEMIS cross-domain reference architecture for embedded systems[END_REF] [19] [START_REF]ARTEMIS EMC2 -Embedded multi-core systems for mixed-criticality applications in dynamic and changeable real-time environments[END_REF] [START_REF]FP7 DREAMS: Distributed REal-time Architecture for Mixed-Criticality Systems[END_REF]. 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 jeopardise 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. Also, to achieve a complete HW isolation from the processing cores, this solution proposes to allocate to the NoC an independent bus for accessing 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 safetysensitive 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 complexity. 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 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 using 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 periodically checks the data of the critical memory areas, including the hypervisor's code and the partitions' code and data. The partitions can individually implement checksum and similar mechanism recommended by the IEC 61508 safety standard (see Annex A of IEC 61508-2-3 [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems -Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems[END_REF] [START_REF]Functional safety of electrical/electronical/programmable electronic safety-related systems -Part 3: Software requirements, Standard[END_REF]) for checking their 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 [21] [22] can also be implemented to diagnose the temporal isolation. For instance, the Program temporal sequence monitoring technique defined in IEC61508-7 section A.9 [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems -Part 7: Overview of techniques and measures[END_REF] may be implemented to monitor the execution of safety critical tasks regarding 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 jeopardise the temporal isolation in the hypervisor and 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 jeopardise the safety of the system such as the temporal, and spatial independences may be affected [START_REF] Motruk | IDAMC: A many-core platform with run-time monitoring for mixed-criticality[END_REF]. On the other hand, from a product line perspective, the number of DIOs which may be requested by a product sample might change. That increment 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 to 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 timeout to detect whether their values can 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 as the configuration of partitions is established using 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 [START_REF]Functional safety of electrical/electronical/programmable electronic safety-related systems -Part 3: Software requirements, Standard[END_REF] "Techniques for achieving noninterference 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., CPUs 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 [START_REF] Xilinx | ZYNQ-7000 All programmable SoC: Technical reference manual[END_REF]. 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 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 to the shared memory and detect failures in the shared memory. The CRCs can be calculated at the beginning or the end of the execution of the tasks, although, in the case that the CRCs are calculated at the beginning, a synchronisation mechanism may be required to synchronise the calculation and the comparison of the CRCs. The implementation of this pattern is dependent on other components of the system, including the CPUs, 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 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 also be changed. Otherwise, an inconsistency arises. 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 [START_REF] Xilinx | ZYNQ-7000 All programmable SoC: Technical reference manual[END_REF]. 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 jeopardise the behaviour of the system. Here is where this cross-domain pattern is focused, defining different solutions for ensuring that changes to the 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. The 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 [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems -Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems[END_REF].

• Diagnose random failures

The SW can manage the memory regions shared among certain sets of coherent masters. In addition, it ensures that the shareability mappings between the masters are consistent to avoid unexpected behaviours and inconsistencies. For instance, a protection mechanism such as an 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 [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems -Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems[END_REF] 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 diagnostic pattern" in Subsection 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. [START_REF] Paolieri | An analyzable memory controller for hard real-time cmps[END_REF] to A.17 and Annex B of IEC 61508-2 [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems -Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems[END_REF] 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 do 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 [START_REF] Kopetz | Real-Time Systems: Design principles for distributed embedded applications[END_REF]. 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 segregation. The use of partitioning mechanisms such as hypervisors are not enough because non-safety partitions can influence to safetyrelated ones. Therefore, this pattern implements a rigid temporal and spatial partitioning by establishing a chip-wide partitioning [START_REF] Larrucea | A realistic approach to a network-on-chip cross-domain pattern[END_REF]. By 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., STMicroelectronics NoC (STNoC)) and together constitute a black-channel network [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems -Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems[END_REF]. 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 mixedcriticality cross-domain patterns defined and implemented under the European project DREAMS. These cross-domain patterns give rise to reusable generic solutions that solve commonly occurring problems in today's mixed-criticality systems. They will be integrated into the wind turbine, aeronautic and 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.

Fig. 2 .

 2 Fig. 2. Shared memory diagnostic pattern-CRC with comparison.

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.