Deploying the Digital Foundations of a Modern, Connected Factory

Speakers

Alex Godbehere

Technical Fellow

Advanced Manufacturing Research Centre (AMRC)

David Grussenmeyer

Industry and Education Engagement Manager

Inductive Automation

Digital factory architectures usually grow organically as business requirements evolve and new technologies are developed. Modern technologies and approaches such as infrastructure-as-code, containerization, orchestration, and edge-driven operations solve many problems presented by legacy, organic, point-to-point based architectures. This presentation will give an overview of Factory+, a Sparkplug-powered, open-access digital factory framework developed by the AMRC, and how it can be used to rapidly and reliably deploy, manage and scale the digital foundations of a forward-thinking manufacturing facility.

Transcript:

00:00
David Grussenmeyer: Hello everyone, and welcome to ICC X’s Virtual Conference. My name is David Grussenmeyer. I'm the Industry and Education Engagement Manager here at Inductive Automation. You are at today's session “Deploying the Digital Foundations of a Modern Connected Factory,” and I'll be your moderator for today. To start things off, I'd like to introduce you to our speaker today. Alex Godbehere is the Technical Fellow for the Smart Factories at the University of Sheffield Advanced Manufacturing Research Center. He's based in the AMRC's Factory 2050 facility and specializes in Industrial Internet of Things, technologies, and connectivity architectures for manufacturing environments. Alex is co-author of the FactoryPlus Specification that outlines an open framework and best practices to standardize and simplify data across a manufacturing organization using modern, scalable, and secure technologies. Take it away, Alex.

00:57
Alex Godbehere: Good morning all. My name is Alex Godbehere, and I'm the Technical Fellow for Smart Factories at the Advanced Manufacturing Research Center. I'm going to use the next 30 minutes or so to give you an overview of the AMRC, what MQTT and Sparkplug is, and how, with Ignition, it solves some of the connectivity challenges that we encounter as a research organization. I'll also touch on a piece of research that we've been working on for the last couple of years that helps define a standardized open-access framework for how we deploy modern technologies into a manufacturing environment.

01:43
Alex Godbehere: So a little bit about us. So the AMRC is a partly government-backed not-for-profit research organization based out of the University of Sheffield, over in the UK. Our main aim is to take low-level, relatively unproven conceptual research, which sometimes comes directly from the university, and de-risk it in such a way that it reaches a sufficient level of maturity to be adopted by industry. Our research typically tends to be relatively cheap to prove out and develop in a lab-based environment, but it can be expensive to de-risk and mature, and typically academia can't afford to do that development and de-risking to a point where industry are prepared to adopt it. So there's typically a bit of a disconnect. And what we do is we act as an intermediary to try and develop and align the research to a point where our industrial partners are prepared to adopt it. We effectively make the mistakes for them but in a safe but representative environment.

03:12
Alex Godbehere: Now, we've been around since 2001, and we consist of around 500 active research staff. We specialize in areas such as machining, composites, materials casting, structural testing, and probably most relevant to this torque is research into the Industrial Internet of Things and Smart Factories. Now we come from humble beginnings. Now Sheffield has an international reputation for metallurgy and steelmaking. And the site that you're looking at here is the former site of an open-cast mine. And this mine has historical significance here in the UK. It was the site of the Battle of Orgreave. It was a violent minor strike back in 1984. There were around 6,000 police deployed and they made around a hundred arrests. And from that point, mining and the steel industry started to leave the area. And what that resulted in was high unemployment rates but plenty of skilled workers.

