Taking IoT to production
IoT promises to take your next big idea to the level where you replace an "Intelligent", "Little" device to do some cool stuff. And almost all of us begin with this in our garages/workshops.
You have built the next awesome IoT device on the do-it-all bread board with wires hooked up and working perfectly. While your internet friends see you as the next #inventor #maker, you would want to fast-track it to be ready-to-market.
Taking your big idea needs a fair amount of rethinking, improvisation and reworking to match the needs of a consumer "durable".
#Reason
Reason with yourself on what are you making! Answer the whats, whens, whys, whos, wheres, hows and buts...
#Reliability
Reliability and last mile uptime + connectivity with IoT systems is a first class requirement. Most IoT applications are suited very well for remote areas. Taking a trip to far end areas just to realize a loose connection is unacceptable. You want to design / print / fabricate a PCB and solder your components instead of letting them hang around loosely tethered with zip ties!
www.jlcpcb.com is a place to look at for limited quantities of your PCBs at affordable rates.
And don't forget an enclosure box!
#Consistency and #Atomicity of work
Imagine driving down the Highway / Motorway and 100mph. And you have a self designed embedded device with the responsibilities below
- Activate the AirBag in case of a collision
- Show the Airbag stats to the driver at all times
- Turn off the music in case of a collision
- Cut off the fuel supply
- Call an SOS number with essential details.
Would you trust your micro controller board to deploy (without latency) your airbag in case of an accident, and in what order? For the sake of discussion, try reordering those priorities and imagining the results!
It makes total sense to decouple the airbag deployment system UI! And we're not talking MVC here. We want the systems to be autonomous in isolation, yet be able to interconnect. A good choice is to design isolated systems and interconnect using an industry standard protocol such as TWI/RS232. Doing that not only ensures that controllers are decoupled but also prepares them for future integration with other industry standard systems.
#Soft Reboot / Reset
All devices fail. Yes they do!
There is a saying in the micro-controllers fraternity, "if it doesn't get fixed by a reboot, it's going back to the design table".
Most micro-controllers/ board have a way of resetting the board. Figure out if you can force a reboot via your firmware or OTA, or worst triggering the watchdog or brown out detector. You *will* need it.
#Fault Tolerance
All devices fail. Again, yes they do!
Frankly, this really boils down to the time you spend on your firmware, foreseeing solutions. There will be faults and resetting will be in an option, but not always! You want to have a way of
- Moving on when faults occur. You do not want the board to be stalled because it could not communicate with the LCD or failed a network connection. The priority rule applies!
- Logging and Reporting all faults.
- If your device is a source of data, you absolutely want to have a way of recovering from data transmission errors, such as a cache policy or a re transmission policy
- Most IoT devices have limited memory to store logs, so have a way of rotating your logs or shipping them to another location
#Power Consumption
This one is my favorite!
I have seen countless IoT devices "assembled" in a jiffy and plagued with BDS, the battery draining syndrome. Button batteries requiring a change every 7 days! Okay, using a power adapter is a quick solution but then the real question is if the power footprint is even optimal!
Further, I've seen enough prototypes for IoT based power saving systems using power hungry micro-controllers to figure out if a switch is on or off!
Take out the time to do some math. Ohm's law and a number of online calculators come in handy. Know what your device needs. Let it run for a week or so during development and project the power needs. See if any onboard things are really require? For instance using a beasty 32 bit processor to do a job that an 8 bit processor can do. It is a serious waste of energy and development time. #YAGNI applies!
Know the #working environment
Another of my favorites! This is best explained with a case study
We were recently working on a product that promised automated data capture from CNC machines!
We built the hardware, wrote the firmware and setup the backend on the cloud. We were super-happy. First day into the installation, and we got 3 million data points wheres ~1000 were expected. This never happened in the test setup. Our device was being subjected to industrial noise from high frequency motor drives in the vicinity! Something we could never have replicated in the test environment.
So we #reiterated (see below) and reworked the firmware. We were super-happy. First day into the upgraded design, and we got less than the required data points! This never happened in the test setup. Most of our devices gave up because the power lines to the device were spiky! Two out of three test devices killed-in-action.
So we #reiterated (see below). We now have a product that is suited to industrial working environments.
#Stateless
IoT units are normally seen as services. Here, I propose a different viewpoint;
It totally helps to see your IoT gadget as a worker unit (reporting to the boss - mqtt broker / backend server) and not the complete service.
IOT devices wanting to save states tend to disrupt designs in the long run. These devices are intended to be networked and sooner than later one runs into challenges of dropped network connections leading to out-of-sync data, anomalies and conflict resolution.
Any of these conflict resolution algorithms put onto the IoT device is going to add significant processing loads on the device. Let the backend do this. For instance, if you have dirty data coming in, reject+log data instead of trying to clean it at the device level.
Make IoT #Priority-Dumb
Yes you heard that right. IoT devices need not be intelligent!
They need to be workhorses, doing things, not spending time thinking. Critical, hard time driven decisions are the only ones that should be offloaded to the device.
For instance, if you had a car with a connected safety air-bag system, your IoT system should be interested in driving the airbag rather than displaying to the user the inflated pressure of the airbag when deployed!
Write your own #backend
Speed of processing and speed of development have always had a trade-off. Using off the shelf systems is good but one can get limited quickly. Of course, they are good to get you started; keeping network paths minimal and reducing N + 1 problems is always useful and snappier.
Sooner, than later, you'll realize that IoT data is all about short sized data packets, millions of them! If you're writing APIs, you want them to be quick, asynchronous and responsive!
Use basic #protocols for networking
Using PROfinet / Modbus / CAN sounds cool, but nothing beats the simplicity of I2C or SPI. Use basic protocols as much as possible. Wire up your own protocol around the basic one if the basic protocol is limiting. Using tight bit packing helps. bandwidth is expensive. Be frugal with bytes. Use MQTT over HTTP!
#Dealing with hijacks
IoT devices are built for unattended operation. After all that's the point of a "thing". Hijacks can go unnoticed and IoT being a non event driven system, detection as well as recovery can be an expensive affair. Have a way to quarantine and block devices, and have it handy.
Better still, enforce a deny first grant policy instead of an allow first.
Log everything, every time and leave identifiers, signatures. Have a way of detecting legit vs illegit traffic.
#Security Controls
Security of IoT devices works on three levels
- Hardware Security- Having a way to remotely activate/block or white/blacklist your devices is way to go. Have a way of identifying and flagging blacklisted devices when they try to connect to your backend. Use inbuilt hardware IDs such as MAC Id or chip serial numbers, these are hard to change.
- Firmware Security - this is a no-brainer really. Almost all software tool-chains for popular platforms have integrated security features, and are generally enabled by default. One can easily protect firmware from being reverse engineered or even read back from the chip. A little Googling helps!
- Device Specific Data Security - This is analogous to "user-data" in the IT parlance. You need to build a zero tolerance policy on recording, storing and transmitting device specific data. record what is necessary, store what is necessary, securely transmit what is necessary (hint: https), always!. And most importantly, you want to have a way for a complete data wipe-off or self-destruct!
#Log everything
Logging is your only way of seeing what's going on inside the device. Most IoT devices run headless or have a significantly limited user interaction. Looking at the logs / trace is your chance of figuring out what's going on. Soon enough, logs will get large, huge! Have a way of shipping them off or extracting them to save on board memory and bandwidth.
#debug in-silo
It also helps to have a multi level logging systems enabled. So everything that is debug specific, can be enabled during development. Have a way of putting your device into debug mode such as holding down a button sequence while powering on or use the onboard UART to send data to an external terminal!
#Learn C
Arduino IDE is cool, but take out time to learn a low level languages like C or Assembly. You will be amazed on things that one can do efficiently with low level languages. Yes sure these were your degree college dreads but then efficiently is the keyword here. Write your production code in C, preferably using the manufacturers SDK. You'll be able to supercharge your chips, even super-clock them at times. Try doing that with Arduino IDE. It's built for prototyping.
Use software to #Simulate #Hardware and Debugging
Write or find a piece of software that simulates the hardware!
Emulators are commonly available and will go a long way in shortening your time to market. Further, emulators can also eliminate initial struggles such as setting up the hardware correctly for testing etc.
Emulators will do what virtual machines have done to software development cycles.
#Reiterate, #Recover
Finally, you're not going to get it right the first time! Be Agile! Don't be afraid of reiterating your design. You'll know the rules of business in the first few projects!
I hope this helps you with your journey in taking your IoThing to production. Go, Build!
Comments