[image] [image] Ressource protégée - Inria - Institut national de recherche en sciences et technologies du numérique Accéder directement au contenu

[image] [image]

* Documentation

* FR
  Français (FR)

* Anglais (EN)
  Se connecter

* Portail HAL Inria

* Recherche
  Loading...

## Recherche avancée

Information de documents

Titres

○ Titres

○ Sous-titre

○ Titre de l'ouvrage

○ Titre du volume (Série)

○ Champ de recherche par défaut (multicritères) + texte intégral des PDF

○ Résumé

○ Texte intégral indexé des documents PDF

○ Mots-clés

○ Type de document

○ Sous-type de document

○ Tous les identifiants du document

○ Identifiant HAL du dépôt

○ Langue du document (texte)

○ Pays (Texte)

○ Ville

○ À paraître (true ou false)

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

HAL
open science

Design and Analysis of an Online Update Approach
for Embedded Microprocessors

Patrick Uven, Philipp Ittershagen, Kim Grüttner

► To cite this version:

Patrick Uven, Philipp Ittershagen, Kim Grüttner. Design and Analysis of an Online Update Approach for Embedded Microprocessors. 6th International Embedded Systems Symposium (IESS), Sep 2019, Friedrichshafen, Germany. pp.179-188, 10.1007/978-3-031-26500-6_15 . hal-04489009

HAL Id: hal-04489009

https://inria.hal.science/hal-04489009v1

Submitted on 4 Mar 2024

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

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

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

Distributed under a Creative Commons Attribution 4.0 International License
## Auteur

### Auteur (multicritères)

○ Auteur (multicritères)

○ Auteur : Nom complet

○ Auteur : Nom de famille

○ Auteur : Prénom

○ Auteur : Complément de nom, deuxième prénom

○ Auteur : Organisme payeur

○ Auteur : IdHal (chaîne de caractères)

○ Auteur : Fonction

○ Auteur : personID (entier)

○ Auteur : Identifiant de l'organisme payeur

○ Auteur : Identifiant de la structure

○ Directeur de thèse

○ Éditeur

○ Éditeur scientifique

○ Éditeur de la série

## Ajouter

### Structure

### Structure (multicritères)

○ Structure (multicritères)

○ Structure : Acronyme

○ Structure : Nom

○ Structure : Code

○ Structure : Pays

○ Structure : Type

○ Structure : État dans le référentiel

○ Structure : Identifiant HAL de la structure

○ Structure/équipe de recherche : Pays

○ Structure/regroupement d'équipes : Pays

○ Structure/laboratoire : Pays

○ Structure/regroupement de laboratoires : Pays

○ Structure/institution : Pays

○ Structure/regroupement d'institutions : Pays

## Ajouter
<figure><img src="image_3.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
Autres

Champ de recherche par défaut (multicritères)

○ Champ de recherche par défaut (multicritères)

○

○ Revues (multicritères)

○ Revue : Éditeur

○ Revue : Titre abrégé

○ Revue : Titre

○ Revue : Identifiant interne

○ Revue : Date de début de publication

○ Revue : ISSN électronique

○ Revue : ISSN

○ Revue : Éditeur

○ Revue : Couleur dans SHERPA/RoMEO

○ Revue : État dans le référentiel

○

○ Colloque (multicritères)

○ Colloque : Titre

○ Colloque : Organisateur

○ Colloque : date de début (Année)

○ Colloque : date de fin (Année)

○ Conférence invitée (oui/non)

○

○ Projets ANR (multicritères)

○ Projet ANR : Acronyme

○ Projet ANR : Acronyme du programme

○ Projet ANR : Code décision (référence)

○ Projet ANR : Nom

○ Projet ANR : Identifiant interne

○ Projet ANR : État dans le référentiel

○

○ Projets européens (multicritères)

○ Projet européen : Acronyme

○ Projet européen : Identifiant de l'appel à projet

○ Projet européen : Référence

○ Projet européen : Nom

○ Projet européen : Date de fin

○ Projet européen : Financement

○ Projet européen : Date de début
# Design and Analysis of an Online Update Approach for Embedded Microprocessors *

Patrick Uven<fnref n="1" />, Philipp Ittershagen<fnref n="2" />, and Kim Grüttner<fnref n="2" />

