Please disable Adblockers and enable JavaScript for domain CEWebS.cs.univie.ac.at! We have NO ADS, but they may interfere with some of our course material.

Components

Our setup contains three major components, the physical Lego industry with motors and sensors. EV3 Bricks for communication between the physical system and the CPEE which is our process execution engine. 
 

Lego

The physical side of the lego is built with a diverse set of mechanics known from industry i.e. a conveyor belt, crane, warehouse, rotary plate. Each of these components consists of motors and sensors. All of these components are built in a way that they are self calibrating. This is necessary as we do not want human tasks to be necessary while demonstrating the processes. I.e. When streaming and accessing the industry from the other side of the world there might not be a physical person nearby for the calibration task. 

Services / EV3 Bricks

These EV3 bricks serve as connection between our physical system and the process model running within the CPEE. They allow for access over a REST API. The API allows for an interesting problem we did not think of beforehand. The granularity in which the API has to be designed. There are several ways such a REST API can be implemented. 
 
  1. Direct inputs, in this case the API allows for direct access of motors and sensors. For example the process engine has to call the motor how long, at which speed it shall run. Or the engine runs a motor on a certain speed and listens on a specific sensor until a certain value is reached and then stops the motor. 
     
  2. Composition of inputs, in this case the API does multiple inputs with one access. In this case specific commands are available per physical system. For example the process engine calls the service "Go Left" within the API the motor is started in the direction left with an default speed and the motor is stopped when a certain sensor is activated. In contrast to the case above where the process engine has to set the speed and listen to the sensor. 
     
  3. Full run through, in this case the API gets a call and runs through the process without the need of another call. The API starts and stops multiple independent parts of the physical systems in order to achieve its goal. 
 
We decided to use the Composition of inputs for various reasons. 
  1. In contrast to direct inputs the process designer does not want to set the speed of the motor, nor to listen for a specific sensor to stop the motor. 
  2. The Direct inputs API can be dangerous as well. What happens when the process designer forgets about stopping a motor? Does the machine break?  
  3. Full run through would be possible but in that case we would need to program our process models within the bricks. If there is ever a change to the process we would need to change this within the bricks and could not to this conveniently with a process model.  
  4. Further Full run through would not be suitable for supporting our case of demonstrating the capabilities of the CPEE and we would not be able to show certain goals we want to achieve i.e. runtime process changes, order preferences.  

CPEE (Cloud Process Execution Engine)

For more information see «http://cpee.org/» 
Letzte Änderung: 30.01.2017, 09:54 | 534 Worte