INTER-METH -- Analysis Phase: How to analyze the integration of two heterogeneous platforms using INTER-METH for INTER-Health Pilot

(Getting Ready) Integration scenario description

  • The integration scenario to be addressed in this recipe is shown in the following figure in which two different IoT platforms needs to be integrated in the INTER-Health Pilot (see Deliverable D6.3). In particular, the analysis phase involves the requirements elicitation by the integrator/s aiming at integrating BodyCloud and UniversAAL platforms.

Figure 1. Overall integration scenario

Recipe ingredients

  • Documentation: INTER-METH methodology available here

  • SW: INTER-CASE tool (downloadable here)

Prerequisites

  • Apache Tomcat

  • MySQL DBMS

  • Bootstrap library

  • Xonomy library

  • Itextpdf library

  • log4j library

OR

Simply use our web-app instantiation of the INTER-CASE Tool available here

(How to Do it) Execution of the Analysis Workflow through INTER-CASE

  • Here we describe how to execute the analysis workflow through INTER-CASE:

The Integrator user first logs into the web-based INTER-CASE (see the official user guide here and starts a new Integration Project. A summary page, Project Status (see Figure below), shows an overview of the integration procedure. In this case, we just focus on the Analysis phase.

Figure 2: Project Status window.

As first step the Integrator should insert the basic info of the two platform: IoT Platforms box; thus obtaining what is reported in Figure 3. Each platform is characterized by name, type, ontology, and owner.

Figure 3: IoT Platforms basic info box.

In the Analysis phase, the Integrator user must execute the Analysis workflow reported in the INTER-METH documentation: https://inter-iot.readthedocs.io/projects/intermeth/en/latest/ (see Fig. 1.4).

Integration Goals can be defined before starting to execute the workflow or after platform analysis.

In the following figure, the integration goals are defined using the tool. Of course, integration goals are defined by the integrators according to the final integration goals they intend to achieve thus it is not an automatic process but a manual and human-driven task. The tool just provides support to report them.

Figure 4: Integration goals definition.

In the running example, three goals were defined by the Integrator:

  • IG1: Data generated from the two platforms have to be shared and transparently accessed from both platforms;

  • IG2: Common notion of the users registered to each platform;

  • IG3: Subscription support from one platform to the other to be notified upon the availability of new data of a given user.

In order to add new goals, the Integrator needs to select "Add an IG" and then edit the textfield with the integration goal definition.

Thus, the steps the Integrator has to execute, supported by the tool, are:

  1. IoT Platforms Analysis

  2. Integration Layers Identification

  3. INTER-GOM Production

IoT Platforms Analysis is carried out by the Integrator with reference to the INTER-IoT Reference Architecture (see here and reported in the Analyzed Platform Document box. The snapshots are reported in Figure 5.

Figure 5: IoT Platforms Analysis.

Integration Layers identification is performed by the Integrator and reported in the Category of Integration box as Figure 6 portrays.

Figure 6: Integration Layers Identification: Category of Integration.

Finally, the INTER-GOM model, containing functional and non-functional requirements, is produced by the Integrator and reported in the Goal Oriented Model box.

Figure 7: INTER-GOM Production: Goal Oriented Model.

(How it Works) Inspection of the XML INTER-CASE files

  • Here we describe how to inspect the XML files created into the previous step using the INTER-CASE tool:

The files can be extracted and easily saved to your local machine directly from the tool.

IoT Platforms

<System_Integration>
  <IoT_Platform Ontology="OpenIoT">
    <Name xml:space="preserve">UniversAAL</Name>
    <Type xml:space="preserve">Medical Platform</Type>
    <Owner xml:space="preserve">SABIEN</Owner>
  </IoT_Platform>
  <IoT_Platform Ontology="SSN">
    <Name xml:space="preserve">BodyCloud</Name>
    <Type xml:space="preserve">Cloud Medical Platform</Type>
    <Owner xml:space="preserve">UNICAL</Owner>
  </IoT_Platform>
</System_Integration>

Analyzed Platforms Document

<System_Integration>
  <IoT_Platform Ontology="OpenIoT">
    <Name xml:space="preserve">UniversAAL</Name>
    <Type xml:space="preserve">Medical Platform</Type>
    <Owner xml:space="preserve">SABIEN</Owner>
  </IoT_Platform>
  <IoT_Platform Ontology="SSN">
    <Name xml:space="preserve">BodyCloud</Name>
    <Type xml:space="preserve">Cloud Medical Platform</Type>
    <Owner xml:space="preserve">UNICAL</Owner>
  </IoT_Platform>
</System_Integration>

Integration Goal

<Integration_Goals>
  <IG id="1" xml:space="preserve">Data generated from the two platforms have to be shared and transparently accessed from both platforms.</IG>
  <IG id="2" xml:space="preserve">Common notion of the users registered to each platform</IG>
  <IG id="3" xml:space="preserve">Subscription support from one platform to the other to be notified upon the availability of new data of a given user</IG>
</Integration_Goals>

Category of Integration

<Category_of_Integration>
  <INTER-LAYER layer="MIDDLEWARE"/>
</Category_of_Integration>

Goal Oriented Model

<Integration_Point>
  <Category_of_Integration CoI="MIDDLEWARE"/>
  <Functional_Requirements>
    <FR id="1" xml:space="preserve">Common knowledge and sharing of users IDs</FR>
    <FR id="2" xml:space="preserve">Sintactical and semantic translation of messages (since BodyCloud uses JSON while UniversAAL is based on RDF)</FR>
    <FR id="3" xml:space="preserve">Subscription management to topics (e.g. messages generated from a given user)</FR>
    <FR id="176" xml:space="preserve">User Access Gateway for Patients.Gateway main functionalities for patients are:-Access to services (providing username and password).-Setting Profile communication and devices pairing.-Managing measures on the device and releasing them to the gateway which stores them on a local database.-Possibilities of inserting measures manually.-Sending measures to the platform.-Reporting locally measures already stored.-In term of interoperability, the INTER-Health gateway uses the gateway architectural scenarios described in the requirement 175.</FR>
    <FR id="218" xml:space="preserve">Personal data collected on Computerized Nutritional Folder during Experimental and Traditional Nutritional Counselling. The data of the recruited subjects, collected on electronic nutritional folder refer to: - Personal and identification data; - Anthropometric data (weight, height, BMI, waist circumference); -Food research (eating habits and physical activity) </FR>
    <FR id="106" xml:space="preserve">Definition of reference meaning for health information. Health information can be detected using different devices according to different way of measurement (unit of measure that could differ from country to country and also depending on devices manufacturers). To use same information coming from different systems and going to others, it is mandatory to establish specific criteria to: - Define a common meaning if it is possible. - Determine a correspondence between different data that have the same meaning and different values. - Set transcoding tables between different values of the same data.</FR>
  </Functional_Requirements>
  <NON_Functional_Requirements>
    <NFR id="71" xml:space="preserve">Application response time.The "navigation" functionalities on different contents by using both Smartphone or Personal Computer to access to the platform, have to guarantee a response time of a few seconds. </NFR>
    <NFR id="127" xml:space="preserve">Availability of sensor data.Health monitoring data must be viewable from a remote location to facilitate patient triage and inform decision making. </NFR>
    <NFR id="146" xml:space="preserve">Information sheet. Processing of personal data.The person tasked with processing must provide the information sheet, to the involved person or the person from whom you collect the data, in the manner determined by the data processor of the structure and using the forms, where prepared by the Company. During the health use case, the information sheet shows in a simple but detailed way: -Purpose of the study;-Detailed study protocol;-Advantages and the risks involved;-Any costs or compensation for subjects who choose to participate;-Voluntary participation;-Right of withdrawal at any time;-References of the person responsible of the project.</NFR>
    <NFR id="145" xml:space="preserve">Informed consent. Processing of personal dataThe informed consent must be: -freely express;-specifically performance;-must be known by the involved person, of legal age, not banned and able to understand or want. For different reasons of incapacity or inability, the privacy code has the legitimacy of one of the following subjects:--operator of the power, in the case of under-age or person prohibited or subject to support administration;--family, close relative or partner (all placed on the same level) for cases of physical impossibility or inability to understand or want the individual;--residually, the Data Processor of the institution where is the involved subject.</NFR>
    <NFR id="103" xml:space="preserve">User Authentication to access INTER-Health services. Users shall authenticate to the services using their username and password</NFR>
  </NON_Functional_Requirements>
</Integration_Point>