Eclipse IoT Survey Report Reveals Arm & Linux Dominate, Security Concerns

Orange Pi Development Boards

The Eclipse IoT Working Group has just released a report asking the global IoT developer community to share their perceptions, requirements, and priorities. And with over 1,700 individuals taking the survey between February and March 2019, the key findings are interesting:

  • IoT drives real-world, commercial outcomes today. 65% of respondents are currently working on IoT projects professionally or will be in the next 18 months.
  • IoT developers mostly use C, C++, Java, JavaScript, and Python
  • AWS, Azure, and GCP are the leading IoT cloud platforms
  • Top three industry focus areas remain the same as last year: IoT Platforms, Home Automation, and Industrial Automation / IIoT.
  • MQTT remains the dominant IoT communication protocol leveraged by developers
  • The Eclipse Desktop IDE is the leading IDE for building IoT applications

The last point may be slightly biased because the survey was done by the Eclipse IoT Working Group, so most respondents were already familiar with the Eclipse IDE.

IoT Developer ConcernsSecurity concerns dropped slightly compared to last year, but it’s not surprising 38% of respondents list it as a top concern since it’s a problem so complex to solve.

IoT Non-Linux Operating Systems
Click to Enlarge

Linux is basically in a world of its own for IoT gateways and edge nodes with 76% penetration, while FreeRTOS dominated for constrained devices. Most non-Linux operating systems experience a drop between 2018 and 2018, especially bare metal programming which dropped from 20% to 11%. The only two non-Linux OSes with a growing market share are VxWorks and Huawei LiteOS. Debian based Linux distributions such as Ubuntu and Raspbian, and even Debian itself dominates the Linux world with at least 30% of respondents picked Debian derivatives for their IoT projects, but the Yocto Project also came strong.

Linux IoT Operating SystemsArm dominated with their Cortex-M MCU class cores in constrained devices, while it’s a bit more spread out for gateways with 70% percent of respondents using Arm, and 42% going with Intel solutions. The total goes above 100% since some respondents simply use both.

Constrained devices Arm IoTThe top three cloud platforms have managed by large US companies with Amazon Web Services (AWS) being using by 34% of respondents, Microsoft Azure by 23% and Google Cloud Platform (GCP) by 20%.

The selected programming language is very much a case of choosing the right tool for the job with C and C++ the preferred language for constrained devices, Java and Python for gateways and edge nodes, and Java and JavaScript for the IoT cloud.

IoT Programming Languages
Click to Enlarge

When it comes to communication protocols, HTTP (REST API?) comes first with 49%, following by MQTT (42%) and WebSockets (26%).  The answers to connectivity protocols were a bit odd since they mixed “mid-level” protocols like TCP/IP (54.1%) with hardware solutions such as WiFi (48.2%) and Ethernet (41.2%).

You’ll find more details in the announcement, and the survey report (PDF).

Via LinuxGizmos

6
Leave a Reply

avatar
2 Comment threads
4 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
willydgpDim Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Dim
Guest
Dim

I think that the embedded domain is the most rational domain after the FPGA domain. In the FPGA world there aren’t many alternatives, so pretty much things are stable for many years. But part of the embedded domain (not the lower level), although is prone to all those different hype technologies is still robust and uses tools that make sense.

The only risk I see in the future, is that more higher level programmers are trying to join the domain, which is welcomed of course, but they also try to join in with their own tools and mindset. Tbh, I don’t know where this is going to lead, but I already see a lot of misuse in the tools in the domain. That is also possible because the hardware is much faster now and have more resources, but still it’s a misuse to rely on that performance to apply tools that are bloated and don’t make sense. I would prefer if those devs were trying to adapt to the existing tools rather enforce their own.

Gladly, (I never expected to say this) there are still silos like the Linux kernel that those tools can’t infiltrate; but for other cases that’s not happening. Also the time to market is an excuse for using those tools and not learn how to use the already existing. It’s not hard to learn C and especially if you’re professional and want to do embedded, then you should spend some time to learn it and use it. It’s good to do that for many reasons, not only because this is a standard tool, but because it will wide open your mindset.

Also, I would like to see more usage of rust in the future as it’s promising and makes sense to use as a future modern tool, especially compared to the latest C++ releases.

dgp
Guest
dgp

The FPGA world is no better off for the shitty vendor tools. The only reason the vendor tools and arguably horrible languages like VHDL and Verilog are still kicking around was because the vendors kept the chip level details a secret so it wasn’t possible to do anything better than transpiling.

A lot of guys C code is complete and utter trash despite them thinking they are a real developer because they can do C and not one of those silly higher level languages. In the microcontroller world a lot of devs are actually EEs and their code is usually worse.

It’s not a “misuse” to use the available processing power and memory to implement stuff like TLS properly (or use an off the shelf library that does it) so you have half a hope of it not being full of holes especially when your customers are connecting your stuff to their home.

dgp
Guest
dgp

The amount of projects using Debian based distros is concerning. That says to me that those devices are going to have flash with a ton of bad blocks in no time and that the developers haven’t put much thought into stuff like ensuring that the file system hasn’t been tampered with.

willy
Guest
willy

It precisely is the problem of todays societies : laziness is profitable in that it creates unreliable products that users accept to renew every 2 years and they find it normal to do so… All these connected devices are going to be a real threat to each other in a few years. There’s no willingness from vendors to provide stable releases, the only way to get fixes will be to upgrade, which will scare a number of users (risk, different experience, loss of certain features they liked), and we’ll end up with devices that don’t receive fixes anymore. I’m quite concerned to see tablets in cars already. All those without the money to visit the garage once a year will accumulate tons of security vulnerabilities that will drive on our roads and possibly connect to the same internet as anyone else. I don’t understand why software is still the only area where warranties are not enforced. A vendor should be forced to provide 2 or 3 years of fixes for a product defect or to replace the product with a new equivalent one. It would force them to be a bit more serious and to verify that their contractors are able to deliver fixes over time.

dgp
Guest
dgp

The “embedded” eco-system is pretty broken in that regard. Even if the manufacturer wanted to update their software until the end of time they would be dependent on upstream component vendors to keep supplying updated SDKs, binary blobs etc. I used to think there should be some sort of “code escrow” law where vendors are forced to archive their code somewhere so that it can be released to the public when they go bust or refuse to support a product. But I don’t think it’d ever work. It might fly in the EU but it would never happen in the US and the end result would be the EU stuck with stuff made before the law came in and potentially in an even worse situation.

willy
Guest
willy

It’s exactly to unblock the whole chain that I’d like to see warranty laws updated. The thing is that at the beginning vendors would be stuck with non-updated products but over time they will get used to demand to their makers and providers to engage in this direction in order not to take risks or to limit them. We could expect that over 10 years warranties would finally be handled reasonably well because once one vendor can do it, it becomes a competition. It has worked in plenty of other industry areas. It’s a shame IT is the worst served here.