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

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

Support CNX Software - Donate via PayPal or become a Patron on Patreon
Subscribe
Notify of
guest
6 Comments
oldest
newest most voted
Dim
Dim
1 year ago

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… Read more »

dgp
dgp
1 year ago

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… Read more »

dgp
dgp
1 year ago

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
willy
1 year ago

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… Read more »

dgp
dgp
1 year ago

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… Read more »

willy
willy
1 year ago

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… Read more »

Advertisements