Exploring new methods of data exploitation in the maintenance domain
Part One: The Current Method
In maintenance many processes we conduct rely on data. Some of this data may need to be elicited from experts and may not be encoded. Codified data may be split between different disparate systems and may not be easily linked. Each different information system may also hold data about the same entities stored differently that makes it incompatible with loss of interoperability.
- The Computerised Maintenance Management System (CMMS) may contain an equipment registry with physical location & equipment breakdown structures, maintenance plans, work orders, notifications and task lists.
- A machinery surveillance system may have the data to define a process diagram, with tag identifiers for sensors and their data, but the tag identifiers may not align with the sensor identifiers in the original engineering drawings.
- There may often be Failure Modes Effects Analysis (FMEA) data that does not share the same physical breakdown of the same equipment as the CMMS.
However, what if we could make these systems more succinct? Ensure that data is not stored in silos or hard to access?
This article will focus on framing the problem of disparate data and how we can rethink our classical ways of managing data, to improve our current systems. In the second blog in this series, we will introduce an emerging data management technology and show how this can centralise our data and use inherent reasoning capabilities to extend it and make it more amenable to ask general questions.
FMEA Data Exploitation
FMEA usually contains a physical breakdown of each system of interest or machine using a hierarchy, decomposing the machinery to constituent parts. The FMEA then looks to define functions, functional failures, failure modes, effects and risks. to populate the data linked back to the original breakdown.
A major reason why we use FMEA in the maintenance domain is that it contains the fundamental information we need to design and produce a maintenance regime. According to the international standard SAE JA1011, the use of an FMEA is mandatory if we conduct an RCM process.
There are some fundamental problems with a hierarchical model of the machinery.
- A single hierarchical equipment breakdown structure does not lend itself easily to model physical or functional dependencies in systems that use shared and distributed elements. Examples include electrical and hydraulic within a system of other mechanical components. We can model the electrical or hydraulic components and connecting pipes and cables, but the connections from the supplies to the actuators that sit in other branches of the hierarchies is problematic.
- In an earlier blog in this series, we have argued that the purpose of maintenance is to preserve functions required of machinery in a defined context by its stakeholders. Why is it that most FMEAs are written against a physical breakdown structure? Surely a functional view of our equipment that links to the physical breakdown view would be more useful.
- The FMEA is often created using spreadsheets, with columns and rows to record the data attributes described above as one-to-many hierarchical relationships. But this does not adequately model the real-world situation, for example, many failure modes may share the same failure mechanisms and vice versa. The true relationships are many-to-many. Additionally, if we misspell a shared entry in one cell compared with others it causes problems with filtering and grouping data.
Use of SQL for FMEA data:
- FMEAs could use relational SQL databases, which can represent many-to-many relationships using link tables to solve this issue. Relational databases can be normalised so that all of the data is only entered once, (to at least strong third normal form) which avoids misspelling errors and other anomalies in the data possible in a spreadsheet flat-file approach.
- However, querying normalised SQL databases through the link tables raises other problems in query complexity and performance. De-normalising SQL schemas is a common practice to improve performance when the data is linked to a user interface application. This change re-opens the risks of data anomalies unless extra verification code is added which can over-complicate application software.
- Adapting and updating a database also presents issues in requiring changes to the underlying schema. If a user interface is built on the database with tight coupling, then this could involve major updates to the whole application. Changes are difficult and expensive and take too much time.
- One important element of an FMEA which does not lend itself well to a spreadsheet tabular view is a description of the operating context of the system of interest. In my experience, an FMEA without an operating context description has marginal value for the design of a maintenance regime.
We do need to remember that the spreadsheet tabular view of FMEA data is familiar and human friendly to many engineering people. Any FMEA application must be able to be reproduced in this report format, but this report format should not constrain the underlying data structure or schema.
A vision of what should be possible
To capture the vital aspects of our systems efficiently and correctly we need a richer representation of our systems and their data. This would enable us to ask fundamental questions that we want to be answered.
Such questions could be:
- If I lost an electrical supply at any point in its distribution what system functions would I lose? This question relates to populating the Effects of a functional failure in an FMEA
- What other components should I isolate, to form a trustable safe-to-work boundary around a component? This is a frequent requirement from maintenance to safely work on a component with the rest of the system still working, or isolating sources of stored energy, or hazardous materials. We could use our data to automatically populate task list instructions, or check the accuracy of existing task lists.
- What effects on the functionality of the whole system will the failure of one, two or many components have? This goes beyond the limitations of an FMEA, in only analysing one failure mode at a time. We should be able to incorporate the data and relationships to reproduce the functionality of a Fault Tree or HAZOPs analysis.
- What are the functional requirements of a system or machine including their performance standards? We want to have many views of our data from different perspectives including Physical breakdown and dependencies, functional dependencies, electrical/hydraulic perspectives, process perspective, and others.
RDF Graph databases would provide a data management system that enables this kind of multi-perspective view based on common data. Linkages are expressed using data triples and the relationships between system entities can be much richer than a SQL database.
The most powerful aspect is the ability to use reasoning to enrich the data. This is where we have existing data and relationships, but using the inherent logic and rules, we can derive more meaningful relationships which allows us to gain more insights and derive more value.
Part Two delves into how this can be done using RDFox a new reputable RDF triple store or database, to illustrate how all this can. To read Part Two of this blog, tune in in a fortnight. Part 2 can be found here.
Has anybody used Graph, triple store or linked data databases in the Maintenance Context? Let us know about your experiences. Which graph database did you use and did you manage to merge different views of your data?