The Road to Building Industrial IoT Solutions

Introduction

IoT (Internet of Things) has been a popular word for quite a few years. However, it is still a concept that sounds fashional, hi-tech, mysterious, surrounded by halos of smart devices sometimes.

In this article, I am not attempting to illustrate how to make a toy working with fancy IoT technology, but trying to demystify the process of developing IoT solutions down to the ground by using non-smart devices and focusing on the common practice of how industrial IoT solutions are developed.

Talking about "IoT" means that we shall do something to connect the "things", thus hardware devices, such as data collectors and transmitter will play great roles in the solutions.

Being "industrial" means that it is critical about functionality, accuracy, stability and durability within the specific situations where the devices run, and sometimes also means that large scale deployment.

The word "practice" means that there are some common routines we can follow and real world pitfalls to avoid. Recognizing and realizing them will help smooth out the way towards our future IoT solution developments.

No code will be provided in this article for the following reasons:

1. The main purpose of this article is to discuss the common practice, the methodology, of the development and deployment of IoT solutions, not a specific solution. We focus on the differences between IoT solutions and software-only solutions.
2. We use hardware products manufactured in China, that are unlikely available overseas. And our software is programmed for those hardware, without the hardware, the software is meaningless.

Even though, the discussion in this article, I am sure, will still help you start up your own business on industrial IoT solutions.

The practice of developing and deploying IoT solutions

The practice of IoT solutions is listed here as a 7-phase procedure below, and then each phase of the practice will be explained with a simple use case. In the explanation part, the case and the practice reflected by the case will be interlaced each. Then we will see in each phase what we are going to do, what we need, where are the pitfalls we shall avoid. The IoT solution practice usually consists the following phases.

1. Recognizing the requirements
2. Finding the appropriate hardware solutions
3. Selecting among models and manufacturers
4. Testing the devices and prototyping the application
5. Software implementation
6. Deploying the devices and the software
7. Connecting more things, generating more values

1, Recognizing the requirements or breeding your idea

The case: one of our clients wanted us to help them to queue trucks in his factory.

They were running a concrete factory and had about 100 concrete mixer trucks to transport their products to various builders. Each truck was ridden by a specific driver. The concrete factory paid those drivers for each delivery. More deliveries, more money. There were several production lines in the factory producing concrete. The production and deliveries were all managed by dispatchers in a control tower within the factory. The dispatcher firstly started a production line to produce concrete, then dispatched a truck to fetch the concrete under the production line.

Figure 1: The plan of the factory

The problem was that the trucks were not working in good orders. The truck drivers claimed that they came to the factory earlier, but were queued behind other drivers who came later. Once being queued behind, they would have to wait in the factory longer. Waiting in the factory did not make money. Delivering concrete did. Consequently, they would have less chance to deliver more concrete orders and felt the dispatchers unfair. The manager of the factory had already set a rule that who came earlier should be enqueued in front of those who came later. But it could not be well followed by the dispatchers, since they were sitting in the control tower busy operating and monitoring the production systems at most time.

They wanted something to solve their problem, maybe a device which installed at the gate of the factory detecting the entrance of the trucks. Drivers in the factory had two switches and the factory never stopped production. The device would therefore be working outdoors within 24 hours a day.

The practice: the recognition of requirements in IoT solutions is almost the same as traditional software-only solutions--talk to the client and listen to them, observe them work, read their documents and data; afterwards, address the problems and summarize a specification for requirements.

However, when things become industrial, we shall pay special attentions to the working environment of the devices, which may greatly affect and limit our device selections later. Environmental specificity is one of the most critical considerations in industrial IoT solutions, and it spans over the whole solution from the commence to the end.

For instance, some devices work great at day time, but they may not be so functional at night; if devices are required to work outdoors, climate changes and other physical situations must be taken into consideration.

2, Finding the appropriate hardware for the requirements

The case: there were quite a few ways to form such a first-in-first-out queue mentioned above. The key was to identify which truck entered the factory at what time, in an open area.

Option 1: GPS

In China, each truck must install at least one GPS device to report its position to the traffic bureau periodically, according to the traffic regulations. The GPS devices on the trucks of that factory in this case happened to be sending data to our servers. Thus it was also possible to use the GPS time and locations to determine when a truck was back to the factory.

We could spot the location of the factory in our system, and compare the real-time locations of the trucks. When a truck was reported about 10 meters closed to the factory and it was more than 10 meters away from the last report, we could trigger an event that it was back, and enqueue the truck.

