Dirk Slama: Adi, why do gateways play such an important role in IoT projects?

Adi Reschenhofer: A gateway-based architecture is the key approach for future IoT projects. Implementing a gateway-based architecture will allow you to update key project elements such as security, edge device functionality, and protocols via the gateway itself.

Dirk Slama: What is the best way to implement custom features on the gateway?

Adi Reschenhofer: If you need a certain feature on your smartphone, you simply download an app from an app store. This is what IoT platforms will be able to offer in the near future. IoT projects currently involve custom software and hardware development, but the idea here is to commoditize as much as possible. This means that hardware will soon be available as a standard off-the-shelf product. Software features will be packaged in apps that can be purchased in the marketplace and distributed to the designated gateways.

Dirk Slama: How is security implemented?

Adi Reschenhofer: One challenging issue regarding security in IoT projects is the fact that gateways and devices (“things”) need to be authenticated without user interaction. This means that the identity of a gateway or device needs to be set up either during manufacturing or later in a commissioning process. Having gateways implemented on the edge of the network provides you with the possibility of updating security policies or exchanging entire security algorithms if necessary.

Dirk Slama: What are the other benefits of having a gateway in place?

Adi Reschenhofer: Further advantages of gateway-based architecture include resources that can be used to process or store data close to its source and avoid sending large amounts of data to the backend systems. In addition, having the possibility to adapt to future requirements simply by deploying an app is a huge benefit that accelerates time to market.

Dirk Slama: How do you select the right gateway category for your project?

Adi Reschenhofer: Finding the right fit is the key challenge. The proper sizing of the gateway is determined by the use case. Computer and Internet connectivity are cost and energy consumption drivers. Putting effort into estimating the compute and connectivity needs is the key to implementing a sustainable solution.

Dirk Slama: How do you decide between a custom gateway and an off-the-shelf gateway?

Adi Reschenhofer: The make-or-buy decision is based on the availability of a standard product for a specific requirement. In cases where a standard gateway can offer you the features required for your IoT project, it is valid to use it. This will help save time, which is what is needed to design, develop, test, certify, and produce a custom device. In some cases, minor adaptations to existing products – such as adding hardware modules via serial, USB, Ethernet, or other ports – can also deliver the required solution.

In certain cases, non-technical factors can influence the decision-making process. If the gateway is needed for a consumer solution, brand design is very important and will most probably result in the development of custom enclosures. If you are retrofitting gateways in existing machines, a redesign might be necessary as well.

Dirk Slama: What are the key aspects to watch out for in terms of manageability?

Adi Reschenhofer: You basically have to ensure that your solution supports the complete solution lifecycle, i.e. Plan/Build/Run. In all phases, the management system must provide full visibility and control. It is also important to monitor a gateway’s vital parameters like CPU utilization, memory, and storage usage to ensure faultless operation. The management platform is also used to distribute the firmware and specific apps.

Dirk Slama: Roman, from a gateway perspective, what are the key challenges involved in an M2M/IoT project with complex and widely deployed assets?

Roman Wambacher: The first thing that comes to mind is heterogeneity. Many of our customers have deployed tens of thousands of assets in the field over several years, if not decades. Numerous projects that we get involved in have to retrofit gateways to existing product lines. Very often, there are multiple generations of complex asset classes or product types, each with different product variants, which have all been rolled out globally. This means that interfaces to the different devices on these products are also highly heterogeneous. We often have to deal with a multitude of interfaces, and backward compatibility is critical, even for new solutions. Many customers start solutions by focusing on the assets that are already in the field. This way, they can access a large base of connected assets very quickly.

Dirk Slama: So how do you deal with this heterogeneity?

Roman Wambacher: Well, one thing we recommend is that our customers establish a dedicated interface management system for their product portfolio. This system must address hardware and software interfaces, both on the protocol level as well as on the functional level. It also has to take versioning, product variants, and backward compatibility into account. A closely related issue concerns product variant management. Only by addressing this centrally can you manage global M2M and IoT solutions on a large scale. For example, you need a central mechanism that controls how you deal with different configurations for specific products. If you don’t manage this properly – ideally in an automated manner – it will hit you hard on the cost side later.

Dirk Slama: What about data availability?

Roman Wambacher: Yes, that is an important issue as well – as is data quality. Most products that were designed and deployed in a pre-IoT world simply didn’t have to pay much attention to these issues. The products live an isolated life in the field. Take battery fill level as an example. In all likelihood, a non-connected product will not have put a lot of effort into providing a high-quality interface to this function. In the IoT world, the situation is very different. Interfaces to things like fuel consumption or operating hours suddenly become very important. In many projects, the people on the solution side are astonished that such basic asset functions are not available at all, or not in the required quality. There is a good chance that an embedded software developer will not have given much thought to the fact that in a connected world, it could be a problem if an asset temporarily sets the operating hours to zero during start-up. In the IoT world, this is exposed immediately.

Alternatively, take something like product identification. Very few existing product lines will actually have a consistent way of uniquely identifying assets in the field through automated interfaces or an electronic identification plate. So you will probably have to get creative and move this problem to the solution level, for example by using a pairing approach based on QR codes or something similar.

Dirk Slama: How do you deal with this kind of situation?

Roman Wambacher: You have to address this systematically, product type by product type, and version by version. All data from the products has to be validated per product type and version. You will be surprised by the many different meanings of basic things like “product health” that different product versions might have. Integration tests are extremely important – you can’t start early enough. And, of course, you have to perform field tests. Finally, your project plan has to provide for the unexpected. Don’t underestimate the complexity of fixing interface problems in such an environment, especially if they require changes on the asset side.

Dirk Slama: And how do you select a gateway?

Roman Wambacher: Well, using an off-the-shelf gateway always sounds attractive, because of the cost of custom gateway development. In many cases, however, it will be hard to avoid. Generic gateways are often too feature-rich and hence too expensive. Or else they lack certain critical interfaces you need in your project. In our experience, if you need 10,000 or more gateways, there is a good chance that you will end up opting for a custom solution.

Dirk Slama: What do you have to take into consideration for global rollouts?

Roman Wambacher: Well, ideally you want a single type of gateway for all countries to reduce complexity and TCO. However, in many cases this will not be possible, for several reasons. Most notably, there are country-specific technical requirements – different frequencies used for LTE, for example, or CDMA versus GSM. Modems that support multiple options do exist, but this will add to the cost side. You should not underestimate the extra costs you will incur by supporting multiple gateway types. Just think of the government approval processes you will have to go through for each gateway type – and each new version!

Dirk Slama: What other cost drivers are involved in this type of project?

Roman Wambacher: Many people think that the main cost driver is communication costs for mobile data exchange. However, this is usually not the problem, at least in our experience. The bigger problem comes from manual and inefficient management processes for gateways and related issues, such as SIM card activation/deactivation or asset configuration. Asset configuration in particular is something that could be automated, but this would add to the development cost – even though from a TCO point of view it would make a lot of sense.

Another cost driver is feature creep. For many assets, the lifecycle of the gateway will be much shorter than that of the asset itself. So it should be OK to just focus on a minimum set of features for the gateway and trust that a next-generation gateway will be developed sometime in the future.

Finally, many companies don’t plan for additional development budgets after the initial release. However, in our experience, most M2M/IoT projects are never-ending stories. And this should be seen as a positive thing. If a project is successful, there will be a constant demand for new, value-adding features.