Asset reliability and continuous health monitoring (ARCH) platform

Abstract

A server includes a communication interface configured to communicate with a plurality of assets and a plurality of computing devices, a memory storing an asset reliability and continuous health monitoring (ARCH) platform software, and an electronic processor. The processor is configured to receive asset information from the plurality of assets, control a database to store the asset information, and generate a ticket embedding ticket information based on the received asset information, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets. The electronic processor further generates a graphical user interface for display on an electronic display of one of the plurality of computing devices, the interface informing a user of the one or more recommendations.

Description

ASSET RELIABILITY AND CONTINUOUS HEALTH MONITORING (ARCH) PLATFORMCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 677,853, filed on July 31, 2024, the entire contents of which is hereby incorporated by reference.FIELD

[0002] The present disclosure relates generally to an asset reliability visualization platform. More specifically, the present disclosure relates to an asset reliability and continuous health monitoring platform.SUMMARY

[0003] The Asset Reliability and Continuous Health Monitoring platform (also referred to herein as “ARCH platform”), represents a significant innovation in the realm of Asset Reliability & Digitalization (AD&R). The ARCH platform addresses a critical need within this domain by providing a centralized platform capable of hosting a diverse array of use cases. The motivation behind the ARCH platform development stems from the recognition that existing solutions failed to fully meet the multifaceted requirements of AD&R initiatives. Prior to the ARCH platform, end users often found themselves navigating a maze of disparate platforms, each tailored to a specific use-case. This fragmented landscape not only impeded efficiency but also hindered the realization of AD&R’s full potential. The ARCH platform seeks to rectify this by offering a single, unified platform where users can access all relevant functionalities with just one platform.

[0004] However, the ARCH platform goes beyond mere consolidation because the ARCH platform introduces a host of innovative features (based on what were previously separate and disparate platforms) that sets the ARCH platform apart from conventional visualization platforms. The existing platforms lack the specialized capabilities needed to fully support AD&R initiatives. The ARCH platform overcomes the deficiencies of the existing platforms by incorporating functionalities specifically tailored to the unique requirements of the AD&R team. These features encompass advanced analytics, predictive maintenance algorithms, real-timemonitoring capabilities, and seamless integration with a variety of data sources. By providing a comprehensive suite of tools within a single platform, the ARCH platform empowers users to derive deeper insights, make more informed decisions, optimize the performance of different assets, and implement various user and / or machine control signaling (e.g., work orders, machine controls, or other suitable control signaling).

[0005] One of the key strengths of the ARCH platform lies in its ability to facilitate crossfunctional collaboration and knowledge sharing. By serving as a centralized hub for all AD&R activities, the ARCH platform fosters synergy among different teams and departments within an organization. The ARCH platform provides a common platform where stakeholders (e.g., maintenance technicians, engineers, data scientists, or operations managers, or other suitable stakeholders) may collaborate, share insights, and work towards common goals. This collaborative approach not only enhances operational efficiency but also promotes a culture of innovation and continuous improvement.

[0006] Moreover, the ARCH platform is designed with scalability and flexibility in mind, ensuring that the ARCH platform adapts to evolving needs and technological advancements. The ARCH platform’s modular architecture allows for easy customization and expansion, enabling the platform to be tailored to specific requirements. The ARCH platform’s customization includes adding new use-cases, integrating with third-party systems, or scaling up to accommodate growing data volumes.

[0007] In summary, the ARCH platform represents a paradigm shift in the field of AD&R, offering a centralized platform that addresses the diverse needs of asset reliability and continuous health monitoring of the different assets. By consolidating disparate functionalities and disparate platforms into a single platform, the ARCH platform streamlines operations, fosters collaboration, and enables organizations to unlock new levels of efficiency and performance as well create new features as described in greater detail below.

[0008] In some aspects, an embodiment relates to a server including: a communication interface configured to: communicate with a plurality of assets, and communicate with a plurality of computing devices; a memory storing an asset reliability and continuous health monitoring (ARCH) platform software; and an electronic processor communicatively connected to thememory, the electronic processor configured to receive asset information from the plurality of assets, control a database to store the asset information, generate a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets, and generate a graphical user interface that is displayed on an electronic display of one of the plurality of computing devices, the graphical user interface informing a user of the one or more recommendations.

[0009] In some aspects, another embodiment relates to a system including: a plurality of assets; a plurality of computing devices; and a server including a communication interface configured to: communicate with the plurality of assets, and communicate with the plurality of computing devices; a memory storing an asset reliability and continuous health monitoring (ARCH) platform software; and an electronic processor communicatively connected to the memory, the electronic processor configured to receive asset information from the plurality of assets, control a database to store the asset information, generate a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets, and generate a graphical user interface that is displayed on an electronic display of one of the plurality of computing devices, the graphical user interface informing a user of the one or more recommendations.

[0010] In some aspects, another embodiment relates to a method including: receiving, with an electronic processor, asset information from a plurality of assets; controlling, with the electronic processor, a database to store the asset information; generating, with the electronic processor, a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets; and generating, with the electronic processor, a graphical user interface that is displayed on an electronic display of a computing device, the graphical user interface informing a user of the one or more recommendations.

[0011] In some aspects, another embodiment relates to a non-transitory computer-readable medium including instructions that, when executed by an electronic processor, cause the electronic processor to perform a set of operations including: receiving asset information from a plurality of assets; controlling a database to store the asset information; generating a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets; and generating a graphical user interface that is displayed on an electronic display of a computing device, the graphical user interface informing a user of the one or more recommendations.

[0012] Other aspects of the embodiments will become apparent by consideration of the detailed description and accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. l is a block diagram illustrating an example system including an asset reliability and continuous health monitoring (ARCH) platform, in accordance with various aspects of the present disclosure.

[0014] FIG. 2 is a flow diagram illustrating an example software architecture of the ARCH platform of FIG. 1 , in accordance with various aspects of the present disclosure.

[0015] FIGS. 3-28 are example graphical user interfaces illustrating the insights, reporting, and analytics generated and output by the ARCH platform of FIG. 1, in accordance with various aspects of the present disclosure.

[0016] FIG. 29 is a flowchart illustrating an example method performed by the example system of FIG. 1, in accordance with various aspects of the present disclosure.DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

