Living on the Edge

Speakers

Francisco Carrion

General Manager

iControls

Phil Seboa

Sales and Marketing

iControls

The iControls team explore the Edge-to-Enterprise Architecture, showcasing the deployment and configuration of the different flavors of the edge licensing, from a single machine level HMI to an enterprise architecture where each edge gateway becomes a reliable source of data from the process, through either gateway network services or MQTT implementation.

Transcript:

00:05 
Phil Seboa: Welcome to today's ICC live session, “Living on the Edge” presented by iControls, the authorized Ignition distribution partner based in Brisbane, Australia. Today we have a step-by-step guide exploring the edge-to-enterprise architecture, showcasing the deployment and configuration of the different flavors of the Ignition Edge licensing model. From a single machine-level HMI to an enterprise architecture where each edge gateway becomes a reliable source of data from the process. The connections will be made via Gateway Network Services protocol and MQTT. Your presenters today will be Francisco Carrión, our General Manager, who has in the past 25 years founded a leading system integration company in South America and is now utilizing those skills to develop the Australian Ignition community, and myself, Phil Seboa. I am responsible for the sales and marketing here at iControls and have a passion for IIoT and Industry 4.0 techniques and implementation.

01:22
Phil Seboa: The aim of today's session is to create a step-by-step guide from edge to enterprise. Step one will see me install and configure an Ignition Edge server. This will enable the edge to be able to run in isolation. This typically might be a HMI or local machine-type application. Francisco, in step two, will explain how we install and configure the central server to act as an enterprise view of the system. We will show you how you can speed up development by utilizing the edge project to visualize the data collected. We will also give you the steps to configure the Sync Services Module that allows data to be sent from the central server over the Gateway Network.

02:12
Phil Seboa: Step three, I will showcase how we, again, utilize the Ignition Edge projects that we've developed, but alter it so it is now communicating by the MQTT protocol. This will use the Edge IIoT Module and we will also configure the central server to include the MQTT Engine and MQTT Distributor computer modules. We will then showcase many of the features that MQTT offers, including store and forward. Let's look at step one. We'll install and configure the edge gateway and create a device simulator. This is a perfect example for a standalone operation like a pump station, an oil and gas skid, or a production line, all applications where you need high availability. Next, we will create a visualization within Ignition's designer and create the tag structures, UDTs, views, and bindings. We will also configure the tag alarms and alarm table.

03:26
Phil Seboa: First, we need to execute the Ignition setup wizard. This is freely available to download from the Inductive Automation website. The installation wizard allows us to install the Ignition Gateway without any need for configuration, and the installation takes less than two minutes, and we can get underway with our product. Once the gateway is started, we need to navigate to our browser of choice. We need to connect to our local host at port ADFV8. You'll be prompted with the selection request of which version you want to install. In this case, we'll be installing Ignition Edge. You'll need to read and accept the licensing agreement, and then the next step is to create the credentials for the edge gateway. Make sure you remember your password, as it can be tricky to reset later. Once this is entered, we can start the gateway. Success, we have successfully deployed our first Ignition gateway and we'll be greeted by the gateway homepage. You'll notice that you have a trial banner across the top of the window. Until the server is licensed, it will run under the unlimitedly resettable two-hour trial window. To access the configuration tab on the left-hand side, we need to log in with the credentials we just created.

04:54
Phil Seboa: The first step in configuring your Ignition Edge gateway is to rename the server. This is advisable to give context to your system architecture. We navigate to the settings tab and input our new server name. We need to update the visualization module we want to use. We, in this instance, we'll be using the Perspective Module, so we select this from the dropdown, and then we save our changes. Next, we're gonna navigate to our device settings tab to create our device connection. We'll be using the device simulator for this project. So we select this from the list of available devices and click next. We will then give it a name, a basic description, and then create the device. Next, we will need to edit the program. We choose to utilize a CSV file to load the simulation. You can then edit the file if required.

