A Conceptual Architecture for Enabling Future Self-Adaptive ServiceSystems

Fabian BurzlaffUniversity of Mannheim

burzlaff@es.uni-mannheim.de

Christian BarteltUniversity of Mannheim

bartelt@es.uni-mannheim.de

Abstract

Dynamic integration methods for unknown datasources and services at system design time are currentlyprimarily driven by technological standards. Hence,little emphasis is being placed on integration methods.However, the combination of heterogeneous datasources and services offered by devices across domainsis hard to standardize. In this paper, we will shed lighton the interplay of self-adaptive system architecturesas well as bottom-up, incremental integration methodsrelying on formal knowledge bases. An incrementalintegration method has direct influences on both thesystem architecture itself and the way these systems areengineered and operated during design and runtime.Our findings are evaluated in the context of a case studythat uses an adapted bus architecture including two toolprototypes. In addition, we illustrate conceptually howcontrol loops such as MAPE-K can be enriched withmachine-readable integration knowledge.

1. Introduction

Currently more and more companies are makingtheir domain-specific data available for third-partyusage. Well-known examples are projects like BIGIoT, FIWARE or Industrial Data Space . For example,FIWARE aims at establishing an open data platformin the context of Smart City applications whereasthe Industrial Data Space project is closely relatedto business models that are built upon Industry 4.0data sources. In general, such platforms integratedifferent data sources and interfaces by connectingservice providers with requesters by using somesort of adapter. For example, necessary semantictranslations between the system data model as wellas the IoT-device data model are codified withinthese adapters. Unfortunately, this use-case specificintegration knowledge is trapped as it cannot be queriedin a structured way. Consequently, when an IoT-devicewith similar functionality should be integrated with

other platform services, integration knowledge cannotbe reused automatically.

Current integration approaches utilized at designtime are primarily driven by technologies and donot address this problem efficiently [1]. Thesetechnologies are often crafted for supporting certaindomain standards. However, such standards are mostlythe results of tedious and slow voting process. Hence,they are out-of-date as soon as they are available asnew devices and data sources enter the IoT marketalmost daily in a decentralized manner. This means,that such standards are never complete as a basis for fullautomation even though, by definition, they should be.

Self-adaptive systems are predestined to work withinsuch dynamic and undetermined context as they doinclude rules and mechanisms for reacting to contextchanges. However, they mostly rely on the assumptionthat once all adaptation rules are formalized, the systemcan perform all necessary adaptations autonomously.It is hard to believe that a system designer cananticipate all possible states an IoT-System can enterand hence provide a consistent view of all possibleintegration rules. Nevertheless, a machine-readabledescription of data and service semantics is fundamentalfor realizing automated device integration and servicecomposition scenarios. Our contribution in this workis a conceptual architecture for future self-adaptive bussystems that allows for an evolutionary definition ofdevice integration rules. Consequently, we also providean integration approach that handles incomplete contextknowledge for self-adaptive system architectures. Toshow the technical feasibility of our approach, weintroduce tool support for formalizing integrationknowledge in an incremental way.

1.1. Motivating Example

In order to motivate the challenge of semanticambiguity of data and services within the IoT domain,we will use an example from the field of homonyms.Consider the verb close. Depending on the context,

Proceedings of the 52nd Hawaii International Conference on System Sciences | 2019

URI: https://hdl.handle.net/10125/60184ISBN: 978-0-9981331-2-6(CC BY-NC-ND 4.0)

Page 7472

this term stands for physically moving so that anopening is closed or to make a gap smaller. Forexample, a mobile robot approaching a door mayexpose the service close(Object object). Without theimplicit integration knowledge of a system integrator,the adequate semantic assignment for this concreteuse-case is undecidable for an automatic service matcherwithout context knowledge.

An application developer also faces other challengesamong homonyms when figuring out the meaning of aservice regarding request parameters, response elementsas well as their types when integrating an API into anoverall workflow (see Figure 1).

Figure 1. IoT-Interface Example

