# An Architecture for Reliable Transportation of Delicate Goods
## 5 Workflow  
### Service Initialization  
Figure 2 shows the procedures between the actors in the system. The customer/sender contracts the service with the transportation service provider. For this purpose, it defines the transport conditions, which include the limits of the relevant variables and deadlines. The service provider validates the possibility of providing the service, which requires confirming that there are operators to perform all stages of the track under the requested conditions, including deadlines, whether they are carriers, warehouses or others. If there is an agreement, the process begins, specifying the conditions of transport and descriptive information (of the device, merchandise and transport conditions). Two keys are generated, one that only the sender should have access to (later he will provide that key to the recipient) and another for the service provider. Among other things, these keys are used to retrieve the state and get information about the merchandise, through the portal that gives access to the cloud services. There are two distinct keys, since the information provided to each party (service provider x sender/recipient) is distinct. The service provider has access to all the information supplied to the sender/recipient and to the internal information related to the operators. It is up to the sender to pass the key to the recipient, so that this one can formally receive the merchandise. Non-public identifiers are also generated for the device, merchandise, operators, sender and recipient, as well as two pairs of keys for asymmetric encryption. A device is initialized through a reset operation, which will immediately activate the configuration mode with the BLE service designed for this purpose. The process stores the following data: the public key of the first pair of asymmetric keys; the private key of the second pair; the identifiers of the device, merchandise, current operator and next operator; transport conditions; descriptive information; and the earliest and later delivery dates (EDD/LDD) on which the merchandise should be delivered to the next operator. The operating mode and state of the device are also defined, taking into account the way the device is fixed/associated to the merchandise. This state defines the condition of the merchandise in relation to the operator and serves to control the actions that must be available at each moment. In the context of this paper, this state has only two possible values:  
DEPOSITED--Indicates that the operator deposited the merchandise to be received by the next operator. RECEIVED--Indicates that the operator received the merchandise. The RTC of the device is reset and the present GMT+0 universal time is preserved in the cloud registry. Figure 4 shows the BLE characteristics defined for the configuration process, aggregated in what was named as the Closed Access BLE Service--Setup. In turn, the following data is stored in the cloud: the private key of the first pair of the asymmetric keys; the public key of the second pair; the identification of all operators involved in the transport, by the intervention order, with the respective EDD and LDD, maximum time after deposit that the next operator has to collect the merchandise, and approximate geographical position of the merchandise transfer place; the universal date of the RTC restart and the present state (RECEIVED). The device is attached to the merchandise in the presence of the customer, with a physical lock that, once applied, triggers the procedure to monitor the merchandise until it is delivered to the recipient. From then on, the device starts to work, collecting data of the non-compliances. If the safety lock is removed ahead of time, the procedure will not be closed or will be closed in an irregular situation. and the operator who officially had the merchandise in his possession will answer for any damages that may occur.