Performing insightful analytics on production data is a target for manufacturing companies of all sizes. Deciding on what technology to use for the analytics is but one question. Another is where to conduct the analysis. <\/p>\n\n\n\n
Once the decision has been made to perform some level of ongoing \nanalysis of the current and historical data generated by your production\n assets, the analytics decision-making process has only just begun. The \nbiggest decisions revolve around where and how to best conduct those \nanalytics.<\/p>\n\n\n\n
As more companies pursue data analytics, it\u2019s become clear that \nhybrid applications are seen as the optimal choice. The term hybrid, in \nthis instance, refers to a combination of analytics performed by both \nedge and cloud computing platforms. Results from a recent Automation World<\/em>\n survey\u2014conducted for an October 2018 feature on edge, cloud and fog \ncomputing use\u2014reveal that 43 percent of respondents are currently using \nedge computing implementations and 51 percent are using cloud computing.\n Responses to the survey indicate a not-insignificant level of hybrid \ncloud\/edge applications.<\/p>\n\n\n\n But understanding the use of hybrid analytic models only answers part\n of the analytics architecture question. Users still need to determine \nhow to most effectively conduct their data analysis. In other words: In a\n hybrid edge\/cloud analytic environment, what kinds of data should get \nsent to the cloud and what should be analyzed at the edge?<\/p>\n\n\n\n To get more insight into this question, I spoke with Chris Nelson, \nvice president of engineering atOSIsoft, a company long recognized for \nits expertise in plant data analytics. To help make the best \ndetermination of the line dividing what data should go the cloud for \nanalysis and what should be analyzed at the edge, we looked across five \nfactors: speed, reliability, safety, bandwidth and complexity.<\/p>\n\n\n\n Speed<\/strong> Beyond the obvious issues of bandwidth costs and quality of \nconnection, Nelson said the amount and type of data involved, as well as\n the time you have to solve the problem, all come into play.<\/p>\n\n\n\n When considering the amount and type of data to analyze, Nelson said \ntwo initial questions arise: Does it make sense to store it at the edge \nor not? Does this decision need to be made in minutes or could it be \nreviewed for a week or two?<\/p>\n\n\n\n To clarify, Nelson said, \u201cMost predictive maintenance problems can be\n solved at the edge. If an engineer or operator sees a sudden change in \nperformance, he or she can often quickly narrow it down to a few causes.\n The analytics, in that case, are really being supplied by your \nemployee. But let\u2019s say it\u2019s a hugely complex problem, like determining \nwhy a particular factory is more efficient than the other ones and \nwhether or not the practices in that facility can help reduce the \ncapital spend for the next decade. Then you\u2019re talking about a \ngargantuan math problem that\u2019s better solved by running multiple \nscenarios in the cloud. So the demarcation line is really whether you\u2019re\n looking at a human-scale problem or whether you need algorithms to \nreally solve the problem.\u201d<\/p>\n\n\n\n Reliability & Safety<\/strong> \u201cShell, for instance, has created a system to monitor the performance\n and health of its blow out preventers in real time at a control desk,\u201d \nNelson noted as an example of an edge computing application in this \narea. \u201cIf there is a sudden surge or problem, it can cap the well \nimmediately. With this system, Shell can see real-time performance as \nwell as study performance over time. Likewise, quality and product \nsafety in food, pharma and water are classic edge computing problems. If\n something is going wrong with the production of a pharmaceutical\u2014let\u2019s \nsay the process is deviating because of environmental factors or a \nchange in the mixture of materials\u2014you want to know immediately. You can\n halt production, fix the issue and prevent what could be a costly and \ncomplex recall.\u201d<\/p>\n\n\n\n The cloud can play a role in reliability and safety issues when it \ncomes to long-term diagnostics, said Nelson. \u201cFor example, is there \nsomething in your system causing a recurring problem that could be \nchanged to fix that issue on a permanent basis?\u201d<\/p>\n\n\n\n Bandwidth<\/strong> Nelson noted that some companies are using LTE to mitigate the cost \nissue of sending large amounts of data to the cloud. \u201cSempra Energy \nrecently rolled out an experimental LTE network with Nokia and OSIsoft \nin the Broken Bow II wind farm in Nebraska,\u201d he said. \u201cIf one of the \npitch bearing units goes, it can cost $150,000. With OSIsoft\u2019s PI System\n data and LTE, Sempra can detect the problem before it fully blossoms \nand fix it for up to 90 percent less.\u201d<\/p>\n\n\n\n Complexity<\/strong> In his first example, he referred to MOL, a large oil refiner based \nin Hungary. \u201cOverall, they track around 400,000 data streams or tags \nwith the PI System. At one point MOL was experiencing a high temperature\n hydrogen attack. Essentially, that\u2019s when loose hydrogen molecules in a\n reactor get embedded into the steel walls and start to weaken them. \nEngineers saw the corrosion, suspected it might be a hydrogen issue and \nconfirmed it with PI data. They also used the system to track the \nprogress of the fix. They were able to roll it out to six units within a\n week. When that trial succeeded, they rolled it to 50 units. This was \nan example of engineers using PI to solve the problem locally\u2014at the \nedge\u2014and then replicate it. Later, MOL came up with the idea of using \nhigher sulfur opportunity crudes in its system. This had the potential \nto create problems because MOL\u2019s production line was designed for higher\n grade crudes. Determining whether or not to use opportunity crudes, \nhowever, is a titanic math problem involving different simulations and \nscenarios. How will the daily volume change? Will this increase wear and\n tear and therefore maintenance costs? What happens if overall market \nprices dip? To address these questions, MOL took PI System data at the \nedge and shuttled it to Microsoft Azure. This analysis program is \nunderway.\u201d<\/p>\n\n\n\n For a second example, Nelson referenced a problem Deschutes Brewery \nwas having with one of its beers being over-fermented. \u201cBy using the PI \nSystem and an additional sensor, it basically found a zone in the tank \nwhere the yeast was too active. A fix was installed that also reduced \nbrewing time, allowing Deschutes to produce roughly $400,000 worth of \nadditional beer on the same line.\u201d This is an example of an edge \ncomputing analytics application that improved production for the \nbrewery.<\/p>\n\n\n\n Following this success, Deschutes then wanted to study the \nfermentation cycle of each beer. They wanted to know things like: At \nwhat point does its Fresh Squeezed IPA hit a specific alcohol content \nand how is that different from its Black Butte Porter? \u201cThat\u2019s a math \nproblem better solved in Azure,\u201d said Nelson.<\/p>\n\n\n\n To help summarize the edge\/cloud analysis dividing line question, \nNelson suggested approaching the issue this way: \u201cIf the problem is \nsomething users could solve on their own with good sources of \ninformation, focus the analysis at the edge. If you\u2019re talking about 15 \ndifferent data streams and multiple variables, it\u2019s a problem better \nsuited for the cloud.\u201d<\/p>\n\n\n\n Performing insightful analytics on production data is a target for […]<\/p>\n","protected":false},"author":1,"featured_media":1243,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,9],"tags":[],"yoast_head":"\n