Jakob Engblom had an intriguing thought:
One thing that seems to be happening today with the whole “IoT” move and ubiquity of cellular communications (at least in the rich world) is that “in the field SW upgrade” is becoming easier and easier to do. Systems that used to be isolated can now be connected, and thus updated if the manufacturer wants to.
But this creates a whole new set of questions: for how long do you support a deployed system with updates? Are you obliged to roll out updates when you find security holes? Do customers accept that you update their systems? Who controls the data from these systems?
A friend of mine spent a ton of money on a Tesla car recently, and he some interesting stories about its update process. That car is apparently updated by Tesla when the manufacturer feels like doing it. Consumers have little choice, and user interfaces do change over time. He might come down in the morning and realize that some element of the car GUI has changed and he has to figure out how to do something with this particular iteration. Just like with a mobile phone or computer OS, where we are pretty used to this process.
It is a bold new world of connected embedded, and scary things will happen.
(Source: Personal communication)
Jakob’s comments raises a slew of questions.
I had a network router a few years ago and one day a feature just disappeared – an unsolicited midnight firmware upgrade downgraded the product. Suppose a customer had selected the router specifically for that feature, and a year or three after the purchase it suddenly no longer performs as advertised? My understanding of US law is that he could sue for redress, but no one will do that for a $100 device.
In effect the company was like a thief in the night, sneaking into my office and furtively making off with the goods.
Then there’s the liability problem. Suppose you don’t do a firmware upgrade to patch a security flaw that surfaces years after delivery, and a hacker attacks causing grief. It could be argued you delivered a defective product and chose not to remove the bug(s). If firmware upgrades are possible, does this imply they are mandatory? Must product support go on forever?
Adding an Internet connection to a device changes, I think, the nature of the product in a very significant way. A modern oscilloscope, for instance, is a very complex bit of equipment. Firmware upgrades via, say, a USB stick are pretty straightforward. But if a TCP/IP stack is added it could become a threat vector against a network. What responsibility does the manufacturer have years down the road to patch vulnerabilities?
One of my scopes boots Windows… and it’s rumored that some versions of that OS might actually have imperfect security. My Windows 8.1 computer gets a never-ending stream of updates from Microsoft. Should all of those be applied – on practically a weekly basis – to a ‘net-connected scope?
And what happens when the version of Windows in the equipment loses Microsoft’s support? How culpable is the scope manufacturer then?
Commenters will undoubtedly write “just use Linux.” As I write this on January 19 the first page of Slashdot has a story entitled “Serious Linux Kernel Vulnerability Patched.” Linux might reduce the incidence of problems, but won’t eliminate them.
Whether it’s a Linux- or Windows-based system, an OS upgrade can take a lot of time. How frustrated will users be when they need to quickly probe a few nodes, and the scope tells them too wait for an hour for an upgrade to take place?
On the up side, being able to download new code means the customer can get new features for free. It might be nice to advertise “sometimes you might get some cool new feature, but we have no idea what that might be!” Does that rather vague promise compensate for the business risk of litigation for unpatched problems?
These are issues far over our pay grades. You can be sure the legal profession will be soaked in cash as litigation creates case law. Before that happens zillions of IoT devices will be designed and deployed. I wonder how many companies, having no legal guidance on these matters today, will be retroactively liable when problems surface?
What’s your take?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges, and works as an expert witness on embedded issues. Contact him at . His website is .