Best Practice

Lessons Learned: Software Development in The Era of IOT

Ensuring Software Quality

The Internet of Things has long been a reality. 27 billion devices were connected via the IoT in 2017. This number will likely swell to 125 billion by 2030. By 2022, business related to IoT products is expected to comprise a market worth 561 billion US dollars. This trend towards increasingly networked products entails a few changes for software development. When comparing IoT software development with traditional development scenarios, it becomes clear that developers in the era of IoT face new technical and methodological challenges which are hard to detect at first glance. First of all, ensuring the quality of the software can quickly become a challenge. Incorrect architecture decisions lead to security risks and software that is hard to maintain. This results in high costs and reduced competitiveness.

Future-Proof Software

But despite all the obstacles and challenges, IoT projects are the solution for viable software development and will soon be unavoidable. Concept Reply has already demonstrated its expertise in numerous IoT projects. In the process, it has gained a series of important insights that can help overcome these challenges.

Lessons Learned

Lesson 1: The First Step is Security Planning

An IoT environment is extremely complex, because many components intercommunicate and exchange data within it. In the short term, security holes can often only be resolved on the gateway side or by rectifying the weak point directly. At the same time, there are special requirements on the device side (for example, special micro-controllers or limited memory), which means fixes are not readily available. An update option for devices must be planned from day one using over-the-air update functionality. But in the event of a breach, it is also helpful to have a software architecture that is already designed to block or limit access to gateways or the app server.

Lesson 2: Device Simulators as The Tool of Your Choice

In addition to the front end on the client and the back end on the server, the edge software is implemented on the IoT gateway, which is responsible for the Internet connection and simple data processing as well as the ‘thing software’ on the actual device, such as a sensor. The increased complexity necessitates more testing work. Because the actual devices are usually not yet available in early stages of a project, device simulators are an indispensable tool. They help with automated testing in the cloud, among other things, but they also simplify load testing. Devices that are already available can of course be integrated into the test automation, but this makes testing in the cloud more difficult; after all, the devices are usually located behind a firewall in the company network. For this reason, it is necessary to create a complex test infrastructure that differs from traditional test infrastructures.

Lesson 3: Nothing Without Over-The-Air Update Functionality

As the number of devices and equipment in an IoT scenario increases, it is hardly possible any longer to maintain an overview of the situation and install such updates manually. The deployed devices can often only be kept up to date via over-the-air updates (OTA updates). This has to be factored in from the beginning – also with regard to the overall application lifecycle. Devices that have security holes but no update mechanism must be discarded. Another advantage: An update mechanism enables new business models. Whereas at the start of a project a customer often has no idea what functions his development process will need to implement in future, an integrated update mechanism allows software functions that do not yet exist to be distributed at a later date.

Lesson 4: Logging From The Device All The Way To Cloud

In the event of a failure, a root cause search for a large number of devices and possibly intermediate gateways is much more complex than in a classic software environment. Therefore logs have to be made available centrally, partly because under certain circumstances there may be space limitations on the device side. A central log database (or rather syslog-ng) is a possible solution to the problem of high device numbers. Battery operation is another problem, that can be solved by having the device send status information to the cloud every time it goes online.

Lesson 5: IoT Requires Agile Methods

The much-discussed ‘customer experience’ is not only a decisive criterion for success in the front end, i.e. in apps and websites; it also plays a role in devices in the form of user-friendliness. For many customers, user-friendliness often plays no role at first, which is a mistake, because it is important for the long-term success of the solutions. During the development stage, the developer should, for example, already consider how the setup process for an IoT gateway should look. Because IoT projects are often innovation projects, one of the customer’s top priorities is often to achieve a business impact with them, for example, by reducing maintenance costs or marketing software functions in general. Because the hoped-for business impact is difficult to assess, especially in the early stages, it is important to rely on an agile approach. This allows the business case to be developed in parallel. The only remaining challenge then is to stay focused and not get lost in unnecessary features.

Lesson 6: Cloud Native Improves Time-To-Market

Cloud native IoT hubs come with the required functionality already integrated out-of-the-box as standard and can therefore be set up with little effort. They are also relatively easy to upscale if a large number of devices is needed. SDKs, which are offered for many software versions, also help accelerate software development. The alternative to cloud native IoT hubs are IoT hubs developed in-house (based on Kubernetes, open source products and individual software). Proprietary IoT hubs can be designed in such a way that they can run in different cloud environments. This makes the customer independent of cloud providers.

Lesson 7: Embedded Components Should Not Be Developed In Isolation

Conflicts arise here among issues such as energy efficiency, availability and performance. An example: A device that has to cover an extensive range also needs a lot of transmission power, which can only be maintained temporarily due to high power consumption. However, the dimensions of a hardware component are determined based on specific requirements that offer little room for the requisite flexibility if all of the aforementioned criteria are to be met (energy efficiency, availability and performance). It is therefore important to plan in advance. The most important questions here are: Can requirements be implemented in the future as well with the planned hardware, and how much flexibility is required for this?

MORE INFORMATION

Read the full white-paper for a detailed comparison of traditional and IoT software development scenarios, including best-practice examples.

With a competent development partner like Concept Reply by your side, you can approach your IoT projects in a structured manner and implement them optimally: software quality is enhanced, iterations are avoided, (further) development costs are reduced, customer satisfaction is increased, and maintenance costs are lowered.

Download Whitepaper

Concept Reply

Concept Reply is an IoT software developer specializing in the research, development and validation of innovative solutions and supports its customers in the automotive, manufacturing, smart infrastructure and other industries in all matters relating to the Internet of Things (IoT) and cloud computing. The goal is to offer end-to-end solutions along the entire value chain: from the definition of an IoT strategy, through testing and quality assurance, to the implementation of a concrete solution.