Type-sound Declarative Dynamic Object Reclassification Artefact

Type-sound Declarative Dynamic Reclassification Artefact Table of Contents Artifact setup Table of Contents 1. Deploy the system 2. Run the test script Inspecting the results of the Java tests 3. Use the system in a real environment API Fuseki triplestore InfluxDB Activemq Install the infrastructure 1. Deploy the system The system is designed to be run in docker containers. The first step is to install the system and its dependencies. The installation script will check for the required packages and install them if they are not already installed. To install the system, run the following command: python3 setup.py The python packages required for running the tests that have to be installed are. You can do so by installing the packages with pip or pip3: pip install -r requirements.txt or pip3 install -r requirements.txt The required packages are: requests influxdb-client Note that in some newer linux distributions, the operating system might prevent you to use pip directly in favour of apt install python3- to install the required packages. In that case, you either need to install the packages with the apt command, use a python virtual environment, or force pip install --break-system-packages (or pip3 if that is the one installed). If you want to install the packages with pip from the "requirements.txt" file, you can use the following command: python3 setup.py --pip Moreover, the setup checks for docker compose to be installed. The installation by default will use prebuilt docker images for x86 architecture. Therefore, for newer ARM-based architecture (e.g. newer MacBooks or Raspberry PIs), you need to pass the --arm argument python3 setup.py --arm Furthermore, if you want to build the images from scratch, you can use the --build option: python3 setup.py --build The system will then install the different containers defined in the compose.yml file and will prompt the user when the installation is complete. Note that in many Linux distributions, docker and docker-compose are to be run with sudo. If you are not running the script as root, you will need to prefix the command with sudo: sudo python3 setup.py [options] However, it's possible to add the current user to run docker compose without the need to sudo with sudo addgroup --system docker sudo adduser $USER docker newgrp docker sudo reboot now 2. Run the test script To run the test script, use the following command: python3 ecoop-artifact-test.py The script will run the tests and output the results to the console. The first set of tests are referred to the plants adaptation tests that are referred to Table 2 in the paper. Plant ID Moisture Expected State Actual State After Instantiation Plant 1 70.1 Overwatered Overwatered Plant 2 30.1 Thirsty Thirsty Plant 3 60.1 Moist Moist Plant 4 70.1 Thirsty Thirsty After First Reclassification Plant 1 40.1 Moist Moist Plant 2 10.1 Thirsty Thirsty Plant 3 90.1 Overwatered Overwatered Plant 4 60.1 Thirsty Thirsty After Second Reclassification Plant 1 95.1 Overwatered Overwatered Plant 2 50.1 Moist Moist Plant 3 20.1 Thirsty Thirsty Plant 4 85.1 Moist Moist The plants further adapt the health states based on the NDVI values as shown below an in Table 3 in the paper. Plant ID NDVI Expected State Actual State After Instantiation Plant 1 0.0 Unhealthy Unhealthy Plant 2 0.0 Unhealthy Unhealthy Plant 3 0.0 Unhealthy Unhealthy Plant 4 0.0 Unhealthy Unhealthy After First Reclassification Plant 1 -1.1 Dead Dead Plant 2 0.1 Unhealthy Unhealthy Plant 3 0.95 Healthy Healthy Plant 4 0.75 Healthy Healthy After Second Reclassification Plant 1 1.1 Healthy Healthy Plant 2 -0.84 Dead Dead Plant 3 -0.75 Unhealthy Unhealthy Plant 4 0.1 Unhealthy Unhealthy The second set of tests are referred to the pumps adaptation tests that are referred to in the results in the paper in Table 1. Pump ID Model Lifetime (H) Temperature Expected Class Actual Class After Instantiation Pump 1 R385 0 5 Operational Operational Pump 2 WPS27 30 80 Overheating Overheating Pump 3 R365 3000 94 Maintenance Maintenance Pump 4 R365 3000 94 Maintenance Maintenance After First Reclassification Pump 1 R385 0 -5 Underheating Underheating Pump 2 WPS27 30 41 Overheating Overheating Pump 3 R365 2000 50 Operational Operational Pump 4 R365 2000 30 Operational Operational After Second Reclassification Pump 1 R385 2500 -5 Maintenance Maintenance Pump 2 WPS27 30000 41 Maintenance Maintenance Pump 3 R365 300 1 Underheating Underheating Pump 4 R365 2000 35 Operational Operational Inspecting the results of the Java tests The container for the Java part is named gh-java-test. It executes the ./gradlew test command to run the tests defined in the /app/src/test/java folder. The tests are defined to check the same adaptation logic as the SMOL tests, and the results are saved in the /app/build/test-results/test folder inside the container. The results are expected to pass and that should be reflected in the html page created as results. If they fail, the html page will show which tests failed and the reason for the failure. The tests are conducted in Java at the moment of creation of the image, and the results are shown in the web client at http://localhost:8080/. The results are further saved in the Docker container under /app/test-results/ as TEST-*.xml files. To access the container, use the following command: docker exec -it gh-java-test bash Then, navigate to the /app/test-results/ folder: cd /app/test-results/ There, you can find the TEST-*.xml files that contain the results of the tests. You can copy the files to your local machine using the following command: docker cp gh-java-test:/app/test-results/TEST-*.xml . The results showed that all tests passed successfully, and that the approach in Java is equivalent to the one in SMOL. However, note that to construct a full API in Java would require to manually implement all the endpoints and the database connections, which is outside the scope of this artifact. Furthermore, since all query to the influxdb are done through SMOL, the Java API would require to implement the logic to query the influxdb as well. 3. Use the system in a real environment For the system to be used in a real environment, it is suggested to change the various environment variables in the .env files to match your environment and security policies. Moreover, make sure to use the latest version of the api that can be found at Github greenhouse-dt-api, as it also contains the integration to the apache activemq. The system is designed to be run on Docker containers, but it is possible to run the system on a local machine. API The API is a RESTful API that can be used to interact with the system. The API is defined in the GreenHouseAPI folder and is written in Kotlin using the SpringBoot library. The API handles the various requests following the CRUD operations. It requires the following environment variables to be set: DOMAIN_PREFIX_URI to be set to http://www.smolang.org/greenhouseDT# EXTRA_PREFIXES list of extra prefixes for adaptation ast,http://www.smolang.org/greenhouseDT# SMOL_PATH SMOL files, in the repository under src/main/resources/SMOL TRIPLESTORE_URL, in the compose it is set to gh-fuseki TRIPLESTORE_DATASET is the name of the triplestore database to use, in our case GreenHouse INFLUX_ORG: organisation for influxdb, in the compose it is set to UiO INFLUX_TOKEN: token for influxdb, in the compose. We use the .env file and .env.influxdb2-admin-token to set the token in the compose INFLUX_URL: influxdb url, in the compose it is set to gh-influx INFLUX_BUCKET: bucket for influxdb, in the compose it is set to GreenHouse Fuseki triplestore The triplestore is a Fuseki triplestore that can be used to store the data in the system. The triplestore is defined in the compose.yml file and is set to run on port 3030. We used Apache Jena Fuseki as the triplestore, and it is present as a tar.gz file in the GreenHouseFuseki folder. The config.ttl file contains the configuration for the triplestore and is used to set the various parameters for the triplestore, and uses the greenhouse.ttl file as ontology. Fuseki is set to run on port 3030 and can be accessed at http://localhost:3030/. Triplestore is set to use the GreenHouse database and can be accessed at http://localhost:3030/GreenHouse. InfluxDB The InfluxDB is a time series database that can be used to store the data in the system. The InfluxDB is defined in the compose.yml file and is set to run on port 8086. The InfluxDB is set to use the GreenHouse database and can be accessed at http://localhost:8086/. In case of a self-hosted database, it is important to write down the token that gets generated during the first configuration as it is required by the API to access the database, as well as the bucket name and org. Activemq The activemq is a message broker that can be used to send messages between the different components of the system. The activemq can be accessed at http://localhost:8161/. The default username and password are admin and admin, but we suggest to change that. The activemq is used to send messages between the different components of the system, and it is important to set the correct username and password in the .env file. Since we did not needed to use it for the artifact, it is not used in the compose file, but it can be added by adding the following lines to the compose.yml file: gh-activemq: container_name: activemq networks: [ greenhouse-twin ] restart: unless-stopped build: context: ./MessageQueue dockerfile: Dockerfile ports: - "8161:8161" - "61616:61616" - "5672:5672" - "61613:61613" - "1883:1883" - "61614:61614" environment: ACTIVEMQ_ADMIN_LOGIN: ACTIVEMQ_ADMIN_PASSWORD: