# Envisioning a Safety Island to Enable HPC Devices in Safety-Critical Domains

Jaume Abella1, Francisco J. Cazorla1, Sergi Alcaide1, Michael Paulitsch2, Yang
Peng2, Inês Pinto Gouveia2
1 Barcelona Supercomputing Center, Spain
2 Intel, Germany

###### Abstract

HPC (High Performance Computing) devices increasingly become the only
alternative to deliver the performance needed in safety-critical autonomous
systems (e.g., autonomous cars, unmanned planes) due to deploying large and
powerful multicores along with accelerators such as GPUs. However, the support
that those HPC devices offer to realize safety-critical systems on top is
heterogeneous. Safety islands have been devised to be coupled to HPC devices
and complement them to meet the safety requirements of an increased set of
applications, yet the variety of concepts and realizations is large.

This paper presents our own concept of a safety island with two goals in mind:
(1) offering a wide set of features to enable the broadest set of safety
applications for each HPC device, and (2) being realized with open source
components based on RISC-V ISA to ease its use and adoption. In particular, we
present our safety island concept, the key features we foresee it should
include, and its potential application beyond safety.

##  I Introduction

HPC processors can deliver the performance needed for future embedded systems
of autonomous cars and aircraft, which will rely heavily on performance-hungry
Artificial Intelligence (AI) software, as well as a high number of processes
to manage simultaneous events triggered by a plethora of sensors and by timers
periodically. However, the support that those devices offer for their use in
safety-related applications is different across devices, and so are the
guarantees or additional support they need – if any – for their use in
applications with varying needs in terms of integrity level, fail-safe or
fail-operational needs, performance predictability, and time to recover from
different types of errors.

In general, HPC processors can be used for fail-safe applications as long as a
high-integrity microcontroller unit (MCU) is deployed along with the HPC
processor, and the overall system architected so that the MCU can manage all
errors affecting both, the HPC processor or the MCU itself, and guide the
system to a safe state timely in accordance with application safety
requirements. However, if the MCU cannot manage all errors in the HPC
processor preserving safety requirements, or if the HPC processor must remain
fault-tolerant to meet such safety requirements, then additional support is
needed beyond that of the MCU. Such support can be part of the HPC device
itself, or be delivered in the form of an enhanced MCU with extended safety
capabilities to assist the HPC device.

To overcome the potential limitations that some HPC devices may offer for
their use in safety-critical applications, _safety islands_ have been proposed
recently [1, 2, 3, 4]. While the term _safety island_ includes a heterogeneous
set of devices, they normally offer two key sets of features: (1) a safe
enclave to run safety-related applications, in the same way an MCU does. In
fact, an MCU can be regarded as a safety island. However, safety islands offer
lower performance than HPC devices, at least for a set of performance-
demanding applications, and hence the need for an accompanying HPC device. (2)
A safety island also offers specific support to manage an external device that
needs to run safety-related functionalities. Such support may include watchdog
services, performance monitoring capabilities, ability to initiate test
capabilities in the other device or to test it externally, or support to
orchestrate diverse redundant execution in the external device to name a few.

When considering the deployment of a safety island along with an HPC device,
considerations about integration cannot be neglected. For instance, new cost-
efficient chip production and packaging options (multi-die chips –
EMIB111Embedded Multi-Die Interconnect Bridge, Foveros [5]) provide a solution
to deploy separate dies in the same package, which benefits a number of safety
island requirements like fault independence with different dies while
preserving high bandwidth communication.

This paper presents our own concept of a safety island, as well as our
strategy to realize it based on open source RISC-V [6] components with the aim
of easing its use and adoption. In our case, we aim at providing a rich set of
safety services to the HPC device to enable the deployment of safety-relevant
applications on top with varying safety requirements, despite the potentially
limited support that the HPC device may offer natively. Those services
foreseen for our safety island include the following:

  * •

Controllability features to configure the HPC device for fault management and
containment, and for providing predictable performance.

  * •

Observability features for system validation, error diagnosis, and as the
basis to build informed safety measures on top.

  * •

Safety measures to contain and manage errors, and to mitigate abnormal
performance conditions.

In this paper we provide the following contributions for the design and
deployment of our view of a safety island:

  1. 1.

We present our concept of a safety island along with examples for its
practical realization focusing on open source SoCs based on the RISC-V ISA.

  2. 2.

We identify existing open source components providing controllability and
observability features, and safety measures, appropriate for our Safety
Island.

  3. 3.

We identify further features to be developed in the future to complete and
complement our safety island.

  4. 4.

We devise further applications of the Safety Island beyond safety, such as
security, reliability, and power and temperature management. To some extent,
the foreseen security extensions are comparable to the “Security Island”
already offered by some processors (e.g., Arm’s TrustZone [7]).

The rest of the paper is organized as follows. Section II provides some
background and other solutions comparable or related to the safety island
proposed in this paper. Section III presents our concept of safety island.
Section IV describes convenient components for our safety island, whether they
already exist or not. Section V shows how the safety island could be used for
other applications. Finally, Section VI summarizes this paper.

##  II Background

###  II-A Safety-Critical System Development Process

Domain specific safety standards describe the development process to be
followed for safety-critical systems. Examples of such standards include
ISO26262 [8] for the automotive domain, EN5012x [9, 10, 11] for the railway
domain, and IEC61508 [12] for industrial systems. Those development processes
follow a “V” model (see Figure 1). First, the safety goals of the system need
being specified. Safety requirements are obtained out of those safety goals.
Then, the architecture of the system is devised ensuring that all safety
requirements are mapped to specific items that will have to fulfill them.

Safety-critical systems are designed to be correct by construction, hence
meaning that both, hardware and software, are error free. This is achieved by
following specific rules and processes when architecting the system and
implementing it. However, random hardware faults due to radiation, sporadic
deadline violations, voltage fluctuations, and the like cannot be fully
avoided. Hence, safety measures must be included in the system design to
manage errors emanating from those faults (e.g., tolerating them, or detecting
them and reaching a safe state timely). Once the system has been architected,
its different components are implemented adhering to specific constraints
dictated by the standards (e.g., avoiding unobvious control flow in the
software).

Verification activities for the system architecture and implementation must be
included in the process as a way to assess that the design adheres to its
requirements and specifications. Controllability means are generally needed
along with the design and verification activities to avoid problematic
behavior during operation and to enforce specific behavior for verification
purposes.

Validation activities (the right part of the “V”) include testing activities
for individual components, as well as for the subsequent integrations with the
goal of spotting design errors and, in their absence, gain confidence on the
safety of the system. Those testing activities must be as little intrusive as
possible to observe the system in operation conditions. Using observability
means allow provision of system information without altering the behavior of a
system.

Overall, safety-critical systems need to include safety measures, as well as
controllability and observability channels to ease their development in
accordance with safety standards.

Figure 1: V-model of the development process of a safety-critical system.

###  II-B Relevant Concepts

In this paper we build on a number of concepts with broad application across
domains, but different names. For the sake of consistency, we resort to
automotive naming only (i.e. from ISO26262).

