Since the early 1990s embedded systems developers have had an uneasy but productive relationship with the constantly increasing connectivity made possible by the Internet and World Wide Web.
Before 1990, common electronic communications protocols and physical connections — either wired or wireless — did not exist to the degree they do now. The Internet then was an “Internetwork” of diverse proprietary and special-purpose networks, in which Ethernet’s TCP/IP was at best a “lingua Franca” many used to communicate between one and another. So, many “embedded” designs were exactly that — literally embedded and hidden from the outside world, not connected. They were isolated from outside intrusion within some sort of protective local area network using a protocol that was either proprietary or industry- and application-specific.
Then the move toward ubiquitous connectivity began happening in the early 1990s, shortly after the IPv4 suite of Internet Protocols was formalized. It happened again in the early 2000s with the creation of the next-generation IPv6 and 6LoWPAN protocols, and as the shift from wired to wireless connectivity began and accelerated. With each increase in speed, each change in protocols, each change in physical connectivity, the embedded-systems industry has had to (1) look at their software tools, such as languages, compilers, debuggers, and processor building blocks, and see how they had to be changed or modified to deal with the changes and (2) find ways to take advantage of that connectivity in its designs.
Now, the unique URLs available in IPv4 — and the many subdomain tricks used to make it look like there were more — have finally run out. There were only 4 billion or so (1032 , to be precise) to begin with, and major Internet service providers have been forced to move to IPv6, with 7.9×1028 times as many URLs as IPv4.
Now with an Internet that has virtually unlimited numbers of URLs — most of them capable of being accessed wirelessly — that means that not only every person, but every previously embedded “thing” can theoretically be connected directly to the Internet. With the possibility of a pervasive “Internet of Things” (IoT) — with a few humans thrown in here and there — embedded-systems developers have been forced again to reassess the challenges they face and the tools and building blocks they use to build systems that will be virtually naked to the outside world.
A common language
The good news for embedded-systems developers is that in this new connected environment, the languages they depend on — C and C++ primarily — will be the same as those used in most IoT designs. But both have gone through revisions (such as C in 2011) that have new capabilities for code-checking, tracking, and debugging that will make it possible to write better code faster and with fewer errors. This is all important in an era when systems with faulty software will be used by millions or even billions of users, rather than the thousands and hundreds of thousands in earlier eras of embedded-systems design.
Where the uncertainty of development in this environment will occur — because of the industry coalitions that have been formed — is in the middleware approach taken. There are essentially two approaches.
To read more of this external content, go to “IoT: Bottom-up approach.”
Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. If you want to see a calendar of topics for upcoming weekly Tech Focus newsletters or have a topic you would like to see covered on Embedded.com, he welcomes your feedback. Send an email to , or call 928-525-9087.