Manufacturing Control Systems Capable of Managing Production Change and Disturbances
Mascada compared to ...
This section gives a short review of relevant literature for Mascada. It contains four parts.
First, ARIAA is reviewed; it is highly relevant for Mascada. The ARIAA scope is quite similar; although the application focus is different. Mascada focuses on throughput whereas ARIAA is designed to fulfill incoming tasks in due time. ARIAA also uses exclusively pricing mechanisms to achieve self-organization. Mascada intends to use more technical information as well. Both projects want to achieve self-organization and schedule emergence.
Second, distributed scheduling systems are discussed. Distributed scheduling has many similarities with Mascada but there are differences in the nature of the entities (agents) in these systems, the context and the problem domain which require a novel approach. These are:
Third, the system development tools are discussed. The consortium recognizes that the GenSym developments would be very useful, but pricing prevents their use throughout this project. It is possible that G2 will be evaluated in the context of one of the demonstrator projects.
Fourth, work on integration of process planning with scheduling is addressed. This is outside the Mascada scope, but can be addressed within the PROSA architecture (and is the subject of ongoing work with the partners outside the Mascada project). One relevant result from this work is that this integration is able to offer opportunities for enhanced performance, for certain processes, by reducing the granularity of the operations by an order of magnitude. This means that the production system has a much larger set of alternatives at its disposal (e.g. to maneuver around disturbances).
The AARIA project is very relevant for Mascada and very similar in scope. AARIA aims to derive actual control decisions from schedules; these schedules are created in a distributed manner by agents. AARIA also aims to have the agent systems self-organize in response to the demands and pressure from the environment. Mascada has similar goals.
AARIA differs from Mascada in the application focus. AARIA wants to control a production system to fulfill incoming tasks in due time, whereas MASCADA wants to safeguard and/or maximize throughput in various production systems in which disturbances nullify the effectiveness of plans/schedules that are generated (too long) on beforehand.
AARIA uses ‘dollars’ in its mechanism to achieve and implement emergent behavior and self-organization. Mascada will use more technology-oriented types of information (e.g. time windows and product characteristics, such as color, which determine whether an individual product can join a given batch). The Mascada agents will be more knowledgeable on the physics and mechanics of the system to which they belong. Pricing may be used in Mascada as well, e.g. to handle capacity contention, but it is only one of the mechanisms.
Mascada will investigate three different applications (one test bed, two demonstrators), and derive guidelines to reduce the time and effort required for new applications. AARIA is building a single system.
We expect this AARIA system to be suitable for manufacturing control at a significant distance from the equipment control itself, including the multi-site coordination/control - which is an interesting target in economic terms. When the control task moves closer to the equipment, the Mascada results and approach will be more suitable. In a sense, Mascada addresses the more difficult problem because its target is more heterogeneous and likely to impose harder constraints. Because of this, AARIA is likely to face more direct competition from existing alternatives. In other words, the consortium believes that Mascada will yield better value.
MicroBoss and CORTES look at the scheduling problem as a constraint satisfaction problem (CSP): each order has an earliest start time and a latest completion time, and the scheduling algorithm looks for a feasible, rather than an optimal schedule. However, in MicroBoss, it is possible to define due dates, and to take decisions in such a way that the tardiness is minimized (Constrained Optimisation Problem - COP). Lead time and work-in-progress are also addressed by Microboss. To identify the need for backtracking quickly, MicroBoss defines aggregate demand profiles for each resource. This elegant concept has been on the shortlist of the Mascada project from the very beginning as a useful element.
In the CORTES project, Sycara extends the concepts of micro-opportunistic scheduling to distributed scheduling. Agents construct aggregate demands profiles, maintain them and exchange updates of them on regular basis. Meanwhile, new constraints are added as the agent takes scheduling decisions. Sycara also defined a communication protocol to exchange the information between agents, like demand profiles.
Summarizing, based on the detection of bottlenecks and rush orders, the CMU group has developed a set of scheduling algorithms based on AI techniques. These algorithms provide good schedules in reasonable time, are also used for reactive scheduling (schedule repair) and distributed scheduling. As such this work is relevant for Mascada, especially the reactive and distributed versions.
Differences, to be addressed in Mascada are:
DAS (Distributed Asynchronous Scheduler) is a distributed constraint-based scheduler. DAS is based on a hierarchical management organization; the hierarchy is three-fold and resembles three possible layers in a (manufacturing) organization. DAS has agents assigned to resources which perform tasks at these different levels (operational, tactical and strategic), while jobs are passive and are presented to the strategic agent for schedule assignment.
In contrast, Mascada uses the PROSA architecture in which agents are associated with resources, jobs and product types. Hierarchy is introduced through aggregation, but such hierarchies are dynamic. Mascada has, in addition, enabling agents (staff agents) which can form a temporary hierarchy when required.
DAS is flexible in case of disturbances by representing the disturbance (e.g. machine failure) by a repair operation; that allows to handle such a failure by normal scheduling activities. Jobs can be introduced at any time into the system. Mascada will provide such abilities as well, similarly treating disturbances as ‘business as usual’.
The differences to be addressed by Mascada are mostly identical to what is written for MicroBoss and CORTES (cf. supra).
ReDS2 Distributed scheduling system (logical successor of DAS), distributes the scheduling criteria over agents. Purpose of REDS is to find a structure that can be used for designing production control systems. The proposed structure is composed of recursively defined autonomous modules, referred as planning agents (note that planning is a function). In contrast, Mascada recognizes four types of agents in its PROSA architecture. This PROSA architecture offers, for instance, advantages concerning the integration with other dimensions in manufacturing (cf. IP3S below).
ReDS uses top-down goal decomposition and bottom up disturbance handling ('shock absorption'). Mascada uses knowledge about the production requirements (from the user) to handle disturbances at the lower levels, and will ignore plans from higher level planning agents when they have become ineffective because of the onset of disturbances.
ReDS treats intentional changes flexibly (order negotiation), in a top down manner by goal decomposition. It treats global performance comparably to what Mascada does (with staff agents) by the statistician. This statistician is one example of a staff holon. Another example are the monitor agents from Lin and Solberg.
The remarks about what Mascada still needs to address, in addition to what RedS achieves, are similar to what is written for MicroBoss and CORTES (cf. supra).
Red Pepper currently is the core of PeopleSoft's ERP software: 'intelligent assistants to manufacturing planners and schedulers'. It is based on 'Response Agent' (Production Response Agent; Enterprise Response Agent) technology: real-time planning and scheduling to respond and adapt to changes. Focus is on enterprise functions & integration, and as such, on higher level than in Mascada. It has been reported, that Production Response Agent and PeopleSoft Manufacturing (PSM) is used for sales & distribution facility, but NOT for manufacturing (actually PSM is not up to dealing with the rigors of the manufacturing process).
In other words, Red Pepper does not emphasize the ability to account for the specific requirements of the manufacturing system that must be controlled. It focuses on the planning and scheduling tasks at the border of today’s ERP systems. The remarks written for MicroBoss and CORTES (cf. supra) still apply.
ILOG provides a constraint-based scheduling approach. Scheduling is treated in the classical sense as sequencing of tasks on production resources. The underlying process model contains production resources, jobs with partially ordered tasks, due dates, and durations. The underlying information technology is Finite-Domain constraint solving. The basic functionality is provided by a tool called ILOG Solver.
On top of this tool, a second tool is developed which provides scheduling-specific modelling and processing facilities: ILOG Scheduler. There is a lot of discussion in the constraint-based scheduling community how far one should go with such specialized constraint processing; it restricts the expression power of the underlying modelling language. When operating close to the production machinery, as Mascada does, this is a significant disadvantage. Also, constraint-based systems are difficult to handle by end-users.
In conclusion, ILOG seems unattractive to Mascada because a lot of issues remain unsolved and crucial aspects receive little attention (e.g. the ability to cope with specific properties of the problem domain while remaining computationally efficient). The disadvantages of using (non-mainstream) ILOG technology are likely to outweigh the advantages within the time frame available to the Mascada project.
A-TEAMS is a system/tool to build multi-agent solutions for computationally hard problems (an A-Team is a network of collaborating software agents). One of these problems, to which A-Teams was applied, is job shop scheduling. The result of this exercise is, in comparison to the results of Micro-Boss and Cortes, less specifically relevant to Mascada. The application described in the reference below addresses the problem of off-line static scheduling; and hence it does not address issues like disturbances and transportation between the workstations. It follows a task-oriented approach, whereas Mascada follows the PROSA (Product Resource Order Staff) approach, where agents represent objects like resources or orders. A-Teams have addressed other problems but mainly in the domain of ‘high performance computing’ instead of interaction with a complex environment like manufacturing systems. In this respect, it is unlikely that the A-Teams ‘toolbox’ is particularly suitable for comparison with Mascada.
GENSYM provides a set of products to develop real time systems. Products are built around Gensym’s flagship software G2. Developed in cooperation with the National Center for Manufacturing Sciences (NCMS), the ADE toolkit allows Gensym customers to rapidly develop, test, and deploy intelligent agents across a network. As such, Gensym provides an environment enabling easy development of multi-agent systems.
Nevertheless, Gensym doesn’t provide scheduling or manufacturing control applications. G2 is an open-ended development shell; the design of the agents behavior is left to the application builder. Moreover, in most applications, the reaction to disturbances is not an automatic behavior. Most of the time, the user only gets assistance for decision making, thanks to powerful graphical tools.
In conclusion, G2 and ADE would be good environment in which to develop and implement Mascada multi-agent system. Inter-agents components are worth consideration and would allow to concentrate on agents and system behavior, without having to care for agents "logistics". The consortium is aware of the advantages G2 offers, but its price makes it an unaffordable solution in the scope of this project. This price does not represent an obstacle in the market of A.I.Systems. However, its price is a smaller (but not insignificant) obstacle for exploitation because it is too expensive for most educational environments such that the availability of trained personnel is limited.
IP3S (Integrated Process Planning/Production Scheduling) is the integration of process planning and production scheduling. The integration is based on a blackboard architecture. The blackboard and the common representation for exchanging the information make it possible to add different kinds of process planners and schedulers to the system. Currently, the process planner IPPI and the Micro-Boss scheduling system are adapted and integrated in the system.
Such an integration is out of scope for Mascada. However, the PROSA architecture was designed by a team comprising members who had been involved in a similar project (Complan, short-term R&D). The mandatory presence of the product holon is, among other reasons, justified by the knowledge that a migration path for such integration is required. By‘agentifying’ the product ‘type’, it becomes even possible to relax the need for common information representation formats with interaction protocols. Current activities in this domain, outside Mascada, is basic research on NC control in PROSA, which also involves on-line process planning while accounting for unpredictable resource availability and process results.
Comments for the authors: Paul Valckenaers
Page design: Paul Valckenaers