IIoT is the perfect solution for all your data accessibility needs, right? If you check out my previous blogs, I discussed the many benefits of using the Industrial Internet of Things (IIoT) to remotely access data. However, if not used properly, IIoT can get you into some trouble. Let’s review 5 common mistakes to avoid when building your IIoT application.
1. Excluding your IT department
It’s crucial to make sure your Information Technology group is involved in this project. IIoT applications can be very taxing on your network. It’s easy to forget some key aspects like bandwidth and network traffic when developing your application. But when your application is finished, your IT department is going to want to know what network resources that are being used. Some questions they might ask include:
- How many potential clients will the server have at any given time?
- What is the max refresh rate of your application?
- How frequent do you query the SQL server?
- How are your queries structured?
- What might be some vulnerabilities on this application?
- What measures are you taking to protect these vulnerabilities?
It’s going to be a lot easier if they are included right away so everyone has a good understanding of what resources are available and how to protect them.
2. Excluding OT and Controls Engineers
Similar to the IT department, it’s important to include the controls engineer especially if you plan on hosting data from a PLC. The controls engineer is going to want to determine what data is publicly available and what data should be kept private. Some questions the controls engineer(s) might ask include:
- What is your application trying to show?
- What PLC data do you want to use for this?
- Is your application going to write data to the PLC?
- Do any modifications need to be made to the PLC code?
Keep in mind that any modifications that need to be made to the PLC will probably have to go through the controls engineer. This is to ensure that no code changes on the PLC will impact the efficiency and safety of production.
3. Running out of date software
Software that you write and the software that your application relies on should always be up to date. In other words, if you use a module or library in your code, it’s important to make sure you have the most up to date version. Also, it’s important to keep updating your application for additional security and functionality. Out of date software can lead to potential application crashes or even vulnerabilities for cyber attacks. Keep in mind, an application that runs on out of date software makes the server host vulnerable as well as its clients.
4. Unorganized data flow
Data flow is an important concept to consider early on in the development of your application. Say you have a server forwarding PLC data to a SQL database that is then utilized in a web application. The web application acts as a historian and analyzes data change over time. Is it better to calculate the data in the back-end application, the SQL database, the server forwarding the data or the PLC? The answer depends on the situation but typically, it’s best to keep the data calculations as close to the source as possible. For example, say your back-end application calculates percentages based on yesterday’s production compared to today’s. In this situation, if the back-end application crashes, you lose historian calculations. Typically, a SQL database is much more reliable as far as downtime and crashes and it will run whether your back-end application is functional or not. Therefore, it would be better to do these calculations in the SQL database rather than the back-end script. Continuing this concept, what if the PLC could do this calculation? Now the forwarding server, the SQL database, and the back-end script can all crash and you would still have your historian data for when they go back up. For this reason, the closer to the source of data you get, the more reliable your calculations based on that data will be.
5. Unprotected sensitive data
Possibly one of the most important things to remember when developing your application. Even simple applications that just display PLC data can give a hacker enough for an attack. Think about this IoT scenario: Say I have a server that hosts data from my personal home such as whether or not my front door is locked. This information is important to me if I want to check if someone forgot to lock the front door. But to a burglar, this data is just as useful if not more as he/she can now check the status of my door without having to leave their car. If I don’t protect this data, I am openly advertising to the world when my front door is unlocked. This is why encryption is crucial for sensitive data. This is also why it’s important to discuss you project with the controls engineer. Data that seems harmless might actually be detrimental to host publicly.
Data accessibility is evolving from a convenience to a necessity. Everyone’s in a hurry to get their data into the cloud but keeping these ideas in mind early on in the application development process will save everyone a headache later on. That way, IIoT really can be the perfect solution for all you data accessibility needs.
To learn more about IIoT visit www.balluff.us.