Integrity levels. There are multiple integrity levels that describe different
levels of acceptable risk. They are referred to as Automotive Safety Integrity
Levels (ASIL) in the context of automotive, with ASIL-D being the most
stringent ASIL, and ASIL-A the least stringent yet with some safety
requirements. Finally, an additional level named Quality Managed (QM) is used
to refer to items with no safety requirement at all.

Dual (DMR) and Triple Modular Redundancy (TMR). Systems with the highest
integrity levels are often realized building on DMR or TMR for error detection
and/or correction. In the particular case of automotive systems, ASIL-D
components are generally deployed on Dual-Core Lockstep (DCLS) CPUs. DCLS is
an efficient implementation of time and space redundancy for computing cores
where the same software runs on two identical cores, but with some staggering
(time shift) among them so that a fault affecting both cores simultaneously
would cause different errors – if any – due to their different state. Hence,
errors are detectable by means of simple comparison since redundancy is
_diverse_. The potential sources for faults affecting redundant cores, as well
as their impact, have been carefully analyzed [13], and caveats to deal with
the impact of such faults provided [14].

Safe state. Many systems have a safe state, i.e. a state that, whenever
reached, guarantees system safety. For instance, the safe state could consist
of a successful transfer of the control to the driver in the case of partially
autonomous cars, or stopping the car in a safe location. Reaching such safe
state may imply that the corresponding safety system is no longer working.
Hence, the safe state may affect the availability of the faulty component or
the overall system. Systems lacking a safe state are often referred to as
fail-operational systems, whereas those with a safe state are referred to as
fail-safe systems. Note that fault tolerance (for fail-operational systems)
and safe states (for fail-safe systems) are intended to be achieved at a given
system level, but failures may be allowed at lower levels. For instance, a job
of the task controlling the braking system may fail due to a soft error, so
that we have a failure at the scope of such microcontroller. However, at a
higher level we may have multiple redundant units and a voting system to
achieve fault tolerance, or mechanisms to detect the error and potentially
enforce a lower driving speed (i.e. a potential safe state) if such fault
occurs too often and challenges the timeliness of the braking system.

Fault Tolerant Time Interval (FTTI). From the time a fault occurs until it is
properly controlled, there is a maximum time affordable in which no hazard can
occur. That time interval is referred to as FTTI in automotive, and determines
the time needed to recover normal operation, or to reach a safe state where,
despite availability may be harmed, safety is preserved.

###  II-C Related Work

This paper presents a safety island explicitly conceived to provide advanced
safety services to an HPC device. However, other works such as that by Siemens
[1] already envision their own safety island, and some HPC platforms targeting
mainly the automotive domain, such as the Intel Go platform [2] and the NVIDIA
DRIVE AGX Orin [3, 4] already include an automotive ASIL-D compliant
microcontroller as a form of “safety island”. In the case of Siemens, their
safety island [1] aims at providing a safe enclave for execution and post-
mortem test capabilities for the HPC device but, to our knowledge, it lacks
advanced observability and controllability features, as well as safety
measures, intended to preserve safe operation in the HPC device despite
errors, as opposed to our concept. In the case of the HPC platforms with
ASIL-D compliant microcontrollers, such automotive microcontroller is an
Infineon AURIX processor in both cases, which is primarily intended to operate
as a standalone microcontroller. However, if configured properly, it can
provide some of the services provided by the safety island described in this
paper, potentially with lower efficiency due to the lack of explicit hardware
support for some features, such as multicore interference monitoring and
diverse redundancy support for the cores in the HPC device.

For the realm of IoT, the safety island on Intel’s Atom® x6000FE Series [15]
enables functional safety (FuSa) capabilities that detect and attenuate a
system fault before it causes or exacerbates further errors (if using the
fault $\rightarrow$ error $\rightarrow$ failure sequence terms as described
in[16]). Functionality includes fault monitoring and reporting, on-demand
diagnostics measurements, watchdog timers, temperature monitoring, self-
diagnostics of the safety island itself and encoding/decoding of communication
protocols between the safety island and other external elements.

In the area of security, some Arm processors include the Arm TrustZone [7],
which is a form of highly-coupled security island providing a security enclave
in Arm processors. Hence, despite with different purposes (security instead of
safety), and with a particular degree of coupling (only for a highly-coupled
implementation), Arm’s TrustZone has some commonalities with the safety
island.

##  III Architecture of our Safety Island

Figure 2: Schematic of our Safety Island.

Our goal is presenting a safety island with a number of specific
characteristics as follows:

  * •

Include features for monitoring and controlling the behavior of an HPC device,
as well as capabilities to accurately diagnose the cause of any error so that
the most effective remedy can be applied.

  * •

Be suitable for its realization as a chiplet, hence easing integration with
COTS HPC devices, and minimizing integration challenges.

  * •

Be built on open source technologies as much as possible to ease its adoption
and extension by the community.

This section presents our safety island, including key design and integration
considerations for its effectiveness.

###  III-A Safety Features of our safety island

The purpose of our safety island is providing HPC devices with appropriate
capabilities to execute performance-demanding applications while preserving
their safety requirements. As explained before, safety-related systems require
a number of features that can be generally classified into the following
categories.

####  III-A1 Controllability Features

Controllability features are needed to guarantee that execution conditions for
safety-relevant applications are controlled to a sufficient extent (e.g.,
limiting mixed-criticality interference, guaranteeing some performance levels,
etc.).

##### Proactive Features

This type of features includes the ability to restrict the operation of HPC
components whenever needed by setting appropriate configurations (e.g.,
network-on-chip (NoC) policies, cache replacement policies, cache sharing
policies, shared resource usage quotas, etc.) so that safety requirements can
be implemented through the safety island without introducing disruptive
changes in the HPC processor.

##### Reactive Features

Alternatively, if some behavior cannot be avoided by means of appropriate
configurations, monitoring capabilities are needed to detect misbehavior
(e.g., abnormal error detection rates in caches, overutilization of some
components, etc.), diagnose the cause, and take actions to mitigate such
misbehavior (e.g., stalling the offending process for a while).

####  III-A2 Observability Features

Observability features are critically important during both system validation
and operation. During system validation, they allow collecting detailed
information of the behavior of the overall system. The information can be from
individual hardware and software components. This information can then be
processed offline to detect any misbehavior. Such observability features
typically decrease the need for longer test campaigns, since they ease
obtaining the evidence; evidence whether some behavior occurs or not. In some
circumstances, observability feature may be mandatory to detect certain
behavior that is not observable otherwise. Those features are expected not
only to identify specific situations, but to provide enough information to
ease diagnosis to mitigate the source of the unexpected situations.

Observability features are fundamental during operation since they can be
linked to – reactive – controllability features, as indicated before, as well
as to safety measures that require detailed diagnostics to guarantee safety
without impacting other key metrics such as availability and performance.