This option had at least four problems. The first and the second problem were about accuracy. The third and fourth problem was about data availability.

The first problem was that GPS locations drift around. Even if a truck is static with its engine stopped, we can read its GPS location moving slowly around. Typically, the drift radius can be 25 meters normally and much larger when the signal is poor.

The second problem was that GPS devices did not report their positions continually. Usually a device reported its position at an interval about every 10 seconds. Therefore, every device would not report their positions at the same time. The GPS devices could stop working when the truck was powered off. Thus it was impossible to synchronize their report timings.

Because of the above two problems, if truck A and B, all equipped with a GPS device, entered the factory firstly A and immediately followed by B, it was possible that we read that A came to the factory before B, but almost the same possible that B came to the factory before A as well.

In this case, the third problem was that those GPS devices happened to be sending their positions to our servers. If not, we wouldn't have the locations of those trucks and might have to install a second GPS device on each truck and make the total costs of the solution blow up, which would be unacceptable to most of our clients. Consequently, this option would prevent us from doing business with some clients and thus it was a less viable option.

The fourth problem was that the transmission of GPS location records relied on the GPRS network. In this case, the GPRS signal in the factory was good. Theoretically, when GPRS signals were unavailable, the system would not work at all. Certainly, this would very unlikely to happen since people in the factory need communication and no one would be so stupid to build a factory where cellphones would stop working occasionally.

Option 2: License plate recognition system

This option works like the following: install a camera at the gate of the factory and take pictures when a truck is back to the factory. Within the camera, there is a license plate recognition module which will identifier the license plate on the truck and send its number to the computer via network.

The first problem of this option was accuracy in special scenarios. License plate recognition system, stated according to one of the most popular vendor, works correctly 99% at daytime. The number of accuracy was pretty good. However, it was only for the daytime performance on regular vehicles, not for the trucks in this case.

1. Firstly, the trucks travelled between the factory and construction sites. The dirt from the construction sites could cover the license plates and make the recognition rate decrease significantly.
2. Secondly, most trucks and concrete factories in China operate the full day. The accuracy of the recognition rate could drop at night.
3. Thirdly, the accuracy was totally inacceptable in rainy nights. The factory in this case located in South China and there could be quite a lot of rain.

The second problem of this option was the high cost of such a good license plate recognition system.

Option 3: RFID tags and readers

We finally adopted this option.

We installed an RFID reader at the gate of the factory and handed an RFID tag to each driver. The drivers placed the tag onto their trucks and drove them into the factory. When they arrived, the tag reader would read the tag number and send it to the computer in the network. The program on the computer would look up the database and identify the associated driver and truck. Afterward, the driver with his truck would be enqueued in the system.

The reader plus the tags were quite less expensive than the camera with license plate recognition system, but were working all day and all night, in rain or sunshine, serving the best speed, accuracy for identification, location and time.

The practice: in an IoT solution, we must find out the "Things" we are going to deal with and use the right hardware to collect and transmit data from those "Things".

Without the right hardware, requirements may not be fulfilled, the data gathered or the result may be unreliable, the system may be unstable, the total cost of the solution may be exaggerated, the scalability of the solution may be restrained.

In the above case, we see that accuracy, data availability and the working environment varies our selections considerably, cost can be an important consideration sometimes. The right hardware means that it must function well in the all working environment to best support uninterrupted industrial operations, balancing with acceptable accuracy and costs.

Some most common, but not all, considerations on working environment are listed here:

1. Power supply: what if the device where your data collector is plugged onto is power-off? How long can the device work if it is powered by batteries?
2. Networking: without networking, things are just things, not Internet of Things.
3. Working time: date and/or night
4. Climate: can your device survive in icy, rainy, windy, misty and/or dusty days
5. Human destruction and thievery: in one of our cases, an employed truck driver used a jammer to disrupt GPS signals and shut down the power supply of the remote cameras in the truck in order to steal the cargo; car thieves now use GPS signal detectors to find out and disconnect GPS devices before stealing
6. Place: for example, GPS won't work indoors
7. Pressure: external pressure or crush demands a hard container to protect the device
8. Space: is there enough room to install and steady the device and free from potential crush?
9. Temperature: batteries run out faster in lower temperature; some chips may go wrong in high temperature
10. Moisture: possible cause of short circuits
11. Stability: where to install and stabilize your devices? vibration can break connections between chips
12. Acidity and alkalinity: acidic environment ruins the electric wires or cables
13. Ecology: I saw several clients had their fiber optic cables bitten by mice; living bugs cause system bugs
14. Cleanness: computer visual system fails under heavy dust, dirt or mist
15. Noise: speech recognition system fails under terrible noise
16. Magnetism

