Autonomous Runtime Consumer Interface Generation and Deployment for Service Interoperability

The new Industry 4.0 approach contributes to addressing evolving industrial requirements, which are continuously fueled by changing market demands. This situation leads to growing complexity and considerable increases in development and maintenance costs. A signiﬁcant portion of engineering time is dedicated to the integration and interconnection of heterogeneous components. The solution for interoperability issues and the reduction in the associated engineering time are thus key tasks for increasing productivity and eﬃciency. Therefore, this paper provides an engineering approach to create interoperability among heterogeneous systems in Service Oriented Architecture (SOA) based environments by means of generating an autonomous consumer interface code at runtime. This paper aims to present a novel interoperability solution. The proposed approach makes use of service interface descriptions to dynamically instantiate a new autonomously generated interface that solves service mismatches between a provider and a consumer. This paper includes the deﬁnition of the consumer interface generator system, as well as the beneﬁts and challenges associated with the autonomous generation and deployment of a consumer interface code at runtime. To illustrate the potential of this approach, a prototype of the system, which shows positive results, is implemented and tested.


Introduction
The development of new devices, technologies, and architectures has opened an emergent paradigm where the digital and physical worlds work together, leading to a new digitalization era. The German initiative, Industry 4.0 [1], has resulted in several new architecture proposals, of which RAMI 4.0 and the IIRA are major examples. The real-world implementation of these architectures is intended to be a combination of legacy technology, the Internet of Things (IoT) and cyber-physical systems (CPSs). Nevertheless, the rigidity and inflexibility of the current industry approach, the ISA-95 architecture [2], affect the evolution of the new industrial paradigm. The engineering costs and efforts associated with these tasks represent a major bottleneck in the migration to Industry 4.0 [3].
Driven by the additional processing capabilities that IoT and CPS devices offer and their increasing num-marily due to the increase in the required engineering effort and costs. Hence, the improvement of IoT and CPS interoperability has become an increasingly relevant research objective in recent decades and has motivated research within both academia and industry. This work aims to develop a solution aligned with the Industry 4.0 vision by means of reducing the engineering effort associated with interoperability issues. The proposed approach addresses the autonomous generation and deployment of a service consumer interface code at runtime.
Abdellatif et al. [8] analyzed the state of practice of industry migration. Some of the results extracted from the survey highlight the high maintenance costs associated with legacy systems and indicate the necessity to find solutions that reduce costs and help with migration to newer technologies. However, engineering and maintenance costs are not only a legacy system problem but also a common industrial problem. One of the topics presented in the Electronic Components and Systems Strategic Research Agenda [1] by the Artemis industrial association was the connectivity and interoperability of systems. Their analysis claimed that IoT interoperability, SoS integration technology, and engineering tools may reduce connectivity development costs by 80%, which is considered a game changer for the future of the industry.
A significant portion of engineering time is dedicated to the integration and interconnection of different components. A reduction in this time is thus a key task for increasing productivity and efficiency. Consequently, this paper seeks interoperability solutions while maintaining high levels of engineering simplicity to reduce design and runtime changes and thus reducing automation engineering costs. The major contributions of this article are as follows: 1 This paper provides a run-time engineering approach to create interoperability between heterogeneous systems in Service Oriented Architecture (SOA) based environments. 2 As to enable service translation and communication mismatches between the provider and the consumer, a generator system was proposed that uses service interface descriptions to autonomously generate a corresponding service consumer interface. 3 Requisites and challenges associated with the autonomous generation and deployment of the consumer interface code are outlined. 4 Finally, to prove the effectiveness of the theoretical approach, a prototype is implemented to illustrate the great potential of the proposed system. [1] https://artemis-ia.eu/documents-1.html The rest of the paper is organized as follows. Section 2 gives a brief overview of the related work. Section 3 introduces the consumer interface generation approach. The implementation and test of the proposed approach is presented in section 4. Section 5 defines the technical challenges. Finally, the conclusion and future work are presented in sections 6 and 7, respectively.