**Abstract.** Software updates are already used in many systems for fixing bugs and for improving or extending their functionality. For many embedded systems with strong requirements on their availability, software updates are still not used because an update cycle usually causes a down time of the system. For servers in data centers with high availability requirements, so-called live patching solutions exist for many years. Live-Patching allows updating the software without affecting the availability of the system (i.e. no restart is required). In this work, we propose the application of live patching on small embedded microprocessors. We present a proof-of-concept implementation on a Xilinx MicroBlaze processor and compare the properties of our implementation, w.r.t. the amount of transmitted update data, memory requirements and update cycle duration against a state-of-the-art full-memory update.

**Keywords:** Online Update · Live Patching · Xilinx MicroBlaze.

## 1 Introduction

Autonomous, dynamically changing cyber-physical systems (CPS) will permeate all areas of work and life in the future - e.g. industry 4.0; autonomous, cooperative driving; highly automated medical devices; smart grid controls; inter-modal transport systems and many more. These systems will support or perform various safety-related control tasks under conditions that will change during operation (e.g. new traffic infrastructures for highly automated vehicles, new communication technologies, new sensor technologies or security mechanisms, extended deployment scenarios, etc.). As these conditions are generally not (completely) known at the time of system development, the continuous system evolution of CPS after commissioning is of central importance. In particular, the ability to continuously incorporate experiences from the operation of systems in the field into the further development of CPS (swarm data collection as well as continuous updating) and to design systems in such a way that improvements can be introduced into CPS promptly is crucial.

<footnote n="1">¹ Carl von Ossietzky University Oldenburg, Oldenburg, Germany
patrick.uven@informatik.uni-oldenburg.de</footnote>

<footnote n="2">² OFFIS – Institute for Information Technology, Oldenburg, Germany
{ittershagen,gruettner}@offis.de</footnote>

<footnote>* This work is part of the Step-Up!CPS project and was funded by the German Ministry of Education and Research (BMBF) under grant agreement no. 01IS18080A.</footnote>
○ Projet européen : État dans le référentiel

○ Projet européen : Identifiant interne

○

○ Date de production : année

○ Date de mise en ligne : année

○ Date de publication : année

○ Date d'écriture : année

○ Date de modification du dépôt : année

○ Date de dépôt : année

○ Date de publication électronique : année

○

○ Collection HAL (multicritères)

○ Collection HAL : catégorie

○ Collection HAL : Code

○ Collection HAL : Nom

○ Collection HAL : Identifiant interne

○

○ Identifiant interne du contributeur/déposant

○ Nom complet du contributeur/déposant

○

○ Domaines

○ Domaine primaire

○ Domaine racine

○ Sous-domaine niveau 1

○ Sous-domaine niveau 2

○ Sous-domaine niveau 3

○

○ Statut du document

○ Version du document

○ Type de dépôt

○ Type de document

○ ISBN

○ Numéro - référence

○ Identifiant DOI

○

○ Classification

○ Audience

○ Vulgarisation

○ Comité de lecture - texte (oui ou non)

○ Actes de colloque
In contrast to smartphones and PC operating systems, where regular updates are part of everyday life, updates of highly dependable CPS place significantly higher demands on the architectures of these systems. Considering dependability as a measure of a system’s availability, reliability and its maintainability we can see that updates support maintainability and online updates (i.e. updating the system while it remains operational) support availability.

This work considers the design and analysis of an online update approach for an embedded microprocessor. Our contributions consist of

1. a modular software live patching approach (called append update) for on-line updates of functions at run-time (i.e. an update without stopping the system),

2. a proof-of-concept implementation of the append update approach on a Xilinx Zynq MPSoC, which demonstrates updating a Xilinx MicroBlaze processor system initiated from the ARM based processing system, and

3. an analysis and a comparison against a state-of-the-art offline update approach.

This paper is structured as follows. The next section presents an overview of related work in the area of software update techniques. Section 3 describes the full and append (live patching) update approaches, which is followed by a proof-of-concept implementation on a Xilinx MicroBlaze microprocessor system in section 4. Section 5 evaluates our approach and compares the full and append update approaches. The paper closes with a conclusion in Section 6.

## 2 Related Work

Existing commercial solutions in the automotive sector (e. g. escrypt [9], Infin neon [3], as well as SWUpdate [2], libostree [6] or Mender [1] for embedded Linux systems) are capable of replacing the entire firmware of individual ECUs with a new version. However, modular updates or changes to the software during operation are not taken into account.