The type of information to be observed and how it is collected is highly
diverse and must be properly tailored to not incur excessive cost. For
instance, one could trace all transactions across two components (e.g., across
a shared cache and DRAM memory) or summarize them by counting the amount of
data transferred over a period of time. The former may require tracking each
individual address accessed along with some information about the transaction
(e.g., whether it is a read or store operation, amount of data transferred,
etc.), which requires huge storage but provides highly detailed information,
whereas the latter provides much less information but only needs few counters
to track the amount of data transferred potentially broken down across
components originating the transactions (e.g., across cores, accelerators,
etc.).

Overall, it is key to enable the safety island with appropriate support to
collect different types of traces, and either output them at high speed, or
compress them on-the-fly to generate compressed logs for a “post-mortem”
analysis. Information to be monitored includes abnormal performance behavior,
activity in shared resources (e.g., NoCs, caches and memory controllers), etc.
Also, programmable filters to monitor only specific subsets of information are
highly convenient.

####  III-A3 Safety Measures

Random hardware faults and sporadic abnormal performance conditions are
generally unavoidable. The safety island must provide capabilities to monitor
faults, diagnose the cause, tolerate some of them, and contain the impact of
all of them so that software layers can easily and timely manage errors and
preserve fault-free operation at all times.

Some safety measures can be implemented by mostly relying on controllability
and observability features already described before, but some others may
require additional support. For instance, hardware or software monitors may be
needed so that, upon the detection of abnormal behavior in the HPC device,
specific corrective actions are taken (e.g., resetting specific components,
switching to a degraded operation mode, etc.). Since those monitors may have
the highest integrity levels, they may require DMR or TMR support in the
safety island. Similarly, error detection capabilities for the HPC device may
require the safety island to orchestrate some form of diverse and redundant
execution on the HPC device regardless of whether the HPC device has specific
hardware support for that.

###  III-B Hardware Integration Considerations

Integration of the safety-relevant features with the HPC device (aka as HPC
island) to be mastered is a challenging concern. The higher the coupling
between the safety island and the HPC island, the higher the efficiency of the
safety island due to having higher controllability and observability, but the
lower the modularity since mutual dependencies across the safety and HPC
islands would increase. For instance, two extremes of the integration could be
as follows:

  * •

Coupled integration: the islands could be integrated connecting the safety
island as a master to the different interconnects in the HPC island (e.g., all
AMBA interconnects). This would grant detailed observability and
controllability to the safety island, which would have direct information from
the different internal interfaces, and could react almost immediately to any
predefined event. On the other hand, such integration would be highly device-
specific, hence potentially requiring non-negligible modifications to tailor
the safety island to a particular HPC device.

  * •

Loose integration: the safety island could be encapsulated into a chiplet with
standard predefined interfaces agnostic of the particular characteristics of
the HPC device to be mastered. This approach would favor portability and
modularity, but would be detrimental for observability and controllability
purposes since (i) some interfaces may not be directly observable, and (ii)
access to the connected interfaces may have higher latency than in the coupled
approach, hence increasing reaction time, which ultimately may inhibit the use
of some safety measures requiring immediate actions (e.g., to avoid error
propagation).

When integrating both islands, the safety island and the HPC island, it is
critically important to understand what is reachable (and how) through the
existing interfaces to program the safety island accordingly (e.g., monitoring
modules, traffic injection modules). Note that, even if some parts of the chip
are not directly reachable by the safety island, they may still be managed
indirectly. For instance, one could inject traffic reaching specific devices
attached to not directly reachable interconnects, and observe the latency to
obtain a response to guess the amount of load in that interconnect.

####  III-B1 Chiplets

While integrating all features in a single chip die generally provides
advantages in terms of power and performance, some issues are driving industry
towards the use of chiplets instead. In particular, single-chip solutions
hinder chip reuse, may lead to lower yield due to the increased number of
transistors per chip, and provide diminishing returns in terms of performance
as the chip size grows.

Instead, chiplets provide a number of key advantages, particularly relevant
for the safety island: (1) they allow for chip reuse, so the same safety
island can be used for different HPC devices. (2) Designs can be specialized
for efficiency reasons, hence not needing to build a single chip for all
targets. (3) Heterogeneous technologies can be used across different chiplets,
hence easing integration. (4) Due to being smaller and simpler devices than
monolithic chip solutions, they ease testability. Finally, (5) their smaller
size allows increasing yield.

Still, chiplets have to face some challenges that relate to using larger
boards to accommodate multiple chiplets, increased latency for chiplet-to-
chiplet communication, increased reliability concerns due to the increased
number of soldered joints, thermal/mechanical constraints to place multiple
chiplets together, and the lack of chiplet-to-chiplet communication standards,
although the Universal Chiplet Interconnect Express (UCIe) has recently
appeared to mitigate the latter.

####  III-B2 Physical and Logical Integration

A number of integration aspects related to the physical location of the
different chips and the communication interfaces emerge in chiplet-based
solutions. For instance, UCIe provides a physical solution to manage the
integration of multiple chiplets. However, the particular protocols to be used
to communicate chiplets over such communication interface remain to be
defined.

Analogously, whenever multiple chiplets are deployed, the physical location of
the different chiplets, including memories, must be carefully laid out to
maximize performance, while minimizing power, area and reliability concerns.
Also, it must be carefully analyzed which chiplets need to interact. For
instance, it is unclear whether all or just a subset of the chiplets need to
access main memory, whether it is better deploying memory controllers in all
chiplets or concentrating memory access through a single chiplet, whether some
specific memory technologies are more convenient than others when using
chiplets. Overall, new integration-related challenges emerge when using
chiplets.

Aspects related to the power supply, power domains, and power monitoring must
also be taken into account since the safety island is intended to be used for
safety critical functionalities. In general, the safety island inherits
similar requirements to those of any other safety-relevant microcontroller.
Using other chiplets for other devices (e.g., for the HPC device) brings
increased costs, as mentioned before, but may ease implementing some safety
measures since physical segregation, in general, reduces the number of
potential single-point faults.

###  III-C System Software Considerations

A number of observability and controllability features in the safety island
may require accessing specific modules in the HPC island such as, memory
interfaces to inject traffic, or configuration registers to exercise control
on the HPC device. However, existing Memory Management Units (MMUs) or
Input/Output MMUs (IOMMUs) may exercise control on the permissions and
privileges to access (and potentially modify) different components in the HPC
island. Therefore, it becomes critically important that the safety island – or
the system software on its behalf – is capable of properly configuring
permissions and privileges (e.g., at boot time) so that it can perform its
work during operation. Note that such boot and configuration process is not
exempt of security risks, and, hence, is a delicate process that needs to
follow appropriate rules for a secure boot and configuration. Additionally, in
order to retain flexibility, namely in regards to fault tolerance and
containment, permissions and privileges should as well be configurable at
runtime. However, such flexibility can equally incur security risks if the
reconfiguration interface represents a single point of failure and can be
directly manipulated by exploiting, e.g., a page table vulnerability.