Related Work
This section presents the works, which concern code generation and the related interoperability issues, that are relevant to this paper, as well as a brief introduction on the main concepts of the Arrowhead framework, which is used to prove concept implementation.

Interoperability
Interoperability is a key element of SOA and facilitates seamless communication between services. As defined by Peter Wegner in 1996 [9], it is "the ability of two or more software components to cooperate despite differences in language, interface and execution platform". There is an actual demand for interoperation that remains an open issue, even in the more recent technological paradigms. A myriad interoperability types and classifications can be found in the literature. In [10], a summary of the most popular types of interoperability is presented based on the 64 types identified by Ford et al. [11]. Moreover, different taxonomies, such as the one introduced by Noura et al. [7], which refers to the interoperability in the IoT, or the one presented by Hatzivasilis et al. [12], are presented.
The large number of available taxonomies reflects the wide range of cases and levels where interoperability is required. Some of the types listed overlap or complement one another; to simplify the discourse, only the more representative cases for this work are selected based on the previously mentioned literature.
• Technical interoperability is a general term used to define the ability to exchange direct and satisfactory information or services. • Information interoperability is achieved when processes and systems are capable of effectively using information from services. • Technological/communication interoperability can be defined as seamless communication between systems despite differences in the communication protocols and transmission layers. • Syntactic interoperability can be defined as seamless communication between systems despite differences in data, interface, and encoding formats. • Semantic interoperability implies the common understanding of information models and ontologies for the used terms.
To improve the state of interoperability, several researchers have studied and leveraged numerous interoperability issues for specific domains and components. The work presented in this paper makes use of the SOA approach by generating service interfaces to increase the interoperability in heterogeneous SOA environments. SOA has been proposed to provide syntactic interoperability and interoperability across heterogeneous systems [7]. It is built on top of the network layer; hence, processed information and data are easily managed through services [13]. Web service technologies (WS* and REST web services) are defined to accomplish the SOA concept, including service sharing, reuse, and interoperability [14].
Nevertheless, an SOA is not the only possible approach to address interoperability. Some of the most common approaches for addressing communication interoperability issues are adaptor [15], gateway [16] [17] and middleware [18] solutions. These solutions are based on the mediator concept, where interoperability is achieved through the development of an intermediate tool. This approach has limitations in terms of scalability since interactions require specific connectors and limitations when new devices are added or updated. The open API was also introduced to assist developers and enable cross-platform interoperability [7]. Nevertheless, the proliferation of platform providers, and consequently APIs, increases complexity and interoperability issues.
Moreover, semantic web technologies, such as the resource description framework (RDF), SPARQL and Web Ontology Language (OWL), have been used to describe web resources. Semantic web technologies can be considered a major driver of interoperability within heterogeneous environments according to recent studies [19]. This innovative approach carries several challenges in the IoT context. These challenges were discussed by Ganzha et al. in [20] and include problems within individual research projects that are usually in the prototype stage and may be incomplete or even abandoned.
Although the extensive work presented in the literature helps to advance interoperability issues, there are still open research challenges to be solved. Some of the remaining open challenges remaining, according to Noura et al. [7], are as follows: (1) the use of specific domains, where most of the proposals focus on interoperability in a specific scenario rather than a more generic interoperability; (2) the lack of de facto standards for the different communication layers; (3) the customization of REST APIs and data models, which creates interoperability difficulties across platforms; (4) the dependency on underlying technologies and systems, where stakeholders should not have to adapt to major changes in their systems to achieve interoperability; and (5) the lack of automatic tests for interoperability solutions that demonstrate reliability to enterprises.
The interoperability problem addressed in this work is framed as technical interoperability, which includes communication, syntactic and semantic interoperability. The heterogeneity among systems precludes the consumption of services and information exchange. The aim of this work is to overcome this interoperability issue at the runtime level. The outlined challenges, such as the customization of APIs and data models, the dependency on underlying technologies, and the lack of tested solutions, are some of the interoperability issues that motivate this work.