[0017] Before any embodiments of the present disclosure are explained in detail, it is to be understood that the present disclosure is not limited in its application to the details of construction and the arrangement of components set forth in the following description orillustrated in the following drawings. The present disclosure is capable of other embodiments and of being practiced or of being carried out in various ways.

[0018] FIG. 1 is a block diagram illustrating an example system 10 including an asset reliability and continuous health monitoring platform, in accordance with various aspects of the present disclosure. It should be understood that, in some embodiments, there are different configurations from the configuration illustrated in FIG. 1. The functionality described herein may be extended to any number of servers providing distributed processing.

[0019] In the example of FIG. 1, the example system 10 includes a server 100, a plurality of assets 120A-120N (may be collectively referred to as “asset 120”), and a plurality of computing devices 13OA-13ON (may be collectively referred to as “computing device 130”). In some examples, the plurality of assets 120A-120N are individually a motor, a pump, a controller, or other suitable asset that either has a degree of “health” that may be monitored or is capable of performing health monitoring of another device. In some examples, the plurality of assets 120A-120N may be located in a single location (e.g., located at a single plant or warehouse). In other examples, the plurality of assets 120A-120N may be located in a plurality of locations (e.g., located a plurality of plants or warehouses in one or more countries).

[0020] In some examples, the plurality of computing devices 130A-130N are individually a server, a personal desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch, or other suitable computing device. In some examples, one of the plurality of computing devices 130A-130N is a smartphone of a maintenance personnel that receives information from the server 100. In other examples, one of the plurality of computing devices 130A-130N is a server of a third-party database that provides information to the server 100.

[0021] The server 100 includes an electronic processor 102 (for example, a microprocessor or another suitable processing device), a memory 104 (for example, a non-transitory computer- readable storage medium), and a communication interface 112. It should be understood that, in some embodiments, the server 100 may include fewer or additional components in configurations different from that illustrated in FIG. 1. Also, the server 100 may perform additional functionality than the functionality described herein. In addition, the functionality of the server 100 may be incorporated into other servers. As illustrated in FIG. 1, the electronicprocessor 102, the memory 104, and the communication interface 112 are electrically coupled by one or more control or data buses enabling communication between the components.

[0022] The electronic processor 102 executes machine-readable instructions stored in the memory 104. For example, the electronic processor 102 may execute instructions stored in the memory 104 to perform the functionality described herein.

[0023] The memory 104 may include a program storage area (for example, read only memory (ROM)) and a data storage area (for example, random access memory (RAM), and other non-transitory, machine-readable medium). In some examples, the program storage area may store the instructions regarding an asset reliability and continuous health monitoring platform software 106 (hereinafter referred to as “ARCH platform 106”).

[0024] The ARCH platform 106 has machine-readable instructions that cause the electronic processor 102 to receive (e.g., retrieve) and process asset information from the plurality of assets 120A-120N and generate information (e.g., ticket and ticket information) based on the asset information. In some examples, the electronic processor 102, in performing the ARCH platform 106, uses machine learning to generate and output insights, data visualization (e.g., operation reporting and analytics), and operation recommendations. Additionally, in some examples, the asset information received from the plurality of assets 120A-120N (or retrieved from a database (not shown)) may include telemetry data, sensor data, machine data, control signals, I / O data, tag data, real-time data, operational technology (OT) data, other suitable data, or a combination thereof.

[0025] Machine learning generally refers to the ability of a computer program to learn without being explicitly programmed. In some embodiments, a computer program (for example, a learning engine) is configured to construct an algorithm based on inputs. Supervised learning involves presenting a computer program with example inputs and their desired outputs. The computer program is configured to learn a general rule that maps the inputs to the outputs from the training data it receives. Example machine learning engines include decision tree learning, association rule learning, artificial neural networks, classifiers, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity and metric learning, sparse dictionary learning, and genetic algorithms.Using one or more of the approaches described above, a computer program can ingest, parse, and understand data and progressively refine algorithms for data analytics.

[0026] The communication interface 112 receives data from and provides data to devices external to the server 100, such as the plurality of assets 120A-120N and the plurality of computing devices 130A-130N. For example, the communication interface 112 may include a port or connection for receiving a wired connection (for example, an Ethernet cable, fiber optic cable, a telephone cable, or the like), a wireless transceiver, or a combination thereof. In some examples, the communication interface 112 may communicate with one or more of the plurality of assets 120A-120N and the plurality of computing devices 130A-130N via the Internet.

[0027] In some examples, the server 100 includes one or more graphical user interfaces (as described in greater detail below and illustrated in FIGS. 3-28). The one or more graphical user interfaces (e.g., one or more webpages) including graphical elements that allow a user of a computing device 130 to interface with the server 100. The one or more graphical user interfaces may include, or be part of, a display screen that displays the insights, and the reporting and analytics generated and output by the electronic processor 102 in performing the ARCH platform 106.

[0028] FIG. 2 is a flow diagram illustrating an example software architecture 200 of the ARCH platform 106 of FIG. 1, in accordance with various aspects of the present disclosure. FIG. 2 is described with respect to FIG. 1.

[0029] The software architecture 200 includes data sources 202. The data sources 202 may include enterprise resource planning (ERP) systems, sensors, programmable logic controller (PLCs), SCADA databases, and / or other suitable data sources.

[0030] The data sources 202 (e.g., the plurality of assets 120A-120N and / or the plurality of computing devices 130A-130N) output information that is transformed by the edge system (at operation 204).

[0031] The data sources 202 (e.g., the plurality of assets 120A-120N and / or the plurality of computing devices 130A-130N) output information that is ingested by the server 100 (atoperation 206). Specifically, the server 100 ingests the information as part of a “data factory” and outputs ingested information to a data lake storage (at operation 208) and performs data aggregations (at operation 210). The server 100 also stores temporary data in the data lake storage (at operation 208).

[0032] The server 100, using a machine learning / Al platform, retrieves and processes data stored in the data lake storage (at operation 212) and generates data reports (at operation 214). The server 100 outputs the data reports as part of the ARCH platform via a website or mobile application (at operation 214).