04:31
Alex Godbehere: So this site was earmarked for redevelopment back in the early 2000s, and we were the anchor tenant on that land, in a bid to try and attract others. We opened up this research center, which you can see here circled in red back in 2004, and that land cost us one pound. Fast forward to today, that same building is still there. But we've got quite a lot of other buildings and facilities surrounding us now. We opened up the what we call “The Factory of the Future” back in 2008, and that's where our machining group and composites teams work from. That land cost us 200,000 pound an acre four years later. We then opened our Dedicated Composites Center, our Knowledge Transfer Center, and the Nuclear AMRC in 2012. At this point, it cost us around 400,000 pound an acre. So it doubled again in four years. In 2013 and in 2014 we opened our castings facilities and our training center, which trains apprentices up to degree level. And as we've grown over the years from a few people in a shed to a research center with a footfall of around 20,000 people through our doors a year, we've had a number of notable neighbors move in next door. So you'll please see on this diagram McLaren and Rolls-Royce highlighted there, and they chose the location for these production facilities that they're not research centers, they are production facilities, and they chose the location due to the proximity to the AMRC's research.

06:34 
Alex Godbehere: When it came to further expand in 2015, we realized that we had priced ourselves out of this land. We couldn't afford to build on it anymore. So we migrated across the road, which you can see on the right there, to the other side, which was the old Sheffield City Airport, which you can just see in the bottom right corner there. You can probably still see the footprint of where the runway used to be. And the university purchased this entire site, so we now control the land over here.

07:07
Alex Godbehere: In 2015, we built Factory 2050, which is where I am based, and there are a number of other university buildings scattered around the perimeter as well, and they're focused mainly at low-level research. You can also see Boeing in the background there, so that is their first production facility outside of the States for Boeing, and we're honored they chose to build it alongside us in Sheffield. So much of our research has its origins in high-value manufacturing, which typically and historically was directly applicable to sectors like aerospace and defense. But nowadays, we're seeing a lot of what we call translational research, so research which is applicable to other industries as well, like rail, the energy sector, construction, civil, and medical. And it's probably worth noting as well, we have a number of other centers scattered around the UK, so we have one in Wales and one in the northwest of England, and the idea behind these centers are to take our research to partners who already have established manufacturing facilities in those regions.

08:22
Alex Godbehere: Now a little bit about the reason why we exist. So the manufacturing readiness level scale is a scale which defines the maturity of a particular technology for application within a manufacturing use case. And what typically tends to happen is ideas are cheap to develop, prove and test in an academic environment, but they become quite expensive to de-risk and mature to the point where industry are prepared to adopt them. So the idea is the AMRC acts as an intermediary to try and bridge this gap, and we work by having one foot in the academic camp, and we work closely with the universities, being part of one ourselves, and we have another foot in the industrial camp where we have a number of partners which we work with to guide the research.

09:31
Alex Godbehere: Now the AMRC's involvement in and the kind of work that we undertake is largely dependent on the manufacturing readiness level of the technology in question. So if a partner comes to us with a manufacturing challenge and we know that an existing integrator can do that work, we will link them up with one of the integrators from our partner network, and we'll be there for support throughout that journey. If we know of an integrator who can do it, however, they require maybe some guidance, or it's in a field they haven't worked in, or the technology needs development or refining, we can then conduct a project alongside the integrator, and the their partner and we can develop the research in the safe environment of the AMRC.

10:27
Alex Godbehere: And if it's an idea, or a concept, or a technology that hasn't been used before in manufacturing, or it's low MRL, we perform core research within the AMRC. I'm not going to dwell too much on this slide, but this represents a summary of findings from a recent independent report on the economic impact that the AMRC has had on UK manufacturing, and we're incredibly proud of this. So on to something maybe slightly more relevant. We're not a production facility at the AMRC. Our primary export is information, it's knowledge, it's intellectual property. We, like most other companies in the manufacturing sector, have our challenges around OT connectivity and digital communication across the organization.