Code Generation
Code generation is understood as the process of obtaining executable code automatically from a given input [21]. The inputs can vary depending on the code generator, and some of the most commonly used examples include design models such as UML, domainspecific languages (DSL) or graphic diagrams and charts.
Despite the technical improvements in recent decades, there are several remaining major software engineering issues, including interoperability issues and development and migration costs. To overcome these problems, several studies have focused on new approaches that promote automatic and semiautomatic code generation. The interoperability definition highlights the challenges and possibilities that arise with autonomous code generation. It is a challenging task to autonomously generate code that understands the desired behavior of the service and, when generated, works with other heterogeneous services as intended. The possibilities offered by autonomous code generation arise when communication patterns and abstract models are well defined and effectively detail the desired dependencies and communication patterns.
The generation mechanism depends on the specific domain and context. Many approaches have been proposed to fulfill specific demands. The following cases illustrate the research efforts made in each preeminent application domain.
• Model-driven software engineering (MDSE). The automatic generation of code based on models increases the advantages and productivity provided by MDSE. UML is used as a de facto standard for modeling software systems and has led to the development of tools to automatically generate code with UML as the input model [22]. Nevertheless, other models are also used for code generation.
Harrand et al. [23] presented a code generation framework based on their own modeling language: ThingML. The ThingML approach focuses on the customization of a proposed family of generators. Syriani et al. [24] classified existing techniques for template-based code generation (TBCG). TBCG is a popular technique in MDSE that produces code from templates (high-level specifications). • Neuroscience. Neuroscience presents results in terms of mathematical models, which are typically translated into code. Code generation is used in neuroscience as a novel approach to avoid computational problems in the translation between high-level descriptions and low-level code [25]. Some examples of code generation pipelines in this domain include Brian [26], GeNN [27], and NESTML [28]. • Embedded systems. Embedded systems aim to reduce energy consumption via more efficient code, and code generators are a useful tool for addressing this objective. For example, in [29], C code was generated with a parametric description of a quadratic program (QP) and produced a fast and reliable optimization of the QP solver. Another example is code generation in parallel programming [30]. • Natural language. Parsing natural languages and semantics implies the difficult task of mapping unstructured (or partially structured) inputs to well-formed executable outputs. The generation of a code based on natural language and semantic translation has generated some interest in the scientific community; works presented in [31] [32] [33] represent a sample of the efforts in the field. • SOA. In the SOA framework, specifically in REST, tool kits can be found that make use of code generation at design time to ease the writing load. Swagger, Apache CXF, and GSoap are some examples. Nevertheless, the use of these tools remains at compilation time. The generated outputs cannot be used directly at runtime without human intervention. State-of-the-art methods reflect the successful use of this approach in domains such as MDSE, neuroscience and parallel programming; however, the use of code generation at runtime remains incomplete and case-oriented. The use of service interface code generation at runtime is considered in this study; at present, this is an open research gap that is worth considering to find a generic interoperability solution. This work highlights the benefits and advantages of generating and deploying code at runtime in the context of SOA.

Arrowhead Framework
The Arrowhead framework is an SOA-based framework that aims to provide automation capabilities (scalability, security, real-time control and engineering simplicity) as well as enable industrial IoT and device interoperability at a service level [34]. The main objective of the Arrowhead framework is to enable interoperability among heterogeneous systems with existing protocols and standards and handle legacy systems. It supports the following SOA-based design principles: standardized service contracts, late binding, loose coupling, service abstraction and autonomy.
The main entity of Arrowhead is the local cloud; a local cloud [35] is the key concept used to designate the communication and computation environments capable of providing the core services for the development of automation tasks in a protected manner. Local clouds are composed of devices that contain systems that provide services. A minimal local cloud setting includes three mandatory core systems-service registry, authorization, and orchestration-and at least one application system. In addition to the mandatory core systems, there are other core systems, such as the Gatekeeper, DataManager, EventHandler, and Configuration systems, that provide extended functionalities. Mandatory core systems are very relevant to this work since the code generator communicates with and makes use of the local cloud core systems. The service registry provides service registration, the orchestrator provides service discovery, and the authorization system provides authentication, authorization, and accounting (AAA) security. This work can also be considered an extension of the work presented by Derhamy et al. [36] on the Arrowhead framework, which focused on the dynamic translation of application protocols. The approach introduced in the present paper extends the concept of dynamic service instances that are used for translation and creates a new dynamic interface instance that addresses not only the application protocol but also the service contract features.

