TECHNICAL FIELD
The subject matter disclosed herein relates to reliability operations, and more specifically, to control system collaboration and reliability operations.
BACKGROUND OF THE INVENTION
Control systems, including industrial control systems, may include a variety of components and subsystems participating in a process. For example, a controller may include one or more processors, I/O subsystems, a memory, and the like. The controller may be operatively coupled to a variety of systems and used, for example, to control an industrial process. However, control systems may be complex, including numerous interrelated components and subsystems. Accordingly, recognizing or predicting a reliability of control system operations may be difficult and time-consuming. It would be beneficial to improve reliability and collaboration of control systems.
BRIEF DESCRIPTION OF THE INVENTION
Certain embodiments commensurate in scope with the originally claimed invention are summarized below. These embodiments are not intended to limit the scope of the claimed invention, but rather these embodiments are intended only to provide a brief summary of possible forms of the invention. Indeed, the invention may encompass a variety of forms that may be similar to or different from the embodiments set forth below.
In a first embodiment, a system includes health advisor system. The health advisor system includes a data collection system configured to collect a data from a control system, and a configuration management system configured to manage a hardware configuration and a software configuration for the control system based on the data. The health advisor system further includes a rule engine configured to use the data as input and to output a health assessment by using a rule database configured to store at least one rule, and a health assessment generator configured

to provide a health assessment for the control system, wherein the data collection system is configured to use at least one online conduit to collect the data, and wherein the health advisor system is executable via an edge device communicatively coupled to a cloud infrastructure.
In a second embodiment, a method includes acquiring a data from a control system using at least one online communications conduit, wherein the control system is configured to control a turbine system to produce electrical power. The method additionally includes analyzing the data to obtain a data analysis by using at least one control system health assessment rule. The method further includes deriving a control system network status, a security status, a parts availability status, or a combination thereof, based on the analyzing the data.
In a third embodiment, a tangible, non-transitory machine readable medium includes code configured to acquire a data from a control system using at least one online communications conduit, wherein the control system is configured to control a turbine system to produce electrical power. The code is additionally configured to analyze the data to obtain a data analysis by using at least one control system health assessment rule. The code is further configured to derive a control system network status, a security status, a parts availability status, or a combination thereof, based on the analyzing the data.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
FIG. 1 is an information flow diagram of an embodiment of a control system health advisor communicatively coupled to plant including a control system;

FIG. 2 is a schematic diagram of an embodiment of the control system health advisor of FIG. 1 communicatively coupled to a control system;
FIG. 3 is a block diagram of an embodiment of the control system health advisor of FIG. 1;
FIG. 4 is a flowchart of an embodiment of a process useful in providing and using a health assessment for a control system; and
FIG. 5 is an online information flow diagram of an embodiment of the control system health advisor of FIG. 1 coupled to a plant including a control system.
DETAILED DESCRIPTION OF THE INVENTION
One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers’ specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
When introducing elements of various embodiments of the present invention, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
In certain embodiments, control of operations for an industrial process and associated machinery may be provided by a control system. In these

embodiments, the control system may be implemented as a combination of hardware and software components suitable for receiving inputs (e.g., process inputs), processing the inputs, and deriving certain control actions useful in controlling a machinery or process, such as a power generation process, as described in more detail below. The novel techniques described herein include: 1) a controller data transmission diagnostics system (e.g., network diagnostic system) that may diagnose network issues, among others; 2) a control server, also called an edge device, that utilizes virtualization technology and may host multiple virtual and/or physical devices and/or applications including thin clients, data logging historian, on-site monitor (OSM), an efficiency map, a health advisor suite and related systems, and additionally host and/or interface with cloud-enabled applications; 3) a parts failure tracker/predictor that may track and/or predict certain issues with the control system and related systems; 4) an inventory database that may include certain “social” and collaborative features as further described below; 5) a health advisor database which may include cloud-based updating; and 6) a dynamic security system suitable for providing a cybersecurity “umbrella” over the control system and related systems.
By way of further description, certain corrective maintenance (CM) techniques may be used, useful in repairing or updating the controller after an unexpected maintenance event. However, because the CM techniques are typically applied after the unexpected event, the controlled process may be stopped until the control system is brought back to a desired operating condition. The novel techniques described herein, including prognostic health monitoring (PHM) techniques, may enable a preventative or predictive approach in which control system issues may be identified prior to their occurrence. Accordingly, maintenance actions, such as control system upgrades, part replacements, supply chain order placement, and the like, may be performed in advance, and the control system may be maintained in an operational status for a longer duration. Indeed, stoppages of the controlled process and associated machinery may be substantially minimized or eliminated.

In certain embodiments, online data flows may be used, for example, in a controller health advisor suite of software tools, suitable in analyzing and deriving a health assessment for the control system. By using online data flows, the health assessment may be provided more quickly (e.g., near real-time, real-time), and subsystems, such as remote services centers and analytical subsystems, may be disposed at any desired geographic location. Further, the health assessment and related data may be distributed through the online data flows, thus providing actionable information to any number of interested entities. The health assessment may include a controller readiness, controller recommendations (e.g., upgrade recommendations, parts replacement recommendations, parts ordering recommendations), a configuration report, early warning reports (e.g., early warning outage reports), and access based reports (e.g., role-based access reports). The health advisor suite may additionally include offline components, useful in performing the health assessment while the health advisor suite is communicatively coupled either directly to the control system, or coupled indirectly to the control system. Additionally, the health assessment may be provided in real-time or near real-time. The health assessment may be derived continuously and used to update or improve the control system, thus providing for an up-to-date prognosis of the health of the control system.
With the foregoing in mind and turning now to FIG. 1, the figure is an information flow diagram illustrating an embodiment of a controller health advisor system 10 that may be communicatively coupled to a control system 12. The health advisor system 10 may include non-transitory code or instructions stored in a machine-readable medium and used by a computing device (e.g., computer, tablet, laptop, notebook, cell phone, personal digital assistant) to implement the techniques disclosed herein. The control system 12 may be used, for example, in controlling a power plant 14. The power plant 14 may be any type of power producing plant 14, and may include turbomachinery, such as a gas turbine, a steam turbine, a wind turbine, a hydroturbine, a pump, and/or a compressor. It is to be noted that, in certain embodiments, the controller 12 may be used to control a variety of other