In case no machine-readable semantic standard forsuch drill exists, a system integrator must either consultan informal standard (e.g. ISO 16100 for IndustrialAutomation Systems and Integration ) or simulate thedrill to assign an unambiguous semantic label to thenecessary model elements. Once a crisp semantic isestablished, an adapter could be programmed to mapthe device model element to the bus data model ina meaningful way. However, the mental mappingsresiding in the system integrators head are only storedinside imperative code structures, which in turn arehard to query. Hence, as soon as a similar interfacehas to be integrated in the future, all work mustbe repeated without any possibility to reuse alreadyavailable integration knowledge from within adapters.

1.2. Problem statement and Paper Outline

Current approaches for formalizing adaptationscenarios in self-adaptive systems follow the idea of arevolutionary adaptation plan. If a condition holds, thena plan is executed [2]. However, for such a scenarioto work a complete and shared knowledge base mustbe defined upfront. In this work we will shed light onincorporating a shared knowledge base that allows foran evolutionary formalization approach. Furthermore,we will provide first technical insights on how todeal with incomplete instead of complete integrationknowledge in an automated way. To do so, our leadingresearch questions is:

RQ: How can system integrators be enabled toformalize semantic knowledge within self-adaptiveservice systems and which challenges are still unsolvedtowards using this knowledge?

The objective of this paper is to conceptually aligna novel integration method called Knowledge-drivenArchitecture Composition and self-adaptive servicesystems. The key results of this work are the following:First, to present all additional architectural elementsneeded and to discuss conceptually emerging upstream-as well as downstream consequences. Second, todemonstrate necessary tools and technologies thatcan be used to overcome ambiguous data elementsand semantic shifts for IoT interfaces when usingknowledge-driven architecture composition. Third andlast, to demonstrate the potential of the introducedmethod within a simple case-study.

Our paper is structured in the following way:Chapter 2 gives a short overview of an incremental,use-case based integration method and its delaminationto existing work. Chapter 3 represents our maincontribution: A conceptual architecture as well as anadequate tool support for capturing semantic integrationknowledge as a new component for self-adaptivesystems. Furthermore, an example is used to exemplifyour method as well as its potential benefits for controlloops. Chapter 4 answers the second part of our researchquestion by outlining challenges faced during the casestudy. Finally, chapter 5 concludes our work.

2. Knowledge-driven ArchitectureComposition and Service IntegrationMethods

Currently, several actors within the IoT market comeup with new models for describing, managing andacting upon IoT devices [3]. However, such standardsseldomly formalize the semantics in a machine-readableway. Among other factors, the applicability ofnegotiated standards is influenced by their claim to becomplete. Hence, as soon as a new standard mustbe supported, manufacturers are forced to support itin a revolutionary big-bang approach (e.g. OPC UA). Current formal scientific solutions are also drivenby the goal of being formulate for all possible usecases in a complete manner. For example, SOAP-baseddescriptions in bus systems must be created for everypossible use case that may occur during runtime.Hence, the formalization effort for practitioners tendsto be too high as the effort for describing eachintegration case usually does not pay off. Although such

Page 7473

approaches facilitate automated component couplingscenarios, practitioners currently rely on implementingpoint-to-point adapters. Consequently, current top-downintegration approaches (i.e. standards) are not applicablewithin the dynamic and decentralized IoT market as newdevices with new functionality enter the market almostdaily.

Figure 2. KDAC Principles Illustrated

To tackle this problem, we introduced a novelintegration method called Knowledge-drivenArchitecture Composition (KDAC) that relies onan incremental semantic formalization process. Thismethod explicitly allows for incompleteness ofintegration knowledge and supports an evolutionaryinstead of a revolutionary definition (i.e. big-bangformalization) of integration cases (see Figure 2). Byusing declarative languages based on first-order logic(e.g. OWL-DL), the inherited problem of partiallyincomplete integration knowledge can be tackled. Therationale for this is the usage of reasoning principlesfrom the field of ontologies.

For example, due to the transitive characteristics ofconverting temperature units, a reasoner could infer newintegration knowledge. So, if the integration knowledgebase contains the mathematical conversion formulasfrom Celsius to Fahrenheit and from Fahrenheit toKelvin, a logic-based reasoner can directly infer theconversion function from Celsius to Kelvin. Based onthe underlying principle such inference procedures andthe reuse of machine-readable integration knowledgefrom previous integration cases can facilitate automatedcomponent composition (e.g. plug-and-play principle).Automated component coupling is achievable as soon asall functional service and data characteristics are presentand/or can be deduced.

