Using MCUs to enable autonomous safety in autonomous systems

Article By : Bob Martin

Microcontrollers (MCUs) offer a solution for implementing safety co-processors at the heart of today’s new generation of autonomous systems.

Accelerating adoption of artificial intelligence (AI) and machine learning (ML) technologies in increasingly autonomous systems is driving requirements for smarter safety systems across a variety of industries. The focus has moved from cost savings to user convenience and safety. This requires a complete functional safety (FuSa) layer consisting of a safety co-processor with trusted input/output controllers that work together to protect the system. Microcontrollers (MCUs) offer a low-cost solution for implementing these safety co-processors that are at the heart of today’s new generation of autonomous systems.

Autonomous safety functions and specifications

Safety co-processors execute the deployed ML model that accepts external data streams including video, audio, environmental and operator data – or, in some cases, all these data streams at once. These data streams must be inherently trusted.

Equally important, safety co-processors must trust in the faithful reproduction of the output states they generate for motors, relays, indicators, and other actuators. The main processor should also be able to rely on these input/output (side band) controllers to make intelligent and quick decisions in case of a failure.

Using MCUs as safety co-processors

Supported by complete development ecosystems, 8- and 32-bit MCUs are primarily used in four main functional safety areas for which the following industry-standard specifications have been created:

  • ISO262: Automotive Safety Integrity Applications (ASIL) for Automotive Applications
  • IEC 61508: Safety Integrity Levels (SIL) for Industrial Applications
  • IEC 60730: Functional Safety Standards for Household Appliances
  • IEC 60730 Functional Safety for Medical Devices
Microchip Industrial robots
Figure 1. Industrial robots welding large heavy objects. (Image: Microchip)

The development tool ecosystem has two important backend requirements. The first is robust coding practices during development as well as during compilation into machine code. This is addressed using functional safety compilers that are certified to ISO or IEC functional safety standards through organizations such as TÜV SÜD, an internationally accredited testing body.  The second backend function is detailed analysis of what code was executed and what code was missed during a typical testing cycle. This requires a code coverage plug-in.

How autonomous safety works

The primary interaction to the outside world is through hardware layers, starting with the direct sensor and actuator interfaces provided by the FuSa-enabled MCUs at the edge (figure 2).

Microchip autonomous safety diagram
Figure 2. Autonomous safety features in 8-bit microcontrollers.

Key functions include:

Brown Out Detect (BOD)

Very few operational environments have perfect power supplies.  Microwave ovens and laser printers can cause lights to flicker, large electric power tools are known to trip circuit breakers.  Autonomous systems must know that their power supply is failing before it fails so that either a backup supply can be enabled, or critical data and output states can be set to ensure a clean power-down.

The BOD circuitry in these MCUs can monitor the supply voltage continuously and react to a falling level in two specific ways.  First, the voltage level monitor (VLM) function will trigger an interrupt when a selectable threshold value is crossed, allowing for emergency shut-down tasks immediately before the actual BOD level threshold is crossed.  Once the BOD level is crossed the device will hold in reset until this condition is removed.  It is also possible to determine the cause of reset event to ensure a proper recovery strategy which may be different than a first power-on cycle.

Windowed Watchdog Timer

Modern MCUs use watchdog timers as a fault recovery mechanism that is intended to terminate an infinite loop or ‘spin lock’ condition that has no exit except for drastic measures.  Early versions set a timeout threshold either in seconds or milliseconds, which then needed some type of “poke” from the running code before this threshold was reached. Once acknowledged, the timeout threshold was reset, and the countdown was re-started.  Lazy programmers used periodic interrupt service routines to update timers, but these routines can continue executing by themselves even though the rest of the system is stuck in an infinite loop somewhere. There is no system reset to resolve the situation.

The windowed watchdog timer solved part of the problem by allowing a watchdog service window to be specified.  In this way the watchdog timer cannot be serviced too slowly or quickly. This makes it harder to rely on code that is known to execute in elapsed times below the maximum threshold.

Cyclic Redundancy Check (CRC) Code Scan

A CRC code scan peripheral ensures the integrity of the programmed code image. It is much more powerful than just a checksum that can be easily fooled through mathematical manipulation. A specific MCU hardware block is configured to run a scan on the bootloader section of program memory, the application section, or the entire flash memory array. The peripheral will then compare its CRC result with the correct checksum attached to the end of the specified code space. If the two 16-bit numbers match, this verifies that the code space has not been modified. A match failure can be configured to generate a non-maskable interrupt to further deal with the problem.

True Input Path General Purpose Input/Output (GPIO) Peripherals

In the early days of MCUs, when a GPIO pin was configured as an output the only way to validate that the pin voltage level (i.e., 5V) matched the control bit value (i.e., ‘1’) was to use a separate GPIO pin configured as an input to read the voltage level.  A GPIO pin configured as an output could not read back the actual voltage but merely the value that was written to it; hence, the ‘input’ value always agreed.

True input path GPIO cells provide a separate electrical path to a discrete internal INPUT register that reflects the true level set at the pin.  While this level can only be read in terms of logic ‘1’ or logic ‘0’ it still provides enough feedback to validate what was written to the OUTPUT control register. A disagreement between these two values should never happen. If there is a difference, then either a short or open circuit condition exists on that specific GPIO pin that needs to be handled appropriately.

MCUs with these capabilities provide the foundation of a complete FuSa layer. This layer will grow in importance as AI/ML-based automation moves from a focus on system production and maintenance savings to the safety and convenience of the user experience.

 

This article was originally published on Embedded.

An avid maker before it was a widespread term, Bob Martinsenior staff engineer at Microchip Technology has been tearing apart things to see how they work for his entire life.  After obtaining a B.S.E.E. from the University of Saskatchewan, his early career spanned everything from installing specialized instruments into Arctic weather stations, designing industrial control systems and supporting upper atmospheric research campaigns for Environment Canada. He moved to the Bay Area 20 years ago and has continued to concentrate on embedded systems design since.  After a decade at National Semiconductor which also exposed the wonderful world of analog he ended up in a few startups before landing at the Arduino prime enabler of Atmel where he managed a microcontroller applications team. With 30 years of embedded system experience he now serves as the “wizard of make” for Microchip, continuing his role from Atmel, educates aspiring makers and continues to create, experiment and explore as much as he can.

 

Leave a comment