machinery, and may be disposed in any industrial plant (e.g., manufacturing plant, chemical plant, oil refining plant). The plant 14, for example, may include a gasification system, a turbine system, a gas treatment system, a power generation system, or a combination thereof.
The health advisor system 10 may include a health advisor database 16, a health advisor suite (e.g., suite of software and/or hardware tools) 18, and a knowledge base 20. The health advisor database 16 may store, for example, rule-based information detailing expert knowledge on the workings and possible configurations of the control system 12, as well as knowledge useful in making deductions or predictions on the health of the control system 12. For example, the health advisor database 16 may include expert system rules (e.g., forward chained expert system, backward chained expert system), regression models (e.g., linear regression, non-linear regression), fuzzy logic models (e.g.., predictive fuzzy logic models), and other predictive models (e.g., Markov chain models, Bayesian models, support vector machine models) that may be used to predict the health, the configuration, and/or the probability of occurrence of undesired maintenance events (e.g., failure of a power supply, failure of a processor core, failure of an input/output [I/O]) pack, insufficient memory, loose bus connection) related to the control system 12.
The knowledge base 20 may include one or more answers to control system 12 questions or issues, including answers relating to controller configurations, unexpected problems, known hardware or software issues, service updates, and/or user manuals. The health advisor suite 18 may update the knowledge base 20 based on new information, such as a control system health assessment 24. Additionally, an online life cycle support tool 22 is provided. The online life cycle support tool 22 may use the health advisor suite 18 and the knowledge base 20 to provide support to customers 26 of the power plant 14. For example, the customers 26 may connect to the online life cycle support tool 22 by using a web browser, a client terminal, a virtual private network (VPN) connection, and the like, and access the answers provided by the knowledge base 20, as well as the

health advisor suite 18 and/or the health assessment 24, through the online life cycle support tool 22.
The online life cycle support tool 22 may similarly be used by other entities, such as a contract performance manager (CPM) tasked with administrating contractual services delivered to the plant 14, and/or a technical assistant (TA) tasked with providing information technology and/or other system support to the plant 14. For example, the plant 14 may be provided with contractual maintenance services (e.g., inspections, repairs, refurbishments, component replacements, component upgrades), service level agreements (SLAs), and the like, supported by the CPM and the TA.
The health assessment 24 may be used, for example, to enable a new product introduction (NPI) 28 and/or a root cause analysis (RCA) 30. For example, issues found in the health assessment 24 may aid in identifying issues related to the introduction (e.g., NPI 28) of a new hardware or software component for the control system 12, or the introduction of a newer version of the control system 12. The identified issues may then be used to derive the RCA 30. For example, the health advisor suite 18 may use techniques such as fault tree analysis, linear regression analysis, non-linear regression analysis, Markov modeling, reliability block diagrams (RBDs), risk graphs, and/or layer of protection analysis (LOPA). The RCA 30 may then be used to re-engineer or otherwise update the control system 12 to address any issues found.
The health assessment 24 and/or the knowledge base 20 may also be used to derive engineering opportunities 32 and revenue opportunities 34. For example, controller usage patterns (processor usage, memory usage, network usage, program logs), issues found, frequently asked questions, and the like, may be used to derive engineering changes for the control system 12. The engineering changes may include changing memory paging schemes, memory allocation algorithms, applying CPU optimizations (e.g., assigning process priorities, assigning thread priorities), applying programming optimization (e.g., identifying and rewriting

program bottlenecks, using improved memory allocation, using processor-specific instructions), applying networking optimizations (e.g., changing transmit/receive rates, frame sizes, time-to-live (TTL) limits), and so on.
Revenue opportunities 34 may also be identified and acted on. For example, the health assessment 24 may detail certain upgrades to the control system 12 based on a desired cost or budget structure, suitable for improving the performance of the control system 12. Upgrades may include software and or hardware updates, such as newer versions of a distributed control system (DCS), a manufacturing execution system (MES), a supervisor control and data acquisition (SCADA) system, a human machine interface (HMI) system, an input/output system (e.g., I/O pack), a memory, processors, a network interface, a power supply, and/or a communications bus. By using the heath advisor suite 18 to derive the health assessment 24, the techniques described herein may enable a more efficient and safe power plant 14, as well as minimize operating costs.
Also shown are a controller data transmission diagnostics system 35, a dynamic security system 37, a “local” inventory database 39, an “offsite” inventory database 41, a parts tracking system 43, and an edge device or control server system 45. The controller data transmission diagnostics system 35 (e.g., network diagnostic system) that may diagnose network issues, in the control system 12, the plant 14, with the customer 26, and so on. The controller data transmission diagnostics system 35 may additionally provide the health advisor system 10 or be included in the health advisor system 10 with derivations that may show or predict that certain issues have arisen in hubs, switches, linking devices, IONet systems, and so on, and further describe below.
The dynamic security system 37 may observe real-time dataflows, for example, in and out of the control system 12 and plant 14, to detect probes, cyberattacks from outside sources, from inside sources, attempts at cyber phishing, and so on. The dynamic security system 37 may also maintain control system inventory and perform audits to derive if certain systems are less secure or that certain systems

may include older software, hardware, and so on, that may then be flagged for upgrades. The dynamic security system 37 may be communicatively coupled to a cloud 50 and/or edge device 45, and may thus have up-to-date access to updated intrusion signatures, system patches, virus signatures, phishing signatures, code snippets to look for during audits/intrusion detection, and so on.
The edge device 45 may be a server (e.g. hardware suitable for use as a server communicatively coupled to a plurality of client computing systems to provide for computing services to the computing systems) that is communicatively coupled to the cloud 50 as well as to the control system 12, systems in the power plant 14, and/or the health advisor system 10. More specifically, the edge device 45 may provide for the development, deployment, and operation of applications, including industrial applications, at the edge and in the cloud 50. The edge device 45, in certain embodiments, may be disposed inside of the plant 14 and/or be included as part of the control system 12.
According, the edge device 45 may include a Machine gateway (M2M). The Machine gateway component is an extensible plugin framework that may enables out-of-the-box connectivity to assets (e.g., plant 14 assets, control system 12 assets, health advisor system 10 assets) based on the most common industrial protocols. For example, many assets already support connectivity through industrial protocols such as OPC-UA or ModBus 2, and the Machine gateway may translate communications to those supported protocols. The edge device 45 may also include a Cloud gateway (M2DC). The cloud gateway component connects the edge device 45 and applications using the edge device 45 to the cloud 50. There are several protocols that are supported, including HTTPS or WebSockets. 3. The edge device 45 may also include a Mobile gateway (M2H). More specifically, in addition to connecting to the machines (e.g., machines in the plant 14) and to the cloud 50, the mobile gateway component enables people (humans) and applications to bypass the cloud 50 and to establish a direct connection to an asset. This capability may be especially important for maintenance scenarios. For example, when service technicians are deployed to