In other words, one can think of the reasoningprocess over integration knowledge bases as playing

the game Sudoku: As soon as enough integrationknowledge for an unknown and new integration caseis present, the missing information can be calculatedbased on rigorous mathematical rules.

The novelty of this approach is formalizing semanticintegration knowledge per use-case in a bottom-upmanner. By focusing on integration knowledge insteadof conforming to technological-oriented interfacedescriptions, it maximizes the effort for formalizing thesemantic coupling process as a concrete use-case mustbe present. Hence, formalization does only take place ifthere is a specific need for it.

In previous work [4], it was shown that this approachis feasible and could reduce the integration time in thecontext of the Industrial Internet of Things from 90 to20 minutes. Furthermore, the evaluation shows thatreusability of semantic mappings between endpoints issignificantly higher than adapting imperative softwareadapters. The resulting knowledge base is a promisingsource for self-adaptive control loops.

2.1. Impacts of KDAC on Self-AdaptiveService Systems

The IoT system integration market is expectedto increase from 17.0 billion US$ (2017) to 35.7billion US$ (2020). One central driver for thisare services and applications realized by IoT-devices.Hence, self-adaptive service systems are a promisingway for applying a novel integration method forsupporting system integrators as they already offermechanisms for dealing with context uncertainty atdifferent complexity levels. When integrating softwarecomponents in a semantical way based on partiallyincomplete integration knowledge, there are severalupstream (i.e. system integrator viewpoint looking fromtechnical integration layer) and downstream effects (i.e.user goals and need looking from data and servicerequest layer) from an architectural perspective (seeFigure 3):

• An upstream effect is the reusability of integrationknowledge for new IoT device. In case eachIoT device has a unique resource identifier (URI)attached, the respective device type can bematched against the integration knowledge baseand already existing composition knowledge fromprevious cases can be automatically generated.However, there must be a possibility to tellthe system integrator which mapping elementsbetween IoT device model and system model aremissing. Nevertheless, as integration knowledgeis only formalized if a use-case is present these

Page 7474

Figure 3. Conceptual System Architecture for a self-adaptive Service System supporting KDAC

<condition, event> combinations can be reusedfor the definition of more complex adaptationplans. In addition, they must not be made up byadaptation plan designers at design time out ofthin air.

• A downstream effect when formalizingintegration knowledge in an incremental wayis the enrichment of the knowledge base thatcan be consulted by algorithms that implementthe MAPE-K loop. Here the KDAC approachcan be seen as a moderator that sets the stagefor compositions approaches. Hence, basiccommunication semantics must not be definedin a revolutionary way and can be utilized bycomposition algorithms. Subsequently, this alsomeans that in the beginning a human must bepresent. However, following the assumption thatIoT integration cases are similar across multiplesites, an empty knowledge base may initial befilled with generic integration knowledge. This isillustrated as three global boxes in Figure 2.

• Another downstream effect is the way usergoals are evaluated. In an evolutionarydesigned self-adaptive IoT System that realizesuser goals by using data and services offeredby decentralized IoT components, it wouldtheoretically be feasible to locate missing devices.For example, a user-specific goal realizable by asystem residing on one site may be not realizableby a system at another site. However, as

the shared integration knowledge-base containssemantic integration knowledge and does notdepend on a concrete interface syntax, new IoTdevices and/or data sources can be integratedon demand. Now the aforementioned upstreameffect of formalizing data and service modelscan support a plug-and-play-like componentintegration mechanism. Hence, new user-specificgoals can be realized efficiently without alteringthe overall adaptation logic or even stopping thesystem.

As a result, this discussion shows that theunique characteristics of incomplete case-bases andan evolutionary instead of a revolutionary approachfor formalizing basic composition rules influences thearchitecture of self-adaptive systems. Despite thisobservation, user centric self-adaptation plans in suchsystems require a lot of distinct integrations cases toenable IoT ensembles to fulfill a desired user need inan automated way.