The EU-funded Horizon 2020 project TAPPS [8] has developed an open platform for CPS software, which consists of an “app store” for security-critical and security-uncritical applications (or functions) as well as the software and hardware layers necessary for the assurance of security and real-time properties. The update management is based on virtualization techniques which were used to run a Linux and a FreeRTOS system on the same hardware. The platform requirements for running such a software stack naturally limit the applicability of such approaches in resource-constrained scenarios.

The Dynamic Software Updating (DSU) [4] mechanism describes the concept of replacing one or more functions during runtime. As one of the first contributions to this topic, the approach provides an extended toolchain for annotating the changes of the software in a high level language. The developer then selects a safe point in time to replace the function, at which point the software execution is paused, updated and then resumed. More recently, a similar approach,
○ Référence interne

○ Financement

○ Collaborations

Ajouter

Lancer la recherche

Recherche experte (SolR)

Recherche experte (SolR)

Lancer la recherche
Vers la recherche avancée

• Déposer

Portail INRIA.HAL.SCIENCE
Les publications, logiciels... des scientifiques Inria

• Accueil

• Publications Inria

○ Consulter les derniers dépôts

○ Par équipe de recherche

○ Par auteur

○ Rapports de recherche et techniques

○ Livres blancs

○ Rapports d'activité des équipes

○ Statistiques

• Boite à Outils

○ X2Hal : importer par lot

○ Logiciels : créer le Codemeta.json

○ Créer mon IDHal

○ Créer mon CVHal

○ Haltools : créer ma page de publications

○ Haltools : extraire des données (réservé Inria)

○ Les bonnes pratiques

■ Comment bien s'affilier ?
presented in [5], uses indirection to replace functions in the running software
application. However, this leads to a constant overhead for each function call
due to the use of indirection for each updated function. Additionally, the pro-
gram execution has to be paused to migrate to the new function, similar to the
approach from [4]. While the approach presented in this paper also induces a
runtime overhead due to indirection, it does not require the target system to be
paused during an update.

Furthermore, there are live patching solutions available for the Linux oper-
ating system. A popular solution is kGraft [7], where new kernel functionality is
inserted into the memory and referenced by the updated function. The approach
also features migration procedures, including a special “reality check” which de-
cides if a redirection is appropriate based on the consistency of the overall system
state. The contribution of this paper is closely related to the technical solution of
this Linux-based update approach However, while such live-patching systems are
based upon resource-intensive software frameworks such as Linux, our contribu-
tion focusses on exploring and analysing a live-patching mechanism for systems
with direct access to the memory of a microprocessor system.

3 Overall Update Approach

This work considers an update approach for a system architecture which consists of three parts. The *Microprocessor system* is an embedded system consisting of a microprocessor, memory modules as well as I/O peripherals. This system is the target of the update and is executing software that should be changed during run-time. The embedded system is running software written in C and uses a shared memory for its instructions and data. The *Distribution system* is the source of update files and is not in the scope of the online update process itself. We therefore assume that the update files are already available on the *Update system* and have been securely transferred to the system and omit the communication details between those systems. Finally, the Update system is responsible for controlling and updating the Microprocessor system, which we will explain in the following section.

3.1 Update Procedure

The update procedure starts with the development of C-based software functions
for the microprocessor system. As shown in Figure 1, the source file is compiled
into an object file, which is then processed by the linker. The linker script con-
tains the necessary memory layout information to map all relevant object file
sections to sections of the final memory layout. The result will be saved in an
ELF file.

Next, a script converts the ELF file into a memory dump of the target mi-
croprocessor memory, which discards all ELF metadata and copies the loadable
ELF sections to their corresponding memory addresses. The file format consists
of one word on each line as well as the address in which it is written. This file
■ Quelle version puis-je déposer ?

■ Choisir le bon « type de document »

■ Mettre en valeur ses publications

○ Les tutos IES Inria

■ Lier les notices dans HAL

■ Umbrhal Inria pour l'accessibilité

■ Personnaliser son CVHAL

■ Créer et Personnaliser sa collection

• Documentation

○ Aide en ligne HAL

○ Aide en ligne Haltools

○ Aide en ligne X2hal

○ Tutoriels video HAL

○ Documentation API HAL

○ Ajouter des vignettes

○ Identifiant auteur IdHAL et CV

○ Compléter son dossier ORCID avec ses dépôts HAL

○ Inria et la Science Ouverte

X

X

X

Loading...

X