maintain or repair machines, they can connect directly to the machine to understand its operating conditions or perform troubleshooting, for example via a laptop, smart phone, tablet, and so on via M2H. While cloud 50 connectivity is supported, in certain industrial environments where connectivity can be challenging, the ability to bypass the cloud 50 and create this direct connection to the machine may enable faster and more secure access to the assets. In certain embodiments, the edge device 45 may be located inside of the plant 14 and/or in the same location as the control system 12. Further, the entire health advisor system 10 as described herein may operate an application executable via the edge device 45 and having access to cloud 50 infrastructure.
The cloud 50 infrastructure may include a scalable cloud infrastructure that may serve as a basis for Platform as-a-Service (PaaS) and/or Software as-a Service (Sass), which developers may use to create Industrial Internet applications. The cloud 50 also provides an entry point for industrial enterprises to take advantage of certain software technology (e.g., access to scalable computing and security) without having to make large hardware and software commitments. In order to process the vast amounts of data required by Industrial IoT scenarios, the cloud 50 may be used to develop various applications and software systems, with the cloud 50 leveraging commercial off-the-shelf hardware, making it easier to scale out (add additional computing) instead of scaling up (adding more storage, memory, and CPU to an existing server). The cloud 50 may manage the complexity of scale so that developers can focus on creating application that drive industrial value. Indeed, the cloud 50 may include one or more operating systems, one or more programming-language execution environments, databases, and web servers executing in a scalable way. Accordingly, application developers can develop and run their software solutions on the cloud 50 PaaS without the cost and complexity of buying and managing the underlying hardware and software layers. For example, the techniques described herein may include all of the health advisor system 10 executing as a PaaS application in the cloud 50 and interfacing with assets or machinery via the edge device 45.

The parts tracker/failure predictor system 43 may track and/or predict certain issues with the control system 12 and related systems, such as power plant systems 14. For example, models of the control system 12 and/or power plant systems 14 may include simulations, neural networks, state vector machines (SVM), data mining models (e.g., cluster-based prediction models), statistical models, and so on, that may predict an upcoming maintenance-related event based on use of the equipment. For example, the parts tracker/failure predictor system 43 may predict upcoming need to change networking equipment (e.g., switches, hubs, cabling, repeaters, encoder/decoders, network cards, wifi equipment, linking devices, etc.), controller equipment (e.g., R, S, T cores, power supplies, memory, etc.), based on usage data and/or current signals (e.g., electrical networking signals, processor-based signals, wifi signals and so on).
As depicted, the parts tracker/failure predictor system 43 is communicatively connected to the health advisor system 10 and may thus leverage the health advisor system 10 to provide the health assessment and then use the health assessment to derive upcoming predictions of undesired maintenance events. Further, the parts tracker/failure predictor system 43 is communicatively coupled to the local inventory database 39 and/or the offsite inventory database 41. The local inventory database 39 includes a comprehensive inventory of “parts,” including hardware and software components that make up the control system 12. For example, spare networking cards, cabling, switches, hubs, repeaters, encoder/decoders, network cards, wifi equipment, linking devices, spare processor cards, power supplies, memory, power plant 14 equipment, and so on, may be stored in the local inventory database 41 for the power plant 14 and control system 12 shown.
Inventory for a remote power plant 14 and/or a remote control system 12 may be stored in the offsite inventory database 41. That is, for a plurality of power plants 14 and their related control systems 12, each different power plant 14/control system 12 combination may store their inventory, such as the aforementioned spare networking cards, cabling, switches, hubs, repeaters, encoder/decoders,

network cards, wifi equipment, linking devices, spare processor cards, power supplies, memory, power plant 14 equipment, and so on, in a different inventory database, such as the database 41. Each different inventory database may thus belong to a different customer 26. It is to be noted that the databases 16, 39, 41 may be stored and/or replicated in the cloud 50 and/or in the edge device 45, and thus kept up to date across multiple sites (e.g., plants 14 and customers 26). Accordingly, data from the databases 16, 39, 41 may be distributed to other sites (e.g., other customers 26) and used to track fleets of plants 14 and/or control systems 12 for analysis for example, across fleets to improve predictive accuracy of the parts tracker/failure predictor system 43.
The parts tracker/failure predictor system 43 may interface with the databases 39, 41, for collaborative purposes. For example, the parts tracker/failure predictor system 43 may predict that there will be a need for a network card for customer A and that customer B has just such a network card available. Further, the parts tracker/failure predictor system 43 may predict that customer B won’t need a replacement card in the near future (e.g., one month, two months, one year). Accordingly, the parts tracker/failure predictor system 43 may enable customer A to negotiate or contact customer B and procure the network card. The inventory databases 39, 41 may thus be used to provide collaborative features, such as providing a list of items for procurement at each customer 26 site, a cost for each item, a supply time to deliver each item, and so on. Accordingly, customers may view inventory across a plurality of plant 14 sites, bid on inventory, buy inventory, barter for inventory, and so on. Each customer 26 may secure their respective inventory database 41, for example, by allowing only a subset of items to be shown, by allowing only a subset of certain customers to see certain data, and so on. By providing for collaborative and social aspects, the databases 39, 41 may enable a more efficient and productive use of resources owned by the various customers 26.
The data transmission diagnostics system 35 may collect data from both IONet as well as unit data highway (UDH)/plant data highway (PDH) network switches to

determine channel healthiness, packet loss, duplicate packets, network load and internal switch issues such as CPU utilization, FAN status, and so on. This network data may be processed inside of the heath advisor rule engine, described in more detail below to identify the current network status as well as any possible network issues. The network health report as well as recommendations may then be added to the health assessment 24.
FIG. 2 is a schematic diagram depicting an embodiment of the control system 12 communicatively coupled to the health advisor suite 18. The control system 12 may include a computer system 36 suitable for executing a variety of control and monitoring applications, and for providing an operator interface through which an engineer or technician may monitor the components of the control system 12. Accordingly, the computer 36 includes a processor 38 that may be used in processing computer instructions, and a memory 40 that may be used to store computer instructions and other data. The computer system 36 may include any type of computing device suitable for running software applications, such as a laptop, a workstation, a tablet computer, or a handheld portable device (e.g., personal digital assistant or cell phone). Indeed, the computer system 36 may include any of a variety of hardware and/or operating system platforms. In accordance with one embodiment, the computer 36 may host an industrial control software, such as a human-machine interface (HMI) software 42, a manufacturing execution system (MES) 44, a distributed control system (DCS) 46, and/or a supervisor control and data acquisition (SCADA) system 48. The HMI 42, MES 44, DCS 46, and/or SCADA 50 may be stored as executable code instructions stored on non-transitory tangible computer readable media, such as the memory 40 of the computer 36. For example, the computer 36 may host the ControlST™ and/or ToolboxST™ software, available from General Electric Co., of Schenectady, New York.
The health advisor 18 may be communicatively coupled to the computer system 36 through direct or indirect techniques. For example, a signal conduit (e.g., cable, wireless router) may be used to directly couple the health advisor 18 to the