Another software aspect relates to the fact that user level software with
safety requirements may need to run on the safety island. For instance,
control applications needing native DCLS only available in the safety island
may require running on the cores of the safety island. Similarly, some parts
of the applications needing to run on the HPC island may also need to run on
the safety island. To guarantee a safe environment, virtualization becomes
mandatory as well as an appropriate hypervisor or real-time operating system
(RTOS) providing partitioning services to those applications, such as fentISS’
XtratuM [17], SYSGO’s PikeOS [18], GMV-Portugal’s Air [19], Lynx Software
Technologies’ LynxSecure, Wind River’s hypervisor, Green Hill’s Integrity,
Continental’s OSEK VDX, and Erika Enterprise, to name a few.

###  III-D System Safety Considerations

The integration of the safety and HPC islands is not exempt of some safety
considerations, mostly related to the hardware and software considerations
above. A key safety consideration relates to the latency to retrieve
information from the HPC island as well as to exercise control. Coupled
integrations generally lead to lower latencies, which favor decreased safety
risks, as opposed to loose integrations.

The ability to observe and control the HPC island with low latency is key for
a number of safety-related aspects such as fault containment and reaction
times at system level. For instance, in the context of automotive safety-
relevant systems, an FTTI is defined, as explained before. Exceeding that FTTI
implies that hazards can occur potentially violating the safety goals of the
system. Therefore, the safety island design and integration must be planned to
adhere to safety considerations relevant at hardware, software and system
level.

###  III-E Security Considerations

While the goal of the safety island is providing safety capabilities, it must
realize some security support to avoid its improper use. Security aspects
relevant for the safety island include authentication, permissions and secure
boot.

The safety island must realize a secure boot process, in cooperation with
software, to guarantee that software executed during booting, as well as
drivers loaded, come from legitimate sources. Authentication is also key if
any such software requires being updated with updates being initiated by
external sources.

During operation, in order to monitor and even control the HPC device,
appropriate permissions must be set in the configuration of the HPC device so
that safety island actions are allowed. In that context, authentication
becomes fundamental since analogous actions triggered by devices other than
the safety island must not be allowed. Some technologies, such as Intel’s CSME
(Converged Security and Management Engine) [20] provide capabilities to
authenticate and load firmware into relevant IPs. Such type of technology
could be expanded towards use among chiplets, allowing for example the safety
island to authenticate itself towards the cores in the HPC device.

###  III-F Extendability Considerations

The use of a safety island, especially if conceived as a separate chiplet,
brings opportunities in terms of extensions and updates. For instance,
improved safety island designs can be deployed along with a given HPC device
without needing to update the latter. Such improvements may come in the form
of extensions to enable more efficient means to manage safety aspects (e.g.,
resorting to hardware support instead of software-only solutions), such as
enhanced monitoring units, or more powerful cores in the safety island to
perform specific services (e.g., implementing domain-specific ISA extensions
in the safety island cores). Such extensions can be also realized deploying an
eFPGA in the safety island so that a firmware update suffices, hence avoiding
physical changes.

##  IV Key Components and Technologies

Realizing a safety island requires an SoC capable of executing safety-relevant
functionalities, as well as capable of providing safety services to the HPC
island. To build a functional and open source safety island, we identify a
number of existing and under development components and technologies that need
to be consistently integrated to form the safety island. Some of those
components and technologies are introduced in this section.

###  IV-A Baseline MPSoC

As part of the H2020 SELENE project, an open source RISC-V based MPSoC
suitable for the space, automotive and railway domains has been released [21].
The SELENE SoC offers a 6-core multicore based on Gaisler’s NOEL-V cores [22]
and other GPL IPs [23]. Moreover, it includes a wide subset of the IPs
described in the remaining of this subsection that make it further appropriate
as the starting point to develop a safety island.

However, there are other alternatives. Unfortunately, high-performance RISC-V
cores are mostly proprietary, such as SiFive’s P650 and others. Some open
source cores have been recently compared [24], including Rocket [25], BOOM
[26], CVA6 [27], and SHAKTI [28] C-Class implementations. No core is proven
superior to the others in all fronts with varying conclusions for both ASIC
and FPGA realizations if we consider performance, power efficiency, area, or
maintainability.

###  IV-B Multicore Interference Monitors

A key safety service in multicores relates to monitoring the interference
across cores or other type of devices (e.g., accelerators) since such
interference may affect real-time guarantees for safety-critical real-time
tasks. Recently, the Safe Statistics Unit (SafeSU) [29, 30] has been proposed.
It provides capabilities to monitor the traffic in AMBA interfaces such as AHB
and AXI4, although its design has been made modular to enable its porting to
other interfaces. The SafeSU allows measuring the interference each master
device causes on each other device in different interfaces, and has been
successfully integrated in the SELENE SoC [31]. It remains to be studied how
to tailor it to monitor the traffic in remote interconnects rather than those
in the safety island itself.

###  IV-C Multicore Interference Quotas

The SafeSU [29, 30] has also been equipped with an interference control
mechanism building on its interference monitoring capabilities. In particular,
the SafeSU allows programming interference quotas that, upon being exceeded,
trigger interrupts that can be immediately captured by the hypervisor or RTOS
so that any action needed can be taken, in accordance with system needs (e.g.,
dropping the offending task, stalling it for a while, increasing QoS
guarantees for the offended task). These interrupts have been properly
connected to the corresponding interrupt controller at hardware level and
successfully captured by the operating system on top, so the integration of
the SafeSU with the software layers is simple.

###  IV-D Performance Validation

While monitoring and quota features during operation are key features needed
for the design of the system, such system must be thoroughly tested to
guarantee that timing overruns will not occur making deadline violation risk
residual. Software tests provide limited controllability to exercise all
performance corners since multicore interference scenarios can only be induced
indirectly and, in some cases, without synchronous control. For instance, some
traffic with long bursts can only be produced by devices such as Ethernet
ports of the Direct Memory Access (DMA) controller, which are too hard to
synchronize with traffic produced by the computing cores. To tackle this
issue, the Safe Traffic Injector (SafeTI) [32] has been recently proposed. It
allows programming arbitrary traffic patterns, including delays between
consecutive transactions, fully synchronously, and allowing to generate any
type of traffic including read/write, with arbitrary data transfer sizes,
with/without burst behavior, etc., including repeated traffic, as well as
fixed-size and infinite traffic patterns. As for the SafeSU, it remains to be
studied how to tailor the SafeTI to inject traffic in the HPC island from the
safety island.

###  IV-E Diverse Redundancy for Cores

Functionalities with the highest integrity level (e.g., ASIL-D in automotive)
require diverse redundancy in several domains, which is efficiently
implemented with DCLS. Hence, at least some cores in the safety island need to
implement DCLS. The SafeLS realizes DCLS for NOEL-V cores in the SELENE SoC
[33]. However, as explained before, DCLS is generally expensive if not needed
for some tasks since redundant cores are not user visible. Hence, different
flavors of diverse redundancy can be deployed providing different tradeoffs,
such as allowing cores to be used independently, although failing to provide
diverse redundancy for I/O code. This is the case of the Safe Diversity
Monitor (SafeDM) module [34], which allows measuring whether diversity exists
across two cores. Conversely, the Safe Diversity Enforcement (SafeDE) [35]
module allows enforcing some time staggering, and hence, diversity across two
cores running a task redundantly. The SafeSoftDR software module [36] could be
used instead since it provides the same functionality as SafeDE in a less
efficient manner but without requiring any hardware support. A comparison
across the different mechanisms can be found in [37].

