Guide for Extensions

3 Testbed Provider Services (Testbed to FIESTA-IoT)

3.1 Configuration and Runtime Sequence example

The required steps and interactions between the Testbed provider and the different FIESTA-IoT components in order to set up and integrate a Testbed to the system is depicted in 1st Figure to 5th Figure below.

Where we can see the Testbed & Resource registration and the TPI configuration and runtime. For the Testbed setup we presume that the Testbed Provider has already generated the Data Semantic Annotator and initiated an instance of the Testbed Provider Interface for his/her Testbed.

For the Testbed Registration as depicted in 5th Figure:

  1. The first step is to open the Testbed Registration UI (preferably thru the FIESTA-IoT portal). If the Testbed Provider is not logged in yet the User credential will be requested to be entered.
  2. The credentials are forwarded to the Security component where a SSO token id is generated and send back to the container (browser) that the Testbed Registration UI is opened from.
  3. This SSO token id is then used from the Testbed Registration UI in order to retrieve from the security module information like the UserID, User role etc.
  4. With the user ID Testbed Registration UI is now contacting Testbed Registration Data Storage (TRR) in order to retrieve potentially other Testbeds info that have already been registered from the specific Testbed Provider (by UserID).
  5. The Testbed Provider now initiates the process of registering a new Testbed.
  6. An already annotated resource script has to be entered to the form in order to be validated.
  7. The resource script is send from the Testbed Registration UI to the Validator component and a report is generated with a success or no success message from it.
  8. The rest of the Testbed information are entered to the Testbed Registration UI form like the Testbed’ s TPS endpoints along with the API key (if it exists).
  9. By hitting the register button the information are stored both on the Testbed Registration data storage (TRR) and the Resource Registry data storage (IoT Registry) depending on the non-semantic or semantic nature of it.

An equivalent process for the Resource registration shall be followed and is depicted in 2nd Figure below:

  1. The first step is to open the Resource Registration UI (preferably thru the FIESTA-IoT portal). If the Testbed Provider is not logged in yet the User credential will be requested to be entered and the next two steps are the same as step 2 and 3 of the Testbed Registration Sequence above.
  2. With the user ID the Resource Registration UI is now contacting Testbed Registration Data Storage (TRR) in order to retrieve all the testbeds registered from the specific Testbed Provider (by UserID).
  3. The Testbed Provider can now choose the Testbed of interest from the presented list. If no testbed is registered yet then the Testbed registration process should be followed to register one.
  4. With the Testbed ID the Resource Registration UI is now contacting Testbed Registration Data Storage (TRR) in order to retrieve potentially other resource info that have already been registered for the specific Testbed.
  5. The Testbed Provider can now initiate the process of registering a new Resource.
  6. An already annotated resource script has to be entered to the form in order to be validated.
  7. The resource script is send from the Resource Registration UI to the Validator component and a report is generated with a success or no success message from it.
  8. The rest of the Resource information are entered to the Resource Registration UI form.

By hitting the register button the information are stored both on the Testbed Registration data storage (TRR) and the Resource Registry data storage (IoT Registry) depending on the non-semantic or semantic nature of it.

Now we can move to the TPI Configuration sequence shown in 3rd Figure below:

  1. The first step is to open the TPI Configuration UI (preferably thru the FIESTA-IoT portal). If the Testbed Provider is not logged in yet the User credential will be requested to be entered and the next two steps are the same as step 2 and 3 of the Testbed Registration Sequence above.
  2. With the user ID the Resource Registration UI is now contacting Testbed Registration Data Storage (TRR) in order to retrieve all the testbeds registered from the specific Testbed Provider (by UserID).
  3. The Testbed Provider can now choose the Testbed of interest from the presented list. If no testbed is registered yet then the Testbed registration process should be followed to register one.
  4. When the Testbed Provider picks a Testbed ID the TPI Configuration UI contacts the Resource Registry Data storage (IoT-Registry) in order to retrieve the list of registered resources for the specific testbed. If there are no registered resources the user should follow the Resource registration process to register some.
  5. The User can choose a list of resources to set up, identify an execution schedule and choose the TPS retrieval method (i.e. getObservation). Finally all these info can be sent to the DMS in order to start a scheduled job which is going to retrieve the annotated measurements from the TPS and forward them to the FIESTA-IoT platform (which is described below).

Finally, a runtime sequence of acquiring the annotated measurements and forwarding them to the FIESTA-IoT platform is depicted in 4th Figure below. In this example, we presume that the testbed TPS instance has been implemented and exposes the “getObservations” services, which provides the FIESTA-IoT annotated measurements of a given list of resources for a specific time period. 

  1. After successfully initiating a DMS scheduled job as described in the sequence diagram above the DMS scheduler enters a loop with the identified time period from the Testbed provider. In every loop the DMS sends a message to the identified Testbed TPS with a list of resource IDs and a timeperiod (from->to time) that the TPS needs to produce the annotated measurements.
  2. TPS replies back to DMS with an FIESTA-IoT annotated document with all the requested measurements.
  3. DMS collects this document and forwards it along with the annotation type to the Message Bus under a specific topic.
  4. In the meantime the Message Bus Dispatcher (MBD) has subscribed to the above topic so every time something is published to it the MBD gets informed and receives the message which was pushed to the Message Bus from the DMS.

 The collected annotated document is now pushed to the Validator and if the document is semantically and syntactically valid is forwarded to the Meta-Cloud Data storage (IoT-Registry) for storage.