Le document que vous demandez est en access restreint
jusqu'au 2026-01-01 !

Revenir a la notice

Retourner à l'accueil

Contact

•

Ressources
<figure><img src="image_4.png" /><figcaption>Fig. 1. Update workflow</figcaption></figure>

is used to populate the linear address space of the microprocessor. Additionally, as each word is one microprocessor instruction, we can easily change or replace instructions in the file. The update itself is implemented in two different variants:

**Full Update** The full update completely replaces the software on the microprocessor. To achieve this, the update procedure can pause, halt, and even reset the microprocessor and consequently discard its current state.

**Append Update** The append update allows replacing user-defined functions of the existing software by appending a new version in unused memory space, thus allowing the software to continue its operation and to retain its current state.

The following section describes the different flows of the full and append update approaches.

## 3.2 Full Update

The full update approach resembles the typical process of updating software on a processor. As described above in the basic workflow, the engineer writes new functionality in the existing C source code. After compiling and linking the program, the update file contains the complete memory of the full program. The update process consists of the following steps:

1. The distribution system initiates the update process by transferring the file to the update system and signaling the start of the update. The update system is idle while waiting for the signal and the microprocessor system is still executing the outdated software.

2. In the next step, the update system pauses the microprocessor, such that it can safely write to the whole microprocessor memory content while ensuring that the microprocessor does not read any instructions or data from it. This is to avoid the execution of a combination of partly updated instructions which could lead to undefined execution behaviour of the microprocessor.
* Documentation

* FAQ

* API

* OAI-PMH

* AuréHAL

## Informations

* À propos

* Données personnelles

* Mentions légales

* Accessibilité

* Conformité RGAA

## Questions juridiques

* Je publie, quels sont mes droits ?

* Loi pour une République numérique

* Stratégie de non-cession des droits

* SHERPA/RoMEO

## Portails

* Portails institutionnels

* HAL

* HAL SHS

* HAL Thèses

* MédiHAL

## CCSD

* CCSD

* Episciences

* Sciencesconf
3. As soon as the microprocessor is paused, the update system writes the contents of the update file into the memory of the microprocessor.

4. Finally, the update system resets the microprocessor. While the update system returns to the idle state, the microprocessor system can now execute its updated software.

## 3.3 Append Update

The append update follows a different approach: instead of replacing the whole program binary, we only consider parts (i.e. C functions) that actually change. To avoid the problem of pausing the microprocessor to change multiple lines in the memory, we instead place the updated functions in a dedicated memory section and update a jump instruction at the start of the old function.

The left side of Figure 2 depicts the typical microprocessor memory structure consisting of instruction segments, constants, and dynamic data. To update a function in the program, we duplicate the function in the source code, apply the source-level updates, and place the generated binary content of the new function in a dedicated memory section of the ELF file. We then copy this section to the dedicated memory region in the target memory layout, as depicted in the bottom part of Figure 2.

<figure><img src="image_5.png" /><figcaption>Fig. 2. Microprocessor memory overview</figcaption></figure>

The next step is to integrate the updated function into the existing control flow of the program. We achieve this by redirecting any calls to the old function to the updated one. Since we are able to atomically write on a word granularity to the target memory, we are able to replace a single instruction in an atomic manner. This allows us to replace the first instruction of the old function with a branch instruction redirecting the processor to the new function instead. In Figure 2 we can see the

addition of the new function as well as the branch instruction. Function 4 gets changed and the first instruction becomes a branch to the memory section of update 1 in which we can see the updated function. Any subsequent call to the outdated function will be redirected to the updated version of the function. As we don't need to pause and reset the microprocessor system anymore, the interaction between the update and the microprocessor system is much smaller compared to the full update.

However, there are some restrictions on functions eligible for this update procedure, which needs to be considered during the development:
- The signature of the function (and the calling convention) must stay identical (i. e. all types, including the return and argument parameters have to be the same, including the ordering of the parameter types).

- The function symbol must have external visibility in the final compiled ELF file. Features like inline expansion of a function cannot be used, as they would hide the function and thus make it impossible to update them.

- The parallel execution of both old and new function has either to be pre-vented in the program or we have to make sure that both version can run without complication at the same time.

- If the updated function is called multiple times from another function or if it is used recursively, we have to make sure that the behaviour of the function stays the same. Otherwise we have to defer the update until the recursive function call has been completed.

# 4 Implementation

