Home > On-Demand Archives > Talks >

IoT Fault Lines

Steve Branam - Watch Now - Duration: 40:58

Steve will outline the fault lines in the elements of the IoT triad: the embedded devices, the frontend user applications, and the backend server applications.

These fault lines are a common source of problems during development, testing, deployment, operation, and maintenance of IoT products. The goal of the presentation is to heighten awareness of them to avoid nasty surprises, and present some strategies for managing and mitigating them.

M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

Doini
Score: 0 | 3 years ago | 1 reply

Thank you for the clear and instructive presentation! If you don't mind, would you recommend us a book about the basics of IoT ?

SteveBranamSpeaker
Score: 0 | 3 years ago | 1 reply

Thank you! Unfortunately, I'm not familiar with any books on the basics of IoT. There may be some out there, but in general the model is still new enough that I haven't seen any literature on it. There's plenty of information on embedded systems, backend microservices, and frontend apps as individual projects, so it might be practical to read some of those with an eye toward an integrated approach, aware of some of the issues I presented.

Doini
Score: 0 | 3 years ago | 1 reply

Thank you for the answer, I appreciate it.
Also, I would like to mention that your format of the presentation with just a few points on a page and explaining each of them verbally was easier to follow than ones with more text on the page. And then having the explanations written under the points on the pdf slides, it was very helpful to follow again the presentation.
Thank you!

SteveBranamSpeaker
Score: 0 | 3 years ago | 1 reply

Thank you, that's very valuable feedback! That's EXACTLY what I was trying to accomplish with that format, so I'm glad to hear it worked for you.
My initial version was very much like the typical text-heavy presentation. But I've been learning about TED talks and the push to have just a little bit on a slide, which led me to completely redo it. The final written information on the PDF is the same, but I reorganized it and completely changed the way I presented it. Then I did a third iteration that replaced some of the static slide narration with the interstitial videos.
All with the goal of keeping the presentation dynamic and engaging, and communicating information effectively.

Doini
Score: 0 | 3 years ago | no reply

Yes, now I was focusing on what you said and understood better the idea. With other presentations with the full text on the slide I was trying to read it and I was losing what the speaker said.
Thank you again!

RayS
Score: 0 | 3 years ago | 1 reply

Great presentation, with a lot of very practical ideas. It would be easy to use the ideas in this presentation as the template for a master project plan.

SteveBranamSpeaker
Score: 0 | 3 years ago | no reply

Thank you! I hope you can put some of them to use. Your development team would probably appreciate it!

Greg
Score: 0 | 3 years ago | 1 reply

Thanks, Steve. I very much enjoyed your presentation.
We are a little beyond neophyte in our IoT journey, but nowhere near as disciplined (yet) as your presentation recommends. To that end, we have been looking at trying to automate more things, but find existing automation tools for embedded to be scarce. Do you have suggestions for off-the-shelf tools to help with automated building and, especially, automated testing that can be done for embedded devices (e.g. ARM Cortex-M microcontrollers)?

SteveBranamSpeaker
Score: 1 | 3 years ago | 1 reply

Thank you! I'm sure there are some tools out there for automating embedded work, but unfortunately I haven't see anything specifically. The closest thing I've seen is CI/CD pipelines that do the embedded toolchain build. This is where TDD can be a big help, because that's where you can create off-target unit tests that you can incorporate into the pipeline (see James Grenning's stuff for embedded TDD and off-target testing).
Beyond that, what I've seen is custom Python-based automation for testing. Invest some time in building out a test infrastructure to drive things, then build test suites based on that.The infrastructure would provide the various embedded-specific control of the test environment, including setting up and controlling simulators, real hardware,.and physical test fixtures. That includes everything from performing OTA on the device under test to load the right code, driving test scenarios with commands and test hardware devices (such as an actuated arm that moves on command so that you can trigger a sensor on the device under test), and collecting and summarizing test results. Probably the reason few off-the-shelf automated tools exist is that this tends to be very project-specific.
You can see that this requires some real investment, so takes management commitment to spend the time and money to do that. Make that a real project in itself, with dedicated staff (might just need one person, but could certainly grow bigger depending on the complexity). But you need people whose job it is to think about how to go about doing that testing and make it happen, not just as an afterthought.

Greg
Score: 0 | 3 years ago | 1 reply

Thank you for your insight. This is similar to what we've run into ourselves.
And I totally agree with the automation stuff being its own project and requiring management support. We had a hardware engineer who was working really hard to get this to happen and was making some progress. Alas, he decided to go back to school to pursue an advanced degree, so that strong voice is lost. I think management is still interested, though, so I may point to some of your advice as justification to continue on.

SteveBranamSpeaker
Score: 0 | 3 years ago | no reply

Excellent! That's exactly why I did this presentation, because people may not realize these things are needed. Plus they may be in denial that it's a cost of doing development.

Johnpauliloh
Score: 0 | 3 years ago | 1 reply

I joined the conference from Nigeria. It's an amazing experience!

SteveBranamSpeaker
Score: 0 | 3 years ago | no reply

That's awesome! I'm glad you're finding it useful!

Carl
Score: 0 | 3 years ago | 1 reply

good recap
well presented
thank you

SteveBranamSpeaker
Score: 0 | 3 years ago | no reply

Thank you!

krish
Score: 1 | 3 years ago | 1 reply

Very informative. What about energy-profiling/energy-efficiency testing? Thank you very much.

SteveBranamSpeaker
Score: 1 | 3 years ago | no reply

Yes, for battery-powered devices, this becomes a top priority testing item.
You need to measure idle/sleep power, awake power, transmit-busy power, and per-message exchange power consumption, much like CPU and memory consumption. And if the device is actuating devices, power consumption doing that.
You also need to test functionally to be sure that radio duty cycle doesn't get too high; a bug could result in transmitting for longer-than-expected periods, sucking up lots of power. A bug could also keep the device from sleeping. Then battery life drops from years to hours.

OUR SPONSORS