1. Assist. Prof. Rassim Suliyev Zhumaniyaz Mamatnabiyev Week 6
IoT in Industry
Assist. Prof. Rassim Suliyev
Zhumaniyaz Mamatnabiyev
Week 6

2. OUTLINE Intermediary devices Microcontrollers and microprocessors
Sensor communication
System communication
PID (proportional-integral-derivative controller)

3. Intermediary devices
A key component for developing an IoT solution is a computer that reads the sensors, stores and processes data, communicates and displays results, or actuates some other device (the 'Processing' section in the IoT diagram above). There are literally thousands of different types, with a vast array of capabilities, costs and features, so this raises questions, such as:
Which micro controller/microcomputer should we use?
How do we get them to talk to the Internet and ‘Cloud’?
What’s the difference between a microcontroller and microcomputer?

4. Microcontrollers and microprocessors
Almost all electronics equipment contains either a microcontroller or microprocessor. Ex: digital watch, washing machine, etc.
The microcontroller is the heart of an electronic device.

5. Microcontrollers and microprocessors
Most IoT systems utilise microcontroller units (MCUs) to collect data and transfer it to the processing units through the Internet. The advantages of using MCUs include:
They are relatively simple, as MCUs do not require an operating system to function and are easy to interface with external components such as sensors.
A MCU is usually sufficient to provide processing power and functionality in most IoT systems, thus making them economically viable for IoT applications.
Due to their simplicity, MCUs are less vulnerable to security attacks.
A microprocessor is a micro version of our computers, hence the name ‘microprocessor’.
We can see that generally, if an application requires a form of Operating System, a microprocessor is normally used. A good example is our smartphones, which often use ARM microprocessors.

6. Microcontrollers vs microprocessors
Microprocessors can be thought of as more advanced embedded systems than microcontrollers.  The main differences between a microprocessor and a microcontroller are:
A microcontroller is 'all in one': the processor, RAM, and IO are all on the one chip - as such, you cannot (for instance) increase the amount of RAM available or the number of IO ports. The controlling bus is internal and not available to the board designer.
A microprocessor generally does not have on-chip RAM, ROM, and few GPIO pins. It usually uses its pins as a bus to interface with RAM, ROM, serial ports, digital and analogue IO, etc. As such, it is expandable at the board level.

7. Microcontroller or microprocessor?
The first choice you need to make when designing an IoT solution is obviously whether to use a microcontroller or microprocessor. In many cases this simply comes down to asking the question: ‘Do I need an Operating System?’
When they are used, operating systems for IoT hardware are often categorised into two groups: end devices and gateways.
End devices, or nodes, are often small and low power (both in energy and processing).
Gateways often control communication to the Cloud, or handle significant processing themselves.
As more and more processing is pushed to the network’s edges, traditional applications and devices that previously ran without an operating system are taking advantage of the ease of development, maintenance, and automation an operating system brings. There has been a great deal of activity in developing operating systems for the IoT in recent times.

8. Microcontroller or microprocessor?
Under general circumstances, one of the main constraints of an IoT microcontroller or microprocessor (from now on, let’s refer to them both as a ‘micro’ unless we need to differentiate) is their power consumption. However, there are other key aspects to consider when selecting a micro. They include:
Power consumption
Most IoT devices will be placed in the field running on a small battery. We would like the devices to run for weeks, days or even years on a single battery.
Connectivity options
For example; Bluetooth, LoRa, Choosing the IoT connectivity comes with its own set of choices, dependent mostly on power and range required.
Development boards and kits
Many IoT development boards are prototyping solutions that feature low-power processors and support various programming environments such as ‘C’, Python, Scratch, etc. These platforms are generally used to collect sensor data using firmware and transfer it to an on-site or cloud-based server.

9. So, how to choose?
When looking to develop a new IoT solution, prototypes of both hardware and software are implemented and refined through testing and product evaluation/feedback. What you choose will depend on:
the requirements of your project, and
your test results.
Utilising off-the-shelf components can, in many cases, speed up the development process. As mentioned previously, there are many kits available and these can ‘jump start’ the development of rapid prototyping solutions, without the requirement of designing and producing custom-printed circuit boards (PCBs) and other components.

10. IoT device specifications and characteristics
Platforms for the IoT are continuously being developed and released in ever-increasing numbers and varieties. As such, it is necessary to understand the underlying specifications of these devices, so as to evaluate and compare the characteristics of new devices as they become available (and not fall for the vendors’ hype).
We can characterise IoT devices in terms of these high-level capabilities, including:
Power management
Sensors and actuators
Processing capability
Connectivity