Consumer Interface Generation
The most promising approach that provides convergence, decoupling services and virtualization of network resources is a service-oriented architecture (SOA) [37]. The use of SOA further opens the possibility to simplify the engineering and deployment of new functionalities and solutions at runtime. Implementation engineering of such service-based systems requires the creation of both a service producer and a service consumer code in a variety of IoT and CPS devices and their associated software systems. If this process is automated such that the service producer and consumer code could be autonomously generated and deployed in an efficient and secure way, considerable engineering efforts could be saved, thus supporting a faster transition to Industry 4.0 at a clearly reduced investment cost.
In SOA, the interaction among systems is performed via the consumption of services. The services are made available and managed through a service contract. A service contract specifies all the interactions between the service provider and the service consumer, including the service interface, the interface documents, service policies, the quality of service (QoS) and performance [38].
The heterogeneity of the current technological ecosystem leads to mismatches between the service contracts of the provider and the consumer. Such mismatches between the consumer and provider interfaces hinder the consumption of services. The proposed approach is based on the autonomous generation and deployment of a consumer code that matches the producer service contract. This situation enables producer and consumer interoperability engineering at runtime.

The Autonomous Generation Process
Code generation involves the automatic creation of executable code from a given input. Regarding the generation procedure presented in this work, the executable code can be understood as the service consumer interface, and the given input is the interface description.
Consumer interface generation is defined as the process of applying the service interface metadata to provide a consumer with a new interface capable of communicating with the orchestration system and consuming one or more services. This process relies on the description of the provider and the consumer interfaces as a main source of information. An accurate description of the interfaces and service metadata is necessary for code generation.
The consumer interface generation system and future experiments have been developed and defined within the Arrowhead framework [2] . The generator is characterized as a system belonging to a local cloud; therefore, it is capable of interacting with the mandatory core systems (the orchestrator, service registry and authorization systems) and other application systems.
The theoretical scenario, shown in Fig. 1, describes the interactions required during the generation process. This scenario is built on an Arrowhead local cloud. The interface generator system is a functional block of that cloud that is driven by the core systems and starts the generation of the new interface for the consumer. The generated interface is a service dynamic instance that is designed to be integrated with the previous consumer system and used as an adaptor between the provider and the consumer. The description of the service interface and the identification of the service mismatches are necessary for the generation of [2] https://www.arrowhead.eu/arrowheadframework/ the code. As first introduced in [6], the format selected for this scenario is a service contract description. The definition of this format is not a part of the scope of this paper. In Fig. 2, the generation process is illustrated in a sequence diagram. The process starts when the consumer sends an orchestration request to the orchestration system asking for a specific service. The request sent by the consumer is a regular orchestration request. From the consumer point of view, the orchestration process remains the same.
Unlike the usual orchestration process, the orchestrator can identify a mismatch between the interfaces that produces an interoperability problem between the consumer who wants to consume a service and the provider who provides the service. The identification of mismatches is performed through a compatibility analysis between the consumer and provider interfaces during runtime.
Once the compatibility between the systems is analyzed, if the descriptions of the interfaces are inconsistent or if the analysis reports contain a mismatch that cannot be addressed by the generator, an error message is sent back to the consumer. If the analysis results are positive, the orchestration system calls the consumer interface generator (C.I.G. in Fig. 2).
The consumer interface generator is responsible for reading the interface descriptions and generating the new interface.
The generation process is performed as follows: 1 The consumer interface generator asks the service contract registry for the interface descriptions of both the consumer and provider systems. The format used to describe the interfaces is a contract description language. 2 The service contract description is used to generate a suitable interface. The generation strategy is based on modular and flexible code generation. The code is compounded by Arrowheadspecific functions to communicate with the core systems and customize functions to interact with the provider and the current consumer interfaces. 3 Before the code is executed on the consumer device, the generator communicates with the authorization system, which establishes or updates the necessary authorization rules, authentication profiles, and privileges. 4 Finally, the generated code is injected and executed on the consumer device. In case the security measures running on the device make the execution of the code unfeasible, there is the possibility of running the code on the local cloud setup. This option is less recommended due to the potential scalability problems associated with it. Discussion on the specifics of the injection of the code is part of future work and is beyond the scope of this paper. To use the new interface, the orchestration system responds to the consumer at the new interface endpoint. The consumer uses the generated interface each time and consumes the service without starting the generation process again. The endpoint of the new interface is not public; it is only accessible and known by that consumer. Since the endpoint of the interface is not public, it cannot be considered a regular service, and the service instance generated is exclusively used as an internal link for the consumer to communicate with the provider.