06:47 
Phil Seboa: From there, we need to install the Ignition designer. This is the design ecosystem that you will use to develop your screens, known as views, and create your application. The designer can be installed on any machine on the network, whether it be a Windows or Mac. Follow the step-by-step guide for the installation. Once the installation is completed, the Ignition Design Launcher will appear. This launch environment gives you access to any gateway on the network. You can also define remote gateway access through the launcher. We will be adding our gateway here. You can also create a shortcut to your server by clicking on the more menu in the top right corner of the gateway card for quicker access. The designer will now require you to log in with your credentials and load the design environment.

08:25
Phil Seboa: Now we are going to add our first UDT. The UDT or user defined template allows you to create a common data structure that can be replicated based on the parameters you set. We need to navigate to the Browser Devices button in the Tag Browser and find our tag simulator, add our motor tag to the UDT definitions in the Edge tag provider. We will then customize the motor name to remove the number and add a parameter for the motor number.

09:05
Phil Seboa: We will then alter the UDT's OPC path to make it dynamic based on the motor number parameter we just created. We will do this for all the structures that rely on this relationship.

09:43
Phil Seboa: Next, we want to create a new expression tag within our tag structure and name it status. This will be an expression tag that monitors if there is a fault on any of the tags within the UDT. We will now use this UDT to create our tags using the Instance Creation Wizard. We enter the base tag name and the range for the tags to be created. We need to enter the range again in the pattern. This will give us a preview of the number of tags and then the list of the tags to create. A great way to add multiple tags without the need to create individual bindings. As you can see, all the tags have now been created in our Tag Browser. We'll now create our first view of the project. This will be our template for the visualization built in Perspective. We'll use a Flex Container to house the components.

11:15 
Phil Seboa: We will now define the size properties in the Property Editor, giving the container its height and width. As this is a template, we need to define the parameters we need to pass into the view. We will call the first one “tag provider.”

11:37
Phil Seboa: You can find the tag provider name on the left hand side of the screen. Next, we will define the parameter motor number. We'll give it a value for one, for now. The first component we will add from our Perspective component palette is a label. Next is a Coordinate Container. This will house our tank. We'll add the tank to the Coordinate Container and size the tank to suit. Next we're gonna bring in a pump. For this project, we are just gonna hide the labels. We'll make this separate from the pump itself. Next we're gonna add another label. Then we're gonna add a multi-stage button and an additional button, and we'll just change the styling on the multi-stage button. Just gonna add some padding around the edge and same for the button. For the label, we are going to create a dynamic tag structure based on an expression. So we're gonna use an expression binding and pass the motor number into the title of the template. Then we're gonna apply some styling into the label. We're gonna do the same for the level label. We're gonna make this an indirect tag binding.

14:36
Phil Seboa: We'll select one of the levels. We're gonna alter the tag path to include some parameters from the view. So this, the first one, is gonna be your tag provider parameter, and then the second one will be the motor number. We are then gonna perform a transform on the value so that it becomes user-friendly and we'll round it to two decimal places. And we're gonna apply some styling. We'll make it center to the view. Next we're gonna configure the multi-stage button. We're going to use an indirect tag binding, again, setting the parameters based on the motor number and tag provider properties. Next, we're gonna copy and paste the tag binding onto our control value and we'll make this bi-directional. The additional button we will use to simulate a fault on the system. We will do this by creating an event script so that when the button is pushed, it'll create an error. Next, we're gonna configure the bindings for the tank and pump visualizations using the previous steps to bind them to the view parameter.

19:28
Phil Seboa: With the pump, we are going to use a map transform to determine the state of the animation of the pump. The parameters that the component will require are string values that include the states: stopped, running, and faulted. We can now check that all the components are working by using the simulation button within the design environment. The next view we will create is the main view. Again, we will need to set the dimensions of the view. We will this time embed a Flex Repeater in this container to house our template view. This all helps all our instances of the template and be driven by the parameter that is passed into it.

