We have used Embedded Linux as the Operating System on a number of development projects. Digi provide a version of Linux which they call 'Embedded Linux' and this we have used on their range of ConnectCore modules. These are attractive modules, as they provide significant processing power, but a simplified design process for us. We only need to provide a base board which maps the ports we want to support, along with any other additional electronic hardware. The module we use also provides Wifi, the ConnectCore 9P 9215.

In addition, we have used Linux on diverse computer devices such as the Owasys OWA311, the Garz+Friske Livius ARM-based system and our own design of processor board to which we have ported Linux.

Linux provides a complex operating system, with a complete filing system, TCP/IP for computer interconnection, a GUI if necessary (although we have rarely used this, we just use the kernel) and a whole host of commands to cover a great deal of functionality. Linux is open-source and is available on a host of computers, running on a multitude of processors. It is extremely flexible and can be tailored for virtually any task. We add to the system by writing our own applications and functions and occasionally, device drivers.

Wireless technology is essential for the kind of work we do. It might be Wifi, for TCP/IP networking. It might be Bluetooth for small autonomous networks. It might be one of the many other IEEE 802.15 systems, such as Zigbee.

We have worked with Wifi on various M2M projects, particularly the vending machine projects. Our machines are often in areas where public Wifi is available, such as airports and railway stations, so it makes sense to use these services. However, we have found practical difficulties in doing so, not least the fact that the services get swamped at rush hour. Our approach was to react to the fact that we lost connection reliably at certain parts of the day, but had good service at other parts of the day.

We have a particular interest here in mesh networks, the ability of a network to create itself, and to heal. This has great impact on battery life. The Live!Label project used standard Wifi networking when we trialled the system and this proved to be a limitation. We had the labels at different positions around a museum and we found that the Wifi signal was too weak, due to the internal walls. Also, the power consumption on the board was high due to the Wifi module, so we couldn't run on batteries as we had hoped.

We repeated the experiment at a later date, but revised the design to use Zigbee. We created a mesh network such that each label in the system was a node on the network. This had the affect of building a network room by room and greatly extending the range of the network. It also meant that the system consumed much less electrical power. Zigbee is low power anyway, but the devices only needed to communicate with the nearest nodes and thus worked at a lower RF power.

It's trendy, the Internet of Things (or sometimes the Internet of Everything). But it's a bit like when you heard of the iPod and thought "but that's just an MP3 player". Or when you heard of the "Cloud" and you thought "but that's just servers". The Internet of Things is clever branding, designed to stimulate interest, but really it's what we've been doing for years. Smart boxes, talking over the Internet to a server. The IoT is subtly different, it's better and friendlier. But then, so is the iPod, compared to an MP3 player.

Clearly, there is more to the Internet of Things. The hype is significant mostly due to the volume of noise. And the potential, because we're talking about billions of devices. The IoT is happening because of the fall in costs of small smart computer systems, of sensors and wireless systems. One of the best examples of the IoT is Nest, with intelligent smoke alarm and their central heating control system. But, there is a difference when you look at Nest devices. They are smart. They react to you. You can wave at the smoke alarm to tell it that actually there isn't a problem. It lights up a night light if it senses movement.

But the Internet of Things is more than this. It's a simplification, if you like. The aim is to simplify the ability of a device or a sensor to connect to to the Internet and to send some data. The range of possible sensors and devices is unlimited, the purposes are unlimited. Some people claim that this is a similar stage in history as the start of the Industrial Revolution, that we're about to witness a similar revolution. Who knows. It's just fascinating.

The examples of IoT tend to start with the 'intelligent fridge' - your fridge contacts the local supermarket because you've run out of milk. It is much bigger than this, much bigger. The main difficulty with this example is that the responsibility is on the fridge manufacturer to add the sensor and the communication link. Much better is to have a system that allows you to add any sensor to any existing system, a sensor that is capable of communication and then link that sensor to a decision making system. That way, there's no difference between a system monitoring milk availability to the system controlling temperature in a house - it is all about simple, communicating sensors feeding into a decision making system.

Human interaction describes the relationship between people and computers. When designing machines to be used directly by people, either adults or children, the focus has to be on the interface to the machine. Production of these Human Interaction Devices also incorporates control of hardware including buttons and the motors which drive the product. Xor Systems has worked on a number of human interaction devices, including vending machines and interactive museum displays.