Note that, DCLS is intrinsically highly coupled with the redundant cores, and
hence, only available for the safety island. Instead, SafeDE, SafeDM and
SafeSoftDR can manage diversity for non-DCLS cores. Therefore, they can be
tailored to deliver diverse redundancy to cores in the HPC island from the
safety island.

###  IV-F Diverse Redundancy for Accelerators

Full redundancy for accelerators such as GPUs is generally not present in HPC
devices. Therefore, it is not possible orchestrating diverse redundancy across
multiple accelerator instances as done for cores with SafeDE and SafeSoftDR.

However, accelerators are often highly parallel and offer large internal
redundancy this has been leveraged in some works to implement some form of
diverse redundancy with appropriate software and hardware support [38, 39].
This type of support can be potentially integrated in the safety island, which
can, for instance, offload redundant kernels in a GPU of the HPC island
inducing diversity with different means (e.g., intrinsics support, scheduling
policy characteristics).

In the context of Deep Neural Networks (DNNs), high – yet not perfect –
accuracy rates are obtained for processes such as object detection and
classification. DNNs often rely on approximation and stochastic behavior, and
hence, do not generally require bit-level precision. Instead, high – yet not
full – precision is wanted at semantic level (e.g., properly detecting and
classifying an object) regardless of whether the accuracy is a bit higher or
lower. In that context, it is possible deploying lower-cost and approximate
(e.g., using lower precision arithmetic) accelerators in the safety island
providing diverse redundancy to large and precise accelerators in the HPC
island as long as the former are capable of detecting large deviations for the
predictions of the latter [40]. Such DMR scheme has already been realized in
[41].

###  IV-G Watchdogs

As part of the architectural design of safety-related functionalities,
watchdogs are popular since they allow checking the aliveness of specific
components. At hardware level, watchdogs are also popular and, in the context
of the safety island, they can be deployed to monitor the aliveness of
specific components in the safety island as well as in the HPC island (or the
complete HPC island).

Generally, watchdogs are expected to be made sufficiently independent of the
item being monitored, e.g., with independent clock and power supply. Hence,
this is expected to hold by construction in the case of loose integration of
the safety island. However, specific design rules must be followed for both
coupled integration of the safety and HPC islands, and watchdogs monitoring
components part of the safety island itself.

Watchdogs can monitor clock signals, cycle counters, instruction counters, or
time-to-response for some devices. For instance, one could couple a watchdog
to the SafeTI so that the latter sends a request requiring response to a
specific component in the HPC island, while the watchdog awaits for an answer
within a specific time bound. If such response does not arrive timely, the
watchdog may raise an interrupt to be captured by the system software in the
safety island.

###  IV-H Virtualization Extensions

Hypervisors and RTOSs, often required in safety-critical systems, require
appropriate virtualization capabilities to offer partitioning services to the
guest operating system. Such virtualization can only be realized if supported
by the hardware platform. Hence, virtualization extensions become mandatory
for the safety island. For instance, the aforementioned NOEL-V cores in the
SELENE SoC implement such extension and have been proven effective to run
hypervisors on top, such as fentISS’ XtratuM [42, 17].

###  IV-I Logging Support

Most HPC devices include some form of tracing support. However, information
traced can be abundant and produced continuously, which, in general, requires
a host computer to process it. Such information can be of much use to diagnose
the source of some errors, or, at least, to enable reproducibility for
diagnostics purposes. The safety island can act as such host computer.
However, storage capabilities are limited for the safety island (e.g.,
typically KBs for on-chip storage and MBs for off-chip storage), and hence,
either information is dropped by, for instance, retaining the most recent
traced information only, or summarized in the form of logs. Retaining recent
information can be easily done with trace buffers where information is stored
using a FIFO policy. Logging requires, instead, a tradeoff between the details
retained and the hardware cost to retain them. The higher the degree of
information loss, the lower the cost to store remaining information. For
instance, one can track timestamps for specific events, which would require
large storage capabilities or restricting trace recording to a limited time
window. Alternatively, one could use counters to track occurrences of those
events – potentially broken down across multiple categories, with much lower
storage cost, but losing information relative to the timing of those events.
For instance, some authors proposed an error logger for caches tracking error
location to diagnose permanent faults [43].

###  IV-J Chiplet Integration Technologies

In case of a loose integration with a chiplet-based safety island, Universal
Chiplet Interconnect Express (UCIe) comes as the standardizing solution to
die-to-die interconnectivity. The layered protocol specifies a die-to-die
adapter layer and a protocol layer, the latter supporting PCIe or CXL, with
further protocol mappings planned. This requires, however, that communicating
chiplets adhere to standards. For instance, UCIe’s specification does not
cover packaging/bridging technology used to provide the physical link between
chiplets. It is bridge-agnostic, meaning chiplets can be linked via different
mechanisms such as fanout bridge, silicon interposers (i.e. 2.5D packaging) or
other packaging technologies such as 3D packaging. Nevertheless, standards
such as bump pitch, must be taken into account, meaning RISC-V platforms would
require dedicated, standardized support for UCIe, which could potentially
hinder observability.

In terms of packaging technology, for instance, Intel’s EMIB (Embedded Multi-
Die Interconnect Bridge) is a 2.5D packaging technique used to connect dies on
the same substrate. 2.5D refers to the integration of dies/chiplets on a
substrate using an interposer. It brings specific advantages such as larger
die count and larger package configurations, lower cost than full size silicon
interposer and support for high data rate signaling between adjacent die.

3D packaging is an alternative to interposers. 3D packaging refers to the
direct high-density interconnection of chips through TSV (through-silicon
via). In 3D packaging, chiplets are placed on top of one another instead of
horizontally next to one another, forming a 3D structure with each chiplet
occupying a layer. Finally, the interposer connects the 3D assembly of the
chiplet with the substrate. For instance, Foveros is a high-performance 3D
packaging technology.

##  V Other Applications

The safety island can be used, for obvious reasons, in contexts where system
requirements include the combination of high-performance needs and safety
requirements. However, most of its features can provide other type of services
to HPC devices, such as, security and Reliability, Availability and
Serviceability (RAS). Therefore, there is a broad area of application for the
safety island beyond safety requirements strictly. For the sake of
illustration, we introduce the use of the safety island for RAS and security
applications in the remaining of this section.

###  V-A RAS

