During some market research we came across a very interesting embedded market study from EETimes. The research was done by AspenCore and the study is available here. Please note that the study is from March 2019 but we feel most of the results are still very relevant today.
General considerations for an IoT project
In this blog post we want to give an overview what typical embedded projects look like and analyse what makes them different from regular IT projects.
In 2017 the qbee team started their journey to bring server automation technology and device management to the embedded IoT space. The reason we wanted to do this was driven by the perception that many embedded projects still work a bit like a system administrator from the late nineties. People develop homegrown tools and solutions or use a lot of time putting together a type of control system manually. Then this system needs to be maintained over the whole product lifecycle introducing a lot of hidden costs, limitations and dependencies.
In the late nineties IT systems in general had very little strategic importance and the CTO was often very disconnected with the company’s general strategic roadmap (if there was a CTO at all). Information technology was more of a cost center than a means to drive business and growth or to obtain a strategic advantage. The support for the services was often a “best effort” from dedicated individuals in the IT department and very varying in quality. This has been fixed today and now it is common to have both CTOs and CIOs to join the company’s board of directors and these positions are fundamentally involved in crafting and supporting new strategies or business models. This is largely helped by good available tools.
But in the IoT and embedded device space we still see a lot of disconnected initiatives. Who will be responsible for the secure and continuous operation of all the industry 4.0 devices on a shop floor? Who is operating all the different smart city IoT units throughout their lifecycle. Interestingly enough the data gathered from these devices usually flows to a backend that is part of a very defined IT strategy with high SLA (service level agreement) and dedicated emergency plans. But the units gathering the data are often still on a “best effort” basis and it can be difficult to understand who is responsible for the operation of those in terms of security updates and general “device well-being”.
Who will be the business owner of all the industry 4.0 devices over the complete product lifecycle?
Now we have 2020 and we believe that IoT or embedded projects are currently going through the same transition as traditional IT has. Some companies are already moving and including IoT and OT (operational technology) topics into their general IT agenda and roadmap. Others are trying and evaluating what impact the digitalisation will have on their shop floor, company or even smart city. In APAC 64% of all sampled companies believe that IoT development will be “important” to “critically important” within the next 12 months.
The typical embedded development project
The applications that are targeted vary widely from sensor driven applications and industrial development over smart buildings and more consumer oriented topics such as smartphones, wearables or connected vehicles. A common ground for all these projects is that the final solutions can be deployed anywhere in the world making it very crucial that these devices can be managed, updated and maintained over the full product lifecycle.
A very interesting fact is that embedded project teams often need a very broad range of knowledge that covers many different areas of competence. This can go from hardware development such as CPU compute boards, sensors or interface electronics over firmware engineers working on the hardware related low level programming to high level application software development. Comparing this again with regular IT systems this would mean that the embedded project team is doing everything from assembling your laptop, developing Windows, developing Word and operating and updating this over the full product lifecycle.
As can be seen above a typical embedded project team consists of 14.1 persons for EMEA. If we assume that large consumer projects such as connected vehicles or smartphones will have much larger teams than we can estimate that the real industrial embedded team will be even much smaller than 14 people. That is also consistent with what we experience from our customers. Looking at the above graph and using those numbers a typical team handling the software related part of an embedded project would be 3.5 software engineers and 1.6 people working with system integration. So approximately 5 people are responsible for preparing an operating system, developing remote OTA update capabilities, remote access, security hardening, device management and last but not least to develop the application software. If you compare that with typical team sizes of other software projects these are very few resources for so many challenging tasks. In order to make this work efficiently it is very important to select tools that can help to succeed with this challenge.
A typical industrial Iot development team has a very small size taking into consideration the amount of competences needed.
As can be seen in the diagram below cloud integration tools such as firmware updates or device management are making an inroad into development but are still not standard everywhere. We consider it a very high project risk to not rely on standard building blocks to solve these challenges and that is why we have developed the qbee.io device management and remote access solution. This allows both large corporations and small and medium enterprises to deliver projects with a broad range of useful functionality already in place and that is maintained and supported without loading the limited IoT team resources even further. We strongly believe that the real value creation happens in the application software through the application data.
We strongly believe that the real value creation happens in the application software through the application data.
Looking at the profiles of the different project members AspenCore reveals some other interesting findings. It seems like project participants have a fairly high level of experience which corresponds very well with the graph that shows that they need to have a very broad range of competences. In 2019 the average project member was already 26.3 years out of school and thus had time to acquire a large amount of competence and experience. From our own experience with customers we see often that people have moved from one area of competence (for example hardware design) into software as this was a competence area that their employer lacked resources.
Another interesting fact from the survey reveals that most projects do not use embedded virtualization or hypervisors yet and are not planning to use those within the next 12 month. In general IT virtual machines and hypervisors have been a key factor in increasing efficiency and making large scale deployments manageable. For embedded projects the virtualization topic is not that important yet probably due to the fact that devices are often using very low level hardware functionality and that most devices have a fairly consistent use case. But when systems are deployed with the intention to run for years rather than to be redeployed all the time it is crucial to have the necessary configuration management and monitoring systems in place.
This survey gave an interesting insight into today’s embedded development reality and the challenges that arise from there. We encourage readers to look at the original survey from AspenCore. There are many other facts to be discovered and we are looking forward to the next update of this survey.
