Every racing team knows that the skills needed to achieve pole position through qualifying laps are different from the skills and setup necessary to win an endurance race. Winning teams have the expertise and technology to adapt their strategy as the race unfolds. In the same way, being first to market in a technology race doesn’t always guarantee success over the longer term.

The economic benefits of deep learning technologies are now well understood, but as an innovator, there’s always a concern that while deploying new technology ahead of competitors can produce a competitive edge, there are also risks. Wright suggested back in 1936 that the cost of a unit decreases as a function of the cumulative production. Late entrants are likely to have access to cheaper technology and the latest software, so how do the most enlightened organizations ensure that their early leadership position isn’t overtaken by laggards who have access to more affordable and newer technology?

Unlike the era when the firmware was “burnt” into a ROM, in most cases, it’s no longer necessary to ship products with firmware that implements the “North Star” feature set. What we once called firmware has now become software, and low-cost microprocessors can now exceed the performance requirements of initial applications, enabling models and algorithms to be easily and quickly updated without the cost or risk of manual updates. To use the racing analogy, it’s now possible to tune a car mid-race. This allows innovators to start deploying earlier and see immediate benefits without the fear that their technology will become obsolete before they’ve finished the roll-out. In a field where data is king, pioneers can start to amass business data that can be used to develop, train and optimize smart devices later. Devices may start as fairly dumb data acquisition nodes and gradually be trained to become fully autonomous at the push of a button. For example, Telsa’s fleet of vehicles is believed to have accumulated around 1.3 billion miles of training data from cars that had Autopilot installed: a critical step in the training process before they activated their autopilot feature*.

Of course, avoiding costly mid-race pit stops and tuning software “live” requires close integration between an in-device IoT platform and a management service. It’s with this knowledge, that Mbed Linux OS 0.6 has been released, making it even easier to start building Linux based products that can be updated “over the air” using Pelion Device Management. Building on version 0.5 released in December, version 0.6 of the Mbed Linux OS adds the following features:

• Over the air update of containerized applications from Pelion Device Management are now more robust than in 0.5, as the last known good application is automatically restored if an update fails.

• Incorporates an updated version (2.1.1) of the Pelion Device Management client.

• To increase speed and productivity for developers, we’re now supplying pre-built OS images. Previously developers had to compile their own OS which could be slow on laptop-class hardware.

• Developers can get connected to Pelion Device Management quicker by injecting their Pelion credentials onto a device at runtime rather than when compiling the OS.

• Support for cellular connectivity with the Quectel EC25 modem module.

• Support for a TechNexion System on Module (SoM) based on the NXP i.MX7 Dual. While the Raspberry Pi remains popular for PoCs, the TechNexion module offers a compatible form-factor that’s an ideal migration path for customers who require greater security and industrial qualification for production deployments.

• Partial support for the NXP i.MX8M Mini on NXPs own evaluation board.

Full documentation for the new release can be found here.

Mbed Linux OS isn’t quite ready for use in large production deployments yet, so we’ve decided to extend the developer preview that we launched in December. If you’d like to receive early access so that you can start developing with Mbed Linux OS, please register here.

(*Source - https://electrek.co/2016/11/13/tesla-autopilot-billion-miles-data-self-driving-program/)