Bob: Coming up for manufacturing in the near term and... What we see coming up in the near term, and our friends at DMC are going to offer a perspective on that. Data notification alerts and remote kind of activity are becoming increasingly common on the plant floor. We're going to talk about a number of areas here this afternoon, and I know, we've known Matt and his been a great supporter of our efforts and understanding the system integration market in the plant market very well. Matt Puskala is a Project Director and member of the senior management team at DMC based here in Chicago. He’s focused on industrial integration with PLC systems, including Siemens and Rockwell is a lead developer for web applications and web enabling systems. He holds a B.S. Degree in Electrical Engineering from Kettering University, the mascot of which I do not know. It’s one of the very few ones I'm not familiar with. It's what?
Male 1: The Bulldogs.
Bobs: The Bulldogs. We're very pleased to have Matt with us this afternoon. From DMC Matt Puskala. Matt?
Matt: All right. Does this sound okay? All right. So, thanks everybody for coming. I appreciate it. I want to thank Head of Affairs, and also I want to thank CFE Media for giving me the opportunity to speak today. In particular, I want to thank Bob Bavara and Jimmy Langhenry. As Bob mentioned, my name is Matt Puskala. I work with the company called DMC, and today I'm going to talk about industrial automation and modern connectivity. So, to start off, the company I work with DMC... I don't know if any of you guys happen to see my colleague, Tim Jager. He's over here, he gave a presentation earlier this morning on working with system integrators, some good questions to ask, how to choose a system integrator. I heard it went over well. All right. So, DMC, we are an engineering solutions company that focuses on software. We're growing company, and over the past year and a half we've opened up offices in Denver and in Boston in addition to our main office here in Chicago.
Now, we work in a lot of different areas, a lot of different industries. We work with a lot of different software platforms, a lot of different hardware platforms. All that said we typically break down the areas that we work into four different groups. But industrial automation makes up over 60% of what we do of our business. We're talking about programming PLCs, programming robots, programming servo systems, all that stuff. We also do quite a bit of work developing applications for PCs, for the web, and for databases. So, today we're talking about factory automation and connectivity, so we're primarily talking about the intersection of these two worlds here. I think Bob did a pretty good job of giving my bio. I'll give you guys just a little bit background here. I went to a small engineering school in Flint, Michigan, called Kettering University. It used to be General Motors Institute. I graduated in Electrical Engineering and its a co-op school, so I actually started at DMC in 1999 as an intern. I've been here for quite a long time, and I've seen the company grow. It's been a fun adventure.
I'll give you guys a quick overview of what we're going to talk about today. So, modern connectivity, it could mean a lot to a lot of different people. To kind of get us on the same page, I'm going to frame the conversation. I'm going to give you guys what my definition is for the context of what we're talking about today, and tackle little bit about why modern connectivity might or might not make sense. And then I'm going to tell you guys three stories about modern connectivity, and in each of these stories, I'm going to talk a little bit about the why, why it made sense again, what the driving factors were. And then also at the end of each story we're going to dive into the how; the technical details. And then at the end we're talking about modern connectivity a hot topic often times is security. It's kind of a big broad topic there's a lot you could dig into. I'm just going to focus on giving you three quick tips and then I'm going to put you guys on a good direction for some further reading if you're interested in digging into that a little bit further.
All right. So, as I said before, modern connectivity in the context of factory automation could mean a lot to a lot of different people. For me, to give you guys a definition that I want to use today, let's take a step back and look at the classic traditional automation systems. So, you've got the PLC. That's the brains of your system. It's making all the decisions and its controlling all of your factory equipment through IO. All your motors and what not. All your actuators. And then of course, you've got the interface that's your window into the system. Now, all of this is an island on its own. It's not connected to anything else, at least traditionally, especially if go back a couple decades. So for me, I would say the definition is anytime you're connecting your system to something outside of that core production purpose, with the idea of pulling information either in or sending information out. So, that could mean that you're connecting it to the internet in one way or another, or it doesn't have to be the internet. It could be connecting it to your own internal networks. We could be connecting to servers, databases, or more complicated systems. It may be something as simple as opening-up remote access so that you can get support from third parties on a moments notice if you've got a system that goes down.
So, nothings ever free. Adding modern connectivity to your factory system is going to have some costs. You're opening yourself up to external threats. You're adding more complexity to your system. It could be more challenging debug and take care of things. You got more points of failure and of course it costs time, money, calendar time. So, when you were making the decision of whether or not we want to add modern connectivity. We want to have a good understanding of the reason why were doing it. What's the benefit? I'm going to give you guys four reasons why, or basically break it down to four reasons. So first off: optimizing production. Sometimes it's good to be able to identify productivity losses. Now, when are you going to identify a productivity loss? It might be tomorrow or next week when you when you get a chance to look at a particular report or look at your data, but why not be able to do it immediately? Why not get an immediate text notification the second you got some major issue?
I'll give you guys a quick story. Just recently a few weeks ago, we went out on a sales call to a client. They produce food. And in their packing rooms they've got a little bit of an issue, a pain point that they brought up. And basically they tried to maintain the temperature and the humidity within certain bounds, but of course, it's a little bit cold so their workers who are in there sometimes just said, "I'm just going to open up the door." Now, that's going to cause problems with the product, it can cause issues with shelf life later on when the products ships. So, they came to us to look for some ideas to try to solve this problem and the solution that we presented to them is a pretty easy, pretty simple solution. There's a company called Dixon, they've got an off the shelf solution where they make these little devices, standalone devices that you can put into a room. Each of this devices has a temperature sensor on it and a humidity sensor. And then you can pull this data into the cloud. Dixon offers cloud services. And from there, you can log into their systems and you can view the charts of your data. But further more, you can set this stuff up, so that if your temperature falls outside of certain bounds you get an immediate text message, a phone call, an email, whatnot. Now, to give you guys an idea of how much this cost if you're going to set this up for a couple of rooms. We're talking a cost of hardware of maybe around a $1,000. And then for a year subscription for their cloud services, we're talking around $200 to $300. And then the set-up time, this stuff is really, really trivial and easy to set-up.
All right. So, furthermore, on optimizing production you might want to improve the process. So, for your process you may have all these different variables: temperature, tweaking recipes that have an impact on your product. And you want to keep track of what if I change x or change y: "What input does it have?" Excuse me. What effect does it have? Basically we're talking about the ability to do some data mining here.
Second reason it would be traceability. So, for couple of examples here. If you're a food manufacturer or your a pharmaceutical company, you may have regulatory bodies that require certain amount of traceability. And then furthermore, let's say, there's an issue with your product and you need to perform a recall. Well, now you're going to be able to keep track of where your particular lot went and be able to effectively do that recall and your also going to know where that lot came from. What parameters you had involved in the process, or what raw materials you brought in that caused you to have to this issue.
Third reason would be convenience. There's this idea of, if I need third party support to keep my system up and running and I've got a major downtime issue, I may need to call somebody. It may be hard for them to drive-out or to fly-out and I want that instantaneous response. So, in that case you may want to open up the system. Also, let's say you're responsible for keeping an eye on several plants that are all over your floor.
Well, it can be nice to be able to keep track just from your desk, just from your PC.
Fourth reason, standardized and control the system inputs. Basically, what I'm talking about here is recipe management. Now, the benefits of recipe management is that they allow you to keep your process consistent and keep your quality consistent not just on one particular unit, but potentially in a distributed system where you've got systems all over the place. One other quick benefit for this is when your changing-up from one product to another it's a breeze to be able to just go and select the next recipe. So you can save some time. All right. So, in terms of the framing the discussion, we've talked about the definition. We've talked about some of the reasons why. What's the goal here? Well, I would like it if you guys could come away from this with some new ideas, or maybe just some new ways of looking at some old ideas that will help you guys get the most out of modern connectivity at your own systems or for your client systems.
All right. The first story that I'm going to tell you guys, this is an automotive story. A good friend of mine works for an automotive supplier. He's an engineer there. And he's responsible for making sure that a bunch of particular machines are running well. These machines are all producing automotive parts. And every Monday morning he comes in and he's got a continuous improvement meeting where they're responsible for looking at big problems and seeing what they can do to keep these machines running optimally. Basically we're talking about solving mysteries, though identify a big problem. What do you think their big problem is at that time? Then they'll do investigation to see if they can find the cause, and of course solve it.
All right. So, I give you guys a couple of examples. This right here is one of the lines that he’s responsible for. Now, the parts travel down the conveyor here, and it stops at one of several stations and each station there's an operation on the part. Once it gets past station four it moves over to station five and there's a press operation. Now, the press operation takes a lot longer than all these other operations, and it would be the bottleneck slowing down production, but in order to increase throughput they added several presses. And the transfer station here will take the part and put it into one of five open stations. Then from there of course it travels on down to the next next operation.
So, in one of these meetings they were looking at problems and they noticed that they had a lot of transfer faults in particular when they were running one part. By transfer faults, I'm talking about drop parts at station five here. So they decided to look into the cause and it turns out that the particular part that they were running had the smallest diameter of all the other parts, and they did a quick investigation and the cause was pretty simple and the solution was pretty simple. Basically the end effector on the transfer wasn't well suited for handling the part, so they just redesigned the end effector and were able to solve the problem.
I'll give you guys another example here. They took a look at all the different faults that they were having on a daily or weekly basis, and one particular fault seem to be having the biggest impact. And that was press jam faults. Press jam faults were happening here at station four. So, my buddy Dan spent a little bit of time trying to investigate what the cause was and he watched the machine for a while. And typically what would happen is station three runs a little bit faster than station four, and you would get a build up of parts in between there. Now normally it would handle the queuing well, but every once in a while you have an issue where a couple parts would slide on top of each other they would both move into station four together and you get a jammed stand. So, the solution: pretty simple, just add the better part queuing and they were able to reduce the problem. Now, the way they were collecting the data that they were using to solve these problems was basically just threw manual data collection. The operators were responsible for writing down the faults that they had on every shift and the numbers that they were producing and this was working out pretty well for a lot of these simple mysteries. But what happens when you have a more difficult mystery?
So, what are the mysteries that they had to solve on this exact same machine was just simply the fact that production was inconsistent on a daily basis. They took a look at this and they try to find the solution here. And sometimes it seemed like the cause was related to a particular part, but not always. Sometimes it seemed like the cause was related to a particular fault. Our production was done and we had more of this particular fault, but not always. Nothing really seemed to correlate. When they were having this discussions they realized over and over again, "we don't just trust the data."
They kept doubting in it: I don't know if the operator got this down right. So, the real problem that they had was inconsistent data tracking. Well, how do you improve that? Through automation. Automate your data collection and automate your reporting. So, they implemented a system with some help from us that pulls in data automatically from all these PLCs, all these factory lines. And sends daily reports and weekly reports out to both the engineer's and the shift supervisors. The system breaks down the data, slices and dices it every which way. All the different ways that they think might be useful for solving these future mysteries. To give you guys a couple of examples. They've got production data by part, production data by machine, they've got their top fault data, they've got down time data by down time reason.
Now, that they were armed with this data it was time to come back to this challenging mystery and see if they could figure it out. Well, it turns out that when you're changing over from Part A to Part B on this machine, you have to make a lot of mechanical changes. Lets say the diameter is different. You've got to bring the tracks on the conveyor in or out to match the diameter of the new part, and you've got to make some mechanical adjustment to the press as well. The mechanical adjustments to the presses at station five were particularly challenging. It took a lot of manual labor to do this. And it also was hard to get back in there. You had tight space. So, basically it turns out that some of the operators rather than doing that were simply disabling the presses. And as you can imagine that's where the potential bottleneck was. It cost a drastic reduction in throughput. Now, that they had the automated data correlating it to a particular operator was pretty easy. What they did help them solve this mystery, but of course it armed them to solve future mysteries. It was a good investment. And one of the key features here for us was the visibility. Dan, himself, he’s an engineer, and he's not going to be the best equipped person to take care of some issues with operator performance, but it was also going out to the shift supervisors.
So, the how. How is this done? Well, all of these PLCs that were controlling each of this lines were running on a Rockwell Automation Allen-Bradley PLCs, so a FactoryTalk Metrics was a good solution. FactoryTalk Metrics has a fair amount of functionality out of the box both in terms of data collection and also doing reporting. In order tweak these systems there is a lot of tools that you can use to make it easy. But one of the really cool things about is it's got an open architecture, so if you really want to slice the data and customize the system for your particular problems or your plant floor you can bring in third party tools to leverage the most out of this.
All right. So, as a broad overview, you've got several PLCs out here on the on the plant floor, each one of them controlling the line, and they're pulling all this data into a single Windows Server. And FactoryTalk transaction manager is responsible for pulling this data into the network. That's a tool that comes with FactoryTalk Metrics. This data gets dumped into a data base, a Microsoft SQL Server Database, and then there's some method of viewing reports.
Let's take a quick look at what's going on in the PLC. So, if you want to get the system up and running with just some simple data and some simple reports keeping track of productivity. All you really need is to create some tags or registers in the PLC that represent the current state of that PLC or that factory line at any given time. But if you want to start adding more complicated customization for your particular system, all you really need to do on the PLC side is add a tag or a register that represents whatever data, whatever factor you think might be related to your your production. All right. So, digging in to what's happening on the sever side here. I already talked a little bit about the FactoryTalk transaction manager. You've got the data and the sequel server database and then there's a method of viewing reports. Out of the box they have a method called Report Expert. It allows some basic pre-configured reports. And then, if you want to take a look at it, basically what you do is, you pull up your web browser and you point it to an address that goes to this particular machine and there you go.
But if you want to add more powerful reports? Well, there's a lot of third party systems that you can connect to this. In this case, Microsoft SQL Server Reporting Services was used. It's similar in some respects in that you can browse these reports via a web browser, but the really cool thing is that you can pull in the full power of SQL queries. If the data is there in the database, you can come up with SQL queries that slice and dice the data, whatever way makes more sense for you and for your factory floor. Now as I mentioned before, one of the cool key features of this was the visibility in the fact that you didn't have to just log in to the web browser to pull these reports, but they were sending these reports to get them right in peoples faces. How do you do that? It's actually pretty simple. You can set up an SMTP server on that exact same Windows Server, and then just configure SQL Server Reporting Services to connect to it.
So, a quick recap on this. Again, their focus here was to get the most out of these machines. And basically the power of FactoryTalk Metrics was utilized, but really fully leveraged through customization and pulling in third-party tools.
The next story I want to talk about is a candy story. So, I don't know if you guys know this but one interesting thing about making candy is that the ingredients are pretty simple. For example, if I'm making a soft chewable candy the main ingredients are really just water, sugar, and gum or gelatin. Now, by tweaking these ingredients I can get quite a bit of variety in the product. For example, on the one end I might have a soft chewy gummy bear, but then if I change that the gum or gelatin in it I can go all the way over to the other end where I've got a jujube which is still a chewable candy, but it's almost a hard candy that your more likely to suck on than chew. On top of that running out the ingredients you'll going to have the coloring and the flavoring, and that's pretty much it. So, from all theis you can imagine that on one particular piece of factory equipment, you can get quite a wide variety of production out of that system simply by varying the recipes.
Now, the candy industry isn't immune to the pressures of globalization. Just like everybody else these guys also have to innovate all the time. They have to come up with new ideas, new products. They have to get them to market quickly, that have to experiment all the time. Now, one of our clients, a candy manufacturer, their global engineering team was given a challenge of implementing a new recipe globally, all across world at all their plants. And this recipe was going to be a soda flavoring crossover. Now, not only was this challenging because they had to implement this all over the world. They also had a lot of different systems that were built on different platforms. They had some Siemen PLCs. They had some Allen-Bradley PLCs.
Furthermore, a lot of these plants were set up at different times, so in addition to having different platform manufacturers, within Allen-Bradley for example, they had to some legacy systems. They had some control logic systems. They had some SLC-500 systems. The global engineering team basically had two options at each of these situations. They could either fly engineers or resources out to that location to implement it, or they could try to find local integrators to implement this new recipe.
So, as you can imagine it took a bit of effort. It took five calendar months to make some simple recipe changes and a fair amount of money. And of course at this point of time, they needed to implement the next recipe. Did this make sense? Well, they came to us with an idea and we helped them to implement a better solution. This new solution is a single website that resides on their internet, and it's responsible for for implementing these recipes at all their plants all over the world. Now, one cool thing about this is that didn't have to scrap all their existing control software and hardware. They were able to keep it all. So now, if they want to implement the new recipe a user simply has to go to this internet website, log in, select a particular plant, then select a particular factory line from that plant and then edit in an existing recipe or create a new one.
So, let's talk a little bit about how this is created. Off course in a broad overview you've got the single global server and these plants all over the world. On that server, a quick overview of the components. You've got the internet website. This is where you go to the view or edit existing recipes. Then you've got the database, and this is where all the recipe data is stored. Then finally, there's some custom code. And the custom code is responsible for sending this recipe data out to each of the factory lines. All right. Digging in a little bit further into the tools that were used for the internet website. We used DNN. It's a Content Management System. It's not the only Content Management System out there. Drupal and Joomla are couple to name a few. We in particular like this one because we’re Microsoft certified gold partners. We love Microsoft's tools and this was built on the Microsoft deck. You've got ASP.net on the front end, and then a SQL Server Database again for the backend.
Now, why would I use a Content Management System, rather than build a website from a scratch? Well, there's a lot of functionality coming out of the box, and then in addition to that you can purchase a ton of different third party tools to further extend that functionality. To give you guys a couple of examples of third party tools you might be interested in using, there's some cool reporting tools. There's some graphing and charting tools tools. There's some tools that can be used to expose some parts of the database and allow the users is an easy way of getting in there and editing it. Couple other things worth mentioning. If you want to add a new page, it's pretty simple, you just go through a couple menu clicks and you get a new page on your website. And it's pretty quick and easy to get up and running. If you know what you're doing and you've done it before, you can get a DNN installation up and running in probably one to hours. So, if you look at the middle row here that's going to be the out of the box functionality. You've got that the DNN ASP.net side. That's going to be the typical front end. And then you've got of course the DNN tables on the backend. And then, if you look at the bottom row that's the custom functionality that we added on top of that. On the ASP.NET side, that's going to be the functionality that's going to allow the users to view and edit the recipe data. And then, in the database there's some custom tables were the recipe data are stored.
All right. So, let talk a little bit about how this data gets pushed over to all these PLCs all over the world. On the old system, you've got a PLC. And in the PLC there are several tags or registers in it that tell the system how to make that particular recipe. If the operator wants to change the current recipe, the operator would go over the interface select the recipe, and then, the interface will send all these values down and into the appropriate registers. The new system, if the operator wants to change the recipe it works somewhat similarly. The interface is still going to send the recipe number down to the PLC, but from there this custom code that we wrote that exist on this global server, reads in the recipe number. And from there it's responsible for making sure that all this data gets populated. On the same server you’ve got the database server and that's where pulling in that recipe table. But then the one challenge here is we've got plants all over the world and they’re all on different platforms. So, how do we talk to all these different PLCs? Through an OPC server. OPC is an old standard it's been around for quite awhile, the cool thing about it is it's an open standard. It support hundreds of different industrial platforms.
In this particular case the tool that we use for was Kepware. It's not the only OPC tool out there. It's just someone that we happen to choose. So, to give you guys a quick recap of this story, really the idea here is that we developed a solution for them that was cost effective. We didn't build everything from scratch, but we pulled in all these pre-existing pieces: the DNN website, the database, and the OPC server. And then there is a bit of custom code on top of that connects these altogether. It's a glue that holds everything together.
The last thing that I'm going to tell you guys today. This one's a pretty simple straightforward story. I think it’s kind of a fun one. The story is about us. It's an integrator story. So, at DMC going out on site can sometimes be a little bit rough on our engineers. Sometimes they spend a lot of time on site commissioning new lines, getting things up and running. To give you guys an example, my co-worker, Jimmy, his first year at DMC he spent a total of 43 days at our office. The rest of the year he was onsite living out of a suitcase. A couple years later, Jimmy was out at a chemical manufacturing plant and he was commissioning a brand new line. Now, it felt like he was getting close to being done. He thought he was going to be able to go home soon. And all that he had left to do was to test some of the IO and run through debugging a lot of the systems. I guess there was still a fair amount of things to do, but he felt like he was getting really, really close.
So, it's time to start testing the IO, and of course there's some IO issues. He goes up to the interface for pump one he pushes a forward button, and pump five runs in reverse. He tries to open up valve three and valve six closes. Now, Jimmy was getting concerned because it seems like he was just the tip of the iceberg. There hundreds of IO points on the system. It was a pretty complicated system. And all of this debugging of the IO issues was going to take quite a while. Now, the typical way he was planning on doing this would be to go to the controls try to activate a particular IO point, and then watch the system see what happens. This is going to be a little bit challenging because they were hundred feet away. And so what was originally going to be kind of a tough one person job looked like it's going to be a slow two person job requiring signaling back and forth across a loud factory floor. So, Jimmy was getting frustrated and he thought we was going to go home in a couple days, but now it was looking like it was going to be several weeks. Jimmy had a simple idea, that's pretty straightforward, it's an idea that we use in our office quite a bit. It's an idea that IT has been using for many years now.
What if you can take the controls and bring them to whatever system you're working on? So, how is this done? In this particular situation, the interface was running on Iconix and Iconix runs on Windows. All you have to do is use Windows Remote Desktop Connection, and you can have a mobile interface on your laptop that you can bring anywhere. Another cool thing about this is that there are apps for iOS and Android, so you can also do this on your iPad or your Android phone. So, Jimmy got the job done a little bit more quickly, and he got to go home. One cool thing worth mentioning here is that, the client actually liked this idea so much that they started using it themselves. When they bring a tanker truck in to bring in new materials. They've got to hook it up to the system and they've got to run some pumps in manual mode and watch the IO, and make sure that everything is happening right. Now, what they do is they've got an iPad that they bring out to the system, so that they can do it right there and keep an eye on everything.
Because this was done just simply because the system was running on Windows, this is something that you guys can do on any given interface platform that runs on Windows. Now, one other cool thing that I want to mention. I don't actually have a slide on this, but more and more were seen a little bit of these web enabled interfaces. Now, one cool thing if you think about what platform is this system is going to work on? If you have a web enabled interface or just a website in general it's automatically going to be cross platform capable. Any given system, again, your your iPhones, your iPads, your Android systems, any system that has a web browser is going to be able to get into that system. Again, this is a pretty simple story, the idea here is just using a simple connectivity idea for the purpose of convenience.
So, last thing I want to talk about today are some security considerations security. Security is a pretty complicated topic there's no single one-size-fits-all solution for, but it's certainly a hot-button issue these days. Security can be expensive. You can spend a lot of time and energy focusing on security. And when you're doing it, of course, you want to think about what is it that I'm trying to protect and what are the threats that I'm worried about? So, I'm not going to dig on to this too much right now today, but I'm going to give you guys three quick simple recommendations. Then I'm going to point you guys in the direction of some other resources, if you guys are interested in some further reading.
So, one thing that I would recommend, and you think this is obvious, but you'd be surprised how many clients we run across that don't do this. Getting the habit of backing up your control software all the time.
Back it up. Get people in the habit of backing it up anytime they make any change, whatsoever. In particular, I would recommend that you guys use some kind of archival system, or even would better would be a software repository. We ourselves use Subversion, quite a bit. There's a lot of other software repository tools out there. I think we've got a cool blog on our website that one of my coworkers wrote that talks about a custom tool that we made that will do this software repository for Siemens software. But the cool thing about a software repository is that every time you save to it, you get to log your data. You get to log the changes and put some notes of what you made. So, you can go back and look at the history and understand what each particular version does. And if you think about this, you might not realize that you made a mistake, or you've got an issue with your system tomorrow. You might not realize it for three months. You may not want to go back to the last version, you may want to go back to a version that's quite a ways back. And you'll have all that at your fingertips. The reason I would recommend, doing this. I mean, I may be saying the obvious here, but if you think about this, if somebody is getting to your system and do some mischief, the one universal thing that everybody's going to be concerned about, maybe you're concerned about IP, maybe not, maybe you're not doing anything particularly novel. Everybody's going to be concerned about downtime. Downtime is expensive and you back your stuff off it will allow you to get up and running quickly.
The second recommendation I would say, consider isolating from the outside. If it does make sense to open up your system, so that third-party or your global engineering team can get in there at a moment's notice. You probably want a lock that down via VPN, or maybe even a more secure authentication system. Just a quick note to be careful about Wi-Fi, keep in mind, anytime you get Wi-Fi people potentially can sniff that from outside your plant. And then again, looking at the pros and cons here, does it always make sense to have that system connected to the Internet. Maybe you can get quite a bit of functionality just by connecting it to some internal network.
The third recommendation that I would give you guys is to consider isolating from the inside. My guess is you guys are familiar with the Stuxnet virus from several years ago. To give you guys a little background here. I think the bleep here is that probably, either the Israeli government or the US government was was involved in creating this virus, with the purpose of infecting Siemens PLCs that run an Iranian nuclear facility. Now, how did this virus get in there? Well, the thought is that it got in there via a USB floppy drive that somebody plugged in somewhere, and then from there it had full access to the network. It was able to propagate and do quite a bit of damage. Couple other stories that have been in the news, I'm sure you guys heard about the Target breach where a lot of credit card data was stolen. And just over the past couple of days we've been hearing about a similar to breach with Home Depot. Also, within the past couple weeks there's been a story about a banking breach, where last I heard, the thought is that Russian hackers got into several banks. One of them was JPMorgan, and they were monitoring the stuff for quite a while and they were able to get a hold of some sensitive banking data. Now, the one common thing about all these stories is that, in my understanding is that, they all had wide open networks, so once somebody was able to get in via U.S. floppy drive, or a lot of these other cases via torsion that somebody accidentally downloaded in their office. These guys had unlimited access to everything, and if these companies had utilized subnets with firewalls as gatekeepers to keep people from being able to freely get from one place to another a lot of these damage could have been avoided.
All right. I'm going to give you guys a couple quick resources for further reading. The US Department of Homeland Security has a pretty cool website. Their industrial control systems cyber emergency response team website has a lot of cool industrial automation security resources. In particular, I'm going to point out a couple things there. If you guys go to their recommended practices page there's a lot of good documents there. One document that I'll point out, in particular, is the defense in depth strategies. It's like a 40 page document that gives a quick overview of a lot of these concepts. They've also got a page there that lists vulnerability by specific industrial control system or software. So, if you got a particular system that you're worried about and you want to know what mischief somebody might be able to do, you just go to the site. You can search and you pull it up. One thing that I'll note here is they not only talking about the connectivity vulnerabilities, but they also talk about the vulnerabilities that somebody was able to get to access to the system on your plant plant floor. Physical access.
All right. So to bring this discussion full circle here, basically as we frame the discussion through this definition talking about some of the reasons why. We went through a few stories and if you guys think back to the pros and cons list, sometimes it doesn't make sense to add modern connectivity, or be careful about what type of modem connectivity. But in each of these cases there were some pretty good benefits. So, I want to thank you guys all for your time today. And my hope here is that you guys each hopefully get to walk away from here with either some new ideas, or maybe just some new ways of looking at some old existing ideas. Thanks.
Bob: Thank you Matt. We have time for some questions. Any? We have one right here.
Female: Yes, just a quick question when you talk about the applications and the interface being mostly based on a Windows. Do you see right now any resistance in the market to Windows given some of the vulnerability Securities and around security? And do you work with any alternatives? So, when you talk about your remote desktop application...
Matt: Yeah. Well, like I've said before if you're saying by alternatives, if you’re saying an alternative that also offers some level of connectivity and mobility, we are seeing a couple different companies offering some web-enabled systems. So, if that's the case there maybe some risks here because, let's say, you're going to use it on an iPhone or an Android system. They may have some vulnerabilities as well, and anytime you've got a web-based system there could be some vulnerabilities there. But, yeah, I would say that's one potential alternative. I know Siemens has an offering on that. I know Rockwell has an offering as well one of their FactoryTalk HMI systems.
Bob: More questions. I've been waiting for a long time, Matt, to see Scooby Doo incorporated, in the way into a presentation. So, thank you for that. What do you see from a client standpoint in terms of their readiness to move to some of these ideas? We've heard in the last presentation that there are leaders, followers and then late adapters. Where do you see the market being strongest right now? What are some of the industries that are really kind of embracing this idea?
Matt: That's a good question. I'm not sure if I can speak on specific industries, but I would say the one idea that I'm seeing more and more is this whole idea of collecting data on what's going on, on your production floor so that you can maintain a consistent level of production and identify ways to improve production. I mean, it's all about cutting cost and staying competitive globally. But I think the big idea here is the more money people have to spend on this depending on what it is you're producing the easier it is going to be to implement some of these things.
Bob: We run into a problem with gathering data, but then the real trick is utilizing it and delivering it back to to the users and throughout the enterprise in a way that I can manage that. Where are the pain points in that process, because we've done a pretty good job collecting data and now we're trying to figure out where to go from there.
Matt: Okay. Yeah, that's that's a good question. I think a lot of that comes down to basically driving culture one way or another in the organization. If you’ve got people that are kind of used to just sitting on their hands, I think you are mentioning people who are followers. Sometimes that can be a problem. But, I think one of the big things here is visibility. I've seen some systems where they've got a large big screen TV that gives production data that's right in front of everybody's faces. I told the story earlier about the email of course as well.
Male 2: Okay. I have a question. I see a big presence on MTConnect in this IMTS. So, what do you see in MTConnect and OPC? Do you see its two paths and they’re running different ways, or you do see conversion in future?
Matt: That's a good question. I'm not familiar with, you said MTConnect.
Male 2: MTConnect. If you need, like, a huge boost there so on the machining. I seen mostly like EDM, CNC machine right now, and they provide MTConnect. MTConnect I think they are very similar to OPC UA but it's different. And I do see a lot of in-factory automation specially POC where see all the OPC moving to OPC UA. But there are so many different communication protocols out there. What do you see like... Is that going to be in the near future OPC UA will be dominating especially between machine and a higher level system, because its not that fast? So, we're not talking about real-time can show that all you would see, and I get co-existing of multiple protocols for the next five years.
Matt: I think. Okay. I'm not familiar with the MTConnect, so I can speak too much on that. I think in the industrial automation world you're always going to see a lot of different protocols across the board. You mentioned OPC UA. I think that's worth bringing up as well. If you look at it, as I mentioned before, OPC is a pretty old standard. It's been around for awhile, it's a little bit clunky. And OPC UA is an attempt to basically update it a little bit, but still maintaining a lot of that legacy connectivity. But I don't think you're going to see a huge convergence of this stuff. In my personal opinion I think, the the automation world is one where there's room for a lot of players and there's historically been a lot of different platforms and solutions for all these different problems.
Bob: Other questions? Well, Matt, thank you. That's a great presentation. We have a question at the back. I'm sorry. You're not done with your great presentation yet, Matt.
Male 3: I think to highlight the other gentleman's question too, is, have you been in touch or working with S99 and the ISA99 folks also?
Matt: I, myself haven't. I think I have some colleagues who have, but I can't speak to that too much.
Bob: I do know MTConnect is one of the open architecture programs that AMT is put together. And they have had some adoption success stories as well. I think as you said, there's a lot of solutions out there it's finding both in terms of industry and in terms of application. What's going to make the most sense for you. Any questions? Well, once again, thanks Matt for the presentation. We appreciate the opportunity. Matt, thanks very much.
Matt: Thanks guys.