11. Power management
Power management is a critical concern for most IoT devices. Many are wearable (who wants to recharge their smart watch three times a day?), installed in remote or inaccessible areas, or intended to run for long periods of time without maintenance (including solar powered and energy scavenging devices).
Placing devices into a sleep or low-power mode may alleviate some of their power requirements, but the device itself must be capable of entering this mode, and then being awakened by an appropriate method.
One major constraint on power is not just the micro itself, but the communications protocols implemented on the platform. We will look at this in further detail shortly.

12. Power management
Several aspects impact a device’s power requirements, including:
the clock rate of the CPU
number of processor cores
included peripherals (USB, Bluetooth, Ethernet ports)
processor load
supply voltage levels

13. Sensors and actuators
In order to make use of the information detected by sensors, it is necessary to convert these measurements into digital readings.
While sensors convert an environmental variable (temperature, humidity, etc.) into an electrical signal, output devices or actuators convert an electrical signal to a physical action. Output devices include LEDs, speakers, screens, and actuators such as motors or solenoids that move or control things in the physical world.  When designing a system, we need to consider the ports necessary to drive these devices. 

14. Processing capability
IoT devices capture, process, analyse and transform sensor data and/or interact with the environment via actuators and displays. To do so, they require processing and data storage capabilities. There are two main approaches to how, and more importantly, where we process our data:
Transmit the data to other devices, gateway devices, or cloud services or apps for aggregation and analysis.
Process the data locally in the IoT device (or perhaps on the gateway device).
The ‘Cloud’ based solution is to transmit possibly large volumes of data to a cloud server or data center for analysis.
The ‘Edge’ approach involves performing data analysis at the edges of a network where the data is captured, rather than in a centralised or Cloud location. Data can be analysed in real-time on the devices themselves, or on a nearby gateway device that the IoT devices are immediately connected to.

15. Connectivity
We can't have an Internet of Things device without connectivity to the Internet! How we connect, and what attributes are important for our application, are additional considerations when selecting a platform or prototyping kit.
Our microcontroller needs to talk to our sensors and actuators and also connect to the Internet, either directly or via a gateway/concentrator.
Devices communicate with other devices locally, and publish data to services and apps in the Cloud.
Solutions may use:
Wireless links, e.g WiFi, Bluetooth, Low Power Wide Area Network (LPWAN), LoRa and SigFox; or
Wired links, e.g. SPI, I2C, Ethernet, RS232.

16. Prototyping boards
The are a growing range of off-the-shelf prototyping kits now available, many specifically designed for IoT development. These low-cost, modular systems offer a flexible way to rapidly develop and test out IoT solutions without a big financial outlay. Many of these microcontrollers and microcomputers (also called single board computers, or SBCs), are designed around System-on-a-Chip (SoC) ICs.
SoCs bundle a number of capabilities onto a single chip, including:
data processing
Storage
networking
SOCs offer many advantages, including their low cost and the incorporation of a range of subsystems such as Graphic Processors (GPUs) and I/O ports (USB, DACs/ADCs, etc.).

17. Microcontroller development boards
Microcontrollers contain a processor (often more than one - multicore), random access memory (RAM), and electrically erasable programmable read-only memory (EEPROM) for storing the custom programs that run on the microcontroller.
Development boards are PCBs (printed circuit boards) with additional circuitry to support the microcontroller, to make it more convenient to prototype with and program the chip.
The devices that interact with our environment (sensors and actuators) are connected to either digital or analogue General Purpose Input Output (GPIO) pins on the development board. If you are going to have multiple micros communicating with each other, ensure that you have sufficient GPIO pins, and that they support your preferred communications protocol (for example SPI, I2C, etc.).

18. Microcontroller development boards

19. MicroComputer development boards
As with microcontroller development boards, these contain one or more processor cores, RAM, and some static storage such as an SD Card, USB flash drive, or hard drive (usually a solid state drive – SSD). However, in most cases they are much more powerful with a faster CPU, greater RAM, and a variety of I/O devices, such as USB, Ethernet, WiFi, and HDMI for screens, built-in.
Often also called ‘single board computers’, they also generally run an operating system, allowing an wide selection of development tools to be used. There are many different operating systems available. The most popular are those based on Linux.
Be aware that these devices tend to have limited  GPIO, often do not include ADCs or DACs, and consume significantly more power.

20. MicroComputer development boards