21:18
Phil Seboa: We next navigate to the main view in the project browser and add a view parameter. We'll give this the name “tag provider” and set the value to edge. Then inside the Flex Repeater Container, in the main view, you'll bind the tag provider property. We can then duplicate the instances and set the motor numbers we want to display. We need to set the tag provider binding for each of these instances. We can do this by copying and pasting. By un-checking the default values on the widths of the instances, they will then fit the container.

22:46
Phil Seboa: The next step is to set the primary review for the project. Now we can launch the Perspective session, testing that the main view works correctly. Next, we are going to insert an Image Component into our view and make the content of the image based on a URL. We can do this by navigating to the location of the image we want to use. For this example, we are going to use the iControls logo from our webpage. We can copy and paste the location into the source property of the component.

24:15
Phil Seboa: Next, we are going to insert the Alarm Status Table into the project. This component gives you a view of all your alarms within your system, which you manage within the component. We can save and update the project and then view it in our browser. Let's take a look. Next, we need to configure our alarms. All our tags are based on a parent UDT. We only need to configure that parent and it will be applied across all the children. Navigate to the UDT definition and we want to set the alarm based on the fault conditions. We add the alarm and name it “motor fault.” We want the display path to be dynamic based on the motor number property and the fault name, in this case, motor fault.

26:44
Phil Seboa: Next, we nominate the set point to be equal to one. We can now see that the motor, three and four, which are currently in fault condition in our table. It would also show when a fault is created. You can use the Alarm Table to acknowledge when creating a fault.

27:53
Phil Seboa: Now we have completed the alarm configuration. The next step is to configure history. We do this by selecting our view history, selecting history, and enabling it. You can then confirm that history has been configured for all the child tags within the structure. You can do this in the Tag Browser. It will show a symbol next to the tags that have been historised. With this step complete, we have created a standalone edge server. Now Francisco will show how we configure the enterprise central server.

28:48
Francisco Carrión: On step two, we will create an enterprise Ignition server utilizing the Edge project we just created. For this, we will install and configure the central Ignition server using the same installation process as before, and we will use the Quick Start project to create navigation between multiple views. We will then configure the edge server to use the Sync Services Module and create a Gateway Network connection between the edge and enterprise servers. Then we will return to the central system and create a remote tag provider, import the visualization from the Edge project to the main view of the enterprise system, alter the bindings to suit and demonstrate the remote history and store-and-forward functionality.

29:44
Francisco Carrión: Here we will start the installation the same as before, but selecting the Ignition server rather than the Edge. Once this is complete, we want to enable the Quick Start project after logging in. We will again change the server name to give context to the architecture. If you're going to design the central system locally, you can install the designer as we did on step one on the local machine. Or you can use that designer and log directly into the new server over the network. In this case, we will add both servers to the design environment and we can also log into the gateway through our browser.

31:45
Francisco Carrión: With this completed, let's load both, the new central project and the Edge one in our designers using the shortcuts we already created. Once we have both servers installed, we can see that on the central server, we still do not have any of the tags from the Edge. So we need to create a connection between both of the gateways, which in this case is going to create it through the Gateway Network. In order to do that, we are going to go to the Edge instance, and we are going to create an outgoing connection, just to follow the best practice of creating the connection on the lowest hierarchical side of the architecture. We're going to enter the IP for the central gateway, the IP address, so it knows where to connect to. And after we create this outgoing connection, what the Edge is going to do is going to try to initiate communications with the central gateway.

33:13
Francisco Carrión: So we switch to the configuration on the central gateway, and what we need to do is to approve that incoming connection in this case. And we do that through going into the Gateway Network configuration on this gateway and select incoming connections. And then we approve the certificate for the connection that the Edge is requesting at the moment. And afterwards, we need to accept and approve the connection itself. So once we do this, we have both gateways connected and exchanging information through the gateway network. In the central gateway, we will now need to create a real-time remote tag provider connecting the central enterprise to the edge. The central gateway can see the edge remote server, and we can add any of the tag providers in it by selecting and saving the changes. Remember that the Edge only has one provider, so that's the only one that we will be able to select.

