Short answer: It's possible.
Long answer: It's complicated. That's why so many many very bad implementations are out there.
At the very least you have two steps in any remote / over-the-air update process.
Of course, this is the absolute bare minimum. If you're working in iterations it's also a very valid first ...
That question is too broad, but given that you omitted the single most important thing, I feel I need to pipe up.
Authenticate the update.
If you want to make sure that your devices are running your code, then you need authentication, not encryption. Encryption ensures that other people can't know what's in your code, and that's hard to achieve and rarely ...
I have software (Windows Server - a little different to 'things' but the principal is the same) that calls in every 24 hours - it sends back various meta data about itself :
customer name (or unique ID)
timestamp of call/request
product type / id
The web service parses out the data and inserts (or updates if the customer has an existing ...
The simple answer is yes - you need enough blocks of flash to support bootloader and A/B code images if you want high reliability. Before activating the new image, you can write the whole thing, verify it and potentially retry.
However this is an expensive/reliable strategy and there are things you can do to reduce the overhead. Low level support for OTA ...
I want to reduce the need to flash everything and risk bricking the device completely as much as possible. Are there existing strategies when flashing microcontrollers over the air?
Aside from your code that does the updating which would be relatively static, you need to keep two images in your storage: an active image and a backup image. Whenever, you need ...
Freescale Semiconductor describes a robust way of over-the-air firmware upgrade for their Kinetis Microcontrollers.
It is called: Program Flash Memory Swap.
Systems using flash memory swap
In devices with two or more internal
flash blocks that support swap, the memory base address of each flash
block can be exchanged. The address location of each flash ...
You could, for example, make a request every X weeks/days/hours... to a server with the current version number of the software. You will after be able to use analytics to see the current percentage and number of devices updated.
Yes, explicitly so, albeit it will be relatively slow.
Carriers are actually recommending NB-IoT and Cat-M1 combo modules, and dynamically switching to M1 when FOTA is needed, although this will only make sense for some apps.
How do IoT manufacturers enable patching or upgrading of encryption algorithms or security protocols remotely or simply to ensure that the device is kept secure?
A large number of IoT manufacturers have a simple solution to this: "don't bother". These tend to be the same developers who add default (or even unchangeable) passwords to their devices, which led ...
Check out OTA which is abbreviation of Over The Air. Arduino has that property.
You can make update with Arduino IDE, Web Browser or HTTP Server.
Arduino IDE option is intended primarily for software development phase. The two other options would be more useful after deployment, to provide module with application updates manually with a web browser or ...
mbed cloud does offer full firmware update functionality, but I think you'd have trouble porting it to your platform if you're running without an OS. I don't think the source is open today, so you can't even use it for reference. I'm also not sure what the criteria are for getting access right now.
You need to think about the features you need - is this a ...
I'll be answering only this part, as I know of no 'out of the box' system for an unknown firwmare.
maybe there are some best practices for implementing firmware upgrade
over the air for embedded devices in secure and robust way?
In term of practice, what I would do is as follow:
1) Have a very minimal boot loader, something as dumb as possible only ...
It's all about a smart synchronization policy
You need a smart synchronization policy that works in tandem with your roll-out approach of your update. The most obvious point in time where the IoT device should sync its version is directly after the update. The rest of the sync schedule is highly dependent on the type of device.
Is it always on and ...
Given the answers in the comments then using git over ssh is probably the best option.
Firstly git will only pull the differences between the current head hash and the head on the remote. Given you are pulling updates to python scripts these should just be text files so the diffs should be simple.
I say pulling over SSH because you can enable compression ...
I have a question about FOTA which got no reply. So I researched & posted my own answer, so that you don't have to reinvent the wheel.
You can either use RUAC which looks to be so good that it might be overkill, or you could work your way through (the most recommended) FOTA on GitHub.
If you don't choose one, there is enough FOSS there that you can ...
The standard model for android updates is now a rolling beta program which individual devices can be enroled in. This would provide a developer with a simple means to perform testing in advance of a consumer roll-out, provided they have a suitable test farm or collection of beta test installations.
This is probably a better choice than being reliant on ...
Moran posted this IETF draft titled A Firmware Update Architecture for Internet of Things Devices on the 30th of October 2017.
A key summary outlined over at Bleeping computer is
The update mechanism must work the same even if the firmware binary is delivered via Bluetooth, WiFi, UART, USB, or other mediums.
The update mechanism must work in a broadcast ...
Is it true that Google will be pushing updates to IoT devices using Android Things without the device developers verifying that it works?
Yes, for Android Things devices Google plans to push upgrades continuously without any device developers verifying it.
Is this likely to cause breakage?
It supposedly is being achieved by ensuring that the device-...
Please share a link to the paper you are alluding to when you mention the authors. Perhaps someone can then think of something specific.
Otherwise, the general answer is "creating something new maybe better for a thesis than to say 'there exists something already' " !!
If the firmware of your device can be made less complex than the bootloader required for a secured remote update, then do not implement remote update.
I know the consensus is to have a secured and robust bootloader, with strong public crypto authentication, safe rollover mechanisms, maybe a basic network stack, and then put on top of that a RTOS, with a ...
This question has been answered, but perhaps this will be valuable for others.
You can wire an ESP32-based board or module to your Arduino, and use https://vcon.io for a remote OTA. vcon firmware can act as an AVR (and not just AVR) programmer, and reflash your Arduino remotely.
Also, as a side-effect, you'll get remote control capability for your Arduino....