supporting software interoperability using standardised ... · our initial objective use of...

Supporting software interoperability using standardised interfaces:

issues and needs

IWEI 2015, Nimes, May 27th 2015

Nicola Gessa (ENEA), [email protected]

Angelo Frascella(ENEA), [email protected]

Piero De Sabbata (ENEA), [email protected]

Arianna Brutti (ENEA), [email protected]

Summary

• The initial objective

• The two cases

• The proposed approach

• Standard specification analysis

• Issues and criticalities in the adoption

• Conclusions

Our initial objective

Use of standard specifications for interoperability among

enterprise applications in order to:

• Better data integration, use of information coming from

enterprise software systems (of course!)

• Introducing standard data formats in research projects

• Guarantee more generality to project results

• Feed standardisation activities

• Standard testing and validation

Case 1: The TexWIN project

• March 2010 – March 2013

• Design and implementation of a self-learning and self-optimizing control system to improve production processes and machine configuration.

Case 2: The ARTISAN project

• November 2011 – April 2014

• Design and implementation of a software system able – to monitor energy uses

within the company,

– to report them to the user and

– to optimize production scheduling to minimize the energy consumption in the production processes.

Approach

In TexWIN and ARTISAN the same approach was followed for the definition of the communication interfaces:

• exchanged data between ERP/MES/external actors and the developed software were examined

• definition of the use cases of the projects to properly describe:

– information about industrial processes and products

– information about the machines involved in production

– existing software infrastructures (ERP, PDM, MES systems)

• existing standards were evaluated and the most fitting standard was chosen

• mapping between the data to exchange and the standard was executed (standard Use Profile definition for each case)

Standard evaluation

• Identification of possible standard solutions:

– PPS - Production Planning and Scheduling, OASIS

– B2MML - Business To Manufacturing Markup Language, ANSI/ISA

• PPS and B2MML both model information related to production orders, managing information about processes, machine descriptions and configurations, products, shifts…

• A restricted set of parameters has been used for standard analysis and comparison.

Standard evaluation

B2MML PPS

Information semantic covering

Predefined documents

Documents structure complexity

Customisation mechanisms

Documentation

Existing examples and use cases

Standard evaluation

B2MML PPS

Information semantic covering

Complete Complete

Predefined documents Yes No

Documents structure complexity

High Low

Customisation mechanisms Use of properties and XSD

extensions

External profile declaration, application based

Documentation Good Good

Existing examples and use cases

No No

The choices

Two different motivations for two different choices:

• Usability: TexWIN selected PPS. – Lower complexity – More simple to use

– Adaptation of the library to communication needs - flexibility

– B2MML was too complex and rigid

– Creation of ad hoc XSD documents from the main core schema

– Use of XSD syntax (restriction and enumeration) for conservative customisation, instead of an external application for profile validation

• Diffusion: ARTISAN selected B2MML. – Wider diffusion of B2MML in existing companies

Issues in standard adoption

• Main problems in ARTISAN:

1. Some messages require information that is not present in the corresponding B2MML messages.

• Solution: B2MML property/parameter use for customisation.

2. Some messages have no equivalent messages in the B2MML set of messages.

• Solution: use of “similar” messages with weaker semantic equivalence saving syntactic compatibility.

• Minor issues:

1. fields of B2MML messages useless for ARTISAN, but mandatory according to B2MML schema

2. Low percentage of B2MML messages field is used for ARTISAN messages

Issues in standard adoption

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

Source: ARTISAN

Results in the projects

Both PSS and B2MML were rejected.

• ARTISAN – preferred a simpler communication infrastructure, based on CVS messages: XML

infrastructure seemed, to the developers, useless and time wasting

– 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

– some other technical partners asserted implementation of automated interfaces based on standards would require a huge and expensive work that companies would not be willing to face

• TexWIN – adopted a proprietary XML data format, that was well accepted

– the developers considered the standard non appropriate for the project use cases

– standard implementation has been considered not convenient and too difficult

