IoT is changing the world around us. This change is affecting every walk of life including the maintenance industry. Maintenance management used to depend on skills of the maintenance managers to troubleshoot skills and was least data-driven as they have very limited data to fall back on when it came to machine health. However, it is rapidly changing. It is becoming heavily data-driven than skill driven. Advances in wireless communications and data processing enable maintenance managers to gauge the health of the factory in an instant.
We can tell that its no longer a hype but a reality and proof is in the fact that the leading organization- OPC Foundation is spending time in developing the Unified Architecture (UA) Specification for IIoT in the manufacturing environment. The standard is being developed to enable IIOT devices to easily pass information between sensors, machines, monitoring devices and the cloud in a secure and open way. Also OPC, AMT & OMAC have jointly developed Packaging Machine Language (PackML) and MTConnect which combines OPC UA with existing industry standards to lower cost of predictive maintenance.
Low cost of IIOT sensors is making predicting failure or measuring remaining useful life (RUL) of a tool a no-brainer enabling maximum uptime at optimum costs . As an example, a drill over course of its functioning will start to suffer wear. As we continue using them regularly at some point of time they become unusable either because the precision of the job falls below the parameter or the drill bit breaks off. With the combination of Industrial IoT sensors and AI techniques today we can easily predict the remaining useful life of the tool .
Any maintenance professional will agree with me that predictive maintenance is a journey they have to take but IIOT makes the journey easier. Retrofitting existing machine with a sensor to measure machine health becomes very easy. One of the companies where we work with to enable this transitions is OPA By Design. It is a smart device which can be tagged to any existing machine at a very minimal cost to measure 8 different parameters and report it maintenance supervisors via mobile app & cloud. Since the machine is constantly being monitored, any sign in degradation in the health of the machine is alerted instantly
IIOT is also enabling to drive down the inventory holding cost as now maintenance supervisors have better predictability of machine failure and hence they have to stock less spares. It also results in fewer emergency inventory orders and less downtime due to out-of-stock inventory.
IIOT is not changing anything for the maintenance professional except the fact that he can now listen to his assets and make informed decisions based on actual data on the health of the asset. IIOT is not going to fix the problem for him. He will still have to depend on his best technician to fix it reliably
We have been hearing a lot about IIOT to be the real revolution happening or industry 4.0 or the next industrial revolution. However its not like a eureka moment and it’s not something set out in future. It’s been an evolution into it for past many years. Factories were already getting digital with the industrial internet, with Industrial IOT its just picked up pace. The tools, technology and ease of data access has accelerated the pace of this adoption.
Large industrial houses like GE or Siemens or ABB were always an IIOT company although they were not known for it. They had the ability to monitor and managed the expensive machinery health Since it was important for them to prevent downtime to customers . It also enabled them to learn in real time how machine was being used to improve their engineering. The thing that has changed is that this capability can be offered and implemented by any industrial plant of any size or revenue.
IIOT is a vast area which includes everything from sensors to data big data & AI. After ERP, IIOT will change it further to pick up on problems sooner and there by saving time and money . Imagine a small shop manufacturing pumps – They can now be connected real-time to their sales offices so they know which pumps are selling each day which in turn enables them to adjust the production to what’s needed more, to getting inventory only when they need based on this data, and the predictive maintenance systems enable them to know if there is any flaws in the manufacturing process and once the pumps are installed at customer premises they can collect the live data and alert customer of any possible problem they are foreseeing .
There are many companies operating in this space trying to address different parts of the puzzle . At SequoiaAT we have been fortunate to work with 2 companies in this space @opabydesign work in building condition monitoring and predictive maintenance. @Deepthoughts works on building energy monitoring solutions for factories to ensure that machines are running efficiently and at optimum energy consumption
We may not see or experience much change in daily life unless we are involved in the industry or factory and that’s our daily job. Supervisors expertise to be called upon to identify and fix a problem is going away as a decision will be made on actual data and not the experience of a floor supervisor. Today if you are a small shop, and say a machine starts making noise most likely your workers are depended on more experienced people to troubleshoot and tell what the problem could be with help of these cheap but effective smart devices .
Link to Article on Linkedin
Headless systems abound in the embedded world, in consumer electronics, industrial automation, communications, automobiles etc. In these embedded devices, a Human Machine Interface (HMI) is conspicuous by its absence. That’s to say the device lacks a user display like a monitor, or LCD panel and nor does it have an input device like a keyboard/mouse or remote control.
Yet many of these systems need manual configuration by the user. The authorized user should be able to change certain operating parameters of the device within a predefined set of values. For instance, the Right/Left speaker settings in a home audio system, or safety thresholds in an industrial chemical reaction process, or DNS Server setting on a network router, or an engine speed/RPM limit setting on a telematics device etc.
User configuration circumvents the need to change the embedded software code (also known as the firmware) to address each and every individual user’s preference/scenarios. This would otherwise imply access to the source code (which in most cases is not open to users), making the required code modification, followed by compilation and re-flashing the updated firmware into the device. Configurability, the attribute that allows users to change key system parameters (that are internally used for computation by the firmware code) to predefined values at run-time, has traditionally been a critical design consideration for embedded system designers.
The user performs configuration settings usually using a software application that runs on a desktop or mobile device that presents the user with a configuration interface. The first generation of configuration applications (configuration files being their predecessors) ran on the desktop and used the serial/RS232 port, omnipresent at that time, to connect to the embedded device. These Apps were ported later on either to USB, which replaced RS232 on most modern computers, or ran as such by leveraging the virtual com port (a USB driver abstraction) that made the USB port appear as a normal serial port to the App. Examples of these applications can be found with printers, CNC machines, process control equipment etc.
After the World Wide Web established itself as a platform-independent paradigm for server access, the HTTP protocol came to be adopted across the spectrum of embedded designers for the purpose of device configuration. The inventors of the “www” may never have dreamed that the advantage they had created of not having to install a client application (and ending up managing multiple versions of client Apps for various OS/versions) would some day result in the creation of tiny embedded web-servers that run inside embedded devices. These are low footprint HTTP servers (like HTTPD) which make it possible for the embedded device to be configured using just a browser running on any platform. The IP connectivity typically being over either wired network like Ethernet, or wireless that is Wi-Fi or cellular (GPRS/3g), implemented as light-weight TCP/IP protocol stacks (a la lwIP) to run on resource constrained systems.
For instance, most telecom equipment, network switches, routers and gateways come with configuration pages that can be accessed using a browser. The first step in configuration typically is login, to authenticate user credentials and confirming the level of authority to perform configuration tasks. Subsequently a set of configuration pages are served out from a central menu, where the user can set/change specific parameter values for a group of configuration parameters related to IP networking, that are grouped together on that page. For enterprise routers, the configuration includes simple settings, like DHCP/Static IP, Default Gateway, Subnet mask, DNS Settings etc., but grow pretty complex, to Firewall/DMZ settings, Access Control, VPN/tunneling, Port forwarding etc. Thus it requires a qualified and experienced networking engineer to configure it correctly and to maintain the network equipment up and running.
Narrowing down focus to the world of consumer electronics, a few major industry trends seem to have influenced the way users configure headless systems in the home entertainment space today.
1) The ongoing explosion of mobile Apps, on Android, iPhone, Windows phone etc. – To such an extent that “there is an App for anything and everything”! This seems to have turned the tables on the earlier “browser” trend. Who cares for the browser now, there’s an App that does it anyway! And everyone knows it’s a song to just download/install a (whatever) App from the (which ever) Store.
2) The proliferation of home routers – With exploding popularity and plummeting costs, that the term “IP address” today is considered the tech-ABC of modern life. (In the 70’s the term “IP address” used to be high-tech parlance, but today it forms a part of the general vocabulary of a high school kid!) Since IP networking involves a highly standardized set of settings, like DHCP/Static IP, DNS settings etc., a home user can usually manage to set it up without much trouble. Or can at least leave the defaults alone knowing it is good enough to work correctly!
3) Wi-Fi gaining the status of defacto standard in consumer electronics – Thanks mainly to its cable-free, high bandwidth and moderately high range qualities, all ideal for the home segment. Given the massive penetration of Wi-Fi in homes today, networking for most consumer-electronics manufacturers defaults to Wi-Fi, although occasional segments of wired Ethernet could still be present in the home.
Streaming media protocols like Digital Living Network Alliance (DLNA) that work over self-discovery based networking protocols like Universal Plug-n-Play (UPnP) therefore work seamlessly over Wi-Fi, making it a natural choice for most device manufacturers, ranging from the traditional players like Sony, LG, Samsung etc. to recent innovators in this space like Google, Microsoft, Amazon etc. (*) These devices are far from standardized in their function, ranging from simple audio streaming systems, or gaming consoles to full-fledged home theatre systems. Some of these products come with Wi-Fi remotes and configuration (mobile) Apps. The important commonality is that these devices are all accessible on the Wi-Fi network, all the time.
So why configuration for a consumer electronics device! Imagine a user picks up the product from a store and brings it home, so how does the device know the user’s home network details so that it can connect? How could the user tell the consumer electronics device, “this is my network SSID, and this is the passkey”? – A mandatory and generic configuration that is valid for any make/model, for these are the vital pieces of information without which the device cannot join the home network successfully.
Further configuration needs will depend on the nature and functionality of the device. For instance, for a DLNA compliant device, what is the role of that device, whether is it a controller, or a renderer etc. Being non-standard and product-specific configuration settings, a browser based configuration process using menu-driven web-pages may not be intuitive to most home users. Hence custom Apps on popular platforms like Android, iOS etc. (available on the respective App stores for users to download and install) have become in vogue.
The user being a layman here (unlike in the case of a network switch where the user is an experience network administrator) the Config. App needs to provide a zero-learning, intuitive and wizard-driven experience. The Config. App needs to anticipate the user’s concerns, learning curve and proactively push help, like context-sensitive FAQs or “How to” videos, rather than let issues happen and then provide troubleshooting tips. As someone rightly said, “think not how you as an engineer would use it, but how your mom and dad would, and get it to work correctly too”!
The duration of time when the user is configuring the device is called configuration (or config) mode, whereas most of the time while in normal operation serving the home entertainment function, it is said to be in normal mode. To support the web server design pattern for configuration purposes, the device could be switched to become a Wi-Fi Access Point while in config mode. This means that the Config. App (usually a mobile App) can now connect to the device, and the user can set the configurations. Whereas for performing its normal home entertainment function, the device could be switched back to act as Wi-Fi Station, that normally connects to the home router/Wi-Fi Access Point.
Modern Wi-Fi chipsets (a la Broadcom) come with multiple mode operation – Wi-Fi Station (STN) and Wi-Fi Access-Point (AP) modes. Alternatively, a Soft-AP implementation on a single mode chipset would also serve the same purpose, as long as it can be made to switch between modes. The actual switching to config mode could be triggered on a special combo keypress (often with predefined timing) on the device itself. For instance, the Config. App of a consumer electronics device could display the following instruction to the user, “To enter Config mode, press and hold the FFWD and REV buttons simultaneously for more than 10 seconds. The Yellow LED will start blinking to indicate it has entered Config mode “.
From a connectivity view-point it is interesting to note that while in Config mode, the device loses its connection with the home network, since it is now acting as an Access-Point. With the mode switch it has started its own network for configuration Apps to connect, during which its normal functionality like rendering music is not available. It is sometimes even confusing to users, especially if internet access is involved, like Internet Radio etc.
Switching back to normal mode typically happens at reboot. Alternatively it could be implemented as the response to a reboot command while in Config. Mode. Following this mode switch the device regains its ability to play music etc. Another interesting behavior is that when this mode switch/reboot happens, the Smartphone loses its Access Point effectively so it automatically rejoins the home network to which it was connected earlier, a subtle yet standard behavior across Smartphones.
Since the embedded device and its Config. App have now become two peer Wi-Fi stations on the home network, it necessitates a mechanism for the App to know if (and when) the device rejoins the network after reboot. This could be implemented in the device using a broadcast mechanism of datagram messages, which the App could be programmed to detect with a suitable timeout.
Given the need for the Config. App to be available to users on multiple Smartphone platforms like Android, iOS etc. embedded system designers have adopted HTTP-based RESTful APIs as the programming interface to the embedded device. The embedded web-server is in fact a REST Server exporting REST APIs, which are implemented either as GET or as POST requests. The mobile Apps could call these REST APIs, with the data being exchanged as JSON payload of these requests. The embedded firmware that includes the REST Server is usually validated early on in the development cycle using generic REST API Clients (a la Chrome Advanced REST API Client), following which the Android and iOS Apps could be developed and hosted in the respective Stores.
Although not related to configuration, another generic scenario encountered with consumer electronics devices is firmware upgrade, or OTA (Over-the-air) upgrade as it has come to be known. The App typically alerts the user regarding the availability of the latest firmware, based on which the user decides to initiate the upgrade. The firmware image gets downloaded from a designated server of the manufacturer, typically an FTP server, file integrity check is performed after download, the firmware image is written into Flash, the boot loader parameters are modified and the device reboots (often more than once). All of this happens sequentially, silently under the hood, the App finally informing the user regarding the status of the upgrade.
The OTA feature also helps the manufacturer ship the hardware to hit the stores early, while allowing them to conveniently roll out updated features to users. So the next time we buy a device, like a fitness band, and install its App and it triggers off an upgrade (the first-time upgrade often being unsolicited!), we know what’s been happening! The App therefore forms a critical link in the whole upgrade process since the user needs to be kept in the loop always.
Configuration of headless systems has come a long way, the connectivity and Apps migrating across multiple technologies and platforms. In consumer electronics an increasing list of non-Configuration features are getting included in the Apps, such as firmware upgrades, library settings, playlists, favorites etc., making today’s consumer electronics products ever more user friendly and competitive.
(*) – While products from most home audio leaders like Bose, Denon, Yamaha etc. do support the DLNA standard, some of them are known to be moving towards proprietary APIs for media streaming and control. However they will most probably continue to leverage the underlying UPnP layer for device discovery, description and connection services.
IOT and Big data are considered as two sides of a same coin. For some industry requirements, you won’t be able to differentiate whether it is IOT or big data solution. At the same time, in some cases your IOT solutions may not be having any big data use cases. In such cases, it is always a tough call for the IOT strategist to decide on the feasibility of considering big data in their system.
I suggest to keep your data big data friendly.
What does big data friendly mean?
Current big data solutions are spending lot of efforts to clean up their large amount of complex & messy data. It happened just because the data was not collected big data friendly. We should learn from the mistakes of others!!! Your data may not be “big” now, but it is growing and soon will be large for any big data processing in future. Industry already started adopting new approaches, moving from descriptive to predictive and prescriptive analytics. We should prepare our data for various big data analytics in future to improve our business value.
How can we make our IOT strategies big data friendly?
There are a few design considerations,
1. Finding ‘target-rich’ data :-
All data may not be worth saving for future. Organizations need to focus on the high-value ‘target-rich’ data. Business analyst and data scientist should work on identifying the high value data which can be an asset for the organization in near future.
2. Data saving strategies :-
How data is stored is a major decision point for the big data system.
2.1 Data Format
Saving text data in formats like JSON data won’t be easy to handle when the data become huge. We should also consider using more big data friendly formats like Parquet, Avro, ORC etc
2.2 Dynamic schema for version handling
The data veracity increases when the system grows with different versions have different fields added or renamed or removed. Manually handling schema is always an overhead. Self describing data formats will be a suitable solution. We should consider using data formats having dynamic schema generation capability (like parquet).
2.3 Partitioning strategy of data
Data partitioning strategy should be defined to having better segmentation of data for easy processing.
3. Security considerations.
Data security is one of the major concerns of both big data and IOT systems. We should implement the privacy by design. Privacy impact assessment and data anonymization are few things to be considered.
In a multi tenant environment, you don’t know how fast your data is growing and become matured as big data. Preparing your data for future will enable to extract maximum value out of it.
“Information is wealth”, Sequoia Applied Technologies will help design solutions to Capture it before you lose it!! .