Updates for the Edge

A presentation at GIDS in July 2020 in by Kat Cosgrove

Slide 1

Slide 2

Slide 3

Slide 4

Slide 5

Slide 6

Slide 7

It’s beyond inconvenient Edge computing is massive and growing

Consumer - Industrial - Medical Slow OTA updates are annoying Wired updates are expensive and more annoying @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 8

It’s dangerous Unpatched bugs can be a huge vulnerability

Slide 9

Slide 10

Not building for it. Many devices are not made to be updated.

Designed to run one version until the end - “Update strategy” here is flashing the device - Bugs are inevitable @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 11

Slide 12

Connectivity Concerns We can’t rely on the device’s network

Networks may be unstable - Bandwidth may be low - Network probably isn’t secure @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 13

Hardware Variations - It’s 20.4 billion devices - Lots of specialized hardware - Variations in memory, storage space, architecture How do we design something that handles so much variety? @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 14

Slide 15

Slide 16

Slide 17

Slide 18

Slide 19

Slide 20

Cars Now - Majority not designed for OTA updates OTA updates are still slow and inconvenient Little standardization Significant portion of recalls are due to software @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 21

Cars as Edge Devices - Presented a range of solvable pain points in one device - Tangible example for end users and manufacturers - Device in question meant speed, reliability, and safety were equally important @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 22

Slide 23

Two Distinct Workflows Software Updates Firmware Updates

Without flashing firmware - No interruption of user - Takes only seconds - Relies on K3S and Helm @jfrog |
More diﬃcult update - Takes only minutes - Rollback if there is a failure - Relies on Mender, Yocto, and Artifactory Copyright © 2019 JFrog. All Rights Reserved

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Helm “Charts” describe complex applications

Slide 33

Slide 34

The Result - Software Application updates are quick and eﬃcient

Average of 35 seconds from dev to car No interruption for the user Can happen while device is in use Could happen silently, depends on device purpose @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 35

Slide 36

Slide 37

Slide 38

Mender Overview Ticks several of the boxes we’re looking for:

Slide 39

Mender - A/B Two partitions are on the device

Bootloader aware of “active” - Update streams to “inactive” - Automatically revert to previous partition on failure Update A User Space A Update B Kernel Initramfs A Now let’s handle the size of our builds. @jfrog | User Space B Copyright © 2019 JFrog. All Rights Reserved Kernel Initramfs B Bootloader

Slide 40

Slide 41

Yocto Overview - Eliminates OS bloat Drastically reduces resources required BitBake recipes and layers define your build Layers for common configurations are provided Custom layers to isolate applications or behaviors @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 42

Slide 43

Yocto and Artifactory - After first build, we can make things much faster Yocto cache allows for incremental updates Build cache can be stored in Artifactory Reduces time required to build by up to 50% @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 44

The Result - Firmware - Cuts the total time after first build to 5-10 minutes Build is as small as possible Updates are signed and secure Automatic rollbacks in case of failure Success! @jfrog | Copyright © 2019 JFrog. All Rights Reserved