• In both the cases, the B2MML and PSS structures appeared too complex, rich and not fitting with respect to the real informative needs

• Main attitudes from developers: • “I don’t want to study the standard and

its specification! It’s too hard and boring” - difficulties in the comprehension of the specification.

Issues with the developers



• “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 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 by myself” - the developers thought that in any case it would be easier to re-develop the communication mechanism.


Criticalities

I don’t want to study the

standard…

I think that standard

wouldn’t work

I will solve the problem better on

myself

Information semantic covering - 3 -

Predefined documents - - -

Documents structure complexity 4 1 2

Customisation mechanisms - 2 2

Documentation 2 - 1

Existing examples and use cases 3 1 2

Where is the problem?

• The developers have an intrinsic inertia to consider and study external solutions or ideas but…

…some aspects of standards seems to be the most impacting:

1. the complexity of the document structure

2. the availability of examples and use cases

3. the poor comprehension of the customisation mechanisms required to adapt the standard

• The documentation in general appears less critical because of the good average quality of the specifications.

• Standard usability can be important as much as quality and correctness

Conclusion, need for:

• Wider application of a standard quality evaluation framework

– introduction of more specific criteria related to the adoption and customisation procedures and supports

• Existence of real, complete and clear examples of the standard adoption is very relevant as well as having clear technical documentation

– also to clarify the customisation mechanisms

• Simple and widespread mechanisms for customisation, minimizing the extra effort for this activity for the adopters

• Awareness about the potentiality and benefits achievable from standard adoption

– long-term benefits were not clearly perceived or were exceeded by the short-term drawbacks

• Trace of the standard adoption progress and exchange of results among standard developers and users (not easy to achieve…)

Thanks for your attention!

[email protected]

www.cross-tec.enea.it

www.xml-lab.it

Use of B2MML extension mechanisms (1)

• B2MML provides 4 types of «internal» extension mechanisms (properties, segments, process and product parameters, user extended enumerations)

• Among these, properties are fields that can be “personalized” for adding specific information lacking in the document

• In ARTISAN, for example, we need to exchange the following data model:

Artisan Data Model Description Type Occurrence

List of machines

|-Machine 1-N

||-ID The ID of the machine String 1-1

||-Name The unique name of the machine String 1-1

||-Description The description of the machine String 0-1

||-Priority The priority of the machine Integer 0-1

||-Department The ID of the department, where the machine is located String 1-1

The B2MML document used

for this data model

(ProductionCapability) does

not contain this information

Use of B2MML extension mechanisms (2)

• This is the mapping of the original data model towards B2MML:

Tree of the B2MML

message

Occurrence Corresponding

ARTISAN data fields

Notes

ProductionCapability List of Machines

|-Description 0-1 Value fixed to “List of

Machines”

This would allow to understand the aim of this

message

|-EquipmentCapability 0-N Machine

||-EquipmentID 0-1 Machine/ID The ID of the machine

… … … …

||-

EquipmentCapabilityPr

operty

0-N

|||-ID 0-1 Value fixed to

“Priority”

The name of the propriety

|||-Value 0-1

|||-ValueString 1 Machine/Priority The value of the propriety (priority of the Machine)

The defined «priority»

propriety

XML implementation

<?xml version="1.0" encoding="UTF-8"?>

<ProductionCapability xmlns="http://www.mesa.org/xml/B2MML-V0600"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.mesa.org/xml/B2MML-V0600 file:/[PATH ON THE

COMPUTER]/Schema/B2MML-V0600-ProductionCapability.xsd">

<ID>H212</ID>

<Description>List of Machines</Description>

<EquipmentCapability>

<EquipmentID>M1</EquipmentID> 

<Description>A sewing machine </Description>

… <EquipmentCapabilityProperty>

<ID>Priority</ID>

<Value>

<ValueString>3</ValueString>

</Value>

</EquipmentCapabilityProperty>

</EquipmentCapability>

…

</EquipmentCapability>