[0033] FIGS. 3-28 are example graphical user interfaces 300-2800 illustrating the insights, reporting, and analytics generated and output by the ARCH platform of FIG. 1, in accordance with various aspects of the present disclosure. As explained above, some or all of the example graphical user interfaces 300-2800 may include, or be part of, an electronic display screen that displays the insights, reporting, and analytics output by the ARCH platform 106.

[0034] As illustrated in FIG. 3, a first example graphical user interface 300 includes a user management section 302 of the ARCH platform. The user management section 302 is based on information of a user database. The user management section 302 allows an administrator to add / remove / modify a user to / from / within the user database.

[0035] As illustrated in FIG. 4, a second example graphical user interface 400 includes a user role assignment section 402 of the ARCH platform. The user role assignment section 402 includes a number of roles, for example, 1) ARCH admin, 2) Asset Manager, 3) Developer, 4) Leadership, 5) Use case champion, and 6) Plant Manager.

[0036] An ARCH Admin user role will have unrestricted access throughout the ARCH platform. In some examples, the ARCH Admin user role enables the user to be able to: a) manage users and roles (manage notification preferences across all users), b) modify asset hierarchy, c) full access of MonARCH (admin only), d) report creation and modification, e) modify seed configuration, f) view all plant and use case dashboards and the respective reports, and g) view tickets from all plants.

[0037] In some examples, the Asset Manager user role is able to: a) give access to view reports at the assigned asset levels only and b) view tickets pertaining to the assigned asset. The Asset Manager user role has no modification rights.

[0038] In some examples, the Developer user role is able to: a) modify asset hierarchy, b) report creation and modification, c) modify seed configuration, d) view all plant and use case dashboards and the respective reports, and e) view tickets from all plants.

[0039] In some examples, the Leadership user role does not have any modification privileges. The Leadership user role is able to: a) view reports and dashboards for all plants and use cases, b) view tickets from all plants (no commenting / assigning capability). The Leadership role does not have access to MonARCH.

[0040] In some examples, the Use-case Champion user role is able to: a) give complete access at a use case level to view all Plants pertaining to a use case, b) can see tickets pertaining to a use case. The Use-case Champion user role does not have any administrator level modification privileges.

[0041] In some examples, the Plant Manager user role is able to a) give full access to the user at the plant level only and b) can assign / comment on tickets. The Plant Manager role does not have any modification privileges.

[0042] In some examples, more user roles or less user roles may be listed than these six user roles. For example, additional user roles may include SAT lead and Supply Chain Admin.

[0043] As illustrated in FIG. 5, a third example graphical user interface 500 includes an preferences section 502 of the ARCH platform. Once a user is added in ARCH; every user is able to customize the way they receive notifications. The notification options include 1) email notification, 2) Microsoft Teams notification, 3) text message notification, 4) web notifications, and / or 5) any other suitable notification.

[0044] In some examples, the type of notification to review may also be selected. For example, the type of notification to review may be “All Notifications,” “Only Alarm level and Danger level alerts,” or “Only Danger level alerts.”

[0045] As illustrated in FIG. 6, a fourth example graphical user interface 600 includes an asset pool section 602 of the ARCH platform. The asset pool section 602 is where assets get created in the ARCH platform in order to monitor the newly created asset. Unlike conventional platforms, the ARCH platform monitors both main assets (blow molder and filler), and more importantly, granular level assets such as motors, pumps, valves, transmitters, or other suitable granular level assets.

[0046] As illustrated in FIG. 7, a fifth example graphical user interface 700 includes a visualizations section 702 of the ARCH platform. Visualizations are a very important piece in the ARCH platform. Visualizations allow us to show insight to the end user visually. Custom visualizations were limited with the different platforms out in the market. In some examples, the visualizations section 702 includes a plurality of visualizations: 1) an Area Chart, 2) a Bar chart, 3) a Column chart, 4) a Donut chart, 5) a Gauge, 6) a KPI, 7) a Line and Column chart, 8) a Line chart, 9) a Pie chart, 10) a Stacked Bar chart, 11) a Stacked Column chart, 12) a Table, 13) a Tachometer, and 14) a Waterfall chart. The ARCH platform is not limited to these fourteen different visualizations and implement any other suitable visualization.

[0047] The ARCH platform is also able to visualize up to three years of data. In order to be able to visualize that much data, there are aggregations based off the selected time range within 10 seconds. The ARCH platform also can render 20,000 data points and visualize in the given format i within 10 seconds as soon as user queries the data to provide great user experience.

[0048] A first example aggregation may be a five-minute aggregation (1 - 14 days). As illustrated in FIG. 8, a sixth example graphical user interface 800 is a five-minute aggregation visualization section 802 over the “last 2 weeks” and includes several example charts 804-814 based on asset information with respect to “BLOWMOLDER - Heating Mod Belt End 1.” A first example chart 804 illustrates the drive X axis velocity. A second example chart 806 illustrates the gearbox X axis velocity. A third example chart 808 illustrates the drive X axis velocity alarm. A fourth example chart 810 illustrates the gearbox X axis velocity alarm. A fifth example chart 812 illustrates the drive X axis velocity warning. A sixth example chart 814 illustrates the gearbox X axis velocity warning.

[0049] A second example aggregation may be an hourly aggregation (15 - 90 days). As illustrated in FIG. 9, a seventh example graphical user interface 900 is an hourly aggregation visualization section 902 over the “last 90 days” and includes several example charts 904-914 based on asset information with respect to “BLOWMOLDER - Heating Mod Belt End 1 ” A first example chart 904 illustrates the drive X axis velocity. A second example chart 906 illustrates the gearbox X axis velocity. A third example chart 908 illustrates the drive X axis velocity alarm. A fourth example chart 910 illustrates the gearbox X axis velocity alarm. A fifth example chart 912 illustrates the drive X axis velocity warning. A sixth example chart 914 illustrates the gearbox X axis velocity warning.