3. Integrating an EvolutionaryMaintained Knowledge Base into a BusArchitecture

A central problem for applying knowledge-drivenarchitecture composition to self-adaptive systems isto capture semantic integration knowledge. Hence, anecessary step is the development of adequate tools andtechnologies. A major problem to resolve ambiguous

Page 7475

Figure 4. Integration Knowledge Base for trigger-request pattern

data and interface declaration is the formalization ofthe needed case-specific integration knowledge in anexplicit way. To minimize the formalization effort, weexplicitly allow for a domain-specific schema. Hence,based on our preliminary results gained from simpleclient-server architectures [4] the upcoming sectionsfocus on demonstrating the basic tools needed forapplying knowledge-driven architecture compositionwithin self-adaptive system.

As hardware as well as technically standardizedsoftware gets cheaper (e.g. embedded operatingsystems), system integration can be seen as thefuture bottleneck for delivering IoT-Services tousers seamlessly. Ideally, devices can be exchangedin self-adaptive IoT-systems (e.g. DeltaIoT [5])seamlessly. However, integrating a new IoT-Deviceis currently not only linked to a significant manualintegration effort but also relies on shared knowledgebases for control loops.

In the context of self-adaptive systems, one of themost commonly used architectural paradigms are eventbuses. For this architectural style, one can locatetechnical service integration issues at the followingabstract layers [6]:

– Technical Layer: On this layer, it must beensured that at least one communication protocolis supported at the network layer from the bus aswell as the device that should be attached to it

– Syntactic Layer: On this layer, all data andservices must be normalized in a sense thatthey conform to the overall bus schemata.Furthermore, configuration services may alreadyprovide different predefined configuration tactics

– Semantic Layer: On this layer, the relations of

different services and their interaction style aredefined

Based on the assumption that future serviceproviders are conforming to some syntactical domainstandards (e.g. OPC UA for industrial devices), onecentral challenge is the automation of device integrationbased on heterogenous service and data semantics.A conceptual self-adaptive bus system architecturethat supports automated component composition isillustrated in Figure 3. The central architecturalelements needed are sorted according to different layers:

• On the Technical Integration Layer, the concreteinterfaces of devices are connected on the basisof their communication protocol with the buscommunication channels (e.g. REST or HTTPfor Web Services and SQL or MQTT for datasources)

• On the Virtual Data Management Layer, thedifferent local data schemes from various datasources are integrated

• On the Virtual Service Engineering Layer, twotypes of services reside: The first one is an atomicservice that can directly invoke a proprietaryservice running on a device. The second type ofservice is a complex service. This means, thatsuch a service can be composed of other existingservices or is subject to adaptation logic to fulfilla user goal.

• On the Data and Service Requester Layer,services can be accessed by the platform user inorder to realize a certain need or a goal.

At the technical integration layer, additional formalinterface descriptions are plotted. Although suchsemantic service descriptions are not commonly usedin practice, they may still be present. If there exists

Page 7476

Figure 5. Mapping-Assistant for System Integrators

a symmetrical mapping between interface descriptionas well as the provided interface functionality, thensuch descriptions are an additional valuable informationsource for the presented KDAC approach [7]. Itwas shown that the usage of this integration methodcan improve the matching result for semantic servicematchers such as SAWSDL-MX [8] significantly.

Consequently, our main technological contributionwill be focusing on the technical integration layer andits upstream effects on the proposed architecture (i.e.IoT-Device integration). Downstream effects such asuser goal realization or service composition will not befocused for the remainder of this paper.

As a first prototypical evaluation, we will showcasethe impact of our method by outlining the integrationprocess for our motivating example within a simplecase study. Furthermore, we will illustrate howthe architectural elements Integration KnowledgeRepository and Mapping-Runtime can be utilized byother processes during the adaptation life cycle (c.f.Figure 2). In addition, we will outline how ourcentral theme of incomplete and evolutionary definedintegration knowledge can be exploited by control loops.

3.1. Case Study IoT-Device Integration

An IoT-device, such as a drill, typically offersways to access its information model and executedevice-specific functionality. Typically, for sensingpurposes values of information model elements such

