Internet of Smaller Things
•Download as ODP, PDF•
4 likes•1,110 views
Jon Cruz discusses the challenges that need to be overcome in order to create robust IoT systems and how IoTivity is serving this need.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Internet of Smaller Things
Similar to Internet of Smaller Things (20)
More from Samsung Open Source Group
More from Samsung Open Source Group (14)
Recently uploaded
Recently uploaded (20)
Internet of Smaller Things
- 1. Samsung Open Source Group 1 Internet of Smaller Things More of Less is More Jon A. Cruz Samsung Open Source Group jonc@osg.samsung.com
- 2. Samsung Open Source Group 2 Why IoT?
- 3. Samsung Open Source Group 3 Why IoT? ● Simple answer: – It's coming in everywhere – Tipping point has been passed – Details left to other sources
- 4. Samsung Open Source Group 4 Why IoTivity?
- 5. Samsung Open Source Group 5 Why IoTivity? ● Open – Open Source – Open Standard – Open Governance ● Implementing OIC spec ● Licensing clarity ● Vendor agnostic
- 6. Samsung Open Source Group 6 'Smaller' ?
- 7. Samsung Open Source Group 7 What is 'Smaller' ? ● Size ● Specs ● Data-sets ● Applications – Aka 'apps' ● But not impact
- 8. Samsung Open Source Group 8 Smaller Size ● 85.60 mm × 56.5 mm ● Not small enough
- 9. Samsung Open Source Group 9 Smaller Size ● 35.5 mm × 25.0 mm ● Not small enough
- 10. Samsung Open Source Group 10 Smaller Size ● 18 mm x 18 mm ● Not small enough
- 11. Samsung Open Source Group 11 Smaller Size ● 12 mm x 12 mm ● Getting there
- 12. Samsung Open Source Group 12 Smaller Specs ● Limited processor – 32-bit or even 8-bit – Often microcontroller ● Limited RAM – 1 GB, 1 MB or even down to 8 KB ● Limited storage – Flash – 4 GB, 4 MB or even down to 256 KB
- 13. Samsung Open Source Group 13 Smaller Specs RAM Flash Raspberry Pi 2 1 GB 4 GB Edison 1 GB 4 GB Artik-1 1 MB 4 MB Curie 80 KB 384 KB Arduino Due 96 KB 512 KB Arduino Mega2560 8 KB 256 KB
- 14. Samsung Open Source Group 14 Smaller Specs (unified) RAM Flash Raspberry Pi 2 1024.000 MB 4096.000 MB Edison 1024.000 MB 4096.000 MB Artik-1 1.000 MB 4.000 MB Curie 0.078 MB 0.375 MB Arduino Due 0.094 MB 0.500 MB Arduino Mega2560 0.008 MB 0.250 MB
- 15. Samsung Open Source Group 15 Smaller Data-sets ● Issues with data – Storage – Bandwidth – Connectivity ● Usefulness ● Aggregated is not smaller ● Privacy – Gets into business concerns, legal issues, etc.
- 16. Samsung Open Source Group 16 Smaller Applications ● 'Apps' or programs ● Space limits complexity ● 'Targeted' hardware – Less general – More task-oriented
- 17. Samsung Open Source Group 17 Smaller Devices Increasing ● Originally shrinking PCs – Leveraged existing Internet experience ● Now growing microcontrollers/modules – More contributions from 'Makers' ● Less is more ● More of less is more – Lots of smaller devices – Self-organizing
- 18. Samsung Open Source Group 18 IoTivity Approach
- 19. Samsung Open Source Group 19 IoTivity Approach ● Single, unified code-base ● Multi-platform ● Stacks and Layers
- 20. Samsung Open Source Group 20 Single, unified code-base ● Cross-platform ● Multiple tool chains ● Disparate platforms ● Edge cases to cover more
- 21. Samsung Open Source Group 21 Multi-platform ● Current – Linux – Arduino – Android – Tizen ● In-progress – OS X – iOS – MS Windows
- 22. Samsung Open Source Group 22 Stacks and Layers ● Built upon each other – Core functionality by taking a subset of the code – Simplifies verification – Easier to correct and bug-fix ● Other solutions have separate code-bases – Many problems from this approach
- 23. Samsung Open Source Group 23 Core is Common ● Implemented in C ● Some optional features – More features in higher layers
- 24. Samsung Open Source Group 24 Layers on Top ● C++ layer adds functionality to the core – Ease of development ● Java wrapper layer – Same core library executing on Android – Exposed in Android friendly manner – Possible to implement in pure Java later
- 25. Samsung Open Source Group 25 Classes of Platforms
- 26. Samsung Open Source Group 26 Classes of Platforms ● Focus on common code ● Certain exceptions ● Groups of platforms – Linux – OS X – Tizen & Android – Arduino
- 27. Samsung Open Source Group 27 Differences ● Linux ● UNIX ● Tizen & Android ● Arduino
- 28. Samsung Open Source Group 28 Linux ● Default target/assumptions ● Older and newer distros targeted
- 29. Samsung Open Source Group 29 UNIX ● BSD and OS X differ in certain ways – e.g. clock_gettime() – Generally covered by POSIX info
- 30. Samsung Open Source Group 30 Tizen & Android ● Different in similar ways ● Both stripped down for devices – Network code is the most common divergence
- 31. Samsung Open Source Group 31 Arduino ● Represents device/micro-controller world ● Unique challenges – Logging can be especially troublesome ● Helps keep other platforms clean
- 32. Samsung Open Source Group 32 Build System
- 33. Samsung Open Source Group 33 Build System ● Implemented as a 'build', not just scripted – Setup targets, dependencies, etc. – Allow the system to do the heavy lifting ● Mainly SCons – Subs out to other systems ● Android ● Tizen ● Set dependencies correctly
- 34. Samsung Open Source Group 34 Cross-compile ● Build for different platform than the current ● Allows one system to check many – e.g. all devs can validate changes didn't break other platforms ● Improves developer habits and code quality
- 35. Samsung Open Source Group 35 Architectural Issues
- 36. Samsung Open Source Group 36 Split between C & C++ stacks ● Simpler/required functionality in C ● Complexity and helpers in C++ ● C++ stack build on top of C ● Java wrapping C/C++
- 37. Samsung Open Source Group 37 Focus on Protocol/Messaging ● Initially CoAP – Abstracted and potentially replaceable ● Abstracted stack from transport – Higher levels avoid transport and protocol details – Lower levels implement individual transports
- 38. Samsung Open Source Group 38 Threading ● Threading not supported on all platforms ● Details have been abstracted – Internal functions and structs for threads, mutexes, etc. ● Work in progress – Moving threading out of lower levels and into higher – Tuning and synchronization optimization
- 39. Samsung Open Source Group 39 Coding Design & Practices
- 40. Samsung Open Source Group 40 Coding Design & Practices ● As cross-platform as possible ● Minimize code duplication – #ifdef for certain functionality ● Focus on feature not platform/OS – Files excluded from other situations ● Platform dependent code ● Specific transports ● Had to reduce file duplication
- 41. Samsung Open Source Group 41 Platform Specifics ● Languages in use ● Compiler versions – Bugs ● Tools available ● APIs/functions available – Tizen/Android networking ● Unique aspects
- 42. Samsung Open Source Group 42 Arduino ● Standard tool-chain ● Minimal capabilities ● Constants/strings in flash – PROGMEM ● Needs explicit calls to access – F() ● Wraps string constants ● IoTivity added to logging macros
- 43. Samsung Open Source Group 43 C Practices ● Minimize memory use – Flash/program size – Runtime RAM ● Minimize duplicated code ● Follow standard functions – Look at POSIX + extensions – Use 'man' liberally
- 44. Samsung Open Source Group 44 C Practices ● Be explicit on target spec – C99 ● -std=c99 – Avoid compiler extensions when possible ● minimize -std=gnu99
- 45. Samsung Open Source Group 45 C Practices ● Enable and watch warnings – Know which ways to get desired warnings ● For gcc, -Wall -Wextra – Do not ignore warnings – Use fatal warnings when possible ● Fix, don't suppress!!!
- 46. Samsung Open Source Group 46 C Practices ● Use reentrant functions – e.g. strtok_r() instead of strtok() ● Pass by reference – Watch for structs passed by value – Prefer refs/pointers ● Use 'const' – Especially on pointer parameters – Easy to remove, but hard to add later
- 47. Samsung Open Source Group 47 C Practices ● Use 'static' – Limit visibility and impact of file-local globals ● Avoid use of globals – Eliminate when possible – Replace with context pointers – Leverage reentrancy ● Follow practices of POSIX foo_r() functions
- 48. Samsung Open Source Group 48 Questions?
- 49. Samsung Open Source Group 49 Thank You!
- 50. Samsung Open Source Group 50 References ● Credits – Images ● Original Raspberry Pi drawing CC BY-SA 4.0 Efa2 – https://commons.wikimedia.org/wiki/File:Raspberry_Pi_B%2B_rev_1.2.svg
Editor's Notes
- Welcome to this presentation on the Internet of Smaller Things
- A first question might be as to why someone should care about the Internet of Things (IoT)?
- The answer to 'why' is quite simple: the Internet of Things is coming in strong, is likely to be encountered most anywhere and has definitely passed the tipping point More details on IoT and why it is important will be left to other presentations, and we'll move on to focus on the more pertinent question...
- Why IoTivity?
- There are many reasons developers and companies should care about IoTivity. The key one is that it is 'open' in most ways. It is an open source project, focused on implementation of an open standard, and is run under open governance. The main focus of the project is to implement the standard from the Open Interconnect Consortium (OIC). One factor is to have clarity about licensing, but this talk really isn't about that so we'll leave that subject to the legal and business teams And finally a strong point for the IoTivity project is that it is vendor agnostic and trying to advance collaboration.
- Drilling down, this talk is addressing what I call “Smaller” things. But what exactly does that mean?
- Well, there are several ways in which 'smaller' can apply. Devices can be physically smaller in size. They can be smaller in specs and capabilities. They can be smaller in regards to the data sets they produce and mange. They can also be smaller in terms of the applications running on them. All are valid points to keep in mind for IoT. However the one way that I don't expect them to be smaller is in their impact.
- Looking first to smaller physical size we might consider the Raspberry Pi. It's very small for a computer… but still that isn't small enough
- The Intel Edison comes in at about the size of an SD card. Very small for a computer at about 888 mm², but still not small enough
- The Intel Curie drops things down to button size, 255 mm² and almost as small as a U.S. dime. But again, still not small enough
- The Samsung Artik-1 drops things down even more, and at only 144 mm² is really getting there. What these examples do show, however, is that the size of devices is changing rapidly and that includes being in response to needs of different uses.
- For developers, though, the more important way of being smaller is in regards to capabilities. In these modern times of massive desktop computing power, the devices for IoT can be a major step backwards. 32-bit or even 8-bit processors instead of 64-bit. Limited RAM, with one gig being on the 'huge' end. And limited storage that can be a quarter of a megabyte or possibly less
- Running through a quick breakdown of our examples it's clear to see that there is a range to them, but also that they are definitely on the 'light' side of computing power. However, let's change things up a bit to have a better picture
- If we unify the the way our sizes are listed it suddenly becomes clear that some of these are very very small. You can also quickly see an initial split where the top two items are effectively miniaturized computers while the others in the list are more of what I would consider “small devices”
- Aside from the processing power of the hardware details, we also need to consider smaller data-sets. There are issues with data for IoT devices that include storage, bandwidth and even connectivity. Then in and of themselves, the data-sets from individual devices might not be as useful as some sets we are used to. However… when aggregated we can end up with the exact opposite of smaller for IoT data-sets And of course in these modern times the privacy aspects of the data-sets also will not be small
- And finally for “smallness” I'll touch on the applications running on the IoT devices. You're not likely to have something as complex as a whole office suite or full relational database running. The nature of the devices limit the application complexity. Additionally these devices are likely highly targeted and specialized, so won't have need of more general purpose computing apps.
- The number of smaller devices along with the chance of encountering them (even unknowingly) is constantly growing. By becoming smaller, they can be used in more and more places. By becoming used and coordinated they can allow very complex scenarios to be played out… complexity from aggregation.
- Now that some of the conceptual IoT basics have been covered, let's move on to the substance of the IoTivity project itself.
- The project's approach is to have a single unified code-base that works across multiple platforms and is cleanly layered into stacks and an easy to use library.
- Aspects of a unified code base include that it is cross-platform code, that multiple tool-chains might be employed in building it, and that disparate platforms are supported. To help with coverage, edge cases were selected to help verify more platforms will be easily added.
- The current target focus is on Linux, Android, Tizen and Arduino. Then OS X and to a lesser degree iOS are targets of opportunity. Finally Windows support will be addressed, but is not a primary area at the moment. The main limiting factor is just in having enough people to support and QA the various platforms.
- Again, IoTivity is focused on layering up functionality and support. I'm aware that other projects might have separate source code trees for different targets, but over time that tends to get messy and has many issues.
- The IoTivity core is a library implemented in C with just a few optional features. More features are added in higher layers.
- Some of the higher layers include C++ which gives developers more functionality and a bit more ease in development, and a Java layer that wraps the main library up for use on Android systems.
- Of the different platforms IoTivity is targeting, there are a few classes that they can be grouped into.
- The project has focused on common code. It does have a few exceptions here and there. However the main breakdown of the current code-base can be covered by these four groups.
- These targets have differences in code and some on the implementation. Ideally, however, the IoTivity library will be minimizing those differences for developers who are just using it.
- Various Linux targets are the basis for the default assumptions and coding. We are trying to cover a good range of platforms, including older Linux distros. Unfortunately when it comes to hardware going out the software might not be updated as quickly as developers might like.
- The UNIX platforms, which includes Mac OS X, are close to Linux in coding. The differences are usually covered in POSIX info.
- Tizen and Android are essentially more specialized platforms that have been tuned and stripped down for devices such as phones. However it turns out that many of the ways that writing code for them differs from say a Linux desktop are actually similar to each other.
- The Arduino devices, on the other hand, are very different and represent the smaller more microcontroller view of things. However, by addressing the unique challenges of coding for the more restrained hardware the code itself runs better on the other target platforms.
- Moving into actually using IoTivity, some consideration needs to be made of the build system
- IoTivity is using a 'build' system as opposed to just generic scripting that happens to build it. The details probably warrant a few presentations just to themselves, but for now just know that setting up dependencies to integrate correctly will allow using software to have minimal problems.
- The build does cross-compilation of targets such as Android and Arduino. This allows for better developer efficiency and helps mitigate the risks of developers changing code for one platform ending up breaking it on others.
- Getting more into the pragmatic parts of IoTivity, we can focus on a quick overview of some architectural issues.
- The architecture splits things into layers of C and C++ stacks (with Java for the Android people out there). When possible, applications should be using the C++ or Java layers to be most productive.
- The spec we are following does start with CoAP, but the design intent is for applications to be shielded from the details and be able to possibly use different protocols and transports (e.g. WiFi, BLE, etc.) with minimal effort.
- Threading is something to be considered. The IoTivity library tries to minimize and encapsulate its use of threading so that applications won't be too burdened by it.
- And finally we get to the most pragmatic aspects on actual IoTivity design and coding practices
- Design-wise IoTivity is trying to be as cross-platform as possible while minimizing special-case code and/or files.
- Different platforms can affect the language you use, such as Java on Android. Then compilers, bugs in them, features missing support, etc. come into play. Even stock functions you might come to rely on may not be present or may be missing the implementation you count on.
- Arduino is a very interesting case. We use what is mainly a standard tool-chain to cross-compile for AVR or ARM based hardware, but with AVR there are complications. One area is the use of flash for keeping data to avoid consuming all your RAM. String constants used for logging was one area IoTivity made things easier.
- General C practices consist of several things. One key is to remember that IoT devices might be limited so try to keep your program size and runtime RAM use minimized. Avoiding blocks of duplicated code is one easy way to reduce size. When writing your own functions, look to how the standard library ones work including POSIX, its extensions and definitely what man pages tell us.
- To help, be explicit about which versions of languages are being used. IoTivity requires C99 for the C code and C++11 for the C++ (although the latter is a very complicated thing) Stick to the standards and code is more likely to build and run correctly on more platforms.
- Probably the biggest win for good cross-platform code is in turning on and paying attention to warnings. In the past I've fixed bugs in Windows code by correcting compilation warnings on Linux. And most importantly be sure to actually fix the underlying issues. Avoid the management temptation to just suppress warnings.
- Try to write and use reentrant functions. If there are variants, pay attention to which ones you choose. Avoid pass-by-value which ends up copying things around. Const pointers can be some of the most helpful. Use of const in the correct places can also allow the compiler to optimize your code better. And keep in mind that it is far easier to remove const later on than it is to add it.
- Another point is to use 'static' when needed. For C code this will keep things limited to the file they are in. And finally try to avoid globals. This is a subject that could easily warrant a few talks all to itself so I'll leave it with these few highlights