[0050] A third example aggregation may be a daily aggregation (90+ days). As illustrated in FIG. 10, an eighth example graphical user interface 10000 is a daily aggregation visualization section 1002 over the “last 6 months” and includes several example charts 1004-1014 based on asset information with respect to “BLOWMOLDER - Heating Mod Belt End 1.” A first example chart 1004 illustrates the drive X axis velocity. A second example chart 1006 illustrates the gearbox X axis velocity. A third example chart 1008 illustrates the drive X axis velocity alarm. A fourth example chart 1010 illustrates the gearbox X axis velocity alarm. A fifth example chart 1012 illustrates the drive X axis velocity warning. A sixth example chart 1014 illustrates the gearbox X axis velocity warning.

[0051] As illustrated in FIG. 11, a ninth example graphical user interface 1 100 includes a standard and custom date range section 1102 of the ARCH platform. The standard and custom data range section 1102 includes the following date ranges 1) last 12 hours, 2) last 24 hours, 3) last 2 days, 4) last 7 days, 5) last 2 weeks, 6) last 30 days, 7) last 90 days, 8) last 6 months, 9) last 1 year, 10), last 2 years, 11) last 3 years, and 12) custom date range.

[0052] The ARCH platform provides an ability to annotate any visualization that is produced within the ARCH platform. As illustrated in FIG. 12, a tenth example graphical user interface 1200 is an annotation section 1202 overlaid on a data visualization 1204 over the “last 3 years” and includes one example chart 1004 based on asset information with respect to “BLOWMOLDER - Discharge Starwheel.” The first example chart 1004 illustrates the nondrive Z axis Hi Frequency Acceleration. This is a unique, user friendly, and helpful feature tocapture the status / condition / context of the specific data point by annotating the visualization and storing the annotation in the database for further improvement / development of the model as well as future reference by users.

[0053] The ARCH platform provides an ability to zoom in on any visualization that is produced within the ARCH platform. As illustrated in FIG. 13, an eleventh example graphical user interface 1300 is a selected zoom section 1302 overlaid on a data visualization 1304 over the “last 12 hours” and includes two example charts 1306 and 1308 based on asset information with respect to “BLOWMOLDER - Heating Mod Belt End 1 The first example chart 1306 illustrates the drive X axis velocity. The second example chart 1308 illustrates the gearbox X axis velocity.

[0054] As illustrated in FIG. 14, a twelfth example graphical user interface 1400 is a zoomed in visualization section 1402 over the “last 12 hours” and includes two example charts 1404 and 1406 based on asset information with respect to “BLOWMOLDER - Heating Mod Belt End 1 The first example chart 1404 illustrates the drive X axis velocity. The second example chart 1406 illustrates the gearbox X axis velocity. FIG. 14 is a visualization resulting from the action taken with respect to FIG. 13.

[0055] As illustrated in FIG. 15, a thirteenth example graphical user interface 1500 includes a ticket system section 1502 of the ARCH platform. The ticket system section 1502 keeps track of all the conversations / comments / data related to those specific issues that are ticketed. The ticket system section 1502 is a collection of information from assets and plant teams. The ARCH platform includes ticketing logic that generate a ticket for a specific asset (e.g., a motor, a pump, a servo, a valve, a transmitter, or other suitable asset.). The ARCH platform embeds valuation information inside the generated ticket, such as the asset type and reasons why a ticket was generated. Every ticket generated by the ARCH platform uses a common format for the ticket ID 1504: 1) plant initials - number (e.g., RCH-359) which means Richmond ticket 359.

[0056] As illustrated in FIG. 16, a fourteenth example graphical user interface 1600 includes a ticket details section 1602 of the ARCH platform. The ticket details section 1602 lists the embedded information associated with a specific ticket. In some examples, the ticket details section 1602 includes some or all of the following information: 1) a ticket ID, 2) an alert date, 3)anarea / line, 4) an asset name, 5) a motor name, 6) a device status, 7) a previous health, 8) a current health, 9) remaining months, 10) an electrical number, 11) a sensor label, 12) possible cases, and 13) one or more recommendations. In other examples, the ticket details section 1602 includes additional or alternative information depending on the use case.

[0057] The ticket ID is an identification of a specific ticket for communication with plants and / or users. In FIG. 16, the ticket ID is ID #RCH-359.

[0058] The alert date is an identification of the date that an alert was generated. In FIG. 16, the alert date is 03 / 10 / 2024.

[0059] The area / line is an identification of the specific line that has been ticketed. In FIG. 16, the area / line is Line 2.

[0060] The asset name is an identification of the asset. In FIG. 16, the asset name is Capper A.

[0061] The motor name is an identification of the specific motor being monitored. In FIG. 16, the motor name is Cap Buffer 2.

[0062] The device status is an identification of the asset’s current data collection status. In FIG. 16, the device status is connected.

[0063] The previous health is a value generated by a machine learning model that shows the previous health status for this specific asset. In FIG. 16, the previous health is 7.

[0064] The current health is a value generated by a machine learning model that shows the current health status for this specific asset. In FIG. 16, the current health is 4.

[0065] The remaining months is a value generated by a machine learning model that shows how many months until this asset is expected to fail. In FIG. 16, the remaining months is 33.

[0066] The electrical number, when available, is the electrical identifier for this specific asset. In FIG. 16, the electrical number is CATID: VSZ21.6001+PSF1-MTR102.

[0067] The sensor label, when available, shows the sensor number. In FIG. 16, the sensor label is Drive: DXM4 R46121.

[0068] The possible cases show information on why the alert was generated for this specific asset. In FIG. 16, the possible cases is “High temperature can lead to an Overheating Failure.”

[0069] The recommendations show recommendations on how to fix this specific asset. In FIG. 16, the recommendations is “Imbalance - Check that the foundation has a good center of mass. Misalignment - Check if the motor / gearbox drive shaft is aligned correctly to the load. Looseness - Check the tightness of the motor to its base plate. Overheating - Check the ambient temperature that the motor is running at. Check that the ventilation holes of the motor are not blocked.”

[0070] As illustrated in FIG. 17, a fifteenth example graphical user interface 1700 includes a ticket status section 1702 of the ARCH platform. The ticket status section 1702 lists the status associated with a specific ticket. In some examples, the ticket status section 1702 is one of: 1) In Progress, 2) Resolved, 3) Open, 4) False Alert, and 5) Under Maintenance. In other examples, the ticket status section 1702 includes additional or alternative statuses depending on the use case.

