Intel Developer Forum 2016 (IDF) produced quite a few announcements this year, including the Joule, a powerful IoT dev kit. Although targeted at makers, Intel and partners spoke about how this Joule can be used for industrial IoT use cases --- cases like augmented reality safety glasses for manufacturing environments from PivotHead.
This spawned an interesting debate in geek circles --- Is Intel Joule just a maker's tool, or does it have a place in the hands of the IoT professional/enterprise.
Here is how the exchange went amongst three Red Hat IoT aficionados: Rich Naszcyniec @naszcyniec, Paolo Patierno @ppatierno, and Ishu Verma @iot_ishu):
Paolo: "Building IoT devices for production takes a lot of more sweat and blood than a Maker project."
I come from the embedded devices world. I wrote code during the time when maker platforms like this didn't exist, and the cheapest evaluation kits cost hundreds of dollars … today we have products that cost just dozens of dollars
I don't like it when people consider these platforms to be ready to use as an embedded device for IoT without re-engineering them first... and trust me ... there are a lot of people who think like that out there.
A lot of software developers are moving to the IoT space not only on the cloud side but on the devices side as well.
We should be worried about that and what the world could be with such devices not being developed from scratch by an engineering team with both hardware and software knowledge thinking about all the concerns related to the environment.
These new developers are helped by the “huge” amount of resources they have on devices today (or something similar). These are more like “little” servers ... not like devices with a few KB of RAM and Flash.
I only hope that all these boards are for a makers’ market or at least used by enterprises for fast prototyping (validating an idea), demos and POCs.
It's also true, at least as far as I'm aware, that current industrial products are not based on Galileo, Edison, Raspberry Pi .... isn't it?
Rich: "Maker approach works for new markets like IoT"
Serious question. What is the harm you are concerned about? I am sure amateur board makers and teams will put some items on the market with flaws. But honestly, it won't be the first time I have seen that happen. Even with devices I installed prior to the maker movement. I have boxes of purchased but now dead items I keep thinking I will scavenge a part or two from.
Personally, I am thrilled by the maker movement. It revitalizes interest in science and specifically electronics. I see it more and more often in the schools which is fantastic. Our kids see that it is ok to believe they can make gizmos. Heck, it even gets software "veterans" like myself interested in the hardware side of the business. A side that for a long time I felt was not approachable since I don’t have an electrical engineering background. I’m just a guy with a degree in marketing with an unrecognized minor in computer science.
Another factor to consider is that todays mantra for software development is build fast and fail fast. With maker kits, the same mantra can be adopted for IoT. There are just so many possible uses for IoT it is hard to know what new idea will stick in the market. Don't cheap maker kits make it easier for a person or team with an idea give it a try?
Paolo: "IoT/embedded products need be production grade"
Absolutely... the maker movement revitalizes interest and as you said it's great for schools... it's fantastic for me… however was the Raspberry Pi born for this reason ?. My son is 4 years old and I'm waiting to start teach him something using these boards.
It's also true that you can just set up an idea in a short time validating it before starting the real development
The problem is ... if it's done by "professionals" then they know very well that in order to have the final product they need to move to a solid platform that is not leveraging on the maker board. Even in the past, the “professionals” already knew about starting to develop on evaluation kit but then moving to a re-engineered board for production and not selling the dev kit as a final product.
If it's done by "a non professional" ... it could become the final product! Trust me ... this happens today.
There is a quite interesting article, “makers and professional”, which explores the way these different figures are related to each other and can work together-- over the years some great ideas were born thanks to makers but then the actual working product came with professionals.
On moving from the idea stage with a fast prototyping and validation step to an engineering phase, the AgileIoT manifesto and related framework are quite interesting. These define how it’s possible to apply Agile methodologies for developing and deploying a complete end-to-end IoT solution.
A lot of non-embedded developers are moving into the IoT world ... it doesn’t seem so positive to me because they don't have the full background for doing this. As I said, they are driven by cheap boards and great tools and languages ... but making a device work 365/7/24 is a different thing.
I don't like to think that my self driving car could be based on a Raspberry Pi with an application developed in NodeJS :-)
Of course it's a limit ... fortunately in some markets ... the “things” are taken more seriously and built from production-grade components.
Ishu: "Don’t forget the things need to be integrated with enterprise systems"
I agree with Paolo that the production-quality criteria are essential for mission critical systems or widely deployed systems. The QA requirement for these systems is much more stringent but the downside is that it takes a long time to develop, test and deploy these systems. Once deployed, these systems continue to provide the same functionality they're designed for for a long long time so it's ok to have a long design cycle. This is similar to how enterprises design and deploy their current systems. In order for IoT devices to be integrated with existing enterprise systems, these devices need to follow the same stringent criteria for deployment or they’ll put the entire system at risk (being the weakest link).
Rich: "Fail fast approach allows for a short shelf life"
Thanks for the great reply. I thought that was the point you were making but wanted to make sure.
It is interesting that you have concerns about "sloppy" hardware that can stem from quick prototyping and result tools available for use. I have similar concerns about software and people who take software microservice ideology to the extreme. I sense there is a rush to produce but not ensure the microservice is efficient, secure, etc.. You can get away with "sloppiness" easier with software than hardware. Especially now with microservices that can be deployed to run once with all its inefficiencies, get destroyed, and then a new instance takes its place. Why worry about a runtime that runs in a timespan potentially measured in seconds or less? I guess the parallel with cheap hardware could be who cares if it only lasts X months/years/etc. A new one is easy and cheap enough to replace it with.
But is that a healthy direction? I think you have the same type of question/concern.
Paolo: "IoT products need to meet stringent industrial-grade criteria"
It's true what you say ... that it can happen even in the software-only industry with microservices, for example.
When I said 365/7/24 I didn't mean only problems with a maker board which can't satisfy the requirements but the software as well. In the embedded/IoT world, your software enables the device to interact with the surrounding environment; code mistakes can be catastrophic even in terms of human lives.
Regarding the hardware, it's not so simple to replace it ... let's consider an IoT solution for a tanker in the middle of the ocean :-) It's better to have a rugged device which will run for 10 years and avoiding having to reach the tanker for substituting the Raspberry Pi every month.
Just to be precise and avoid misunderstanding ... when I say that maker boards are not so good for real products I mean the board themselves, but not the modules on them
...
For example, regarding Intel Joule ... I don't think that having the entire board as a final product could be good but having the Joule module on a re-engineered board could be just the right thing, ... of course, if the module itself is good :-D
Regarding the software, the cheap boards and high-level languages usage allows other "types" of developers to approach the embedded/IoT world ... where there are a lot of other concepts not related to the software (hardware protocols for example) ... they can make a lot of mistakes having a poor result.
I personally know a lot of developers (here in Italy) moving from Web and mobile applications to embedded devices ... just to have more business thanks to the buzz word ... I saw some code ... (silence)
Of course it's true that there are other good developers who start on this path studying from scratch and improving their knowledge seriously on the hardware perspective.
Rich: "Fast prototyping with maker and then switching to production with industrial grade"
What people do in the makerspace is great ... these boards allow them to get in touch with new technologies and that's awesome!
If someone really wants to make a commercial product, I can see using these boards for fast prototyping and demos ... before jumping to commercial hardware.
Ishu: "We’re all saying the same thing….."
I think we all agreeing that we need to have both approaches as they solve different problems.
For areas where the technologies and standards are still evolving, the maker approach would serve the needs better as the traditional embedded product development takes too long and is not suited for devices that need to be modified frequently. Once a winning solution emerges that is ready for wide deployment then it can then be hardened using the traditional embedded methodologies that Paolo describes. In addition, these products also need to follow the enterprise best practices for security, management, etc.
Conclusion:
IoT is a huge area with dozens of use cases. We need to have both approaches as they solve different problems. For production systems, whether mission-critical systems (e.g. system for an oil rig in the middle of ocean, health care equipment, etc) or widely deployed systems (e.g. RFID card readers), the stringent quality criteria need to be met.
This means the IoT solution needs to be built with industrial-grade hardware and software components (e.g. Eurotech ReliaGate 20-26 IoT Gateway). These systems are built right and it takes time to develop, test and deploy these systems but they stay in operation for a long, long time.
For IoT use cases that are still evolving, the fast prototyping offered by the makers’ style design approach would serve the needs better. These systems are used for development/testing and are repeatedly updated, upgraded or replaced. The traditional embedded development model is not suited for these use cases where product features, standards and architectures are still evolving. Once a winning solution emerges that is ready for wide deployment then it can then be hardened using the traditional embedded methodologies.
