Core Application. The term “
Core Application. As used herein, the term "Core Application" shall mean the software and related Documentation, provided by Contractor pursuant to this Agreement as part of the System Software in accordance with Subtask 2.2 (Deliver and Install System Hardware and System Software) of Exhibit A (Statement of Work) and identified in Section I.A.1 (Core Application) of Attachment A.2 (System Configuration) in order to meet the Functional Requirements. County As used herein, the term "County" shall mean the County of Los Angeles, California. County Facility; County Facilities As used herein, the term "County Facility(ies), whether singular or plural, shall mean any one or all of County facilities listed in Attachment A.5 (County Facilities), for which Contractor shall provide tasks, subtasks, deliverables, goods, services and other work under this Agreement.
Core Application. Agent Logic The agent logic refers to the selection of the scheduling software that is suitable for the given problem class. The agent is given with the problem that is supposed to give a planning/scheduling decision, however the identification of the way that the problem is going to be solved in an internal procedure. Due to the diversity of manufacturing scheduling problem making this decision autonomously would be a very complex aspect for the agent, in order to reduce this type of complexity the agent was given this configuration by the AAS description as well as the amount of accuracy and resources that are going to be allocated in order to solve this optimization problem. These properties are mentioned within the Sub-module [“Scheduling properties”] and acknowledge the agent on what is the optimization tool that is going to be used to approach the solution. It is important however to define who is responsible for defining this parameter. In the proposed MAS4AI planning agent solution, this parameter is provided by the user (production manager). This aspect will be covered by the UI-agents developed in WP2, WP3 and WP6 which will allow interaction between the multi-agent system and the business personnel on the factory. Although this might be a difficult decision for the production manager considering the fact that he/ she might not be familiar with the optimization solution, this selection needs to be performed only once in the agent’s lifecycle. What is more, as some of the proposed planning methodologies are very environment specific e.g. transportation planning versus resources planning, this selection will be even easier for the user. Other than the decision of the scheduling approach, the agent’s logic works at all times as it is responsible for handling information within the agent. In specific, as the interaction layer services retrieve information from external sources and convert them into JAVA objects using within the meta-agent application the logic defines what to do with this information. As such, during the optimization procedures that are covered by the optimization toolbox, the meta-agent awaits the scheduled/ planned output. From that point on, the agent logic will give this information back to interaction layer in order to distribute them into the corresponding endpoints.
Core Application. Agent Logic The VDL use case was the one, that provided the guidelines to develop the deviation agent logic. In VDL production system, deviations from the initial plan are identified manually in the ERP system by an operator, at the end of each shift. Rather than this, even when deviation is recognized and addressed, it is not tackled in an efficient way. Thus, the solution that the deviation agent will provide is two-way: · Highlight deviations · React to deviations The operator that performs this task manually can make mistakes. In addition, it is a time- consuming job. By automating this task, identifying deviation for a production system will be easy and quite accurate. Based on a deviation observed, by inserting some condition parameters, the user will be able to decide which is the desired action (local reschedule, broadcast reschedule etc.). The information about orders/jobs/tasks is stored in the AASs. By extracting the information for a particular entity, the deviation agent will be able to calculate deviation. Rather than an order id for a general deviation check, clarification about the specific value that needs to be checked for deviation can be provided. For example, if the user chose the checkStart function, the deviation agent will check the start dates and times of the orders included in the assignments property of the AAS. In addition, a condition check can be defined, if we want to make an immediate action, if deviation is observed. Additionally, the deviation agent, rather than applying the deviation logic for identifying deviations in a particular process, it is going to highlight the processes affected an occurred deviation. This will notify the production manager to include orders with possible future deviations in a rescheduling round. The deviation agent logic is shown in Fig1. Figure 47 Deviation logic flow diagram
