How the Internet of Things will affect consulting engineers

Echelon’s Varun Nagaraj answers one-on-one questions, explaining how the Internet of Things can and should be used by engineers.

Amara Rozgus, Consulting-Specifying Engineer

01/02/2014

Share

Consulting-Specifying Engineer (CSE) asked Varun Nagaraj, senior vice president and general manager, Internet of Things at Echelon Corp., for some insights on how the Internet of Things (IoT) will be viewed by consulting engineers

Nagaraj has more than 20 years of high-tech product planning and strategy experience. He holds a BSEE from IIT Bombay, a master’s in computer engineering from North Carolina State University, and an MBA from Boston University.

CSE: How will the Internet of Things directly affect consulting engineers?

Nagaraj: The IoT takes advantage of Internet protocol (IP) as a kind of unifying force, creating bridges among previously parallel or incompatible protocols. As a result, the IoT will both simplify and expand the role of consulting engineers, allowing them to concentrate on higher-level considerations of an application, rather than being restricted to a single set of protocols for any given project.

CSE: How will the IoT directly affect the products and systems that consulting engineers specify?

Nagaraj: When IP is driven to the device level, consulting engineers will be able to focus on specifying products based on their functionality rather than worrying about protocols and communication transport compatibility issues. And because developers can create single products/systems that work with multiple protocols, consulting engineers will have available a wider range of product/system options available to specify for each project they work on.

CSE: Which of the following —lighting, fire/life safety, HVAC, or electrical/power products —do you see moving most quickly into the IoT?

Nagaraj: I would expect lighting to move most quickly into the IoT space, followed by HVAC and fire/life safety.

CSE: Why?

Nagaraj: Economics and emerging regulations will drive widespread adoption of LED lights with controls in commercial buildings and in public spaces. It will be important for the consulting engineer to specify systems that can grow, are not vendor-dependent, and can serve as a platform for other control applications. The use of IP at every level in a lighting system will facilitate these objectives.

CSE: What’s the projected growth for products in this fastest-growth area?

Nagaraj: Forecasts can vary widely. For example, IHS, a well-known research firm is forecasting that nearly 50% of the 1B “industrial or commercial” IoT devices installed in 2017 could be lights.

CSE: With regard to building automation systems (BAS) and building management systems (BMS), what future trends do you see?

Nagaraj: I see three trends:

1. A multi-protocol future based on the IP protocol as the unifying layer—not just at the management layer where it is used today, but also at the device of fieldbus level. This will hopefully result in the ending of the counterproductive LonWorks versus BACnet discussion that is so ingrained in our specification world view today. The right answer should be either LonWorks or BACnet—but over IP!

2. The use of big data collection and analysis techniques to identify opportunities for system optimization.

3. A continued use of wired communications even as there is an increasing use of wireless options.

The primary issues of cost and efficiency in systems, since 1980's has been incompatible protocols, data and address schemes, and definitions of objects. These need to be resolved so that 'users' and facility managers can really take advantage of the technologies.

Tony , Non-US/Not Applicable, Saudi Arabia, 01/18/14 01:08 AM:

I agree with Anonymous but would go further.
Most of the multitude of incompatible protocols now in use for BAS/BMS purposes carry the same information:From address, To address, Type of data/command and Value. It makes no sense whatever to perpetuate this situation down to the device level, even if all protocols run over IP, for two reasons.
Firstly, either a "universal" device must incorporate hardware and software to recognize multiple protocols and do the necessary translation, or a single protocol device must have as many variants as there are protocols that the manufacturer wishes to comply with. The former can reduce inventory but is more expensive and slower than the latter. In both cases, however, this makes the device considerably more expensive than if there was only one protocol in use; and in both cases the device must also incorporate software to wrap/unwrap the protocol addressing and data formats into and from the standard IP packet "envelope".
Secondly, all this wrapping/unwrapping and translation of protocols takes valuable time and therefore has a serious impact on the information-carrying capacity and response time of the system.
The logical solution - which will, no doubt, be fought tooth-and-nail by the various organizations and commercial interests behind the present proliferation of protocols - is to have ONE COMMON, OPEN PROTOCOL which uses IP addresses directly, has standardized data ID and value formats and, most importantly, fits exactly into an IP packet, so that no wrapping and unwrapping is necessary.
At my age, I would like to see it before I check out - but I'm not holding my breath!