• LinkedIn
  • Facebook
  • Instagram
  • YouTube
  • Mail
OMiLAB@University of Vienna
  • Home
    • Login to your profile
    • About this OMiLAB
  • Partners
  • Projects
  • Digital Innovation Environment
  • Events
Login to join the community
OMiLAB Community of Practice » OMiLAB@University of Vienna » Digital Innovation Environment » Experiments

Self-monitoring CPS


Source code:

Use Case

In the chosen use case, the car-sharing provider’s cars can monitor their own state in terms of the viral load on the inside of the car and communicate it to potential customers. Also, based on this internal state and the overall state of the providers vehicle fleet, decisions are made in order to ensure that an appropriate number of safe cars is active. The underlying concept is that customers have a different risk appetite and therefore, it is reasonable to provide such a service. The CPS considers different aspects in order to decide what information should be communicated to its stakeholders (customers and service personel) as well as how it reasons to guarantee an appropriate number of safe cars. This amount of cars is assured by either waiting until the viral load is reduced or by consulting a disinfection station.

Important key factors are:

  • positive or negative customers
  • Acceptance of negative covid-19 test results which can be handed in in retrospect
  • Number of cars which are safe in the whole fleet
  • Dynamic calculation of a threshold when to wait or to disinfect (when threshold is exceeded)
  • Day or night in order to determine when a disinfection station is operating
  • Weather conditions in order to predict public car demand

Experiment

In the experiment, we want to test the capability of our car to correctly communicate its own state and make proper decisions based on the implemented Rule-based System. Depending on the environment, several outcomes are possible. In the video below on scenario is depicted with the following actions:

  • The car is booked by a contagious customer
  • No negative covid-19 test result is handed in in retrospect
  • It is currently day, the car is contagious (due to the customer) and the threshold is exceeded
  • The car drives to the disinfection station
  • The car is disinfected by the service personell
  • The car’s status is safe again

Results

Overall, the experiment in connection to the use case was conducted successfully and the semantic approach was effectively realised. The CPS is working accordingly to the principles of a Rule-based System. For our use case, sufficient rules are implemented in the CPS. The inference engine (our APIs) perform communication between the data base, consisting of the rule base and the working memory, and the user. As a result, the CPS is capable of monitoring its own state and reacts appropriately to its environment. Furthermore, It is possible for a user to control the CPS via Bee-Up and all underlying information which the CPS processes are displayed. Therefore, it is transparent why the CPS performs which actions during the run-time of the experiment.
Despite the overall success of the experiment there are still aspects which could be improved.

First of all, we lack the opportunity to use input parameters in order to control the course of the experiment. For example, we cannot influence, whether a customer is positive, negative or that a negative covid-19 test result is provided in retrospect. Hence, we are heavily dependant on our mocked data which turned out to be very tedious during the process of testing and verification. This is especially  true, since our use case has developed a certain level of complexity over the course of several iterations and there are many factors which influence the outcome. In addition, one could consider to automate the process of car renting. Currently, we have to manually trigger the customer-interaction process in Bee-Up which simulates that a customer rents a car. On the other hand, our use case might become too confusing if random customer interactions would disturb the workflow.

Another improvable aspect which is also connected to the mocked data affects our dynamic threshold. We tried to stay as close as possible to the typical behaviour of a pandemic by using a mathematical function in order to calculate the threshold. However, we cannot consider historical data from the last days or week which would be very valuable for such an analysis. We are rather relying on random data from said function. In general, we did not manage to implement a concrete time frame for our use case which would have been interesting.

Our last thought for improvements would be that the workflow could be simplified in case a customer is negative or an early negative test result is provided in retrospect. Currently, all actions are performed for positive and negative customers alike. Even though, most actions are not explicitly useful for a proven negative customer and a safe car (e.g., check for a negative covid-19 test result).

In conclusion, the experiment was a success in proving our use case’s theory. The Rule-based system is enabling our CPS to monitor itself, changes in its environment and react accordingly. However, small changes would be beneficial for an increase in user-friendliness and an improved presentation of the scenario.

OMiLAB Community of Practice

This OMiLAB is member of the OMiLAB Community of Practice organized by OMiLAB NPO.

OMiLAB NPO / OMiLAB gGmbH
Lützowufer 1
10785 Berlin
Germany

  • LinkedIn
  • Facebook
  • Instagram
  • YouTube

Email: office@omilab.org

Learn more about
OMiLAB Community of Practice

NEMO Innovation Camp

Bee-Up Modelling Toolkit

ADOxx Metamodelling Platform

Scene2Model Digital Design Thinking Platform

Quick Links

  • Home
  • Partners
  • Projects
  • Digital Innovation Environment
  • Events
  • Administration
  • This website is provided to you by OMiLAB NPO
    Imprint & Copyright – Pricacy Policy