An interesting challenge with these devices is designing them to be simple to use. Museum displays can be used by children or the elderly, so cannot be too complicated to navigate. The same is true of vending machines. As vending machines have been around for a long time, most people already know how to use one. This means that deviating from this standard way of using a device is not a good idea for keeping things simple, and instead new features (like new payment systems) need to be integrated in clever ways. Xor systems has worked on a number of more complicated vending machines, including machines with 48” displays which can show advertisements

It is quite common for these machines to be remote or stand-alone systems which still have to report back their status in real time, or update the device with new information. Think a vending machine in an airport or an information display next to a monument in a field. The advert on the vending machine may need to be updated, or new text needs to be sent to the information display, or you need to know if the display is working without having to walk to the field it’s in. These devices need to be connected and we have overcome these connectivity problems by adding a 3G routers to machines, which creates a mini network and allows a number of devices to connect to the Internet over the mobile phone network.

Embedded systems have two crucial functions and this is one of them - the ability to control. It may be as simple as turning an LED on and off (and on any board we design, that's the first thing we get working). And it may be complex, such as driving the actuator that moves the aileron that turns the aircraft, or the motor than spins the steering wheel on a car when it is auto-parking. What it signifies is that the embedded system has made a decision and it is doing something to the system outside of the board for which it is responsible. Usually, when we describe the object we're controlling, we use engineering terms. It is an actuator, it is a relay, it is a motor, it is a light.

The device we are controlling will normally be bigger and more powerful than our electronics. We're using hydraulics or compressed air or electricity, starting and stopping it at the behest of our software. And all of it is done to some algorithm. Embedded systems can reliably and repeatedly implement some algorithm and at some speed. A simple example is ABS. The process involved in braking is easy to understand - brake hard enough to be just at, but not beyond, the point of skidding. That has to be the maximum efficiency of braking. If the tyre starts to slide, reduce the pressure to the brakes until the tyre starts to turn but hold it just there. The road conditions change continously and the system needs to sense this and change accordingly. A simple sensor monitors the tyre and knows when it is turning; a hydralic valve controls the amount of brake pressure being applied. Any human is able to understand and implement the algorithm, but only a computer can do it fast enough to make it work well.

An important factor on control is feedback. How far do we move the actuator? How long do we run the motor? if you consider a lift door, we start a motor to open the door. This will drive a screw to wind the door open. How do we know when the door is fully open? Well, usually there's a microswitch and that signals to the system that the end stop has been reached. The same applies to the actuator. Maybe we simply use time. We know how far the device we're controlling can move in a fixed time, so we can time it. But it is more reliable to provide positional feedback.

This is the second crucial function of an embedded system - the ability to measure. We've discussed, in Control, about sensing digital inputs, so we know about end of travel and suchlike. That could be considered as measurement. But there are two approaches we use on embedded systems - direct measurement through analogue to digital converters and indirect measurement, by talking to sensors that directly measure the parameter. in this case, we query the sensor for a reading.

Consider the first - direct measurement. There's a skill in this, selecting the right device, scaling the input, selecting the number of bits and rate of reading. It can be complex. The sampling rate is subject to Nyquist's sampling criterion - the sample rate is at least twice the maximum component frequency of the function being sampled. You don't want to undersample a complex signal.

Once you have digital values, then it is possible to apply algorithms, such as filtering, averaging and so on.

Indirect measurement is increasingly common. Sometimes the whole device, mounted on a circuit board, does all the measurement required within the chip itself. All that is required is to talk to the device over I²C or SPI or similar to obtain data. Also, we talk to devices over more robust and long-serving interfaces, such as RS485 or RS232. These are reliable, well-understood and widely used in measurement systems.

Traditionally for environmental monitoring, like Dust or Weather, the sensors are located remotely and data produced by these measurement systems are stored physically on the device or on a memory card. In advanced systems, the data is recorded on computers housed in the site office or in a specially adapted container. The sites where the sensors are located are then periodically visited by engineers to collect the data for analysis. There are a number of problems with this approach, including the lack of real-time data and not knowing about faults in equipment until after data is collected or after a technician has visited. It could be days or weeks before a fault is discovered.

Xor Systems has brought the technology up to date by connecting devices to the internet and broadcasting the data remotely to the Cloud, and in real-time. Data can be viewed on a secure website that Xor Systems developed, where users can log in and access data from their devices. Faults can be found quickly as the website is able to report whether the measuring device is online and still measuring. Additionally devices can be rebooted or new software be pushed to the device, all remotely. Data is secure because it is stored on to Cloud servers.

This is achieved by connecting a small computer system to the measuring device via RS232 or perhaps RS-485. The computer system is also connected to a 3G or 4G router to allow connectivity to the internet. A C++ program was developed which runs on the computer system which allows data to be collected from the measuring system and push it to cloud-based storage. The program copes with loss of signal by saving data until connection is restored.

We took this approach with dust measurement. Devices such as the ES-642 Particulate Monitor can be addressed over a multidrop RS-485 network, allowing a number of instruments to be queried. Each instrument has a different size filter attached allowing through a chosen particulate size. The two of main interest to humans is PM10 and PM2.5. The figures refer to the size of the particles in microns (μm). PM2.5 particles are of real concern because they can penetrate further into the lungs and lodge there permanently, with an increased risk of cancers and respiratory diseases. We're interested in wind-borne dust here, on quarries or construction sites. Having access to the real-time values of dust levels can prevent unnecessary exposure.

In addition to measuring dust, it is also beneficial to measure weather as well. Spikes in dust levels can be explained by an increase in wind. Conversely, drops in dust levels may be due to increased precipitation. By measuring both dust and weather, a greater understanding of the data can be achieved.

Vending machines are classic products for developers in the real-time world. They involve control of hardware covering items such as the control buttons and the motors that drive the product; they include simple user interfaces that are designed to be simple to use and readily understood with the general public; and they usually have some element of remoteness, in the sense of their location. These days, owners expect their machines to report back, in real-time, status information and alerts to report events such as sales or problems. To this mix, there is need for payment systems, such as Chip and PIN, accepting payment from credit cards, with direct access required to a bank.

The remoteness is of interest, because the vending machine is located in some public place like a railway station or an airport concourse, and they fulfil a public need. People do need their phones charged or their passport photo or a memory stick or a SIM card and it is easier and quicker to buy from a machine, especially at unusual hours of the day. The machine has to be simple to use, which is a challenge from a User Interface perspective. Most simple vending machines, such as chocolate or coffee machines, have a very pared down UI, because there is no need for anything complex, but on the sort of vending machines we have worked on, the needs are more sophisticated and therefore the UI has to cope with more complex needs. There are lessons to be learned from the simplicity of the coffee vending machine and it is also worth including behaviour from simple machines. The public know how a vending machine works, they've used them for years, so it is advisable to maintain that simplicity - the temptation is to make the UI complex because now we have a computer in the system. The computer has been added to cope with the complexity of the credit card transaction. The trick is to maintain the simplicity of operation.

Vending machines need connectivity now, which is a new thing. We've done the simple thing, initially, of adding a 3G modem. But this provides an incomplete solution, so we now provide a 3G router, which creates a mini network within the machine and allows a number of devices to connect to the Internet over the mobile phone network. This is important, because vending machines are an ideal way to provide advertising screens. We add displays of 48" and upwards on top of the machines, displays which show adverts like those seen on TV. They are timed to appear at certain times of the day, and they change throughout the day. We need remote access to be able to add and alter these adverts and the 3G router provides this.

Xor Systems was recruited by ANV Measurement Systems of Milton Keynes, who are market leaders in sound measurement equipment, to develop an embedded system and web based platform, to allow remote control and data gathering from the sound instruments provided by ANV.

Prior to Xor's involvement, ANV provided a system which was capable of recording to a memory card physically contained within the sound instrument, this imposed a number of restrictions, such as the length of time which a device could record for, the need for the client to physically visit the instrument at its location as well as the inability to monitor sound levels in real time, all of which ANV wanted to eradicate.

Therefore it was vitally important that the device could be left in the most remote of locations and could be accessed, in real time, without the client needing to physically visit the site. We identified and provided a small computer system capable of meeting the requirements and a 3G router to allow interconnectivity. We then developed a C++ application which allowed the system to write data to cloud-based storage, be accessed remotely and cope with situations such as loss of signal.

Once in the cloud, complex algorithms are used to process the data sent from the sound instruments, which provides valuable information and detailed reports to ANV and its clients.

When logged in to the bespoke website, customers can manage their instruments, changing the measurement interval, frequency weighing and other settings on the device; view data from the instrument in real-time, examine historic data and set event-driven notifications and alerts.