computer 38. Likewise, a file transfer mechanism (e.g., remote desktop protocol (rdp), secure file transfer protocol (sftp), manual transfer) may be used to indirectly send or to receive data, such as files. Further, cloud 50 computing techniques may be used, where the health advisor 18 resides in the cloud 50 and communicates directly or indirectly with the computer system 36.
The health advisor suite 18 may include a data collection subsystem 54, a configuration management system 56, and a rule engine 60. In certain embodiments, the data collection subsystem 54 may collect and store data, such as data representative of the status, health, and operating condition of the control system 12. The data collection subsystem 54 may be continuously operating, and may include relational databases, network databases, files, and so on, useful in storing and updating stored data. The configuration management system 56 may be used to manage the various configurations of software and/or hardware components used in constructing the control system 12. Indeed, the control system 12 may include multiple software and/or hardware components, each component having one or more versions. These versioned components may be packaged by a manufacturer into the control system 12 as part of a contract services agreement, and/or may be provided as part of a transactional services agreement (e.g., purchased individually). The rule engine 58 may be used to enable the derivations of the health assessment 24, as described in more detail below with respect to FIGS. 3-7.
Further, the computer system 36 and the health advisor 18 may be communicatively connected to a plant data highway 60 suitable for enabling communication between the depicted computer 36 and other computers 36 and/or health advisors 18. Indeed, the industrial control system 12 may include multiple computer systems 36 interconnected through the plant data highway 60, or through other data buses (e.g., local area networks, wide area networks). In the depicted embodiment, the computer system 36 and the health advisor 18 may be further communicatively connected to a unit data highway 62, suitable for communicatively coupling the computer system 36 and the health advisor 18 to an

industrial controller system 64. In other embodiments, other data buses (e.g., direct cabling, local area networks, wide area networks) may be used to couple the computer system 36 and the health advisor 18 to the industrial controller 64.
The industrial controller 64 may include a processor 66 suitable for executing computer instructions or control logic useful in automating a variety of plant equipment, such as a turbine system 68, a temperature sensor 70, a valve 72, and a pump 74. The industrial controller 64 may further include a memory 76 for use in storing, for example, control code (e.g., computer instructions and other data). For example, the controller 64 may store one or more function blocks written in an International Electrotechnical Commission (IEC) 61804 language standard, sequential function charts (SFC), ladder logic, or programs written in other programming languages, in the control code. In one embodiment, the control code may be included in a configuration file 65. Additionally or alternatively, the configuration file 65 may include configuration parameter for the controller, such as instantiated function blocks (e.g., function blocks to load into memory), networking parameters, code synchronization and timing, I/O configuration, and so on.
The industrial controller 64 may communicate with a variety of field devices, including but not limited to flow meters, pH sensors, temperature sensors, vibration sensors, clearance sensors (e.g., measuring distances between a rotating component and a stationary component), pressure sensors, pumps, actuators, valves, and the like. In some embodiments, the industrial controller 64 may be a triple modular redundant (TMR) Mark™ VIe controller system, available from General Electric Co., of Schenectady, New York. By including three processors, the TMR controller 64 may provide for redundant or fault-tolerant operations. In other embodiments, the controller 64 may include a single processor, or dual processors.
In the depicted embodiment, the turbine system 68, the temperature sensor 70, the valve 72, and the pump 74 are communicatively connected to the industrial

controller 64 and/or the health advisor 18 by using linking devices 78 and 80 suitable for interfacing between an I/O network 82 and an H1 network 84. For example, the linking devices 78 and 80 may include the FG-100 linking device, available from Softing AG, of Haar, Germany. Additional field devices 86 (e.g., sensors, pumps, valves, actuators) may be communicatively coupled via the I/O network 82 to the controller 64 and/or the health advisor 18, for example, by using one or more input/output (I/O) packs 88. The I/O packs 88 may each include a microprocessor 90 useful in executing a real-time operating system, such as QNX® available from QNX Software Systems/Research in Motion (RIM) of Waterloo, Ontario, Canada. Each I/O pack 88 may also include a memory 92 for storing computing instructions and other data, as well as one or more sensors 94, such as temperature sensors, useful in monitoring the ambient temperature in the I/O packs 88. In other embodiments, the turbine system 68, the temperature sensor 70, the valve 72, the pump 74, and/or the field devices 86, may be connected to the controller 64 and/or the health advisor 18 by using direct cabling (e.g., via a terminal block) or indirect means (e.g., file transfers).
As depicted, the linking devices 78 and 80 may include processors 96 and 98, respectively, useful in executing computer instructions, and may also include memory 100 and 102, useful in storing computer instructions and other data. In some embodiments, the I/O network 82 may be a 100 Megabit (MB) high speed Ethernet (HSE) network, and the H1 network 84 may be a 31.25 kilobit/second network. Accordingly, data transmitted and received through the I/O network 82 may in turn be transmitted and received by the H1 network 84. That is, the linking devices 78 and 80 may act as bridges between the I/O network 82 and the H1 network 84. For example, higher speed data on the I/O network 82 may be buffered, and then transmitted at suitable speed on the H1 network 84. Accordingly, a variety of field devices may be linked to the industrial controller 64, to the computer 36, and/or to the health advisor 18. For example, the field devices 68, 70, 72, and 74 may include or may be industrial devices, such as Fieldbus Foundation™ devices that include support for the Foundation H1 bi-