Proof of Concept
The proposed approach to solving runtime interoperability issues by autonomously generated consumer interfaces was described from a theoretical point of view in the previous sections. In this section, the current implementation and high-level overview of the interface generator are provided to support the proposed model and generation strategy. The scenario for the implementation is the same as that described in section 3.

Interface Generator System
The consumer interface generator is a system that generates and dynamically instances the interface code and operates as an adaptor between the consumer and the provider. The input of the system is the service contract description of both the consumer and provider systems, which provides a description of the service contracts and their interfaces. The output of the system is an executable code formed by the methods required for communicating with the local cloud core systems and to consume the service from the provider. Internally, the system consists of four functional blocks and three complementary services, as shown in Fig. 3. The functional blocks are described below.
• Metadata interpreter. The first block is responsible for interpreting the interface description file of both systems and internally storing the information of the specified service or services for both requests and responses. This block is developed apart from the others to allow its substitution if the input interface description format changes. Information about the provider system and service is provided by the orchestration system. • Generation. The information acquired from the description of the interfaces is used by this block to autogenerate the code to consume the service from the provider and the transformations necessary to be understood by the consumer. The output of this block is a functional Java code. • Conformation. Once the code is generated, the conformation block is in charge of communicating with the other core systems to update the security and other functional information necessary for the new interface configuration. • Injection. The last block of the process builds the code into an executable and injects or executes it depending on the specific case. This block requires data on the hardware constraints and specifications to determine the best option for a specific device and scenario. Following the SOA structure on which the Arrowhead framework is built, communication between the system and the core systems occurs via services. To accomplish the generation process, the interface generator provides one service (GenerateInterface) and consumes two services (GetInterfaceDescription and Se-curityConfiguration).
GenerateInterface The interface generator provides the service GenerateInterface. This service is the trig-ger for the generation of the code and is consumed by the orchestration system. The orchestration system posts a request to generate a specific interface; this request informs the service identifier of the requester consumer and the selected provider. This information is used by the generator to request the interface description of both systems for the delivered service.
GetInterfaceDescription To request the interface description, the interface generator consumes the service GetInterfaceDescription from the interface description database. The preliminary location of the interface description database is the system registry. The system sends a get request with the system name.
SecurityConfiguration The security configuration for the new interface is requested via the SecurityConfiguration service that the authorization system has to provide. This service is not yet defined in the current implementation, and it will be a part of future developments.

