Technology selections

Technologies used in the implementation are selected through the theoretical study from the Chapter 2 of the thesis. Final selection was quite straightforward due to the fact that practise of weight factors was implemented for the most important features of the tech-nologies. These most important features included, pricing of the technology, future ex-istence, reliability of the service provider, data privacy and service security, low learn-ing curve, support for Node.js execution, REST service support in Dashboard solution and extensive software support either through direct contact or through tutorials and online forums. Current section starts from the selection of the programming language

and continues for the selection of the cloud technology and final to the Dashboard tech-nology. Method of tables are adopted for making evaluation.

3.1.1 Programming language selection

All major cloud service platforms (AWS, Azure, GCP) support multiple programming languages for server implemented code execution. In the implementation, REST ser-vices for the robot controller and for the frontend solution plays a significant role. From the previous experience, there was a knowledge that JavaScript with Node.js environ-ment has an extensive support for REST services through additional package and so worth both JavaScript and Node.js was kept as a preferred programming language-runtime compilation. Robot controller has a Digest authentication for the REST inter-face and Node.js request package additionally incorporates the concerned method. From these grounds, JavaScript with Node.js server environment was selected for the pro-gramming language.

JavaScript was originally developed for a scripting language, rather than pure coding language, used in HTML web pages. JavaScript is executed at the client side of the ser-vice. Thus, only a few lines of code is needed to command the client browser to perform the required actions. [134] Another design rule which makes the JavaScript ideal for HTML pages is the asynchronous execution method. Asynchronous means that various code executions are performed simultaneously compared for synchronous method where code is executed line-by-line. Consecutive line waiting for previous one finished.

In the design principles of JavaScript, there are no fundamental limitation that it could not be used at server side as well [134] thus Node.js was developed.

Node.js adopted Google Chrome V8 JavaScript engine and implemented a server side execution. Node.js is an event driven and non-blocking method for building scalable server side solutions. [135] Node has gained extensive popularity in the recent years and vast number of independent developers are participating in Node package ecosystem, npm (Node Package Manager), for making their own code packages performing diver-gent actions. Npm is mentioned as the world’s largest open source library. [135]

3.1.2 Cloud technology selection

For the cloud service technology and provider there was no preferred selection when starting the evaluation. The whole process was handled through initial requirements (see Chapters 1.3 and 2.4.1 for more details). Open source cloud computing services where left out from the evaluation. There were two reason for such action. First, the future existence of the service had set a great value. Second, the readiness for supporting the commercial (Small and Medium sized Enterprises) solutions was one of the primary goal. Private (on premises) cloud solution was left out because in the work description,

public clouds were set to be the technology to use. UpCloud will be one potential alter-native in the future. Now UpCloud provides solid application execution environment with high speed hard drive system. However, no fee for new customers are offered and product line is not yet equal with other rivals. That is to say, evaluation would be cum-bersome with no similar products available.

In the evaluation table, each service provider can score from 0 to 100 on each feature. If all the providers manage themselves equally, everyone is provided with same value.

Score values are weighted through factors decided according to the importance set forth in these features. Pricing, learning curve and existence of the service in the future where the main objectives. This appears in the evaluation table where 20 % factor is provided each of these features. When something as essential as production and process data is in question data privacy was additionally provided with same 20 % weight factor. In the case if some provider would score 100 on each of the feature, according provider would get final score 100 which is the maximum. After the theoretical study and the assess-ment of Table 2. Amazon Web Services was selected to act as the backend service tech-nology. Amazon Web Services fared in the evaluation through their extensive tutorial matters and pricing model. Learning curve in the case of AWS performed superior compared with other rivals. Their service-managing portal is the clear and easy to com-prehend.

Dashboard operates the frontends technology and visualizes the process data for the user. Dashboard acts as user interface. Low learning curve, pricing, report creation pos-sibility and easy implementation style were the key figures when making the final selec-tion. Positive value was also given in the case where REST interface could be natively supported. Highest weight factors where provided for low learning curve and report creation possibilities. Reason for such action emerged from design rule where Small and Medium sized enterprises were kept in mind for one possible implementation environ-ment. Mentioned business sector could alter the Dashboard solution in-house basis and

create modified reports out from the manufacturing process. Methods in the evaluations were similar compared with the assessment of cloud service provider. Through the Ta-ble 3 Wapice IoT-Ticket was selected to be the frontend technology.

Wapice IoT-Ticket managed with the native REST interface and their feature in report creation. Reports can be triggered automatically after the process is finished and report templates can be composed with company specific emblems and document styles. In the case of pricing, the situation was slightly cumbersome. Conventional web applications proved to be the one for least expensive. However, costs would rise in the implementa-tion part. Learning hours would be higher compared to rivals, thus stacking the costs.

Table 3. Dashboard service provider evaluation

Application environment makes the connection of the thesis to production engineering technology and it provides the platform for implementing the designed solution in actu-als process. The application is located at the Tampere University of Technology, Me-chanical Engineering and Industrial Systems research Laboratory of Laser Applications.

Described application is a testing environment for Direct Energy Deposition Methods, a subclass of Additive Manufacturing. Used techniques include cladding and form fabri-cation. These technologies and methods are detailed in Chapter 2.1. Devices of the ap-plication are:

 ABB IRB 4600-40/2.55 robot

 AB IRBP A-750 positioner

 Fronius Cold Metal Transfer (CMT) Advanced 4000R and VR 7000 controller

 Fraunhofer IWS COAXwire

 Corelase C-LASE 3000 kW fibre laser

 Medicoat AG Powder - Duo Laser feeder with FhG COAX8 powder nozzle These devices are connected through various interfaces, which are noted in the Figure 10 where the structure of the application environment is portrayed. Robot acts as the master in the process, controlling the devices. Robot was the natural choice for the main controller for its capability of handling multiple interface architectures. Especially in the