directional communications protocol. The field devices 68, 70, 72, 74, and 86 may also include support for other communication protocols, such as those found in the HART® Communications Foundation (HCF) protocol, and the Profibus Nutzer Organization e.V. (PNO) protocol.
Also shown are the controller data transmission diagnostics system 35, the dynamic security system 37, the parts tracking system 43, communicatively coupled to the health advisor 18. The edge device or control server system 45, is also shown, which may enable cloud 50 infrastructure for the health advisor system 18 and/or host the health advisor system 18. Likewise, it is to be noted that the edge device 45 may enable the cloud 50 infrastructure for the controller data transmission diagnostics system 35, and the dynamic security system 37, and/or the parts tracking system 43 and/or host the controller data transmission diagnostics system 35, the dynamic security system 37, and the parts tracking system 43.
In operations, the data transmission diagnostics system 35 may observe networking hardware and/or software behaviors for the plant data highway 60, the unit data highway 62, the I/O network 82 (e.g., IONet) and an H1 network 84 and related components, e.g., UDH/PDH network switches, linking devices 78, 80, hubs, wifi equipment, cabling, repeaters, and so on, to determine channel healthiness, packet loss, duplicate packets, network load and internal switch issues such as CPU utilization, FAN status, and so on. This network observations may be processed inside of the heath advisor rule engine 18 to identify the current network status as well as any possible network issues. For example, packet loss may be identified and the likely components of the loss identified. Similarly, behavioral analytics, route analytics, data transfer analytics, protocol analytics, and so on, may identify protocol problems, performance problems, flooding, inadvertent timeouts, timing issues, and so on. Identified issues and likely culprits may then be added to the health assessment 24.

The dynamic security system 37 may also observe data and user interactions via the plant data highway 60, the unit data highway 62, the I/O network 82 (e.g., IONet) and an H1 network 84, and related components, including plant 14 equipment such as the turbine system 68, the temperature sensor 70, the valve 72, and the pump 74, to determine weakness that may lead to intrusions as well as possible intrusions in progress. The intrusions may include viruses, phishing attacks, probes, denial of service (DOS) attacks, man-in-the-middle attacks, ransomware attacks, and so on, both external as well as internal. The dynamic security system 37 may also perform system audits to derive if certain systems are less secure or that certain systems may include older software, hardware, and so on, that may then be flagged for upgrades. The dynamic security system 37 may be communicatively coupled to the cloud 50 and/or edge device 45, and may thus have up-to-date access to updated intrusion signatures, system patches, virus signatures, phishing signatures, code snippets to look for during audits/intrusion detection, and so on.
The parts tracker/failure predictor system 43 may also observe data and user interactions via the plant data highway 60, the unit data highway 62, the I/O network 82 (e.g., IONet) and an H1 network 84, and related components, including plant 14 equipment such as the turbine system 68, the temperature sensor 70, the valve 72, and the pump 74, to track and/or predict certain issues. For example, models of the control system 12 and/or power plant systems 14 may include simulations, neural networks, state vector machines (SVM), data mining models (e.g., cluster-based prediction models), statistical models, and so on, that may predict an upcoming maintenance-related event based on use of the equipment using the observed data as inputs. For example, the parts tracker/failure predictor system 43 may predict upcoming need to change networking equipment (e.g., switches, hubs, cabling, repeaters, encoder/decoders, network cards, wifi equipment, linking devices, etc.), controller equipment (e.g., R, S, T cores, power supplies, memory, etc.), based on usage data and/or current

signals (e.g., electrical networking signals, processor-based signals, wifi signals and so on).
FIG. 3 is a block diagram of an embodiment of the health advisor suite 18 depicting the transformation of inputs 106 into the health assessment 24. By using the inputs 106 to derive the health assessment 24, the health advisor suite 18 may enable an up-to-date prognosis of the health of the control system 12, and may be used to derive the NPI 28, the RCA 30, the engineering opportunities 32, and/or the revenue opportunities 34 for the plant 14. As mentioned above, the health advisor suite 18 may include computer instructions stored in a non-transitory machine readable medium, such as the memory of a computer, a tablet, a notebook, a workstation, a cell phone, and/or other computing device. In the depicted embodiment, the inputs 106 may include site software 108, rules 110, and/or process dynamics 112.
The site software 108 may include all software (e.g., software tools, operating systems, networking software, firmware, microcode, display drivers, sound drivers, network drivers, I/O system drivers) used by the components of the control system 12 of FIG. 2, such as the HMI 42, the MES 44, the DCS 46, the computer 36, the controller 64, the linking devices 78, 80, the I/O pack 88, the plant data highway 60, the I/O network 82, the H1 network 84, and the field devices 68, 70, 72, 74, 86.
The rules 110 may include “if … then …” rules with the “if” portion set as an antecedent condition, and the “then” portion set as a consequent of the antecedent condition. The rules may also include fuzzy logic rules, expert system rules (e.g., forward chained expert systems, backward chained expert systems), recursive rules (e.g., Prolog rules), Bayesian inference rules, dynamic logic rules (e.g., modal logic), neural network rules, genetic algorithm rules, or a combination thereof. The rules may be derived through consultation with one or more experts in the field, such as a controller system health experts, or automatically, such as by using machine learning techniques (e.g., reinforcement learning, decision tree

learning, inductive logic programming, neural network training, clustering, support vector machine).
The rules 110 may created by using a rules editor 111. In one embodiment, the rules editor 111 may be included as part of the health advisor suite 18. In another embodiment, the rules editor 111 may be provided separate from the health suite 18. The rules editor 111 may include computer instructions stored in a non-transitory machine readable medium, such as the memory of a computer, a tablet, a notebook, a workstation, a cell phone, and/or other computing device. In the depicted embodiment, the rule editor 111 may be used to create, update, and/or delete, one of more of the rules 110. For example, FIGS. 6 and 7 describe a screen suitable for creating, updating, and/or deleting one or more of the rules 110.
The process dynamics 112 may include data received when the health advisor 18 is communicatively coupled to the control system 12, the controller data transmission diagnostics system 35, the dynamic security system 37, the parts tracking system 43, the databases 39, 41, and so on. The process dynamics 112 data may include alerts issued by the controller 64, and/or the HMI 42, the MES 44, the DCS 46, the SCADA 48, the , the controller data transmission diagnostics system 35, the dynamic security system 37, the parts tracking system 43, the databases 39, 41, and so on.. Likewise, the process dynamics 112 may include utilization data (e.g., percent utilization, total utilization) for the memories 40, 76, 92, 100, 102, utilization data for the processors 38, 66, 90, 96, 98 (e.g., utilization by software processes, utilization by software applications), current configuration parameters used by the components of the control system 12 (e.g., memory page size, virtual memory pages, thread priority, process priority) controller 64 parameters (e.g., master/slave configuration, I/O parameter), bus 60, 62, and 84 parameters, I/O pack 88 parameters, linking device 78, 80 parameters, field device 68, 70, 72, 74, 86 parameters.

