## 2 Methodology
### Methods: AOSR Heuristics
These Belief Sets can be modified if needed as per any business requirements, which provides volatility in terms of modifying the standard settings based on confidence about the knowledge according to its date, nature, or the sender of the information (i.e., other agents from AOSF environment). Figure 1: Algorithmic Architecture of AOSR 2.0. Belief-Builder holds the capability, in certain situations, to check on any upcoming exceptions by utilising the _Check-Exceptions_ function. For example, sometimes a request to fetch data may not succeed because of a network failure or an empty record. In such a case, the dataset may hold no record-tuple, which may cause errors when performing operations through actuators. Belief-Builder manages such issues before initiating other components, as highlighted in Algorithm 1. Belief-Builder converts all the information from the _Belief Base_ into data threads to read through and thoroughly compare every single data entry and uses _Thread-Reader_() to extract, analyse, and combine each of them into different Belief Streams. For the initial configuration, the Belief Builder builds the baseline beliefs for Products and Racks, as well as their detailed characteristics. Similarly, Knowledge Builder is based on the same strategy to build the pool of knowledge-constructs and maintain a completely updated _Knowledge Base_. The feature of sensing from the environment ensures AOSR 2.0 is constantly updated, which helps ensure actions are planned in a timely manner. Algorithm 2 represents the heuristics of _Percept-Builder_, which is responsible for pooling percepts from the environment. It builds its beliefs and knowledge from _Belief Builder_ and _Knowledge Builder_, respectively. Based on knowledge threads related to products' locations within the warehouse, it builds a comprehensive placement plan (P), which keeps updating whenever a product batch needs to be shipped or delivered. ```
1:procedureRequest-Analyser-ECU
2:\(Initiate\) BeliefBuilder()
3:\(Initiate\) KnowledgeBuilder()
4:\(PlacementPlan[]\gets KnowledgeThreadPlan[]\)
5:\(request\gets ACLmessageReceiver()\)
6:\(P\gets request.requiredProduct\)
7:\(Q\leftarrow request.requiredQuantity\)
8:\(C[]\leftarrow ExtractCharacteristics(P)\)
9:if request is from ECUthen
10:\(AvailableRacks[]\leftarrow Search\)-\(\mathit{Back}(P,\mathit{cl})\), \(Q\), \(\mathit{Plan}[]\)
11:if\((AvailableRacks[])\)then
12:\(FewestAvailableRacks[]\gets FindFewest(AvailRacks[])\)
13:\(NearestAvailableRack\gets FindNearest(FewestAvailableRacks[])\)
14:\(GeneratePlacement(P,Q,NearestAvailableRack)\)
15:\(UpdateBeliefBuilder()\)
16:\(UpdateKnowledgeBuilder()\)
17:\(Notification-Generate(SUCCESS,ECU)\)
18:endif
19:if(AvailableEA())then
20:if(CheckReslottingNeed())then
21:\(p\leftarrow ExtractADNlogProduct()\)
22:\(q\leftarrow ExtractADNlogQuantity()\)
23:\(GeneratePlacement(p,q,EA)\)
24:\(GeneratePlacement(p,q,ExtractPlacement(P,Q)\)
25:\(UpdateBeliefBuilder()\)
26:\(UpdateKnowledgeBuilder()\)
27:\(NotificationGenerator(SUCCESS,ECU)\)
28:endif
29:endif
30:else
31:\(NotificationGenerator(FAILUIRE,ECU)\)
32:endif
33:\(CheckIpdates\)
34:endprocedure
```  
**Algorithm 2** Overview of Percept Builder-ECU Heuristics. The AOSR-WMS system interacts actively with two main SC entities via several other agents (e.g., supplier side agents, customer side agents, smart device agents, mediator agents, and other user software agents) defined in the AOSF environment [25; 30]: (i) enterprise central unit (ECU), which further connects with the supply chain management unit (SCM) to take account for all the suppliers' management; and (ii) customer relationship management unit (CRM), which takes account of all customer interactions. Both units, ECU and CRM, send requests and desires to a warehouse planner agent for any shipment or delivery operations, corresponding to certain product-batches.