Patent Application
20220414613
The present disclosure relates to systems and methods for servicing and maintaining a plurality of analytical apparatuses or systems, including the, various instrumental sub-systems modules, components and individual parts contained therein. More particularly, the present disclosure relates to such systems and methods that are capable of identifying and predicting the root causes of actual or potential performance degradation of each of the plurality of analytical apparatuses.
Generally, analytical systems (also referred to, herein, as analytical systems) can comprise of a plurality of parts or components, modules, and instruments. They provide either a determination of the identity or characterization of structure of one or more chemical compounds or substances in a sample, a qualitative determination as to whether one or more compounds are present in (or absent from) a sample and/or a quantitative determination of the relative or absolute amount(s) or concentrations of one or more compounds in a sample. As the complexity of analytical apparatuses increases (in either the number of underlying entities or complexity of individual underlying entities), the process of troubleshooting after unexpected problems arise becomes more difficult and more time consuming. According to a conventional instrument servicing and support procedure, instrument operators/owners place a service call to technical support personnel after a problem arises. They report their description of the problem, which generally include general symptoms and possibly their interpretation of the source of the problem. Without any data on the system or failure state, technical support is not equipped to triage calls to the proper service professional. As such, the call may be assigned to a service support engineer based on locality and availability. This specialist then travels to the instrument site and begins troubleshooting as per their sub-system training. Restoration of proper system performance could take hours to weeks, depending on whether the proper specialist was sent to the site and whether the proper diagnostic tests were run that isolated the problem correctly. This model of service depends heavily on the level of both operator/owner and service personnel training, experience, and proficiency.
The inconsistency and inefficiency of the conventional servicing and support model is unacceptable in the routine analysis and clinical markets. This leads to lengthy and unexpected instrument downtime, as well as potentially high costs to both the service vendor and the instrument operator as a result of on-site trial and error troubleshooting. With the development of systems earmarked as medical devices and clinical or routine applications underway, improving this conventional procedure of instrument servicing is critical.
Many complex analytical apparatuses/systems contain many interacting components/parts, modules, and/or instruments. Failure of any one component, module, or instrument can lead to a system failure. The manifestations of such system failure can be generic and non-diagnostic by themselves. Additionally, some failure modes are characterized not by the binary failure of one component, module, or instrument, but by subtle coordinated changes in a number of variables that lead to system performance decline. Without an understanding of how each component, module, or individual instrument is behaving, diagnosing the root cause of a system failure is time consuming and inefficient. Currently, some analytical instruments or modules include control software that is able to record a number of diagnostic tests and evaluations that may be used later for post-failure troubleshooting in accordance with the conventional servicing and support model. The control software of such instruments or modules may also be configured to record various “status” metrics (pressures, temperatures, voltages, etc) on each system at regular frequencies, as well as system settings. However, according to the conventional model, this information is not collected or saved in a sufficiently comprehensive manner by which it could be properly collected from all components, modules, or instruments in the system, and thus correlated or analyzed together, as a whole. Because of the complexity of most modern analytical apparatuses, one should examine each entire apparatus as a system instead of examining the system instrument by instrument, module by module, and measurement by measurement.
The teachings of the present disclosure aim to address the issue of inefficient and ineffective analytical instrument support according to the conventional servicing and support model. Systems and methods in accordance with the present teachings may use standardized terminologies to communicate and relate data from different types of analytical instruments in a web of interconnected data that serves as knowledge from which operational and/or functional trends may be inferred, future events may be predicted and new insights may be discovered and acted upon. The present teachings include modifications to the way both hardware metrics and application-specific performance metrics are collected and stored. In accordance with the present teachings, such information is structured as a whole system “signature” such that it can be regularly generated, stored, and encrypted locally at each instrument site. The general approach is to augment and enhance operational and/or functional information that is available locally within an analytical instrument and to organize the resulting collection of data into a context that is diagnostically relevant.
Each signature comprises a plurality of fields or entries, each of which conveys information regarding a particular aspect of the state of a particular analytical instrument. The content of each field in each signature (both in definition and statistics) is defined, for each class or type of analytical apparatus or system, by the manufacturer to ensure the relevancy and significance of each field in the signature. Preferably, the signature includes, in addition to readings recorded by on-board sensors, various contextual information such as configuration information, settings, records of errors and other events, usage statistics, and consumables usage. The format of the signature is preferably designed such that it is flexible, adaptable to future hardware changes, small in size (kBytes), and consistent between all hardware platforms provided by a particular vendor. Because the signature is compiled locally (at the site of the apparatus or system to which it pertains), it can be transferred to a remote location for organization into time series and analysis. The information is encrypted, prior to transfer, in a manner that is acceptable to even the most privacy-conscious users, such as those users who work in the medical and health care fields.
From a diagnostic or prognostic standpoint, the benefit of linking hardware and performance metrics from all subsystems of an analytical system into one full system signature is that these very different but related metrics provide context to one another. Instead of relying on the diagnostic value of each metric, one at a time, the provision of a whole-system signature in accordance with the present teachings enables technical personnel to be able to observe subtle changes to the system as a whole. As a result, through correlation of the metrics that have changed or are changing at the same time, service personnel can holistically predict the root cause of system failure, or determine sub-systems that will require preventative action to avoid failure.
By converting conventional specific on-demand, post-failure diagnostic tests into regular, scheduled evaluations and normalizing the recording of all status information to a frequency and statistical representation that provides diagnostic value, it is possible to record signatures that are associated with normal hardware performance. Through data analysis, such nominal signatures may be contrasted to signatures that are associated with reduced performance, errors and instrument breakdowns. The hardware-based fields of a particular signature can then be linked to other fields pertaining to application-specific performance metrics that are derived from running defined quality control samples and methods. The hardware-based fields include status information relating to measured instrumental variables which may include, without limitation, voltages measured at various test points, temperatures and pressures measured at various locations, measured ion beam or electron beam intensity, measured light source luminance, laser power, event occurrence, configuration data, utilization data, etc. The coupling of hardware-related and performance-related fields, such performance-related fields created either automatically or manually, is used to create a plurality of information-rich full-system signatures.
Each full-system signature is constructed from a plurality of signature items, where each item is a specific measurement relating to a particular system variable, operational parameter or event. Additionally or alternatively, each signature item may relate to a variable, operational parameter or event associated with a part, component, module or instrument. These variables may possibly be measured at different respective frequencies. By collecting the various signature items, full-system signatures may be constructed, where each variable corresponds to a specific data field or entry in the signature. Data interpolation, as guided by data propagation rules, allows each such full-system signature (hereinafter, referred to as simply a “signature”) to correspond to a particular time point.
By collecting the signatures from each instrument over time, generally at a central location having computing and database resources, one can populate a database and subsequently mine this data to develop a diagnostic or predictive model of platform failure. Data-mining techniques that employ artificial intelligence software are then used to develop a classifier for each instrument or instrument class that provides maximum accuracy in both diagnosing and predicting failures. Such capabilities comprise the foundation for remote monitoring, remote service-call triage, remote troubleshooting and, in turn, reduced time and cost per service call, and a significant reduction in unexpected downtime though preventative maintenance scheduling.
Signature data may be provided in any computer-readable structured data format. Preferably, however, the signature data is provided in a format that employs defined categories, properties, concepts, relations and entity definitions in accordance with one or more standard ontologies (sometimes known as “knowledge graphs”), as used in information science. Because data may be compiled from a plurality of different analytical instruments, it is desirable that all instruments use a common vocabulary that can enable consolidation of the data from multiple instruments and subsequent formulation of conclusions based on the consolidated data. A standard syntax may be used to communicate information that adheres to the standard vocabulary. Preferably, the syntax is standardized and is both computer-readable and human-readable. As examples, the JavaScript Object Notation (JSON) syntax or JavaScript Object Notation for Linked Data (JSON-LD) syntax may be employed.
Many ontology frameworks are available for adaptation and use with the present teachings. For example, the “Sensor, Observation, Sample, and Actuator” (SOSA) ontologies have been developed by the World Wide Web Consortium (W3C) to provide flexible but coherent perspectives for representing the entities, relations, and activities involved in sensing, sampling and actuation. The “Simple Knowledge Organization System” (SKOS), also developed by W3C, is another standard way to represent knowledge organization systems. So-called “OWL-Time”, also developed by W3C, is used to describe the temporal properties and temporal ordering relationships of any resource denoted using a web identifier (URI), including web-pages and real-world things. Ontologies from QUDT.org, the Allotrope Foundation™ (www.allotrope.org) and many other organizations are also available. These ontologies relate to units and measures (QUDT), analytical data and instrumentation (Allotrope), standard taxonomies (SKOS), and time (OWL-Time).
The developers of the various ontologies may be described as domain specialists. In accordance with the present teachings, various conceptual models are imported from the domain specialists as necessary. In this way, common terminology may be used to describe the very different systems that are inter-networked in accordance with the present teachings. This enables service or support personnel and artificial intelligence algorithms to make sense of and analyze new data from both existing instruments and new instruments and/or from a diverse set of instruments without having to decode the data stream of each particular instrument.
The present teachings include a system diagnostic classifier for each apparatus or system or for each class of apparatus or system. In order to analyze system signatures in an automated manner, a database of system signatures is required. By routinely collecting system signatures from many systems of the same class over time, it is possible to build and train a classifier that will automatically predict the root cause of a problem from a new previously “unknown” signature. Such a capability can allow service departments to quickly and automatically triage each service call in order to ensure that the appropriate service support specialist or engineer is sent on-site to address the problem and that this specialist or engineer arrives with the right parts required to solve the problem. For users that cannot afford or accept unexpected instrument downtime, regular collection and analysis of the system signatures can enable predictive analysis and preemptive action when performance is declining, thereby converting unexpected service calls to planned preventative maintenance visits. Collectively, and across all apparatus and system platforms, this would represent a major improvement to the quality and timeliness of product support.
The building of each classifier will start with the database of historical data. Domain experts can analyze signature data from a failing system and intelligently confirm the cause of a system failure. The determined failure modes can be used to annotate the system signature. These annotated signatures are then fed into the dataset to “train” the classifier. Over time, accumulating sufficient exemplars of various failure modes or categories will enable meaningful training of a classifier. This feedback loop of automation and expert on-site determination will further drive the classifier to more specific and accurate fault diagnosis. There exists a multitude of classification techniques that may be employed, from simple decision trees, to expert systems, to deep learning using an artificial neural network. The advantages of such a networked system; including whole-system signatures, signature-reporting infrastructure, database, computing resources and classifiers; include reduction in warranty period costs, accuracy of part failure reporting and, in, turn, inventory stocking, improved product design and overall improvement in the efficiency of instrument servicing and maintenance.
In accordance with a first aspect of the present teachings, a system comprises: (1) a central location comprising: (a) computer storage media having one or more databases thereon; and (b) one or more computers configured to communicate with the computer storage media; and (2) a plurality of sites, each site comprising: (a) an analytical apparatus; and (b) a site computer system comprising program instructions operable to generate a collection of apparatus signatures, each apparatus signature comprising a collection of data relating to the operation of the analytical apparatus at a time when said signature is generated, wherein the one or more computers at the central location are configured to store each collection of signatures in the one or more databases.
In accordance with a second aspect of the present teachings, a method comprises: (a) generating, at each one of a plurality of analytical apparatuses, each analytical apparatus being disposed at a respective site, a collection of apparatus signatures, each apparatus signature comprising a collection of data relating to the operation of the analytical apparatus at a time at which the said signature is generated; (b) transmitting each collection of apparatus signatures corresponding to an analytical apparatus from the respective site of the respective analytical apparatus to a database at a central location; (c) annotating at least a portion of at least one collection of apparatus signatures with information determined by service personnel in response to failures or reduced performance of one or more of the analytical apparatuses; (d) using computer-readable instructions that are operable to recognize trends in the signature data, performing a computer analysis of a collection of apparatus signatures having one or more annotations; and (e) generating, from the computer analysis, either a prediction of when the analytical apparatus corresponding to the collection of apparatus signatures will require calibration, component replacement, or other servicing or an identification of the root cause of a performance degradation of or failure of said analytical apparatus.
The teachings of the present disclosure also aim to address the issue of inefficient and ineffective conventional support for analytical instrument systems, such as hybrid analytical systems, that comprise more than one analytical instrument, possibly of different types, cooperatively working together with one another. For example, U.S. Pat. No. 10,088,460 teaches a system that includes a sample preparation system for preparing various samples and a sample analysis system, which includes a suitable analyzer, wherein the sample preparation system and the sample analysis system are commonly housed and are interconnected in an automated manner.
In accordance with some aspects of the present teachings, information communicated by an analytical instrument may be structured as a set of “signature” items that may be regularly generated, stored, and encrypted locally at each instrument site. The signature items record functional information that is available locally within an analytical instrument. By consolidating information from multiple signature items, possibly generated by multiple instruments or systems, the resulting collection of data is enhanced and organized into a context that is diagnostically and/or prognostically relevant.
Each signature item comprises a plurality of fields or entries, each of which conveys contextual information regarding a particular aspect of the state of a particular analytical instrument, or a subsystem, component module or individual part of the instrument. The content of each field in each signature item (both in definition and statistics) is defined, for each class or type of analytical instrument, module, component or part, by the manufacturer to ensure the relevancy and significance of each field in the signature item. Preferably, the signature includes, in addition to the reported measurement or record, various contextual information. Metric categories describe the type of data and contextual information that is contained in and reported by a particular type of signature item and further describe how such information should be propagated in time, when information from a plurality of individual signature items is later compiled into a “full system signature”. The various metric categories relate to various types of information pertaining to, for example, instrument configuration, activities, state changes, settings, records of errors and other events, usage statistics, and consumables usage. All signature items may include an evaluation of an “action category”, which may alert users, service personnel, research and development personnel or manufacturing personnel to a need to perform preventative maintenance, service call triage or other actions. Each action category evaluation applies to an individual signature item and indicates the relevant reaction to that data with requiring further processing. The format of the signature items is preferably designed such that it is flexible, adaptable to future hardware changes, small in size (kBytes), and consistent between all hardware platforms provided by a particular vendor.
The data available from signature item data can be linked together and/or compared with historical service records (each of which may comprise a symptom code, and/or one or more root cause codes) in order to annotate signature data patterns with failure classifications. By linking hardware metrics with performance metrics, or linking hardware metrics with service classifications into one full system signature, wherein the metrics are derived from all components, modules, and instruments of an analytical system the context of each of the various data points may be ascertained, both within and between each component, module, and instrument in the system. Instead of relying on the diagnostic value of each metric, one at a time, the provision of a whole-system signature in accordance with the present teachings enables technical personnel to be able to observe and understand subtle changes to the system as a whole. As a result, through correlation of the metrics that have changed or are changing at the same time across the system, service personnel, or an algorithm, can holistically predict the root cause of system failure or performance decline, or determine sub-systems that will require preventative action to avoid failure or repair.
In accordance with a another aspect of the present teachings, a method comprises: (a) generating, at each one of a plurality of analytical apparatuses, each analytical apparatus being disposed at a respective site, a collection of apparatus signatures items, each apparatus signature item comprising a collection of data relating to the function of the analytical apparatus at a time at which the said signature item is generated; (b) transmitting each collection of apparatus signature items from the respective site of the respective analytical apparatus to a database at a central location; and (c) generating a full-system signature of each one of a subset of the analytical apparatuses by combining information from a plurality of the signature items. In some instances, the method may further comprise (d) annotating at least a portion of the full-system signatures with information determined by service personnel in response to failures or reduced performance of one or more of the subset of analytical apparatuses. In some instances the method may yet further comprise the steps of: (e) using algorithms or computer-readable instructions that are operable to recognize trends in the signature data, performing a computer analysis of a collection of the full-system signatures having one or more annotations; and (f) generating, from the algorithmic or computer analysis, either a prediction of when an analytical apparatus will require calibration, maintenance, component replacement, or other servicing or an identification of the root cause of a performance degradation of or failure of said analytical apparatus.
The above noted and various other aspects of the present invention will become apparent from the following description which is given by way of example only and with reference to the accompanying drawings, not necessarily drawn to scale, in which:
The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the described embodiments will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiments and examples shown but is to be accorded the widest possible scope in accordance with the features and principles shown and described. To fully appreciate the features of the present invention in greater detail, please refer to
In the description of the invention herein, it is understood that a word appearing in the singular encompasses its plural counterpart, and a word appearing in the plural encompasses its singular counterpart, unless implicitly or explicitly understood or stated otherwise. Furthermore, it is understood that, for any given component or embodiment described herein, any of the possible candidates or alternatives listed for that component may generally be used individually or in combination with one another, unless implicitly or explicitly understood or stated otherwise. Moreover, it is to be appreciated that the figures, as shown herein, are not necessarily drawn to scale, wherein some of the elements may be drawn merely for clarity of the invention. Also, reference numerals may be repeated among the various figures to show corresponding or analogous elements. Additionally, it will be understood that any list of such candidates or alternatives is merely illustrative, not limiting, unless implicitly or explicitly understood or stated otherwise.
Unless otherwise defined, all other technical and scientific terms used herein have the meaning commonly understood by one of ordinary skill in the art to which this invention belongs. In case of conflict, the present specification, including definitions, will control. It will be appreciated that there is an implied “about” prior to the quantitative terms mentioned in the present description, such that slight and insubstantial deviations are within the scope of the present teachings. In this application, the use of the singular includes the plural unless specifically stated otherwise. Also, the use of “comprise”, “comprises”, “comprising”, “contain”, “contains”, “containing”, “include”, “includes”, and “including” are not intended to be limiting. As used herein, “a” or “an” also may refer to “at least one” or “one or more.” Also, the use of “or” is inclusive, such that the phrase “A or B” is true when “A” is true,
“B” is true, or both “A” and “B” are true. As used herein, the term “module” refers to a collection of computer readable instructions that is directed to enabling a computerized system to perform a specific function or set of functions.
Each analytical apparatus or system 11, 12, 13 comprises at least one local computer that comprises various software or firmware modules. A communications hub or module of each system (not shown in
The one or more central computers 17 (
The instrument-specific signature 21 from each analytical apparatus or system 11, 12, 13 is sent in an encrypted form to the common location 16 in order to preserve data confidentiality and user privacy. The instrument-specific signature 21 may include, without limitation: (a) the time and date of signature recordation and/or transmission; (b) unique instrument identification information; (c) instrument-specific configuration information; (d) status information relating to measured instrumental variables (e.g., voltages at various test points, temperatures and pressures measured at various locations, ion beam or electron beam intensity, light source luminance, laser power, etc.); (d) usage statistics; (e) instrument settings; (f) calibration settings; and (f) results from recent scheduled evaluations or diagnostics; (g) results from recent system suitability-related measurements of standard samples; (h) consumables availability and consumption; (i) serial numbers of the apparatus and, if available, of components; (j) part numbers of components; (k) version and/or revision numbers of software and firmware, etc.
The exact information that is included within the instrument-specific signature 21 is dependent on the class of analytical apparatus to which the data pertains. Such data is stored locally in an event-driven manner, and transmitted to the common location 16 at a frequency that may be determined by the user(s). The data pertaining to measured instrumental variables may be provided as a single average value for each variable, together with a statistical measure of variation, as determined from all measurements of the respective variable made since a prior recording of that signature item.
Alternatively, the data may comprise the raw measurements, without pre-processing.
As a further alternative, the status of each instrumental variable may be recorded in the signature as one of a limited number of status descriptors or indicators such as, for example: “out of nominal range, high”; “within nominal range” and “out of nominal range, low” or “maintenance x required within time t”.
Computer analyses of the data within collections of signatures, as performed by the one or more central computers 17, may be employed for the following uses: triaging of instrument problems or failures by service personnel, scheduling of preventative maintenance of instruments by service personnel, providing operational feedback to research and development engineering personnel, providing operational feedback to manufacturing and process engineering personnel and providing operational feedback to instrument users. The computer analyses improve the efficiency of triage activities because they enable service personnel to quickly identify trends in the acquired signature data that allow categorization and/or isolation of problems and the narrowing of the range of possible root causes of noted symptoms or problems. Likewise, the computer analyses may improve the effectiveness of preventative maintenance activities through accurate prediction of the useful service lifetimes of various instrument components. These predictions inform instrument users of the appropriate times for performing user-responsible maintenance actions, inform research and development and process engineering personnel of any problematic components that are not meeting their expected performance or service lifetimes and inform manufacturing personnel of inventory requirements. Signature data may also include so-called “action category” entries or fields that may be populated with codes that provide alerts to users or service personnel of situations that require immediate or urgent action. One form of alert code may be directed to actions that are the responsibility of instrument users; another form of alert codes may be directed to actions that must be addressed by professional service personnel.
In the example illustrated in
In accordance with the present teachings, the received data pertaining to each individual apparatus or system is analyzed by software, preferably artificial intelligence software, in order to recognize patterns or groupings of deviations of the instrumental variables from their nominal values that are diagnostic of a particular mode of instrument failure or reduction in instrument performance. The analyses are also performed in order to recognize patterns or correlations of time-variation of the instrumental values that may be used to predict how and when a failure or a reduction in instrument performance will occur. When matched to one or more particular modes of failure of an apparatus, the collection of such recognized patterns, groupings and/or correlations form the information basis upon which so-called “classifiers” can be constructed for the particular apparatus. Alternatively, classifiers may be developed for a particular class of analytical apparatus by analyzing, with the artificial intelligence software, consolidated instrument-specific signature received from all apparatuses or systems of the particular class.
In order to develop classifiers, an observed trend, grouping or correlation in the instrumental variables must be matched to an actual failure mode or an observed reduction in performance, as determined in the field by service personnel through direct observation. In this way, the artificial intelligence software is trained. By means of such training, it is expected that the accuracy of classifiers should improve with time.
An initial training set composed of existing historical data or observations may be input to the artificial intelligence software when the networked system 10 is to be constructed or when a new class of apparatus is to be introduced into the system for the first time. In general, the historical data will have been obtained by means of the conventional instrument servicing and support procedure described above. Unfortunately, such historical data may be incomplete or inconsistent, either in terms of the recordation of pertinent instrumental variables, user actions and descriptions of root causes of failure or in terms of the number and types of potential failures actually observed. Thus, any classifiers developed using the initial training set are likely to be only approximately or partially accurate. For this reason, the networked system 10 is configured to constantly update the training set by means of: constant transmission of instrument-specific signature 21 to the central location 16; and occasional input, into one or more databases of the data storage module(s) 18, of problem-resolution descriptions 26, including information about replacement parts required, service hours required, assessments of root causes of failure, etc. by service personnel (see
Subsequently (
The various data acquisition hardware components, as well as associated device drivers, dedicated control software, firmware, etc. are depicted generally at 101 in
Although a different set of variables may be recorded for each sub-system or for each type of instrument, it is preferable that the information from all such control modules is communicated to the central location 16 in accordance with either a common format or a common schema. Preferably, the signature format should also be flexible and future-proof. In simple implementations, the signature data may be communicated to the central location in a native computer binary-code format, such as an array of floating-point numbers, that is consistent among all apparatuses. However, there may be some disadvantages to communicating signature data in that way. For example, such a format makes it difficult to add new features; if one instrument requires a change, then all others must upgrade at the same time. Further, different classes of instruments will generally have different release cycles. For such reasons, it is preferable to use a flexible communications approach and data structure.
The inventors have recognized that JavaScript Object Notation (JSON) and/or JavaScript Object Notation for Linked Data (JSON-LD) are data representation formats that may be readily employed for the purpose of communicating signature data, since these formats are in widespread use, are highly flexible and adaptable, are easy to read and write and are compatible with most programming languages. These types of data representation are not tied to any particular programming language, framework or architecture and maintain flexibility so that each instrument development team may continue to add and modify features of particular instruments, as needed. Each type or class of apparatus may comprise its own unique internal variable types and data representations, provided that the signature data is properly translated into JSON or JSON-LD format at each local site 9 (see
The packaging of local instrument data into the JSON (or other) signature transmission format is performed at the driver or firmware level 101 of each individual instrument.
The signature data is then passed to a communications hub 103 at which it is authenticated and encrypted. The authentication ensures that the signature comprises a valid format and originates from an authorized data source. The encryption step ensures that the signatures cannot be wiretapped, spoofed, or tampered with during their subsequent transmission to the central location 16.
Data signatures from each device are transmitted from the communications hub to a network connection agent 105 that comprises a plurality software or firmware modules (here shown as modules 105a, 105b, and 105c). The connection agent 105 serves as the main communications interface between the central location 16 and either an individual data analysis instrument at the site 9 or, potentially, the entire site. The connection agent 105 also performs the function of storing the encrypted signature data in a database 107 that is local to the site 9. Direct Internet transmissions are managed by an Internet-facing communication sub-module 105a. that is responsible for transmitting validated and encrypted signature data to the central location 16 by means of an Internet connection 131. If necessary, another sub-module 105b of the connection agent 105 may create a package of service-related information 109 (here referred to as a “service bundle”) that may be consulted by a service technician or engineer in the case of an instrument fault or malfunction. Such service bundles are provided in a conventional report format that is intended to describe the nature of an observed instrument fault or failure to service personnel for their use in determining the possible causes of and remedies for the fault or failure.
Preferably, the connection agent 105 also comprises a user interface sub-module 105c that communicates with a user terminal 126 by which users may set various preferences for information transmission timing and for the manner in which information is transmitted. Instrument status and other notifications may be sent to users through the user interface sub-module 105c and user terminal 126. For example, action category alerts that require user actions, such as maintenance actions, may be provided to users in this fashion.
According to some embodiments, a separate communications hub 103 and a separate connection agent 105 may be provided for each analytical apparatus. However, in some instances, a single site 9 comprises two or more analytical apparatuses that communicate with the central location 9. According to some embodiments, only a single communications hub 103 and a single connection agent 105 may service all of the instruments at the site.
At the central location 16, direct communications of encrypted instrument signatures from the various sites 9 are received by signature bundle importer module 119 that executes on the one or more central computers 17. All such signatures are stored in a central database 111a. A service administration module 115 maintains service-department records relating to administrative tasks, bookkeeping, logistics etc. on a service database 111b with which it is in communication. The information in such records may include, without limitation: labor hours, ticket opening and closing data, costs incurred, parts ordered, billing information, codes relating to problem severity, and codes relating to root causes of problems, the latter of which may be entered by service personnel through user interface 125. The service database 111b may also contain root cause and malfunction symptom codes that are, entered into the database by service personnel during service calls to instrument sites. Such codes may be accessed by the one or more central computers 17 and used to annotate signature entries in the central database 111a. Although the service database 111b is schematically illustrated as being located at the central location 16 in the schematic example illustrated in
Preferably, the one or more central computers 17 comprise one or more data-visualization and data-analysis software modules that may be accessed by instrument-vendor personnel, service-department personnel or instrument users/owners by means of a terminal or computer system 125. Generally, the terminal or computer system 125 will be remote from the central location 16 but, in some instances, the terminal or computer system 125 terminal or computer system may be on-site at the central location. Depending upon their respective roles, interested personnel will have access, via their user interface 125, to a particular subset of the data-visualization and data-analysis software modules. Four such modules, 121a, 12113, 121c, and 121d, are illustrated in
Method 201 (
According to the method 203 (
The method 205 (
Preferably, the content and organization of signatures and the content and/or organization of signature data on the one or more databases are such that otherwise-unknown groupings, trends or other bits of information in, the data can be uncovered using the defined categories, properties, concepts, relations and entity definitions of one or more standard ontologies (sometimes known as “knowledge graphs”), as used in information science. Once uncovered, the groupings, trends and other information can be advantageously used in a variety of ways. Table 1 in
Usage case number 1 covers situations in which service call triage is performed automatically and/or remotely. The provision of mineable organized data within the database(s) can allow artificial intelligence analysis to recognize trends that can be presented to service personnel as a list of most probable causes of a service issue. Alternatively, experienced service personnel can query the database to rapidly discern relevant trends that can point to the most probable causes. These capabilities can increase the percentages of service-call issues that may be resolved either remotely or at the time of a first visit by a service technician, thereby overall repair time and cost per service call. Most collected data will support this use case.
Usage cast number 2 of Table 1 (
Usage case number 3 of Table 1 pertains to rapid and/or automatic service response to acute or directly actionable system or parts failures. Such capabilities not only reduce overall apparatus downtime but also ensure that safety concerns are acted upon immediately. According to some embodiments of systems and methods in accordance with the present teachings, technical support is automatically notified when an event has occurred that requires service recovery action.
Usage case number 4 of Table 1 covers situations in which research and development factory personnel utilize data collected from a plurality of apparatuses in order to recognize trends that enable recognition and correction of systemic issues in a timelier fashion than was previously possible. This usage case may relate to, without limitation, hardware, instrument control software, calibration algorithms, and user-interface software. Where available, this use case is supported by metrics that confirm part function and/or failure. Similarly, manufacturing and process systems engineering personnel may utilize the collected data, in accordance with usage case number 5, to more-accurately monitor parts and equipment inventories, to order and/or deliver parts for needed service calls, as well as to confirm proper part replacement on service calls. Finally, in accordance with usage case number 6, users may be provided with maintenance recommendations and various status updates.
Table 2 in
Action category 1C pertains to required actions that are the responsibility of users. Users may be directly alerted to the need to perform a certain action—for example, replenishing a consumable, introducing a calibration sample, etc.—through a user interface of instrument control software, remote monitoring software, or mobile device. Action category 15 pertains to required actions that are the responsibility of service personnel. When the need for service action is detected, an alert and any required data may be routed immediately to technical support personnel. Concurrently, a service ticket may be opened automatically. A 1S action categorization encompasses one or the other of two different usage cases (see Table 1 in
As noted above, signature data may be provided in any computer-readable structured data format. However, for maximum benefit, it is desirable that collected data is structured in accordance with the semantic definitions of objects, measurements, data linkages, etc., as defined in one or more of the various ontologies discussed above or as defined in technologies collectively known as the Semantic Web Stack. In such instances, it is desirable that signature data is communicated and structured in accordance with the syntax of JavaScript Object Notation for Linked Data (JSON-LD). The JSON-LD structure may be consistently employed among signatures pertaining to various apparatuses and systems, including full analytical systems, sub-systems of hybrid systems (for example, a chromatograph component of a hybrid system that also includes a mass spectrometer), individual device components (e.g., an on-board centrifuge) as well as individual parts (i.e., a temperature controller board). Validation of such signatures is essential. To be valid, such signatures must: (a) conform to the JSON-LD specification; (b) conform to the JSON schemas provided during setup or definition of the general networked system 10 (
A schematic depiction of two types of JSON-LD signature communications, as used in methods and systems of the present teachings, is provided in
Each measurement or event, whether at the system, sub-system, component apparatus, or individual part level, carries specific reference information/metadata. The dynamic information that is specific to a given instrument (or component, part, etc.) at a given point in time or span of time is captured in a signature communication. An individual signature might contain information about a single event, for instance, in the case of an error or a state change. Alternatively, it may contain a great deal of data spanning many hours of collection, for instance, the aggregation of multiple sensor readings.
The left side of
The instrument configuration/composition category (metric category number 1 in Table 3 of
Metric category number 4 comprises reports summary statistics of diagnostically relevant readbacks (i.e., on-board sensor measurements, such as of temperature, pressure, voltage, electric current, etc.) together with their appropriate context. Multiple statistics may be used to describe a single readback. Metric category number 5 comprises reports numerical settings (calibrated or otherwise) of all devices including, if available, the results of calibrations. Metric category number 6 comprises numerical results of all user-triggered or scheduled sub-system evaluations, diagnostics, or checks that measure the efficiency of subsystems, especially those known to be altered as a function of use.
Hardware and software error records and codes are reported using metric category number 6. Such reports pertain to a single time point and may, where possible, be linked to an associated readback, diagnostic or check that triggered the error. Metric category number 8 is used for reports of part-specific or feature-specific usage. Such measurements provide context to the usage of particular parts and may, if possible, be linked to part-specific serial numbers. Metric category number 9 is used to report aspects of general system usage. Finally, metric category number 10 is used to report information relating to consumables, where applicable. The information may relate to the relative quantity or quality of various consumables.
Taken together, the collection of signatures that are transmitted from an analytical system in accordance with the present teachings can provide a very precise record of the state of the system at any point in time at a granular level, including information ranging in scope from system-wide down to the level of individual component parts. Some of the signature-related information may be either static, constant over extended periods of time or region-specific. In order to maintain transmission efficiency, such constant or relatively static or contextual signature-related information may be removed from the actual signature transmissions and maintained, instead, in a centralized repository, referred to as a “manifest”. For example, consider a particular temperature reading that is reported by signatures every ten seconds in degrees Celsius, that pertains to a particular part within a particular sub-system and that is measured by different types of temperature sensors, depending on place of manufacture. It would be a waste of communications resources to convey all of that information at each temperature measurement. Accordingly, the unchanging portions of the information—degrees Celsius, sensor type, part and sub-system, in this example—may be consolidated in the manifest. Distributing information in this way not only saves communications bandwidth but also creates the opportunity for manufacturing personnel, process engineering personnel and/or service personnel to update certain characteristics of their signature definitions as necessary, outside of software release schedules.
Systems and methods for remote monitoring, troubleshooting and service scheduling of analytical instruments have been disclosed. The discussion included in this application is intended to serve as a basic description. The present invention is not intended to be limited in scope by the specific embodiments described herein, which are intended as single illustrations of individual aspects of the invention, and functionally equivalent methods and components are within the scope of the invention. Indeed, various modifications of the invention, in addition to those shown and described herein will become apparent to those skilled in the art from the foregoing description and accompanying drawings. Such modifications are intended to fall within the scope of the appended claims. Any patents, patent applications, patent application publications or other literature mentioned herein are hereby incorporated by reference herein in their respective entirety as if fully set forth herein, except that, in the event of any conflict between the incorporated reference and the present specification, the language of the, present specification will control.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2020/062092 | 11/24/2020 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 62940783 | Nov 2019 | US | |
| 63049990 | Jul 2020 | US |
