=Paper=
{{Paper
|id=Vol-1414/paper12
|storemode=property
|title=Supporting Software Interoperability using Standardised Interfaces: Issues and Needs
|pdfUrl=https://ceur-ws.org/Vol-1414/paper12.pdf
|volume=Vol-1414
|dblpUrl=https://dblp.org/rec/conf/ifip5-8/GessaFSB15
}}
==Supporting Software Interoperability using Standardised Interfaces: Issues and Needs==
https://ceur-ws.org/Vol-1414/paper12.pdf
Supporting software interoperability using standardised interfaces: issues
and needs
Nicola Gessa Angelo Frascella Piero De Sabbata
ENEA X-LAB, Via Martiri di ENEA X-LAB, Via Martiri di ENEA X-LAB, Via Martiri di
Monte Sole, 4, 40129, Bologna, Monte Sole, 4, 40129, Bologna, Monte Sole, 4, 40129, Bologna,
Italy Italy Italy
nicola.gessa@enea.it angelo.frascella@enea.it piero.desabbata@enea.it
Arianna Brutti
ENEA X-LAB, Via Martiri di
Monte Sole, 4, 40129, Bologna,
Italy
arianna.brutti@enea.it
Abstract
This paper reports the experience, gained in two different European
research projects, TexWIN and ARTISAN, in connecting software
prototypes with pre-existing enterprise software like ERP and
Scheduler. The two systems aim to support human in optimizing the
production processes, but their functioning clearly depends also on the
collaboration with external software systems; this collaboration is
needed for production data collection and the interfacing with enterprise
machine control systems. Activities in the projects regarded the analysis
and design of a communication system for the data exchange with the
enterprise software: various possibilities and existing standards were
considered and the feasibility of their adoption established but, despite
the declared project objectives, the standard based interfaces were not
implemented. The aim of this paper is to describe both the followed
approach to introduce standards in the research project activities and to
propose a first analysis of the reasons for the missing concrete adoption
of standardized interfaces.
1 Introduction
Nowadays the enterprises rely on a wide variety of different software to control and manage their activities.
Normally, this software is specialized for solving specific problems, and generally is developed by different software
houses or companies. Usually manufacturing enterprises have ERP (Enterprise Resource Planning) systems, for the
global management (production planning, order managing, data interchange with customers and buyers), but, in
general, they also adopt scheduling programs, for refined machine scheduling (with proper algorithms), MES
(Manufacturing Execution System) that allows interfacing and control of the floor level machines, and PDM (Product
Data Management) systems. All these applications improve the efficiency of the enterprises, in terms of productivity
and optimisation. Introducing new software functionalities – coming from software prototypes developed in research
projects - into an enterprise, for example to improve machine settings or order management, easily implies the need
to exchange or share data with the pre-existent installed software. In other words, since it is not realistic to simply
substitute all the other software, new functionalities must be able to import/export, or simply to exchange data with
Copyright © 2015 by the paper’s authors. Copying permitted only for private and academic purposes.
In: M. Zelm (eds.): Proceedings of the 6th Workshop on Enterprise Interoperability, Nîmes, France, 27-05-2015, published at http://ceur-ws.org
other systems like ERP or MES; considering their variety, a wide range of data formats that can coexist in the same
enterprise.
In order to manage the interfacing of new software with existing ones, standardised data formats could help in
solving such problems, especially when the applicative target of the new software is not limited to a specific domain.
In this paper we want to describe our experience, the problems found and some considerations in facing the definition
of proper interfaces for the TexWIN and ARTISAN systems, in order to allow their connection with enterprise
software.
In section 2 we very briefly describe the two project concepts. This is the starting point to describe in section 3 the
approach followed in both cases for the communication framework design. In solving communication problems, we
considered the possibility to adopt well-known standards, that had been previously analysed and evaluated. On top of
these evaluations we want to highlight problems and requirements in the adoption of IT standards for interoperability
in industry systems: in section 4 we report our experience in the context of the TexWIN and ARTISAN projects and
section 5 provides the conclusions.
2 The TexWIN and ARTISAN projects and the interoperability problem
Globalization is now demanding more and more communication skills, in every sense and in every field. A key point
in achieving this target may be the adoption of appropriate communication standards: this need is well evidenced for
example by the European community, which explicitly requires to accelerate and to simplify the procedures for
standardization (EC 2011). Moreover the interest in the figure of the standard engineer for standard development is
increased: specialized personnel is more and more relevant since specifications are no more only PDF or Doc
documents, but use more technical formats, like UML, XML, meta-data. Curiously, this interest in standard engineers
is manifested especially by the market (and not by standardization bodies), which looks for staff that supports the
companies in following standardization activities, and there is little clarity about the role, training and competence of
a standard engineer (Freericks C. et al., 2012); the contribution of academic research and education on this topic is
still poor. At the same time, “standard quality” is becoming a more and more relevant topic, and methods for standard
quality evaluation are discussed (CAMSS). Other analyses have been done on the standardization life cycle (Hoel T.
et al., 2012) (Brutti A. et al., 2012) (Soderstrom E., 2004), but in this case the focus is on the process to define 3
standards, not on the characteristics of the results. Both in TEXWIN and in ARTISAN we considered standard
interfaces as a possible key factor for software adaptability and utilization.
TexWIN (TexWIN) (Textile Work Intelligence by closed-loop control of product and process quality in the
Textile Industry) was a European research project devoted to the development of a software system that, working in
accordance with the existing enterprise software, improves the industrial productivity, supporting the industrial
process management. The idea was the development of a Case-Based Reasoning system that monitors the machinery,
stores information about the production, and suggests process and machinery configurations considering the gathered
experience
The ARTISAN (Energy-aware enterprise systems for low-carbon intelligent operations) project (ARTISAN)
began after TexWIN and, even if with a different objective, it had similar needs about interoperability. The core of
the ARTISAN prototype was, indeed, a software system able to monitor energy consumption within the company, to
report them to the user and to provide optimized production scheduling that minimize the use of energy in the
production processes (Zampou E. et al., 2014).
It was fundamental in both the projects the possibility to exploit the huge amount of information and
functionalities provided by external software. The two systems in fact should not substitute these components, but
need to collaborate with them. On this purpose the interoperability problem becomes crucial and standard adoption
represents an effective, if not mandatory, solution to simplify the phase of integration and interconnection
3 Definition of a communication framework in TEXWIN and ARTISAN
3.1 Approach followed and standard evaluation
Since the problem of the communication framework definition was similar in TexWIN and ARTISAN projects, we
used the same approach for both:
- exchanged data between ERP/MES/external actor and the project software was examined. A considerable amount of
work was devoted to the definition of the use cases of the projects, that allow to properly describe:
- the data and information about industrial processes and products;
- information about the machines involved in production;
- existing software infrastructure (ERP systems, PDM, MES);
- existing standards were considered and the most fitting standard was chosen
- mapping between the data to exchange and the standard was executed.
This analysis led to the identification of two possible alternatives: B2MML (B2MML) and PPS (PPS). Both of
them are standard data formats designed to model information related with production orders, and the information
management. In order to evaluate the two different standards we identified a restricted set of six parameters on which
we based the analysis and the comparison of the standard 4 quality. The evaluation of the quality of a standard is
challenging; the following is a sub-set of the parameters for the evaluation of ICT standard specification quality.
- Information semantic coverage. It evaluates how much the standard is able to solve and cover the communication
problem. B2MML and PPS were selected because they provide the modelling of a well-defined set of concepts that
are fundamental in the project use cases, for example Order, Resource, Process, Product. On the other hand, quite
obviously, both of them lack specific concepts related to the textile sector (that is one of the use cases for the
TexWIN and ARTISAN projects). Moreover in some cases, their generality could result in an ambiguous
interpretation.
- Predefined document templates. It considers the mechanisms adopted to build the communication messages.
B2MML provides a set of predefined documents, ready to be used as information structures for the data exchange.
On the other hand, PPS does not define document structures, but provides a single library of elements. In PPS each
element can be detailed by its sub-elements and attributes and put in relation with other elements, giving a wide
freedom in using the information structures.
- Documents structure complexity. It considers the complexity of the document structure. The structure of the PPS
is quite simple and easy to use, since it is based on a library of elements and attributes, that can be composed. This
structure on the other hand has the limitation that can be difficult and laborious to put in relations many different PPS
elements (for example an Order and a Process) that are not in a predefined hierarchical structure. Moreover, PPS
provides only one XML Schema that does not give clear reference in terms of usage. B2MML has a limited set of
complex documents (represented with XML Schemas) that are difficult to fit with specific communication problems.
- Customisation mechanisms. It considers the mechanisms available to personalize the standards for specific
situations (customisation is a relevant aspect for standardisation specifications (De Sabbata P. et al., 2005)). The
approach for document profiling and customisation is quite different between B2MML and PPS:
- B2MML provides various methods, based on property/segment/ parameter definition and XSD syntax
capabilities (use of enumeration, namespace, substitution group, ‘any’ element).
- PPS does not use XSD syntax capabilities, it is based on a specific XML format that allows to make
configuration files for user profile definition. It then requires a specific application for profile elaboration and
validation of data exchanged against these profiles.
- Documentation. It considers the quality of the specification description, for the user understanding. Both PPS and
B2MML are well documented.
- Existing examples and use cases. It considers the existence of well documented examples for the practical
comprehension of the standard usage. Both PPS and B2MML lack of relevant and significant examples and use case
descriptions that help in the practical adoption of the standards, in particular in real cases. This is a strong limit, also
because examples are very useful in understanding how to use the specifications. Examples/use cases should
- show practical instances of the standard documents, to clarify how to use and the meaning of the data
structure
- describe the actors and the exchange context in the document usage, in order to understand the way to send
and receive data using the standard.
This analysis is summarised in Table 1.
Table 1: Standard specification evaluation
B2MML PPS
Information semantic Complete Complete
covering
Predefined documents Yes No
Documents structure High Low
complexity
Customisation Use of properties and XSD External profile declaration,
mechanisms extensions application based
Documentation Good Good
Existing examples and use No No
cases
3.2. The TexWIN and ARTISAN choices
In order to implement the communication between the TexWIN system and the external software systems like ERP
and PDM we selected the PPS standard as the most suitable and simple to use. The motivation for this choice are
strongly related to the possibility for the software developers to better understand the lower complexity of the PPS
and to easily use and adapt the library of core elements to the communication needs, whereas the structure of the
B2MML document could result too rigid and inappropriate for specific needs.
So in TEXWIN case the simplicity and flexibility of PPS was finally preferred; this despite the customisation
mechanism, that requires an external application to validate the correct usage of use profiles in data exchange. On this
topic in fact we decided not to use the PPS profiling approach, but to modify the PPS XSD Schema introducing
enumerations to restrict the values of some elements and attributes, and creating new XSD documents starting from
the main core schema. Our modifications are fully conservative, in the sense that they are merely restrictions and
XML instances that are valid with respect to the modified XSD of our profiles are also valid with respect to the
original PSS schema. In this way we avoid our developers implementing or adopting ad hoc solutions for XML
instance validation, that would result in additional irksome activity.
The analysis made in TexWIN was considered valid also for ARTISAN, but an additional factor was taken in
consideration there: the diffusion of the standard. It turns out that, even if PPS resulted simpler than B2MML, it is
scarcely diffused. On the contrary, B2MML is widely implemented by existing companies (this was established
asking to end users from different companies). This factor was considered, at the end, the more important one, so
B2MML was chosen for implementing the interoperable communication in ARTISAN: a mapping between the
ARTISAN messages with companies system and the B2MML messages was executed. This task was not plain, since
among the 21 messages needed for ARTISAN communications, only 5 could be simply mapped towards B2MML.
4. Issues in standard adoption
The mapping between the standard data formats and the ARTISAN data model could provide an example of the
difficulties and issues faced. The main problems can be classified in the following categories:
- Some ARTISAN messages require information that is not present in the corresponding B2MML messages.
- Some ARTISAN messages have no equivalent messages in the B2MML set of messages.
For solving the first problem, a definition of properties or of process and product parameters were used, which
have the advantage of maintaining the compatibility with the original schemas. In the second case, the problem was
more difficult and it was decided to solve it by the use of a weaker semantic equivalence for saving, at least, the
syntactic compatibility of the messages, instead of customizing schemas loosing completely the compatibility. For
example, the Sensor message was mapped to the B2MML equipment message and the List of Shift to the B2MML
Production Capability message. This semantic extension was required by 4 messages.
Table 2: The 4 messages
Problems found in mapping execution N. of involved messages
No problem 5
Lacking of fields, solved by properties mechanism 4
Lacking of fields, solved by parameter mechanism 5
Lacking of message, solved by semantic extension of the existing one 4
Moreover, some other minor problems were encountered in the mapping:
- The same B2MML message is used for more than one ARTISAN message
- There are fields of B2MML messages useless for ARTISAN, but mandatory according to B2MML schema
- Low percentage of B2MML messages field is used for ARTISAN messages
At the end of the analysis, some problems and discussions regarded the adoption of standards in the software
development: it seemed that no major problems were raised by the developers, but at the end they rejected the
standard based solution, and preferred to implement proprietary data format. In ARTISAN, the implementation of an
XML infrastructure seemed, to the developers, useless and time wasting, whereas in TexWIN XML was a well-
accepted technology, but in both the cases, the B2MML and PSS structures appeared too complex, rich and not
fitting with respect to the real informative needs; the only partial matching of the B2MML mapping with ARTISAN
requirements seemed not to guarantee interoperability to the system, and so it was not worth the effort required by its
implementation. Moreover in ARTISAN an unexpected and strong opposition came not by the developer but by a
partner involved in the analysis phase, who asserted that the implementation of automated interfaces based on
standards would require a huge and expensive work that companies would not be willing to face.
At the end, in the projects the developers preferred a simpler communication infrastructure, based on CVS messages
(ARTISAN), or proprietary XML (TexWIN). We can summarize their motivations in three types:
- “I don’t want to study the standard and its specification! It’s too hard and boring” - difficulties in the comprehension
of the specification.
- “I think that the standard wouldn’t work in my case” - the developers thought that the standard was not the right
solution for the problem and that it cannot well solve the communication issues.
- “I will solve the problem better on myself” - the developers thought that in any case it would be easier to re-develop
the communication mechanism.
We think that it is useful to make an effort to understand the causes of this way of thinking and the rejection of
standard-based solution. These motivations are partly the faults of the standard specification, and partly the faults of
the developers and it is difficult to evaluate strict responsibilities between the standard specification developers and
the specifications adopters.
It seems like the developers have an intrinsic inertia to consider and study external solutions or ideas: they are
partially responsible for the rejections, but something can be improved from the specification developer point of
view. In the following table we try to delineate which aspects of the standard specifications are
responsible of the rejection from the developers in our cases.
Table 2 - Standard specification issues (1=low influence, 4=high influence).
I don’t want to study I think that standard I will solve the problem
the standard… wouldn’t work better on myself
Information semantic covering - 3 -
Predefined documents - - -
Documents structure 4 1 2
complexity
Customisation mechanisms - 2 2
Documentation 2 - 1
Existing examples and use cases 3 1 2
In the table, for each of the three aforementioned motivations (in the columns), based on our experience we
provide a “weight” to identify which aspects (in the rows) can be improved in the standards to help their
comprehension and adoption. What emerges from the previous table is that, from the standard developers point of
view, two aspects are the most impacting: the complexity of the document structure and the availability of examples
and use cases; the documentation in general appears less critical because of the good average quality of the
specifications.
Probably the difficulties in understanding practical application are originated by both the lack of samples and use
cases as well as the poor comprehension of the customisation mechanisms required to adapt the standard to the
specific problem. A this initial stage the existence of Predefined Documents does not seem to have an impact for the
developers.
This means that even in the context of the technical specifications the ease of use can be important as much as the
quality and correctness; in some case, when different solutions are available, easiness is fundamental and critical in
the choice of the adopters. Since customisation is a relevant part in standard adoption, specific online (and easy to
use) software applications for customisation purpose could be considered to help in such activity.
5. Conclusions and next steps
In this paper we describe our experience coming from the TexWIN and ARTISAN projects. In these projects we
needed to define a communication framework to let the developed software to exchange data with external enterprise
systems. In our approach we proposed the adoption of standard specifications to allow a wider interfacing with
external software; this solution was however rejected from the developers. We have outlined our standard analysis,
and tried to understand and share the motivations and the problems that caused the rejection.
Our experience suggests the need for a wider application of standard quality evaluation framework (like CAMSS).
It is clear that due to the wide variety of standards this is a difficult but necessary job. Then we point out that the
existence of real, complete and clear examples of the standard adoption is very relevant as well as having clear
technical documentation. Human works and learns from experience and examples, not only from books and theory.
The absence of significant examples and use cases leads the developers to think “the standard is so dark and abstract
that neither the standard developers know how to use it”. Standard evaluation frameworks, like CAMSS, could
prevent such issues through the introduction of more specific criteria related to the adoption and customisation
procedures and supports.
On the other hand, it is clear that a standard specification is not thought to solve a specific problem, but for its
nature it is quite generic. What is absolutely relevant is that the developers of a standard embrace simple and
widespread mechanisms for customisation, minimizing the extra effort for this activity for the adopters. This
mechanism should simplify the work of the standard adopters, not the opposite, being difficult and odd. Use cases
and examples should be provided also to clarify the customisation mechanisms. Relevant issue for the enterprises is
also the awareness about the potentiality and benefits that they can obtain from standard adoption, in term of
efficiency and market. It seems that, in our cases, the long-term benefits were not been clearly perceived or were
exceeded by the short-term drawbacks.
References
[1] TexWIN Project: http://www.texwin.eu/
[2] B2MML - Business To Manufacturing Markup Language: http://www.mesa.org/en/B2MML.asp
[3] PPS - OASIS Production Planning and Scheduling TC: https://www.oasisopen.
org/committees/tc_home.php?wg_abbrev=pps
[4] European Commision (EC), A strategic vision for European standards: moving forward to enhance and
accelerate the sustainable Growth of the European economy by 2020, COM(2011) 311, September 2011
[5] Freericks C., “Standards Engineers – Who Needs Them?”, I-ESA’12, Proceedings of the International
Conference on Interoperability of Enterprise Software and Applications, 2012, Valencia, pp. 457-464, ISBN
978-1-84821-426-2
[6] Hoel T., M. Pawlowki J., “Managing Standards Development in Emergent Fields of Technology Innovation – a
Proposed Model of Key Processes in ICT Standardisation”, IESA’ 12, Proceedings of the International
Conference on Interoperability of Enterprise Software and Applications, 2012, Valencia, pp. 435 - 441, ISBN
978-1-84821-426-2
[7] Brutti A., De Sabbata P., Ciaccio G., Frascella A., Novelli C., “A Model to Analyze Critical Factors in B2B
Interoperability Standards Lifecycle”, I-ESA’12, Proceedings of the International Conference on Interoperability
of Enterprise Software and Applications, 2012, Valencia, pp. 409-414, ISBN 978-1-84821-426-2
[8] Soderstrom E., “Formulating a General Standards Life Cycle”, Proceedings of 16th International Conference of
Advanced Information Systems Engineering - CaiSE 2004, Riga, Latvia, June 2004.
[9] De Sabbata P., Gessa N., Novelli C., Frascella A., Vitali F., "B2B: Standardisation or Customisation?", in
proceedings of e-Challenges conference, Ljubljana, October 19-21 2005, pp 1556-1566, ISBN 1-58603-563-0.
[10] CAMSS - Common Assessment Method for Standards and Specifications:
http://ec.europa.eu/idabc/en/document/7407.html
[11] ARTISAN Project: http://www.artisan-project.eu/
[12] Zampou E., Plitsos S., Karagiannaki A., Mourtos I., “Towards a framework for energy-aware information
systems in manufacturing”, Computers in Industry, Volume 65 Issue 3, April, 2014. Pages 419-433