21. Do I need an Operating System?
The decision to run an Operating System, or not, will impact your choice of micro significantly. One way of determining whether or not to include an OS, is to look at the memory and I/O requirements of your device.
If your application requires less than 16 kilobytes of RAM or Flash (usually an 8 or 16 bit micro) and can be implemented in a single loop (which simply means the program starts reading instructions from the top, and when it reaches the end, jumps back to the beginning and repeats forever, e.g. a digital clock), an operating system is probably not necessary. However, with the ever-reducing costs of hardware, even simple applications are now including an OS.

22. Programming and selecting a 'language'
Selecting your development board using hardware specifications alone is not ideal. As we know, to get a micro to perform any function, we need to program it. To achieve this, we use a particular language, usually selected on the basis of how familiar we are with it, ease of use, libraries available, and the task we wish it to do.

23. Sensor communication
Serial communication protocol is the common protocol used for microcontrollers’ communications. It involves the process of transmitting a series of digital pulses between sender and receiver on specified data rate, and is generally divided into synchronous and asynchronous categories.

24. Asynchronous serial communication
In asynchronous serial communication, transmitter and receiver manually agree on the data rate, and each manage the timing independently with no common clock. That means the data rate for the transmitter sending pulses is the same as data rate for the receiver listening for the pulses.
The transmitter and receiver are required to agree on some parameters to establish the asynchronous communication, including;
data rate
voltage level corresponding to 1 bit or 0 bit
signal voltage level interpretation; whether high voltage=1 and low
voltage=0, or high voltage=0 and low voltage=1, for inverted signals.
Generally, in most microcontrollers the high voltage is either +5V or +3.3V representing the 1 bit, and low voltage is 0V representing 0 bit. At the end of the data transmission, the receiver end is able to rebuild the original message by using the interpreted bits from voltage level.
Asynchronous communication is suitable for connecting microcontrollers that can manage the time signal independently of each other, using their internal clock.

25. Synchronous serial communication
In synchronous serial communication, a clocking system manages the synchronisation between the transmitter and receiver. The clock is either embedded as part of the data frame, or a separate clock wire manages the timing during transmission.
All devices in the communication line share the same clock data, and with every clock pulse one bit moves in the line; therefore the clocking system directs devices regarding when to listen to the coming bits and when to discard them.
This type of communication is used for simpler devices with no internal clock crystal and few memory registers.
The two most common synchronous serial communications are Inter-Integrated Circuit (I2C) and Serial Peripheral Interface (SPI).

26. System communication
The large amount of data that is collected by sensors is required to be transferred to servers on the Cloud for analysis and decision making. Then the necessary action will be delivered back from the Cloud to microcontrollers.
Communication between sensors to computer/Cloud is done using a number of communication protocols based on the power consumption, coverage, data rate, and cost requirement for each IoT system.

27. Sensor to Cloud communication protocols
Ethernet
A wired network is the traditional way of connecting devices to the Internet, and is practical for an environment with a wired connection to the Internet, such as a smart home system.

28. Sensor to Cloud communication protocols
Wireless
The diagram below illustrates the different types of wireless communications used by mobile technology, and how the communication is sent to the internet: via Bluetooth (BT), WiFi and Mobile.

29. Wireless communication
The distance the data can be communicated affects the network that technology can be used in.
Wireless communication standards and technology can be grouped based on the size of the network:

30. Bluetooth

31. 6LoWPAN

32. WiFi

33. Wireless Wide Area Network (WWAN)
A wireless wide area network (WWAN), is a form of wireless network. The larger size of a wide area network compared to a local area network requires differences in technology. Wireless networks of different sizes deliver data in the form of telephone calls, web pages, and streaming video.
A WWAN often differs from wireless local area network (WLAN) by using mobile telecommunication cellular network technologies such as LTE, WiMAX (often called a wireless metropolitan area network or WMAN), UMTS, CDMA2000, GSM, cellular digital packet data (CDPD) and Mobitex to transfer data. It can also use Local Multipoint Distribution Service (LMDS) or Wi-Fi to provide Internet access. These technologies are offered regionally, nationwide, or even globally and are provided by a wireless service provider. WWAN connectivity allows a user with a laptop and a WWAN card to surf the web, check , or connect to a virtual private network (VPN) from anywhere within the regional boundaries of cellular service. Various computers can have integrated WWAN capabilities.

34. Processes and systems
Most electronic systems are designed to perform a specific task; that is particularly true of our IoT ‘things’. These things can be broken down into two parts: the process and the system.

35. Systems, inputs, and outputs

36. Systems, inputs, and outputs
Our inputs are:
coffee
water
a filter
electricity
The output is coffee.

