Transcription

• Speaker #0

  Hello and welcome to this new session of UAO Goes Live, Implementing Asset-Centric Automation with IEC 64999. I'm Greg Boucaud, Chief Marketing Officer of Universal Automation Network. In this session, we will explore how industrial automation is evolving from asset-based to asset-oriented and asset-centric strategies and how IEC 64999 enables these approaches through openness, modularity and interoperability. Joining me today is Saad Khouma Redi Moulakeshima, Chief Architect Officer at Universal Automation.org. Saad will share his insights on how this technology empowers flexibility and future-proof automation systems. Stay tuned as we delve through this topic and don't hesitate to ask your question in the chat. Saad, welcome.

• Speaker #1

  Thank you Greg.

• Speaker #0

  Can you introduce yourself to us again for those of you who know you again?

• Speaker #1

  Yeah, sure. Thank you. Thank you, Greg. And thank you for giving me this floor to come back and present on something very interesting today. It's been a while that I was part of this session and presenting some interesting topic. Sure. Today we have a very interesting topic, which is what exactly is asset-based and asset-centric automation? what where do they apply and how connected they are and how different they are so this is what we are going to explore a little bit and beyond that we are going to look at how asset based and asset oriented control automation can be done using IEC 64099 and the universal automation runtime okay so i now present you this groundbreaking concept of asset-based and asset-centric control automation which is a very very important initiative that is being actively pursued by both end users and also the automation vendors and suppliers we start our presentation first trying to understand the basics of what asset-based automation is and what asset-centric automation is so we start with the terminology so it's very important for us to understand what an asset is before even we talk about what asset based and asset centric control and automation is so at a at a basic level an asset is a physically or logically identifiable entity i hope everyone understands what does it mean when we say physically or logically It's not a must that something which can be touched or which can be seen or which can be perceived is only an asset. There could be some logical stuff like for example, a software application itself could be called an asset. Even there are things which are having life. For example, even a human is considered an asset in certain contexts. So anything which can be identified as an entity in the world or in the system can be called a asset and it contributes to in specific to control and automation an asset is something which is physically logically identifiable and also is contributing to the operation monitoring of an industrial system now if we look at the assets it's not a must that an asset is a single entity or a standalone entity no an asset which is single, standalone, with its own attributes and behaviors is a simple asset. And it is also possible that there exist composite assets, which are combination of several simple assets. When all these simple assets are brought together, they kind of exhibit a behavior, which then becomes unique to this composite asset. So it's very important to understand this. simple asset and composite asset because this is what then plays a major role when we talk about asset-based automation and asset-centric automation. Now, few examples of physical assets as you can see here, machines, devices, infrastructure, anything that is contributing to operation monitoring and control of an industrial process or an industrial system is an asset and that's what you see here as physical assets. and as i was mentioning before logical assets they are not physically perceivable but they they do exist and software modules for example a control application itself can be called an asset a digital twin can be called an asset and data sets databases even these kind of things the logical and digital format entities can also be called as assets so this is a very basic introduction to what an asset is now we move on to understand a bit about asset characterization. How is an asset characterized? An asset for sure must have an identifiable attribute in it which is like it identifies itself as a unique entity in the system. This typically is done through unique ID or name and this is what we use even in the real world. Each person is identified by a name in general and sometimes you have to qualify the name with few more things to really make the asset. uniquely identifiable and of course the asset should also have a description which is basically the metadata which which is kind of like say if it is a device who is the manufacturer of the device what is the device uh manufacturer id what is the year of manufacturing and and all these details so this is basically a description of that asset and then is this asset operable especially in the the context of control and automation. It needs to clearly tell whether the asset is operable, then if it is operable, then what are the different operating modes, how it can be controlled, what kind of parameters that it presents to you, how you can monitor them and all this. Then the composability part, that means it should be possible to use asset by itself and it should also be possible to make this asset part of a composite asset or a composite system. and then it should still be usable as part of the system. So that's another characterization of an asset. And all these things, all this understanding is very critical when we try to understand now what is asset-based and asset-centric automation. And then there is also a very, very important aspect about an asset that we need to be really clear about. An asset might have more than one facet. So, a facet here is a logical partition of an asset and when I say partition here, it need not be a physical partition. It is more a logical partition which refers to what are those interesting characteristics that are interested to somebody who is trying to act on the asset. So, that is what you see here. So, there are two definitions which I have put forward here. An asset facet is a logical partition of an asset that refers to specific perspective. perspective or aspect of an asset. For example, if you take a pump, a pump might have multiple facets. For example, a operational engineer who is operating the pump might be interested in this facet of operating like, can I start it? Can I stop it? Can I set the RPM? Can I change the RPM? Things like this. Whereas there might be another actor who is more interested in understanding, okay, I want to know whether the health of this pump is uh correct or not or is there any problem with the pump then then this technician might be interested in looking into different facets of the asset which exposes different information and data to this uh actor so that's why we have the second definition where we say an asset facet is a specific view of an asset that highlights the information or functionality relevant to particular actor right so both the definitions go hand in hand and again the definitions are not uh always the same when it comes to looking at understanding a particular asset. Now, as you can see, there is a table that is presented here. I try to present here some examples of what kind of an actor is interested in, what kind of facets associated with the assets used in control and automation operators are more interested in. controlling and monitoring an asset which is part of the industry setup a maintenance technician is more interested in diagnostics life cycle configuration so on and so forth a system integrator is more interested in how do i do communication configuration how do i do control configuration using this asset right and the product production manager might be more interested in monitoring and the performance and the life cycle of the asset because that is important to them to optimize the production so on and so forth Security administrators, obviously, they are more focused on the security and safety aspects of the asset. Simulation engineers are more interested in how do I work with a digital twin or can I create a digital twin of this asset and then do certain simulation and tests and verification and validation. And the MES and ERP systems. So an actor here need not be always a human. An actor here can be even another system or another asset as well. So it's not a must that an actor is always a human. An actor can be another device, can be another system, can be an adjacent system, whatever it may be. So it all depends upon how you visualize it and how you view at it in terms of understanding what kind of facet is critical for this kind of operation or for this kind of interaction, so on and so forth. So this facet as well is important when it comes to asset-based and asset-centric. automation because we leverage on these facets when we try to implement this asset based and asset centric control and automation now we get introduced to the very basics of what is an asset based and what is an asset centric control and how do they compare with each other compare and contrast with each other so asset based control is strategic development of your control application okay You apply certain strategy around your control application development to ensure the plant is operated reliably and the operations are focused on minimizing the downtime, reducing the maintenance costs and extending the operational life. So this is more close to the shop floor where you are doing certain things. to make sure you are using the asset in a way in your control application that you are able to maximize the uptime reduce the maintenance costs and extend the operational life of the asset now few examples of what it means when you say you are taking the asset as a base for developing your control application condition based controller heat exchanger for energy efficiency what this basically means is apart from asking your heat exchanger to operate in certain way before you ask it to work in a way you take into consideration the condition of the heat exchanger itself it is possible that over a period of time the heat exchanger has deteriorated a bit and then maybe it cannot heat up so quickly or it cannot cool down so quickly so then you take this aspects into consideration when you are putting your startup sequence when you are putting your shutdown sequence into consideration okay my heat exchanger let's say has aged a lot so now it's not a good idea to really ask it to heat up so fast things like this and then being aware of the life cycle and taking that also into consideration when you are developing your control application which means for example you Let's say you are using a valve positioner in a process industry and then you know that the valve positioners come with certain life cycle data with them. For example, a valve positioner may be saying that the opening and closing of the valve can be performed these many times in the lifetime of the valve. or maybe it may say that okay once you perform these many openings and closings you need to take the valve for maintenance or you need to reduce opening it completely or you should not close it completely things like this so again taking these into consideration and then defining your control and control application or implementing your control application is asset based control also the other example proactive control of pumps to avoid failures yes also you operate the pumps and Not just pumps, any device for that matter. You always take into consideration what this asset is and what is the performance of this asset in this condition or what is the manufacturer saying about the operating limits of the asset, so on and so forth. And then you implement your control accordingly with the focus on reducing the maintenance, minimizing the downtime and extending the life of the asset. That's what we call as asset-based control. Then asset centric control is it's more a strategic approach where control and operational decisions are centered around us. So a control application engineer is mostly just focused on writing the control application that he is able to control the overall process by virtue of controlling an asset whereas the operational people sure they do want to understand how the process is controlled but what is most important for them for the operational people is you know maximizing the productivity. closely aligned with what are the business goals okay so the asset centric control is in a way the control engineer and the operational uh engineer coming together to make certain decisions and then make sure that the operational procedures and the the operational decisions that come to the operator in the control room who is operating the plant are done taking asset as the core of their operation or considering the asset as core of their operation. The objectives for this asset centric control and automation is it is to maximize the productivity, it is to maximize the return on investment, it is to maximize or it is to meet the business objectives, making sure you are not stressing the assets, making sure you are still protecting the set you are still operating the asset in a way that it is not leading to a large maintenance cost right so this is something which is asset centric control and operation so it's not just asset centric control it always is going hand in hand with operational decisions so it's basically asset centric control and operation one of the example here is you have to schedule the heat exchange operations and you have to prioritize the maintenance based on business impact and return on investment. Imagine you are using a heat exchanger for production of certain chemical or I don't know somewhere in a pharmaceutical industry. You know that there is a great demand for this particular drug or chemical in the industry and you want to produce and make money out of it. Sure you have to do it. At the same time you have to take into consideration if you are stressing so much on the heat exchanger what could happen. will you lose the heat exchanger forever and then which means you are going to spend a lot of money buying a new heat exchanger or you're going to spend a lot of money bringing it back to life the way it is supposed to work. So whatever business objective you are trying to meet that is the profit making objective in a way is compromised because you are stressing too much on the heat exchanger. So it's very important for the operational people to understand these aspects and then plan the operations accordingly. sure you need to meet the market need at the same time you need to make sure you are not stressing on the resources that you have in the plant so i spent a bit of time here explaining asset based control and asset centric control because this is what is the concept that i thought i should share with you guys and and this is something which is very very useful for everyone not just end users but also for automation vendors and suppliers to understand how you can design and develop your control system which helps end customers leverage these concepts to make the best out of it. Okay so here is a bit of again comparison what is the focus area as I said asset-based control engineering is tying the control logic to the asset condition and asset centric control is you have the control but then you are orchestrating this control like for example there is certain configuration that you give to this application certain set points you give to this application you are orchestrating this control logic and control application to maximize the value that you are able to extract from the asset and also meet your business objective the scope when it comes to scope asset based control engineering is clearly in the engineering and automation engineers scope On the other hand, the asset centric control is more a strategic orchestration of the control, which means the operational engineers are supposed to define how the strategic orchestration is to be done so that their business objectives can be met with minimal impact on the assets. Now, what type of data is used here? So mostly it is real time sensor data that is coming from the asset, which is used here in the asset based control. On the other hand, in the asset centric control you are going to make use of lot of information coming in terms of lifecycle and the performance data, the historical data that you have about the asset, which kind of tells you at what levels of configuration the asset operates to its full potential and all these things. Again, responsibility, as I said, it is the engineers who are defining and configuring the control system that take care of the asset-based engineering. And in case of asset-centric control, it's the production and operations planning. people who have to work and come up with this orchestration methodology and then use the control system engineers to orchestrate the logic and configuration accordingly. And in terms of goal optimizing the control performance and asset reliability is the asset-based control engineering goal. On the other side, the asset-centric control is about maximizing the value that you are able to generate. in terms of meeting the business objectives using this asset centric. Great Now that we know what is asset based control and asset centric control, how do we design and develop this? What are some of the important principles that are foundational to designing and developing an asset based control or an asset centric control? One of the very very important design and development principle is you should be able to encapsulate and abstract an asset definition. And then once you are able to encapsulate and abstract an asset behavior, then you want to reuse it. And you also want to make it configurable in order to make it unique to the specific instance of the asset. Also, you need the ability to modularize some of the implementations of asset-based. control and the asset centric control so that this modularity can help you scale to whatever level you want to scale and then the asset based and asset centric control both are towards uh doing a decentralized and distributed intelligence that means you avoid too much dependency between the assets or let's say there are four or five assets which are coming together and delivering a job and you want to make sure that one asset sure will get influenced by what the other assets are doing but this if this asset can operate independently with the cognizance of what other assets are doing that's the best that you can achieve so decentralized and distributed intelligence is very key for asset based and asset centric control and engineer Of course portability and interoperability, this is something which is most important thing in the industry today. It's not just about asset based and asset centric engineering but this portability and interoperability brings in a lot of flexibility in terms of choosing the vendors, suppliers, devices, the assets that you want to use for your control and automation. Plug and produce highest engineering efficiency, this is what gives you the highest engineering efficiency. efficiency. So this design and development principle is a very, very important one. And then being able to do a digital integration and being able to connect the assets with each other and also connect the assets to other enterprise level application assets is also very, very important considering today's digitalization and the advancements in digitalizations that are happening today. and especially with AI it is going to next level. Vendor independence and openness again this is something which is being now demanded I would say or which has now become a mandatory thing in any of the industrial automation solutions this is something that the end users always want it because they don't want to be tied to a particular vendor they want the openness that they're able to use the same control application and same implementation of a control application or even if it is asset based or asset centric they want it to be independent of the vendor they want it to be developed independent of the vendor and then they want it to be used on multiple hardwares and multiple software platforms the other important principle is software defined so always you want this freedom of running your control application more based on what is defined in the software rather than driving it based on what hardware you have. So this is a very very important principle that even the asset based and asset oriented. control application and engineering needs to adhere to. Of course, as I said, orchestration is the key for asset-centric automation because if you look at most of the distributed control systems today, let's say I create a control application and then I deploy it and it is running and managing my process plant. And in cases like batch control or in cases where you're using the same production line or you're using the same production unit to produce different materials there is always a down time where you're re-preparing the line or you're re-preparing the plant for producing something else this is something which that that is needed on the other hand for example let's say i deployed a control application and now in the middle of the process i realized that i need to make a change to the the way the control application is working i want to orchestrate it a little bit differently so that i am able to make the maximum value out of the assets that i am using for this production of material the ability here is to orchestrate the application on the fly which means you are not stopping your process you are orchestrating new configuration or you are orchestrating some additional logic into the application and you are able to get it to work or Steer it the way you want to make it work. So this is something which is very critical to asset-centric automation. Orchestration is a very, very, very important aspect for asset-centric automation. Now that we know what are the design and development principles that are key to implementing asset-based and asset-centric automation, we should also be aware that, okay, I have this design development principles. I'm modeling my system. I'm modeling my application based on this. principles but then what kind of programming constructs, what kind of programming concepts, what kind of programming languages should I use to easily implement a system which is modelled based on these principles that becomes very critical. So next we look at these programming constructs which are very very key to achieve what you modelled and design and take it into implementation and execution and these are the very important programming constructs one obviously object based and object oriented programming this is what brings you those four object oriented principles into play abstraction encapsulation polymorphism and inherent okay not everything is needed you could do very well with three of them abstraction encapsulation and polymorphism yeah inheritance may or may not be inheritance can be achieved in multiple ways We will come to that in the later slides when I present how 64099 helps you achieve it. Of course, the service oriented architecture, this is something which has been there in the IT world for a long, long time and also came into the industrial world maybe a few years before, maybe five to ten years before, but was not pursued so much on the embedded level. this was more pursued at an application level, things that run on engineering stations or things that run in enterprise servers or cloud, whatever, is not much pursued at the embedded level. However, if we want to realize this dream of asset-based control and asset-centric control, it's very, very important that we are also able to leverage the service-oriented architecture and principles to achieve or to implement those models which are... created using those design methods. Another important aspect is event driven modeling and programming, which is very, very key to independent execution of logical units, as I was saying, distributing, being able to distribute intelligence or being able to distribute the application to multiple edge nodes. And these edge nodes, they need to talk to each other as and when needed. It's not like, okay, I'm talking to someone. continuously to know if this someone is going to do something tomorrow. No, that doesn't make any sense. What makes sense is, okay, if there is a way that I come to know this person started doing this and I want to start doing something else, that's the best. I don't want to keep pinging this person, have you started, have you started, until this person starts doing something, right? So similarly, event-driven modeling and programming is very critical to asset-based and asset-centric engineering because the efficient way the assets communicate with each other is need-based. Only when there is a need, they need to exchange information. Only when there is a need, they need to exchange data or events.

