## 3 Results: AGA Logic Variables for Scene Description and Dialog Communications
### Communication Module and the Dialog Protocol
This product term mixes two entries by logic operators, involving the previous and the next ones. The number of logic variables in entries should be equal. If, due to some reason, any parameter was lost (e.g., network verifier was busy or switched off at the actual time moment), by default, the corresponding logic parameter is substituted for the maximal truth level 255 [68]. We intentionally differentiate between zero and lost data here, as we prefer to avoid excessive zeros in the resulting set of data and not to help possible cheaters. Close aspect was discussed in [68] for the AGA formal description of noisy signals in the combined quantum and classic verification scheme. Another common feature of logic LL is that three groups of data are used in it. The first group is the content data to be written to LL. Due to reasons described in Section 2, logic truth levels can code arbitrary information, mapped onto the logic scale. The second group of data is the approving external hash values, assigned by collaborating external agents and network nodes [68; 69]. The third group of data is represented by internal hash values, proposed in [68] to approve content of LL by mixing of internal and external parameters. It is especially actual for systems with a small number of participants. In fact, all possible adapted versions of LL can be reduced to procedures given in Figure 11. For example, the minimalistic version presented further in Section 4.3 involves entries consisting of one logic word, and other parameters are the approving parameters. In order to explain the practical applications of such an algorithm, let us consider the minimalistic example of the verification task shown in Figure 12, where the autonomous vehicle delivers some hazardous industrial waste to terminals of the specialized reception center. As the price for service may change due to external reasons, there is the danger of illegal data modification by the owner of the robot or his competitors. The state regulator arbitrarily checks compliance with current legislation and requests data, approving correct work of other robots. The regulator's agent can check if the vehicle's uploading system was activated namely in dates of waste loading at the factory and that its real space position at fixed time moments coincided with the GPS coordinates of the factory or terminals. Besides this, the mass and characteristics of uploaded dangerous cargo should correspond to parameters of initially loaded freight that are requested from the factory and the terminal via Internet. Moreover, the advanced state regulator's agent may need to check digital dialog conversation between the vehicle and the terminal. The estimation of possible solutions here shows that permanent black box registration of agent's parameters is comparatively slow and expensive, if the verification of data is not planned to be often held. Moreover, the full dubbing of all incoming sensor data and messages seems to be appropriate only for administrator's archiving, supported by substantial resources. And the telemetry provided by the external network service cannot exclude data leakages. It is reasonable to use some protected data verification scheme, providing quick-enough data extraction and efficient dialog communications between unmanned vehicles, terminals, and regulator's agents. Here, the blockchain method [54; 55; 56] demonstrates the example of possible network solution, convenient for data aggregation and completed work-history documenting in the protected memory storage. For the sake of simplicity, we consider the minimalistic variant of the authentication procedure, where the state regulator's agent requests the individual license number (ID) of a robotic vehicle, which delivers waste to the reception terminal in Figure 12. The full modeling of the task needs to use the decision-maker, which is the task for further design.