Information Exchange Architecture for Collaborative Industrial Ecosystem
- 309 Downloads
Due to the networked nature of modern industrial business, repeated information exchange activities are necessary. Unfortunately, information exchange is both laborious and expensive with the current communication media, which causes errors and delays. To increase the efficiency of communication, this study introduces an architecture to exchange information in a digitally processable manner in industrial ecosystems. The architecture builds upon commonly agreed business practices and data formats, and an open consortium and information mediators enable it. Following the architecture, a functional prototype has been implemented for a real industrial scenario. This study has its focus on the technical information of equipment, but the architecture concept can also be applied in financing and logistics. Therefore, the concept has potential to completely reform industrial communication.
KeywordsIndustrial information management Digital business ecosystem Multi-sided platform Systems integration Lifecycle management Operations and maintenance
While the purpose of industry is to make products, information management is an important factor in competitiveness. Information is essential in business transactions, logistics and the lifecycle management of production equipment. According to Snitkin et al. (2010), insufficient information management causes costs of 1.5% of sales in asset-intensive industries. A practical example is maintenance, which considerably affects the performance of industry (Foon and Terziovski 2014; Wickramasinghe and Perera 2016). For efficient maintenance, the information of the installed equipment must be up-to-date, available to the right persons and sufficiently extensive. Therefore, careful information management supports efficiency, which is vital for enterprises. Because industries operate with low margins, a relatively little change in total costs often seals if an enterprise is profitable. Besides, in the international scale, even a low-percentage share of costs translates to billions of euros.
To facilitate information management, this study introduces an architecture to enable digitally structured information exchange between industrial enterprises. Its motivation stems from the shortcomings of the current communication practice, which is largely manual. To facilitate communication, there have been standardisation efforts, but the existing standards do not cover all types of information. In addition, there is no digital communication medium that scales well for an arbitrarily large ecosystem. Due to the lack of efficient digital tools, labour-intensive and error-prone means, such as spreadsheets, are utilised instead. This forces employees to manually feed information to systems although the information often exists in a digital format in a system of a business partner. Because system-to-system communication is expensive to implement and maintain, this study suggests a scalable single-integration solution. It introduces an architecture where an open consortium agrees on common business practices and information formats. In the architecture, the actual communication occurs via mediators that deliver information between enterprises. The mediators bring multi-sided platforms (see, e.g., Hagiu and Wright (2015)) to the industrial context.
This study particularly focuses on the lifecycle management of industrial plants. Within the lifecycle domain, especially the delivery of technical information is currently inefficient. Technical information is particularly related to investment projects and maintenance. Although the current focus is on process industry, the concept would have similar benefits in other branches, such as manufacturing and marine industry. Furthermore, the concept is applicable to all fields of information exchange, including financing and logistics.
The structure of this paper is as follows. Section 2 provides an overview of related work. The remainder is based on the design science research method, that is, new knowledge is generated by designing artefacts based on a problem definition, and the artefacts are then evaluated (March and Smith 1995). Section 3 describes the concrete problem followed by a solution – the information exchange architecture – in Section 4. Section 5 introduces a functional prototype that delivers information between the back-end systems of business partners. Section 6 evaluates the artefacts, and a conclusion as well as future work are provided in Section 7.
2 Previous Work for Digitalised Information Exchange
This work is considered novel, as no similar solutions are known to exist in industrial production business. In the past, systems have been integrated to enable automatic information exchange. Still, the scope and scalability of those integrations has been limited. In addition, although existing information structure standards are important, they are insufficient to realise a medium for concrete information exchange. That is, no solution has been generic enough to realise business collaboration where information exchange is implemented with digitally processable media.
Various technologies covered by the EDI (Electronic Data Interchange) concept have been utilised in inter-enterprise business information exchange for decades. According to Bartholomew, for small companies, implementation costs have been a barrier to EDI utilisation (Bartholomew 1997 as cited by Soliman and Janz (2004)). Information standard specialist David R. R. Webber has stated that EDI users have also suffered from its inflexibility (as cited by Becker (2012)). Still, EDI has faced evolution. According to Angeles, there has been internet-EDI development to eliminate the requirement for a dedicated EDI network back in the late 90’s (Angeles 2000). There has also been work to map EDI messages to XML (Extensible Markup Language) to improve interoperability such as an ISO specification for deriving XML schemata (ISO/TS 20625 2002). From this study point of view, a fundamental shortcoming is that EDI does not address the presentation of technical information.
After EDI, various standards have been created for business-to-business (B2B) communication. RosettaNet has been promoted by the electronics and high-tech industry (GS1 US 2017). Universal Business Language (UBL, also standardised as ISO/IEC 19845) has been created to exchange business documents between organisations regardless of the industry (ISO/IEC 19845 2015). Another business document standard is Open Applications Group Integration Specification (or OAGIS) (Open Applications Group 2016). These standards may help exchanging business information, but they are not concerned with technical information.
Electronic invoice (or E-invoice) is a service where invoicing operators deliver invoices and payments between enterprises in a software-processable form thus enabling system-to-system integration. To increase business performance, a wide E-invoice adoption has been declared an important goal within the European Union (Final Report of the Expert Group on e-Invoicing 2009, pp. 14-15). However, a Finnish past study by Lumiaho and RämRänen concluded that the estimated low return-on-investment in SMEs may hinder their E-invoice adoption (Lumiaho and Rämänen 2011). Still, European E-invoice service providers have reported that, from 2013 to 2015, there has been a growth of 23% in the E-invoicing volume between enterprises (European e-invoicing service providers 2016). Compared to technical information delivery, invoicing is rather a simple task, as invoices typically just consist of line entries of the products sold.
There are also standards for information structures or integration with a scope that is too limited for this work. OPC UA or IEC 62541 is concerned with integrating manufacturing equipment to information systems (IEC 62541 2015). Hästbacka et al. (2014) have published an example about its application. ISA-95 or IEC 62264 has its scope in the integration of manufacturing systems with other information systems within an enterprise (IEC 62264 2013). The scope of MIMOSA OSA-EAI is maintenance and condition information (MIMOSA OSA-EAI 2014); a MIMOSA-based service architecture has been introduced by Hästbacka et al. (2016). Although these standards do not cover the needs of this study, they help the unification of information structures thus presumably facilitating information exchange even between enterprises.
In general, there has been progress to advance the technologies for the integration of production equipment. The Industry 4.0 initiative is an example of this Industrie 4.0 (2017).
The standardisation of technical information is crucially important, because information exchange requires commonly agreed structures. ProList, later harmonised with eClass (2013), contains structures for industrial process equipment information. A subset of it has also been published as IEC 61987-10 (2009). Related data structures and equipment classification scheme are available in IEC 61987 CDD (2017). Another related standard is ISO 15926 which is particularly concerned with the engineering information of production plants (ISO 15926-1 2004). As a part of ISO 15926, there is also a reference data library for equipment classification (ISO 15926-4 2007). Related to ISO-15926, the CFIHOS project (Capital Facilities Information HandOver Specification) is a practical effort to support technical standardisation (CFIHOS 2018). Product lifecycle has also been considered. Typically, the various products utilised in a plant have a wide spectrum, which brings complexity to their lifecycle management; this is covered in IEC 62890 (2016).
Recently, the concept Digital Business Ecosystem (DBE) has emerged. In the book by Nachira et al., DBE is defined as a business driven group of actors, supported by modern information technology, that is self-organising like the biological ecosystem (Nachira et al. 2007, p. 5). There have been various European Union associated research projects that contribute to digitalisation from the DBE point of view (Nachira et al. 2007, pp. 200-214). In his doctoral thesis, Korpela states that the ongoing information interoperability effort requires collaborative ecosystem-wide work to be realised (Korpela 2014, pp. 113-114). As a practical contribution, Cojocaru et al. have proposed a concept and an ontology to enable information exchange in a farming business ecosystem (Cojocaru et al. 2014). Ecosystem thinking may promote collaboration thus raising the motivation of enterprises to invest in the related ICT infrastructure.
There has also been work to exchange information in industrial enterprise networks. In the SEFRAM project, an information system was designed to help storing and exchanging the engineering design information of process industry (Paljakka et al. 2009). Vargas et al. present an architecture to support inter-enterprise hierarchical production planning (Vargas et al. 2016). Tchoffa et al. have studied Product Lifecycle Management and interoperability in manufacturer networks in aerospace industry (Tchoffa et al. 2016). Furthermore, a concept called Cloud Manufacturing is expected to bring benefits such as scalability, agility and easier business networking. Tao et al. (2015) have primarily envisioned manufacturing resource services while (Wu et al. 2015) have also covered product design as a cloud service. Information distribution and networked production are also present in machine fleets as studied by Kannisto et al. (2017).
Various organisational aspects should be considered to realise interoperability. Some contributions have aimed at detaching business from the proprietary information models of back-end systems. Model-Driven Development (MDD) is an approach to structure software specifications as models; based on it, Elvesæter et al. (2006) have proposed a model-based interoperability framework. The point of view for modelling may also be enterprise rather than software systems (Agostinho et al. 2016; Weichhart et al. 2016). In collaboration, the mutual trust of organisations is important (Vernadat 2007). Inter-organisational business processes and practices should also be considered to reach effective collaboration (Vernadat 2010; Xu 2011). Service-oriented thinking helps integrating heterogeneous resources between partners (Li and Wei 2014).
Due to the ever-changing nature of enterprises and business, the adaptation ability of information systems has also been discussed. A possible means to achieve this is to utilise semantic ontologies to map incompatible information models together. (Agostinho et al. 2016; Panetto et al. 2016; Weichhart et al. 2016).
3 Challenges of Managing Technical Information
Plant asset equipment is the core of industrial production. Due to the range of production-related functions, the variety of the equipment is also huge. Furthermore, in a large plant, the installed equipment base may cover tens or hundreds of thousands of devices. Due to the large number and variety of items, the management of the related information is a complex task. Unfortunately, additional challenges occur due to the requirement to exchange information between enterprises.
3.1 Information Management in Industrial Business Domains
In this study, the particular focus is on the lifecycle domain and especially technical information. All of the three domains are equally important, but the coverage of the other two is left for future work. In addition, technical information currently has insufficient tools for information management and exchange.
3.2 Role of Information in Plant Lifecycle
The networked nature of modern business causes additional burden to information management. Networking is a result of subcontracting non-core services, as plant operators want to concentrate on their core business. Subcontracting often covers, e.g., engineering or maintenance operations. Engineering design is an example of a task requiring a lot of communication, as the engineers receive production-related requirements from the plant operator and equipment suppliers provide them information about the available products. Likewise, suppliers buy equipment from various manufacturers and deliver it to various operators. That is, often manufacturer sells equipment to a supplier that delivers the equipment to an operator – following the specification of a consulting engineer. Similarly, maintenance operations also require communication: first, the operator must receive the information of any equipment changes that occur in maintenance; second, maintenance history is valuable for the plant operator in maintenance planning; and third, maintenance work requires coordination to minimise its disturbance to production tasks. The more tasks are covered by external services, the more information exchange is necessary between enterprises. However, even if all the work were performed within a single enterprise, there would still be no way to avoid the communication and information management effort. Considering communication, the recently arisen Cloud Manufacturing research searches for responses to analogous problems in a networked environment (e.g., Tao et al. (2015)).
3.3 Heterogeneity of Technical Information Structures
3.4 Research Problem
Clearly, information systems should be developed to increase the performance of information management in industrial enterprise networks. Information processing requires a lot of domain expertise, and its manual accomplishment is both laborious and error prone. With appropriate tools, the automation degree of business processes could be increased, and tacit information management knowledge would be enclosed in software. This would enable commonly agreed communication processes rather than each enterprise or even employee communicating differently.
What kind of architecture enables the digitally structured exchange of technical information in an industrial business network?
What is required so that the architecture scales well for an arbitrary number of business partners that utilise heterogeneous information structures in their back-end systems?
4 Architecture for Collaborative Information Exchange
Fortunately, despite challenges, it is possible to realise efficient information exchange in industrial business ecosystems with the current ICT tools. Still, to utilise these tools appropriately, a carefully designed architecture is necessary due to the complexity and heterogeneity of the environment. The architecture focuses on the communication of enterprises, and it must consider even the evolution of the ecosystem, because it affects the requirements of information exchange.
4.1 Ecosystem-wide, Scalable Interoperation Approach
Alternative (a) illustrates an intuitive yet expensive point-to-point way. “Just connect with your partners and start exchanging information”; the internet even provides a physical communication medium that reaches any office. However, considering scalability, the unsuitability is clear. For instance, a typical plant operator must communicate with dozens or hundreds of equipment suppliers, service providers and equipment manufacturers that each have their own information structures and infrastructure. Therefore, the number of system integrations is high, and their management would be a continuous and expensive burden. In real life, the point-to-point approach is a good investment only if data is transferred frequently with a high volume. This volume is rarely high enough in industrial business networks.
Alternative (b) provides an improvement over (a) by taking an API (Application Programming Interface) approach. Here, the business parties connect themselves to a bus-like communication medium providing their own interface made specifically for business transactions. Compared to alternative (a), the business-orientation promotes easier integration, and the internet provides a suitable physical medium. Still, the business partners utilise heterogeneous information structures, which means that – from the information contents point of view – each integration is still point-to-point, because there is nothing to coordinate the information structures.
Alternative (c) provides a more scalable and cost-effective way for a large ecosystem by introducing a mediator for information exchange. Instead of the individual APIs of (b), the mediator specifies a common information structure. The mediator also coordinates the evolution of the information structure. Still, the parties must map their data formats to the common one, but it is inevitable whenever information is exchanged between enterprises. Compared to alternatives (a) and (b), the mediator role of (c) causes additional complexity, but the approach scales well for an arbitrarily large network. With a single link to the mediator, the business parties can reach any other party that is connected to the mediator. The more parties are involved, the higher benefit is enabled for each enterprise. Besides, because alternative (c) introduces a coordinating actor, it also enables the coordination of collaborative business processes instead of blindly delivering messages. Collaborative business processes are often long, and they have a chain of certain activities. The activities that follow one another include, for instance, request for quotation, quotation, order and delivery. The coordinating actor has the ability to push the enterprises to unify their business practices, which often vary.
Alternative (d) enhances (c) by proposing an open network of mediators. Unlike in (c), which has only one mediator, (d) has multiple. Therefore, alternative (d) has advantages over (c). In (c), a single operator dominates the network, which reduces the desirability of customers to join. Furthermore, especially in large networks, there is probably room for competition about pricing or services, which also favours (d). Still, technical questions arise, such as how to route information from from the clients of one mediator the clients of another. Fortunately, an analogous routing problem has been solved in mobile phone networks and the IP network a long time ago. Furthermore, now that there are multiple mediators, there must be a dedicated organisation that agrees on the data formats and other business practices of the network. Compared to other alternatives, (d) is most complex, but it also provides the best scalability, which is a fundamental requirement in this study. Additionally, based on real-life experiments, an ecosystem truly requires openness instead of a sole mediator proposed in alternative (c). Therefore, alternative (d) is the basis of the following architectural considerations.
4.2 Open Consortium for Common Agreements
To enable interoperability with common agreements, there must be an open consortium to create and maintain the agreements. No ecosystem actor has the capabilities to realise information integration alone (Korpela 2014, pp. 113-114). The consortium has a balanced representation of its members, and no enterprise has a dictating role. The consortium orchestrates each of the three collaboration domains: enterprise, value chain and lifecycle (where technical information is a part of the lifecycle domain; the domains are specified in Collaborative Manufacturing Management Strategies (2002, p. 5)). If needed, each domain has a coordinator of its own, but these coordinators must follow the orchestrator. The consortium as well as the coordinators of the domains are agnostic on the implementing technologies and platforms, which provides a degree of freedom in the implementation of information exchange.
As the consortium agrees on the common business practices and information structures, standards should be utilised as much as possible. Still, it is typical that standards do not cover all needs. Thus, some agreements must probably be specified as extensions to existing standards.
It has already been acknowledged that an open ecosystem is important for the industry of the future. The project DBE Core (2018) is an example of the commitment of enterprises to make common agreements for ecosystem-wide interoperability.
4.3 Role of Mediators in Lifecycle Domain
This study has its particular scope in the lifecycle domain of industrial production. In this domain, the business is concerned with equipment-related activities, such as investment projects and maintenance.
The mediators should also take the business role of a matchmaker, as Evans and Schmalensee (2016) would call it. Matchmakers help customers to find and purchase services. In the consumer business, matchmakers appear in several business fields, including the booking of accommodation or ordering a pizza by choosing one of various service providers. Respectively, in the lifecycle domain, the mediators should take advantage of their role by providing additional matchmaking services. The mediators have the basic role of coordinating collaborative business processes and delivering information between business parties. Considering this role, the mediators could also help customers to discover services, as it would otherwise occur outside of the platform. The services would include the typical services of the lifecycle domain, such as engineering, equipment sales and maintenance.
4.4 Design Aspects
Considering the physical platform for implementation, cloud computing is a promising tool. Cloud-based systems provide a feasible scalability for a high number of customers. However, there may also be legal questions about the physical location of customer data, because some data is considered too sensitive to be stored in an arbitrary geographical location.
4.5 Information Items and Workflows
Technical information has various subcategories to be managed. First, some information is common to all devices that represent the same product, while some is related to an individual device. Second, one or more attachments must be delivered, including operating manuals, certificates and bills of material. Respectively, some attachments are related to a product and some to an individual device. Third, the information of engineering design is important for equipment purchases. Considering the complexity of the related information management, it would be a relief if the manufacturer stored all product-related information. Unfortunately, various devices are actually tailor-made assemblies, so their information has an individual nature. Besides, plant operators often want to guarantee their access to the information. Therefore, a full dependency on manufacturer-provided information is often intolerable, and the heterogeneity of such information (due to lack of common information formats) is another obstacle.
A few standards for information exchange within the lifecycle domain
5 Prototype for Technical Information Exchange
To demonstrate the designed information exchange concept, a prototype has been implemented. The prototype provides a medium for digitally structured information processing. Using the prototype, there have been experiments with everyday business data to demonstrate the practical value of the concept.
5.1 Information Exchange Cases
In an everyday maintenance service, a usual business model is to provide a spare parts storage so that a quick replacement is possible. The maintenance service provider has a spare parts storage for equipment. Whenever device maintenance is required, the device is detached from the production process and replaced with another device. If the related engineering design information is available to the maintenance provider, it has two options. Either a similar device will be installed, or it is replaced with another one that fulfils the production process requirements but provides an appropriate performance (IEC 62890 2016, pp. 57-58). However, often an identical device is just installed and the one removed is either repaired or thrown away.
In contrast, the usual business process of equipment renewal resembles the typical purchase process of various industries. Often, equipment renewal projects start by sending requests for quotation to potential equipment suppliers and then choosing the best quote. The information of process engineering must be delivered to the suppliers, so they can select and provide appropriate equipment. Depending on the number of equipment suppliers and if consulting engineering services are applied, multiple arrangements are possible.
In the experiments made with the prototype, no engineering design information is exchanged, but the focus is on the delivery of equipment information to plant operators. While important, engineering design information exchange is another case requiring further software design effort – thus, it is performed by traditional means, and its digitalisation is left as a future task. Still, some information is still delivered from the equipment hierarchy, because it is necessary to associate all equipment information to the correct position in the hierarchy.
Each plant operator and equipment supplier has a dedicated storage silo on the web application platform that serves as a secondary master data container. The storage also has a website as the user interface, so incoming and outgoing data is observable. Such a “data lobby” is necessary because direct information exchange between back-end systems is not desirable for two reasons. First, the business parties want to have the possibility to observe, validate and possibly enrich incoming data before approving it for their systems. Second, any data to be delivered to a business partner is gathered there before delivering it as a batch. Each batch is associated to a task that represents an instance of a collaborative business process. Therefore, a task is created for each maintenance request and each equipment batch to be purchased. The tasks also enable free-form messages to be submitted to other users; inter-enterprise communication is enabled by synchronising the tasks between plant operator and equipment supplier websites.
While interfaces and system interoperation are essential, the design of web applications is also important. In the prototype, such applications include the import and export applications as well as the web user interface built on the web application platform. To facilitate application development, software libraries have been implemented.
5.3 Practical Experiments
For experimentation, the information systems of two equipment suppliers and two plant operators were integrated with the platform. For each party, the information exchange was implemented for at least one equipment type. The equipment information included both product-related and individual device information as well as external attachments (such as operating manuals and certificates).
The details of the experiments made with the platform prototype
Fields in record
Export to back-end
It is clear why there have long been means to transfer business information electrically (such as EDI) but no similar methods exist for the technical information in industry. Compared to the information of typical business transactions, technical information is far more complex and versatile. Even in a single plant, the technical information often comprises dozens or even hundreds of different equipment types (such as valves, pumps, sensors and electric motors) that have their specific information structures. Although there has been standardisation efforts, there is no concrete medium to exchange technical information in a digitally structured format.
The envisioned information exchange architecture provides various improvements in industrial ecosystems. Although industrial plants will always remain individual, it would still significantly reduce transaction costs to apply both commonly agreed practices for information exchange and information mediators that coordinate the communication. Due to common practices and mediators, each business party would just implement a single adapter. The adapter would wrap any enterprise-specific complexity and provide digitally structured connectivity with any party in the network.
To enable common practices, the main challenge is a commonly agreed governance model. There must be a consortium to not only create the practices but also maintain them, so that the evolution of the business environment is considered. Therefore, the consortium must be open, and it also repeatedly requires collaborative effort from its members. However, the alternative is to preserve the current situation where some information-related standards exist but there are no coordinators. Then, information exchange would always require laborious and error-prone manual processing. The question is whether the cost of collaboration and coordination is lower than the cost of problems and additional work caused by the current information management methods. The problems of the current practices are concrete. For instance, if a production unit or an entire plant remains non-operable because wrong replacement parts have been supplied for maintenance, the costs are often hundreds of thousands of euros or even more. Additionally, there are also indirect costs, as the reliability of delivery is an important competitive factor.
Despite the overall cost savings of the concept, the realisation of an adapter may be too expensive for the business partners that have a low yearly turnover and only minor ICT infrastructure. A similar obstacle has appeared for EDI implementations in the past (Bartholomew 1997 as cited by Soliman and Janz (2004)). For low-volume partners, the concept should offer a more lightweight mechanism – perhaps a SaaS web application that enables business interaction without any back-end integration.
Interoperability is not only related to information exchange, but it also reflects to internal enterprise structures thus bringing further advantages. The so called Conway’s law argues that a system design resembles the communication structure of the organisation it serves (Conway 1968). Here, however, interoperability is enabled with an “architecture first” approach, and no single business party dictates the system structure. Then, each party must actually adapt its own workflows. Such progress will likely unify organisations in the long term, which reduces the need of tailored services and, potentially, lowers costs. Furthermore, enterprise modelling promotes collaboration (Agostinho et al. 2016). Respectively, it can be argued that collaboration efforts drive enterprises to adapt their infrastructure towards a common model. If this applies, ICT systems would become more heterogeneous, which reduces the number of customisations. Then, the “economies of scale” would apply in the development and maintenance of ICT infrastructure.
In collaborative business, all the parties are considered to have benefit from the business model. This work has focused particularly on the plant operator side. For an operator, it is clear that if information exchange is both more efficient and produces fewer errors, advantages are expected. Still, other parties than operators would also receive benefits. Equipment suppliers and manufacturers also need information management to support their business; appropriate information helps suppliers match their services to customer needs (Saarijärvi et al. 2014). On the other hand, the business intelligence of service providers is empowered by the data of their customers; in business intelligence, external data brings more power compared to internal company data (Castellanos et al. 2013). Naturally, the access of suppliers to plant information depends on the openness of plant operators. Still, at least some customer information must be exposed in business transactions, and the architecture facilitates the collection of this information due to the digital communication method. While plant operators should push their suppliers towards this business model, a higher supplier desirability is expected if benefits occur to all parties.
The implemented information mediator prototype showed its practical usefulness by saving time and effort as equipment information was delivered. There were two use cases (maintenance and renewal project) where information was imported from back-end systems and then exported in the recipient end. As both import and export had been configured to use the back-end system templates, neither manual data mapping nor conversion was required during execution. The amount of delivered data was considerable in size, although more benefit would occur in repeated information delivery. Even though there was a limited number of equipment suppliers and plant operators in the experiment, there is no obstacle for an arbitrarily large network of partners.
The limitation of the prototype is that there is currently no open consortium to coordinate the ecosystem. Therefore, there are neither open API specifications nor actual adapters for business parties. There is also no mediator network, but the prototype only includes a single mediator. Nevertheless, as the open ecosystem develops, it becomes possible to form a mediator network that utilises commonly agreed APIs.
On the technological side, the prototype has been built on a single-instance application platform, which could be replaced with cloud-based infrastructure. On a cloud platform, the core challenges of information processing would be similar, and there are no conceptual differences. However, a cloud-based solution would have advantages, such as scalability and availability.
The prototype should also support more technical information types. In various use cases, it is essential to deliver especially the information of engineering design. As these structures resemble equipment information, the work is supposed to be straightforward – however, the business scenarios that involve consulting engineers are more complex than information delivery just between a supplier and a customer. Furthermore, the current prototype has a limited support for business processes and business information delivery, as the current focus has been technical information.
For data adapters, an interesting question is whether semantic web technologies would reduce the work required for data mapping (as suggested by Agostinho et al. (2016), Panetto et al. (2016) and Weichhart et al. (2016)). The current architecture design relies on coordinated information exchange and information mediators that quickly adapt to new business needs. When the business needs change, the semantic web technologies could save manual work by automating data conversions between formats. However, it is questionable whether the power of automated semantics is sufficient for complex structured information, such as equipment data. Still, a hybrid solution of an automated and static conversion could be considered. In this approach, semantic technologies would generate static, reusable data mappings under human supervision. However, even for this approach, the complexity of the data may be too high. It is also an obstacle that the current data structures usually lack semantic metadata, which prevents the application of semantic methods.
This paper introduced an architecture to exchange information between business parties in a networked industrial ecosystem. The motivation is that the operation of industrial plants necessitates information exchange in various activities, of which this study concentrates on the lifecycle domain and particularly technical information. Because information exchange is laborious and expensive with the current tools, this study introduced an architecture to enable digital information processing. In the architecture, common agreements are made to unify the business practices and information formats within an ecosystem, and information mediators coordinate communication. To demonstrate the functionality and benefits of this approach, a prototype was presented. The architecture has considerable potential to increase efficiency in information management. Indirectly, it would also enhance the overall production performance by improving the quality and availability of valuable data.
Various future research tasks remain. An open consortium should be formed to create and maintain the commonly agreed communication practices. Then, following the practices, the proposed prototype should be extended to realise the mediator role, and any enterprises in the ecosystem would build their adapters to enable connectivity with a mediator. Furthermore, this work focused on technical information in the process industry. In the future, the scope should also include financing and logistics as well as the domains of piece goods manufacturing and marine industry. Finally, it is notable that the ICT technologies to build the digital ecosystem already exist. Therefore, the main challenge is to organise the ecosystem.
This work has received funding from Tekes (the Finnish Funding Agency for Innovation; diary ID 2081/31/2010) as well as the Academy of Finland (grant 310098). Furthermore, it has been greatly contributed to by discussions with various partners in the Finnish process industry. The authors would like to express their sincere gratitude.
- Agostinho, C., Ducq, Y., Zacharewicz, G., Sarraipa, J., Lampathaki, F., Poler, R., Jardim-Goncalves, R. (2016). Towards a sustainable interoperability in networked enterprise information systems: Trends of knowledge and model-driven technology. Computers in Industry, 79, 64–76. https://doi.org/10.1016/j.compind.2015.07.001.CrossRefGoogle Scholar
- Ajo, R., Hakonen, S., Harju, H., Järvi, J., Kaskes, K., Lenardic, E., Niukkanen, E., Nurminen, T., Ritala, P., Tolppanen, M., Tommila, T. (2001). Laatu automaatiossa, parhaat käytännöt. Suomen Automaatioseura ry (Finnish Society of Automation).Google Scholar
- Bartholomew, D. (1997). Clinging to EDI. Industry Week, 246(12), 44–47.Google Scholar
- Becker, M.B. (2012). Interoperability case study: Electronic data interchange (EDI). Technical report, Berkman Center Research Publication.Google Scholar
- CFIHOS. (2018). CFIHOS (Capital Facilities Information HandOver Specification) for process industries. http://uspi-global.org/index.php/projects/frameworks-methodologies/136-cfihos (accessed 5 Jul 2018).
- Collaborative Manufacturing Management Strategies. (2002). Technical report, ARC Advisory Group.Google Scholar
- Conway, M.E. (1968). How do committees invent. Datamation, 14(4), 28–31.Google Scholar
- DBE Core. (2018). https://dbecore.com/ (accessed 5 Jul 2018).
- eClass. (2013). https://www.eclass.eu (accessed 23 May 2017).
- Elvesæter, B., Hahn, A., Berre, A.J., Neple, T. (2006). Towards an Interoperability Framework for Model-Driven Development of Software Systems, Springer London, London. https://doi.org/10.1007/1-84628-152-0_36.
- European e-invoicing service providers. (2016). European e-invoicing service providers report a significant growth of 27% and over 1 1/4 billion processed e-invoices in 2015. http://eespa.eu/european-einvoicing-service-providers-report-a-significant-growth-of-27-andover-1-1-%C2%BC-billion-processed-e-invoices-in-2015/ (accessed 20 Apr 2017).
- Evans, D.S., & Schmalensee, R. (2016). Matchmakers: The New Economics of Multisided Platforms. Harvard: Harvard Business Review Press.Google Scholar
- Final Report of the Expert Group on e-Invoicing. (2009). Final report of the expert group on e-invoicing. Tech. rep., European Commission, Directorate-General for Internal Market and Services and Directorate-General for Enterprise and Industry, https://joinup.ec.europa.eu/community/epractice/document/eu-final-report-expert-group-e-invoicing.
- GS1 US. (2017). http://resources.gs1us.org/ (accessed 20 Apr 2017).
- Hästbacka, D., Barna, L., Karaila, M., Liang, Y., Tuominen, P., Kuikka, S. (2014). Device status information service architecture for condition monitoring using OPC UA. In Proceedings of the 2014 IEEE Emerging Technology and Factory Automation (ETFA) (pp. 1–7). https://doi.org/10.1109/ETFA.2014.7005141.
- Hästbacka, D., Jantunen, E., Karaila, M., Barna, L. (2016). Service-based condition monitoring for cloud-enabled maintenance operations. In IECON 2016 - 42nd Annual Conference of the IEEE Industrial Electronics Society (pp 5289–5295). https://doi.org/10.1109/IECON.2016.7793470.
- IEC 61360-4. (2005). Standard data element types with associated classification scheme for electric components - part 4: IEC reference collection of standard data element types and component classes. Geneva: Standard International Electrotechnical Commission.Google Scholar
- IEC 61987-10. (2009). Industrial-process measurement and control — data structures and elements in process equipment catalogues — part 10: Lists of properties (LOPs) for industrial-process measurement and control for electronic data exchange — fundamentals. Geneva: Standard International Electrotechnical Commission.Google Scholar
- IEC 61987-21. (2015). Industrial-process measurement and control - data structures and elements in process equipment catalogues - part 21: List of properties (LOP) of automated valves for electronic data exchange - generic structures. Geneva: Standard International Electrotechnical Commission.Google Scholar
- IEC 62264. (2013). Enterprise-control system integration. Geneva: Standard International Electrotechnical Commission.Google Scholar
- IEC 62541. (2015). OPC UNified Architecture. Geneva: Standard, International Electrotechnical Commission.Google Scholar
- IEC 62890. (2016). Life-cycle management for systems and products used in industrial-process measurement, control and automation (committee draft). Geneva: Standard International Electrotechnical Commission.Google Scholar
- IEC 61987 CDD. (2017). IEC 61987 - SC 65E/WG 2 - common data dictionary (CDD - V2.0014.0016). http://cdd.iec.ch/cdd/iec61987/iec61987.nsf (accessed 23 May 2017).
- Industrie 4.0. (2017). Industrie 4.0. Innovationen für die Produktion von morgen. Technical report, Bundesministerium für Bildung und Forschung.Google Scholar
- ISO/TS 20625. (2002). Electronic data interchange for administration, commerce and transport (EDIFACT) – rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) implementation guidelines. Geneva: Standard International Organization for Standardization.Google Scholar
- ISO 15926-1. (2004). Industrial automation systems and integration – integration of life-cycle data for process plants including oil and gas production facilities – part 1: Overview and fundamental principles. Geneva: Standard International Organization for Standardization.Google Scholar
- ISO 15926-4. (2007). http://rds.posccaesar.org/2008/05/XML/ISO-15926-4_2007 (accessed 23 May 2017).
- ISO/IEC 19845. (2015). Information technology – universal business language version 2.1 (UBL v2.1). Geneva: Standard International Organization for Standardization.Google Scholar
- Korpela, K. (2014). Value of information logistics integration in digital business ecosystem. PhD thesis, Lappeenranta University of Technology.Google Scholar
- MIMOSA OSA-EAI. (2014). http://www.mimosa.org/mimosa-osa-eai (accessed 20 Apr 2017).
- Nachira, F., Nicolai, A., Dini, P., Le louarn, M., Rivera Leon, L. (Eds.). (2007). Digital Business Ecosystems. Brussels: European Commission.Google Scholar
- Open Applications Group. (2016). http://www.oagi.org (accessed 13 Dec 2016).
- Paljakka, M., Söderman, J., Karaila, M., Syrjänen, T., Uusitalo, M., Heikkilä, H. (2009). SEFRAM service framework for process industry information exchange. In Automaatio XVIII Seminar, Helsinki, march 17-18.Google Scholar
- Snitkin, S., Mick, B., Novak, R. (2010). Asset information management: Part I — the case for building an AIM strategy. Technical report, ARC Advisory Group.Google Scholar
- Tchoffa, D., Figay, N., Ghodous, P., Exposito, E., Kermad, L., Vosgien, T., Mhamedi, A.E. (2016). Digital factory system for dynamic manufacturing network supporting networked collaborative product development. Data & Knowledge Engineering, 105, 130–154. https://doi.org/10.1016/j.datak.2016.02.004.CrossRefGoogle Scholar
- Wickramasinghe, G., & Perera, A. (2016). Effect of total productive maintenance practices on manufacturing performance: Investigation of textile and apparel manufacturing firms. Journal of Manufacturing Technology Management, 27(5), 713–729. https://doi.org/10.1108/JMTM-09-2015-0074.CrossRefGoogle Scholar
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.