Business processes in a broad range of industries along the value-chain and product life-cycle sufer from significant challenges pertaining to data quality. These challenges include unknown data validity and tolerance ranges, inconsistency across datasets, data incompleteness, and inaccessibility due to data silos. To address these challenges, we need standardised product data exchange between diferent business units along the value-chain and product life-cycle. Existing modelling languages such as OWL are expressive, but not suficiently usable for non-semantic experts, while typically these experts (e.g., engineers) possess the essential knowledge for creating the data models. To this end, we develop an approach named as Information Modelling Framework (IMF) that aims at user-friendly modelling for engineers. This paper presents our ongoing research of the IMF approach and exemplify its usage with a real business case at Siemens Energy.
Motivation. In a broad range of industries, including manufacturing, process, etc. the
business processes along the value-chain and product life-cycle sufer from significant challenges
pertaining to data quality [
e.g., extensive and heterogenous customer requirements in data sheets, documents, and standards, laws/regulations Challenges: collisions
interpretations uncertain specification
Basic Design
Order-Execution
Data: A fraction of proposals gets an order.
with a higher amount and richer documentation.
Detailed Design
Procurement supply chain/ contractor/ data from suppliers
Manufacturing tolerance classes/quality assurance
Logistics
Commissioni ng
Operation Production
Mode Service Mode Maintenance Mode
Recycling
Disposing
industrial information modelling, ultimately aiming to enhance data quality, accessibility, and
interoperability within Siemens Energy and similar industrial contexts [
Challenges. In particular, we consider the following challenges: • C1, Consolidation challenge to address semantic ambiguity and data transformation. The exchange of technical information frequently occurs without standardised semantics and consistent data structures. This process often relies on unstructured documents or datasheets, both in inter-company transactions involving clients and suppliers and within internal teams. The result is a multitude of diferent data formats that require unification for efective communication. • C2, Provenance challenge that results from loss of information along the extended value-chain.
Across the extended value-chain (Fig. 1), valuable technical information can become fragmented and scattered. Multiple copies of the same data fields proliferate, and numerous intermediate steps introduce complexity and potential for data loss. This lack of transparency and data quality hinders operational eficiency and efectiveness. • C3, Automation challenge in ensuring data integrity. Current practices often necessitate manual verification of requirements, a process prone to errors. This manual approach not only consumes valuable resources but also raises concerns about data integrity and accuracy. An automated solution is needed to enhance the reliability and consistency of requirement verification processes.
Requirements. Our goal is to develop an approach to achieve standardised product data exchange between the diferent units in the business process and value-chain. Based on the industrial/business needs, the requirements include the following points: • R1, Standardised/shared: the approach should have standardised vocabulary and information structure with a good coverage and a process of extending it; • R2, Machine-processable: the approach should have automatable information verification mechanism to ensure that the info satisfies a set of specifications; • R3, Precise: the approach should use unambiguous/precise languages, with minimal redundancy, be clear cross references and well-organised; • R4, User-friendly: the approach should be easy to use for engineers (non-semantic experts); • R5, Good interface/modularised: to use the information modules, users only need to understand the modules, and do not need to understand the whole content;
system
• R6, Flexible/versatile: the approach should accommodate a broad range of needs/interests; • R7, Provenance traceable: the approach should be table to track where the information comes from, to have clear provenance along the information propagation chain.
Existing Approaches. The existing approaches can be categorised largely into two groups.
One group is intended for users who are experts in information modelling, such as OWL [
This paper presents our ongoing research on standardisation of product data exchange
between diferent business units along the value-chain and life-cycle. We rely on the approach
of Information Modelling Framework (IMF), which is being developed as an engineering friendly
method to model engineered systems and assets. We aim at using IMF models as the standardised
data exchange format, and present a gearbox use case at Siemens Energy as preliminary results
to exemplify our approach. This new approach has the rigour of logic-based formal languages
while being user-friendly enough for engineers, thus bridging the gap between the existing
approaches.
2. Approach: Information Modelling Framework
Approach Guidelines. We rely on the approach of Information Modelling Framework (IMF)
[
System Block: the boundary of a system
element Terminal (points that indicate input to/output from system boundary)
Location: position of system elements
Activity: cooling (Function)
Cooling
System
(Product)
Artefacts:
pumps,
pipes,
chillers
Three aspects
• Using a limited vocabulary to express engineered systems;
• Alignment with Industrial Data Ontology (former ISO 15926-14) [
System Thinking. To model engineered systems and assets, we first need some basic concepts of system thinking. For simplicity, we brief these concepts in informal descriptions and take the example of a cooling system (Fig. 2). • System and system elements. A system is a group of system elements to achieve a purpose, where a system element is a system by itself. For example, a cooling system achieves the purpose of the cooling function, that is to reduce the temperature of e.g., an physical object. • Breakdown and granularity. A system can be broken down to system elements, and this breakdown can be continued to a granularity that is needed. The cooling system can be broken down input a pumping system and a heat exchanger, where the pumping system can be further broken down into pumps, which can be broken down into pipes and electric drives.
This breakdown goes to a granularity that is needed.
• Interaction. The system elements can interact with other system elements. For example, the
pumping system interact with the heat exchanger via pipes and liquid in the pipes.
IMF Modelling Basics. With the system thinking as the background knowledge, we shortly
introduce some IMF modelling principles and refer the readers to the complete manual for
details [
GearboxAssembly imf:ProductBlock imf:ProductTerminal lis:hasPart imf:connectedTo Gearbox
Casing Gearbox
Shaft Driven Oil Pump
Gear Turning
Device Input Shaft
System
Coupling
Output Shaft
System
Input Shaft
System
Junction
Box
• Three Aspects. As in ISO/IEC 81346-1 in RDF [
Aspect. The relation is used to represent the interaction of a system. – imf:fulfilledBy. This relation has domain of Function Block and range of Product Block, or domain of Function Terminal and range of Product Terminal.
Shared Semantics. IMF aims at semantics shared among the stakeholders. These include three components: • Semantics of information models: Semantics of objects, relations, and attributes is defined in shared IMF models and ontologies, between the stakeholders, such as clients, Siemens Energy, suppliers, etc. • Semantics of attributes: These also include standardised specifications, such as attribute qualifiers, description of a product life-cycle and milestones, solution documentation • Semantics of data validation: Reasoning and data validation are done using OWL reasoners and SHACL engines. Centrifugal Compressing
Mechanical
Driving
Mechanical Transmitting
Housing/ Protection
Electrical Connection Process Gas
Cooling MomentInput
Mechanical System
Lubrication /Cooling Speed Changing
Noise Reducing
Winterisation Moment Changing
Moment Transferring
OilPumping OilDistribution Lubricating OilCooling
Insulation
Casing
A gearbox is a common component of a gas compressor train that is interconnected with many other components. The gearboxes are normally supplied by external suppliers and incorporated into solutions provided by Siemens Energy. This section presents the modelling of a gearbox in the gas compressor with IMF, aiming at standardised data exchange with the IMF models. We discuss the gearbox as a system element in a gas compressor train. The IMF models of a gearbox includes Function Aspect, Product Aspect, and Location Aspect.
Product Aspect. To ease the understanding, we start with the Product Aspect, which describes the breakdown and interaction of the physical artefacts of the system (Fig. 4). • Gas Compressor Train Block. It is the root node of the IMF model in the Product Aspect. A gas compressor train is often referred to as a compressor package or gas compression package. It is a complex mechanical system used in various industries to compress natural gas or other gases. The gas compressor train is the overall artefact that fulfils the function of compressing the incoming gas. The Gas Compressor Train Block has many parts, such as the Gas Compressor Block and the Gear Box Assembly Block. • Gas Compressor Block. The gas compressor is the central component of the gas compressor train that fulfils the primary function of compressing the incoming gas. • Gearbox Assembly Block. The gearbox assembly is a critical subsystem that eficiently transmits power from the driver, typically an electric motor or a gas turbine, to the compressor and other auxiliary components. This assembly ensures that the compressor operates at the correct speed and torque, optimising the compression process. Gearbox Assembly Block has further six parts. For conciseness, we omit these details. • Coupling Block and connections between the terminals. In Fig. 4, we show the Terminals and the imf:connectedTo between the Terminals partially. These connections indicate that the input shaft system of the gas compressor is connected to the coupling via some media (here force), and the coupling is connected to the output shaft system of the gearbox via media. Function Aspect. The Gas Compression Function Block is fulfilled by the Gas Compressor Train Area
Building Gas Compressor
Train imf:LocationBlock lis:hasPart imf:connectedTo Gearbox Assembly
Gas Compressor
House
Gas Compressor
Product Block. We illustrate the IMF model for the system from the function aspect in Fig. 5. • Gas Compression Block. It is the root node of the IMF model in the Function Aspect, which describes the primary and overarching function of a gas compressor, that is to compress gas. This compression process reduces the volume of the gas while increasing its pressure. This function can be achieved if all of its sub-functions are achieved. • Centrifugal Compressing Block is one of the sub-functions, which describes the (potential of) the activity that the compressor uses the mechanical energy to increase the gas pressure. • Mechanical Driving Block describes the (potential of) the activity to provide the mechanical energy. • Housing/Protection Block describes the (potential of) the activity to provide a sturdy and protective casing or enclosure for the compressor’s internal components. It is an activity because it spans over time. • Electrical Connection Block describes the (potential of) the activity to establish the necessary wiring and connections for the control system to interact with the compressor. • These sub-functions can be achieved if their sub-functions are achieved. For conciseness, we omit further details.
Location Aspect. The Location Aspect is the description of installation positions (intended or actual) at the customer site and the product spatial extension. • The first three blocks always exist for all engineered systems. Site Block describes the geographical position and spacial extension of the overall site where the gas compressor operates. Area Block describes a part of the site, and Building Block describes the building, which is a part of the area. • The following blocks describe the gas compress train from the location aspect. The Gas Compressor Train Location Block has three parts, which is the Gearbox Assembly Block, Gas Compressor House Block, and the Gas Compressor Block. These blocks contain attributes of the position and spacial extension of each physical artefacts.
Summary. The three figures (Fig. 4 - Fig. 6) are to exemplify how to describe engineered systems with the IMF models. We could see that despite the very limited allowed vocabulary (graphical elements, aspects, and relations), very complex engineering systems from real business case can be described. In addition, because of the limited vocabulary, representations of such systems in IMF models are easy and intuitive for engineers to understand, and close to the way they think. After having the blocks and terminals, the attributes with specified values and ranges are attached to the blocks and terminals, organising most of the essential information of engineering systems.
Conclusion. With good data quality and standardised data models, we could reduce nonconformance cost, improve productivity (less time spent on search and confirmation) in projects, increase application and data re-use in IT and administration, shorten cycle time of projects, and improve reaction times to third parties. IMF aims at such standardised data models, and the “lingua franca” between organisations, business units along the product life-cycle and value-chain. This work is a step towards a grand goal, and provides preliminary guidelines and experience for future investigation and industrial practice.
Limitations. Looking at the challenges C1-C3, we can see that C1 is partially addressed by the presented IMF approach, while C2-C3 are not touched. Regarding the requirements, we can see that R1, R3, R4, R5, R6 are partially fulfilled by the IMF approach, while R2 and R7 require future research. C3 and R2 require translating the IMF models into some well-defined languages, such as OWL and SHACL. C2 and R7 require more research on tracking the information drift along the product life-cycle and value-chain, especially tracking the attributes changing, because preserving information across the attribute life-cycle is essential in quality assurance. Outlook. As future work, we see the following directions: • semantic interpretation that translate the IMF models to some well-defined language such as
OWL and SHCAL; • semantic verification that automatically validates the data integrity; • software engineering that provides diferent pieces of tooling and end-to-end tooling for IMF modelling, including Mimir, Tyle (by Equinor) as starting point as user interface, and Domain Ontology Editor (by Siemens Energy) for ontology administration; • alignment with various standards, we need shared ontologies mapped to various standards, such as CFIHOS, AAS, etc. • An ecosystem of industrial information modelling is being built across many organisations.
Storyline: Maja. Motivation, challenges and requirements: Christophe, Maja, Arild, Baifan and Foivos. IMF approach: Arild, Baifan, Foivos, Maja. Gearbox case: Christophe. Figures: Baifan, Maja, Christophe, Foivos. Writing: Baifan, Maja, Christophe, Foivos, Arild. This publication is supported by the European Commission H2020 with the project number 958371 (OntoCommons) and by the Norwegian Research Council with project number 237898 (SFI SIRIUS), 308817 (DigiWell).