Traditionally, the information of industrial systems is documented in a large number of documents written in natural languages (with tables, diagrams, etc.). It is time-consuming and error-prone for the users to read these documents, extract their needed information, and check consistency in scenarios such as requirement negotiation, where a system designer and a supplier need to understand and negotiate the requirements of large number of facility assets.
Why not using OWL 2 directly?
OWL 2 is an established formal language widely used for information modelling. However, using OWL 2 directly for information modelling for industrial systems has several drawbacks:
- Engineers need a more straight-forward and easy-to-use tool. To model information in OWL 2 requires excessive training of semantic expertise, including ontologies, logics, and ontology engineering. This is a large time investment for the engineers and they are reluctant to do so. Our past project experience tells us engineers need a more user-friendly and simpler tool.
- Engineers need more specific guidance for information modelling of facility assets. OWL 2 is designed with well-defined syntax and semantics for general purpose of knowledge engineering, and does not provide specific guidance of information modelling for industrial systems. The vast realm of possible ways of modelling and OWL 2’s expressivity and flexibility becomes a drawback, because engineers need guidance in modelling to efficiently build high-quality information models.
Let us consider an example: a system designer wants to build a system, e.g., a building cooling system consisting of pumps and coolers. They need to purchase system elements for the system from the supplier, e.g., pumps. They would specify the requirements of thousands of pumps in a pile of documents and send to the supplier. The supplier needs to go through the piles of documents and read out the exact requirements, and possibly also talk frequently with the solution provider to align the intended requirements and the nominal capability of the products of the product provider.
This process of requirement negotiation in a traditional way is very time-consuming and error-prone, for multiple reasons: the documents are very extensive; they are written for documenting as much as possible information, but not for specific purposes; the natural languages are intrinsically ambiguous.
With IMF models, the requirement negotiation becomes much easier: The system designer gives the system requirements in IMF models, and the supplier gives the system specification also in IMF models; then an automatic semantic verification happens to check if the system specification satisfies the system requirements; meanwhile, other smart reasoning happens such as compliance to standards, automatic generation of system price, etc. People save a huge amount of time and money thanks to the IMF models!