Working environment issues could usually make the whole solution impractical or lead to physical failure, from which could seldom be recovered by a "remote reboot", but require costly human on-site intervention. That is why building a stable and durable industrial IoT solution so challenging.

Figure 2: In another case, we had difficulties in finding enough room for our devices in cargo elevators

You may also encounter the challenge of making your decision on using ad hoc devices or generic architectures like Raspberry Pi, Arduino, etc. No definite rule applies here. The decision is usually a balance between several aspects. Since we are talking about industrial solutions, business considerations are listed first.

1. Integration/Deployment scalability: If you are connecting a GPS module with the Raspberry Pi motherboard, it is OK for us to use breadboard and wires when we are making our funny customizations, but it is obviously unacceptable for industrial use. You have to weld the module and the motherboard together, and possibly, place them into a hard container to protect the chips. What will happen if you receive an order demands thousands of devices deployed within one week? Can your team or someone else assemble the devices in the given time? If not, maybe it is better to find an ad hoc device that suit your needs.
2. Technical support: For generic architectures, there are vast communities for the motherboard. But when it comes to certain extensive modules, less people will be on your side. For ad hoc devices, many manufacturers can provide SDK, demo programs with source code in several programming languages, in time telephone and/or instant messenger support. Some manufacturers even provide on-site services. It will be much more preferable when you find such manufacturers in a demanding industrial project.
3. Cost: It really depends on devices. Usually ad hoc devices, for being massively produced and better modular integration, have lower prices than generic architectures.
4. Device OEM: Some manufacturers are willing to brand your company name on their products. If you are considering this, ad hoc devices may be your first choice.
5. Innovation/Quick modeling: With great programmability in generic architectures, quick modeling for new ideas is more possible.
6. Extensibility: Do you need to extend the devices with special modules now or in the future?
7. Performance: Some generic architectures, such Raspberry Pi, have relatively high performance CPU and large memory, which is great for computational tasks at the "Thing" side; however, they are not always the winner, some ad hoc devices have built-in hardware specially designed, for instance, a remote camera equipped with a license plate recognition module, an LED display array controller, may bring better performance for some specific tasks.

Figure 3: The comparison between ad hoc hardware devices and the generic architectures

Aspects	Ad hoc devices	Generic architectures
Integration/Deployment scalability	Preferable
Technical support	Maybe preferable	Vast communities for the motherboard, less on extensive modules
Cost	Usually preferable
Device OEM	Possibly preferable
Innovation/Quick modeling		Preferable
Extensibility		Preferable
Performance	May be preferable for specific tasks	Preferable for generic computation

3, Selecting among models from millions of manufacturers

The case: in the previous phase, we selected the RFID technology for the solution. Afterward, it was time to select the right product from the right manufacturer. We finally selected an ad hoc RFID reader for its good integration, excellent technical support and lower cost.

In China today, we can very easily reach millions of device vendors from various sources:

1. E-commerce markets. The e-commerce markets are our favorite purchase options. We can very easily locate lots of device vendors, sorted by recent sales numbers, relativities, reputations from buyers and even the distances of the device providers to our position. We can also read comments and questions from the buyers in the market.
2. Search engines. Some manufacturers, may be big, do not have their e-commerce shops on the online marts. They have their own official web sites. By using search engines, it is possible to locate those manufacturers or their resellers.
3. IoT related forums. For instance, both Raspberry Pi and Arduino have their specific online forums around. Some generic IoT forums provide information on other products or hardware architects.
4. Social networks. Nowadays, some manufacturers are building their sales channels on the social network, for instance, WeChat (the biggest mobile social network in China), Weibo.com (a society web site like Twitter in China). It is also possible to find out information about good manufacturers there.
5. Traditional business associations and offline trade markets.

Figure 4: Various RFID related products in an e-commerce market (the third one provided a demo program)

After some searching and communications via instant messaging applications or by phone calls, we settled down to four models provided by two manufacturers.

Both manufacturers provided powered and powerless RFID tags. Powered RFID tags enabled the reader to read them from about 1 to 10 meters away, but the batteries in the tags had to be replaced every several months; the powerless tags could only be read within about 1 meters, but no need to use any battery, and they were much cheaper than the powered ones.