In the depicted embodiment, the health advisor suite 18 includes online 114 and offline 116 operational modes, which may be used alone or in combination with each other. In the online mode 114 of operations, the health advisor may be constantly receiving the inputs 106, for example, by using the data collection subsystem 54 of the health advisor suite 18, then processing the inputs 106, for example, by using the configuration management 56 and rule engine 58 of the health advisor suite 18, to produce the health assessment 24. In the offline mode 116 of operations, the inputs 106 may be provided, for example, as a set of files or as a “batch job.” That is, the files or “batch job” may be provided to the data collection subsystem 54 as pre-collected data, which may be subsequently used to produce the health assessment 24. By providing for the offline mode 116, the health advisor suite 18 may be used, for example, in a computing device that may be disconnected from the controller system 12. User input 118 is also depicted. The user input 118 may include data related to the control system 12 and manually entered by the user. Additionally, the user input 118 may include usage input (e.g., keyboard, mouse, voice) directing the health advisor 18 to perform certain desired operations, such as operations deriving the health assessment 18, including a TMR readiness report 120, a recommendation report 122, an auto configuration report 124, early warnings 126, access-based reports 128, network status reports 129, security reports 131, and/or parts reports 133.
The TMR readiness report 120 may detail the condition of the TMR controller 64, including any detected fault conditions, alarm reports based on alarm logging data, error reports based on error logging data, and may also derive an overall readiness metric by using the inputs 106. For example, the readiness metric may detail an approximate percentage readiness (0%-100%) for the overall control system 12, as well as for each component of the control system 12. A higher number for the percentage readiness may indicate that the control system 12 (or component) is more suitable for continued operations, while a lower number for the percentage readiness may indicate that the control system 12 (or component) is less suitable for continued operations. The percentage readiness may be derived

by using certain of the rules 110 focused on determining the overall operational health of the control system 12 (or component). The percentage readiness may also be found by using a statistical or historical analysis based on the inputs, such as a Poisson distribution model, linear regression analysis, non-linear regression analysis, Weibull analysis, fault tree analysis, Markov chain modeling, and so on.
The recommendation report 122 may include recommendations on improvements for the control system 12. For example, certain hardware and software upgrades or additions may be recommended. The hardware upgrades may include memory upgrades, network equipment upgrades, processor upgrades, replacement of components of the control system 12, replacement of cabling, replacement of power supplies, and so on. The recommendations may also include adding certain component and related subsystems, for example to enable faster control and/or faster processing of data. The software recommendations may include upgrading or replacing the software components of the control system 12 (e.g., HMI 42, MES, 44, DCS 46, SCADA 48), operating systems, software tools, firmware, microcode, applications, and so on.
The auto configuration report 124 may include details of the configuration of the control system 12. The configuration details may include a list of all software and hardware components used by the control system 12, including details of the components 36, 38, 40, 42, 44, 46, 48, 50, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, and/or 102. The details may include the number of each of the aforementioned components used by the control system 12, version information for each components (hardware version, firmware version, software version, microcode version), interconnections between component (e.g., network diagram, electronic circuit diagrams, information flow diagrams, programming flowcharts, database diagrams), procurement information (cost, delivery times, supplier information).
The early warning report 126 may include a list of issues that may lead to undesired conditions, such as unexpected maintenance events or stoppage of the

control system 12. For example, the early warning report 126 may include issues such as insufficient memory 40, 76, 92, 100, 102, loss of redundancy of the controller 64, low bandwidth capacity of the buses 60, 62, 84, insufficient processing power for the processors 38, 66, 90, 96, 98, failure of any of the components 36, 38, 40, 42, 44, 46, 48, 50, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, and 102, software errors, hardware errors, and so on.
The access based reports 128 may be reports accessible by certain roles, such as system administrators, plant operators, commissioning engineers, managers, programmers, control engineers, procurement personnel, accounting personnel, and so on, and useful in performing the jobs associated with the aforementioned roles. In one embodiment, the access based reports 128 may be based on the data used in the reports 120, 122, 124, and/or 126 focused on the desired role. For example, a control engineer role may receive a report 128 based on all of the data used in the reports 120, 122, 124, and 126, while a procurement based report 128 may distil the data and present data relevant to procurement activities (e.g., manufacturing information, cost information, delivery time information). In this manner, data from the reports 120, 122, 124, and 126 may be distilled and used to more efficiently support roles such as system administrators, plant operators, commissioning engineers, managers, programmers, control engineers, procurement personnel, accounting personnel.
The network status report(s) 129 includes a list of network issues, e.g., for the plant data highway 60, the unit data highway 62, the I/O network 82 (e.g., IONet) and an H1 network 84 and related components, e.g., UDH/PDH network switches, linking devices 78, 80, hubs, wifi equipment, cabling, repeaters, and so on. The network status report 129 may include channel healthiness, packet loss, duplicate packets, network load and internal switch issues such as CPU utilization, FAN status, and so on. Accordingly, a list of network issues and likely culprits for the issues may be provided in the network status report 129.

The security report(s) 131 may include a list of intrusions, both active as well as within a certain time period (e.g., last minute, last hour, last day, last week, last month, last year), as well as a security audit that may list hardware and software systems that would benefit from upgrades. The security report(s) 131 may also list any derived system weaknesses/vulnerabilities, such as lack of two-factor authentication, weak passwords, unsecured components or systems, open network ports, insecure protocols & applications and so on.
The parts report(s) 133 may include a predictive list of parts, components, and/or systems that may be experiencing or about to experience undesired maintenance conditions. For each part, component, and system, the parts report(s) 133 may include a probability of failure, a predictive date of failure, a cost of replacement, a list of sources (e.g., list of suppliers, manufacturers, other customers 26) for the part, component, or system, as well as lead time for replacement from each source, and other parts, components, and or systems that may be affected by the undesired maintenance. The parts report(s) 133 may include a fault tree analysis of part, component, and/or system failure that uses the predictive undesired events to derive a deductive failure analysis for parts, components, and or systems of the plant 14 and/or the control system 12.
FIG. 4 is flowchart of an embodiment of a process 130 useful in analyzing the control system 12 and deriving the health assessment 24. The process 130 may be implemented by using computer instructions stored in a non-transitory machine-readable medium, such as the memory of a computer, a laptop, a notebook, a tablet, a cell phone, and/or a personal digital assistant (PDA). By analyzing the inputs 106 and deriving the health assessment 24 (e.g., TRM readiness 120, recommendations 122, auto configuration report 124, early warnings 126, access bases reports 128, network status reports 129, security reports 131, parts reports 133), the process 130 may enable a more efficient, reliable, and safe control system 12.