• Speaker #0

  So, event driven modeling and programming is critical to achieving this high level of efficiency in asset based and asset centric control. State machines and state based control and operation, this is also a very very important programming construct, especially when an asset has to decide in what state, what behavior that it should expect and for the asset centric automation, it's important for the orchestration of the asset centric automation to know what is the current state of this asset. Now from this state to which other states can it transition? Does it make sense to transition this asset from this state to that state in order to achieve my objective? So all these things become very critical. This programming construct is very important to implement the asset based and asset centric control and automation. Then asynchronous communications in a way Event-driven modeling and programming itself is towards achieving asynchronous communications. Same thing as I was explaining. Communicate only when needed. Why do you want to flood the communication network even when there is no need for you to communicate? So for efficiency, for efficient utilization of the resources, asynchronous communications are really, really critical. I take a little pause here from the concepts to bring you back to what we are. Just to bring back what Universal Automation is for the benefit of the people maybe who have joined here for the first time. I will continue on the topic just after this slide. So for those who are new on the stream streaming Universal Automation is a nonprofit organization. It's an ecosystem of users, vendors and academics. And we operate with the principle of common automation kernel based on 61499 as a shared source. So. the model used here for achieving openness for sure it leverages the open openness concepts that are available in 61499 and on top of it it is the shared source model which makes the dream a realization so shared source model we operate on the shared source model for the best portability and interoperability and of course today innovation landscape is not done in silos innovation always happens in collaboration So we foster for innovation through collaboration by bringing all these different types of members into this organization. Okay, so I'm again coming back to this design and development principle just to throw or shed some light in terms of how these design and development principles are supported by the 61499 and ua together So the asset encapsulation and abstraction as I was mentioning object orientation is the fundamental here. The function block model, the ECC state chart, the concept of composite function blocks, the sub applications, adapters, user data types, all these things help implement asset encapsulation and abstraction. Then comes modularity and scalability. It's very important that even with this encapsulation and abstraction you are able to make an hierarchical composition as you can see here there can be an FB becomes part of a composite FB becomes part of a sub application becomes part of an app so this kind of modularity helps you scale your application then comes the decentralized and distributed intelligence it's a no voice to say 64099 is focused on distributed control systems is a standard for distributed control systems so by nature it supports decentralized and and distributed intelligence. And to achieve this, The standard contains the definition of system, devices, and resources model, application, ability to map application to multiple resources in multiple devices, and then, of course, the event and data connections across devices are implicitly supported. The communication service interface function blocks are also key to achieving this distribution because these are the ones which enable you to implement the exchange of events and data between. function blocks running in different resources and devices. Plug and produce also some of the fundamental things that are touched upon in 64099 standard the management commands that give you the ability to do this plug and produce kind of implementations. Typed sub applications self describe or self describing units which means you can produce a sub app and then directly get it to work by putting it into the application and resource of course adapters to define contracts for event and data exchange between sub apps or between composite fbs or between fbs gives you the flexibility to do a plug and produce which basically adapter can be used in a way to achieve polymorphism vendor independent and openness as i said the standard itself is focused on this however even with standard there are instances where the vendor independence and even interoperability and portability is compromised the approach of shared source from universal automation is a very very very key thing to achieve this vendor independence as i said portability and interoperability the standard does talk about lot of these things to make sure the applications are portable and the applications running on one vendor is interoperable with the application running on another vendor device so on and so forth as i said most of these constructs which are defined within the standard help you achieve this on top of it the shared source model is critical to achieving this. Software defined probably it is only the 64099 and the implementation of it which is letting you go and create your control application without thinking about what hardware I'm going to use, what IOs I'm going to use, what kind of resources I'm going to use. You focus on your application development, you start top down not bottom up not by deciding the hardware and IOs, you start from the top. you define your application you implement it only when there is a need to take it to the field that's when you you go and figure out which devices you want to use and where you want to deploy it and this is very very key to achieve what we call as the software defined automation until the time you are starting your job with choosing the hardware you can never claim that it's a true software defined automation so it's very very important that the 64099 principles are diligently followed to make sure the software defined and hardware agnostic approach is achieved orchestration yes again the some of these concepts in standard the possibility to have application networks the management commands for managing the lifecycle lifecycle of the application and the runtime topology and then using this supervisory function blocks and subapps. coordinating with each other all these things contribute to making an application orchestratable and then also being able to orchestrate it and there are number of use cases where these are currently used by universal automation members reusability and configurability as a the basic fundamental of this the ability to have type libraries and then these type libraries containing types from which you create instances and then you create application that itself is a concept that allows the achieving of reusability and configurability which is very very important in asset based and asset centric automation. Digital integration and connectability, the service interface function blocks are the key here and then using them in conjunction with proper definition of adapters to wrap up the way the interface and the data exchange is defined. is critical to achieving this digital integration and being able to connect the control application to various other applications that are adding value by taking data from control to the next level so that was about how 64099 complements implementation of those design and development principles now a quick look into how some of these programming constructs are addressed in 61499. Object based and object oriented programming as I said the very basic the function block model itself is object based and even the adapter definitions the ability to define user data types all these things contribute to the fact that 61499 natively supports object based programming. Object oriented yes it's not so much especially the inheritance is something which We just... kind of compensated using the concept of containment, I would say containment and composition. It doesn't matter which approach you use as long as you are able to wrap up and reuse that's good enough to make sure you are able to achieve this abstraction and encapsulation levels. Then comes the service oriented architecture, yes the ability to have service interface function blocks which are modeling the functioning of a service for external interfacing and communicating with external services is promoting the use of service oriented architecture in the runtime. And in a way, the adapter types and the way you define the adapter types and the way you use these adapter types for the service interface function blocks is key to having clear and easy to use interfaces. Yeah, the management commands also contribute a bit here in terms of making sure the deployment and other kind of services which are exposed by the runtime are based on service oriented architecture. Event driven modeling and programming, event driven. Execution is fundamental to 61499. So natively, 61499 enables implementation of asset-based and asset-centric control, leveraging the event-driven execution model. I don't want to go in deep here, but this is very, very important, as I was explaining for this asset-centered control application development. State machines and state-based control, yes, the presence of electronic, the state chart, the ECC itself is contributing to the state machines, but in general, state machines are part of any embedded software. The only point here is it takes down to the next level. It's not just the device state or the service state which is being managed and maintained, but the state goes down to the level of function blocks. Each function block has its own state and the state together of several function blocks then becomes the state of the application. So this is also native to 6.14.99. Asynchronous communications, sure, it's again the service interface function blocks which are key here and service interface function blocks in combination with event-driven execution is what is key for asynchronous communications. Even if you have service interface function blocks which are cyclic that still doesn't help you achieve this asynchronous communications for that you have to do a lot of work in your implementation to make it asynchronous but with 64099 the design itself is supporting you to do asynchronous communications or it is enforcing this principle okay a quick recap of the same thing again with visually event driven function block again contributing to object-based event-driven modeling all these principles software hardware decoupling the system device and resource model which is helping you to decouple the application from the underlying platform and the device and the hardware the distribution yes the native concept of distribution is part of the standard so the distribution distribution of intelligence and the distributed execution of publication is possible yes the event driven function block this is something that everyone should keep in mind that everything that you model everything that you develop even in an asset based and asset oriented engineering it needs to be driven through events because you don't want to keep cyclically checking something cyclically doing something sure if there are instances where there is a need to do that yes you can do especially if there is a repetitive task like for example moving a moving something at certain interval in one direction and moving it back. If this is something which is to be done, yes, you can use cyclic. But if you want this movement to be done only when there is something, some change detected, that's when the event driven thing comes into play. So it's very, very important that you differentiate these things and then implement them accordingly. So the basic function blocks, the composite function blocks, everything is event driven. And these constructs help you. abstract, encapsulate and implement an asset. Application and device resource models, these are key to again achieving two important things, the vendor independence, the hardware independent, and also interoperability and portability. This is what is a demonstration of how the application is unlocked from the underlying device and hardware. Plug and produce software components. is again achieved through this library concept where you have types defined in a library, you instantiate these types and then you program your whole applications. Then you select the hardware topology. This is what is the top-down approach of control engineering and this is very critical to implementing asset-based and asset-centric control. You should be able to bind to an asset what you are developing much late in the game. based on what this asset offers but then your application should be still equipped to deal with these things. Deploy application to the controllers and then you are done and the intercontroller communications as I said the distribution is implicitly taken care. This is all what I had to present today. I think I have done my talk in the time plan. Greg, I think we can go for open session where we can take some questions if there are any.