It did not matter if we used the powered tags or the powerless tags in this case. Our client in this case decided to use powered RFID tags for their drivers could drive through the gate comfortably. In another case, another client preferred powerless RFID tags for they believed that having the drivers to stop at the gate and have the tag read would bring more safety to the area around gate.

The practice: the same kind of hardware can have various models and configurations, provided by various manufacturers, which can also affect the whole project. It is time to make some selections.

The selections include selecting the model and its manufacturer.

On selecting the model, if we are making things for hobby, we can pick one for simple reasons. For business, things are not so simple. In the previous phase, seven considerations are listed when comparing ad hoc devices against generic architects which are applicable when we choose among models. The clients' requirements can affect the choose of models too.

On selecting the manufacturer, we have plenty of sources. As we are sourcing from manufacturers, we must take it serious as we are finding our business partners. Although this is an article about IoT technologies, I'd still love to share our experiences on choosing manufacturers. Here are some manufacturers we had better avoid…

1. Notorious for sellout against their clients. Will they attempt to find out your clients and contact them without your acknowledgement? Will they stop supplying you for their own interests? If you are considering making a manufacturer your only provider, and the product is vital to your solution, you'd better do more background searching on them.
2. Limited in manufacturing capabilities, short of supplying.
3. Unresponsive on selling, and more critically, technical supports when we have entered the Test or Deployment phase below.
4. Having obvious defects on their products implying quality control issues, for instance, random tiny gaps on products, which claiming to be waterproof or you are planning to use outdoors; reworked solder joints on printed circuit boards.
5. Badly documenting their products.
6. Not manufacturers but resellers actually. Buying from traders are quite OK in most cases, but pretending to be the manufacturer is another story. If they are offering products at a high price mismatching the quality and service, responding slowly to your technical requests or even purchase orders, it could be an implication that they are not doing good business.

If you are prototyping your idea, you may postpone this phase and choose your manufacturer before wholesaling your inventions to the world.

4, Testing the devices and programming the prototype of the application

The case: having the powerless RFID tags chosen, we bought one reader and 10 tags from one manufacturer and did some tests with a prototype application.

The reader and tags were shipped within 3 days. We got not only communication protocols of the reader but also demo programs with source code from the manufacturers as well.

The demo programs helped us quite a lot:

1. It set up the hardware with specific parameters, for instance the sensible distance, IP address of the reader and so on.
2. It verified that the reader and tags were working.
3. It was taken as a bootstrap of our program later.
4. It also helped our programmers to understand the protocols in a short time.

The practice: testing is one of the most time-consuming phase. As discussed above, IoT solutions usually works in various physical environments. Thus it is preferable to emulate those environments in tests. Before environmental tests, we must do some preparations, such as setting up the reader, planning the test, writing a prototype program if no demo program was available, etc.

In this case, we bought equipment from one manufacturer. If the deadline is demanding, maybe it is better to bought from both manufacturers and test their devices at the same time, in case when one product fails, we still have the other one to keep working with. Nonetheless, it is much more preferable that we test devices and choose our suppliers when we are free from project pressure.

The time of shipment can be critical sometimes as well. If a manufacturer could not ship its products on time, it may be a bad signal that it is having some difficulty in continuously and promptly supplying products to you.

The case continues here.

Step 0, Power and network preparations

We studied the installation guide of the RFID tag reader, connected the reader and a computer to the LAN ports in a switch, powered on them. Since the tags were placed close to the reader, the reader kept beeping after it was powered on. That was quite distracting. We moved the tags away.

Step 1, In office feature tests

The reader had its initial IP address. We changed the switch and the computer to the same subnet of the reader. We pinged the reader from the computer and verified that the reader was responding and the network was OK.

We then started the demo program to configure the sensible distance of the reader to 2 meter, and brought back the RFID tags. The reader no longer beeped until we brought a tag close to 2 meter nearby. We changed the distance back to default. The reader kept beeping again. We changed the distance to 1 meter to avoid the distraction. We then verified that the reader could be configured to various reading distances.

In the demo program, we could also see the numbers of the tags popped up as they were read and the reader beeped in the previous step. By comparing the numbers displayed on the program and printed on the tags. We then verified that the reader could read tags correctly.

We also saw that heartbeat packages were received by the demo program.

We reconfigured the reader to have a new IP address, subnet of the reader, and then changed the networking settings of the switch and computer respectively. The reader was not responding ping commands any more after the reconfiguration.

We checked the manual and it said that the new network setting would not be applied until the device was restarted. We powered off the reader by unplugging it and powered it on after 1 minute. It responded the ping commands once again.

