Programmers ramp for Internet enabled control for embedded devices

Programmers ramp for Internet enabled control for embedded devices
As the connectivity of the Internet moves into embedded control, developers and programmers are finding that their coding chores are more complicated, not only during development, but during debugging and testing, and even after deployment in the field. Complicating their efforts further are additional factors that need to be considered during design.

Most are related to the fact that the controller device — no matter how deeply embedded — is connected to the broader Internet through one of the previously existing proprietary control network protocols that now act as an on-ramp to the broader network. And, on top of that are the various device management frameworks that have emerged. The engineers and programmers who contribute to this week's In Focus detail the latest programming schemes and connectivity techniques for this complex networking environment.

This connectivity is used in several ways. It is used by developers as a way of updating the programming in the device and to correct programming and design errors not caught in development during the prototype stage, or during early deployment in the field by OEMs. Also, it allows programmers to have the best of both worlds: an embedded design that is not only lean and mean, but future rich as well. The first is achieved by incorporating only what is essential to the barebones operation of the devices. The second is achieved by using the network to access additional resources, on a server, a companion device or an embedded gateway device.

And, device connectivity allows programmers to think new ways about embedded applications. Instead of one device, programmers can start thinking in terms of confederations of devices taking advantage of the peer - to- peer capabilities built into the Internet's TCP/IP and UDP protocols. Such mechanisms such as the Sun inspired Jini approach, the Microsoft-inspired Universal Plug and Play, as well as a number of newer approaches will, according to Alan Lattanner, CEO, Blue Iguana Networks, Inc. (Sunnyvale, Calif.), allow devices to cooperate with varying degrees of connectivity: device to device, device to intermediary embedded gateway or device to server.

From the point of view of the OEM, the total cost of the system including support, repair, upgrading, and maintenance drops. Contributor, Michel Burger, CEO at Embrace Networks, Inc. (Sunnyvale, Calif.), noted that "while the component cost of such Internet-enabled controllers is higher at the initial stages, the additional lifetime costs are eliminated." Instead of maintaining an extensive staff of trouble shooters and field engineers to deploy to determine problems, do repair and upgrades, the new connectivity options allow all of this to be done remotely." Burger discusses the need for a software layer between devices and applications in his article.

According to William Peisel, CTO, NetSilicon, Inc., (Waltham, Mass.), IP connectivity makes embedded controllers truly pervasive in terms accessibility and modifiability. "Embedded smart devices, whether their main chore was control or computing have always been ubiquitious," he said. "By the beginning of the 1990s, before the Internet, the number of 4,8,16 and 32 bit embedded controllers in use world wide was in the billions, more than the population of the world, truly pervasive."What is different now, he said, is the ubiquitous TCP/IP-based connectivity and accessibility which offers developers, programmers and OEMs a much wider range of options in terms of manageability and updateability."

What embedded device developers and programmers do not realize yet, he said, is how profound the impact of TCP/IP based connectivity into devices will be on embedded design in all of its aspects, including program development. "In rather rapid order the embedded market has sped through what I perceive as three basic stages to device connectivity," said Peisel. "Some of them have gotten comfortable at the earlier stages with the enormous advantages that connectivity, and the enormous challenges, and now they must move to the next stage."

Value-added stage

According to Peisel, during the first stage — basic connectivity — OEMs have been equipping printers, motor controls, security cameras and the like with essential networking functionality, such as Ethernet 10/100 and basic Internet access. Examining their current competitive landscapes, many electronics OEMs attempt to do this quickly and with as little complexity as possible. He noted that the embedded industry has left this stage and moved on and are now well into Phase 2, the value-added stage, where they are coupling the intelligence of a networked microprocessor with networking services, to perform data collection and distribution from collaborating devices to enhance the functionality of their products.

He forecasted that the most profound changes will come at the transition to Phase 3: enterprise-generated device connectivity. While there are few such devices existing or in design, many companies are considering designs where networked devices become fully participatory and autonomous members of the business operation. "Programmers and developers in these latter stages of device connectivity are being pushed to think more creatively about design in a connected environment," said Piesel, "this means remembering that the device alone is not the platform, but the device and the surrounding network environment."

The process of transition is not going to be an easy one for the programmer and developer, said contributor, David Fotland, chief technology officer at Ubicom, Inc. (Mountain View, Calif.), because they are faced with a multiplicity of chores beyond just figuring out how to integrate a network. "Greater attention will have to be paid to reliability, not just of the device, but the entire system which includes the device software, the connectivity protocols, the middleware and even how servers and embedded gateways and portals support the devices," he said. "This means taking a look at how to improve and adapt the current generation of tools but an array of new tools and frameworks and network environments as well."

In addition to first generation device networking environments such as Jini and UPnP, a number of newer and more specific connected device application development environments and device management frameworks are emerging to make device coding and software modification is less burdensome. While the underlying mechanisms by which these important middleware jobs are done have some similarities, the frameworks that have evolved in very different directions, reflecting the point of view of the market segment and application they are targeting.

NetSilicon, which is in the business of selling ARM-based and network enabled smart devices into industrial control and the home networking market, looks at the connectivity problems from the point of view of developers working on designs they want to be adaptable across a broad range of connectivity and networking environments. "Our developers were telling us that it took them as long to program and reprogram settings for different network environments as it took to do the actual application code writing, debugging and testing," Peisel said.

Changing variables

And, as the size of the applications has grown with the capabilities of the underlying controllers, the variable problem was getting worse. "As the application is moved from one network to another, from say an industrial control application that used CAN in conjuction with TCP/IP to one that used Devicenet in change, variables through out the application needed to be changed individually," he said. Working with the developers using their devices, said Peisel, NetSilicon's engineers developed a network oriented operating environment API that allowed developers to change such variables globally, reducing development efforts significantly.

Blue Iguana on the other hand, looks at the device networking from the point of view of supporting developers who are looking at adding the ability to reprogram both hardware and software on the fly remotely. To support its proprietary hardware/software reconfiguration tool suite, said CTO, Lattanner, the company has also developed a package of scalable server software package and a controller oriented management protocol for which it making the code base available for use by developers, or competitor.

"Our company will not grow if the market for such device networking frameworks does not thrive and attract developers," he said. "That means we need common standards for critical pieces of the framework. That won't occur if we keep it all to ourselves."

According to Embrace Network's Michel Burger, a feature often ignored in existing networked device management alternatives is a clear cut way to interface network of embedded devices to existing distributed management frameworks, such as CRM (customer-relationship management), ERP(enterprise resource planning), HL7 in health care, or RosettaNet for electronic components.

NetSilicon's Peisel believes the emergence of a new generation of connected device management frameworks represents a shift in the embedded industry from Phase 2 to Phase 3 device networking. "As we move further into this stage we will see the beginnings of a standard programming and management framework specific to device networking," he said. "Although early attempt such as Jini and UpnP address some of the specific needs of embedded developers, the fact that a number of other alternatives are emerging indicates that they are not enough."

He predicts that an industry wide specification will have to emerge. "Exactly what form such a net-centric device oriented development environment will take — the extension of an existing current general or proprietary standard, a ground up detailed spec, or an agreement on just a common set of procedures, constructs and grammar," he said. "But I do know that the additional programming and development load that connectivity imposes on designers will require it."