[0071] Open is the default ticket status for any new ticket generated. In-progress indicates a team is planning to check out the asset during next possible window. Under Maintenance indicates an issue was found during the inspection of the asset, plant teams planning to resolve the issue. Resolved indicates task was completed, and the issue is resolved. False Alert indicates prediction was incorrect or ticket was generated due to data discrepancy.

[0072] As illustrated in FIG. 18, a sixteenth example graphical user interface 1800 includes a ticket assignment section 1802 of the ARCH platform. The ticket assignment section 1802 lists people that may be assigned a specific ticket. When a person is assigned the specific ticket, the server 100 may notify the person according to their selected notification settings.

[0073] As illustrated in FIG. 19, a sixteenth example graphical user interface 1900 includes a ticket comments section 1902 of the ARCH platform. The ticket comments section 1902 allowsusers to provide information (e.g., feedback) about the specific asset associated with the specific ticket. In the ticket comments section 1902, a user may add comments, format comments, tag users, add links, add pictures, add videos, add documents, edit comments, and / or delete comments.

[0074] As illustrated in FIG. 20, a seventeenth example graphical user interface 2000 includes a troubleshooting tool section 2002 of the ARCH platform. The troubleshooting tool section 2002 allows a user to compare multiple datasets on a single graph to create a custom analysis. The feature allows the user to: 1) choose the plant, 2) choose the assets, 3) choose the data points, 4) choose between a table or graph, 5) save the template, and / or 6) export data.

[0075] As illustrated in FIG. 21, an eighteenth example graphical user interface 2100 includes a troubleshooting tool table view section 2102 based on the selections made with the troubleshooting tool section 2002 of FIG. 20. In FIG. 21, the “Aseptic Tank 1” is the selected asset and the “T40TemplePlant_T40AsepticGroup_T40AsepticProcessing_T40AsepticStorage _T40AsepticTankGroup_T40AsepticTankl_T40AsepticTankAIsafeTanklDevices_T40TEl 15_ Temperature PV” and “T40TemplePlant_T40AsepticGroup_T40AsepticProcessing_T40Aseptic Storage_T40AsepticTankGroup_T40AsepticTankl_T40AsepticTankAIsafeTanklDevices_T40T E140_Temperature_PV” are the selected tags.

[0076] Additionally, the troubleshooting tool table view section 2102 includes a table of values regarding the specific asset. In the example of FIG. 21, the values include dates, times, and corresponding temperatures, specifically, “TE115 TEMPERATURE” and “TE140 TEMPERATURE.”

[0077] As illustrated in FIG. 22, a nineteenth example graphical user interface 2200 includes a troubleshooting tool graph view section 2202 based on the selections made with the troubleshooting tool section 2002 of FIG. 20. In FIG. 22, the “Aseptic Tank 1” is the selected asset and the “T40TemplePlant_T40AsepticGroup_T40AsepticProcessing_T40AsepticStorage _T40AsepticTankGroup_T40AsepticTankl_T40AsepticTankAIsafeTanklDevices_T40TEl 15_ Temperature PV” and “T40TemplePlant_T40AsepticGroup_T40AsepticProcessing_T40Aseptic Storage_T40AsepticTankGroup_T40AsepticTankl_T40AsepticTankAIsafeTanklDevices_T40T E140_Temperature_PV” are the selected tags.

[0078] Additionally, the troubleshooting tool graph view section 2202 includes a graph of values regarding the specific asset. In the example of FIG. 22, the values include dates, times, and corresponding temperatures, specifically, “TE115 TEMPERATURE” and “TE 140 TEMPERATURE.”

[0079] As illustrated in FIG. 23, a twentieth example graphical user interface 2300 includes an electrical ID hover section 2302. As illustrated in FIG. 23, when a user places a cursor over an asset, the electrical ID hover section 2302 is shown along with the corresponding electrical ID for that specific asset.

[0080] As illustrated in FIG. 24, a twenty -first example graphical user interface 2400 includes a sensor label hover section 2402. As illustrated in FIG. 24, when a user places a cursor over a drive tape, the sensor label hover section 2402 is shown along with the corresponding sensor label for that specific asset.

[0081] As illustrated in FIG. 25, a twenty-second example graphical user interface 2500 includes a search section 2502. The search section 2502 allows a user to search for a specific asset in the ARCH platform, so the user does not need to spend time manually looking for the asset. The search function will filter the Asset and the Line / Area when there is a match.

[0082] As illustrated in FIG. 26, a twenty-third example graphical user interface 2600 includes a disconnected sensors section 2602. The disconnected sensors section 2602 gives the user a summary of which sensors are disconnected for that Line / Area.

[0083] As illustrated in FIG. 27, a twenty-fourth example graphical user interface 2700 includes an activity log section 2702. The activity log section 2702 allows users with an ADMIN role to view activity logs for access logs, use case logs, asset hierarchy, and MonARCH logs.

[0084] The access logs are logs that show when a user is added, role is updated, or removed from the ARCH platform. The use case logs are logs that show the total number of active users and the total number of users on the ARCH platform. These logs also show what areas of ARCH the user is utilizing (reports, ticket system, or account settings). The asset hierarchy logs are logsthat show if any changes were made to an asset by a specific user. The MonARCH logs are logs that show what modules are being used in MonARCH.

[0085] As illustrated in FIG. 28, a twenty-fifth example graphical user interface 2800 includes a use cases section 2802. The use cases section 2802 hosts as many use-cases as needed within the organization. As mentioned previously, the ARCH platform is flexible and adapts as the number of use-cases increase over time. As illustrated in FIG. 28, there are eleven use-cases in the ARCH platform, where each use-case pulls data from a different source (e.g., a different asset) and different areas (internal or external) to the plant (e.g., different computing devices located internally or hosted by a third-party externally), but all accessed via the ARCH platform.

[0086] In the example of FIG. 28, the eleven uses cases include air leaks use case, aseptic - batch room CCP use case, aseptic - process room CCP use case, aseptic -valves use case, aseptic CIP use case, motors and pumps PdM use case, injection analytics use case, run hours based PM use case, run hours PM use case, servo drives use case, supply chain tickets use case, utilities use case, and WQMS use case. However, the ARCH platform is not limited to eleven use cases and more or less use cases may be implemented with the flexibility of the ARCH platform.