as torque can be read (c.f. Figure 1). For executing anaction, at least one value must be written or one function(c.f. Service Layer in Figure 1) must be invoked.

In our use case, the following communicationscenarios serves as a basis. There exists a drill devicewith the information model plotted in Figure 1. An ironrod is placed on the working area and the drill startsdrilling a hole inside the rod. After the drilling processis finished, a message with the specific parameters usedshould be sent to a Manufacturing Execution System(MES). In this case, information elements offered bythe drill can be accessed via OPC UA and the MESSystem offers a TCP/IP interface that can be fed withdomain-specific XML telegrams. An XML telegramincluding several device parameters should be sentto the MES as soon as the value of the trigger itempartProcessed is set by the drill device to true. Forimplementing the knowledge-base, we have chosen theOWL-DL language and used the HermiT 1.3 reasoneras a validation and reasoning engine. Hence, the IoTdevice provides a domain-specific functionality and theMES system requests a use-case specific informationchunk. Regarding the proposed integration approach,the following steps must be taken (c.f. Figure 2).

At t=0, a system integrator must define the sketchedintegration scenario within the knowledge base. Ifthe needed relationships are not defined within theontology, the system integrator must define them usingthe Mapping Assistant (see Figure 5). Here, a new

Page 7477

Figure 6. Overview Web App for Shopfloor Integration

<trigger, event> pair is defined as:

IF valueOf(trigger Item) OPERATOR trigger valueTHEN Event(requestItem [], responseItem [])

Next, the system integrator must translate eachneeded information model element within the use-caseinto individuals of the type triggerItem, requestItemand responseItem (see Figure 4): In our example, itis sufficient to transfer the information model elementspartProcessed:triggerItem and diameter:requestItem aswell as distance:requestItem as individuals.

At t=1, the use-case should be extended by alsosending the requestItem torque within the event to theMES systems. However, the domain-specific MEStelegram defines the torque as speed. Hence, the systemintegrator defines speed as an equivalent class of torqueand reuses the existing integration knowledge.

At t=n, already integrated interfaces for thecommunication style trigger-event can be automaticallyreused by matching the device specific type IDs as wellas their information and service model elements with asyntactical matcher.

When discussing our Mapping-Assistant withdomain experts from our research project, it quicklyappeared that the introduced tool may still be toocomplex for integrating a new device intuitively.Hence, we designed an additional input applicationfor formalizing integration knowledge. Here, weused a progressive web application framework (i.e.IONIC) that only allows to add individuals to anexisting ontology without allowing for adding newstructural elements (see Figure 6). A benefit of sucha progressive web-application is that it can be easilycompiled to native-code for all known mobile devices(e.g. running on a tablet or a laptop). Hence, during

Figure 7. Message sent over Bus

the integration iterations within the KDAC process thistool can also be used to perform some integration workat the Shopfloor incrementally without changing anycode. Practically, this means that the system integratorcan deploy changes to the Integration KnowledgeRepository. After all files are updated in this repository,the Mapping-Runtime parses the OWL-File andprovides the formalized integration knowledge duringruntime for other interested architectural components.To conclude our use-case, the message being sent tothe MES after all request values have been retrieved orderived is illustrated in Figure 7.

Please note that the proposed integration processmust be performed in addition to connecting the serviceson a technical and syntactical level (i.e. implementingan adapter). Please notice further, that the bus useddoes not provide any means neither for integrating newIoT services automatically nor the possibility to searchfor manually defined integration knowledge. This isalso due to the fact that the ontology schema is highlydriven by the use-case and not driven by any community

Page 7478

standard. A rational for doing so is the intuitiveapplicability of logic-based languages within the IoTdomain.

3.2. Related Work

Future self-adaptive systems must deal withadaptation strategies in decentralized settings and withunanticipated changes. Here, the Internet-of-Thingsserves as a new application opportunity for this systemclass. However, dealing with unanticipated changeswithin such system combinations is still a challengeyet to be solved. Therefore, we position the proposedmethod as a necessary pre-stage to enrich self-adaptivesystems with knowledge.

Other research communities have already producedvaluable solutions for interface matching, automatedintegration technologies and adaptation mechanisms [9].As we cannot provide a concluding literature overview,we will focus on sketching possible solutions for ourmotivating IoT-Interface example (c.f. Figure 1) fromdifferent research perspectives.