11:28
Alex Godbehere: We have a whole host of weird and wonderful machines, rarely any two are the same, and we frequently use the data from these machines for research purposes. And we're proud to be at the forefront of research and technologies like digital twins, big data, and AI, which is great, but all of these enabling technologies need data from somewhere. Which is typically shoehorned into consuming applications via a plethora of connections hosted in an architecture that looks something like the diagram on the left, which we're guilty of ourselves in the past, and this got us thinking. Like most, our digital requirements grew as we grew, and coupled with the rapid acceleration of new technologies and low-powered computing, we had an architecture which resulted in plenty of point-to-point connections. It was an organic architecture which didn't scale. It was almost Frankenstein-like. We bolted new solutions on as they became available. And this mesh of point-to-point connections usually spoke different languages, different protocols, and it simply wasn't fit for purpose. Not only from an operational perspective but also from an organization who people look to for best practice.

13:16
Alex Godbehere: So we wanted to standardize this, and we wanted to document that journey. Hopefully, so others could follow in our footsteps for the things that went well and prevent them from making the same mistakes as we did. So we did quite a bit of intensive research, and we came up with three main cornerstones of the architecture that we would like to deploy. And it became quite quickly apparent that these three principles if we adopted them, would result in a lightweight scalable performance architecture. So we'll explore each of them in detail. So the first one, which is report by exception, and this is the concept of not polling a device or a machine or a piece of software for its status and its values, but instead letting it know that you are interested in that data and allowing it to tell you when it changes.

14:27
Alex Godbehere: So this approach is sometimes referred to as publish/subscribe or pub-sub. And it typically uses considerably less bandwidth than a poll/response architecture. And the reason for that is if you're polling a device, which isn't changing, you are generating network traffic even though you're not gaining any new information, any new insight to the states of that device. 'Cause the value hasn't changed. And theoretically, it allows poll and response and... Sorry, report by exception allows for a higher resolution data than poll/response. And the reason for this is if you are operating over a relatively bandwidth-constrained network, you have to make a trade-off between how often you're gonna poll that device and the network bandwidth that you have available. So you are sacrificing frequency at some point down the line. You're saying, "I'm gonna poll this device once a second or once a minute, or once an hour or once a day." If the values change within that window, you only ever get that final value. Whereas with publish and subscribe, you get every value change regardless of your nonexistent polling interval.

15:50
Alex Godbehere: So that was principle one, report by exception. Principle two is the concept of connecting to infrastructure rather than lots of point-to-point connections between devices and applications. And the kind of the latter architecture, which as said, we are guilty of in the past, would look something like this, where everything that wants data and everything that produces data speaks to every other actor in the system, which you can already see this is very difficult to maintain. It doesn't scale very well. And it becomes increasingly difficult to secure. So each of these connections is speaking, if not a different protocol, a different version of a protocol, more likely. So the idea is we compare this to an architecture where we can connect to infrastructure instead.

16:52
Alex Godbehere: So the analogy that I like to use here is, imagine if every time you want to go to a website on your laptop or your computer, you have to create a new connection using a new cable to their servers. So you want to Google, you plug into Google servers. If you want to go to the BBC website, you plug into their server, and so on and so forth. You'd end up with hundreds and thousands of connections, which isn't scalable. Obviously, you don't do this. You connect to the internet, you connect to an infrastructure. And that's what we're trying to replicate here. So the second principle with connect to infrastructure, the third one is be edge-driven. And this is largely coupled to the report by exception concept, which I mentioned first. But the idea is allow clients to initiate the connection, allow them to tell you when their data changes, which is ideal for low-power devices. They haven't gotta answer the same question a hundred times a second to a hundred different people. And it's more secure because it's client-initiated. There's no open firewalls inbound to that device.

