Skip to main content
Product

ADLATUS® Bootmanager

Secure boot process to ASIL D – the generic boot manager for automotive and industrial control units.

Overview

A wrong decision costs functionality.

This decision – whether and which software application runs after a restart – entails safety risks. The ADLATUS® Bootmanager reduces them in accordance with safety level ISO 26262 ASIL D.

An example: if a memory error in the standard application triggers the restart, the Bootmanager first checks whether restarting it is permissible at all and whether it is stored error-free in the program memory. If this is not the case, it does not start the application – without exception.

A flexibly configurable boot table and operation table allow the boot behavior to be adapted precisely to your system environment. Usually, several applications are available for selection, such as the customer application, the flashloader or an end-of-production-line test (EOPL).

Control unit at a fork in the road with signposts to application, test runner and flashloader
After reset

What the Bootmanager decides

After a control unit restarts, the ADLATUS® Bootmanager ensures that the available applications are called up safely and correctly.

Step 1

Analyze the cause

As a generic boot branch, it first analyzes the cause of the restart.

Step 2

Initialize hardware

Even before any application is considered, it initializes a minimal hardware environment to establish a safe initial state.

Step 3

Release application

If the trigger was a workshop tester, it calls up the flashloader. Otherwise it starts the regular application — but only after checking that it is stored error-free in memory.

Technical features & specifications

Nine features, three tiers

Boot logic

  • Generic boot branch after reset – analyzes the cause of the restart
  • Initialization of a minimal hardware environment at start-up
  • Configurable “boot table” and “operation table” for flexible boot behavior
  • Support for multiple applications (customer application, flashloader, end-of-production-line test)

Integrity protection

  • Secure boot: checksum calculation and verification of all target applications
  • Protection against starting an incompletely programmed or faulty application
  • Monitoring of memory violations

Process maturity

  • Safety level: ISO 26262 ASIL D
  • Software development in line with ASPICE V4 CL2, TISAX 6 CL2, ISO 26262 ASIL D
FAQ

Frequently asked questions about the ADLATUS® Bootmanager

What is the ADLATUS Bootmanager?

The ADLATUS Bootmanager is a generic boot branch that selects and starts the correct target application after every reset. Before starting it, it checks whether the target application is stored error-free in memory, for example via checksums and optionally secure boot. A service reset starts the flashloader; a fault reset starts the application. The applications started include the customer application, the flashloader, emergency operation software or the end-of-line test.

What tasks does the Bootmanager perform?

The Bootmanager initializes the microcontroller in a minimal hardware environment and analyzes the cause of the restart. It selects the target application, checks it and calls it up. It monitors memory violations and complies with start-up time and memory consumption requirements.

Which variants are available: static or dynamic?

The static Bootmanager works with a fixed sequence. The dynamic Bootmanager calculates its own checksums, starts any applications such as an EoL test and implements various strategies for flashloader updates. The dynamic Bootmanager is a prerequisite for the single-stage update.

Which safety level does the Bootmanager achieve?

The Bootmanager is configurable to ISO 26262 ASIL B or ASIL D. With ASIL D, the boot tables are stored redundantly. Software development of the basic version follows ASPICE Capability Level 2.

What security and logistics functions does the Bootmanager offer?

With secure boot, an incompletely programmed application is not started. The Bootmanager calculates and verifies checksums of the applications. The verification methods are extensively configurable, and several applications are available for selection. The selection can be influenced via parameters, for example EEPROM settings.