This section presents the prototypical implementation of the approach to demonstrate its applicability on an embedded microprocessor platform. We have chosen the ZedBoard Zynq-7000 ARM/FPGA SoC Development Board which consists of two main components, an ARM Cortex-A9 dual core (called processing system) and an Artix-7 FPGA (called programmable logic). Figure 3 provides an overview of the systems involved in the update process as well as their communication links.

<figure><img src="image_6.png" /><figcaption>Fig. 3. Implementation overview</figcaption></figure>

The update system is running on the ARM processing system on top of a Linux operating system. The microprocessor system consists of a Xilinx MicroBlaze softcore instantiated in the FPGA along with a dedicated Block RAM as instruction and data memory. We use an AXI bus for the communication between the update and the microprocessor system. A GPIO is used to pause and reset the MicroBlaze processor. An AXI BRAM controller is used to access the dual-ported instruction and data memory of the MicroBlaze from the update system. The goal of the prototype implementation is to demonstrate the following scenario: a defective function (see Listing 1.1) is to be updated with a corrected function (see Listing 1.2).

For both update variants (full and append) we start with the same program loaded in the MicroBlaze memory: A basic program that calls the function from
Listing 1.1 is compiled and linked for the microprocessor, copied into the memory and then executed, such that in both cases the to-be updated software is being executed at the start of the system.

1. `int addValues(int A, int B) {`
2. `return A + A; }`

<caption>**Listing 1.1.** Defective Function</caption>

1. `int addValues(int A, int B) {`
2. `return A + B; }`

<caption>**Listing 1.2.** Corrected Function</caption>

## 4.1 Full update

The full update has a mostly unchanged process compared to manually updating the binary on the processor. The function is updated in the source code, the program recompiled and relinked without any further changes. The resulting ELF file can then be converted to the format presented earlier. The update system now pauses the microprocessor via GPIO and writes the memory contents via the AXI interconnect. When this process has finished, it triggers the reset signal via GPIO and the microprocessor restarts with the updated function.

## 4.2 Append update

In case of the append update approach, we change the update process such that the existing memory is not completely rewritten. Therefore, we create a new memory segment that will contain our updated function. Since memory segments are getting created during the linking process, we have to extend the linker script with a section for the new memory segment. Listing 1.3 shows how to instruct the linker to create a new segment `.update_1` and to keep it in the final binary, even when it is not referenced by any other section. This is needed since the updated function symbol is not referenced in the original source code and would be removed otherwise.

With the new segment created, we can now add our updated function. To achieve this, we copy the old function `addValues` to a new version called `addValues_update_1`, as shown in Listing 1.4.

Additionally, we need to assign the function to the memory segment, which is annotated by the section attribute. When the program is compiled and linked after these changes, all old code sections remain unchanged; only the newly added segment is added behind the previous last segment to the ELF file. At this point, we can convert the ELF file to our update format and write the new lines of code with our updated function into the MicroBlaze memory. To finalize the update, the first instruction of the old function is replaced by the branch to the new function.

1. `.update_1 : {
2.  *(.update_1)
3.  KEEP (*(.update_1))
4. }`

<caption>**Listing 1.3.** Linker script extension</caption>

1. `int addValues_update_1(int A, int B) {
2.  __attribute__ ((used, section(".update_1")));
3.  int addValues_update_1(int A, int B) {
4.    return A + B; }
5. }`

<caption>**Listing 1.4.** Updated function with section assignment</caption>
# 5 Evaluation

This evaluation compares the full against the append update using four different update scenarios (A-D):

0) **Initial program** running on the processor before an update occurs.

A) **Function replacement (same size)** A function will be replaced by the same/identical function.

B) **Function replacement (larger size)** The function from scenario A is getting replaced by a larger function with more instructions.

C) **Iterative function replacement (same size)** The same function (similar to scenario A) is updated multiple times.

D) **Replacement of multiple functions** Multiple functions will be replaced (each of them like in scenario A) at the same time.

The evaluation uses the Xilinx Vivado tool chain in version 2018.2 to build the PetaLinux for the update system, the bitstream for the FPGA, as well as software for the MicroBlaze processor. The hardware platform consists of a ZedBoard with all hardware components configured using their default clock values (CPU 666, 6 MHz, DDR 533, 3 MHz, Programmable Logic 100 MHz). Unless otherwise stated, the results of the following experiments were obtained from 100 runs.

