## 3 Results
### Use Cases
#### 3.4.1 Application of 3D Printer for Additive Manufacturing  
This use case is an end-to-end demonstration that can be applied to a network of micro-factories that can produce products with additive technologies such as 3D printers. Using the same sequence diagram from Figure 24, a new product is bought by the client, which places a new order (Figures 25 and 26 depict the user interface to add an order). Figure 26: Customization of a 3D printable part. Figure 25: Order creation by the client. Conventionally, the term \"client\" often evokes the notion of the end consumer; however, within the realm of micro-factories, the client paradigm expands to encompass entities such as Original Equipment Manufacturers (OEM). Figure 25 shows a listed price value. This listed price varies in conformance with several factors, such as the factory chosen proximity, production scheduling, premium freight, or electricity cost. The price has a fluctuation calculated by the ERP using these metrics that can be shared using the same mechanism of authenticity as the energy consumption that we focus on here. In Figure 26, we illustrate the option to customize a component by sending a valid file (such as an *.stl file) through the ERP to the manufacturing site. This file, too, undergoes authentication and gains traceability through the blockchain component. The order execution is validated by the ERP which sends an invoice to the client (Figure 27) and, through the cloud middleware, the information to the factory (Figure 28). As can be seen in Figure 28, the ERP interface displays solely the generated hashes. However, the information exchanged--readily available for auditing--comprises comprehensive details and specifications. In this instance, these details encompass factors such as filament type, color, density, and notably, the file housing the design of the part intended for printing. With this information, the factory can accept or refuse the order (Figure 29). An acknowledgment is sent through the cloud middleware, and the manufacturing process (if accepted) starts (Figure 30). Figure 28: ERP interface to send orders to partners. Figure 27: Invoice creation. In Figure 29, it is possible to see that the MES system is completely different from the ERP. They are instantiated in two different countries--ERP in Finland, MES in Portugal, and blockchain nodes in Greece--and rely on the cloud to exchange information. Time performance evaluations were not conducted during these tests, as they fell outside the scope of our objectives. The primary focus was on information exchange, a process consistently achieved within a delay of less than five seconds, and the authenticity of the data that could not be accessible from third parties. At the end of the production (Figure 31), the information about energy consumption is sent to the cloud middleware to be available to all tools that need it (Figure 32). Figure 30: MES interface (printer with the event production). Figure 29: MES interface to receive or reject orders from partners. Figure 32 shows the output of the analyses that can be performed, by an authorized stakeholder, in which the progress and all the commitments done for the blockchain can be tracked. Stakeholders requiring access to energy consumption data, such as the ERP for conducting price analyses in this scenario, must be authorized at the blockchain level. The MES system internally stores these data within its own database; however, upon committing to the blockchain, it cannot read it from there due to a lack of reading authorization. An authorized entity has access to the information such as the one in Figure 32 where the \"Consumption\" can be seen, and the \"flow\" can be crosschecked in Figure 28. Looking at this use case, we can say that it was possible to use the architecture and the implemented platform in a heterogeneous environment since we demonstrated the use of several actors with different capabilities to achieve a common goal.