# Proposal of an Interoperability Standard Supporting PLM and Knowledge Sharing

Simone Parrotta, Jacopo Cassina, Sergio Terzi, Marco Taisch, David Potter,
Kary Främling

► To cite this version:

Simone Parrotta, Jacopo Cassina, Sergio Terzi, Marco Taisch, David Potter, et al. Proposal of an Interoperability Standard Supporting PLM and Knowledge Sharing. 20th Advances in Production Management Systems (APMS), Sep 2013, State College, PA, United States. pp.286-293, 10.1007/978-3-642-41263-9_35. hal-01451767

HAL Id: hal-01451767

https://inria.hal.science/hal-01451767

Submitted on 1 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Proposal of an interoperability standard supporting PLM and knowledge sharing

Simone Parrotta<fnref n="1" />, Jacopo Cassina<fnref n="1" />, Sergio Terzi<fnref n="2" />, Marco Taisch³, David Potter³, Kary Främling⁴

¹Holonix s.r.l., Corso Italia 8, 20821, Meda, Italy
{simone.parrotta,jacopo.cassina}@holonix.it

²University of Bergamo, Department of Engineering, Viale Marconi 5, 24044, Dalmine, Italy
sergio.terzi@unibg.it,

³Politecnico di Milano, Department of Management, Economics and Industrial Engineering, Via Lambruschini 4, 20156, Milano, Italy
{marco.taisch, david.potter}@polimi.it

⁴Aalto University, School of Science, PO Box 15400, 00076 Aalto, Finland
kary.framling@aalto.fi

**Abstract.** This paper presents an overview of the proposed QLM standard under development within the QLM Work Group of The Open Group. QLM aims to become a reference set of standards to be used to provide and exchange information between “intelligent” products and other systems. A part an introduction to QLM, the paper presents also an application scenario where QLM standards are already used in industrial practice.

**Keywords:** QLM, Product Lifecycle Knowledge, PLM standard, IoT standard, Open standard, Intelligent Product.

## 1 Introduction

The Quantum Lifecycle Management (QLM) is the name of a Work Group of The Open Group where Work Group members work to establish open, vendor-neutral IT standards and certifications in a variety of subject areas critical to the enterprise.<fnref n="1" /> In particular, the QLM Work Group provides the framework to develop and consolidate open standards necessary to enable lifecycle management to evolve beyond the traditional limits of Product Lifecycle Management (PLM).<fnref n="2" /> QLM aims to support the “Internet of Things” (IoT) paradigm, pushing it to achieve a business impact next to Internet. The IoT tends to be defined in different ways by different people. The QLM definition is based on an IoT where products can have many degrees of “intelligence”, from barcodes or RFID tags that have only an identifier to smart houses, vehicles and other products that have advanced sensing and actuating capabilities, as well as powerful processing, memory and communication capabilities [1].

<footnote n="1">¹ http://www.opengroup.org/</footnote>

<footnote n="2">² http://www.opengroup.org/getinvolved/workgroups/qlm</footnote>
The QLM initiative comes from past research activities and the EU PROMISE Pro-
ject where a preliminary way to exchange data between intelligent products has been
developed [2-5]. Actually there are three QLM standards: Messaging Interface (MI),
Data Model (DM) and Data Format (DF). The Messaging Interface allows to create
ad hoc information flows between different products and systems. It is used for
transmitting lifecycle related information mainly intended for automated processing
by information systems. The Data Model identifies different information to collect
during the product life, grouping them in logical classes with appropriate relations,
cardinalities and links. The Data Format defines the structure of the message ex-
changed by different products and systems.

Communication between different systems, products or combination of both will
follows a “peer-to-peer” model, the header and the footer of the message will contain
the MI specifications while the content of the message will follow the DF structure
while DM structure could be used to collect automatically the message. These there
standards can be managed easily together, however although each of them can also
be used also as independently from the others. QLM is of interest to business leaders,
system planners, and technology providers seeking to manage dispersed lifecycle
information from disparate physical and technology objects that transcend enterprise
boundaries [6].

2 QLM Work Group Standards

## 2.1 QLM Messaging Interface

The QLM connectivity model is similar to that of the Internet itself. Where the Inter-
net uses the HTTP protocol for transmitting HTML-coded information mainly intend-
ed for human users, QLM uses the QLM Messaging Interface (MI) for transmitting
XML-coded information mainly intended for automated processing by information
systems. The MI provides a flexible interface for making and responding to requests
for instance-specific information. A defining characteristic of the MI is that nodes do
not have predefined roles, as it follows a “peer-to-peer” communications model. This
means that products can communicate directly with each other or with back-end serv-
ers, but the MI can also be used for server-to-server information exchange of sensor
data, events, and other information. The MI allows one-off or standing information
request subscriptions to be made. Subscriptions can be made for receiving updates at
regular intervals or on an event basis – when the value or status changes for the in-
formation subscribed to. The MI also supports read and write operations of the value
of information items. The following xml code shows an example of an MI response
after to a request of for information. The parts of code between brackets with the ac-
ronym qlm represent elements of the MI while the parts with the term pmi represent
the message (or payload) exchanged with a structure different from the QLM Data
Format.