The MAPE-K control loop can be regarded asthe state-of-the-art for performing adaptation plans.From an engineering perspective, there must be ahuman-in-the-loop to create and maintain suitablemodels [2]. Here, the proposed method can help toformalize atomic ¡condition, event¿ pairs already duringdevice integration which then can be used to enrichshared knowledge bases utilized by MAPE-K controlloops.

Within the knowledge engineering community,evolutionary extending knowledge-bases by usingincremental formalization techniques is not new [10].As early as in 1994, it was described that it ishard to transform informally described knowledge intomachine-readable knowledge. Here, the focus was totransform the former into the latter one. In our example,this would result in a tool where one can insert use-casespecific <condition, adaptation plans> with naturallanguage. However, their application case was not theintegration of IoT-devices.

IoT interfaces can conceptually be linked tocomponent-based software development [11]. Likephysical IoT devices, a software component doesprovide functionality realized by software and hardwarethrough an interface. Hence, syntactic matchingapproaches [12] can be used to determine whethera required interface matches a provided interface.Another approach would be to search for the specificadapters needed to bridge between two endpoints [13].Regarding our example, one can view the services and

information models as a search specification that canbe fed to a matching system. However, such systemsusually only provide a probabilistic result which mayresult in undesired effects for IoT actors in the physicalworld [12].

SOAP-based systems [14] and (semantic) webservice descriptions [8] do expose mechanism tocoupled services during runtime. These systems requireeach service to be defined in an additional interfacedescription file which is attached to each device.In our example, this would result in the definitionof additional interface descriptions (e.g. using theSAWSDL language ). However, such approachesneed a special runtime environment and also inherit ahigh formalization effort for IoT- device manufacturers.As argued earlier, IoT device manufacturers do nothave a clear incentive to do so. In the case ofWeb Services, annotating web services with tagswould be a minimalistic way of providing an interfacedescription unfortunately, such tags are only beneficialfor search engines optimized for humans and contain nounambiguous semantics.

Last, the software architecture community hasrecently come up with a reference architecture for fastself-commissioning of for industrial IoT-systems inprocess automation [15]. Although commissioningtimes could be reduced to a few seconds across vendorproducts, they rely on the assumption that all vendorsconform to standardized models such as PLCOpen onevery layer (c.f. Figure 1). However, this approach maybe feasible in the context of safety-critical systems suchas the AUTOSAR platform.

Overall, the dichotomy between machine-readableformalization effort and the potential benefit ofautomated integration and adaptation strategies forself-adaptive systems must be tackled. As a potentialsolution, we will now describe potential impacts ofusing our method for self-adaptive service systems inthe next section.

3.3. Perspectives on Self-Adaptive ServiceSystems

Nowadays, marketplaces for data and servicesalready exist for various domains [16]. By applying theKnowledge-driven Architecture Composition approachon self-adaptive systems conceptually, we took the firsttechnical step towards reusing integration knowledgewithin the IoT domain. As a key result, the overhangingincompleteness claim for formalizing integrationknowledge bases from bottom-up is technically feasiblefor self-adaptive service systems.

Page 7479

Another perspective on self-adaptive IoT systemsdeals with proprietary data and service semantics.Regarding the integration of new devices, most platformoperators require system integrators to conformwith predefined platform adapters (e.g. redlink orHub-of-all-Things ). Unfortunately, these adaptersdo not offer practical possibilities to document thesemantic relations between the proprietary serviceprovider and the service requester. This is due tothe circumstance that both, (sensor) data and (web)services only contain weak semantics (i.e. ambiguousand informal semantic descriptions). For example,IoT data typically resides on a low abstraction levelmeaning that the expressiveness of a single data pointitself is rather limited [9][17]. One central observationfrom our case study was that information models andservices offered by IoT-devices are highly interlinked.The assumption of stateless services, which does holdfor most web-services, does not hold in our use case.Hence, the state of an IoT-device may be changedby setting a value of a model element or by calling afunction. The former originates from embedded andthe latter one from software system design. Here, othersemantic relationships must be captured.