HPC devices used for servers and supercomputers, to name some application
domains, have strict RAS requirements. This relates to the relatively higher
criticality of the applications run in those domains when compared with most
desktop computers, as well as the much higher exposure to faults due to having
very high occupancy and, in the context of supercomputers, typically thousands
of computing nodes operating in parallel cooperatively. For instance, in the
case of a supercomputer where parallel applications required on average 1,000
CPUs, acceptable failure rates would decrease at least by a factor of 1,000
with respect to single-CPU computers.

Components such as the SafeSU or watchdogs can provide error detection
capabilities able to trigger recovery actions at software level. Analogously,
logging features can be used to assist recovery by providing relevant
information about the error detected, or can also be used to anticipate
unrecoverable errors by monitoring recoverable ones. For instance, permanent
faults can be detected by diagnosing error location with specific logging
capabilities so that appropriate actions (e.g., CPU replacement in a
supercomputer) can be taken before permanent faults lead to any unrecoverable
error.

###  V-B Security

It is well-known that all safety-critical systems are also security-critical.
This relates to the fact that unintended failures in safety-critical systems
could be produced intendedly by an attacker, hence creating at least similar
risks. The opposite, instead, is not true, and systems can be security-
critical but not safety-critical (e.g., a system managing personal
information).

A subset of the security concerns have analogous behavior to that of the
safety concerns, being the only difference whether their root cause is
intended (security concerns) or unintended (safety concerns). For instance,
abuse in the access to shared resources may be caused by a faulty application
or by a malicious attack. In both cases, the SafeSU could be leveraged to, at
least, detect the abuse and take corrective actions. Tracing and logging
features could be used to discern intended from unintended attacks based on
their history or frequency of occurrence, for instance.

Security concerns may often require countermeasures to stop or fool attacks.
Components such as the SafeTI may be leveraged for that purpose generating
traffic that degrades the ability of the attacker to deduce information from
the victim. For instance, in the case of side-channel attacks learning from
memory access patterns of the victim, traffic can be injected making the
attacker believe such traffic belongs to the victim so that wrong conclusions
are reached (e.g., obtaining a wrong key or failing to narrow down enough the
possibilities for the victim’s key).

In any case, if the safety island is also used for security purposes, a number
of additional security-specific technologies may need to be added to the
safety (now safety-and-security) island, such as cryptographic accelerators,
and means for detecting and defeating attacks. Note that those security-
related features focus on providing security services to the HPC device,
whereas those discussed in Section III-E focus on making safety island
operation secure.

##  VI Conclusions

There is an increasing need for the use of HPC devices in safety-critical
systems, but those devices lack enough controllability and observability
channels, as well as adequate support to realize key safety measures. Hence,
solutions are required to enable the safe use of HPC devices.

This paper presents our concept of a safety island and its main constituents
to enable the safe use of HPC devices for safety-critical systems. In
particular, we analyzed some key tradeoffs related to the degree of coupling
of the safety and HPC islands, identified key components needed or highly
convenient to have in the safety island to fulfill its due, and assessed some
other types of applications of the safety island with overlapping needs, such
as applications with RAS and/or security requirements.

## Acknowledgements

BSC authors contribution is part of the project (ISOLDE), funded by
MCIN/AEI/10.13039/501100011033 and the European Union NextGenerationEU/PRTR,
and the European Union’s Horizon Europe Programme under project KDT Joint
Undertaking (JU) under grant agreement No 101112274. This work has also been
partially supported by the Spanish Ministry of Science and Innovation under
grant PID2019-107255GB-C21 funded by MCIN/AEI/10.13039/501100011033.