37. Feedback
We are all familiar with the concept of feedback. We can apply this to our electronics systems as well. For example, we turn a heater on and set a temperature...then feel it is too hot, and use that feeling to adjust the thermostat of the heating unit.
In our electronic system, we can do the same thing. Even in our simple coffee making system, outputs can result in feedback. For example, the quality of the coffee made can indicate which ingredient (water or coffee) should be controlled next time to produce better coffee.
An IoT device can’t just be a collection of inputs and outputs though, it must ‘do something’, even if it is just to monitor a switch, or to turn ‘ON’ a light.

38. Closed-loop feedback system
The most common configuration is the closed-loop system. In this configuration, a proportion of the output of the system is fed back to the input and either added to (positive feedback) or subtracted from (negative feedback) the input. This results in the output of the system continually altering or updating the input with the current output conditions.

39. Closed-loop feedback system
For example, if we return to our earlier scenario of turning on a heater, we have a closed-loop feedback system that looks like this:

40. Open-loop control system
Another less common configuration is that of the open-loop system. In these cases, the system does not monitor or measure the condition of its output signal. For that reason, it is also called a non-feedback system.

41. Open-loop control system
For example, here is the open-loop drying system of a clothes dryer.

42. Open and closed loop advantages and disadvantages - error correction
Open-loop systems have a significant disadvantage, as the micro has no knowledge of the output (effect) if there is a disturbance - for example, if the coffee pot runs dry. This means we have no way of knowing if there’s a problem, due to the lack of a feedback loop, so if the coffee pot doesrun dry, it may catch on fire!
In summary, an open-loop system has no knowledge of the output condition, so it cannot self-correct any errors when the preset input value drifts.
Closed-loop systems use feedback where a portion of the output signal is fed back to the input to reduce errors and improve stability, which is something we generally want to have in IoT systems.
Closed-loop systems are designed to automatically achieve and maintain the desired output condition, by comparing it with the actual condition. It does this by generating an error signal, which is the difference between the output and the reference input.

43. Motor control
The following video shows open loop control and closed loop control for a robot car controlled by an Arduino.
Video: Robotic car, closed loop control example
Direct Link:

44. PID (proportional-integral-derivative controller)
PID systems are found in a wide range of applications for industrial process control, sensor devices, and even robotics. PID refers to the type of feedback path that this type of controller uses - in fact it uses three different paths, which is why a PID is also called a ‘three term controller’.
This is, in fact, the first or P part of the PID controller, proportional. The I is integral, and the D is derivative.
These three modes are used in different combinations:
P – Sometimes used
PI - Most often used
PID – Sometimes used
PD – rare, but can be useful for controlling servomotors.

45. PID (proportional-integral-derivative controller)

46. PID (proportional-integral-derivative controller)
The idea of this algorithm revolves around manipulating the error. The error (used for feedback) is the difference between the:
Process Variable (PV - what we are trying to control, e.g. current temperature in our home);  and the
Set Point (SP - e.g. the temperature we would like our home to be)
So, The PV is subtracted from the SP to create the error.
The error is simply multiplied by one, two, or all of the calculated P, I, and D actions (depending which are implemented);
Then the resulting combination of error values are added together and sent to the controller output;
If the PV and SP are the same, we don’t have to do anything (e.g. the temperature set in our home is the same as the temperature read by the sensors);
However, if there is a disparity between the SP and the PV, we have an error, and corrective action is needed.

47. PID (Example)
Using our home heating/cooling example, the air-conditioning or heating will be turned on, depending on whether the PV is higher (need to cool) or lower (need to heat) than the SP. 

48. PID | Proportional control
In ‘Proportional only’ mode, the controller simply multiplies the Error by the Proportional Gain (officially termed Kp) to get the controller output. The Proportional Gain is the setting that we tune to get our desired performance from a ‘P only’ controller.

49. PID | Proportional control
If P is large, then there is a tendency to overshoot, and then to overshoot again on the correction.

50. PID | Adding Integral control
The combination of Proportional and Integral action seems to do a reasonably good job of controlling our system. In fact, PI controllers are probably the most common configuration.

51. PID | Adding Derivative action
The third type of action in PID control is the Derivative.
The effect of the derivative is to counteract the overshoot caused by P and I
When the error is large, the P and the I will increase the controller output
This controller response makes the error change quickly, which in turn causes the derivative to act more aggressively to counteract the P and the I
KD uses the rate of change of the error to calculate its ‘damping’ effect on the system.

52. PID | All together

53. PID Summary
The Proportional corrects instances of error;
The Integral corrects accumulation  of error; and
The Derivative corrects present error versus error the last time it was checked.
Get it right, and PID is one of the best methods to control your IoT system!

54. Any Questions?