17:57
Alex Godbehere: So we have connect to infrastructure, report by exception, and be edge-driven. And the technology that suits these very well is MQTT, which you may be familiar with. It has its many uses across many different industries. It's used in Facebook, I believe, for the messaging system, but it was originally created by Arlen Nipper and Andy Stanford-Clark for use in an industrial environment. And that was for the Phillips 66 pipeline. And industry started to see the benefits of MQTT more recently and started to adopt it, which is fantastic, but they all chose to implement it differently. And by definition, MQTT was designed to be flexible. It wasn't designed to say how you use it. It was just a way of transmitting data efficiently. So the analogy I like to use here is with MQTT we've got a way of communicating. We've got the use of, let's say, the telephone, but the problem is we both speak different languages. So I speak French and you speak German, so we can physically hear each other, but we can't understand what we're saying, and that was a problem that we saw with an industry with everybody implementing MQTT differently.

19:16
Alex Godbehere: So enter Sparkplug. So Sparkplug is effectively a specification that lays down the rules of how to use MQTT within a manufacturing or industrial environment. It defines a payload definition, it defines a topic structure, and it defines a state management model. So going back to the telephone analogy, we both have the use of a telephone over MQTT, and we now both speak English. So this is where our initial research got us to. We've got MQTT and we've got a theoretical way to deploy it in industry and best practices based on Sparkplug. Now what? So Sparkplug does a great job of saying what, but by design it doesn't necessarily say how.

20:12
Alex Godbehere: So we took these two specifications, and we embarked on our journey to deploy that within our facility here in Sheffield. And what came out of that was Factory+. Now Factory+ is a completely open-access standardized connectivity framework, which defines how to practically establish a Sparkplug-based architecture within a manufacturing environment. Now I won't dive deep into the specifics of Factory+ here. There's a link to the public-facing website. There, there's also a QR code, but in short, what it does is it standardizes the way that we connect to machines within a manufacturing facility. It standardizes the way we connect to applications within a manufacturing facility or organization. It normalizes and standardizes the structure of the data itself, and through a layer of Factory+ called the Consumption Framework, it also standardizes the way that we can consume data by things like digital twins, dashboards, and other applications.

21:26
Alex Godbehere: Now, the framework itself, yes, it says how to use MQTT, what it is, how to deploy Spark-plug, but it also covers a lot of ancillary things like network infrastructure, containerization, orchestration, infrastructure as code, data schemers protocols, and encoding, which is part of Sparkplug, how to manage devices, how to configure edge connectivity, Historians, short-term, long-term storage, sending and receiving commands, and a whole host of other things. The idea is that Factory+ is a start-to-finish manual for deploying Sparkplug within a manufacturing environment.

22:13
Alex Godbehere: Now those of you familiar with Ignition will be aware that it has the capability to, through the modules offered by Arlen and his team at Cirrus Link, to act as the Sparkplug primary application. So Ignition keeps track of the entire MQTT namespace, it issues commands, and it provides our engineers with a platform to interact with the smart factory, for us and within Factory+ and the framework, Ignition really puts the word “smart” in smart factory.

23:01
Alex Godbehere: Now, before I wrap up, I want to kind of provide you with a little bit of a glimpse of where we're going. Now, Factory+ already offers the schemers, the edge connectivity, the network infrastructure, and so on and so forth. But what we're doing is we're actively working on developing solutions to enable Factory+ built on Sparkplug, MQTT, and Ignition to become a complete open end-to-end connectivity and smart factory platform for manufacturing. And for us, Factory+ has really enables a culture change within our organization. So previously, data lived in silos. Connectivity wasn't standardized. It wouldn't be uncommon to see somebody sending an email asking if they've ever connected to a machine before, or where they stored the data, or how they processed the data.

24:07
Alex Godbehere: Those questions have been replaced with, okay, what manufacturing problems can we now solve? And from an operational perspective, the weeks of work connecting to machines, collecting data, storing the data, standardizing the data is already being done for us by Factory+ before we even know that we need it. And we're excited to see where Factory+ goes. We're excited to see how the community uses it and helps us develop it, and we're extremely proud to be leveraging Ignition as the beating heart of Factory+. So I appreciate that was a bit of a wall of information, but hopefully, it provided some food for thought, and we are gonna stick around for some questions now. So, feel free to ask away. Thank you.