Semantics to increase synergies and move towards the Industry 4.0 Digital Thread (1/2)

I have been working for manufacturers in the automotive and aerospace industries for about two years. During this period I met industry experts in PLM, technical documentation and after sales from client and partners. 
This industry is quite new for me so the below post is a humble contribution which aims at illustrating how MarkLogic can quickly deliver value in such a context as we do for other industries and with minimum development.

In this first part, we will present:

• The context and challenges
• What MarkLogic provides in the PLM context
• The specificities of the PLM data (The condition of applicability and the product structure)

In the second part, we will explain how to leverage semantic and apply all the concepts mentioned before.

Context and challenges

Manufacturers are used to leverage distributed manufacturing using a network of geographically dispersed suppliers, manufacturing facilities and distribution networks.
Moreover the lifecycle of a product program can sometimes be 10 or 20 years long during which the knowledge must be kept and maintained.

In order to leverage synergies between product programs and/or business processes, better understand designs from suppliers or improve customer services, the manufacturers need to have their systems communicating, from design, to production, to distribution channels and after sales activities. The challenge is that systems may have several generation gap with inability to share the data because of major discrepancies in the concepts manipulated and their data models.

Why MarkLogic?

With MarkLogic, it's rather easy to unlock these data by creating a MDM layer leveraging semantics as a shared language to store, search and extract data coming from the existing systems. MarkLogic can load the data form the sources as-is keeping all properties managed by these systems and then thanks to in database harmonisation and TDE (Template Driven Extraction), the source business objects can then be exposed to be consumed. Here are more details about MarkLogic operation datahub.

PLM MDM Layer

But PLM and technical documentations are also about product structure and effectivity. In other words, what components of the product are considered and under which conditions a specific configuration applies (for which product configuration or which serial number).
Here come the elegant and highly scalable solution MarkLogic can provide by leveraging the core capabilities reverse queries, semantics and inference.

Effectivity management

Effectivity in the industry

There are multiple ways to describe an effectivity in the industry. Actually usually systems have their own way with sometimes supported and unsupported models. I'm not trying to be exhaustive but just give an overview of the different models:

• Based on the product features/options themselves
• Based on product "serial number"
• Based on a part reference and a date of effectivity
• Based on a part reference and a production batch 
• Based on a part reference and a program milestone
• Etc.

At the end, the effectivity is a boolean expression based on conditions on what we could call a context and depends on dates, serial, production batches, product features, and/or milestones, etc. An effecting could be written like one of these:

• SERIAL=X AND PROGRAM=Y
• DATE>X AND PART=Y
• ENGINE=DIESEL AND GBOX=AUTO AND (DOORS=5 OR DOORS=3)
• etc.

Effectivity can be associated to parts, sections of the product structure and even to paragraph in a maintenance documentation.

Residual effectivity

An important dimension of effectivity is that you don't always know all the context. An after sales operator might only provide some of the car features for exemple. In that case it's also important to be able to get the applicable objects event if the effectivity contains more conditions. You then have matching constrains (the one which match the product context) and remaining constraints (not provided) which is called residual effectivity.



So in manufacturing, effectivity is everywhere, in structured and unstructured data.

Effectivity and reverse queries

Effectivity being a boolean expression attached to a piece of data or content, there is an elegant design we can use in MarkLogic. MarkLogic stores indeed its data as documents, json and/or XML documents. These documents can represent a business object (a part, an assembly), a product structure section (a list of links with metadata) and/or of course standard end-user documents (XML being one of the standard for documentations).


What MarkLogic can do also is storing serialised queries in its documents. These queries can then be used by one of the query types supported by MarkLogic: the reverse queries.
When you create a reverse query, instead of building the boolean expression with conditions on the positive results you expect, you ask the database : " What are the documents in the database positive to this particular data", so the parameter of the query is not a boolean expression but the data itself.

Effectivity based on features

If you apply this concept to effectivity management, you can ask the database :
"What are the documents positive to this product context", context being a serial number  and/or production date and/or production batch and/or product features, etc.


The input of the query will look like:
reverse-query({engine:'DIESEL',gbox="AUTO"})

So now, if you store the effectivity query alongside your PLM objects (parts, sections, documents, etc.) you can ask the database what are all the PLM objects matching this particular effectivity context. And as all effectivity models can be converted into a query, you immediately get a repository which can manage any effectivity coming from any system, provider or partner. Best of all, everything is highly optimised and scalable.
I had the opportunity in the past year to make working a database with millions of objects like this (on my laptop) and providing responses without impact on the performances, MarkLogic targeting sub second query responses.

What about the residual effectivity?

The effectivity is converted into a boolean expression, it just has to be extended in order to support residual effectivity and to allow a query with partial context (also some of the mandatory contraints are in the context, eg. some features of a car).

At the end, each context criteria of the effectivity query will be an OR between

• Actual context criteria
• A wildcard value (if the use wants all effectivity to be positive to the particular contexte criteria, eg. SERIAL=ANY
• No criteria is provided for the given context property

For exemple :

• [engine="DIESEL" OR engine="ANY" OR MISSING(engine)] AND/OR [Second expression...]

With such serialised query we can now manage full and partial effectivity and query the database even if we know partially the context. For each positive result, the residual effectivity is the different between the actual effectivity of the result and the provided context values. All this being just a standard MarkLogic query without any development.


To know more about reverse query, you can have a look at MarkLogic Alerting documentation which uses reverse queries.

The product structure management

Now let's apply this to the product structure. If a product structure contains multiple sections with different effectivities, by parsing the product structure, you can generate MarkLogic documents (XML or JSON) containing links which share the same effectivity.

Then if you need to get the product structure of a particular product context (serial/production batch, features), you can use a reverse query to get only the links applicable for this context. The query will return only the section documents which are positive to the context. 

So what's next ?

In the next post we will demonstrate how we can combine the above concepts with semantics in order to create a semantic layer to ease interoperability between systems.

In the meantime, here is a previous presentation we delivered on this topic :

• Capgemini Week of Innovation

Special thanks to 

• my colleague Xavier Bonnamy for his kind review of this article!!
• our partner HCL/Geometric which is a key contributor in the PLM and semantics space.