## References

  * [1] Siemens, “Automotive safety island. management of test, safety, and security data at the edge for ISO 26262,” 2021, white paper.
  * [2] Intel Corporation, “Intel GO Automated Driving Solutions – Product brief,” 2017, https://newsroom.intel.com/newsroom/wp-content/uploads/sites/11/2017/01/intel-go-product-brief.pdf.
  * [3] J.F. Mccarthy, “NVIDIA Drive program. https://developer.nvidia.com/drive,” 2018.
  * [4] NVIDIA, “DRIVE OS for DRIVE AGX – NVIDIA DRIVE OS 6.0 Linux SDK Developer Guide,” 2022, https://developer.nvidia.com/docs/drive/drive-os/archives/6.0.3/linux/sdk/oxy_ex-1/common/topics/mcu_setup_usage/mcu_setup_and_usage1.html.
  * [5] “Intel packaging technology,” https://www.intel.com/content/www/us/en/silicon-innovations/6-pillars/process.html.
  * [6] RISC-V International, “RISC-V International website,” https://riscv.org/.
  * [7] Arm, “Learn the architecture - TrustZone for AArch64,” 2021, https://developer.arm.com/documentation/102418/0101/?lang=en.
  * [8] International Standards Organization, _ISO/DIS 26262. Road Vehicles — Functional Safety_ , 2009.
  * [9] European Committee for Electrotechnical Standardization (CENELEC), _EN 50126 - Railway Applications - The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS)_ , 2017.
  * [10] ——, _EN 50128 - Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems_ , 2020\.
  * [11] ——, _EN 50129 - Railway applications - Communication, signalling and processing systems - Safety-related electronic systems for signalling_ , 2018\.
  * [12] International Electrotechnical Commission, _IEC 61508. Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems_ , 1998.
  * [13] P. Tummeltshammer and A. Steininger, “On the risk of fault coupling over the chip substrate,” in _2009 12th Euromicro Conference on Digital System Design, Architectures, Methods and Tools_ , 2009, pp. 325–332.
  * [14] T. Kottke and A. Steininger, “A generic dual core architecture with error containment,” _Computing and Informatics_ , vol. 23, no. 5-6, pp. 517–535, 2004.
  * [15] Intel Corporation, “Elkhart Lake: overview and technical documentation,” https://www.intel.com/content/www/us/en/products/platforms/details/elkhart-lake.html.
  * [16] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy of dependable and secure computing,” _IEEE transactions on dependable and secure computing_ , vol. 1, no. 1, pp. 11–33, 2004.
  * [17] fentISS, “XtratuM Hypervisor,” https://fentiss.com/products/hypervisor/ (accessed Feb-2021).
  * [18] J. Bredereke, “A survey of time and space partitioning for space avionics,” _Technical Report, City University of Applied Sciences Bremen_ , 2017.
  * [19] B. Gomes, D. Silveira, L. Gouveia, and L. Mendes, “Air hypervisor using RTEMS SMP,” in _European Workshop on On-Board Data Processing (OBDP2019), ESTEC (ESA)_ , 2019.
  * [20] “The Intel® converged security and management engine iommu hardware issue – CVE-2019-0090 and CVE-2020-0566,” 2020, https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/cve-2019-0090-whitepaper.pdf.
  * [21] C. Hernàndez, J. Flieh, R. Paredes, C.-A. Lefebvre, I. Allende, J. Abella, D. Trillin, M. Matschnig, B. Fischer, K. Schwarz, J. Kiszka, M. Rönnbäck, J. Klockars, N. McGuire, F. Rammerstorfer, C. Schwarzl, F. Wartet, D. Lüdemann, and M. Labayen, “Selene: Self-monitored dependable platform for high-performance safety-critical systems,” in _2020 23rd Euromicro Conference on Digital System Design (DSD)_ , 2020, pp. 370–377.
  * [22] Cobham Gaisler, “NOEL-V processor,” https://www.gaisler.com/index.php/products/processors/noel-v (accessed Feb-2021).
  * [23] ——, “GRLIB IP Library,” https://www.gaisler.com/index.php/products/ipcores/soclibrary (accessed Jan-2023).
  * [24] A. Dörflinger, M. Albers, B. Kleinbeck, Y. Guan, H. Michalik, R. Klink, C. Blochwitz, A. Nechi, and M. Berekovic, “A comparative survey of open-source application-class risc-v processor implementations,” in _Proceedings of the 18th ACM International Conference on Computing Frontiers_ , 2021, pp. 12–20.
  * [25] K. Asanovic, R. Avizienis, J. Bachrach, S. Beamer, D. Biancolin, C. Celio, H. Cook, D. Dabbelt, J. Hauser, A. Izraelevitz _et al._ , “The rocket chip generator,” _EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2016-17_ , vol. 4, 2016.
  * [26] C. Celio, P.-F. Chiu, K. Asanović, B. Nikolić, and D. Patterson, “BROOM: an open-source out-of-order processor with resilient low-voltage operation in 28-nm CMOS,” _IEEE Micro_ , vol. 39, no. 2, pp. 52–60, 2019\.
  * [27] OpenHW Group, “CORE-V family of open-source RISC-V cores,” 2023, https://github.com/openhwgroup/core-v-cores.
  * [28] N. Gala, A. Menon, R. Bodduna, G. Madhusudan, and V. Kamakoti, “SHAKTI processors: An open-source hardware initiative,” in _2016 29th International Conference on VLSI Design and 2016 15th International Conference on Embedded Systems (VLSID)_. IEEE Computer Society, 2016, pp. 7–8.
  * [29] G. Cabo, F. Bas, R. Lorenzo, D. Trilla, S. Alcaide, M. Moreto, C. Hernandez, and J. Abella, “SafeSU: an extended statistics unit for multicore timing interference,” in _IEEE European Test Symposium (ETS)_ , 2021.
  * [30] G. Cabo, S. Alcaide, C. Hernandez, P. Benedicte, F. Bas, F. Mazzocchetti, and J. Abella, “SafeSU-2: Safe statistics unit for space MPSoCs,” in _IEEE Design, Automation and Test in Europe Conference (DATE)_ , 2022.
  * [31] P. Andreu, C. Hernandez, T. Picornell, P. Lopez, S. Alcaide, F. Bas, P. Benedicte, G. Cabo, F. Chang, F. Fuentes, and J. Abella, “End-to-end qos for the open source safety-relevant risc-v selene platform,” 2022. [Online]. Available: https://arxiv.org/abs/2210.04683
  * [32] O. Sala, S. Alcaide, G. Cabo, F. Bas, R. Lorenzo, P. Benedicte, D. Trilla, G. Gil, F. Mazzocchetti, and J. Abella, “SafeTI: a hardware traffic injector for mpsoc functional and timing validation,” in _IEEE International Symposium on On-Line Testing and Robust System Design (IOLTS)_ , 2021, pp. 1–7.
  * [33] M. Sarraseca, S. Alcaide, F. Fuentes, J. Rodriguez, F. Chang, I. Lasfar, R. Canal, F. Cazorla, and J. Abella, “SafeLS: an open source implementation of a lockstep NOEL-V RISC-V core,” in _IEEE International Symposium on On-Line Testing and Robust System Design (IOLTS)_ , 2023\.
  * [34] F. Bas, P. Benedicte, S. Alcaide, G. Cabo, F. Mazzocchetti, and J. Abella, “SafeDM: a hardware diversity monitor for redundant execution on non-lockstepped cores,” in _IEEE Design, Automation and Test in Europe Conference (DATE)_ , 2022, pp. 1–6.
  * [35] F. Bas, S. Alcaide, R. Lorenzo, G. Cabo, G. Gil, O. Sala, F. Mazzocchetti, D. Trilla, and J. Abella, “SafeDE: a flexible diversity enforcement hardware module for light-lockstepping,” in _IEEE International Symposium on On-Line Testing and Robust System Design (IOLTS)_ , 2021, pp. 1–7.
  * [36] F. Mazzocchetti, S. Alcaide, F. Bas, P. Benedicte, G. Cabo, F. Chang, F. Fuentes, and J. Abella, “SafeSoftDR: a library to enable software-based diverse redundancy for safety-critical tasks,” in _FORECAST: Functional Properties and Dependability in Cyber-Physical Systems Workshop (held with HiPEAC conference)_ , 2022.
  * [37] R. Canal, F. Bas, S. Alcaide, G. Cabo, P. Benedicte, F. Fuentes, F. Chang, I. Lasfar, and J. Abella, “Safedx: Standalone modules providing diverse redundancy for safety-critical applications,” in _Embedded Computer Systems: Architectures, Modeling, and Simulation_ , A. Orailoglu, M. Reichenbach, and M. Jung, Eds. Cham: Springer International Publishing, 2022, pp. 383–393.
  * [38] N. Andriotis, A. Serrano-Cases, S. Alcaide, J. Abella, F. J. Cazorla, Y. Peng, A. Baldovin, M. Paulitsch, and V. Tsymbal, “A software-only approach to enable diverse redundancy on intel gpus for safety-related kernels,” in _38th ACM/SIGAPP Symposium On Applied Computing (SAC)_ , 2023.
  * [39] S. Alcaide, L. Kosmidis, C. Hernandez, and J. Abella, “Achieving diverse redundancy for gpu kernels,” _IEEE Transactions on Emerging Topics in Computing_ , vol. 10, no. 2, pp. 618–634, 2022.
  * [40] J. Fornt, P. Fontova, M. Caro, J. Abella, F. Moll, J. Altet, and C. Studer, “An energy-efficient gemm-based cnn accelerator with on-the-fly convolution lowering,” in _in TBD_ , 2023.
  * [41] M. Caro, J. Fornt, and J. Abella, “Efficient diverse redundant DNNs for autonomous driving,” in _IEEE International Conference on Computers, Software and Applications (COMPSAC)_ , 2023.
  * [42] G. Wessman et al., “De-RISC: the first RISC-V space-grade platform for safety-critical systems,” in _IEEE Space Computing Conference (SCC)_ , 2021\.
  * [43] J. Abella, P. Chaparro, X. Vera, J. Carretero, and A. González, “On-line failure detection and confinement in caches,” in _2008 14th IEEE International On-Line Testing Symposium_ , 2008, pp. 3–9.