34:52
Francisco Carrión: We can see then the remote tags in our Tag Browser, in our enterprise central designer and this will include all the structure we have developed on the edge. Meaning the tags and also the UDTs that create the instances for them. Next we are going to create our main view from the Quick Start project we installed.

35:24 
Francisco Carrión: The Quick Start project is a pre-prepared project that can be used as all the navigation and menus have been set up already. And will help us to speed up the development of this particular project. We will now insert our Edge project by copying and pasting the views into our enterprise system. This will make the screens available for us to embed in our main view in the new central project. We will delete the original large view and replace it with a Flex Container with the same name. We can then embed our Edge project into the home large screen, and we will alter the container size and change the path to point at the Edge main screen. So we can have a view embedded inside of our new main view in the project.

37:21
Francisco Carrión: With Embedded View Component already placed, we need to alter the path of the component to the new locations in our case “edge01/template,” and so we can have access to all the views that are embedded within the Embedded View already.

37:51
Francisco Carrión: Once we have the view already embedded, we can see that we cannot see, still the different motors and that's just because we need to change the path for the edge01 template as we mentioned before, but we still have no data. So we also need to alter the parameters for these views so they point towards the right tag provider, which instead of the Edge, which is the tag provider on the edge gateway, it needs to be altered to the provider that we created here in the central gateway pointing towards the tag provider on the edge. At the moment we correct that and we point towards the correct tag provider, we can see that data is starting to flow between the edge and the central gateway.

39:07
Francisco Carrión: After saving our project and resolving any conflicts, then we can test our screen on our browser and after a while we can see that we have data flowing, so we have data from the tags coming into the screen, but the moment that we try to command, we are going to see that we get an error writing to the tag that we're trying to write and that's because we haven't enabled the write access for the tag provider, so we need to address this. In order to do this, what we need to do is we need to provide a configuration on the service security on the Edge side where we can go into the configuration through the browser and we just select the tag access service within the Gateway Network and change it from read only which is the default value into read, write and edit. This is going to allow any gateway that has a remote tag provider pointing to this Edge instance to be able to write, read, and also edit any of the tags that this tag provider contains. As you can see, after we do this change, we already have control from the central location to any of the tags on the Edge instance. With that configured, then we can test the different features from the edge to be reflected on the central gateway such as alarms where we can visualize the different runtime alarms active at the moment and we can also acknowledge them and whatever other features are enabled such as shelve or filters, we can filter the alarms accordingly.

41:19
Francisco Carrión: Once we have everything configured on the real-time side of our application, now we need to provide a database connection in order for the data to be hosted on our central historian instance. So we will configure the central gateways database connection. We have reconfigured an SQL Express database for this example. Create the connection by entering the correct authentication credentials and point the connection to your relevant table. In this case, we have defined a table that's called “history.” You can now see that the connection is valid after you press save. Now we need to navigate to the history tab just to make sure that the newly created provider is running and available. Within the edge server we can go into the settings to sync the edge to the central now. Since we have a database to point the data to on the central we now need to define the remote history provider. In this case central history which is the one that we created on the central gateway and select the checkbox to allow remote storage of data.

42:56
Francisco Carrión: Once we save the changes, the next what we need to do is to alter the security settings to allow query and storage of the data and save all changes.

43:34
Francisco Carrión: That is pretty much everything that takes for the history to be delivered into the central location. So next we navigate to the central Quick Start project just to confirm that the remote history is coming through. For this we navigate to the Power Chart Component where central history should be available. We can now see that the edge data is flowing through. Now we need to test the backfill functionality by disconnecting the connection from the edge to the central and seeing the trend flatten in the central gateway. At this time, the Edge is going to be using the store-and-forward mechanism to store the local history until the connection is restored. As you can see there is no connection to Edge in central but we still have operation on the Edge entity. So local control is never lost. We will now reconnect the Edge system to the central, demonstrating the store-and-forward capability of the edge. We are going to enable the connection now. The connection is now restored and the backfill of the data is being completed as you can see. This gives you no gaps in your data from the edge. And of course I regain control from the central gateway to the Edge process screens and as well we have the data completed.