[0087] FIG. 29 is a flowchart illustrating an example method 2900 performed by the example system 10 of FIG. 1, in accordance with various aspects of the present disclosure. In the example of FIG. 29, the method 2900 includes the electronic processor 102 of the server 100 receiving asset information from a plurality of assets (at block 2902).

[0088] The method 2900 includes the electronic processor 102 controlling a database to store the asset information (at block 2904).

[0089] The method 2900 includes the electronic processor 102 generating a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets (at block 2906).

[0090] The method 2900 also includes the electronic processor 102 generating a graphical user interface that is displayed on an electronic display of a computing device, the graphical user interface informing a user of the one or more recommendations (at block 2908).

[0091] In some examples, the ticket information includes a ticket ID, an alert date, an area / line, an asset name, a motor name, a device status, a previous health, a current health, remaining months, an electrical number, a sensor label, possible cases, the one or more recommendations, or a combination thereof.

[0092] In some examples, the method 2900 may include responsive to generating the ticket, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface informing a second user of one or more people that may be assigned the ticket, receiving a selection of a person from the one or more people from the second user, assigning the ticket to the person, and outputting an electronic notification to a computing device associated with the person, the electronic notification including the ticket information.

[0093] In these examples, outputting the electronic notification to the computing device associated with the person may further include retrieving notification settings of the device associated with the person, and outputting the electronic notification according to the notification settings that are retrieved.

[0094] In some examples, the method 2900 may further include responsive to receiving the asset information, generating a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying a portion of the asset information to a second user, receiving an annotation request from the second user, responsive to receiving the annotation request from the second user, generating a third graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying an annotation tool to the second user, receiving, with the annotation tool, one or more annotations from the second user regarding the portion of the asset information, and controlling the database to the store the one or more annotations and link the one or more annotations to the portion of the asset information for future reference.

[0095] The following are enumerated examples of the various servers, systems, methods, and non-transitory computer-readable media of the present disclosure. Example 1. A server comprising: a communication interface configured to: communicate with a plurality of assets, and communicate with a plurality of computing devices; a memory storing an asset reliability and continuous health monitoring (ARCH) platform software; and an electronic processor communicatively connected to the memory, the electronic processor configured to receive asset information from the plurality of assets, control a database to store the asset information, generate a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets, and generate a graphical user interface that is displayed on an electronic display of one of the plurality of computing devices, the graphical user interface informing a user of the one or more recommendations.

[0096] Example 2: the server of example 1, wherein the plurality of assets includes two or more assets selected from a group consisting of: a motor, a pump, a servo, a valve, a transmitter, and a programmable logic controller (PLC).

[0097] Example 3 : the server of examples 1 or 2, wherein the plurality of computing devices includes two or more computing devices selected from a group consisting of: a server, a smartphone, a desktop computer, a laptop, a transmitter, and a programmable logic controller (PLC).

[0098] Example 4: the server of any of examples 1-3, wherein the ticket information includes a ticket ID, an alert date, an area / line, an asset name, a motor name, a device status, a previous health, a current health, remaining months, an electrical number, a sensor label, possible cases, and the one or more recommendations, or a combination thereof.

[0099] Example 5: the server of any of examples 1-4, wherein the electronic processor is further configured to: responsive to generating the ticket, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface informing a second user of one or more people that may be assigned the ticket, receive a selection of a person from the one or more people from the second user, assign the ticket to theperson, and output an electronic notification to a computing device associated with the person, the electronic notification including the ticket information.

[0100] Example 6: the server of example 5, wherein, to output the electronic notification to the computing device associated with the person, the electronic processor is further configured to retrieve notification settings of the device associated with the person, and output the electronic notification according to the notification settings that are retrieved.

[0101] Example 7: the server of any of examples 1-6, wherein the electronic processor is further configured to: responsive to receiving the asset information, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying a portion of the asset information to a second user, receive an annotation request from the second user, responsive to receiving the annotation request from the second user, generate a third graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying an annotation tool to the second user, receive, with the annotation tool, one or more annotations from the second user regarding the portion of the asset information, and control the database to store the one or more annotations and link the one or more annotations to the portion of the asset information for future reference.

[0102] Example 8. A system comprising: a plurality of assets; a plurality of computing devices; and a server including a communication interface configured to: communicate with the plurality of assets, and communicate with the plurality of computing devices; a memory storing an asset reliability and continuous health monitoring (ARCH) platform software; and an electronic processor communicatively connected to the memory, the electronic processor configured to receive asset information from the plurality of assets, control a database to store the asset information, generate a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets, and generate a graphical user interface that is displayed on an electronic display of one of the plurality of computing devices, the graphical user interface informing a user of the one or more recommendations.

[0103] Example 9: the system of example 8, wherein the plurality of assets includes two or more assets selected from a group consisting of: a motor, a pump, a servo, a valve, a transmitter, and a programmable logic controller (PLC).

[0104] Example 10: the system of examples 8 or 9, wherein the plurality of computing devices includes two or more computing devices selected from a group consisting of: a server, a smartphone, a desktop computer, a laptop, a transmitter, and a programmable logic controller (PLC).

[0105] Example 11 : the system of any of examples 8-10, wherein the ticket information includes a ticket ID, an alert date, an area / line, an asset name, a motor name, a device status, a previous health, a current health, remaining months, an electrical number, a sensor label, possible cases, and the one or more recommendations, or a combination thereof.

[0106] Example 12: the system of any of examples 8-11, wherein the electronic processor is further configured to: responsive to generating the ticket, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface informing a second user of one or more people that may be assigned the ticket, receive a selection of a person from the one or more people from the second user, assign the ticket to the person, and output an electronic notification to a computing device associated with the person, the electronic notification including the ticket information.

[0107] Example 13: the system of example 12, wherein, to output the electronic notification to the computing device associated with the person, the electronic processor is further configured to retrieve notification settings of the device associated with the person, and output the electronic notification according to the notification settings that are retrieved.