Implementation Details and Tests
A preliminary implementation was developed to validate the theoretical scenario and identify the challenges and limitations of the proposed approach.
The Arrowhead framework version 4.1.3 is used as a base framework for the scenario. The consumer interface generator is implemented with the Java Spring framework and is executed as a provider system in the local cloud. The generation of code is based on the opensource JavaPoet library. The generator system uses the description of the interfaces written in XML as an input and generates an executable jar file as an output that includes all the classes and dependencies required to create a functional consumer interface.
The implementation of this system is considered a work in progress; consequently, some of the protocols and standards are completely supported and others are in the process of integration. Table 1 summarizes the technical protocols and standards supported in the current implementation and future steps in the development. The execution of the newly generated code introduces a delay in the consumption of the services. To validate the potential of this approach, the delay introduced by the new interface, as well as other significant parameters such as memory size and generation time, was measured.
Two main scenarios were implemented and tested. In the first scenario (Fig. 4), the totality of the consumer is generated, including the functions to communicate with the orchestration system and the communication with the provider. The consumer system does not implement any business logic apart from printing out the provider response on the screen. The generated consumer replaces any previous consumer. In the second scenario (Fig. 5), only the interface required for communication between the consumer and the provider is generated. To compare the different scenarios, two processes were measured. The first measured time refers to the complete service consumption process, including orchestration and the consumer-provider interactions. This process starts with the orchestration request (t1 in both scenarios) and is finalized once the consumer has gathered the information from the provider (t3 in scenario 1 and t5 in scenario 2). The second process measured is exclusively the consumption of the service, without considering the previous orchestration process. The consumption of the service is defined as the time from when the service request is sent to the provider to when the response with the requested service information is received.
The time calculations for the processes in both scenarios are presented in Table II. The indexes refer to the timestamps of the black points marked in the sequence diagrams shown in Fig. 4 and Fig. 5. Table 2 Time calculations

Scenario 2
Complete process (Orchestration and service) S2 Tc = t 5 − t 1 Service consumption process S2 Ts = t 5 − t 2 Generated interface time added Tests were performed under the same device and network conditions for the same service to avoid differences in the measurements due to external factors.
The tests were carried out such that there were 200 iterations per scenario. The network used was a private WLAN network (WPA2-Personal 2.4 GHz). Finally, all tests utilized the same computer to obtain comparable results. The device utilized was a personal computer with an i7 core running Ubuntu 18.04.
The times are completely dependent on the service complexity and the characteristics of the device and network. To provide representative data, a hand-coded consumer was implemented based on the same interface description. The measurements taken by the hand-coded consumer are considered as reference values to evaluate the validity of the proposed approach. Table 3 presents the times for each scenario and the delays introduced relative to the hand-coded consumer. The sizes of the generated classes are 14 KB for the completed consumer and 6 KB for the generated interface. The total consumer size, including the dependencies and common classes, is 20 MB-the same size as that of a nongenerated system.
The test revealed differences in performance for both scenarios. The generation of the complete consumer results in a performance similar to that of the handcoded consumer-an unsurprising fact considering the strong similarity between the codes. Regarding the generation of the interface, the results show an increase in the time required to consume the service when the interface is generated, especially when comparing when the complete consumer is generated. Nevertheless, the magnitude of each measurement remains at dozens of milliseconds.
These results confirm that the use of the proposed approach does not diminish the performance of the proposed scenarios. In addition, the current engineering times dedicated to solving the interoperability issues by engineers and operators are always greater than those of the automated solution proposed. Despite familiarity with the framework, where a skilled developer would take minutes to hours to code a consumer interface, the test results show generation in less than a hundred milliseconds without human intervention for the same interface, as shown in Table 4. Future work will include tests to validate the accuracy and correctness of the generated code.

Discussion
The work presented in this paper provides a new approach to solve interoperability issues via the autonomous generation of service interfaces. In contrast to the SOA tools presented in section 2, the generator system works at runtime. This approach provides a new research direction with great potential for addressing interoperability in the frame of SOA. The following section defines the technical challenges and limitations regarding the proposed approach.

Service Interface Description
Information and data descriptions are key requirements for autonomous code generation. In the presented scenario, to generate autonomous consumer interfaces, complete and structured definitions of the provider and consumer interfaces are required. Application protocols, encoding, semantics, types, notations, security features, and the payload structure are some of the aspects that must be defined as part of the interface definition. The ability to model high-level aspects such as the context and QoS is also a relevant issue from an SoS point of view [39]. The lack of information and ambiguities in the descriptions can lead to critical errors or dysfunctional code.
The analysis of the available service interface definition models and characterization of the components necessary for the proposed system are parts of future research directions.