46:21
Phil Seboa: Step three, we will utilize the Edge project again but for this example we will configure the Edge IIoT Modules with the use of the Transmission Module. We will configure the central gateway to include Engine and Distributor modules to create an enterprise IIoT network.

46:47
Phil Seboa: Let's get started. We have prepared the second Edge install following the same steps as before. In this case we will rename the server “edge02.” We will again be using the Perspective Module for our visualization. So we select it from the drop down. We now need to install the IIoT module to give us the connectivity we need. We need to download the modules from the Inductive Automation website through the Strategic Partner modules and install the components separately. First we install the Transmission Module to the edge, accepting the license agreement and certificates. This will then refresh the screen and you will notice extra menus have become available on the left-hand side. Once they have installed, check that they are running. Next we are going to install the device simulator through the device connections as we have done in the previous steps. Now we can load our new edge server into our designer. We can again add a shortcut. Launch the designer. We can now export our tags from our original edge server by navigating to our tags browser and selecting export tags from the dropdown.

49:30
Phil Seboa: We can then import these tags in our new IIoT Edge designer. We also want to import our UDT structures to match. And then click apply. We can delete the MQTT tag folder that is in the provider. Next, we need to copy and paste our views from our old project to our new. We can modify the motor numbers within the components to create a second remote edge system. And test everything is working correctly. Next we need to nominate our main view as our landing page and confirm that it is working. Now we have our second site up and running, we need to configure the connectivity portion of the project. Next we need to login to our central system, go to the configuration settings and install the Distributor Module. This is our MQTT broker and we will enable the connectivity from the edge. Next we are going to install the MQTT Engine Module. We are going to use this to be able to subscribe to any topics being published into the broker. As you can see, we now have two additional menus and the modules are running. Next we want to configure the Engine Module in the central server. The Engine has automatically connected to the local broker. In this instance it is our Distributor Module. Within the Transmission settings we need to create a new transmitter.

53:29
Phil Seboa: We will give it a name and allocate a tag provider. We then need to identify the root folder of the topic we want to publish. In this case we will leave it blank to publish all the tags in the provider. As all the MQTT messages will be published in Sparkplug B format as default, this gives you the option to create a group ID, Edge node ID, and device ID. We have now created our first transmitter. We next need to create a server connection to publish the topics into the broker. This is done in the server tab. We need to fill out the credentials for the Distributor broker. So that's the IP address and login and password details. We can now see that we are connected to the broker. We can now see in our central designer that MQTT Engine has subscribed to the topics being published from the edge via the transmitter. With all the UDTs and metadata complete. Now to get data flowing into our visualization, we need to alter the tag provider property within the view. We also need to define which motors we would like to show. We can now see data flowing from the edge into the central via MQTT. So let's give it a test. We can see here that the tags aren't being written down to the edge. So to enable tag writing down to the edge system from the central via MQTT, we need to access the Engine settings within the central gateway.

56:54
Phil Seboa: We need to find and uncheck the block for outbound edge node tag writes and save the changes. We can now see that the tags are being written down to the edge. And we can check this in our Edge designer. For this project we will enable remote history from the central designer. We can alter the UDT structure being used at the edge by selecting central history from the storage providers. You can confirm the changes in the Engine tag provider looking for the clock symbol. All child instances have now been updated for history. Next we need to navigate to our edge server and enable Transmission history. We navigate to our transmitter, scroll down to the history settings and select default in-memory store and save the changes. Now we can test the store-and-forward capabilities of MQTT. Select the tags we want to display in the Power Chart. Again, we will sever the connection by disconnecting the central Distributor connection, disabling Distributor. We can see that no data is flowing from the Distributor. Now we can re-enable the Distributor and get it up and running again. Which will show the backfill via the edge storage. That concludes our Edge to enterprise demonstration, connecting via Gateway Network and MQTT. On behalf of myself and Francisco, I'd like to thank you for joining us on this ICC live session. Thank you.