<?xml version="1.0" encoding="UTF-8"?>
```xml
<qlm:qlmEnvelope
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:qlm="QLM mi.xsd" xmlns:pmi="pmi.xsd"
  xsi:schemaLocation="QLM mi.xsd QLM mi.xsd pmi.xsd
  pmi.xsd" version="0.2" ttl="10">
  <qlm:response>
    <qlm result format="pmi.xsd">
      <qlm:return returnCode="200"></qlm:return>
      <qlm:requestId>REQ654534</qlm:requestId>
      <qlm:msg>
        <pmi:targetList>
          <pmi:target>
            <pmi:id>AutomaticLine22334411</pmi:id>
          </pmi:info_item_list>
          <pmi:info_item>
            <pmi:id>FailureRate</pmi:id>
          </pmi:info_item>
          <pmi:value>
            <pmi:int>0</pmi:int>
          </pmi:value>
        </pmi:targetList>
      </qlm:msg>
    </qlm result>
    <qlm:response>
      <qlm:qlmEnvelope>
```

[Example of QLM Messaging Interface Response XML code]

## 2.2 QLM Data Model

The QLM Data Model (DM) was initially conceived as the basis for the information model for the Product Data Knowledge Management/Decision Support System (PDKM/DSS), one of the most important components of the overall PLM system developed by the former EU PROMISE Project.

It enabled detailed information about each instance of a product to be enriched with "field data"; i.e., detailed information about the usage and changes to each instance during its life. It also allowed the aggregation of instance-specific data from many different software systems; e.g., CAD, CRM, and/or SCM and other legacy systems as part of a company's IT infrastructure in order to allow specific decision support information to be generated and made available through the PDKM system.

DM is represented by different classes of information to individuate activities, processes, resources, documents, field data and other aspects through the whole product life. Each class contains dedicated attributes to explain information suggested to col-
lect different information about product. Fig. 1 shows classes, attributes and relations of the DM objects. Specifications of the model will be presented in further works.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Data Model Schema</figcaption></figure>

## 2.3 QLM Data Format

The QLM Data Format (DF) represents, through a xml schema, the structure of the message exchanged between many products and/or systems. The structure of the message is similar to the Data Model schema so that it could be easily recognized by a system QLM DM compatible, thereby automating the data collection. In the schema there are elements with similar structure of DM classes with related relations represented by the hierarchical structure. For instance in the structure of Physical_Product are modeled its attributes as Product_Type, Object...
allowed by DM schema as Property, Part_Of, Resource and so on. Moreover in the
DF schema there is a new element called Object that allows to represent new compo-
nents not modeled with the basic schema. The Object structure could be used to repre-
sents new classes in the QLM DF improving the schema for different end users re-
quirements. Each element in DF schema is described with a UDEF attribute. UDEF is
a standard framework, managed by The Open Group, for describing data to improve
data quality and to enable interoperability.<fnref n="3" /> Each element identified in DF schema has
the same structure of the other. A name identifies the type of element (Product, Re-
source, Object and so on), a complex type element called “qlmId” identifies univocal-
ly the object, a “description” element is used to explain its means with a human read-
able text. Moreover there are some different elements specific for that object and
relation allowed with other DF classes. Finally, information of each element in the DF
is identified through the element called “value”. The value has some non-mandatory
attributes used to identify easily the content of the value tag. The value attributes are:
Type, dataTime and UnixTime. Type is used to describe if the value is an integer, a
string, a floating number and so on while dataTime and UnixTime are used to identify
when this value has been recorded.

The following xml shows an example of DF message about product CZF073,
where is possible to find product type, batch number and creation date information.

<footnote n="3">³ http://www.opengroup.org/undef/</footnote>
[Example of Data Format xml code message from the product CZF073 hot stamping process]

## 3 An example of QLM standards application scenario

QLM standards could be used in a manufacturing scenario where a quality controller needs to collect data about product through a production line. Products go through different machines and processes. The quality controller wants to monitor hot stamping and cutting processes verifying parameters from both machines, such as pressure, times, temperatures, presence of cracks, cooked temperatures and so on to individuate rejected products. QLM standards are used to export data from machines and collect information about products. Monitoring products through the production line allows to individuate rejected products in few/real time, avoiding to increase the value of a scrap product and decreasing the number of rejected products. Moreover, real time information collected from different machines in a standard way, can be easily used and elaborated by many different systems supporting decisions, avoiding failures, evaluating process parameters and implementing maintenance activities.

In this application scenario the Messaging Interface is used to request information about hot stamping and cutting resources, the message is sent using the Data Model where information about field data temperature will be collected. The message exchanged follows the structure of the QLM Data Format.

