Yannick Chammings, CEO of French company Witekio, was explaining to me why they were changing the company name (previously they were called Adeneo Embedded), and why this was intended to show how they were changing the way in which they worked with their customers. As a part of this, he started talking about a connected climbing wall. Now climbing walls, while becoming increasingly popular, I think of as essentially dumb. You have an imitation rock face, built from a range of materials, with hand- and foot-holds screwed into a matrix of sockets. The holds can be colour-coded to indicate different routes up the wall, so a mix of different skills can use the same wall, and the routes can be reconfigured by moving the holds. (Oh – and usually the climbers are attached to a safety rope – limiting the damage should they fall off.)
With the Luxov system, the existing holds are replaced by holds that contain intelligence and that can be internally illuminated. The holds connect wirelessly to a server, which, in turn, is connected to a user interface. The owner of the wall can set up a range of routes of differing difficulty through the interface, without having to swing from a rope while unbolting and re-bolting the holds. Registered users log in through the user interface and select a route. As they climb, a bracelet records information about the user and transmits it to the server. Climbers are competitive, so they can compete against other users’ stored times – or just against themselves. The server stores its data in the cloud, so a climber visiting other Luxov walls will be able to download their information to the local server and their results will be uploaded when they are finished.
Now, is this an embedded system? Or is it a baby Internet of Things (IoT)? Or are the two the same thing?
Simplifying greatly, one might argue that the very first use of the Intel 4004 was for an embedded system (a calculator), since it was only with the 8080 that we first saw a device deployed in a recognisable computer for home use.
Hardware engineers welcomed the first MCUs as they were able to replace relays, clockwork timers, and other electro-mechanical devices with more reliable and easier-to-incorporate solid-state devices. A little bit of assembler code and things were up and running for simple control applications. And domain knowledge was paramount.
As we know, things then became more complicated. As processors became more complex and powerful, they were deployed in more demanding applications, and software evolved from a few assembler instructions to a Real Time Operating System (RTOS), along with communication stacks and other middleware, all supporting a large application program, often written in C. In addition to carrying out its functions, the system had to communicate with other systems and with humans. The user interface could be a separate system in its own right – some safety-critical systems such as medical systems, for example, could run the interface on a Windows platform – while using a secure RTOS for the safety-critical application. Domain knowledge, while important in defining the system, had become only one part of the implementation team’s tool set.
A couple of years ago, in reviewing the massive embedded world exhibition and conference, I commented that, while an embedded system used to be described in terms of hardware, the hardware had become merely a platform on which the software actually defined the system. The software has overwhelmed the hardware both in cost and in functionality.
It is tempting to say that there are almost as many definitions of the Internet of Things (IoT) as there are vendors, and the definition reflects the vendor’s product portfolio. However, there is a broad consensus that a typical set-up would start with the edge devices:, the Things – the proverbial connected toaster or the climate control modules for a house. These resemble some types of embedded system in that they will have sensors – and possibly activators, some intelligence – and they communicate with a local gateway. The edge device may just pass information to the gateway or it may process data before passing it. The gateway may carry out further processing, and, as a result, issue commands to the edge device. It will also pass data to a server and data storage, which is increasingly located in the cloud. Depending on the nature of the system, the data will be processed, analysed and presented in reports. This can involve very large quantities of data – the so-called “Big Data”.
At the moment, much of the edge-device hardware is custom or semi-custom made, as with many embedded systems. But, increasingly, platforms like Raspberry Pi and Arduino, originally intended as training tools, are used not just for prototyping, but also for volume production, to the extent that some of the microcontroller companies are producing their own platforms. Here the application is completely defined by the software.
This is where we go back to my conversation with Witekio. As Adeneo Embedded Systems, the company worked with developers who had domain knowledge, and Adeneo provided technical software expertise. However, they were finding that the real issues with the projects they were supporting were increasingly much broader, moving into the IoT arena, and, in particular, there was a need for multi-disciplinary project management and system integration skills.
They decided to build on their expertise in these areas. Rather than become a rival to the big software services companies, who typically take over the entire programme, they decided to become, in their words, “co-pilots” with the developer, providing a small number of highly skilled experts who would help the developer’s existing people to achieve their goals.
The skills they claim to bring to the party include a deep knowledge of the low-level skills, design thinking, and expertise at the system level. These are supported by a proven and well-tested project development methodology.
But it is not only companies like Witekio who are changing how they work to match the needs of companies developing systems for the IoT. The big component distributers are also evolving. A typical one is RS Components (part of the same group as the US distributer, Alliance). Founded in London nearly 80 years ago to supply spare parts to shops repairing radios and later, televisions (Yes, we used to repair electronic equipment rather than throw it away!), the company was one of the first to move into on-line ordering, and it has recently looked long and hard into how it can evolve. They have named their solution the Digital FAE. It is no longer feasible, the company argues, to have FAEs out in the field for every customer. Not only is there a limit to the number of people who can fill the role, but, additionally, those in the field cannot be expected to have knowledge of the over 500,000 products that RS now stocks.
Their community web site, DESIGNSPARK, provides a starting point for an engineer, whether from a large organisation or from the Maker community (RS is one of the two companies supplying Raspberry Pi). The home page provides links to resources for specific types of activities and applications. In addition to the usual lists of products, the user can work through their project interactively. They can access a huge amount of content that not only covers the products that RS stocks, but also includes broader discussions that provide support for people venturing into new areas.
Whatever the IoT is and whatever it will become, it is providing the stimulus for new ways of working and is opening new opportunities for creative engineers and developers.