Security
Security has become a fundamental feature since the communication and interchange of services among different and possibly unknown systems are present. The security implications of the proposed methodology are significant and require a comprehensive analysis. The generation of a completely new interface by a third system, which is placed onto the consumer device and gains consumer privileges, involves severe security vulnerabilities and poses a security threat. These vulnerabilities must be prevented, detected and protected from an architectural and technical point of view.
A complete analysis of the security and secure deployment of the proposed consumer interface method will be defined in future work.

Reliability and Robustness
The autonomous generation of code always involves questions about the reliability and robustness of the generated output. It is imperative to design and implement mechanisms and tests to ensure the consistency and coherence of the final interface before its use. The addition of this step may signify a decrease in the speed and affect the final performance. Despite these drawbacks, the reliability of the service interfaces is considered critical and requires future investigation.

Business Logic Functions and Interface Separation
The dichotomy between the business logic and the service interfaces is denoted in many SOA manuals and sources [40] [41]. Nevertheless, the real implementation of SOA in industrial environments can differ from theory. The separation of the interface from the rest of the service functionality is a requirement for the creation of a new interface.

Hardware Constraints
The proposed strategy involves the generation and execution of code on a consumer device; hence, the technical hardware constraints of the consumer device will affect the performance of the final solution. The current implementation is targeted at devices with medium to high computational resources and memory. Resource-constrained devices require special treatment due to their low memory and computational power, which hinder code injection and execution.
In addition to the memory and computational power, other technical characteristics, such as the operating system, network communication or predefined dependencies, influence the execution of the code.

Quality of Service and Optimization
As a final step, aspects such as the QoS and the performance optimization must be taken into consideration. Tests and measurements must be completed to corroborate the timely performance of the system and its beneficial use as a solution to the interoperability issue.

Conclusion
Real-world industrial automation and digitalization systems coexist in ecosystems that involve a flexible set of stakeholders with diverse technology bases and include the implementation and use of systems based on SOA in conjunction with the IoT and CPS. However, new application requirements and changing market demands contribute to the growing complexity, which indicates a clear risk for considerable increases in development and maintenance costs. Interoperability stands as one of the major issues to be addressed to reduce integration and deployment time and costs.
The proposed approach utilizes code-generation techniques successfully used in other domains to autonomously generate and deploy consumer interface code. The runtime generation of consumer interfaces, proposed in this paper, is a novel approach to solving interoperability issues in SOA heterogeneous environments. This approach is a step forward in the total service contract translation and provides a generation and deployment mechanism to dynamically instantiate service interfaces.
The generation of service interface code is defined by focusing on six key characteristics: autonomy, runtime, security, timeframe, robustness and generality. The generation is implemented within the Arrowhead framework. The consumer interface generator is an Arrowhead system responsible for generation and deployment with the service interface description as an input. This work presents a theoretical definition of this system and the generation process in the Arrowhead framework.
The first implementation of the system is also presented. The time measurements performed are an indication of positive results and show the potential of this new approach. The validation and verification provided in this work serves as a strong indication that the architecture can be applied to other SOA-based frameworks and platforms.
The service interface description, security, reliability, and hardware constraints are some of the challenges that are highlighted and discussed as future directions that need to be addressed to fully obtain the benefits of the presented work. These benefits include a reduction in engineering efforts and an increase in interoperability.

Future Work
The work presented in this paper provides the foundational elements for consumer interface generation as a means to address runtime interoperability issues in heterogeneous SOA environments.
Future extensions of this work will focus on the complete implementation of the consumer interface generation system, including the support of several protocols and standards to provide a broad range of interoperability and the definition of the services and their implementation to accomplish the various interactions defined in the theoretical scenario presented in this paper. To complete the proposed generation strategy, the interface description must be analyzed and accurately defined. This fact highlights the importance of semantic descriptions and interoperability solutions between commercially available standards and ontologies.
Planned future investigations include overcoming the technical challenges defined in section V. Security requirements will be defined and included in future developments. Finally, the reliability and performance of the system will be further measured by tests and validated in industrial use cases. Tests concerning the amount of runnable code, as well as the accuracy and correctness of that code, will be performed to validate the final prototype.