How Connected Products merge into the Internet of Things…

12 June 2014
| |
Reading time: 8 minutes

…and why Architecture is Key

Over the last years many customers addressed Zühlke with a set of similar problems in the realm of Connected products and Internet of Things (IoT). These customers usually are product manufacturers and market leaders that now need to be connected to the digital world in order to expand their range of features in a world dominated by disruptive innovations.

Some vendors want to enable their end users to use mobile devices as a remote control or detached display. Others want to offer smart remote services. Their goal is to increase the customer experience in service scenarios, reduce downtime of a machine and reduce their own service costs. Others want to extend their business and develop themselves from a pure machine vendor towards a company with a full-fledged 360 degree service offering around their product families.

We saw many, many different scenarios in various industries, ranging from medical products over home automation, smart metering applications to smart remote service or decentralized power generation systems.

While these areas sound very diverse, the non-functional requirements of these systems are very alike in most cases.

We always see a high demand for security and scalability, as well as a growing interest in diverse data analytics. But these are just the basics. Add multi-tenancy, a high degree of serviceability and a strong demand for robust and high-available back-end services.

With the growing hype around the Internet of Things (IoT) and the rise of a wide spectrum of platforms in that area, we now want to share some of our thoughts and experiences in that domain.

The role of the Local IP Gateway

The products we are asked to connect usually already have some sensors and actuators to measure their environment or their usage. The actuators might be used to configure the product in its environment.

Many of these products don’t exist in isolation, but are connected in their own little local area network (think of product LAN or home LAN) with some kind of custom, mostly industry-specific, yet very specialized wired field bus (maybe Modbus, CAN, LON, KNX,…) or wireless technology (think ZigBee, ZWave, EnOcean, DECT ULE or many, many others, which hardly interoperate among each other).

There is usually some kind of Local IP Gateway, which is considered to translate some of the local communication into the IP world. Examples for these Local IP Gateways might be a Smart Home Central Unit, an on-board unit in a vehicle or a Smart Metering Gateway.

The problem: You usually install a specific Local IP Gateway for each type of connected product. Many of those gateways are specialized for some field bus or wireless communication.

It gets very interesting if the end customer wants to mix and match. The demand for interoperability and standardization is growing extremely. Certain industries already reacted to that problem and defined national or international standards for these gateways (example: Smart Metering Gateways).

A relatively new trend to connect battery driven end-devices is to use SmartPhones or tablets as Local IP Gateway and communicate via Bluetooth Low Energy for the “last meter”.

Drivers for Connection

Main driver for these gateways is usually to enable some form of data collection (for analysis or maybe also for billing).

Then there is the need for local or remote service access. You need some sort of endpoint to “dial into” the product and conduct your serevice task. But how do you do that in a secure fashion? You usually need some local intelligence to handle security aspects.

The privacy aspect also has to be considered. “Who owns which data?” will be a question that needs to be answered and supported by solution architectures (see current Connected Car discussions on that topic).

Another aspect to consider is the connectivity cost: Many products reuse some kind of locally available internet connectivity to get “online”. They use a local WLAN, or a DSL-box or a central spot which uses GSM to get connected (think Smart Home scenarios, Smart Building, Smart Plant, Smart car, sometimes even SmartPhones are used as gateways & routers).

Interestingly we saw very few scenarios without a gateway. It is still very hard to create a valid business case if you need a dedicated mobile connection just for “your product”.

One more reason to use a gateway is the missing capability of small battery powered sensors to keep an online connection via established IP protocols.

Especially when you add security aspects like SSL to the equation. Low power devices rather utilize low energy communication standards and periodical transmission patterns to reach out to a gateway that is responsible for IP communication to the outside world.

With this basic pattern a large amount of distributed small and cheap sensors can be spread out in a location (e.g. building, production facility, …) with only very few central gateways that collect, distribute, process and propagate data to IP connected peers like the cloud, mobile devices or other gateways.

The next dangerous security hole

Many customers also see the opportunity or necessity to use that local IP Gateway as a web server. End users access the local system via WLAN to communicate to the attached device or product.

The next step is simple: They use DynDNS and open a well-known port to create a connection for their service technicians. They use tools like TeamViewer and log-in as an administrator to see how their system is doing.

Consequence: The next dangerous security hole is born.

If you do this, you use mechanisms which were developed for a trusted environment like your enterprise network. The little difference: You don’t control the endpoint physically. This is no laptop used by a trusted employee.

Your product or device literally runs “out in the wild”. You usually don’t control physical access to it, you usually don’t know the end user and it is accessible 24/7.

Great opportunities to attack the device and your network the next time your service technician dials in…

Typical target architecture1-02

Zühlke often gets called in exactly that moment. The problem usually looks simple: The customer wants some kind of a “service app”, or an “end user app”. Sometimes our customers are motivated by Big Data: they want to analyze differences in product usage across different end users in order to build better products.

They usually don’t want their IT to get involved into that project too deeply, because their IT knows mainly about “Enterprise IT” – managing laptops that are used by trusted employees (and why they think VPN gateways are a valid way to secure the solution).

The customers’ IT usually doesn’t know much about “Product IT” with its very different requirements.

The role of the cloud

How do we respond? We usually draw a target architecture that somehow looks like the picture below. In many of these scenarios the cloud is central. Why? Well – the customers usually don’t want to invest too much into servers. The solution and its cost must scale accordingly to the success of the product.

Our customers navigate into a new market – away from product sales – into service sales.

They usually are not very sure regarding the business case before the product launch. So a very flexible backend with flexible cost (“pay as you scale”) is key for those projects.

Typical target architecture1-01

We see another important reason why the cloud backend is so important: We can shift security aspects from the local network and its limited embedded HW into the cloud.

We don’t want to open up the end users’ router to give external access to the Local IP Gateway. The gateway shouldn’t play the role of a server.

No matter how excellent we engineer that gateway – it will always be vulnerable to denial of service attacks because it runs on limited resources. It should rather behave as a client and leverage server tasks and server responsibilities into the cloud.

And that’s why the connection between the gateway and the cloud is key in an Internet of Things Architecture.

Our role within the Internet of Things

We are providing solutions for our customers in any of the above described scenarios – and we do this in an end-to-end fashion: We build sensors, gateways, cloud services, portals, mobile apps, data analytics and their visualizations.

And we feel that this is our strength: to know any aspect of this broad solution domain.

Is the Internet of Things challenging you, too? And if so, in what way? Let me know – it surely will be inspiring to exchange our knowledge and thoughts on this subject.

Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »