 OK, I suggest we get started. Sort of welcome to another interesting Hyperledger Global Forum session. The title is, Does Industrial Asset Management Provide Good Use Cases for Verifiable Credentials and Distributed Ledgers? It's a provocative question, in a way. My name is Andreas Kint. I am in charge of cybersecurity technology, Ian Siemens. It's a global team that covers cybersecurity technologies on all levels of the Siemens enterprise, the Siemens production, and Siemens products and solutions. It's quite an interesting field. What brings us here to Hyperledger Global Forum is really very concrete problems in industrial production around machine identities, around extending trust into production environment, physical context environments, things like energy networks, things like train systems, factories, city infrastructure, and so on, and any kind of trustworthiness around sustainability. That's another important topic for us here. So with this, I will hand over to my colleague Oliver. He will present the topic. Right, yeah, there. I hope you can hear me. And I'm happy to talk about industrial automation. And I would like to try to answer the question, what could industrial automation have to do with things like verifiable credentials and distributed ledgers? Andreas and me both are Siemens employees. And Siemens is a global champion in industrial automation. Part of with a few slides of industrial automation, what it is, and to establish a common ground for the discussion on what it could have to do with verifiable credentials, distributed ledgers, and so on. First of all, what you see here is distinguished individual industrial automation components. Since the mention is not quite clear, I think it would be something like 10 centimeters by 10 centimeters by 10 centimeters. So not too big. And this actually is a piece, one piece, of an industrial automation component. And this is used as a part of machine. A machine could be something like an industrial robot. And that becomes part of things which are production cells or sites. And these components, machines, production cells, sites are used all over manufacturing, all over utilities, process industries, and so on and so forth. So that's kind of a common component which is kind of ubiquitously used. Now, it has some properties. So first of all, there are components which are called actuators and sensors which actually interact with the physical world. And this is one class of industrial automation component. And there are other classes of components which control such actuators and sensors. So these are the most important classes of components. All these components have a chassis. They are tangible. So it's not like a piece of software that you get by download. It's kind of something that is shipped to you. It has to withstand harsh environments. It has, of course, identification. And the identification comes in two flavors. You can identify such a product as a part of a cohort of a class of components. So there's product type and order ID-specific information by which you identify a whole class of components. And there's also identification on an individual instance level. It, of course, uses computing technologies and all flavors that you know from computing like programs, algorithms, state engines, processors, memories are part of such components. It also, of course, uses networking because it's used in a distributed environment where it interacts with other such components and uses networking for this interaction. And something where things are a little bit different from some IoT environments. Most of them are, in many cases, they are real-time requirements, which means that the interactions in such a system have to happen according to certain boundaries with respect to time. So that's an industrial automation component. Such a component, of course, has a lifecycle. And on the left-hand side, you see top-down rough chart of its lifecycle. It starts with the manufacturing phase where by the manufacturer of such components, the actual instance is manufactured. Then it's kind of shipped. The shipping is not shown here. It arrives at the customer side and then it's kind of bootstrapped. So it must be installed. It must be commissioned. Then it gets into operation where the actual process or automation process is running. Then there could be one or more maintenance phases and there can be an off-boarding phase. Of course, it's not so easy to read here from a kind of a space perspective. The interest of the customers, of course, to maximize the operational phase. So the idea is, of course, this component should run 24 hours a day, seven days a week and 52 weeks. And once it's happening, some data is produced. So next thing, we look at the data objects. And here it's important to understand that you have different classes of data which are associated with the data cycle. So when the component is being manufactured, then data objects are being generated, which we call product master data. And think of things like items would be the serial number for the product instance or things like the MAC address, which is bound to the component. And also information like who's the manufacturer, what type of component was manufactured, what was the order idea, which hardware software version do we have? During the bootstrapping phase, we have another class of data which is being established, which we call deployment master data. And here we have things like application names, could be also IP addresses, or even the physical location, which are relevant for this component and its use. During the operational phase, we have operational data that is being created and that kind of reports on the performance of the component as well as the health of the component. And kind of the maintenance phase and the off-boarding phases, they kind of can touch certain sets of information, but we already talked about the most important ones. Then we have different stakeholders that's also important to understand. It starts simple. First of all, we have two columns here. We have the producer of the data and the consumer of the data. So it starts simple during the manufacturing, the data is produced by the manufacturer or on behalf of the manufacturer. We have a couple of other roles, which can be the consumers. So we see another actor in such an industrial automation system could be a distributor or the machine builder, the system integrator who kind of builds the production cell or plant on behalf of the owner and the owner operator. So we have different roles along the value chain in industrial automation. And here you can see that the production and the consumption changes with respect to where we are. The short summary is there is no single entity which can give and provide all information that is relevant for an industrial automation component along this life cycle. And we will see that that's an important aspect to the challenge and to a solution that we discuss in a moment. Right, so next question is the customers. So the owners and operators of industrial automation equipment, what do they actually ask for? And there's a 1A requirement. And I think that's pretty obvious. That should be a no-prayer. They're interested in runtime performance. So 9 or 99.9 availability of the component. And as well as predictable and available operations of that. That's clearly the number 1A requirement. There is a not so obvious number B, 1B requirement and that's asset management. And to give you an example here, we provided some information from a recent RFI request for information by a major car manufacturer, one of the top five car manufacturers. And that's what they are asking for. And let's take a minute to understand. So first of all, and I hope you can see my cursor, I go to the sub-pollets. They give a list of information items they're mostly interested in and we can see by roughly checking it, that's kind of a union between the production master data and the deployment master data. So they want to have both. They want to have information from the class of production master data, as well as information deployment master data. They want to have this automatically. So they want to have an automated process, which does not depend on much manual interactions or interference, that's important. They want to have it for each and every component and the number of such components can be quite high. So you easily have a five digit number of industrial automation components within a single factory if you look at a user owner like a car manufacturer and the production of some cars. There are also smaller deployments. There are also deployments with four digit numbers. And here maybe an example could be even the vessel equipment or ship equipment is one of a major market. And I guess the numbers typically, there would be four digit number. Of course, there are also smaller ones, maybe three or even two digit numbers of industrial automation components, but anyhow, no matter what the number is, they ask for each of that component should provide its information automatically. They also, next thing that is important, in a factory, typically the components of multiple manufacturers come together. So it's never one manufacturer thing there. Typically it's a two digit number between 10 and 20 manufacturers that come together and deliver equipment for a single factory. They want to have it for all of them and they want to have it in a convenient way, which means they need to have standards for getting this information. And here they already give an idea on what would be their preferred idea of the standards they would like to use to get this information. Well, that's what the customer asked for. And again, the information was it's a recent requirement. Now let's double check where we are. So the question is, are these customer demands fulfilled already? And here we look at three dimensions, first dimensions is the third thing. So can we get the information at all? And it's structured according to the ideas the customer has. They suggest something like a Profinet, identification and maintenance data record. Profinet is one of the important field buses which are used to control actuators and sensors. SNMP is an ITF standard for network management. OPC UA is an industry domain standard for industrial components. And here you can see the overall assessment would be we have a partial coverage of the sourcing. Looks like the Profinet E&M data is best in providing coverage, but they only cover the Profinet specific data. As soon as you have an industrial component which runs Profinet plus X, you have coverage for Profinet but you don't have coverage for the plus X. So overall it's partial. Next, if we... So Andreas and me, so if we look at the level of protection of information or of proving that information, the question is, are we covered here? And the answer is not yet. Typically, for instance, Profinet E&M data is self-asserted information without any protection at all. So it's actually pretty simple to create fake equipment, claiming or pretending to be seamless equipment because there is no safeguard for this E&M data as of today. And that belongs to the class of self-asserted information. So the component tells itself about its own identification and maintenance status and it's not protected. If it would be third party data, also typically things are unprotected. So the proving part is not yet fulfilled. The automating part partly fulfilled. And here again, we have the same issue that we talked before. If you look at components which run Profinet and only Profinet, it's pretty much fulfilled. If you look at more advanced component which run other stacks in addition to a Profinet stack, it's not fulfilled right now. So we have a clear customer requirement. It sounds simple and fair. If we double check the current status, it looks like it's not yet there where the customer wants us to be. So the question is how can we fill the gap? And now we switch to the trust technologies which emerge from the W3C in which we're also used in the blockchain context because they give us a potential and first of all, a potential and also a new potential when we compare them to classical approaches to trust them. We have two candidates here which look appealing to us. There is the W3C verifiable credentials. Here's a bit of generic information on that slide about verifiable credentials. I guess for most of you, there is not too much news on that slide. So maybe let's quickly concentrate on that chart here. So if we translate that to industrial automation, the component which is called hold for here would become the industrial automation component that would be the holder. The verifier here would be typically the owner, the operator or maybe the system integrator who kind of builds up and takes care of running a production cell or a production site. The next thing is based on what we talked already, they need production data. Production data is understood by the manufacturer. They need deployment data. Deployment data is understood by the machine builder or by others. So we will have multiple issuers. So in our understanding, we have one component which is the holder. Probably we have one verifier. I hope you can see my mouse cursor, I move it a little bit. But we have multiple issuers making statements about that component and the verifier asking questions about that. And here we can already see with a classical model here, the verifier probably would have to ask multiple questions to understand deployment data as well as production master data. The appealing thing here is we can transform things. We can even synthesize things. So we can have multiple credentials issued to the component which gets synthesized into a single presentation. And this is a good fit to our constraints. It also allows to kind of do further transformation operation. So this proposal for industrial automation along with the verifier credentials, we have the decentralized identifiers. And here it's important to understand as of now, they provide an identification FAPRIC which is used in the context of verifiable credentials. So they are used for in order to refer to verifiable credentials schema objects or to actual concrete objects. They right now do not yet, or they are not related to the classical identification information which exists in the industrial automation since the decades. And next slide is what could a solution look like? Actually, we have pretty straightforward building blocks which already come out of the W3C documents. So things start with an issuance step which means the issuer issues credentials to the industrial automation component. The industrial automation component is the owner here. And we equip them with verifiable credentials. Again here, this is a recurring thing is because we have multiple actors able to say something about the industrial automation component while the owner operator is asking for all. We have multiple, or we believe there will be multiple in the issuance steps. There will be multiple issuers providing objects verifiable credential objects to a single industrial automation component. This is addressed already in the W3C verifiable credential data model. Next step would be the presentation step. So I'm interested, I'm curious to understand something about my industrial automation component. And in order to do that, I interact with the component and I challenge it to present either credential or verifiable presentation. And I do this in the role of an owner operator. For instance, that's also addressed in the W3C verifiable credential data model. Then there's the verification step. Once I obtained my verifiable presentation, I need to check it, of course, with respect to its authenticity, with respect to its timeliness, things like that, that's already covered in the W3C data model. Then after checking the actual information that I got, I must, the overall context that operate like was. Now I understand that this component has this and that serial number, but is it supposed to be operated within my protection cell or a site? That would be the next question, the validation step. And here the W3C verifiable credential data model intentionally abstains from elaborating that. So they formulate the talk about the validation step, which is a good idea, and but they abstain from detailing it because that becomes industry specific. Right, so we get the building blocks more or less. Now question is, will that be an exercise that is simple to do and we just have to copy and paste what we get? Or do we have to do some lifting? And if we have to do some lifting, is this heavy lifting? And here the answer to this question is, yes, we believe some lifting is needed. And this concerns both actors or especially the technology and solution providers. We talk about in a minute about the users of the solutions, but actually it's not the rocket science that has to be done. And the following items, the work items that have to be addressed in doing this lifting. And again, the lifting here or the assumption is the lifting starts with the artifacts that we get from the WFSE, such as decentralized certifiers and very public credentials. And for the very public credentials, the proposal is for the assumption is we need to have specific schemas for the industrial automation domains. Here we have to take care that with respect to IEEE standards, there's already a relevant piece which was established some 10 years ago, which is called secure device identity, which talks about or which suggests the equipment of industrial automation components with objects which are backed by cryptography, especially asymmetric cryptography, which is your certificates. So that has to be kind of weaved together, which is our first item here. The standardization on how a very public credentials can be presented and verified. We already have lots in the WFSE standards, but still here, how do I discover the endpoints or publicize the endpoints from which I can get that information that looks in this dimension. We talked about the validation procedure. So the things that have to happen or should happen after the actual verification, technical verification. So the overall context validation, that's something like I said before, that's descoped for a good reason from the W3C standards that would have to be felt. There have to be some endpoints on the components which have to be prescribed and described and specified together with the functionality. There also needs to be a clear understanding on what the verifier role is. So is this like an automated component which runs continuously in a production cell or is it more kind of an operator tool thing that is being used? So things like that would have to be specified and identified. And also it looks like that the overall accreditation of the issuer organizations as legal entities would be out. For the decentralized identifiers, there needs to be or there should be from our perspective of consideration on how should decentralized identifiers look like which are able to protect existing investments. As I told you before, identification information already is there. And there is not really an interest to kind of to go back to zero here and restart the whole thing with an empty page. So the decentralized identifier models probably have to take into account that there are identification schemes which carry a value both for the manufacturer organizations as well as for the owner organizations. It also looks like that the DID documents should become non-public in the industrial automation case. So with that we are able to sum up what we talked about. So and here what are the things that you should take away now? Number one, industrial automation. And here we talk about terms like IoT for Internet of Things and OT for operational technology. And here the differentiation probably is IoT usually takes the used IP stack and OT often works with OT IP stack. No matter what it is, we collectively call it industrial automation and yes, there are interesting use cases for verifier. That's us. The use cases that we see which are interesting and relevant here belong to the cluster of asset management. The quotation here gives you a short definition of our understanding of asset management which was taken from Wikipedia. So I think that should be pretty clear I guess to everybody. And the importance next thing that is relevant here, the importance of asset management kind of is self-evident. In industrial automation, we look at the owner operator which typically are legal organizations. This is not you and me at home which are interested in a smart home solution. So these are legal entities which manufacture some goods or produce some utilities. And usually they are the industrial automation components provide capital goods for them. And with respect to that, they need of course to understand what they have and in which kind of state and shape that is. And this is an old requirement. So asset management in industrial automation is not new. It is solved but actually it's kind of old school solved like spreadsheets, papers, people walking around. So the asset management solutions that we are aware of actually like digitization right now. And when we would use the emerging technologies, trust technologies, especially verifiable credentials and distributed ledgers in a smart way, then we could fill the gap. So asset management is important. And here we try to establish the slogan. Yes, it's there. It's kind of analog, it's done, it's happening. It's analog, it's not net digitized. It probably has to be digitized. And the technologies we were discussing can provide an important role in doing that. So expectation management is also important when we think about how we could exploit this potential. When for those who are acting or working for technology and solution providers, the message would be to our expectation management would be what we see that we can get from organizations like W3C something I would term raw material for solving industrial automation use cases. And that's not yet the turnkey solution. And that was the slide about the lifting and whether it's heavy or not. So something has to be done on top. Yes, some lifting, but I guess, or we believe it's not really having lifting. For those who are on the side of technology or solution providers, then there will be some procedural changes. So how asset management is happening and being done can and will change if this kind of process takes place. But there is no fundamental change with respect to whether or not I have to take care about that. And that bear the slides that we wanted to present to you. So thanks a lot. And if there are some questions, I'm happy to try to answer them. Yeah, exactly. Please post your questions into the chat. I know we have only a couple of seconds. Let's just remind us. So one quick question from somebody. Otherwise feel free to reach out to Oliver or me. We would be quite interested in exchange on machine identities. There's a question from Simon. How do you verify that the information about the industrial automation component is maintained correctly? Yeah, I'm not sure if I have to ask a question back. At the end of the day, there are issues. And of course you kind of have to trust the issuers to do their job correct. So there are some contextual checks which can be done. There is no trust out of nothing. So in my understanding, it's a technology that helps to assess and validate the information, putting it into context, evaluating into context. But at the end of the day, you have to trust the manufacturers that you want to work with. Or the machine builder. And that would be my take here right now. Okay, good. Yeah, then I guess, Oliver, we have to wrap up and say thanks for your attention and the interest in the topic.