[0108] Example 14: the system of any of examples 8-13, wherein the electronic processor is further configured to: responsive to receiving the asset information, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying a portion of the asset information to a second user, receive an annotation request from the second user, responsive to receiving the annotation request from the second user, generate a third graphical user interface that is displayed on the one of the pluralityof computing devices, the graphical user interface displaying an annotation tool to the second user, receive, with the annotation tool, one or more annotations from the second user regarding the portion of the asset information, and control the database to store the one or more annotations and link the one or more annotations to the portion of the asset information for future reference.

[0109] Example 15. A method comprising: receiving, with an electronic processor, asset information from a plurality of assets; controlling, with the electronic processor, a database to store the asset information; generating, with the electronic processor, a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets; and generating, with the electronic processor, a graphical user interface that is displayed on an electronic display of a computing device, the graphical user interface informing a user of the one or more recommendations.

[0110] Example 16: the method of example 15, wherein the ticket information includes a ticket ID, an alert date, an area / line, an asset name, a motor name, a device status, a previous health, a current health, remaining months, an electrical number, a sensor label, possible cases, and the one or more recommendations, or a combination thereof.

[0111] Example 17: the method of examples 15 or 16, further comprising: responsive to generating the ticket, generating a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface informing a second user of one or more people that may be assigned the ticket; receiving a selection of a person from the one or more people from the second user; assigning the ticket to the person; and outputting an electronic notification to a computing device associated with the person, the electronic notification including the ticket information.

[0112] Example 18: the method of example 17, wherein outputting the electronic notification to the computing device associated with the person further includes retrieving notification settings of the device associated with the person, and outputting the electronic notification according to the notification settings that are retrieved.

[0113] Example 19: the method of any of examples 15-18, further comprising: responsive to receiving the asset information, generating a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying a portion of the asset information to a second user; receiving an annotation request from the second user; responsive to receiving the annotation request from the second user, generating a third graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying an annotation tool to the second user; receiving, with the annotation tool, one or more annotations from the second user regarding the portion of the asset information; and controlling the database to store the one or more annotations and link the one or more annotations to the portion of the asset information for future reference.

[0114] Example 20. A non-transitory computer-readable medium comprising instructions that, when executed by an electronic processor, cause the electronic processor to perform a set of operations comprising: receiving asset information from a plurality of assets; controlling a database to store the asset information; generating a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets; and generating a graphical user interface that is displayed on an electronic display of a computing device, the graphical user interface informing a user of the one or more recommendations.

[0115] Example embodiments are herein described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to example embodiments. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a special purpose and unique machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. The methods and processes set forth herein need not, in some embodiments, be performed in the exact sequence asshown and likewise various blocks may be performed in parallel rather than in sequence. Accordingly, the elements of methods and processes are referred to herein as “blocks” rather than “steps.”

[0116] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0117] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus that may be on or off-premises, or may be accessed via the cloud in any of a software as a service (SaaS), platform as a service (PaaS), or infrastructure as a service (laaS) architecture so as to cause a series of operational blocks to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide blocks for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. It is contemplated that any part of any aspect or embodiment discussed in this specification can be implemented or combined with any part of any other aspect or embodiment discussed in this specification.

[0118] In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.

[0119] Moreover, in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has,” “having,” “includes,” “including,” “contains,” “containing,” or any other variation thereof, are intended to cover a nonexclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises .. . a,” “has .. . a,” “includes .. . a,” or “contains ... a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. Unless the context of their usage unambiguously indicates otherwise, the articles “a,” “an,” and “the” should not be interpreted as meaning “one” or “only one.” Rather these articles should be interpreted as meaning “at least one” or “one or more.” Likewise, when the terms “the” or “said” are used to refer to a noun previously introduced by the indefinite article “a” or “an,” “the” and “said” mean “at least one” or “one or more” unless the usage unambiguously indicates otherwise.

[0120] Also, it should be understood that the illustrated components, unless explicitly described to the contrary, may be combined or divided into separate software, firmware, and / or hardware. For example, instead of being located within and performed by a single electronic processor, logic and processing described herein may be distributed among multiple electronic processors. Similarly, one or more memory modules and communication channels or networks may be used even if embodiments described or illustrated herein have a single such device or element. Also, regardless of how they are combined or divided, hardware and software components may be located on the same computing device or may be distributed among multiple different devices. Accordingly, in this description and in the claims, if an apparatus, method, or system is claimed, for example, as including a controller, control unit, electronic processor, computing device, logic element, module, memory module, communication channel or network, or other element configured in a certain manner, for example, to perform multiple functions, the claim or claim element should be interpreted as meaning one or more of such elements where any one of the one or more elements is configured as claimed, for example, to make any one ormore of the recited multiple functions, such that the one or more elements, as a set, perform the multiple functions collectively.

[0121] It will be appreciated that some embodiments may be comprised of one or more generic or specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and / or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.

[0122] Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Any suitable computer-usable or computer readable medium may be utilized. Examples of such computer- readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

[0123] Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation. For example, computer program code for carrying out operations of various example embodiments may be written in an object oriented programming language such as Java,Smalltalk, C++, Python, or the like. However, the computer program code for carrying out operations of various example embodiments may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a computer, partly on the computer, as a stand-alone software package, partly on the computer and partly on a remote computer or server or entirely on the remote computer or server. In the latter scenario, the remote computer or server may be connected to the computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0124] The terms “substantially,” “essentially,” “approximately,” “about,” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “one of,” without a more limiting modifier such as “only one of,” and when applied herein to two or more subsequently defined options such as “one of A and B” should be construed to mean an existence of any one of the options in the list alone (e.g., A alone or B alone) or any combination of two or more of the options in the list (e.g., A and B together).

[0125] A device or structure that is “configured” in a certain way is configured in at least that way but may also be configured in ways that are not listed.

[0126] The terms “coupled,” “coupling,” or “connected” as used herein can have several different meanings depending on the context in which these terms are used. For example, the terms coupled, coupling, or connected can have a mechanical or electrical connotation. For example, as used herein, the terms coupled, coupling, or connected can indicate that two elements or devices are directly connected to one another or connected to one another through intermediate elements or devices via an electrical element, electrical signal or a mechanical element depending on the particular context.

[0127] Thus, the present disclosure provides, among other things, an asset reliability and continuous health monitoring platform. Various features and advantages of the invention are set forth in the following claims.