* Albert Chib (1993) Albert93Albert, JH. Chib, S.  1993\.  Bayes Inference via Gibbs Sampling of Autoregressive Time Series Subject to Markov Mean and Variance Shifts Bayes inference via gibbs sampling of autoregressive time series subject to markov mean and variance shifts.  Journal of Business & Economic Statistics1111–15.  10.2307/1391303
  * Bańbura . (2010) Banbura10Bańbura, M., Giannone, D. Reichlin, L.  2010\.  Large Bayesian Vector Autoregressions Large Bayesian Vector Autoregressions.  Journal of Applied Econometrics25171–92.
  * Battulga (2022) Battulga22bBattulga, G.  2022\.  Stochastic DDM with regime–switching process Stochastic ddm with regime–switching process.  Numerical Algebra, Control and Optimization1–27.  10.3934/naco.2022031
  * Battulga (20231) Battulga23aBattulga, G.  20231\.  Parameter Estimation Methods of Required Rate of Return on Stock Parameter Estimation Methods of Required Rate of Return on Stock.  International Journal of Theoretical and Applied Finance2682450005.
  * Battulga (20232) Battulga23bBattulga, G.  20232\.  Rainbow Options with Bayesian MS-VAR Process Rainbow Options with Bayesian MS-VAR Process.  Mongolian Mathematical Journal26241-16.
  * Battulga (20241) Battulga24fBattulga, G.  20241\.  Equity–Linked Life Insurances on Maximum of Several Assets Equity–Linked Life Insurances on Maximum of Several Assets.  to appear in Numerical Algebra, Control & Optimization.  Available at: https://arxiv.org/abs/2112.10447.
  * Battulga (20242) Battulga24aBattulga, G.  20242\.  Options Pricing under Bayesian MS–VAR Process Options Pricing under Bayesian MS–VAR Process.  to appear in Numerical Algebra, Control & Optimization.  Available at: https://arxiv.org/abs/2109.05998.
  * Battulga . (2022) Battulga22aBattulga, G., Jacob, K., Altangerel, L. Horsch, A.  2022\.  Dividends and Compound Poisson–Process: A new Stochastic Stock Price Model Dividends and Compound Poisson–Process: A new Stochastic Stock Price Model.  International Journal of Theoretical and Applied Finance2532250014.
  * Butler (1998) Butler98Butler, RW.  1998\.  Generalized inverse Gaussian distributions and their Wishart connections Generalized inverse gaussian distributions and their wishart connections.  Scandinavian journal of statistics25169–75.
  * D’Amico De Blasis (2020) dAmico20aD’Amico, G. De Blasis, R.  2020\.  A Review of the Dividend Discount Model: from Deterministic to Stochastic Models A Review of the Dividend Discount Model: from Deterministic to Stochastic Models.  Statistical Topics and Stochastic Models for Dependent Data with Applications47–67.
  * Glasserman . (2000) Glasserman00Glasserman, P., Heidelberger, P. Shahabuddin, P.  2000\.  Variance reduction techniques for estimating value-at-risk Variance reduction techniques for estimating value-at-risk.  Management Science46101349–1364.
  * Glasserman Li (2005) Glasserman05bGlasserman, P. Li, J.  2005\.  Importance sampling for portfolio credit risk Importance sampling for portfolio credit risk.  Management science51111643–1656.
  * Goldfeld Quandt (1973) Goldfeld73Goldfeld, SM. Quandt, RE.  1973\.  A Markov model for switching regressions A markov model for switching regressions.  Journal of Econometrics113–15.
  * Hamilton (1989) Hamilton89Hamilton, JD.  1989\.  A New Approach to the Economic Analysis of Nonstationary Time Series and the Business Cycle A New Approach to the Economic Analysis of Nonstationary Time Series and the Business Cycle.  Econometrica: Journal of the Econometric Society357–384.
  * Hamilton (1990) Hamilton90Hamilton, JD.  1990\.  Analysis of Time Series Subject to Changes in Regime Analysis of Time Series Subject to Changes in Regime.  Journal of Econometrics451-239–70.
  * Hamilton (1994) Hamilton94Hamilton, JD.  1994\.  Time Series Econometrics Time Series Econometrics.  Princeton University Press, Princeton.
  * Karlsson (2013) Karlsson13Karlsson, S.  2013\.  Forecasting with Bayesian vector autoregression Forecasting with bayesian vector autoregression.  Handbook of economic forecasting2791–897.
  * Kim (1994) Kim94Kim, CJ.  1994\.  Dynamic Linear Models with Markov–Switching Dynamic Linear Models with Markov–Switching.  Journal of Econometrics601–21–22.
  * Krolzig (1997) Krolzig97Krolzig, HM.  1997\.  Markov-switching vector autoregressions: Modelling, statistical inference, and application to business cycle analysis Markov-switching vector autoregressions: Modelling, statistical inference, and application to business cycle analysis ( 454).  Springer Science & Business Media.
  * Litterman (1979) Litterman79Litterman, R.  1979\.  Techniques of forecasting using vector autoregressions Techniques of forecasting using vector autoregressions.  Federal Reserve of Minneapolis Working Paper 115\.
  * Lütkepohl (2005) Lutkepohl05Lütkepohl, H.  2005\.  New Introduction to Multiple Time Series Analysis New Introduction to Multiple Time Series Analysis (2 ).  Springer Berlin Heidelberg.
  * McNeil . (2005) McNeil05McNeil, AJ., Frey, R. Embrechts, P.  2005\.  Quantitative Risk Management: Concepts, Techniques and Tools Quantitative Risk Management: Concepts, Techniques and Tools.  Princeton University Press.
  * Merton (1974) Merton74Merton, RC.  1974\.  On the pricing of corporate debt: The risk structure of interest rates On the pricing of corporate debt: The risk structure of interest rates.  The Journal of finance292449–470.
  * Miranda-Agrippino Ricco (2018) Miranda18Miranda-Agrippino, S. Ricco, G.  2018\.  Bayesian vector autoregressions Bayesian vector autoregressions.  Bank of England working paper.
  * Quandt (1958) Quandt58Quandt, RE.  1958\.  The estimation of the parameters of a linear regression system obeying two separate regimes The estimation of the parameters of a linear regression system obeying two separate regimes.  Journal of the american statistical association53284873–880.
  * Sims (1980) Sims80Sims, CA.  1980\.  Macroeconomics and Reality Macroeconomics and reality.  Econometrica4811–48.
  * Tiao Box (1981) Tiao81Tiao, GC. Box, GE.  1981\.  Modeling multiple time series with applications Modeling multiple time series with applications.  Journal of the American Statistical Association76376802–816.
  * Tong (1983) Tong83Tong, H.  1983\.  Threshold models in non-linear time series analysis Threshold models in non-linear time series analysis ( 21).  Springer Science & Business Media.
  * Williams (1938) Williams38Williams, JB.  1938\.  The Theory of Investment Value The Theory of Investment Value.  Harvard University Press.
  * Zucchini . (2016) Zucchini16Zucchini, W., MacDonald, IL. Langrock, R.  2016\.  Hidden Markov Models for Time Series: An Introduction Using R Hidden Markov Models for Time Series: An Introduction Using R (2 ).  CRC press.