The following xml code shows a request of temperatures from an oven with five different values of temperature gathered. Elements between brackets with the acronym qlm refer to Messaging Interface elements while parts between brackets with the text df are Data Format elements.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<qlm:qlmEnvelope
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:qlm="QLM_mi.xsd" xmlns:df="QLM DF.xsd"
  xsi:schemaLocation="QLM_mi.xsd QLM_mi.xsd QLM DF.xsd
  QLM DF.xsd" version="0.2" ttl="10">
  <qlm:response>
    <qlm:result format="QLM DF.xsd">
      <qlm:return returnCode="200"></qlm:return>
      <qlm:requestId>REQ323452</qlm:requestId>
      <qlm:msg>
        <df:qlmFieldData>
          <df:qlmID udef="9_8">
            <df:value>oven012</df:value>
            <df:qlmID_Type udef="0.0_8">
              <df:value>internal_oven</df:value>
            </df:qlmID_Type>
          </df:qlmID>
          <df:description>oven temperatures</df description>
        </df:qlmFieldData>
      </df:qlmID>
    </qlm:result>
  </qlm:response>
</xml>
```
```xml
<df:value datetime="2012-10-26T15:33:21">150.5</df:value>
<df:value datetime="2012-10-26T15:33:50">150.7</df:value>
<df:value datetime="2012-10-26T15:34:15">151.3</df:value>
<df:value datetime="2012-10-26T15:34:35">150.5</df:value>
<df:value datetime="2012-10-26T15:34:52">150.3</df:value>
<df:qlmValidFDDType>
<df:qlmMeasuringUnit>
<df:value>celsius_degree</df:value>
</df:qlmMeasuringUnit>
</df:qlmValidFDDType>
</qlmFieldData>
</qlm:msg>
</qlm result>
</qlm:response>
</qlm:Envelope>
```

[XML code shows the response to oven temperatures request]

## 4 Current implementations

QLM standards are being used in some industrial and research applications.

The QLM Data Model has been used by Holonix<fnref n="4" /> as a starting point to develop the i-LiKe platform, a modular and integrated solution for item lifecycle knowledge and traceability. It is composed by cross sectorial modules which cover all product lifecycle phases and industrial operation modules dedicated to phase-specific requirements and needs.

LinkedDesign<fnref n="5" /> is a European project that will develop an integrated, holistic view on data, persons and processes across the full product lifecycle as vital resource for the outstanding competitive design of novel products and manufacturing processes. To achieve this goal the project will develop an integrated information system for manufacturing design. In LinkedDesign the middleware will implement the Messaging Interface specifications while a first version of Data Format has been used to collect data from the field about oven temperatures and rejected products in an automotive production line.

BOMA<fnref n="6" /> is another European project where partners are developing an integrated platform for Leisure Boat Lifecycle Management, enabling services addressing intel-

<footnote n="4">⁴ www.holonix.it</footnote>

<footnote n="5">⁵ www.linkeddesign.eu</footnote>

<footnote n="6">⁶ www.boma-project.eu</footnote>
ligent maintenance, sustainability, upgrades and the used boat market. In particular a
black box will be placed on new boats to collect useful data about its usage which will
be sent to the platform using QLM standards.

5 Future Work

Data about product could be used for particular companies or people in different
ways so that it is necessary improve QLM standards with an element to allow privacy
and security of information exchanged between many products and/or systems. Fur-
ther work will be required for evaluating how the security and privacy aspects could
be managed through QLM standards.

Another work will be to extend the QLM Data Model with classes for specific sec-
tors, in fact the actual version of the Data Model is a cross sectorial model that allows
to close the loop of product lifecycle information with general and not specific re-
quirements from industrial operations. It could be necessary to increase the model if
needed from particular end users or sectors such as nautical, healthcare, logistics or
military.

Finally it will be possible to improve the QLM Data Format developing a modular
approach so that there will be standard classes with specific elements and attributes
that will be used easily by end users. The final user will select the type of class he
wants to use and the different element of that class will appear automatically so that
DF messages can be specified by users more easily.

6 References

1. Främling, K., Nyman, J.: Information architecture for intelligent products in the internet of things. In: Autere, V., Bask, A., Kovács, G., Spens, K., Tanskanen, K. (Eds.), Beyond Business Logistics, Proceedings of the 20th NOFOMA Logistic Conference, Helsinki, Finland, vols. 5–6, (2008), pp. 221–232.

2. The PROMISE Project (2004-2008): A European Union research project funded under the 6th Framework Program (FP6) which focused on information systems for whole-of-life product lifecycle management.

3. Terzi, S., Cassina, J., Panetto, H.: Development of a Metamodel to Foster Interoperability along the Product Lifecycle Traceability. In: Interoperability of Enterprise Software and Applications. (2006), pp. 1–11

4. Cassina, J., Tommasella, M., Matta, A., Taisch, M., Felicetti, G., Closed-loop PLM of Household Appliances: An Industrial Approach. In: Advances in Production Management Systems IFIP — The International Federation for Information Processing, Volume 246, (2007), 153-160

5. Kiritsis, D.: Closed-loop PLM for intelligent products in the era of the Internet of things. In: Computer-Aided Design, Volume 43, Issue 5, (2011), pp. 479-501

6. Främling, K., Shelbourne, J., Cassina, J., Potter, D.:QLM White Paper, An introduction to Quantum Lifecycle Management, (2012)