We repeated step 2 and step 3 to verify that the sensible distance configuration could be preserved after power failure.

We repeated similar steps to verify the other features was functioning correctly.

We placed several tags side by side and brought them near the reader and verified that the reader could read them simultaneously.

Step 2: Outdoors environmental tests

The purpose of outdoors tests was to find out problems in environments where the production would take place and verify features that were unverifiable in office tests.

In test 1, we brought the reader and the tags into a nice sunny day, and used a cable to connect the reader and a laptop to a switch. We adjusted and checked the reader whether the voice feedback was audible and LED display was seeable in sunshine.

In test 2, we brought the tags far from 10 meters and approached the reader. We verified that reader could read all tags as expected within 10 meters.

In test 3, we evenly covered the reader with quite considerable dust and dirt, for the concrete factory was dusty too, and tested the reading with tags within 10 meters.

In test 4, we kept the dust and dirt, and tested the reading with a co-work bringing one tag and went into the 10 meters' range then another one bringing another tag and went into the range about 6 meters behind and observed whether the reader could correctly report that sequence.

The rest tests were omitted here.

The practice: before being put into industrial use, devices should be tested in all possible scenario to make sure that they could work as expected. In order to test the devices, we shall also pay some time for programming a simple prototype to work with the hardware. The prototype is not for production use, but to quickly find out whether the hardware can work as expected.

Nowadays, many hardware manufacturers in China provide demo programs for their products. The provision of demo programs can considerably reduce the test time since the programs will not only show how the protocol works and themselves can be used to verify whether the devices are working properly. If the project is pressing, demo programs with source code may be a must-have feature.

New challenges for test coverage come to IoT solutions. If we are deploying device in uncontrollable environments, we had better make more thorough tests by simulating possible environments. We may also test the sequence of event occurrences.

5, Software implementation

The case: the software implementation included database modeling and programming.

As the business data had nothing to do with the hardware product in this case, we set our software team to modeled the database at the same time as the device test. There were not so many tables in this simple case:

1. RFID tags and their corresponding truck and driver.
2. Tag reading history.
3. The queue for trucks in the factory.

Records would be inserted into the database table when a tag was read.

The programming part included:

1. Receiving data from data collectors.
2. Recording data.
3. Handling duplication, inaccuracy and errors in the data.
4. Utilizing and visualizing the data.

The tag reader used TCP protocol to transmit tag numbers. We merged the demo code into our TCP communication host. Things were almost done within two hours including database interaction and basic testing.

We had two problems on data duplication and incorrectness. The first problem was that since the RFID had a very long sensible distance (requested by our client), a truck could generate more than one readings when it passed the gate. The second problem was that there was only one gate in the factory and a loaded truck would also generate readings as they left the factory.

To solve the problems, we programmed the following logic in the application. The first reading would queue the truck, subsequent reading would not queue the truck any more. We also connected our application to production line systems in the factory and read the dispatched truck from those systems. When the truck was dispatched and finished loading, it would be removed from the queue and would not be queued within 20 minutes--this was not so accurate but an assumption that the deliveries would usually take more than 20 minutes. We improved it later.

After the records being filtered, they were displayed on the screen of the dispatcher's monitor.

The practice: the challenge of IoT programming is always be prepared for data duplication, inaccuracy or incorrectness, the nature of "Things".

Duplication can be eliminated without great efforts since the data is identical and can be identified easily.

To fight with data inaccuracy and incorrectness, for instance, the drift of GPS reported positions, we usually do the following ways:

1. Double verification with another redundant device, or with another device collecting data in a different way. For instance, if we can detect that a vehicle is powered off, there will be little chance that it is moving, the GPS drift problem can be suppressed by this means.
2. Comparison against other data sent by the same device if device redundancy is not an acceptable option. For instance, if a temperature sensor was reporting a degree around 20 centigrade each second, and suddenly it jumped to 100 centigrade and then backed to around 20 centigrade again, it was very possible that the 100 centigrade was a false read.
3. Data processing algorithms may also be applied.
4. Checksum data can also be applied to help preventing problems in data transmission across networks.

Scalability is also an important consideration in this phase. In an IoT solution, there usually are thousands of devices connected.

The understanding of TCP or UDP protocol may be a must-have when developing IoT solutions. In IoT solutions, most devices transmit data with the TCP or UDP protocol for the sake of hardware implementation, transmission efficiency, scalability and standardization. XML SOAP or JSON data packages are seldom seen. To ease our implementation and help us to scale up when our business goes great, we usually use some communication or messaging frameworks, such as SuperSocket, NetMQ, etc.