The project sources for the implementation as well as the files to recreate this evaluation can be found at https://github.com/offis/mb-append-update. The repository also contains an example project with all intermediate steps and a short usage guide.

## 5.1 Memory usage

The memory of an embedded system is always a limited resource. This experiment compares the amount of memory that will be written to the microprocessor memory by the update system, measured by counting the amount of lines that are present in the update files for both update variants. Since every line in the update files represent a word in the RAM, the result is also depicted in words.

<figure><img src="image_7.png" /><figcaption>Fig. 4. Memory overhead</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 5. Timing overhead</figcaption></figure>
Figure 4 shows the relative overhead of the full and the append update compared to the baseline of experiment 0 which had a memory consumption of 13222 bytes. In scenario B, the function has been extended by 220 bytes. We can see the growing size of the memory in the full and in the append update. Scenario C shows that multiple replacements of a function do not affect the size of the full update, because in-place replacement has been used. With the append update, on the other hand, memory consumption is increased by further 198 bytes. In scenario D, the exchange of several functions of the full update behaves analogous to C, since these take the place of the old functions. The memory consumption of the append update corresponds to three times the replacement of a single function. The exchange of several functions in one update neither brings additional overhead nor saves memory. The experiments showed that, independent of the experiment, the number of instruction and the memory usage are linear to each other for the append update.

## 5.2 Duration of the update procedure

We have furthermore compared the duration of the update procedure of both full and append approaches using “perf” on the update system. For the full update, the measured time frame begins when the pause command is sent to the microprocessor and ends with the reset command for the restart of the microprocessor. In case of the append update, we have measured all necessary write procedures.

While the full update (scenario 0) takes 5.203 seconds, all variants of the append update are executed within 0.3 seconds. The reason for this is the different procedure of updating. While the full update rewrites the complete program into memory, the append update only adds a few lines. Figure 5 shows the timing overhead (i.e. the duration of all memory write operations) of the append update approach, in absolute numbers and with a refined view of their overheads.

## 5.3 Run-time Overhead

There is a small run-time overhead in the append update, which results from the additional machine commands that must be executed after the update. As defined in the concept, each updated function brings one additional branch instruction which has to be executed. With the full update, this does not exist because the functions are completely replaced.

# 6 Conclusion

The evaluation of our proposed append update approach clearly shows its advantages and disadvantages. The memory usage of the full updates corresponds exactly to the size of the updated program and also scales with the size and number of functions. On the other hand, the append update grows with each update by the size of the new function.
For many microprocessor systems, the limited amount of required allocated but unused memory might be the most limiting factor of the append update approach.

Considering the duration of an update procedure, it is important to note that the microprocessor system is not available during the full update, which can cause an extended downtime of the system. On the other hand, the execution is not interrupted during the append update, which renders the time required to write the update irrelevant in terms of service availability interruptions. Additionally, the dual-ported block RAM allows for interference-free access to the memory while the microprocessor system is running. However, this is a special case due to the chosen platform and in general, arbitration for memory accesses would be necessary. For this reason, in general the reduced memory access overhead in the append update is of interest. Here, our evaluation showed that the duration of the append update was linear to the size of the updated functions.

For the distribution system and especially for over-the-air updates we can see an important difference in the amount of transmitted data. The full update always transfers the complete memory content, while the append update only has to transfer a few bytes of difference. However, using existing delta-transmission techniques could reduce this difference again in favor of a full update.

In contrast to the full update, the append update procedure also has a run-time overhead. Each replaced function leads to at least two additional machine instructions, but the overhead is insignificant compared to the usual function sizes.

## References

1. Mender (2019), mender.io/

2. Babic, S.: Software update for embedded systems (2019), sbabic.github.io/swupdate/

3. Infineon: Software update over the air (sota) (2019), www.infineon.com/cms/en/applications/automotive/automotive-security/sotware-update-over-the-air/

4. Lee, I.: Dymos: A dynamic modification system (1983)

5. Neamtiu, I., et al.: Practical dynamic software updating for c (2006)

6. OSTree maintainers: Operating system and container binary deployment and upgrades (2019), ostree.readthedocs.io/en/latest/

7. Pavlík, V.: kgraft: Live patching of the linux kernel, events static.linuxfound.org/sites/events/files/slides/kGraft.pdf

8. Prehofer, C., et al.: Towards trusted apps platforms for open cps (2016)

9. Wolf, M., et al.: Design, implementation, and evaluation of a vehicular hardware security module (2011)