The process 130 may acquire data (block 132), such as the inputs 106, related to the control system 12. As previously mentioned, the data may be acquired directly (e.g., through a cable or other conduit), or indirectly (e.g., through files loaded onto a storage medium, such as a CD, DVD, flash card, thumb drive). The acquired data may then be analyzed (block 134). For example, the health assessment suite 18 may use the rule engine 58 and rules 110 to analyze the data. Other techniques including statistical and historical analysis techniques may also be used, such as fault tree analysis, linear regression analysis, non-linear regression analysis, Markov modeling, RBDs, risk graphs, LOPA, Poisson distribution model, Weibull analysis, and/or Markov chain modeling.
The process 130 may then derive (block 136) the control system health assessment 24, for example, by using the control system health assessment suite 18 as described above. The health assessment 24 may then be provided (block 138), to the control system 12 operator and/or manufacturer and to user roles (e.g., system administrators, plant operators, commissioning engineers, managers, programmers, control engineers, procurement personnel, accounting personnel), as well as stored in, for example, the knowledge base 20 accessible by the online life cycle support tool 22. As mentioned previously, the health assessment report may include the TRM readiness report 120, the recommendation report 122, the auto configuration report 124, the early warning report 126, and the access based report 128.
The process 130 may then use the provided reports 120, 122, 124, 126, 128, 129, 131, and/or 133 to improve (block 140) the control system 12 and/or the plant 14. For example, components of the control system 12 may be replaced, added, or upgraded. Likewise, NPI 28 and RCA 30, engineering opportunities 32 and/or revenue opportunities 34 may be derived and used to more efficiently and safely operate the control system 12 and/or plant 14.
Turning to FIG. 5, the figure is an online information flow diagram depicting an embodiment of online information flows 214. That is, through various online

conduits (e.g., virtual private networks (VPN), remote gateways, remote desktop access systems) the health advisor suite 18 may be communicatively coupled to a variety of plant 10 systems. By using online data flows, the health assessment may be provided more quickly (e.g., near real-time or real-time), and subsystems, such as remote services centers and analytical subsystems, may be disposed at any desired geographic location. Further, the health assessment and related data may be distributed through the online data flows, thus providing actionable information to any number of interested entities. Real-time is defined herein as communicating or providing data with minimal communication latency, such as approximately under 2 secs., under 1 sec., under 100 millisec., under 10 millisec., under 1 millisec. Near real-time is defined herein as communicating or providing data with communication latency of approximately under 3, 4, 5, 6, 7, 8, 9 secs.
In the depicted embodiment, the power plant 14 may be communicatively coupled to an on-site monitor system 216 through conduits 218. The on-site monitor system 216 may additionally be communicatively coupled to the control system 12 through conduits 220. As mentioned above, the control system 12 may be used to control the power plant 14, and may use conduits 222 for communications with one or more components of the power plant 14.
As described previously, the control system 12 and/or the power plant 14 may be generating a variety of data, including process dynamics 112, which may be monitored by the on-site monitor 216. The data may further include data 224 related to the plant 14, including the turbine system 68, such as raw sensor data, power generation data, power usage data, temperature data, pressure data, flow rate data, fuel usage data, clearance data (e.g., distance between a stationary and a rotating component), and so on. Indeed, most if not all components of the plant 14 may be monitored by the on-site monitor 216, and the data may be communicated to a monitoring and diagnostic center 226, for example, through conduits 228. The monitoring and diagnostic center 226 may include manufacturer expertise, related, for example, to components of the plant 14, including the turbine system 68 and control system 12. The monitoring and

diagnostic center 226 may use the data 224 communicated by the on-site monitor 216 to derive certain knowledge products 230 useful in health assessment.
The knowledge products 230 may include derivations of machinery status, issues, and/or conditions in the power plant 14, including turbine system 68 and control system 12 status, issues, and/or conditions. For example, the knowledge products 230 may include reports based on the operational status and/or the maintenance status of components of the turbine system 68. Likewise, combustor issues, fuel system issues, exhaust issues, and other turbine system 68 issues may be detailed in the knowledge products 230. Similarly, the knowledge products 230 may detail alerts, alarms, logging data, parameters, and other data related to the control system 12. The knowledge products 230 may be communicated to a remote service center 232 through conduits 234.
The remote services center 232 may additionally receive the health assessment 24 derived by the health advisor suite 18. As described above, the health advisor suite 18 may use the rule engine 58 and the health advisor database 16 to derive the health assessment 24 based on the inputs 106. Accordingly, the derived health assessment 24 may be communicated to the remote services center 232 by using the online conduits 236. Also depicted are online conduits 238 communicatively coupling the health advisor suite 18 to the health advisor database 16.
The computer system 36, HMI 42, MES 44, DCS 46, and SCADA 48, controller 64, and I/O pack 88 may be communicatively coupled to a remote gateway system 240 through online conduits 242, and also use online conduits 244 to connect to other plant 14 components. The health advisor suite 18 may also be communicatively coupled to the computer system 36 (and other control system 12 components such as the HMI 42, the MES 44, the DCS 46, the SCADA 48, the controller 64, and the I/O pack 88) by using the remote gateway system 240. The remote gateway system 240 may include a virtual private network (VPN) gateway, a remote desktop protocol (RDP) gateway, a virtual network computing (VNC) gateway, or a combination thereof. The remote gateway system 240 may

use conduits 246, 248, and 250, which may include encrypted conduits, to communicatively couple the remote service center 232 and/or the health advisor suite 18 to the computer system 36 and/or other components of the control system 12 (e.g., HMI 42, MES 44, DCS 46, SCADA 48, controller 64, I/O pack 88). Indeed, controller system 12 data may be communicated online, in real-time or near real-time, to the health advisor suite 18 and used to derive the health assessment 24. As mentioned above, the controller system 12 data may include may include current utilization data (e.g., percent utilization, total utilization) for the memories 40, 76, 92, 100, 102, utilization data for the processors 38, 66, 90, 96, 98 (e.g., utilization by software processes, utilization by software applications), current configuration parameters used by the components of the control system 12 (e.g., memory page size, virtual memory pages, thread priority, process priority), controller 64 parameters (e.g., master/slave configuration, I/O parameter), bus 60, 62, and 84 parameters, I/O pack 88 parameters, linking device 78, 80 parameters, and field device 68, 70, 72, 74, 86 parameters. For example, monitoring software and/or hardware may be executing in each of the components of the control system 10 and used to communicate the current state of each component, including network components, security-based data, parts-based data, and the like. This monitoring data may then be used by the health advisor suite 18 to derive the health assessment 24.
The remote service center 232 may provide contractual services to the plant 14, such as support and maintenance services. For example, service level agreements (SLAs) may detail levels of support of various plant 14 components, including the turbine system 68 and the control system 12. Accordingly, the knowledge products 230 and the health assessment 24 may be used by the remote services center 232 to provide support services, including actionable intelligence 252. The actionable intelligence 252 may include actionable items useful in improving the efficiency of the plant 14, reducing downtime of the plant 14, and more generally, improving the technical capabilities of the plant 14. For example, the actionable items may include recommendations for additions, upgrades, replacements, and/or