• Speaker #1

  Sure. Thank you, Saad. Thank you for this detailed presentation of asset-based, asset-centric controls. So I think it was quite good to see all of those. I don't see any questions yet in the chat, but still I have a question for you. What do you see are the main benefits for companies adopting this asset-centric automation today, let's say versus the asset base, for example?

• Speaker #0

  Yeah. So for that, we need to understand how the control is done. in the current context, most of the control systems today, for example, a control application engineer, he is, or this person is focusing on developing the application, keeping the process as the center of the universe. Now, in such an implementation, you are not paying attention to will this control application work with this type of asset? Will this control application, Let's say, for example, I have a... heat exchanger from xyz vendor and tomorrow i want to replace this uh heat exchanger from this xyz vendor with another vendor now is your control application capable enough to handle this rather if you are making it based on an asset in your overall system you know that this asset is going to change and you bring in a new asset the only thing that you you have to touch upon in your control application is okay how do i make my control my previous asset uh modeling of this control tailored to this asset so the the focus here is shifting from the process to asset that means you are doing your process control considering what the what assets are actually running the process so which which kind of helps you make sure that the control application is performing it to its best considering the abilities and considering the functioning of the asset and you keep improving it with historical data by analyzing the historical data and a lot of these things so this is this is one way of looking at it and the other thing is until now for example i was visiting few plants and i was a commissioning engineer before always the technicians had a complaint saying oh if i go to the control room it's only the operator screen that i see there now if i want to look at the diagnostics of the let's say a valve and understand why the valve is struck I need to walk up to the valve. I connect my diagnostic tool to that and then look at it. Rather, if you're designing your application and if you're doing your automation application based on what type of valve it is, and then you create different facets of this asset, the corresponding actor can come, look up to this facet, and then say, okay, now I know what to do.