Shifting from a revolutionary way of definingadaptation rules towards an evolutionary way seemspromising for self-adaptive service systems. Amongother reasons, the decentralized development andavailability of IoT-devices also challenges the wayhow adaptation plans for control loops are formalized.Regarding the sketched knowledge-base, such atomic¡condition, event¿ rules can serve as a sound basis formore abstract adaptation scenarios.

Another central observation when applying theKDAC approach was that the SPARQL-query becamethe bottleneck for runtime adaptations. If a newstructural element or relationship is inserted into theOWL-DL ontology, which is not a subclass or aformula conversion, the queries will not return allindividuals. This is mainly because the reasoner cannotinfer all individuals at runtime. Here, the systemintegrator must adapt the SPARQL-Queries within theMapping-Assistant. This requires additional skills andmay result in code changes as new types are returned bythe query itself.

4. Next Steps and Future Challenges

Based on the presented architectural influenceson future self-adaptive IoT service systems by usingour incremental integration method, we are currentlyplanning future technical as well as conceptualimprovements towards enabling smart application

development in the context of Smart Cities. In thissection, we will elaborate on some of the next steps thatwe plan to take.

Challenge 1 is an extended empirical evaluationof our method within a self-adaptive service system.Therefore, we plan to extend the DAiSI platform[18] with the introduced architectural elements anddemonstrate that the KDAC approach efficiently helpsto build up a shared knowledge base without relyingon predefined integration standards. Another objectiveof this evaluation will be the usage of formalizedintegration knowledge to fulfill user goals dynamicallywith control loops.

Challenge 2 will be to fan out the human withinthe proposed integration method. Especially in thebeginning, the human must perform additional workother than implementing software adapters. Hence,as soon as enough integration cases are present, thehuman must again fan out of the process and automatedintegration should take over. It must be methodicallyensured that this turning point is reached as early aspossible.

Lastly, challenge 3 deals with the usability of ourmethod when integration knowledge is missing foran integration case. Here, a suitable recommendersystem must point out the integration mappingsneeded between decentralized developed ontologies andintegrated IoT-devices. However, there already existpromising approaches by the semantic web communitythat can be utilized in order to calculate (c.f. Sudokumetaphor) missing links between semantic modelsefficiently [19].

5. Conclusion

In this work we have introduced a conceptualself-adaptive system architecture for services and datasources in the context of the Internet-of-Things.Next, we discussed the applicability of anincremental integration method called knowledgedriven-architecture composition (KDAC). In particular,we showed that the KDAC method can be utilizedto fill knowledge-bases in an evolutionary instead ofrevolutionary way. The formally gathered integrationknowledge explicitly allows for incomplete integrationknowledge without loosing the ability to be automatedin the long run. Therefore, we introduced two toolsand exemplified the proposed integration approachin the context of a self-adaptive system and a casestudy. We conclude that self-adaptive service systemsare a promising candidate for further research. Amore elaborate empirical evaluation will potentially

Page 7480

prove that the KDAC approach can efficiently fillknowledge-bases utilized by feedback and controlalgorithms.

Acknowledgement

