Updates for the Edge

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

It’s dangerous Unpatched bugs can be a huge vulnerability

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

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

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

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

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

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

Helm “Charts” describe complex applications

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

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

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

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

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

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