Claims

CLAIMSWhat is claimed is:

1. A server comprising: a communication interface configured to: communicate with a plurality of assets, and communicate with a plurality of computing devices; a memory storing an asset reliability and continuous health monitoring (ARCH) platform software; and an electronic processor communicatively connected to the memory, the electronic processor configured to receive asset information from the plurality of assets, control a database to store the asset information, generate a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets, and generate a graphical user interface that is displayed on an electronic display of one of the plurality of computing devices, the graphical user interface informing a user of the one or more recommendations.

2. The server of claim 1, wherein the plurality of assets includes two or more assets selected from a group consisting of: a motor, a pump, a servo, a valve, a transmitter, and a programmable logic controller (PLC).

3. The server of claim 1, wherein the plurality of computing devices includes two or more computing devices selected from a group consisting of: a server, a smartphone, a desktop computer, a laptop, a transmitter, and a programmable logic controller (PLC).

4. The server of claim 1, wherein the ticket information includes a ticket ID, an alert date, an area / line, an asset name, a motor name, a device status, a previous health, a current health, remaining months, an electrical number, a sensor label, possible cases, and the one or more recommendations, or a combination thereof.

5. The server of claim 1, wherein the electronic processor is further configured to: responsive to generating the ticket, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface informing a second user of one or more people that may be assigned the ticket, receive a selection of a person from the one or more people from the second user, assign the ticket to the person, and output an electronic notification to a computing device associated with the person, the electronic notification including the ticket information.

6. The server of claim 5, wherein, to output the electronic notification to the computing device associated with the person, the electronic processor is further configured to retrieve notification settings of the device associated with the person, and output the electronic notification according to the notification settings that are retrieved.

7. The server of claim 1, wherein the electronic processor is further configured to:responsive to receiving the asset information, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying a portion of the asset information to a second user, receive an annotation request from the second user, responsive to receiving the annotation request from the second user, generate a third graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying an annotation tool to the second user, receive, with the annotation tool, one or more annotations from the second user regarding the portion of the asset information, and control the database to store the one or more annotations and link the one or more annotations to the portion of the asset information for future reference.

8. A system comprising: a plurality of assets; a plurality of computing devices; and a server including a communication interface configured to: communicate with the plurality of assets, and communicate with the plurality of computing devices; a memory storing an asset reliability and continuous health monitoring (ARCH) platform software; and an electronic processor communicatively connected to the memory, the electronic processor configured to receive asset information from the plurality of assets, control a database to store the asset information, generate a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets, andgenerate a graphical user interface that is displayed on an electronic display of one of the plurality of computing devices, the graphical user interface informing a user of the one or more recommendations.

9. The system of claim 8, wherein the plurality of assets includes two or more assets selected from a group consisting of: a motor, a pump, a servo, a valve, a transmitter, and a programmable logic controller (PLC).

10. The system of claim 8, wherein the plurality of computing devices includes two or more computing devices selected from a group consisting of: a server, a smartphone, a desktop computer, a laptop, a transmitter, and a programmable logic controller (PLC).

11. The system of claim 8, wherein the ticket information includes a ticket ID, an alert date, an area / line, an asset name, a motor name, a device status, a previous health, a current health, remaining months, an electrical number, a sensor label, possible cases, and the one or more recommendations, or a combination thereof.

12. The system of claim 8, wherein the electronic processor is further configured to: responsive to generating the ticket, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface informing a second user of one or more people that may be assigned the ticket,receive a selection of a person from the one or more people from the second user, assign the ticket to the person, and output an electronic notification to a computing device associated with the person, the electronic notification including the ticket information.

13. The system of claim 12, wherein, to output the electronic notification to the computing device associated with the person, the electronic processor is further configured to retrieve notification settings of the device associated with the person, and output the electronic notification according to the notification settings that are retrieved.

14. The system of claim 8, wherein the electronic processor is further configured to: responsive to receiving the asset information, generate a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying a portion of the asset information to a second user, receive an annotation request from the second user, responsive to receiving the annotation request from the second user, generate a third graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying an annotation tool to the second user, receive, with the annotation tool, one or more annotations from the second user regarding the portion of the asset information, and control the database to store the one or more annotations and link the one or more annotations to the portion of the asset information for future reference.

15. A method compri sing : receiving, with an electronic processor, asset information from a plurality of assets; controlling, with the electronic processor, a database to store the asset information; generating, with the electronic processor, a ticket and ticket information that is embedded in the ticket based on the asset information that is received from the plurality of assets, the ticket information including one or more recommendations to resolve an issue with one of the plurality of assets; andgenerating, with the electronic processor, a graphical user interface that is displayed on an electronic display of a computing device, the graphical user interface informing a user of the one or more recommendations.

16. The method of claim 15, wherein the ticket information includes a ticket ID, an alert date, an area / line, an asset name, a motor name, a device status, a previous health, a current health, remaining months, an electrical number, a sensor label, possible cases, and the one or more recommendations, or a combination thereof.

17. The method of claim 15, further comprising: responsive to generating the ticket, generating a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface informing a second user of one or more people that may be assigned the ticket; receiving a selection of a person from the one or more people from the second user; assigning the ticket to the person; and outputting an electronic notification to a computing device associated with the person, the electronic notification including the ticket information.

18. The method of claim 17, wherein outputting the electronic notification to the computing device associated with the person further includes retrieving notification settings of the device associated with the person, and outputting the electronic notification according to the notification settings that are retrieved.

19. The method of claim 15, further comprising: responsive to receiving the asset information, generating a second graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying a portion of the asset information to a second user; receiving an annotation request from the second user;responsive to receiving the annotation request from the second user, generating a third graphical user interface that is displayed on the one of the plurality of computing devices, the graphical user interface displaying an annotation tool to the second user; receiving, with the annotation tool, one or more annotations from the second user regarding the portion of the asset information; and controlling the database to store the one or more annotations and link the one or more annotations to the portion of the asset information for future reference.

20. The method of claim 15, wherein the plurality of assets includes two or more assets selected from a group consisting of a motor, a pump, a servo, a valve, a transmitter, and a programmable logic controller (PLC).

Images