• Speaker #1

  So really have something which is, let's say, tailored to the one who is using or actually, yeah. having that information basically.

• Speaker #0

  Yeah and then the programming tool should have the ability for example let's say you realized you don't need a particular information before and you now realize that okay I need to have this view of the asset for some reason then the engineering tool if it is created and developed to do this asset based control then you can quickly bring in this new view, new facet and then say, okay, here it is. You can use it.

• Speaker #1

  So without having to reprogram everything or without having to do any changes, actually, it's already pre-made, let's say. Okay, quite interesting. And I loved as well your point about, let's say, software-defined, because I hear that this is a lot. Let's say it's kind of the buzzword today on the market. Everyone is going software-defined. I tend to see that you made a point on paying attention, okay, what means software-defined, and how do we understand it, and this hardware independence, especially that we see that, yeah, others are using software-defined, but it's still kind of...

• Speaker #0

  Yeah, being hardware-independent, this is what we need to understand, Greg. Being hardware-independent doesn't mean it is software-defined, right? Yeah. for something to be truly software defined you should be able to create and develop what you want to do whether it's a control application whether it is a analytics application whatever it is you should be able to develop it or use start creating it without really considering what hardware on which I'm going to run it, what platform on which I'm going to run it or do I have to change my application if let's say I switch from one type of Ivo to the other type of Ivo. So the freedom to think and develop your application without considering end of the day what hardware is going to end up in the industry or the factory that's when it is let's say, through software-defined automation.

• Speaker #1

  And the freedom goes as well until the vendor as well of the automation platform. I mean, not to be one, yeah, locked to one vendor. Okay, good, great. Thank you, Saad. I don't see any other question in the chat. So I will thank the audience and thank you all for joining this session of UAO Goes Live. We hope you enjoyed learning about asset-based. asset-oriented, asset-centric automation, and how IC64099 makes these strategies possible. A big thank to you, Sarath, again, for sharing your expertise. And I would like, if you would like to learn a bit more, don't hesitate to visit our website and to watch again these episodes on either LinkedIn, YouTube, or as a podcast. Don't follow too... Do not forget to follow our page for upcoming updates and upcoming episodes. And for sure, the community of Universal Automation Network is open and is now, by the way, on Reddit. So don't hesitate to go there, follow us and join the conversation. And I wish you a very nice, very good end of the day and see you soon. Bye bye.

• Speaker #0

  Yeah. Also, thanks from my side for. listening to us and for encouraging us to bring you more and more concepts of this type. Feel free to send your feedback even in emails or whatever way it is possible. It's not a must that it needs to come out here as a question. If you have a question, please don't hesitate to write to us and we'll be happy to get back to you.