reconfigurations of the plant 14 and or any component or subsystem of the plant 14, including the control system 12. The actionable intelligence may be communicated through the online conduits 246, 248, and/or 250. All depicted conduits, including the conduits 218, 220, 222, 228, 234, 236, 238, 242, 244, 246, 248, 250 may all be online data conduits (e.g., data cables, wide area network [WAN] conduits, local area network conduits [LAN], encrypted conduits, satellite communication conduits, wireless conduits) suitable for communicating any type of data, as described in more detail herein. It is to be noted that the systems, such as the data transmission diagnostic system 35, the dynamic security system 37, the parts tracking/failure prediction system 43, and the edge device 45 may be software systems executable via processor(s), hardware systems, or a combination thereof.
Technical effects of the invention include the online and approximately real-time (or near real-time) gathering of control system information. The gathered control system information may then be used to derive a control system health assessment, for example, by using a rule engine communicatively coupled to a health assessment database. The rules in the rule engine may be edited by using a rule editor. The health assessment may include a triple modular redundant (TMR) readiness report, a controller recommendation, an auto configuration report, an early warning report, an access based report, a network status report, a security report, a parts report, or a combination thereof, suitable for improving and/or optimizing the control system.
This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if

they include equivalent structural elements with insubstantial differences from the literal language of the claims.

1. A system comprising:
a health advisor system comprising:
a data collection system configured to collect a data from a control system;
a configuration management system configured to manage a hardware configuration and a software configuration for the control system based on the data;
a rule engine configured to use the data as input and to output a health assessment by using a rule database configured to store at least one rule; and
a health assessment generator configured to provide a health assessment for the control system, wherein the data collection system is configured to use at least one online conduit to collect the data, and wherein the health advisor system is executable via an edge device communicatively coupled to a cloud infrastructure.
2. The system as claimed in claim 1, wherein the data collection system is configured to use the least one online conduit to collect the data from the control system in approximately real-time, and wherein the data comprises a network data, a security data, a parts-based data, or a combination thereof.
3. The system as claimed in claim 1, comprising a data transmission diagnostics system executable via the health advisor system and configured to:
observe a control system network included in the control system and comprising a plant data highway network, a unit data highway network, a I/O network, an H1 network, or a combination thereof;
derive a channel healthiness, a packet loss, a number of duplicate packets, a network load, or a combination, for the control system network; and

derive a network health assessment based on the channel healthiness, the packet loss, the number of duplicate packets, the network load, or a combination thereof.
4. The system as claimed in claim 1, comprising a dynamic system
executable via the health advisor system and configured to:
observe the control system;
derive an occurrence of an intrusion attempt of the control system, provide a security audit of the control system, or a combination thereof;
provide an alert, an alarm, a security report, or a combination thereof, based on the intrusion attempt, the security audit, or the combination thereof.
5. The system as claimed in claim 1, comprising a parts tracker/failure predictor system configured to provide for an inventory database of parts for the control system; and provide for access to an offsite inventory database of parts for an offsite control system.
6. The system as claimed in claim 5, wherein the parts tracker/failure predictor system is configured to predict a future maintenance event for a part, a component, or a system of the control system based on the data.
7. The system as claimed in claim 6, wherein the parts tracker/failure predictor system is configured to list one or more offsite customers that offer the part, the component, or the system, for sale.
8. The system as claimed in claim 1, whereint the control system is configured to control a turbine system to generate an electrical power.
9. The system as claimed in claim 1, wherein the control system comprises a Triple Module Redundant (TMR) controller having an R core, an S

core, and a T core, and wherein the TMR controller is configured to provide for redundant control operations for the control system.
10. The system as claimed in claim 1, wherein the health assessment comprises a Triple Module Redundant (TMR) readiness report, a controller recommendation, a configuration report, an early warning report, an access-based report, a network status report, a security report, a parts report, or a combination thereof.
11. A method, comprising:
acquiring a data from a control system using at least one online communications conduit, wherein the control system is configured to control a turbine system to produce electrical power;
analyzing the data to obtain a data analysis by using at least one control system health assessment rule; and
deriving a control system network status, a security status, a parts availability status, or a combination thereof, based on the analyzing the data.
12. The method as claimed in claim 11, wherien acquiring the data from the control system comprises observing a control system network comprising a plant data highway network, a unit data highway network, a I/O network, an H1 network, or a combination thereof.
13. The method as claimed in claim 11, wherein deriving the security status comprises deriving an occurrence of an intrusion attempt of the control system, providing a security audit of the control system, or a combination thereof.
14. The method as claimed in claim 11, wherein deriving the parts availability status comprises querying an inventory database of parts for the control system; and querying an offsite inventory database of parts for an offsite control system.

15. The method as claimed in claim 14, wherein deriving the parts availability status comprises predicting a future maintenance event for a part, a component, or a system of the control system based on the data.
16. A tangible, non-transitory machine readable medium comprising code, the code configured to:
acquire a data from a control system using at least one online communications conduit, wherein the control system is configured to control a turbine system to produce electrical power;
analyze the data to obtain a data analysis by using at least one control system health assessment rule; and
derive a control system network status, a security status, a parts availability status, or a combination thereof, based on the analyzing the data.
17. The tangible, non-transitory machine readable medium as claimed in claim 16, wherein the code configured to acquire the data comprises code configured to observe a control system network comprising a plant data highway network, a unit data highway network, a I/O network, an H1 network, or a combination thereof.
18. The tangible, non-transitory machine readable medium as claimed in claim 16, wherein the code configured to derive the security status comprises code configured to derive an occurrence of an intrusion attempt of the control system, providing a security audit of the control system, or a combination thereof.
19. The tangible, non-transitory machine readable medium as claimed in claim 16, wherein the code configured to derive the parts availability status comprises code configured to query an inventory database of parts for the control system; and querying an offsite inventory database of parts for an offsite control system.

20. The tangible, non-transitory machine readable medium as claimed in claim 19, wherein the code configured to derive the parts availability status comprises code configured to predict a future maintenance event for a part, a component, or a system of the control system based on the data.