The Design Environment is a graphical user interface (GUI) with the aim of helping users to get in touch with the PHYSICS solution framework, providing the tools and a GUI to simplify the development, testing and management of FaaS applications, all in one place.

The Design Environment is a graphical user interface (GUI) with the aim of helping users to get in touch with the PHYSICS solution framework, providing the tools and a GUI to simplify the development, testing and management of FaaS applications, all in one place.

The GUI is a downloadable packaged solution running as docker container on the user client device. Such solution gives to the user the flexibility, at the start up of the project, to leverage the user resources and don’t necessary rely on the cloud environment, with an approach of EDGE computing[1] architecture.

The GUI is divided in two main sections: the first one is dedicated to the Node-RED[2] application that provides a browser-based editor that makes easier to wire together flows using the wide range of available nodes, even custom PHYSICS’s nodes; the second one is the Admin Panel where the tools for managing the deployed Node-RED flows are located.

In the “Admin Panel” the user can proceed to the build of the deployed Node-RED flow to make it ready for the execution in the PHYSICS platform. Then, in the “Test” section, the flow can be tested from both logical and performance point of views. The last section (“Graph”) is dedicated to the creation of the graph where the user can define an application that includes one or more flows.

The application also gives to the user the possibility to load the (not generated) custom images into the integrated Node-RED environment, which can also be located in a user’s custom repository.

The Design Environment integrates a login system based on Keycloak[3], which provides an all-in-one solution to manage the user’s Single Sign-On (SSO) to the application, i.e. the capabilities of authentication, authorization and segregation of the user workspace. The SSO feature enables the future opportunity of enforcing the security of the PHYSICS resources.

The application interacts with the other components of the PHYSICS environment, to enable the build, testing and management of the related flow. In Figure 2, a high-level diagram of the interactions of the GUI with the other PHYSICS components is represented.

[1] Edge computing is a distributed computing paradigm that brings computation and data storage closer to the sources of data. (https://en.wikipedia.org/wiki/Edge_computing)

[2] Node-RED (https://nodered.org/)

[3] Keycloak (https://www.keycloak.org/)

The post PHYSICS Design Environment appeared first on PHYSICS.

Plant growth and production are the outcome of complex interactions between the plant and its environment. To setup the devices controlling the environment in the greenhouses with optimal efficiency, these interactions must be accounted for. Cybeletech develops biophysical plant growth models, which coupled with environmental models, allow to anticipate the impact of management scenarios on greenhouses outcome. To accurately estimate the current status of the plants and anticipate their development in different scenarios it is necessary to have access to the full history of environmental conditions in the greenhouse.

In most of the greenhouses these environmental data are monitored by a set of sensors. The data collected by the sensors are made available through a so-called supervisor, which is often a desktop computer with dedicated software for greenhouse monitoring and management, located in the greenhouse. According to the greenhouse equipment the data may be temporarily saved on this computer or not. To enable the plant growth models to access the full history about environmental conditions, there is a need for reliable data collection pipeline with the following requirements:

1. The data collection pipeline must be resilient to connexion failures, which are happening regularly in greenhouses;
2. The pipeline must be easily adaptable to integrate new and different kind of environmental data sources;
3. The pipeline must be easily deployable on different kind of infrastructure.

A generic data collection pipeline has been implemented in a Node-Red flow and packaged as a pattern (Figure A). It integrates a getaway to temporarily saved the environmental data in a local database in case of connexion failure as well as a retry procedure to send them in distant database as soon as connexion is restored. The procedure to retrieve and pre-process the data collected by the sensors can be implemented in a Python script which is given as input of the pattern (Figure B). The deployment of the pipeline has been done on the supervisor using the Design Environment developed in PHYSICS.

The deployment from scratch on the test greenhouse supervisor took less than half a day. It allows to collect the data measured by sensors over a month without any data lost despite several connexion failures in the greenhouse. Moreover, the Python script for data collection and pre-processing has been adapted to integrate a novel temperature sensor. With the Edge-ETL pattern enabling to abstract from the overall logic, and the Design Environment for deployment on the edge, this update takes less than a day.

The PHYSICS development environment enables a smoother deployment and adaptation of the pipeline for data collection on the edge, while the dedicated pattern increases the reliability of this pipeline.

The post Taking advantage of PHYSICS to implement reliable data collection pipelines on the edge appeared first on PHYSICS.

Personalized healthcare requires decision support systems that can help healthcare professionals to manage large volumes of patients. Care for chronic conditions requires doing so for patients at their everyday setting, outside the clinical environment. These needs can only be addressed with AI systems, at the core of which models trained by ML can be found. Such systems are deployed to offer diverse services, such as model inference for patient outcomes’ prediction, patient clustering into phenotypes and dataset augmentation with synthetic arms.

The traditional deployments of such systems in healthcare suffer from scaling. Deployment is a lengthy procedure, certainly aided by modern CI/CD pipelines, but the resulting systems are quite static in terms of resources, while occupying them even during quiet times.

PHYSICS facilitates the design and deployment of these services. It provides a design environment to implement and deploy the services. The starting point is an AI function implemented in Python at the core, which constitutes a node in complete Node-RED flows built around it using more (Javascript) functions and PHYSICS patterns to handle input and output.

Node-RED offers developers the means to locally test the flow, using additional nodes for user input, and invocation. Local testing is handy during the implementation phase.

Still using the design environment, locally tested flows are then deployed as functions to expose the health care services. PHYSICS annotation nodes control the deployment options at the flow level.

Thus, the flows employed for defining testing and deploying healthcare services are usually split in three sections. The endpoints definition section defines two POST endpoints, the /run with the service core, and the /init for any initialization. The manual invocation section facilitates local testing by sending a request to the /run endpoint. Finally, the annotations section controls the deployment options. The sections are shown in the flow depicted below:

The healthcare services being implemented in the PHYSICS FaaS way are:

• Predictive model inference: Load feature vectors and a predictive model into an inference engine to get inference results.
• Patient phenotyping: Load feature vectors and a set of generative models (describing patient clusters) into a system that return the model best describing each vector.
• Data synthesis: Load a set of generative models and a model transition probability matrix into a system that draws vectors from the generative models, following a model activation pattern as described by the transition probability.

Currently, the first flow is implemented, tested and deployed. It is now undergoing testing to showcase the benefits of the PHYSICS approach in terms of handling rapid small requests by merging them into larger ones. The rest of the flows are under initial implementation. Stay tuned for more news on our progress!

The post FaaS-ification in Health Care appeared first on PHYSICS.