The knowledge of high performance database manipulation can also be a must-have. When the data is collected, they are usually stored in traditional rational databases or NoSQL databases. The size of the data can very fast grow up to terabytes, pebibytes and more. Database partitioning, distributed storage and querying will help solve many problems.

6, Deploying the devices and software

The case: the deployment of the devices was not so difficult for we had professional engineers and the job was finished within a morning.

Figure 5: The installed RFID tag reader at the gate of the factory

The practice: hardware deployment differs from software deployment.

Be cautious for safety. Some of our engineers got injured when installing sensors or cameras on the truck.

If you do not have professional engineers to install the devices, you had better make the product to be installed and maintained as easy as possible. Otherwise you will face many problems while expanding your market shares.

After the deployment, tests should be conducted the same way as the previous Test section shows, on both the devices and the software program.

7, Connecting more things, generating more values

The case: we provided and connected more things into the solution for concrete factories later.

We installed a huge LED display array in the factory, another LED monitor in the drivers' rest room and displayed the queue on them so the drivers could see their positions in the queue.

Figure 6: The outdoors LED display array (behind which were two production lines and the dispatchers' office)

A side note for LED display array testing: the huge display array was installed in a very high place. It was inconvenient and inefficient to test with such kind of devices. During the test phase, we brought a high-pixel-density LED display array connected by an LED hub. Since the array had a much higher density, it was small enough to be placed on the desk and we could test against it easily.

Figure 7: High-pixel-density LED display array was used in the in-office tests

To get rid of the "20 minutes" assumption mentioned the above, we connected the GPS devices on the trucks and marked their locations to be "out of factory" by calculating their distances to the factory.

We installed sensors on the trucks and monitored the unloading. Once a truck was loaded, it would not be queued until it had unloaded the concrete. With the GPS data, the dispatchers could see whether the trucks had unloaded concrete at specific locations or not.

Figure 8: The scheme of the IoT solution at work

We provided reports about how long, how far, how many times each truck ran each day, each month, with the collected loading and unloading data.

We built an App for construction managers, the clients of the concrete factory, so they could know that the trucks from the concrete factory had delivered products to their sites without staying on the sites all day.

Finally, we made use of the following devices and formed a solution:

1. RFID tags and a reader, connected via LAN.
2. Two LED display arrays, with an LED controller on each of them, connected via LAN.
3. A GPS terminal integrated with GPRS transimission module on each truck.
4. A rotation sensor on each truck, sending signals to our cloud via a transparent transmission protocol provided by the GPS terminal.
5. Servers and hard drive arrays in our cloud, receiving data from those GPS terminals and forwarding the processed data to the programs in the factory.
6. A server in the factory receiving the results from the cloud.
7. Computers in the dispatchers' office and elsewhere in the factory.
8. Couple of switches to connect the things.
9. Smart cellphones on each site managers.

Each time we added a new type of device into the solution, we repeated the above phases. Considerations listed in each phase helped us to thoroughly evaluate the situation and avoid problems from many aspects.

The most time-consuming tasks were:

1. Device installation (40%): it depended on the amount of devices to be installed. In this case, we had to schedule with the drivers for they were usually out there deliverying concrete orders. It also took quite considerable time on rewiring circuits on trucks for GPS terminals and sensors. Traveling to the factory could take hours too.
2. Software implementation (45%): the software development could also take much time, but with the help of the manufacturer, the time was reduced; the time on building basic system infrastructures such as communication framework and database planning was not counted here
3. Device selection and manufacturer contact (5%)
4. Requirement gathering and environmental examination (10%)

The practice: with more data collected, IoT solutions get more power. Data flows and information gets utilized effectively. By gathering data, we are also pushing open the gate to Big Data analysis and future applications.

In many solutions, most devices are not "smart devices" at all. Those cloud-connected "stupid devices" by various device manufacturers run reliably and provide needed data and form efficient IoT solutions.

Conclusion

Industrial IoT solutions for production require a comprehensive understanding of the environmental requirements, selection among various hardware schemes, careful choose of hardware manufacturers, thorough environmental tests, readiness of real world failure, inaccuracy and voluminosity, professional installation of devices.

By following the 7-phase practice of developing and deploying IoT solutions, we open the gate to the new connected world with our sure hands.

History

2016-8-2: Initial post