This work was supported by the BMVI projectxDataToGo (http://www.bmvi.de/goto?id=359354)under the support code 19F2048D.

References

[1] N. F. Noy, “Semantic Integration: A Survey ofOntology-based Approaches,” SIGMOD Rec., vol. 33,pp. 65–70, Dec. 2004.

[2] P. Arcaini, E. Riccobene, and P. Scandurra,“Modeling and Analyzing MAPE-K Feedback Loopsfor Self-adaptation,” in Proceedings of the 10thInternational Symposium on Software Engineering forAdaptive and Self-Managing Systems, SEAMS ’15,(Piscataway, NJ, USA), pp. 13–23, IEEE Press, 2015.

[3] A. Meddeb, “Internet of things standards: who standsout from the crowd?,” IEEE Communications Magazine,vol. 54, pp. 40–47, July 2016.

[4] F. Burzlaff and C. Bartelt, “I4.0-Device Integration:A Qualitative Analysis of Methods and TechnologiesUtilized by System Integrators: Implications forEnginering Future Industrial Internet of Things System,”in 2018 IEEE International Conference on SoftwareArchitecture Companion (ICSA-C), pp. 27–34, Apr.2018.

[5] M. U. Iftikhar, G. S. Ramachandran, P. Bollanse,D. Weyns, and D. Hughes, “DeltaIoT: A Self-adaptiveInternet of Things Exemplar,” in Proceedings of the12th International Symposium on Software Engineeringfor Adaptive and Self-Managing Systems, SEAMS ’17,(Piscataway, NJ, USA), pp. 76–82, IEEE Press, 2017.

[6] I. Crnkovic, S. Sentilles, A. Vulgarakis, and M. R. V.Chaudron, “A Classification Framework for SoftwareComponent Models,” IEEE Transactions on SoftwareEngineering, vol. 37, pp. 593–615, Sept. 2011.

[7] F. Burzlaff, C. Bartelt, and u. L. Adler, “Towardsautomating Service Matching for ManufacturingSystems: Exemplifying Knowledge-Driven ArchitectureComposition,” Procedia CIRP, vol. 72, pp. 707–713,Jan. 2018.

[8] M. Klusch, P. Kapahnke, and I. Zinnikus,“SAWSDL-MX2: A Machine-Learning Approachfor Integrating Semantic Web Service MatchmakingVariants,” in 2009 IEEE International Conference onWeb Services, pp. 335–342, July 2009.

[9] P. Anantharam, P. Barnaghi, and A. Sheth, “DataProcessing and Semantics for Advanced Internet ofThings (IoT) Applications: Modeling, Annotation,Integration, and Perception,” in Proceedings of the 3rdInternational Conference on Web Intelligence, Miningand Semantics, WIMS ’13, (New York, NY, USA),pp. 5:1–5:5, ACM, 2013.

[10] F. M. Shipman, III and R. McCall, “SupportingKnowledge-base Evolution with IncrementalFormalization,” in Proceedings of the SIGCHIConference on Human Factors in Computing Systems,CHI ’94, (New York, NY, USA), pp. 285–291, ACM,1994.

[11] T. Vale, I. Crnkovic, E. S. de Almeida, P. A.d. M. Silveira Neto, Y. C. Cavalcanti, and S. R.d. L. Meira, “Twenty-eight years of component-basedsoftware engineering,” Journal of Systems and Software,vol. 111, pp. 128–148, Jan. 2016.

[12] M. C. Platenius, Fuzzy matching of comprehensiveservice specifications. PhD thesis, Universittsbibliothek,Paderborn, 2016.

[13] W. Janjic, O. Hummel, and C. Atkinson,“Reuse-Oriented Code Recommendation Systems,”in Recommendation Systems in Software Engineering(M. P. Robillard, W. Maalej, R. J. Walker, andT. Zimmermann, eds.), pp. 359–386, Springer BerlinHeidelberg, 2014.

[14] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman,N. Mendelsohn, H. Nielsen, S. Thatte, and D. Winer,Simple object access protocol (SOAP) 1.1. Jan. 2000.

[15] H. Koziolek, A. Burger, and J. Doppelhamer,“Self-Commissioning Industrial IoT-Systems in ProcessAutomation: A Reference Architecture,” in 2018 IEEEInternational Conference on Software Architecture(ICSA), pp. 196–19609, Apr. 2018.

[16] F. Stahl, F. Schomm, L. Vomfell, and G. Vossen,“Marketplaces for digital data: Quo vadis?,” WorkingPaper 24, Working Papers, ERCIS - European ResearchCenter for Information Systems, 2015.

[17] H. Cai, B. Xu, L. Jiang, and A. V. Vasilakos, “IoT-BasedBig Data Storage Systems in Cloud Computing:Perspectives and Challenges,” IEEE Internet of ThingsJournal, vol. 4, pp. 75–87, Feb. 2017.

[18] H. Klus, A. Rausch, and D. Herrling, “DAiSIDynamicAdaptive System Infrastructure: Component Model andDecentralized Configuration Mechanism,” tech. rep.,IARIA, 2014.

[19] C. Meilicke, “Alignment Incoherence in OntologyMatching,” 2011.

Page 7481