The popularity of terms such as “digital thread”, “Industry 4.0”, and “Industrial Internet of Things” (IIoT) is emblematic of the technological advances in (and reducing costs of) sensing, computing, digitalization, data storage, and analytics. Additionally, Industry 4.0 is pushing manufacturing to become more distributed, intelligent, and with autonomy at the cell level. Driven by these advances and motivations, manufacturing is becoming more digitally integrated than ever, enabling new insight into production processes via data directly captured from PLCs, sensors, and signals at the process and machine level. In response to the aforementioned challenges and ever-advancing state of the technology many open questions remain around how these various industrial systems should integrate and how they provide meaningful and actionable information using open standards and technologies in an intelligent autonomous manufacturing cell. The proposed reference implementation will be a self-contained (yet extensible) manufacturing cell with a dedicated digital infrastructure and capabilities for running micro-services at the edge. The cell will be comprised of a heterogeneous set of equipment that can perform a set of individual process steps and can be automatically adaptable to variations in part designs, process flows, etc. The cyber-physical testbed will enable industry partners, standards organizations, and government partners to develop, test, and demonstrate new technologies, prove functional concepts, and test use cases that relate to flexible and distributed manufacturing processes. This project is in part funded by the National Institute of Standards and Technology and project partners include Cisco, Hurco, Mitutoyo, and Simplimatic Automation.
Transcript
Tim Bakker:
Thank you everybody. Thank you MT for hosting this and having me on here as a speaker. I very much appreciate the opportunity. I'm Tim Bakker. I'm the research manager for the intelligent factory and the data science teams over at CCAM which is the Commonwealth Center for Advanced Manufacturing. The main topic is really flexible manufacturing, but I'll do a quick introduction into CCAM as probably most people here in attendance won't know what we do and how we're set up. So, I go through the introduction so you can hear. We're a research center in central Virginia, about 30 minutes south of Richmond. This is our beautiful building over here that was built in 2011. This building itself has facilities for office space and event space, but also has a significant high bay where we have equipment and materials for the research, the advanced manufacturing research that we do at CCAM.
Tim Bakker:
The research at CCAM is mainly driven by our members which are industry or university members. And here is a highlight of it. It's a pretty rich and diverse environment where we have really some big names on the board. But we also have university members as part of CCAM, and then some of the American Makes Institute where we are partnering with as well including we're on the MTConnect working group and the stand up groups there as well. It's a rich environment and we're bringing here technologies together that some of these members can bring together to facilitate projects and solve our real world manufacturing problems. It's real exciting to sometimes be able to really bring these two partners together and work out on a project and come to some a solution for the problems that they bring to us. We have four main research projects. Two of them is additive and subtractive manufacturing, and then we do a lot of work in our surface coding research for some of our main members like Rolls Royce.
Tim Bakker:
This service characterization work that we're doing is mostly focused on bit blasting in the plasma spray cell that we have at CCAM where we do all kinds of investigations for process development and characterization of the samples that we're spraying for our members. On the left is our automation group. And part of that we have robotics, we have sensing and vision, and then we also have intelligent factory. And the intelligent factory is mostly working on Industry 4.0 and digital factory related technologies, pushing that forward for our members, for our projects that we do with our members, and then we also have the opportunity to work with external agencies like NIST to really progress digital technology standards in Industry 4.0 as a whole forward.
Tim Bakker:
So then, I'm going to transition to the project that we're doing and the vision behind it. So we're talking here about a distributed manufacturing, and I'm going to try to highlight a bit what we're thinking about what the vision is, what are some of the challenges, and how some of the project that we're having with NIST, how that addresses some of these challenges. So, only I'm not saying that we're going to solve the world here with our project, but we're certainly addressing some of these specific problems that we're highlighting here.
Tim Bakker:
So the concept of distributed manufacturing, I want to start off, is that the world and everybody in it is flexible. And the biggest example of it was now with the pandemic where people adopt to their surroundings, adopt to the environment, adopt to roles. Discreet manufacturing is no different. They adopt to these challenges too. They do things differently to still be to still be in business there. So you see a much more lights off manufacturing where people are working from home manufacturing facilities keep working on with remote assistance and maintenance capabilities there. You see the shift in demand where we're not building these airplane parts anymore, but we're now we're building parts for the healthcare industry. We're toiling. We're making face shields, we're making face masks, syringes, everything.
Tim Bakker:
But also we see more demand on, can we manufacture on demand, and in response of an emergency situation. We've seen our disasters over time here, where we had a need to be at site of the disaster to be able to produce parts that were too tough to fly in or to transport them. So all of those lead to the notion of can we build flexible manufacturing cells that are distributed, that can work autonomously at location where we would need that capabilities. Really good example is our military in their problem of sustaining the military fleet. [inaudible 00:06:37] at the very beginning already said, "Our equipment and our airplanes are in operations for 30 years." And we have to sustain these. We have to make sure that we can still provide parts, et cetera.
Tim Bakker:
So, that's an increasing car for our military to produce these parts. These parts back in the days from the airplanes for manufacturing, the whole facility was set up to build these parts. Nowadays these facilities might not be able to build these parts, and it's just a hassle to repair these pieces of equipment if you don't have the parts available. And then we see a high cost of repairing and qualifying parts. So, where we knew how to qualify a part back in the day, now we have to somewhat reinvent the wheel, and are there ways that we can simplify that process and make it easier and more cost effective. So, what we're thinking about when we talk about these decentralized manufacturing is the ability to use global infrastructure to manufacture. Everything becomes more globalized in the world, including transportation and logistics, but also the manufacturing should look at how to globalize their efforts. And decentralized manufacturing is the idea that we have all these manufacturing facilities basically work together to solve manufacturing demand.
Tim Bakker:
So, we can do it at location, so that we can reduce transportation and logistics, and also that we can really do rapid response. If an military airplane is broken in South Korea, can we fairly easily built that part in our forward facing facilities and build the part and get the airplane as quickly back in the air. We want to look at how can we make this easily, how can we deploy these manufacturing cells easily where we don't a lot of infrastructure to build this up, where there's not a significant cost to overcome to build a local flexible manufacturing cell, and can we scale that? So can we go from an single manufacturing cell to having a distributed manufacturing cells where we can connect all of them together and then work with them together as well, where site A can do a certain part, site B can do another part, or maybe site A and B need to work together to build the final part. So there's a lot of challenges and a lot of vision there to overcome, but that's what we're working on.
Tim Bakker:
Lastly, can we enable small manufacturing facilities to participate in this setup here as well, so that we provide additional opportunities for them to manufacture parts where they otherwise would not have the infrastructure set up, they wouldn't be able to meet the qualifications and the certifications necessary to build some of these parts. So, some of the main challenges and again, there's many more challenges, these are some of the highlights that we are addressing in part of this project here is translation off the process. Can you if you want to build a part at a site A, can you confidently say, "Oh yeah, I understand the process. I can build this part as well on site B." And that requires to know the process very well, that requires to know the key process variables to key process indicators and to be able to monitor those and control those. So that's a big area of research and improvement that we're ongoing with.
Tim Bakker:
Other thing is although we've seen in the last decade a significant shift here from proprietary standards to open standards and AMT is a great example of that with their MTConnect standard, but still the discrete manufacturing, the standard stares is a lot proprietary standards. There are other ways that we can overcome that with the open standards that are available and that have gotten traction in industry there. As I mentioned before, costly investment in the digital infrastructures is a big challenge. We are dealing with legacy equipment, we're dealing with shop floors that don't have a good OT infrastructure there to connect the machines up, that don't have the required security and firewalls in place to collect all of this data and do it in a safe environment. So there's a lot of work to be done there, and that comes with a significant price. And then can we build a flexible standalone cell that is efficient and cost-effective, that can produce a high mix, low falling parts. And that by itself is a challenge too to be able to do that and still be cost positive there.
Tim Bakker:
So, longterm vision and somewhat some of the solutions is to apply digital tread count steps, the ability to connect your machines, to capture all of the digital data, to understand what digital data you need to capture as part of the digital twin or part of the digital tread concepts there. What is the information that you need to know to control your process, that you need to know to verify that you have a correct process, or you have a correct part at the end of it? There's a lot of questions still to be answered there. And it's not going to be overnight. We're all working towards answering some of these questions, and the project with NIST just takes a small, tiny slice of that as well. Apply open standards. So as part of the project, we want to look as much as possible to open standards that are readily available that have proven themselves already in industry so that we don't have [inaudible 00:13:43], so that we don't have these high costs associated with setting up an automation cell.
Tim Bakker:
And it also improves adoptability and integration with existing systems. And over time that only becomes better if more industries and OEMs are starting to adopt these open standards. Last point here is we want to drive intelligence in operational management to the cell. We don't want to be relying on an MES or an MLM solution to drive the control of the cell, the cell itself should be semi-autonomous and should be fed with an order from the outside and after manufacturing and metrology a qualified part will come out. So, that is to increase the ease of deployment and build these distributed, flexible cells across all these different manufacturing facilities.
Tim Bakker:
The intelligence comes in where we might want to rework parts. We had a great talk about the error proving upfront, which is really good if we can reduce that. There's still always going to be needs to after the fact measure the part and rework the part if that is still an option there so that we can reduce scrapping, and we can improve quality of a part. Equipment starts to degrade over time, a good example is cutting tools, they degrade over time, they don't produce always the same cut after time and operation. Can you adapt to that? Can you bring that back into the cell and eventually produce a quality part out of the manufacturing cell there? So coming a little closer to the project that we have with NIST, which got awarded in late 2019 where we're building this intelligent, flexible, manufacturing cell that's going to address some of these challenges with the solutions and the efficiency that we provide.
Tim Bakker:
Project objective is to really develop this intelligent cell that is semi-autonomous, and that can produce a certain range of parts and actually can say, "Yes, we have controlled the process, and thus we have done our metrology, and we build a qualified part at the end of that. And then with that capture all of the digital thread, the process monitoring, the metrology data, capture all of that and get that associated with the part. One critical aspect there that I hadn't mentioned coming back to the translational part in earlier slides, one really interesting challenge there as well is, can you build confidently a family of parts where if you are trying to build a certain variety of brackets, can you put them in a family of parts, can you qualify the process around that family of parts so that you don't have to go to a rigorous certification steps and quality steps to ensure that yes, the cell can not only build part A out of this family, but certainly can build part B out of this family as well without too much upfront costs for evaluation and analysis of the process itself.
Tim Bakker:
All of those are questions, not sure if we're going to be able to address all of that as part of the cell, but we're certainly trying to work towards that. As mentioned we're trying to leverage the Industry 4.0 standards and the open standards that have really shown their strength in industry, and that are up and coming. I'll go dig into that a little bit later in the slides. We want to drive the economy into the shell. It should be as much as hands-off as possible, where just an order gets placed, this order gets then turned into production orders and AP242 documents, and from there everything basically starts to work and we'll build this part. And as we have challenges with our ITOT infrastructures and the security around it, we want to address that in our shell here as well. Can we build a secure environment that can be easily deployed in a shop floor that is seen as something that by itself provides enough security to remove any hesitations there.
Tim Bakker:
So, the project itself is really a reference implementation of flexible manufacturing cell. And then the idea is that we will build up on this implementation in the future through of our members, through some of the external members through NIST, and really built new use cases in this cell and add technology and equipment to further build out its capabilities and functionality. So actually as I mentioned, we're working closely with NIST on this project. They were at this project to us in 2019. Initial collaborators for this project is Cisco. They provided all of the network equipment as part of this cell. We have MiSTAR 555 Shop Floor latest model metrology equipment from editorial, and then Hurco has provided us with a small CNC machine, but really perfect for the use case that we have in mind.
Tim Bakker:
So, we're we're in year two right now, year one was really building up the cell, building up the digital infrastructure with the open standards and some of the technologies that I'll highlight in the next section here. And then year two and three really, the idea is to expand the cell, to reach out to OEM's industry members and understand what they would like to see out of this cell, and figure out if we can bring some of that into the cell and build onto the technology. So, some of the open standards that were highlighted as part of the stele, and we've seen them before, [inaudible 00:21:16] briefly mentioned these as well in his speech, was step AP242, which is a really good, comprehensive standard that works really nicely with the other step standards like AP238, and it's really there to do the product data management for us, and so go from a work order, to process definitions, to operator jobs, et cetera, including all of the cat cam information inside of this standard hair swell.
Tim Bakker:
So it really stretches a long section of our manufacturing cycle that we want to leverage the AP242 standard for... What it doesn't cover is really the metrology side of manufacturing. So, for that, there's the Quality Information Framework, QIF, that really can hold all of our inspection and planning rules for our metrology set up, and then also can hold all of our metrology information so that later that information can be analyzed, we can create some actionable data out of that that can drive adaptability back into the cell and change adapt to changes in the process, adapt to changes to the equipment, et cetera. MTConnect is our semantic vocabulary. We're really happy with the standard and how it has evolved over the last year together with the OPC UA companion spec, we think it's a really strong standard that is really going to be a driver for the future in discreet manufacturing.
Tim Bakker:
In our cell, we don't only use MTConnect for the semantics to place on tax and process data. There are many additional sections of the MTConnect standards that can be used to describe the state of the machine, that can describe state machines in our overall supervisory control system. So we're using MTConnect as much as possible to drive vocabulary, to drive semantics into our overarching functional system there. And then we use it as the modeling. With its modeling capability, we're using MTConnect there as well. OPC UA, I mentioned it here, we do not have that as of right now inside the cell. Certainly I put it here on the slides because we can go around it and together with the MTConnect companions pack, it's a key driver for the future for machine-to-machine communication. You'll see we are not using OPC UA, but we're using some different technologies there to be that middleware and communication layer. But there's certainly an opportunity for us to use OPC UA where it is good to use, and where there's the opportunity.
Tim Bakker:
So, some of the more controversial technologies that we're using inside the cell is almost all explicit open-source technology. Again, we want to come back to something that is easy to deploy where we are using open-source technologies to drive the cell where we don't have [inaudible 00:25:13] and where we don't use proprietary technology to drive the cell here. So, these are the open source technologies that we're currently embedding in our system here. So we're using Kafka, NiFi, and then we're using OpenFaas, which is a server-less compute platform. And I'll come back to that, it's like, "How do we use that, what are the functions for that, that help us build up this cell?" Certainly there's still a need to use some proprietary software out there. We are using Siemens NX to drive our CAD CAM designs, and similarly where you're using Mitutoyo's MiCat Planner measuring link to plan the metrology and also to analyze the data that comes out of the metrology measurements there.
Tim Bakker:
But again, we're going to go as quickly as possible to the open standards there such that we have really well-defined boundaries of where we are using these commercial software packages. We certainly see that a lot of these proprietary, or these commercial software packages are very hard on working to support these open standards, and they're developing these as we go, and one of our objectives as well would be tutorials to actually provide them some feedback on, "Okay, this is working, this is not working, how can we improve it, or what is the use case behind certain functionalities that we want to further explore?" So, a quick overview of our manufacturing cell. So, the 3D rendering here on the left bottom, of course, so we have on the left side there MiStar 555. That's the latest Mitutoyo Shop Floor machine, a really capable piece of equipment, love to work with, it's a really a nice, good piece of equipment.
Tim Bakker:
We have a Hurko VM10i, that's a three axis CNC machine. We have a collaborative robot there in the middle which is driven by MIA 200. And then on top of that is a UR5 robot that's basically going to tend the CNC machine and the Mitutoyo MiStar 555. And then on the right side, we have our Cisco network equipment to really facilitate network functionality, but also firewalls and edge compute capabilities. Quick overview of our network architecture, fairly simple. We have a Cisco firewall, that provides our secure sandbox and really provides us a way to build this and deploy this in an OT infrastructure with minimal hassle with our IT people because they understand that there's a firewall there. They understand that there's a sandbox created underneath it that is well protected.
Tim Bakker:
We have an ethernet switch here provided by Cisco, we have some wireless access point to connect to the mobile platforms there. And then we have our compute edge model. And this is the IC3000 by Cisco. And a lot of the infrastructure that I mentioned before, the Kafka, OpenFaas, Docker containers, it's all deployed on this edge module again, such that we built a contained flexible manufacturing cell that has all of the capabilities inside to run this cell here. Our system architecture, so we have the devices here at the very bottom, and then this is the architecture that we're building up. And so the designs are here, we're now really in the face of, "Okay, what are some of these high-level blocks here that needs to be filled in," and we're developing all of these interfaces in these systems right now using the technology here. And then we're doing a lot of software development there as well to basically tie all of this together.
Tim Bakker:
We're using a Kafka basically as a middleware to connect all of these systems up from the process data that we're getting through NiFi, streaming that out to our database for longterm storage there. Database doesn't only hold process data, we'll also be holding our AP242 standards, files, our QIF information and also our part record that we're going to maintain in there. OpenFaast, I have a slide on that later, I'll come back to it, how we're using it, what it is. What I want to highlight here on the right side is that we have a supervisory control system right now that basically drives all of the components of the shell. So, when a part comes in or an order comes in, this order is going to be pulled apart, and the process definition is going to basically outline what jobs are going to be issued to the different pieces of equipment and hardware that we have in the cell. And then the supervisory controls system will basically ensured that the part is going through all of these jobs sequentially.
Tim Bakker:
So, why not highlight that edge module? I had a pleasure to work with this and really set it up and develop the applications for it. Cisco, this is, I find, really one of the most valuable pieces of equipment out there. It's so easy to use, it's so easy to develop on, and it's really a great little box there. It's industrialized, so we don't have to worry about any IP rating or have it in another closure. It's really neat. You can use a Docker containers on it, you can deploy full blown virtual machines on it, it has support for Linux containers there as well, and they have a great software environment for it to really get you started quickly and deploy some applications.
Tim Bakker:
Some of you might be familiar with Node-RED. We have Node-RED running on there as well to facilitate some testing and development as we go along. So, Apache Kafka maybe you're familiar with it, it was initially developed by LinkedIn, and then it was open-sourced to the Apache foundation there where from there it was further developed into really a solid opensource product that is being used by industry all over the place. Mostly it's used in an IT environment versus an OT environment, and that is somewhat new here. We think that the technology translates and so far it's been perfectly fine. Normally it would be more a cloud-based solution, but with this technology bringing that to the edge, the idea is that we can now bridge the edge to cloud fairly easily. Through it's a replication systems we can easily replicate the data that we collect inside them cell, we can easily replicate that over into cloud infrastructure.
Tim Bakker:
And then that's when we start thinking about distributed manufacturing where some of this data still needs to go to the cloud since we have control and monitoring capability over the process itself. Some key features of Apache Kafka itself is the ability to do permanent storage, the high performance and scalable and low latency functionalities that you have there, you can easily build clusters of Apache or Kafka instances and link them together and you have now a high redundancy and also high performance there as well. It's a typical publication subscription service, so if you've used MQTT or something like that, it's pretty much fairly straightforward in that sense to push data and to get the data out of it.
Tim Bakker:
And it's got a very active community out there. People are heavily developing and making the system, making the making Kafka better. And we see adoption mostly in IT world, but there are some instances and examples out there where Kafka has been used in more of an IOT environment where it was used to collect sensors from the field. So, it's a research project. We'll have to go about and see if this really works out, but so far it seems promising of using Kafka very close to the shop floor and to the edge. Not a great software tool, or at least in my mind is a Apache NiFi. This was originally developed by NSA and open-sourced in 2014. It's official flow-based programming environment, and if you're familiar with Node-RED, then some of this might look familiar there.
Tim Bakker:
But it does have a different functionality or purpose. It's really to do to reroute traffic from one source of information to another system that can ingest data. So, we are using that for our purposes to pull all of the data from our machines and push that over to our Kafka middleware there. It's not meant to do a lot of functional logic where Node-RED has more capabilities, but NiFi is very high performance. There's some really great benchmarking out there where they're just consuming a lot of data and being able to transform it and then push it back out there. So, one example here is we want to work with JSON data versus XML data that the MTConnect agent normally spits out. We're using NiFi to transform this and then spit it back out into the Kafka middle layer as JSON data. It's scalable, they have capabilities to put multiple NiFi instances together. So, even when we would want to go into distributed environment, then we see the great potential to use NiFi there as well to scale this system up. And it's has a large library of processes, functionality to really connect to any kind of data source. Might it be a database, might it be an MQTT broker or any kind of data source broker communication interface that you have, NiFi will be able to connect to that.
Tim Bakker:
So, moving on to server-less compute, and this really has been a really nice side project for for myself. And I've put a lot of interest into this capability. So you might be familiar with AWS Lambda which is a server -less compute platform provided by Amazon. OpenFaast which we're using in this project is a similar functionality. They provide scaffolding to run functions inside of their framework. You really only have to focus on writing the functions itself and logic inside of the functions, and then you can basically upload this to this platform, and then you can trigger these functions when you have data to be used by these functions when you need these functions to actually work. And the platform itself will do scalability, we'll scale up to using more resources, we'll scale down if there's less resource demand on.
Tim Bakker:
So it's a really unique way of deploying functionality inside of a cell that's really asynchronous. One application and use case that we have inside the cell is to do the rework of the part where we're using metrology information to infer what the state of the part is, what has happened during the machining cycles there. And if the part is out of specification, what can we do to rework the parts that so we get a good part at the end out of it. But this functionality of analyzing the data and then spitting out some actionable information that is then deployed in a server-less compute platform like OpenFaast.
Tim Bakker:
Typically, these functions are fairly small. The microservices, they run for maybe a second, and then they're done. And then they go idle for a long time and they're not in forks. So these platforms are great for that kind of functionality. But again, these are platforms that you normally see deployed in the cloud infrastructure and not so much on in a manufacturing cell. But we think there's a good use case here for it, and we're working to is this really going to work or not? Again it's for us exploratory work here that we're doing. So, coming towards the end of my presentation here, currently we're in the second year of our project, equipment has been commissioned, our digital infrastructure, most of the components there that you've seen have been deployed, all of the high level frameworks are deployed, we're working on the lower implementations of that, the connections to the machine, the control of the machine, we're working on the rework portions of the cell there, but also on how do we collect the data, how do we create these AP242 records, how do we create QIF records, et cetera. So, that's really our focus right now, so a lot of system design and software development.
Tim Bakker:
Lastly I wanted to reach out to project partners. I listed the initial collaborators on this project. But we're very much open to any input from industry here, any collaboration, any input that we can get from industry on, "Okay, this is great use case but if we could do this..." or "Hey have you thought about this kind of application that could really work for the vision of the flexible manufacturing cell?" So, we're reaching out there. We're having workshops, we're planning a workshop here in the near future where we'll have industry members come and join and talk about it, talk about what we've done so far, talk about how this can be translated to perhaps their use cases, et cetera. So, that really concludes my talk here, again highlight on the project partners. I mentioned Symptomatic, they are doing the integration for our UR5 and UR200 robot there. And then I want to thank everybody and I'm more than happy to address any questions.
Thomas Feldhausen:
All right, thanks Tim. Excellent presentation, Tim. I love it. I absolutely love the idea of the distributed or the democratized manufacturing, if you will. I've got a slew of questions, but I want to start with your data flow diagram. I noticed from your Hurco machine that you tagged the data flow going both ways with NiFi. Are you actually generating your G-code using NiFi or just passing it through? What's that input look like?
Tim Bakker:
Yeah, that's a good question, Thomas. So, it will be just a flow, true. The G-code will be generated through Siemens NX software where we have access to a specific piece of Siemens software that can automate the process for generating G-code for us. So, once we have the rework engine, once it has analyzed the data and it's come up with, "Oh yeah, we can rework this part if we do this next step," we'll drive that back to NX, generate new G-code, and then that will trickle down to the Kafka and the NiFi, there to the machine and then control the machine. So load the program and start the machine.
Thomas Feldhausen:
It's pretty interesting, the idea of generating G-code in situ to the process. So, as people are looking at building these data flow architectures, where do you have to draw the boundary? Do you draw it at the machine, or do you guys have to start looking at your CAM and your design packages like Siemens NX?
Tim Bakker:
Can you elaborate a bit more on that question? Not sure if I get the crux of it.
Thomas Feldhausen:
So you're generating your G-code in Siemens NX, you're passing it to the machine. From a qualification standpoint, are you just assuming that's good G-code or do you have to draw the boundary further back, and then the process for qualification?
Tim Bakker:
So, there's an interesting aspect to it. We are working with a software vendor Capvidia to perhaps analyze, to decode, or to perhaps do some verification on it. Which really, if you're thinking about maybe the [inaudible 00:46:07] software packages, we're not using that. So we do we do make some assumptions there that the G-code that's produced is good G-code. But it's a good aspect of it. Normally in a normal verification or in a normal manufacturing cell you would verify your G-code before you run it. So that's a good comment.
Thomas Feldhausen:
No, it's interesting from a cyber attack perspective of if you protect one little area where they're going to go further upstream in your manufacturing process for an attack?
Tim Bakker:
I haven't even thought about that, but those are questions that certainly have come around on can you verify your G-code based on a feature idea? Do I need to machine a hole, right? Can you verify the G-code? Yeah, this will actually generate a hole versus, no, this is going to crash the machine there.
Thomas Feldhausen:
As you work through this process, how difficult are you finding it to integrate multiple data streams together? Right now you have a small work cell with one system, but what happens if you start looking at five different machine tools, all from different vendors?
Tim Bakker:
So, that is a challenge. And the design here, you've seen only a snapshot of the design. The design has multiple layers of abstraction there were A we're going to go as quickly as possible to the MTConnect semantics and full vocabulary. So, if a machine doesn't support MTConnect, we'll make that switch as quick as possible and do it for the machine. Luckily our systems so far have MTConnect support so we haven't had to deal with that, but we certainly in the design we have the proficiency in there to build in logic if we need to make that transformation that we can do that. Because yes, that is a large challenge the same way as what is typically not standardized is the control of a machine. So, all of the controls of our machines here, everything is a little different. They all have their own API to to control the machine and their own interfaces to do that. So, there's custom work there, but the design, we're trying to make that really clear. "So, okay, here's your custom code, here's your custom logic for the machine to control it and to get the data out of it in an standardized way."
Thomas Feldhausen:
So, as we start implementing, you guys build this out a couple of years and you start pushing it out to the SMEs, the smaller manufacturers out there, what do you think the biggest hurdle is going to be? Is it going to be having bandwidth on their manufacturing floors if they have to do computing in the cloud, or is it just the learning curve that goes along with this?
Tim Bakker:
I would say adoption is the biggest issue here, learning curve around the ability to connect some of the machines there as they are legacy old state, they might not have the digital interfaces to do that. We certainly, with this project, we want to show that even if you have a small set of machines out there that are set up in a cell there, you can deploy this infrastructure here with minimal cost, with minimal infrastructure or proprietary software needed to drive, or at least get that hint of a digital track inside of that cell such that you can from there start to do all of the other work that you would want to do as part of qualification, process monitoring, data analysis, optimizations.
Thomas Feldhausen:
So, we did have a question come in, but before we get too far from this line of thought, for those out there that are interested in something like this, how do you get started? What do you do?
Tim Bakker:
As in getting involved with the project or get this started by yourself? Let's go both. Well, so as I mentioned, this is a NIST awarded project, so it's public domain. From CCAM that's quite a change for us because all of our projects are mostly proprietary for our members. So, this is really a unique opportunity for CCAM to showcase what we have in-house, what we can do, and also work with industry in a really open way. It's like, "Okay, if you want to join here, then please join in." We would welcome input here. We talked to John Deere, they're very excited about this. We're going to talk to them and say, "Okay, what kind of use cases? What kind of technology? Where does this make sense, where does this not make sense, and does it depend on your setup? Does it depend on what you want to do?" So we do tie into industry here to get them engaged and get them be excited and work with us on this technology.
Tim Bakker:
If you want to get this started by yourself, I would first really dig into the standards that are out there that really help you drive the cell, what they do, and that's how we started on working the standards. How can we drive this cell in such a way that we capture as much information that we can then plop into the standards out there? So, we actually have a white paper published on our website, the CCAM website. It's under research use case studies that highlights these standards, how they interact, what kind of functionality they have, and how we intend to use it for our project here. So, that's a really good way to start. And then for our project we decided not to necessarily leverage OPC way, but that would be probably the first thing for a lot of people out there to start working with OPC UA communication layers of connecting these machines together.
Tim Bakker:
So, we didn't have the need for it, and we had some different visions on scalability and bridging the edge to the cloud. So, that's one of the reasons why we not necessarily went to OPC UA, but we certainly keep it open. There might be a fit for OPC UA in there. Not sure if I completely answered your question there, Thomas.
Thomas Feldhausen:
No, you did good, Tim. So we're running short on time, but I want to get to these last two questions while you're here. So, the first one is, they ask is it too early to forecast if proprietary commercial platforms or open-source open standard approach will dominate the market?
Tim Bakker:
It's a question. I think there's going to be always some reliance on proprietary software. I have not seen any open-source projects yet there that would be good enough to use in industry. If we talk about CAD CAM design environments there, I haven't seen anything. To be honest I probably did dig into this a couple of years ago, but maybe there's something up and coming, we never know how the open source community works at times. So I think for those kind of functionality we're going to be relying on proprietary software. But we try to transition as quick as possible to the open standards so that if in the future there is a great CAD CAM design that comes around, a great product that we can be leveraging that is hopefully then also compliant with the open standard, then we can use that.
Thomas Feldhausen:
Okay. And our last question, what advice do you have on offering solutions protected against the fast evolution of underlying technologies?
Tim Bakker:
That's a good question.
Thomas Feldhausen:
Disrupt or be disrupted.
Tim Bakker:
Yes. And that's tricky at times. In the open source community, you have to do your due diligence to see where the projects are going just to really do some research on what is the computing community behind it, what's the longterm vision of these products? Are they going to be maintained over the years. Those are things that you always have to keep in mind probably when you're dealing with any software, right? Even the bigger OEM industries, OEMs can decide that certain times like, "We're not providing this software anymore, or we're going cloud-based versus a local installation." So, tough question, but with the open source community, you do have typically some look underneath the hood of, "Okay, where's this going? Is the community rich? Is this project going to be sustained for a long time?" And platforms like Apache Kafka, they're going to be around for a long, long time, they're going to be maintained.
Thomas Feldhausen:
All right, Tim. Well, thank you so much.
