Pat Millott, Author at AUTOMATION INSIGHTS

JSON Objects and How They Can Streamline an IIoT Application

In web development, JSON objects are a programmer’s dream come true. JSON, or JavaScript Object Notation, is much similar to XML (EXtensible Markup Language) in that it’s used as a standard format to organize and transfer data across multiple programming languages. For example, say you want to send sensor data from a SQL database to a JavaScript front end. JavaScript doesn’t know SQL syntax and SQL doesn’t know JavaScript syntax. How do these different languages communicate? JSON/XML will act as a middle ground between the two allowing them to talk to each other. When given a choice between the two, I’m always going to pick JSON objects as they are much more efficient than XML. They are shorter in length and easier for computers and people to interpret. Here’s what 3 sensors would look like in XML versus JSON:

How does this apply to the Industrial Internet of Things? The JSON format for data transfer is so universal that IO-Link modules host it on a web server. This server is accessible by entering the IP address of the module. The module data can be seen in JSON format by modifying the IP address and adding “/dprop.jsn” into the URL of a web browser (i.e. 192.168.0.1/dprop.jsn). You should see something similar to the image on the right.

The “dprop” stands for data propagation or simply the movement of data from one source to multiple sources. This data is delivered with a standard request-response system. Say you’re writing some software that uses the sensor data as variables. All that’s needed to get that sensor data is a few lines of code that send a request to the module which in turn responds with your data.

How does this differ from the Industrial Internet of Things (IIoT) application frameworks from my past blogs? Previously, we discussed using OPC UA software to subscribe to PLC data and forwarding this data to a SQL database. From there, the application would query SQL for the data and render it appropriately for the user experience. Using JSON objects, we entirely eliminate the need for SQL or OPC UA software by accessing the data directly from the module. This not only makes the application independent from the PLC but also uses much less network traffic. However, using JSON objects, we can only subscribe to data from IO Link devices.

All acronyms aside, there are a million different ways to structure an IIoT application. The best fitting architecture depends on the environment. Systems with standard input/output will most likely need some form of communication with the controller. IO-Link systems will streamline this process by allowing the user to directly access the module’s IO Link data. How you go about building your application is entirely up to you. In the end, however, having this information readily available via the Industrial Internet of Things will be more beneficial than you could have ever imagined.

To learn more about IIoT visit www.balluff.us.

5 Common IIoT Mistakes and How to Avoid Them

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.

Three Things to Know About IO-Link

IO-Link has become synonymous with the term “distributed modular I/O”. We know it is universal, smart, and easy, but what exactly is IO-Link? In a nutshell, by utilizing a standard sensor cable, the IO-Link slave device speaks point to point with an IO-Link master. The IO-Link master then combines the data with other IO-Link slave devices and communicates over an industrial network or backplane to the controller. In other words, it can be compared to a simple USB connection: for the most part, any USB device will work in any USB port, as long as the manufacturers of both devices have played by the rules when making the devices.

With that being said, here are three things to know about IO-Link:

Cable Type and Length

Cable runs between master and slave can be up to 20 meters in length and typically utilize standard automation cables. Most cables, but not all, are M12 A-coded, unshielded, 3 or 4-conductor DC sensor cables.

Star Architecture

Since IO-Link utilizes a point-to-point serial communication, Star Topology is the only device architecture that can be constructed.

Port Class A vs Port Class B Devices

While most devices utilize IO-Link port Class A, output devices like valves are now being offered as IO-Link port Class B. Be sure to know if the master and/or slaves are Class A or Class B type ports. Most Balluff devices are IO-Link port Class A.

To learn more visit balluff.us/iolink

The Importance of Data Accessibility with IIoT

Typically a college student is asked two questions: “What are you studying?” and “What would you like to do with your degree?” In my case, I always answer with “Computer Science” and “I have no idea”. Lately, the field that has grabbed my interest the most is the Internet of Things (IoT). The concept of data transfer and communication between ordinary utilities is going to revolutionize the way we go about our day to day tasks. Home automation is a key example of this. We have found ways to expedite those pesky tasks that nobody enjoys doing by simply automating them.

I’ve come to realize that there is data everywhere; we just need to take the opportunity to use it. I’ve done this in a few small side projects around my apartment. Is the door locked? Are my lights on? Did the refrigerator door completely close? These are all examples of data that is useful to me at any point in time. The trick is making it available. Using a low power microcontroller and a few sensors, I’m able to host this data and view it at any point in time. IoT has the capability of effectively improving our energy efficiency, security, and productivity simply by making data readily available.

Likewise, these same concepts apply to industrial automation. I’ve spent the last few months developing a web application to demonstrate Industrial Internet of Things (IIoT). The web app simply hosts a live feed of data from a conveyor system. From any computer on the network, we can see crucial data such as conveyor accumulation, sensor status or even maintenance needs. Once this data is made available, we can even automate the analysis. For example, on a conveyor, we can look at the number of packages that go by every day. A simple script that increments by one for every passing object can give a very accurate representation of day to day productivity. More intense algorithms could analyze trends in mass quantities of data return valuable results. All of this is done simply by making data continuously accessible.

According to Business Insider, by 2020, there will be 34 billion devices connected to the internet and that there will be $6 trillion spent on incorporating and integrating IoT. As a student with a passion for technology, I see a lot of potential in this field. So next time I’m asked what I plan on doing with my degree, I might say an IoT developer. It’s a fascinating subject that only has room to grow.

To learn more about IIoT visit www.balluff.us.

How do I see PLC data from my smartphone?

From my smartphone, I can do anything from making coffee to adjusting my home thermostat. This wave of appliances and other physical devices connecting and communicating through a network is known as the Internet of Things and it’s playing a crucial role in industry. With the Industrial Internet of Things (IIoT) we can now monitor PLC data without ever intruding on the PLC. Let’s take a look at how I implemented PLC tags on a web application.

The first step is to download OPC UA historian software. OPC UA stands for Open Platform Communications Unified Architecture. OPC is a client/server communication standard that was made as a gateway between the PLC and a Windows PC. The UA was added as an upgrade that allowed communication across other operating systems such as Linux and iOS along with other added functionality improvements. Once this software is running and the PLC and PC are communicating, we can work on hosting that data.

Hosting the controller data can seem like a daunting task at first due to the many different options in software and programming languages to use. For example: Ruby, PHP, ASP, ASP.NET and much more are available for back-end development. For my web app, I used SQL to host the data from the OPC UA software. As for the back-end, I went with node.js because it has great packages for working with SQL; in addition to the fact that node.js uses JavaScript syntax which I’m familiar with. The front end of the app was written with HTML and CSS with JavaScript for interactivity. With all these elements in place, I was ready to host the server on the PC to host PLC data.

With smart IO-Link sensors on our conveyor I was able to look at diagnostic and functional data in the PLC and setup an interactive screen at the conveyor for viewing production and maintenance information.

And now I can even check my sensor outputs with the same smartphone that just made my coffee and adjusted my office’s temperature.