KR101216189B1

KR101216189B1 - 제조 공정 흐름의 스케줄링 카렌다 및 약속

Info

Publication number: KR101216189B1
Application number: KR1020047019538A
Authority: KR
Inventors: 리위웨이; 네틀스스티븐시.; 바토래리디.; 마타구스타보
Original assignee: 어드밴스드 마이크로 디바이시즈, 인코포레이티드
Priority date: 2002-05-31
Filing date: 2002-12-20
Publication date: 2012-12-28
Also published as: KR20100071111A; JP4559850B2; TW201030641A; TW200401996A; TW201030642A; AU2002359878A1; TW201030643A; TWI332181B; TWI332636B; CN1650300A; JP2005528703A; JP2010165378A; TW201030640A; TWI332182B; EP1514204A1; KR20050008760A; TWI332162B; US7512454B1; WO2003102841A2; JP5496754B2

Abstract

본 발명은 제조 공정 흐름의 약속들을 스케줄링하는 방법 및 장치를 개시한다. 이러한 방법 및 장치는, 커미트먼트 윈도우 내에 공정 윈도우가 떠있는 약속들과; 공정 윈도우들이 소모 간격 및 공정 간격을 포함하고, 이러한 공정 윈도우들이 다른 약속들의 공정 간격과 겹칠 수 있는 약속과; 다양한 상태들로 유지되는 서로 다른 타입의 약속들을 포함하는 서로 다른 타입의 카렌다들의 이용과; 예약된 약속들에 의해 나타나는 명시적 제약 뿐 아니라, 예약된 약속들에 의해 나타나지 않는 암시적 제약에 의해 약속들이 제약을 받는 카렌다링 시스템과; 카렌다들을 관리하는 데에 이용되는 카렌다 조정 기술들과; 그리고 다수의 카렌다들을 통해 동기화된 방식으로 유지되는 대응하는 약속들을 포함한 많은 양상들을 포함한다.

공정 제어, 공정 툴, 카렌다 시스템, 약속 변경, 시프트, 점프 오버, 공정 윈도우, 커미트먼트 윈도우, 직렬 시프트

Description

제조 공정 흐름의 스케줄링 카렌다 및 약속{SCHEDULING CALENDARS AND APPOINTMENTS IN A MANUFACTURING PROCESS FLOW}

관련출원

미국 정부는 본 발명의 지불 완료 라이센스(paid-up license)를 가지고 있으며, 미국 상무성, 미국 국립 표준 기술원("NIST"), 어스밴스트 테크날러쥐 프로그램("ATP")에 의해 수여된 협약서 번호 70NANB7H3041에 제시된 정당한 조항들에 입각하여 제한된 환경에서 특허권자로 하여금 타인들에게 라이센스할 것을 요구할 권리를 갖는다.

본 발명은 자동 제조 환경에 관한 것으로서, 특히 에이젼트 기반 스케줄링 및 공장 제어를 이용하는 자동화된 제조 환경에서의 스케줄링 카렌다 및 약속의 이용에 관한 것이다.

복잡한 전자 장치들이 전세계적으로 수용되고 그 기술 요건들이 증가함에 따라, 전례없이 대규모의 복잡한 집적 회로들이 필요하게 되었다. 반도체 산업의 경쟁에 의해, 제품들은 가능한 가장 효율적인 방식으로 설계, 제조 및 판매될 것이 요구된다. 이에 따라, 전자 산업의 급속한 진보와 보조를 맞추어 제조 기술의 진보가 요구된다. 이러한 요구들을 충족시키기 위해, 물질 및 처리 장비에 있어서 많은 기술적인 진보가 이루어졌고, 집적 회로 설계의 수를 상당히 증가시켰다. 이러한 개선들은 또한 제조 공정의 스케줄링, 제어 및 자동화 뿐 아니라, 설계 및 제조를 돕는 컴퓨팅 자원들 및 기타 정교한 장비를 효율적으로 이용할 것을 요구한다.

먼저, 제조와 관련하여, 집적 회로들 또는 마이크로칩들은, 전형적으로 몇 마이크로미터의 크기를 갖는 많은 구조들 또는 피쳐(feature)들을 포함하는 현대의 반도체 디바이스들로부터 제조된다. 일반적으로, 제조 공정은 일련의 제조 툴들을 통해 다수의 웨이퍼들을 처리한다. 제조하는 동안 반도체 기판에 물질층들이 부가되고, 이로부터 제거되고, 그리고/또는 처리됨으로써, 집적 회로들을 생성한다. 이러한 제조는 본질적으로 다음의 4개의 기본 동작들:

ㆍ반도체가 제조되는 웨이퍼에 여러가지 얇은 물질층들을 쌓거나 부가하고;

ㆍ부가된 층들의 선택된 부분들을 패터닝하거나 제거하고;

ㆍ부가된 층들의 개구부들을 통해 웨이퍼의 선택된 부분들에 특정량의 도펀트들을 도핑하거나 배치하고;

ㆍ물질들을 열 처리, 또는 가열 및 냉각하여, 처리되는 웨이퍼에서 원하는 효과들을 발생시키는 것을 포함한다.

단지 4개의 기본 동작들 만을 나타냈지만, 이러한 동작들은 특정 제조 공정에 따라 수백개의 다른 방법들로 결합될 수 있다. 예를 들어, 피터 밴 잔트(Peter Van Zant)의 "Microchip Fabrication A Practical Guide to Semiconductor Processing"(3d Ed. 1997 McGraw-Hill Companies, Inc.)(ISBN 0-07-067250-4)을 참조하라. 각 제조 툴은 4개의 기본 동작들중 1개 또는 그 이상을 수행한다. 전체 공 정에 따라 이러한 4개의 기본 동작들을 수행하여, 궁극적으로 반도체 디바이스들의 제조를 완료한다.

하지만, 이러한 반도체 집적 회로들을 제조하는 반도체 공장을 관리하는 것은 힘든 일이다. 반도체 공장("팹(fab)")은 복잡한 환경으로서, 여기에서는 많은 파트들(전형적으로, 40,000개 또는 그 이상의 웨이퍼들) 및 많은 파트 타입들(전형적으로, 100개 또는 그 이상의 파트 타입들)이 동시에 제조된다. 각 웨이퍼는 반도체 공장(또는 "팹")을 통해 이동하기 때문에, 이는 300개 이상의 처리 단계들을 거쳐야하는바, 이들중 많은 처리 단계들은 동일한 머신을 이용한다. 큰 공장은 이러한 웨이퍼 처리를 수행하기 위한 약 500개의 컴퓨터 제어 머신들을 구비할 수 있다. 컴퓨터화된 공장 제어 시스템의 도움을 받더라도, 팹을 통해 물질을 라우팅(routing)하고, 스케줄링하고, 추적하는 것은 어렵고 복잡한 작업이다.

반도체 칩들과 같은 제품들을 제조하기 위한 설비(facility)를 효율적으로 관리하기 위해서는, 제조 공정을 다양한 견지에서 모니터할 필요가 있다. 일반적으로, 예를 들어 가지고 있는 미가공 물질의 양, 처리중인 공정의 상태, 공정의 모든 단계에서의 머신들 및 툴들의 상태 및 유용성을 추적하는 것이 바람직하다. 가장 중요한 결정들중 하나는 어떠한 소정의 시간에 각 머신에서 어떤 로트(lot)가 실행되어야 하는 지를 선택하는 것이다. 또한, 제조 공정에 이용되는 대부분의 머신들은 기계적인 예방 관리(preventative maintenance)("PM") 및 장비 검증(equipment qualification)("Qual") 절차들 뿐 아니라, 규칙적으로 수행되어야 하는 기타 진단 및 재조정 절차들의 스케줄링을 필요로 한다. 이러한 절차들은 제조 공정 자체를 방해하지 않도록 수행되어야 한다.

이러한 문제에 대한 하나의 시도는 자동화된 "제조 실행 시스템("MES")을 구현한다. 이러한 자동화된 MES에 의해, 사용자는 제조 환경의 머신들 및 툴들 또는 "엔티티들"의 상태를 제한된 정도로 검사 및 조정할 수 있다. 또한, MES는 제조 공정을 통해 로트들 또는 처리중인 공정의 디스패칭(dispatching) 및 추적을 가능하게 함으로써, 자원들이 가장 효율적인 방식으로 관리될 수 있게 한다. 구체적으로, MES의 요구(prompt)에 응답하여, 사용자는 처리중인 공정 및 엔티티 상태에 관해 요구되는 정보를 입력한다. 예를 들어, 사용자가 특정 엔티티에 대해 PM을 수행할 때, 오퍼레이터는 PM("이벤트")의 성능을 MES 스크린에 기록(log)하여, 그 엔티티의 상태에 관해 MES 데이터베이스에 저장된 정보를 갱신한다. 또한, 엔티티가 복구 또는 유지를 위해 다운되어야 하는 경우, 오퍼레이터는 이 정보를 MES 데이터베이스에 기록함으로써, 이후 제조 준비 상태로 백업 기록이 될 때 까지 이 엔티티의 이용을 막는다.

MES 시스템들이 로트들 및 머신들을 충분히 추적할 수 있음에도 불구하고, 이러한 시스템들은 몇 개의 문제점들을 갖는바, 이들중 가장 명백한 것은 이들의 수동적인 특성, 사전 스케줄링의 부족, 및 상당히 자동화된 공장 동작들을 지원할 수 없다는 것이다. 현재의 MES 시스템들은 공장 상태를 모니터하고 정확한 시간에 액티비티(activity)들을 개시하는 데에 있어서 제조 직원들에게 크게 의존한다. 예를 들어, 웨이퍼 팹 기술자("WFT")가 적절한 MES 커맨드를 발행해야만, 로트의 공정이 시작된다. 그리고, 공정 이전에, WFT는 머신이 이용가능하게 될 때 이 머신에 서 로트가 이용될 수 있다는 충분한 사전 계획에 의해, 자동화된 물질 핸들링 시스템("AMHS")으로부터 로트를 회수하기 위한 MES 커맨드를 발행해야 한다. WFT가 충분히 빠르게 로트를 회수하지 못하거나, 이용가능한 가장 이른 시간에 공정을 개시하지 못한다면, 머신은 아이들(idle) 상태가 되고 제조에 악영향을 미치게 된다.

전형적인 자동화 MES에서의 이러한 타입의 문제점들은 제조 공정의 효율적인 동작에 있어서 WFT의 중요성을 강조한다. WFT들은 극히 중요한 많은 기능들을 수행한다. 이를 테면, WFT들은 자신들이 주목하고 시간이 허락될 때 디스패칭, 이송 및 처리를 개시한다. 이들은 다가오는 추가적인 로트들을 기다리는 것과 대비적으로 불완전한 배치(batch)를 실행할 것인지, 또는 로트들을 처리하는 대신 PM 또는 검증 절차들을 수행할 것인 지와 같은, 스케줄링 결정을 한다. WFT들은 비 부가가치의 MES 트랜잭션들을 수행하고, 수동적인 통상적인 공장 제어 시스템들을 이용한다. 이러한 환경에서, "수동"이라는 용어는 제어 시스템의 액티비티들이 스스로 시작 또는 개시되지 않고 WFT에 의해 개시되어야 함을 의미한다.

하지만, WFT들의 존재 또한 필연적으로 어떠한 비효율성을 가져온다. 전형적으로, 최고의 WFT의 작업과 최악의 WFT의 작업 간에는 큰 차이가 있다. WFT는 전형적으로 다수의 툴들 및 로트들의 처리를 동시에 모니터하기 때문에, 개별적인 로트 또는 툴에 집중하기가 어렵다. 또한, 현대의 제조 공정 흐름들의 규모 및 복잡성으로 인해, WFT가 업스트림의 액티비티들로부터 발생하는 다운스트림의 병목 또는 부족을 미리 예견하여 방지하는 것은 상당히 어렵다. WFT의 교대조 변경, 휴식 및 휴일 또한 비효율성 또는 머신의 아이들 시간을 야기시킴으로써, 제조 공정의 흐름에 악영향을 미친다. 자동화된 MES의 부족에 의해 WFT의 중요성이 확대되는 것과 마찬가지로, 이 WFT의 중요성에 의해 WFT의 비효율성이 또한 확대된다.

따라서, 오늘날의 웨이퍼 팹에서 이용되는 공장 제어 시스템들은 수동적이고 고도의 자동화를 가능하게 하지 못한다. 이러한 시스템들은, 공장의 상태를 모니터하고, 변경에 연속적으로 반응하고, 신속한 논리 결정을 하고, 시기 적절하게 공장 제어 액티비티를 개시 및 조정하는 데에 있어서 WFT들 및 다른 공장 직원에게 매우 의존한다. 이러한 WFT들은 공장 제어 시스템들에는 없는 액티브 요소를 제공하는 에이젼트(agent)들이다. 결과적으로, 매우 경쟁적인 반도체 산업에 있어서의 공장의 효율성은 이러한 사람 에이젼트들의 유용성, 생산성, 기술 수준 및 일관성에 상당히 의존한다. WFT들은 팹의 다양한 베이(bay)들에 위치하는 많은 툴들을 모니터하고 동작시켜야 한다. 이들은 툴들, 베이들, 물질 처리 시스템들 및 다수의 공장 제어 시스템들을 통해 멀티플렉싱을 수행해야 한다. 팹의 제조 램프들 및 보다 복잡한 공정들이 도입되면, 직원 또는 시스템의 성능을 증가시키지 않으면서 증가되는 복잡성 및 용량을 충족시키는 것이 더욱 어려워졌다. 업스트림 및 다운스트림 동작들, 툴 상태, 재공품(work in process) 및 자원 유용성에 대한 WFT들의 가시도가 제한된다.

하지만, 중요한 논리 결정들은 종종 이러한 제한되고 날짜가 있는 정보에 기초하는바, 이러한 정보는 공장 제어 시스템들에 의해 단지 부분적으로 제공된다. WFT들은 시스템들과 상호작용을 하고, 공장 이벤트들 및 상태 변경들을 모니터하며, 그리고 MES 기록(logging)과 같은 기타 비 부가가치 기능들을 수행하는 데에 상당량의 시간을 소비한다. 교대조 변경은 팹의 동작을 중단시키는데, 그 이유는 기술자들이 요구되는 모니터링 및 조정을 일시적으로 제공할 수 없기 때문이다. 기술자들의 최선의 노력에도 불구하고, 툴들의 이용에 어려움을 겪에 됨으로써, 순환 시간, 재고 수준, 공장의 생산 및 혼합(mix)을 포함한 기타 중요한 공장 메트릭(metric)들에 악영향을 준다. 베이내(intrabay) 물질 처리에 있어서, 새로운 300mm 웨이퍼 팹들에서 12인치 웨이퍼들을 이송해야하는 필요성으로 인해, 상당한 복잡성이 부가적으로 도입된다. 통상적인 공장 제어 시스템들은 이러한 수준의 상세한 스케줄링 및 실행 제어를 제공하지 못한다.

본 발명의 목적은 상기의 문제들중 하나 또는 모두를 해결하거나 또는 적어도 줄이는 것이다.

본 발명은 제조 공정 흐름의 약속들을 스케줄링하는 방법 및 장치를 개시한다. 이러한 방법 및 장치는, 커미트먼트 윈도우(commitment window) 내에 공정 윈도우가 떠있는(float) 약속들과; 공정 윈도우들이 소모 간격 및 공정 간격을 포함하고, 이러한 공정 윈도우들이 다른 약속들의 공정 간격과 겹칠 수 있는 약속과; 다양한 상태들로 유지되는 서로 다른 타입의 약속들을 포함하는 서로 다른 타입의 카렌다들의 이용과; 예약된 약속들에 의해 나타나는 명시적 제약(explicit constraint) 뿐 아니라, 예약된 약속들에 의해 나타나지 않는 암시적 제약(implicit constraint)에 의해 약속들이 제약을 받는 카렌다링 시스템과; 카렌다들을 관리하는 데에 이용되는 카렌다 조정 기술들과; 그리고 다수의 카렌다들을 통해 동기화된 방식으로 유지되는 대응하는 약속들을 포함한 많은 양상들을 포함한다.

본 발명은 첨부 도면과 함께 설명되는 하기의 상세한 설명을 참조하여 이해될 수 있는바, 도면에서 동일한 참조 부호들은 동일한 요소를 나타낸다.

도 1은 본 발명에 따라 구성되어 동작하는 공정 흐름의 일 특정 실시예의 일부를 개념적으로 도시한다.

도 2는 도 1의 컴퓨팅 디바이스들의 하드웨어 및 소프트웨어 아키텍쳐들의 선택된 부분들을 각각 부분 블록도의 형태로서 개념적으로 도시한다.

도 3은 도 1의 장치, 즉 반도체 제조 설비로부터의 공정 흐름의 일부 및 자원들의 소모에 대해 약속들을 스케줄링하는 방법의 일 특정 구현을 개념적으로 도시한다.

도 4A는 본 발명에 따라 유지 및 이용되는 예약된 약속들의 카렌다를 개념적으로 도시된다.

도 4B는 일 특정 실시예에서 이용되는 카렌다의 세분화된 계층 구조를 도시한다.

도 4C는 일부 약속들의 일부 부분들이 겹칠 수 있는 일 특정 실시예를 개념적으로 도시한다.

도 5는 스케줄링 에이젼트들과 카렌다들의 특성 및 상호 작용(interaction)의 선택된 양상들을 나타내는, 예약된 약속들의 다수의 카렌다들을 개념적으로 도시한다.

도 6은 예약된 약속들이 새로운 약속의 스케줄링을 수용(accommodate)하기 위해 어떻게 시프트되는 지를 개념적으로 도시한다.

도 7은 새로운 약속의 스케줄링을 수용하기 위한, 예약된 약속들의 "왼쪽 직렬 시프트"를 개념적으로 도시한다.

도 8A 및 도 8B는 빠른 시작 시간의 장점을 얻기 위한, 예약된 약속들의 변경을 개념적으로 도시한다.

도 9A는 객체 지향 프로그래밍 기술들을 이용하는 본 발명의 일 특정 구현에서의 약속 클래스의 계층 구조를 도시한다.

도 9B는 일 특정 구현에서의 약속들의 상태 변경을 나타낸다.

도 10A 및 도 10B는 예약된 약속들이 이전 예약 약속들의 예기치못한 긴 계속 기간(duration)을 수용할 수 있도록 변경되는 2개의 상황들을 개념적으로 도시한다.

도 11은 서로 다른 카렌다들 상의 대응하는 약속들을 동기적으로 유지하기 위해 일 특정 실시예에서 이용하는 통지 메커니즘을 도시한다.

본 발명은 많은 변형들 및 대안적인 형태들을 가질 수 있지만, 도면들에는 특정한 실시예들이 도시되어 있으며, 본원에서는 이에 대해 상세히 설명한다. 그러나, 이러한 특정한 실시예들은 본 발명을 개시된 형태들로 한정하지 않으며, 본 발명은 첨부된 청구항들에 의해 정의되는 본 발명의 정신 및 범위 내에 있는 모든 변형들, 등가들 및 대안들을 포함한다.

이하, 본 발명의 예시적인 실시예들에 대해 설명한다. 명확성을 위해, 본원에서는 실제 구현의 모든 특징들을 모두 설명하지는 않는다. 물론, 주목할 사항으로서, 이러한 모든 실제 실시예의 개발시, 예를 들어 시스템 관련 제약 및 사업 관련 제약을 따르는 것과 같이, 개발자의 특정한 목표들을 달성하기 위해서는, 구현 마다 특정한 다양한 결정들이 이루어져야 하는바, 이는 구현 마다 달라질 것이다. 또한, 주목할 사항으로서, 이러한 개발 노력은 복잡하고 시간 소모적이지만, 그럼에도 불구하고 본원의 개시의 이득을 갖는 당업자들에게는 일상적인 작업이다.

도 1은 본 발명에 따라 구성되어 동작하는 공정 흐름(100)의 일 특정 실시예의 일부를 개념적으로 도시한다. 이 공정 흐름(100)은 반도체 디바이스들을 제조한다. 하지만, 본 발명은 다른 타입의 제조 공정들에도 적용될 수 있다. 따라서, 상기 설명한 공정 흐름(100)에서, 웨이퍼들(135)들의 로트들(130)은 보다 일반적으로 "워크 피스들(work pieces)"이라 칭한다. 공정 툴들(115) 및 그 위에서 수행되는 어떠한 공정 동작들이 반드시 모든 실시예들의 반도체 디바이스들의 제조와 관련될 필요는 없다. 하지만, 명확성을 위해 그리고 본 발명의 이해를 위해, 반도체 제조와 관련된 용어는 도시된 실시예들의 환경에서 본 발명을 설명하는 데에 있어서 유지된다.

공정 흐름(100)의 도시된 부분은 2개의 스테이션들(105)을 포함하는바, 각 스테이션(105)은 공정 툴(115)과 통신하는 컴퓨팅 디바이스(110)를 포함한다. 이 스테이션들(105)은 통신 링크들(120)을 통해 서로 통신한다. 도시된 실시예에서, 컴퓨팅 디바이스들(110) 및 통신 링크들(120)은 보다 큰 컴퓨팅 시스템, 예를 들어 네트워크(125)의 일부를 포함한다. 도 1의 공정 툴들(115)은 웨이퍼들(135)의 로트들(130)을 공정 처리하는바, 이들이 궁극적으로 집적 회로 디바이스들이 된다.

도 2는 본 발명에 따라 프로그램되고 동작하는 컴퓨팅 디바이스들(110)의 하드웨어 및 소프트웨어 아키텍쳐들의 선택된 부분들을 도시한다. 하드웨어 및 소프트웨어 아키텍쳐의 일부 양상들(예를 들어, 개별적인 카드들, 기본적인 입/출력 시스템("BIOS"), 입/출력 구동기들, 등)은 도시되지 않았다. 이러한 양상들은, 명확성을 위해 그리고 본 발명을 애매하게 하는 것을 막기 위해 생략되었다. 하지만, 본원의 개시의 이득을 갖는 당업자라면, 컴퓨팅 디바이스들(110)의 소프트웨어 및 하드웨어 아키텍쳐들이 도 2에서 생략된 이러한 많은 일상적인 피쳐들을 포함할 것이라는 것을 알 수 있을 것이다.

도시된 실시예에서, 컴퓨팅 디바이스(110)는 UNIX 기반 운영 체제(200)를 이용하는 워크스테이션이지만, 본 발명은 이에 한정되지 않는다. 컴퓨팅 디바이스(110)는 실질적으로, 노트북 컴퓨터, 테스크탑 컴퓨터, 미니 컴퓨터, 메인프레임 컴퓨터 또는 슈퍼컴퓨터와 같은 모든 타입의 전자 컴퓨팅 디바이스로 구현될 수 있다. 일부 대안적인 실시예들에서, 컴퓨팅 디바이스(110)는 심지어 공정 툴(115)에 내장되는 프로세서 또는 제어기가 될 수 있다. 본 발명은 또한 UNIX 기반 운영 체제에 한정되지 않는다. 대안적인 운영 체제들(예를 들어, Windows^TM 기반, Linux^TM 기반 또는 디스크 운영 체제("DOS") 기반)이 또한 이용될 수 있다. 본 발명은 컴퓨팅 디바이스(110)의 어떠한 특정한 구현의 이러한 양상들에 의해 제한되지 않는다.

컴퓨팅 디바이스(110)는 또한 버스 시스템(215)을 통해 저장 장치(210)와 통신하는 프로세서(205)를 포함한다. 저장 장치(210)는 전형적으로 하드 디스크(미도시) 및 랜덤 액세스 메모리("RAM")(미도시)를 적어도 포함한다. 일부 실시예들에서, 컴퓨팅 디바이스(110)는 또한 광 디스크(230) 또는 플로피 전자기 디스크(235)와 같은 제거가능한 저장 수단, 또는 자기 테이프(미도시) 또는 집 디스크(zip disk)(미도시)와 같은 다른 어떠한 형태의 저장 수단을 포함할 수 있다. 컴퓨팅 디바이스(110)는 모니터(240), 키보드(245) 및 마우스(250)를 포함하는바, 이들이 협력하여, 관련 사용자 인터페이스 소프트웨어(255)와 함께 사용자 인터페이스(260)를 구성한다. 도시된 실시예의 사용자 인터페이스(260)는 그래픽 사용자 인터페이스("GUI")이지만, 이것이 본 발명의 실행에 반드시 필요한 것은 아니다.

프로세서(205)는 당업계에 알려져있는 어떠한 적절한 프로세서가 될 수 있다. 예를 들어, 이 프로세서는 범용 마이크로프로세서 또는 디지털 신호 처리기("DSP")가 될 수 있다. 도시된 실시예에서, 프로세서(205)는 어드밴스트 마이크로 디바이시즈 인코포레이티드("AMD")로부터 상업적으로 입수할 수 있는 애슬론^TM 64 비트 프로세서이지만, 본 발명은 이것에만 한정되지 않는다. 대안적으로, 선 마이크로시스템즈의 64 비트 UltraSPARC^TM 또는 32 비트 microSPARC^TM, 인텔사의 이타니움^TM 또는 펜티엄^TM-클래스 프로세서스들중 어느 것, 및 컴팩사의 알파^TM 프로세서가 이용될 수 있다.

도시된 실시예에서, 각 컴퓨팅 디바이스(110)는 저장 장치(210)에 상주하는 소프트웨어 에이젼트(265)를 포함한다. 주목할 사항으로서, 이 소프트웨어 에이젼트(265)는 컴퓨팅 디바이스(110)가 아닌, 공정 흐름(100)의 적소에 상주할 수 있다. 이 소프트웨어 에이젼트(265)의 위치는 본 발명의 실행에 중요하지 않다. 또한 주목할 사항으로서, 소프트웨어 에이젼트(265)의 위치가 중요하지 않기 때문에, 일부 컴퓨팅 디바이스들(110)은 그 내에 상주하는 많은 소프트웨어 에이젼트(265)를 가질 수 있고, 다른 컴퓨팅 디바이스들(110)은 어떠한 소프트웨어 에이젼트도 갖지 않을 수 있다. WORKSTREAM^TM과 같은 자동화된 MES(270)의 적어도 일부가 적어도 하나의 컴퓨팅 디바이스(110) 상에 상주한다.

상기 설명한 도 1로 돌아가서, 컴퓨팅 디바이스(110)는 또한 통신 링크(120)를 통한 접속에 의해 보다 큰 컴퓨팅 시스템(125)의 일부가 될 수 있다. 이러한 구현에서의 예시적인 컴퓨팅 시스템들은 국부 영역 네트워크("LAN"), 광역 네트워크("WAN"), 시스템 영역 네트워크("SAN"), 인트라넷, 또는 심지어 인터넷을 포함한다. 컴퓨팅 시스템(125)은 네트워크화된 클라이언트/서버 아키텍쳐를 이용하지만, 다른 실시예들은 피어 투 피어 아키텍쳐(peer-to-peer architecture)를 이용한다. 따라서, 일부 대안적인 실시예들에서, 컴퓨팅 디바이스(110)는 서로 직접 통신할 수 있다. 통신 링크(120)는, 예를 들어 무선, 동축 케이블, 광섬유, 또는 꼬임쌍 와이어 링크가 될 수 있다. 어느 하나를 이용하는 실시예들에서, 컴퓨팅 시스템(125) 및 통신 링크(120)는 구현마다 특정되며, 종래에 알려진 어떠한 적절한 방법으로 구현될 수 있다. 이 컴퓨팅 시스템(125)은 종래에 알려진 어떠한 적절한 통신 프로토콜, 예를 들어 전송 제어 프로토콜/인터넷 프로토콜("TCP/IP")을 이용할 수 있다.

이제, 도 1, 2 모두를 참조하여, 집합적으로, 소프트웨어 에이젼트들(265)은 제조 공정을 통해 웨이퍼들(135)의 로트들(130)을 효율적으로 스케줄링하고 제어한다. 이 소프트웨어 에이젼트들(265)은 각각 어떠한 "제조 도메인 엔티티", 예를 들어 로트(130), 공정 툴(115)을 나타낸다. 이러한 제조 도메인 엔티티들중 일부, 예를 들어 로트들(130)은 "소비자(consumer)"이다. 즉, 이들은 공정 자원들을 소비한다. 이러한 제조 도메인 엔티티들중 일부는 "제공자(provider)"이다. 즉, 이들은 소비될 공정 자원들을 제공한다. 예를 들어, 공정 툴(115)은 공정 흐름(100)에서 소비될 수 있는 자원, 예를 들어 공정 시간을 나타낸다. 공정 툴(115)은 웨이퍼들(135)의 어떠한 일부분을 제조하는 데에 이용되는, 즉 웨이퍼들(135)의 층을 쌓고, 패터닝하고, 도핑하거나 또는 열처리하는 데에 이용되는 제조 툴이 될 수 있다. 또는, 공정 툴(115)은 공정 흐름(100)의 다양한 파트의 성능을 평가하는 데에 이용되는 계측 툴이 될 수 있다. 주목할 사항으로서, 때때로, 일부 제조 도메인 엔티티들은 어떠한 소정 시간에서의 공정 흐름(100)에서의 자신들의 역할에 따라, 어떤 환경에서는 제공자로서 분류되고 다른 환경에서는 소비자로서 분류될 수 있다.

따라서, 일부 소프트웨어 에이젼트들(265)은 공정 흐름(100)을 통해 로트들(130)을 시기 적절하고 효율적으로 나아가게 함에 있어서, 소비자들, 예를 들어 로트들(130) 또는 PM 절차들(미도시)의 이득(interest)을 대리한다. 일부 소프트웨어 에이젼트들(265)은 공정 흐름(100)을 통해 로트들(130)을 시기 적절하고 효율적으 로 나아가게 하는 데에 있어서 자원 처리에 대한 소비자들의 요구를 충족시키는 것에 관련하여 제공자들, 예를 들어 공정 툴(115)과 같은 머신들의 이득을 대리한다. 각 제조 도메인 엔티티는 적어도 하나의 대응하는 소프트웨어 에이젼트(265)를 갖기 때문에, 소프트웨어 에이젼트들(265)은 웨이퍼들(135)의 로트들(130)의 연속적인 처리를 위해 다수의 자원들을 할당(assess)할 수 있다. 공정 흐름(100)을 통해 로트들(130)을 스케줄링하고 제어하는 책임의 일부로서, 소프트웨어 에이젼트들(265)은 웨이퍼들(135)의 로트(130)의 연속적인 처리를 위한 공정 자원들의 할당을 자신들끼리 협상한다. 그런 다음, 소프트웨어 에이젼트들(265)은 자신들의 자원들을 할당하는바, 궁극적으로 이러한 자원들은 로트들(130)이 공정 흐름(100)을 통해 이동할 때 소비된다.

도시된 실시예에서, 소프트웨어 에이젼트들(265)은 지능적이고 상태 인식(state aware)형이다. 또한, 소프트웨어 에이젼트들(265)은 특정한 목적을 갖기 때문에, 이를 달성하기 위해 자발적으로 행동을 개시한다. 이러한 소프트웨어 에이젼트들(265)은 객체 지향 프로그래밍("OPP") 환경에서 구현되지만, 본 발명은 객체 지향 이외의 기술들을 이용하여 구현될 수 있다. 이러한 소프트웨어 에이젼트들(265)의 행동은 비교적 단순하고, 스크립트, 룰 및 외부 특성에 의해 영향을 받는다. 이러한 행동은, 할당된 로트 듀 데이트의 달성, 소정의 품질 레벨의 달성, 머신 이용의 최대화 및 기회적인 예방 관리의 스케줄링 등의 선택된 목적들을 달성하도록 설계된다. 이러한 목적들을 추진함에 있어서, 소프트웨어 에이젼트들(265)은 MES(270)와 인터페이스하며, 기존의 다른 공장 제어 시스템들(미도시)과 통합된다. 본 개시의 이득을 갖는 당업자라면, MES(270) 및 공장 제어 시스템의 구조 및 구성에 따라, 이러한 인터페이스 및 통합이 이루어지는 방식이 구현마다 특정하다는 것을 알 수 있을 것이다.

집합적으로, 소프트웨어 에이젼트들(265)은, 각 로트(130)에 대해, 특정한 적격의 공정 툴(115) 상에서의 (이송 및 자원을 포함하는) 1개 이상의 동작들을 사전에 스케줄링하는바, 이에 대해서는 하기에서 더 설명한다. 예를 들어, 도시된 실시예에서, 소프트웨어 에이젼트들은 공정 툴들(115)에 대한 예방 유지("PM") 및 검증 테스트("Qual") 뿐 아니라, 이러한 공정 툴들(115) 상에서의 공정에 대해 로트들(130)을 스케줄링한다. 이러한 스케줄링은 접근하는 로트(130)를 기다리는 것에 대조적으로 불완전한 배치를 실행시키는 등의 최적화 결정(optimizing decision)을 수행하고, 사양을 충족시키기 위해 기회(opportunistic) PM 절차들 또는 Qaul들을 스케줄링하는 것을 포함한다. 소프트웨어 에이젼트들(265)은 로트 이송 및 공정과 같은 액티비티들을 스케줄링하고, MES 트랜잭션들을 수행하며, 공정 및 이송을 모니터하고, 그리고 스케줄링된 액티비티들 또는 스케줄링되지 않은 액티비티들로부터의 이탈(deviation)에 반응한다.

일 특정 실시예에서, 스케줄링 결정들은 "CNP(contract net negotiation protocol)"에 기초하여 소프트웨어 에이젼트들(265)에 의해 이루어진다. 하지만, 주목할 사항으로서, 본 발명과 관련하여 다른 스케줄링 접근(approach)들이 구현될 수 있다. 자원들의 할당을 위해 CNP의 구현을 촉진시키기 위해, 약속 커미트먼트 윈도우 개념 및 강력한 카렌다 조정 루틴들을 이용하여 부동 약속 모델 접근을 구 현한다. 각 스케줄링 에이젼트(265)는 각 엔티티, 예를 들어 공정 툴(115), 로트(130), PM, Qual 또는 자원에 대한 약속들을 예약하는 "카렌다"를 유지한다. 소프트웨어 에이젼트들(265)의 스케줄링 결정들을 통해 스케줄링된 약속들은 소비자의 카렌다 및 제공자의 카렌다 모두에 "예약"된다. 이러한 약속은 스케줄링된 작업이 달성될 것으로 기대되는 계속 기간 동안 예약된다.

도 3은 도 1에 도시한 반도체 제조 공정 흐름(100)의 공정 약속들에 대한 협상 및 스케줄링에 대한 일 특정 구현(300)을 도시한다. 이 공정 흐름(300)은 스케줄링을 위해 CNP를 실시한다. 보다 특정하게, 이 공정 흐름(300)은:

ㆍ 소비자인 로트(130)를 대리하는 로트 스케줄링 에이젼트("LSA")(305);

ㆍ 동작하는 환경에 따라 소비자 및 제공자 모두가 되는 공정 툴들(115)을 대리하는 머신 스케줄링 에이젼트("MSA")(310);

ㆍ 제공자인 레티클(320)을 대리하는 자원 스케줄링 에이젼트("RSA")(318); 및

ㆍ 소비자들인 PM들 및 Qual들(미도시)을 대리하는 PM 스케줄링 에이젼트("PMSA")를 포함한다.

로트(130), 공정 툴(115), 레티클(320), PM들 및 Qual들 또한 대응하는 "공정" 에이젼트들(미도시)을 갖는바, 스케줄링 에이젼트들은 스케줄링된 액티비티가 실행될 시간이 되면 이 "공정" 에이젼트들에게 제어 신호(control)를 전달한다. LSA(305), MSA(310), RSA(315), PMSA(318) 및 공정 에이젼트들은 도 2의 소프트웨어 에이젼트(265)에 대한 일 특정 구현일 뿐이다.

각 스케줄링 에이젼트들(305, 310, 315 및 318)은 각각의 카렌다(385, 370, 345 및 387)를 유지하고 이용한다. 보다 특정하게:

ㆍ LSA(305)는 로트 카렌다(385)를 유지하고;

ㆍ MSA(310)는 머신 카렌다(370)를 유지하고;

ㆍ RSA(315)는 자원 카렌다(345)를 유지하고; 그리고

ㆍ PMSA(318)는 PM 카렌다(387)를 유지한다.

카렌다들에 예약된 약속들의 타입은 스케줄링 에이젼트(265)가 대리하는 엔티티의 특성에 의존할 것이다. 예시된 실시예에서, 예를 들어 스케줄링 에이젼트들(305, 310, 315 및 318)은 각각 카렌다들(385, 370, 345 및 387)에 표 1에서 설명되는 약속들의 타입들을 예약한다. 이러한 약속 타입들 각각에 대해서는 표 1에 이어서 하기에서 보다 상세히 설명한다.

본 개시의 이득을 갖는 당업자라면, 공정 툴(115)이 공정 흐름(100)에 다시 들어가기 전에, 어떠한 PM들이 팔로우업(follow-up) Qual들의 실행을 호출한다는 것을 알 수 있을 것이다. 이러한 팔로우업 Qual들은, 예를 들어 PM이 공정 툴(115)의 교정(calibration)을 망치지 않도록 하는 등을 보장하도록 의도된다. 하지만, 다른 Qual들은 "독립적인(stand-alone)" Qual들이다. 즉, 이들은 PM의 발생에 의해 호출되지 않는다. 독립적인 Qual들과 대조적으로, 팔로우업 Qual들은 PM의 실행에 의해 결정되는 시간에 수행되어야 한다. 보다 특정하게, 팔로우업 Qual들은 PM이 이들을 호출한 후에, 하지만 어떠한 다른 종류의 약속 이전에 수행되어야 한다.

이것이 일어날 수 있도록 돕기 위해, 예시된 실시예는 팔로우업 Qual들을 이 들을 호출하는 PM의 일부로서 처리한다. 따라서, PM이 스케줄링될 때, 팔로우업 Qual들은 PM을 완료할 때에 수행되는 것으로서 자동적으로 스케줄링된다. 팔로우업 Qual들은 머신 및 MP 카렌다들(370, 387) 상에 개별적인 약속들에 의해 나타내지 않는데, 그 이유는 이러한 팔로우업 Qual들이 이들을 호출하는 PM의 일부로서 고려되기 때문이다. 스케줄링된 PM 약속들의 계속 기간은 PM 자체 뿐 아니라, 이것이 호출하는 어떠한 팔로우업 Qual들에 대해서도 충분하다. 따라서, Qual 약속들은 독립적인 Qual들에 대해서만 머신 및 PM 카렌다들 상에 스케줄링된다.

LSA(305)는 자신이 대리하는 로트(130)를 스케줄 상에 유지하고자 노력한다. MSA(310)는 자신이 대리하는 공정 툴(115)의 이용을 최대화하고자 노력한다. 유사하게, RSA(315)는 레티클(320)의 이용을 최대화하고자 노력한다. 주목할 사항으로서, RSA(315)는 다른 구현들에서 다른 타입의 자원들, 예를 들어 머신 로딩 자원, 더미 웨이퍼들, 카세트들, 웨이퍼 팹 기술자들, 유지 기술자들 등을 대리할 수 있다. PMSA(318)는, 특히 공정 툴(115)에 대해 PM들 및 Qual들을 기회적으로 스케줄링하고자 시도한다. 다양한 에이젼트들(305, 310, 315 및 318)이 이를 행하는바, 이 에이젼트들은 이들이 제공하는 가격, 또는 이들이 충족할 필요가 있거나 유지하기를 원하는 스케줄들에 따라 서비스에 대해 지불하는 예산을 조정함으로써 약속 협상의 환경에서 수행한다.

보다 특정하게, 로트(130)는 전형적으로 다수의 장비 부분들, 예를 들어 공정 툴들(115)과 협상한다. LSA(305)는 공정 툴에 의해 제공되는 시간 슬롯을 찾고자 시도하는바, 이에 의해 로트(130)는 자신의 듀 데이트를 충족시키고 다음 병목 머신 스테이션을 적절한 시간에 공급할 수 있게 된다. 동시에, MSA(310)는 공정 툴(115)의 이용을 최적화하는 방식으로 처리하기 위한 로트들(130)을 얻고자 시도한 다. 전체적으로, MSA(310)의 목적은 그의 각 공정 툴(115)의 전체적인 이용을 최대화하고, 로트들(130)의 상대적인 우선순위를 고려하며, 셋업 또는 레시피 변경을 감소시키며, 그리고 배치 크기를 최적화하는 것이다. 이와같이 에이젼트들이 협동하여 상호 작용을 하게 함으로써, 지정된 시간 윈도우 내에서 특정한 공정 툴(115)에 대해 로트(130)를 스케줄링할 수 있게 된다.

일반적으로, LSA(305)는 요구되는 제조 동작을 수행할 수 있는 공정 툴들(115)을 대리하는 모든 MSA들(310)에게 "비드 요구" 메세지(325)를 발행함으로써 협상을 시작한다. 이 시점에서, MSA(310)는 제공자의 역할을 하는데, 그 이유는 공정 툴(115)이 자원들, 즉 공정 시간을 제공하고 있기 때문이다. 가능한 각 공정 툴(115)에 대한 MSA(310)는, 비드 요구 메세지(325)를 수신하게 되면, 가능한 비드를 식별하고, 이것이 작업을 수행하기 위해서는 자격있는 레티클(320)을 필요로 한다는 것을 인식하고, 모든 가능한 자원들의 RSA들(315), 즉 자격있는 레티클(320)에게 자기 자신의 비드 요구 메세지(330)를 발행한다. 이 시점에서 MSA(310)는 제공자에서 소비자로 바뀌는데, 그 이유는 공정 툴(115)이 공정 자원들, 즉 레티클(320)에 대한 시간을 소모하고 있기 때문이다. 자격있는 레티클(320)을 대리하는 RSA(315)는 1개 또는 그 이상의 비드들(335)을 서미트(submit)하는바, MSA(310)는 이중 하나를 선택하여 자신의 비드(360)에 포함시킨다. 필요한 자원들을 식별한 MSA(310)는 공정 자원들의 제공자로서의 자신의 역할로 되돌아간다. MSA(310)에 의해 다른 가능한 비드가 식별된다면, 이는 적절한 RSA들(315)로부터 비드들을 다시 한번 요구한다.

가능한 공정 툴(115)을 대리하는 각 MSA(310)는 상기 비드 요구 메세지(325)를 발행했던 LSA(305)에게 1개 또는 그 이상의 비드들(360)을 서미트한다. LSA(305)는 모든 MSA들(310)로부터의 모든 비드들(360) 중에서 1개의 비드(360)를 선택한다. 그러면, LSA(305)는 선택된 비트(360)를 서미트한 MSA(310)에게 칸트랙트(contract)(365)를 준다. MSA(310)는 그의 머신 카렌다(370)를 체크하여, 비드가 여전히 유효한지의 여부를 결정한 다음, 유효하다면, 선택된 비드(335)를 서미트했던 레티클(320)에게 칸트랙트(340)를 준다. RSA(315)는 그의 자원 카렌다(345)를 체크하여, 비드가 여전히 유효한 지를 확인하며, 그리고 자기 자신의 자원 카렌다(345) 상에 약속(375a)을 스케줄링한다. 이후, RSA(315)는 "비드 확인" 메세지(355)로 칸트랙트를 확인하고, "자원" 비드(335)를 제공했던 RSA(315)와 관련하여, MSA(310)는 그의 머신 카렌다(370) 상에 약속(375b)을 스케줄링한다. 이후, MSA(310)는 "확인된 비드" 메세지(380)를 LSA(305)에게 보낸다. 그러면, LSA(305)는 자기 자신의 로트 카렌다(385) 상에 대응하는 약속(375c)을 스케줄링한다. 약속들(375a, 375b 및 375c)에 대한 시간에 도달하면, 스케줄링 에이젼트들(305, 310 및 315)은 자신들의 각 공정 에이젼트들(미도시)에게 제어 신호를 전달한다.

주목할 사항으로서, 액티비티는 1개 이상의 자원 타입을 요구할 수 있다. 이에 따라, MSA(310)는 몇 개의 서로 다른 타입의 RSA들(315)과 협상한다. 예를 들어, 로트 공정은 레티클(320) 뿐 아니라, 빈 캐리어(미도시) 및 WFT(미도시)를 필요로 할 수 있다. 따라서, MSA(310)는 RSA(315) 및 레티클(320)에 대해 설명한 협상을 몇번 반복할 수 있다.

여전히 도 3을 참조하여, 상기에서 간단히 설명한 "CNP"에 대해 보다 상세히 설명한다. 상기 언급한 바와 같이, 비딩 과정(bidding process)은, LSA(305)가 모든 가능한 공정 툴들(115)로부터 비드들(360)을 요구할 때에 시작된다. 본 개시의 이득을 갖는 당업자라면 알 수 있는 바와 같이, 공정 툴(115)이 로트(130)가 들어가고자 하는 공정 동작을 수행할 수 있는 지의 여부에 대해 우선적으로 성능이 예측된다. LSA(305)가 가능한 공정 툴들(115)로부터 비드(360)를 요구하면, 이는 비드 요구(325)에 하기의 정보:

ㆍ 이송 시작 시간("TST"), 또는 마지막 (이전) 머신 또는 현재 위치로부터 이송을 시작하는 가장 이른 시간;

ㆍ 스케줄링될 공정 동작("PO") 및 공정 단계("PS");

ㆍ 소비자의 가장 늦은 배달 시간("LDT_C"), 또는 로트(130)에 대해 수용할 수 있는 마지막 완료 시간;

ㆍ 마지막 위치, 또는 "소스" 위치, 즉 소비자가 공정 툴(115)로 이송될 위치의 아이덴티티; 및

ㆍ 비드를 요구하는 로트(130)의 아이덴티티를 포함한다.

일부 실시예들에서, 소비자 에이젼트들은 제공자 에이젼트에게 예산 계산기를 제공한다. 이 예산 계산기에 의해, 제공자 에이젼트는 제공자의 카렌다 상에 이전에 예약된 다른 약속들에 대한 소비자의 우선순위를 결정할 수 있다.

일 특정 구현에서, LSA(305)는 LDT_C의 초기값을 로트가 스케줄에서 늦어지는 시간으로서 계산한다. 대응하는 LDT_C는 다음의 방정식을 이용하여 결정된다:

여기서, DueDate ≡로트(130)가 공정 흐름(300)을 완료하기로 예정된 시간이고;

RPT ≡나머지 모든 공정 동작들의 사이클 시간들의 합이고;

β≡로트 우선순위에 기초한 사이클 시간 압축 팩터이고;

CRA ≡기대되는 사이클 시간에 비례하는 CR 조정에 대한 구성가능한 제어 A이고;

CRB ≡공정 흐름(300)의 끝 가까이에서의 붕괴에 대처하기 위한 CR 조정에 대한 구성가능한 제어 B이고;

DFLTLD ≡ 로트(130)에 대해 기대되는 안내 시간(lead-time), 즉 기대되는 총 사이클 시간이고; 그리고

TargetCR ≡LDT_C에 대한 타겟 임계비(Critical Ratio)로서, 그 초기값이 로트 우선순위 및 1.0으로의 디폴트에 의해 설정되는 구성가능한 변수이다.

하지만, LDT_C에 대한 이러한 초기값이 반드시 비드들의 요구와 함께 전달되는 값이 될 필요는 없다.

가능한 공정 툴들(115)에 대한 MSA(310)는 비드들(360)을 공식화한다. 상기 언급한 바와 같이, MSA(310)는 머신 카렌다(370)를 유지함으로써, 그의 약속들을 추적한다. 비드 요구 메세지(325)를 수신하면, MSA(310)는 머신 카렌다(370) 상에서 로트(130)를 약속에 대해 스케줄링할 수 있는 빈곳(opening)을 찾는다. "약속"은 "공 정 윈도우"("PW")를 갖는다. 이러한 공정 윈도우는 약속 시작 시간("TS")과 약속 종료 시간("TE")에 의해 정의되는 서비스들을 제공하기 위한 추정된 계속 기간의 시간 간격이다. 부동 약속 접근에서, 대부분의 약속들을 그 내에서 공정 윈도우(PW)가 부동이 되는 "커미트먼트 윈도우"("CW")를 갖는다. 이 "커미트먼트 윈도우"는 서비스가 제공될 시간 간격이다. 이러한 커미트먼트 윈도우(CW)의 시작 시간은 소비자가 서비스를 이용할 수 있게 될 때 가장 이른 시작 시간("EST")에 의해 정의된다. 커미트먼트 윈도우의 종료 시간은 서비스에 대한 제공자의 가장 늦은 배달 시간("LDT_P")에 의해 정의된다. 주목할 사항으로서, LDT_P는 로트(130)에 대한 LSA(305)로부터의 비드 요구 메세지(325)의 LDT_C와 다를 수 있다. 도시된 실시예에서, MSA(305)는 유효 비드(360)의 위치를 정하기 위해, 필요한 경우, 로트(130)에 의해 지정되는 LDT_C의 범위를 넘어 서치할 수 있다. 이것이 일어나는 경우, MSA(310)는 비드의 LDT_P를 결과적인 약속의 TE로 설정한다. 각 약속은 공정 윈도우(PW) [TS, TE] 및 커미트먼트 윈도우(CW) [EST, LDT_P] 정보 모두를 저장할 것이다. 이후, 예시된 실시예에서, 이 정보는 비드들(360)을 공식화하는 데에 이용된다.

보다 특정하게, 도 4A는 다수의 소비자들(도시된 예에서는, 웨이퍼들(135)의 로트들(130))의 공정 툴(115)에 대한 약속들에 관한 정보를 저장하는 카렌다(400)를 개념적으로 도시한다. 도 4A에서, 공정 툴(115)에 대한 MSA(310)는 로트들(Lot₁-Lot₄)에 대해 예약된 약속들(APP₁-APP₄)을 각각 갖는다. 따라서, Lot₁-Lot₄에 대한 약속 정보는 다음과 같다:

약속들(APP₁-APP₄)은 커미트먼트 윈도우(CW₁-CW₄) 내의 공정 윈도우들을 나타낸다. 주목할 사항으로서, 도시된 실시예에서, 몇 개의 커미트먼트 윈도우들은 겹치지만, 어떠한 약속도 겹치지 않는다. 하지만, 대안적인 구현들에서는, 하기에서 더 설명하는 바와 같이, 항상 이와 같지는 않다.

도 3을 다시 참조하여, 가능한 공정 툴들(115)에 대한 MSA들(310)은 다음으로 비드들(360)을 LSA(305)에게 서미트한다. 이 비드들(360)은 "비드 정보"를 포함하는바, 이는 구현에 따라 달라진다. 이러한 비드 정보는, 예를 들어 공정 시간 간격 및 비드(360)를 서미트하는 공정 툴(115)의 아이덴티피케이션 만을 포함할 수 있다. 도시된 실시예에서, 비드 정보는 적어도:

TS ≡상기 정의한 바와 같이, 약속 시작 시간;

TE ≡상기 정의한 바와 같이, 약속 종료 시간;

EST ≡공정에 대한 가장 이른 시작 시간, 즉 로트(130)가 공정 툴(115)에서의 공정 준비가 되도록 커미트될 수 있는 가장 이른 시간; 및

LDT_P ≡상기 정의한 바와 같이, 로트에 의해 요구되는 LDT_C 보다 늦거나 그렇지 않으면 다를 수 있는 가장 늦은 배달 시간을 포함한다.

하지만, 비드 비용과 같은 부가 정보가 또한 포함될 수 있다. 도시된 실시예에서, 공정 툴(115)은 로트(130)에 의해 요구되는 LDT_C 이전에 완료되는 약속의 위치를 정하지 못하는 경우, LDT_P를 조정할 수 있다. 이는 늦은 TS, 셋업의 부가, 또는 둘 모두에 의한 것일 수 있다.

EST의 결정은 약속의 타입에 의존한다. 약속들의 대부분의 타입들은 스태틱 EST ("EST_static")를 갖는다. 이 경우, 스태틱 EST는, 시간 기반 PM이 시작할 수 있는 가장 이른 시간과 같은, 액티비티가 시작할 수 있을 때의 고정된 시간이다. 하지만, 약속들의 어떠한 타입들은 EST를 다이내믹하게 계산한다. 이러한 타입의 약속들은 로트 약속들, 로트 공정 약속들, 로트 로드 약속들, 자원 로드 로트 약속들 및 배치 약속들을 포함한다. 다이내믹 EST의 기본적인 계산은 다음과 같다:

EST = max(T + RTT,EST_static)

여기서,

T ≡ max(T_now,TST)이고;

T_now ≡ 현재 시간이고;

TST ≡ 이송 시작 시간이고;

RTT ≡ 나머지 이송 시간(TST와 로트 약속 간의 모든 이송 시간들의 합)이고; 그리고

EST_static ≡ 스태틱 EST이다.

하지만, 도시된 실시예에서, 이러한 기본적인 계산은 어떠한 환경들에서 응용에 따라 달라진다. 특히, 공정이 시작되기 전에 로트(130)가 공정 툴(115) 상에 로드될 때 보다 정확한 결정을 할 수 있도록, 로딩 제약(loading constraint)들이 적용된다. 이러한 제약들로는 다음이 있다:

ㆍ LST ≡로딩 시작 시간;

ㆍ RLT ≡남아있는 로딩 시간; 및

ㆍ ELT ≡본질적으로 상기 설명한 기본적인 결정(즉, EST)인 가장 이른 로딩 시간.

이러한 로딩 제약들은 로트 약속들, 로트 공정 약속들 및 자원 챠지 로트 약속들의 속성(attribute)들이다. 하기의 언로딩 제약들은 머신/자원 카렌다(370, 345) 상의 PM, Qual, 다운타임, 머신 배치 및 자원 챠지 배치 약속들의 속성들이다:

ㆍ UST ≡언로딩 시작 시간; 및

ㆍ RUT ≡나머지 언로딩 시간.

이러한 언로딩 제약들이 설정되면, 각 약속이 제약을 받게 될 것이며, 이에 따라 그 시프팅 능력(하기에서 보다 상세히 설명됨)은 이전 공정에 포함된 로트들(130)이 언로드될 수 있도록 자신과 이전 배치 공정 약속 간에 요구되는 시간 간격을 유지할 것을 요구한다. 이는 다이내믹 EST에 의해 구현되지 않는데, 그 이유는 이것이 어려운(hard) 제약이 아니기 때문이다. 머신 카렌다(370)는 UST 및 RUT를 이용하여, 시프트가 유효한 지의 여부를 결정한다. 언로딩 제약들을 갖는 약속은, 이전 약속의 로트들(130)이 완료된 언로딩 상태를 가질 때 까지 공정을 시작할 수 없다.

다이내믹 EST 계산으로 돌아가서, 로트 약속에 대해:

ㆍ 어떠한 로딩도 필요하지 않으면, EST = ELT이고;

ㆍ 로딩이 필요하지만, 아직 시작하지 않았으면, EST = ELT + RLT이고;

ㆍ 로딩을 시작했지만, 완료되지 않았으면, EST = max(ELT, LST)이고;

ㆍ 일단 로딩이 완료되면, EST = T_now이다.

로트 공정 약속 또는 자원 챠지 약속에 대해:

ㆍ 어떠한 로딩도 필요하지 않으면, EST = ELT + D_setup이고;

ㆍ 로딩이 필요하지만, 아직 시작하지 않았으면, EST = ELT + D_setup + RLT이고;

ㆍ 일단 로딩이 완료되면, EST = T_now이다.

이러한 결정에서, D_setup은 셋업의 계속 기간이다. 주목할 사항으로서, 다이내믹 EST 결정은 셋업이 로딩 이전에 일어나는지의 여부, 또는 셋업 및 로딩이 동시에 수행되는 지의 여부를 고려해야 한다. 또한, 주목할 사항으로서, 이러한 구현은 셋업이 로딩 이전에 일어나는 것으로 추정한다. 그리고, 배치 약속에 대해, 디폴트 결정은 다음과 같다:

EST_batch = max(배치 참가자들의 EST)

하지만, 이러한 공식화는 종종, 배치 참가자들이 로딩을 필요로 하고 최대 로드 사 이즈가 최대 배치 사이즈 보다 적은 경우, 문제를 겪게 된다. 각 배치 참가자의 EST는 개별적인 로트가 로딩 시간을 필요로 한다는 것을 고려하지만, 로드 사이즈가 배치 사이즈 보다 작기 때문에, 모든 로트들(130)은 동시에 로드될 수 없다. 하지만, 이러한 어려움들은 참가자들이 로드될 순서를 고려함으로써 해결될 수 있다. 이 때문에, 각 로트 공정 약속 및 자원 챠지 로트 약속은, 각 로트(130)의 로딩이 이루어지는 순서, 예를 들어 첫 번째, 두 번째, 세 번째를 나타내는 1, 2, 3을 식별하는 "transferSequence" 속성을 포함한다. "0"의 값은 로딩이 필요하지 않음을 나타낸다. 다음과 같은 의사 코드 알고리즘(pseudo-code algorithm)을 이용할 수 있다:

하지만, 대안적인 실시예들에서는 다른 적절한 알고리즘들이 이용될 수 있다.

주목할 사항으로서, 이러한 결정은 다이내믹하기 때문에, 이용되는 일부 양(quantity)들은 특정 이벤트가 발생할 때에 갱신된다. 예를 들어, LSA(305)는 로트(130)의 TST 및 RTT의 갱신을 책임진다. 예를 들어, RTT 및 TST의 값들은:

ㆍ 약속(375)이 처음 예약될 때 갱신되고-그 이유는 약속이 초기값들이 다음과 같이 설정되는 새로운 속성들 RTT 및 TST를 갖게 될 것이기 때문이다:

TST = 이전 로트 약속의 TE(이전의 어떤 약속도 예약되지 않은 경우에는, 현재 시간(T_now)이 이용된다); 및

RTT = TST와 공정 약속 간의 모든 이송 약속들의 이송 시간들의 합-;

ㆍ 이전 약속이 완료됨에 따라, TST의 값이 이전 약속의 실제 종료 시간(TE)으로 설정될 때 갱신되고;

ㆍ 이전 약속의 종료 시간(TE)이 변할 때 갱신되고-이는 이전 약속의 확장(예를 들어, 늦게 실행되거나, 또는 워크 피스들의 수가 증가한다), 축소(일찍 완료하거나, 또는 워크 피스들의 수가 감소한다), 왼쪽으로의 시프트 또는 오른쪽으로의 시프트 등으로 인해 일어날 수 있다. 이 경우, TST의 값은 이전 로트 약속의 수정된 종료 시간(새로운 TE)으로 설정된다-;

ㆍ 이송 약속이 시작됨에 따라, TST의 값이 시작된 이송 약속의 스케줄링된 중료 시간(TE)으로 설정되고, RTT의 값이 시작된 이송 약속의 스케줄링된 계속 기간 만큼 감소될 때 갱신되고;

ㆍ 이송 약속이 완료됨에 따라, TST가 이송 약속의 실제 종료 시간(즉, 실제 TE)으로 갱신될 때에 갱신되고; 그리고

ㆍ 이송이 시작되기 전에, 이송 약속이 왼쪽 또는 오른쪽으로 시프트될 때 갱신된다-다음 로트 약속의 TST 또는 RTT에 대한 어떠한 변경도 없는데, 그 이유는 이들이 보다 이른 로트 약속 또는 이송 약속에 기초하기 때문이다. 도시된 실시예에서, 이송 약속들이 시작된 후에는,이들의 시프팅이 허용되지 않는다-;

ㆍ 이송이 시작되기 전에, 이송 약속이 확장/축소될 때 갱신된다-이는, 로트 위치의 갑작스런 변경으로 인해 이송 약속이 변경되는 경우 일어날 수 있다. 다음 로트 약속은 하기와 같이 갱신된다:-;

ㆍ 이송이 시작된 후, 이송 약속이 확장/축소됨에 따라, 다음 로트 약속이 하기와 같이 갱신될 때에 갱신된다;

ㆍ 이전 로트 약속이 완료된 후, 로트 위치가 변경될 때 갱신된다-LSA는 로트의 위치가 갑작스럽게 변경되었으며 기존의 이송 약속들이 변경되고/되거나 취소되어야 함을 통지받는다. 아직 시작되지 않은 이송 약속들을 변경, 취소 그리고/또는 재예약한 후, 다음 로트 약속은 하기와 같이 갱신된다-;

ㆍ 이전 로트 약속이 재예약될 때, 즉 이전 로트 약속이 취소되고 재예약될 때 갱신된다-TST 및 RTT는, 대체 로트 약속이 재예약될 때 까지 변경되서는 안된 다. 이는 또한 이후 이송 약속들의 변경, 취소 그리고/또는 재예약을 요구할 수 있다. 다음 로트 약속은 하기와 같이 갱신된다-;

또 다른 이벤트들은 구현에 따라 상기 설명한 것들에 부가하여, 또는 대신에 갱신을 촉구(prompt)할 수 있다. 로딩 자원에 대한 RSA(315)는 유사한 방식으로 LST 및 RLT를 갱신한다. 예를 들어, LST 및 RLT는:

ㆍ 약속(375)이 처음으로 예약될 때 갱신된다-이는 약속이 새로운 속성들 LST 및 RLT를 갖게 됨에 따라, 로딩이 필요한 경우, 초기값들은:

LST = 로트 약속의 EST_static이고;

RLT = 로딩 계속 기간이 되기 때문이다. 로딩이 필요하지 않으면, 초기값들은:

LST = 널(null); 및

RLT = 0으로 설정된다-;

ㆍ 로딩 약속이 시작되어,

LST = 로딩 약속의 종료 시간; 및

RLT = 0이 될 때 갱신된다;

ㆍ 로딩 약속이 끝남으로써, LST=T_now이 될 때 갱신된다;

ㆍ 로딩이 시작되기 전에 로딩 약속이 축소 또는 확장됨으로써, RLT=새로운 로딩 계속 기간이 될 때에 갱신된다; 그리고

ㆍ 로딩이 시작되기 전에 로딩 약속이 축소 또는 확장됨으로써, LST=로딩 약속의 새로운 종료 시간이 될 때에 갱신된다.

또 다른 이벤트들은 구현에 따라 상기 설명한 것들에 부가하여, 또는 대신에 갱신을 촉구할 수 있다.

도 3으로 돌아가서, 일 특정 구현에서, 각 가능한 공정 툴(115)에 대한 각 MSA(310)는 실제로 서로 다른 약속 시작 시간들에 대해 예측되는 다수의 비드들(360)을 준비한다. 각 비드(360)는 서로 다른 "비용"을 포함한다. 도시된 실시예에서, "최종" 소비자들을 대리하는 각 스케줄링 에이젼트들(305 및 318)은 그와 관련된 예산 계산기 툴(미도시)을 구비함으로써, 신속한 예산 결정을 용이하게 한다. 각 제공자 스케줄링 에이젼트(310, 315)는 소비자의 각각의 예산 계산기 툴을 호출하여, 준비된 다수의 비드들(360)을 공식화함에 있어서 소비자의 상대적인 우선 순위를 결정한다. 제공자들을 대리하는 스케줄링 에이젼트들(310 및 315)은 각각 관련된 "비용 계산기들"을 갖는바, 이들 또한 이용가능한 시간 슬롯들에 대한 비용을 결정하기 위해 비드들을 공식화하는 데에 이용된다. 이러한 비용 결정들은 공정 툴(115) 및 자원(320)에 대해 그 목적들을 달성하기 위한 MSA(310) 또는 RSA(315)의 요구를 반영한다. 예를 들어, 공정 툴(115)이 비교적 아이들 상태라면, 머신 아이들 시간을 감소시키고자 시도할 때 비용은 비교적 낮다. 역으로, 공정 툴(115)이 비교적 바쁘다면, 비용이 비교적 높아져, 머신 이용의 증가에 대한 보다 적은 요구를 반영한다. "중간" 소비자를 대리하는 MSA(310)는 협상중인 제공자 에이젼트(예 를 들어, LSA(305), PMSA(318))의 예산 계산기 툴을, 또한 협상 중인 제공자 에이젼트(예를 들어, RSA(315))에게 전달한다. 따라서, 제공자들은 최종 소비자들에 대해 이용가능한 예산 및 최종 소비자들에게 자신들의 공정 자원들을 제공하기 위한 비용을 쉽게 결정할 수 있게 된다.

MSA(310)는 비드 정보를 패키지한 다음, 비드(들)(306)을 LSA(305)에게 서미트한다. 도시된 실시예에서, MSA(310)는 실제로 몇 개의 대안적인 비드들(360)을 비드 리스트의 형태로 돌려주는바, 이들 각각은 서로 다른 시작 시간을 갖는다. 도시된 실시예에서, 이러한 비드들(360)은 기존의 셋업을 이용하는 빈 시간 슬롯들; 새로운 셋업들을 요구하는 빈 시간 슬롯들; 로트(130)가 기존의 배치에 합류할 수 있는 시간 슬롯들; 로트(130)가 다른 로트(130)를 범핑(bumping)함으로써 기존의 배치에 합류할 수 있는 시간 슬롯들; 및 다른 로트들(130)에 대해 예약된 약속들을 범핑("취소")할 것을 요구하는 시간 슬롯들에 대해 머신 카렌다(370) 상에서의 서치를 이용함으로써 발생될 것이다. 이러한 서치들중 몇 개는 동일한 시간 슬롯을 돌려줄 수 있지만, 시간 슬롯은 로트(130)에게 되돌려지는 비드 리스트에 단지 한번 나타나야 한다. 본 특정 실시예에서는, 적어도 1개의 비드(360)가 항상 되돌려지고, 되돌려지는 비드들의 최소의 수는 구성가능한 특성값에 의해 결정된다.

주목할 사항으로서, 카렌다들(385, 370, 345 및 387)을 유지하게 되면 스케줄링 과정을 용이하게 한다. 이러한 카렌다들(385, 370, 345 및 387)은 공정 흐름(300)에 대해 예약된 약속들에 대한 어떠한 구조를 강요(impose)하는바, 이러한 구조에 의해 스케줄링 에이젼트들(305, 310, 315 및 318)은 예약된 약속들을 통해 신 속하고 용이하게 서치하여, 적절한 시간 슬롯들을 찾고, 비딩 및 비드 확인 과정을 발생(또는, 그렇지 않으면 이에 참가)시킬 수 있다. 이러한 구조는 또한 약속 관리 루틴들의 적용을 가능하게 하는바, 이들중 일부에 대해서는 하기에서 설명된다. 이러한 약속 관리 루틴들은 스케줄링 과정을 유사하게 용이하게 하고 공정 흐름(300)을 보다 효율적으로 동작할 수 있도록 도울 수 있다.

가능한 공정 툴들(115)에 대한 모든 MSA들(310)로부터 모든 비드들(360)을 수신한 후, LSA(305)는 비드들(306)을 평가한 다음, 서미트된 것들 중에서 1개의 비드(360)를 선택한다. 비드들(360)은 비드(360)의 종료 시간("Bid End Time"), 및 비용("Bid Cost")을 포함하는 다른 어떠한 정보에 비추어 목적 함수(F)를 통해 평가된다. 로트(130)에 대한 LSA(305)는 이러한 방식으로 모든 공정 툴(115)로부터의 모든 비드(360)를 평가한다. 다음과 같은 목적 함수(F)가 이용된다:

여기서, 지연 비용인 COL은 비드 종료 시간의 함수이고, COLF는 구성가능한 가중치이다. 최소의 목적 함수값을 갖는 비드(360)가 선택된다.

도 3을 여전히 참조하여, 일단 LSA(305)가 비드(360)를 선택하면, 자신이 받은 비드(360)를 서미트했던 MSA(310)에게 칸트랙트(365)를 준다. 보다 기술적으로, LSA(305)는 MSA(310)에게 "비드 확인" 메세지를 전송한다. MSA(310)가 칸트랙트(365)를 받아들이고, 공정 동작이 어떠한 자원도 필요로 하지 않는 다면, 이 MSA(310)는 LSA(305)에게 비드(360)를 확인하는 "비드 확인" 메세지(380)를 되돌려주고, 약속(375b)이 공정 툴(115)의 머신 카렌다(370) 상에 예약되며, 약속(375c) 이 로트 카렌다(385) 상에 예약된다. 공정 동작이 자원들을 필요로 한다면, MSA(310)는 먼저 그 비드를 서미트했던 RSA(315)에게 "비드 확인" 메세지(340) 또는 칸트랙트를 전송할 것이다. RSA는 그의 카렌다(345) 상에 약속(375a)을 예약하고, MSA(310)에게 "비드 확인" 메세지(355)를 전송한다. RSA(315)로부터 비드 확인 메세지(355)를 수신한 후, MSA(310)는 그의 머신 카렌다(370) 상에 약속(375b)을 예약하고, LSA(305)에게 "비드 확인" 메세지(380)를 전송하며, 이 LSA(305)는 로트 카렌다(385) 상에 약속(375c)을 예약한다.

하지만, LSA(305)가 비드(360)를 확인하고자 하는 시간 만큼, 공정 툴(115)의 머신 카렌다(370)가 변경되고, 시간 슬롯을 이용할 수 없게 되거나 또는 비드 비용이 변경될 수 있다. MSA(310)는, 시간 슬롯이 이용가능하고 비드 비용이 최초 비드 비용의 구성가능한 비율 이상으로 증가하지 않을 경우에만 비드(360)를 확인할 것이다. 그렇지 않으면, MSA(315)는 LSA(305)에게 응답하여, 비드(306)가 확인되지 않았음을 나타낸다.

공정 툴(115)이 선택된 비트(360)를 확인하지 않는 경우, LSA(305)는 비딩을 시작할지의 여부 또는 다음의 최선의 비드를 선택할지의 여부를 결정한다. LSA(305)는 남아있는 비드들(360)의 수와 구성가능한 "리비드 임계치(rebid threshold)"를 비교한다. 남아있는 비드들(360)의 수가 리비드 임계치 보다 크면,로트(130)는 상기 설명한 비드 선택 과정으로 돌아가서, 다음의 최선의 비드(360)를 선택한다. 다음의 최선의 비드(360)를 선택한 후, LSA(305)는 새로운 비드(360)에 대해 (상기 설명한) 목적 함수(F)를 계산한다. F의 값이 최선의 비드(360)에 대 한 목적 함수(F)의 구성가능한 비율 이상으로 증가하지 않는 다면, LSA(305)는 다음 비드(360)를 확인하고자 시도한다. 그렇지 않고, 남아있는 비드들이 재비드 임계치 보다 적거나, 다음 비드(360)에 대한 목적 함수(F)가 너무 많이 증가했다면, LSA(305)는 모든 가능한 공정 툴들(115)로부터 비드들을 요청함으로써 전체 과정을 다시 시작한다.

일 특정 구현에서, MSA들(310)은 자신들이 배치의 공정 툴들(115)을 대리하는지, 아니면 순차적("직렬")인 공정 툴들(115)을 대리하는 지에 대해 차별화한다. 예를 들어, 많은 타입의 공정 툴들(115)이 있고, 각 타입의 공절 툴(115)은 각 소프트웨어 에이젼트(265)가 특수화되는 서로 다른 특징들을 갖는다. 도시된 실시예에서, 머신 에이젼트들(스케줄링 및 공정 모두)에서 자신들을 특수화하는 예시적인 특징들은:

ㆍ 공정 툴(115)이 웨이퍼 단위로 공정하는지, 로트 단위로 공정하는지, 아니면 배치 단위로 공정하는 지의 여부;

ㆍ 공정 툴(115)이 웨이퍼들, 로트들 또는 배치들을 연속적으로 또는 순차적으로 공정하는 지의 여부;

ㆍ 공정 툴(115)에 대한 포트들의 수;

ㆍ 공정 툴(115)에 대한 포트들이 입력인지, 출력이지, 아니면 입/출력인지의 여부;

ㆍ 공정 툴(115)에 대한 챔버들이 직렬로 이용되는지, 아니면 병렬로 이용되는 지의 여부;

ㆍ 공정 툴(115)이 PM들을 속박(chain)할 수 있는 지의 여부;

ㆍ 공정 툴(115) 내의 챔버들의 수;

ㆍ 공정 툴(115)이 내부 저장 수단을 포함하는 지의 여부;

ㆍ 공정 툴(115)이 다른 로트 또는 배치의 공정을 완료함과 동시에, 어떠한 로트 또는 배치의 공정을 시작할 수 있는 지의 여부;

ㆍ 공정 툴(115)이 로딩 그리고/또는 언로딩을 요구하는 지의 여부;

ㆍ 공정 툴(115)이 자원들을 요구하는 지의 여부, 그리고 요구한다면, 이러한 자원들이 전용 자원들인지, 아니면 공유 자원들인 지의 여부를 포함한다.

하지만, 주목할 사항으로서, MSA(310) 또는 어떠한 소프트웨어 에이젼트(265)가 특수화되는 팩터들은 구현 마다 특정될 것이다.

예를 들어, 머신 에이젼트들이 이들이 웨이퍼 단위, 로트 단위, 배치 단위 등으로 공정하는 지의 여부에 의해 특수화되는 구현을 고려해보자. 일 특정 실시예에서는, 다음과 같은 머신 에이젼트들:

ㆍ 베이스라인 공정 에이젼트;

ㆍ 웨이퍼 기반의 공정 에이젼트;

ㆍ 웨이퍼 기반의 순차 공정 에이젼트;

ㆍ 웨이퍼 기반의 배치 순차 공정 에이젼트;

ㆍ 웨이퍼 기반의 배치 공정 에이젼트;

ㆍ 로트 기반의 공정 에이젼트;

ㆍ 로트 기반의 순차 공정 에이젼트;

ㆍ 로트 기반의 배치 공정 에이젼트;

ㆍ 로트 기반의 배치 순차 공정 에이젼트;

ㆍ 베이스라인 스케줄링 에이젼트;

ㆍ 웨이퍼 기반의 스케줄링 에이젼트;

ㆍ 웨이퍼 기반의 순차 스케줄링 에이젼트;

ㆍ 웨이퍼 기반의 배치 순차 스케줄링 에이젼트;

ㆍ 웨이퍼 기반의 배치 스케줄링 에이젼트;

ㆍ 로트 기반의 스케줄링 에이젼트;

ㆍ 로트 기반의 순차 스케줄링 에이젼트;

ㆍ 로트 기반의 배치 스케줄링 에이젼트; 및

ㆍ 로트 기반의 배치 순차 스케줄링 에이젼트가 이용된다.

본 특정 실시예는 객체 지향 프로그래밍 기술들을 이용하여 에이젼트들을 구현하고, 베이스라인 에이젼트들은 클래스 정의를 제공하며, 나머지는 그 클래스의 서브 클래스들이다.

또한, 다른 에이젼트 특수화가 이용될 수 있다. PM 에이젼트들은 이들이 수행하는 유지 절차들이 시간, 처리되는 웨이퍼, 처리되는 로트, 처리되는 배치, 공정 시간, 이벤트의 발생 등 중에서 어느 것에 기초하는 지에 의해 특수화될 수 있다. 일 특정 실시예에서는, 다음과 같은 PM 에이젼트들:

ㆍ 웨이퍼 기반 PMSA;

ㆍ 시간 기반 PMSA;

ㆍ 공정 유닛(예를 들어, 처리되는 로트들의 수, 처리되는 배치들의 수) 기반 PMSA;

ㆍ 이벤트 기반 PMSA: 및

ㆍ 공정 시간(예를 들어, 누적 공정 시간) 기반 PMSA가 이용된다.

또한, 자원 에이젼트들은 이들이 전용 자원들(예를 들어, 단지 1개의 머신에 의해 이용되는 로딩 자원)을 대리하는지, 아니면 다수의 공정 툴들(115) 사이에서 공유될 수 있는 공유 자원(예를 들어, 웨이퍼 팹 테크(tech), 레티클 또는 빈 캐리어)을 대리하는 지의 여부에 의해 특수화될 수 있다. 로트 에이젼트들 또한 자신들의 우선순위, 제품, 제품 패밀리, 또는 행동의 차별화를 완화하는 다른 속성들에 따라 특수화될 수 있다. 대안적인 실시예들에서는 또 다른 특수화들이 이용될 수 있다.

카렌다들, 예를 들어, 도 3의 카렌다(327)는 또한 관련된 머신들, 로트들, 자원들 또는 PM들로서 특수화될 수 있다. 하지만, 주목할 사항으로서, 이것이 본 발명의 실행에 반드시 필요한 것은 아니다. 도 4B는 OOP 환경에서 객체들로서 구현되는 일 특정 실시예에서 이용되는 카렌다 특수화의 계층 구조를 도시한다.

따라서, 이러한 타입의 에이젼트 특수화가 이용되는 경우, 카렌다들(370, 385, 345 및 387) 또한 특수화될 수 있다. 특수화된 어떠한 카렌다들(예를 들어, 순차 카렌다들) 상에서, 일부 약속은 다른 약속들과 겹칠 수 있다. 본 개시의 이득을 갖는 당업자라면 알 수 있는 바와 같이, "순차"라는 용어는 한번에 1개 이상의 물질(예를 들어, 웨이퍼(135), 로트(130) 또는 배치)을 처리할 수 있는 능력을 말 한다. 즉, 공정 툴(115)은, 제 1 물질의 공정을 완료하기 전에 제 2 물질의 공정을 시작할 수 있다. 예를 들어, "싱크(sink)"라 불리는 공정 툴(115)을 고려하자. 이러한 싱크는 웨이퍼들(135)의 로트들(130)이 다양한 화학 배쓰(chemical bath)들에 순차적으로 노출될 수 있는 몇 개의 터브(tub)들을 갖는다. 제 1 로트(130)가 제 1 배쓰에 노출되는 동안, 제 2 로트(130)는 제 2 배쓰에 노출될 수 있고, 이들 모두는 동일한 공정 툴(115)에 의해 순차적으로 처리된다.

공정 툴(115)이 순차 머신이고, MSA(310) 및 머신 카렌다(370)가 특수화되는 경우들에 있어서, 일부 약속들의 일부 부분들은 겹칠 수 있다. 도 4C에 나타낸 바와 같이, 이러한 카렌다들에서 약속(404)의 공정 윈도우(PW)(402)는 2개의 간격들, 즉 소비 간격(406) 및 공정 간격(408)을 가질 것이다. (주목할 사항으로서, 명확성을 위해, 도 4C에서 수반되는 커미트먼트 윈도우들은 생략하였다.) 소비 간격(406)에서, 로트들(130)은 공정을 위해 공정 툴(115)에 들어가고 있다(즉, "소비"되고 있다). 이후, 소비 간격(406) 이후의 PW(402) 내의 그 밖의 모두에 대해서는 공정 간격(408)이 정의된다. 한 약속의 공정 간격은 동일한 셋업 요건들을 갖는 다른 약속의 소비 간격과 겹칠 수 있지만, 어떠한 소비 간격도 겹칠 수 없다. 도 4C에서, 로트들(LOT₁, LOT₂)은 공정 툴(TOOL₁)에 대해 스케줄링된 약속들(404)을 갖는바, 여기서 로트(LOT₂)의 약속(404)에 대한 소비 간격(406)은 로트(LOT₁)의 약속(404)의 공정 간격(408)과 겹친다. 하지만, 주목할 사항으로서, 서로 다른 셋업들을 요구하는 로트 공정 약속들은 심지어 이러한 타입의 특수화된 머신 카렌다(370) 상에서도 겹칠 수 없다.

따라서, 상기 설명한 바와 같이, 어떠한 소정의 카렌다 상에 스케줄링되는 약속들의 타입은 주로, 카렌다를 보유하고 있는 소프트웨어 에이젼트(265)가 대리하고 있는 엔티티의 특성과 에이젼트 및 카렌다 특수화의 등급에 의존할 것이다. 도시된 실시예에서는, 표 1에서 설명한 바와 같이 4가지 타입의 스케줄링 에이젼트들: 즉 MSA, LSA, RSA 및 PMSA가 있다. 각 스케줄링 에이젼트는 자신의 예약된 약속들을 저장하기 위한 자기 자신의 스케줄링 카렌다, 즉 머신 카렌다, 로트 카렌다, 자원 카렌다 및 PM 카렌다를 갖는다.

도 5는 도시된 실시예에서 다양한 타입의 카렌다들에 의해 보유되는 다양한 타입의 약속들에 대한 설명을 돕기 위한 다양한 카렌다들을 개념적으로 도시한다. 도 5는 또한 어떠한 카렌다들 상의 어떠한 약속 타입들이 다른 타입의 카렌다들 상의 "대응하는" 약속들과 함께 어떻게 예약되는 지를 설명하는 것을 돕는다. 보다 특정하게, 도 5는:

ㆍ MSA(506)에 의해 유지되는 공정 툴(T₁)에 대한 머신 카렌다(501);

ㆍ LSA(507)에 의해 유지되는 로트(L₁)에 대한 로트 카렌다(502);

ㆍ RSA(508)에 의해 유지되는 머신 자원(R₁)에 대한 자원 카렌다(503); 및

ㆍ PMSA(509)에 의해 유지되는 예방 유지를 위한 PM 카렌다(504)를 도시한다.

도 5는 또한:

ㆍ MSA(520)에 의해 유지되는 공정 툴(T₂)에 대한 머신 카렌다(511);

ㆍ 각 LSA(521 내지 526)에 의해 유지되는 각 로트(L₅ 내지 L₁₀)에 대한 다수의 로트 카렌다들(512 내지 517); 및

ㆍ RSA(527)에 의해 유지되는 머신 로딩 자원(R₂)에 대한 자원 카렌다(518)를 도시한다.

도 4A에서와 대조적으로, 도 5에서, 소정의 카렌다에 대한 모든 약속들은 단일 시간선으로 컬랩스(collapse)된다. 각 약속에 대한 커미트먼트 윈도우들은, 이러한 컬랩스를 용이하게 하고 도면이 과도하게 복잡해지는 것을 막기 위해 생략되었다. 이하, 본 특정 실시예에 대해 표 1에서 요약되고 도 5에서 예시된 다양한 종류의 약속들에 대해 간단하게 설명한다.

MSA들(예를 들어, MSA들(506, 520))은 다수 타입의 약속들을 스케줄링하고 예약한다. 도 5에서, 툴(T₁)에 대한 MSA(506)는 머신 카렌다(510) 상에 몇 종류의 약속들을 예약한다. 이러한 약속들로는 셋업 약속들(529 내지 530); 로트 공정 약속들(532 내지 534); PM(537); 및 독립적인 Qual(538)이 있다. 툴(T₂)에 대한 머신 카렌다(515) 상에 나타낸 바와 같이, MSA(520)는 머신 배치 약속(557) 및 다운타임 약속(555)을 예약한다. 주목할 사항으로서, 도시된 실시예에서, 어떠한 공정 툴(115)에 대해 어떠한 약속들, 예를 들어 셋업 약속들(529 내지 530), 로트 공정 약속들(532 내지 534), PM 약속(537) 및 Qual 약속(538)이 스케줄링될 수 있다. 하지 만, 어떠한 약속들은 스케줄링되지 않는다. 예를 들어, 배치 약속(557)은 배치 동작들을 수행하지 않는 공정 툴들(115)에 대해서는 스케줄링될 수 없다. (주목할 사항으로서, 배치 카렌다들 상에서, 로트 공정 약속들은 머신 카렌다(370) 상에 직접 스케줄링되지 않는다. 그렇다기 보다, 이들은 배치 약속의 참가자들로서 예약된다.) 일부 실시예들은 또한 다른 종류의 약속들을 이용할 수 있다.

로트 공정 약속들(532 내지 534)은 툴(T₁)이 로트들(L₁, L₂, L₃)에 대한 공정을 실제로 수행하도록 스케줄링되는 약속들이다. 본 개시의 이득을 얻는 당업자라면 알 수 있는 바와 같이, 툴들(T₁, T₂)은 종종 소정의 로트를 처리하기 위한 준비로 "셋업"을 경험해야 할 것이다. 다른 모든 것이 같으면, 일반적으로 동일한 셋업을 요구하는 로트들을 연속적으로 스케줄링함으로써 셋업의 수를 감소시키는 것이 바람직하다. 툴(T₁) 상에서의 로트들(L₁, L₂)이 이러한 경우인데, 그 로트 공정 약속들(532 내지 533)은 공통의 셋업(S₁)을 요구하기 때문에, 셋업 약속(529) 이후 함께 스케줄링된다. 이러한 타입의 선택은 상기 설명한 비드들을 공식화함에 있어서 스케줄링 과정에서 구현된다. 보다 특정하게는, 비용 팩터들이 비딩 과정에 배분됨으로써, 공통 셋업을 갖는 로트 공정 약속들이 함께 스케줄링되도록 촉진시킨다. 하지만, 도 5에서, 로트(L₃)는 새로운 셋업(S₂)을 요구하고, MSA(506)는 로트 공정 약속(534) 이전에 별개의 셋업 약속(530)을 스케줄링한다. 주목할 사항으로서, 도시하지는 않았지만, 배치 약속들이 수행되는 툴들(예를 들어, 툴(T₂))에 대해서도 셋업 약속들이 유사한 방식으로 스케줄링된다.

이름이 암시하는 바와 같이, 배치 약속(557)은 로트들(130)의 배치를 처리하기 위한 공정 툴(예를 들어, T₂)에 대한 약속이다. 각 로트(130)(예를 들어, L₅ 내지 L₁₀)는 배치의 "참가자"로 여겨지며, 배치 약속은 실제로 다수의 "참가자" 약속들을 포함한다. 실제로, 이러한 참가자 약속들은 단지 배치의 구성을 설명하는 로트 공정 약속들일 뿐이다. 도시된 실시예에서, 로트 약속들(574 내지 579)은 배치 약속(574)에 대한 대응하는(counterpart) "참가자 약속들"이다. 로트들(130)은 개별적인 참가자 약속들을 합류, 제거, 취소, 그리고/또는 범핑함으로써 배치에 부가되거나 또는 배치로부터 제거될 수 있다. 배치가 공정 툴(115) 상으로의 로딩을 필요로 하면, RSA(527)는 하기에서 보다 상세히 설명하는 방식으로 로드 및 언로드 약속들(567 내지 569, 593 내지 594)을 스케줄링할 것이다.

표 1에서 요약한 바와 같이, 로트들(L₁, L₅ 내지 L₁₀)에 대한 LSA들(507, 521 내지 526)은 일반적으로 로트 카렌다들(502, 512 내지 517) 상에 6가지 종류의 약속들: 즉 이동 약속들(540 내지 542); 로트 약속들(546 내지 548, 574 내지 579); 최대 이동 약속(553); 피더 약속(552); 로드 약속들(560 내지 565)(예를 들어, LD₁, LD₂, LD₃); 및 언로드 약속들(583 내지 588)(예를 들어, UL₁, UL₂, UL₃)을 예약한다. 이동 약속들(540 내지 542) 및 로트 약속들(546 내지 548, 574 내지 579)이 스케줄링되는바, 이때 확실성(certainty)을 가지고 스케줄링하는 데에 이용되는 모든 파 라미터들은 알려져있다. 최대 이동 약속(553) 및 피더 약속(552)은, 충분한 확실성을 얻을 때 까지, 즉 소스 및 목적지 공정 툴들(115)이 알려지고, 이동 계속 기간이 결정될 수 있으며, 그리고 이들이 이동 약속들(540 내지 542) 및 로트 약속들(546 내지 548, 574 내지 579)과 같은 이동 및 로트 약속들에 의해 대체될 수 있을 때까지, 카렌다 상에 "위치 보유자(place holder)들"로서 스케줄링된다. 보다 정확하게, 상기 대체는 LSA(예를 들어, LSA(507))가, 로트(130)(예를 들어, 로트(L₁))가 최종 피더 동작으로 이동했고 머신이 선택되었음을 검출할 때 이루어진다. 따라서, 피더 약속(552) 및 최대 이동 약속(553)은, 특정한 공정 툴(115)에 대해 보다 일찍 끼어드는 일부 동작들을 스케줄링하기 전에, 몇 개의 동작들에 대한 제어 동작들을 사전에 스케줄링하는 환경에서 유용하다.

보다 특정하게, 로트 약속들(546 내지 548, 574 내지 579)은 특정한 공정 툴들(T₁, T₂, T₃, T₄, T₅) 상에서 각 로트들(L₁, L₅ 내지 L₁₀)을 처리하기 위한 약속들이다. 본 개시의 이득을 얻는 당업자라면 알 수 있는 바와 같이, 로트들(130)은 전형적으로 공정 툴(115)로부터 공정 툴(115)로 이동하여, 로트의 공정들에서 정의된 연속적인 동작들에 대해 처리된다. 예를 들어, 도 1은 왼쪽의 제 1 공정 툴(115) 또는 소스 위치에서부터 오른쪽의 제 2 공정 툴 또는 목적지 위치로 이동하는 로트(130)를 도시한다. 이러한 이동들은 일반적으로, 로트 약속이 스케줄링될 때에 스케줄링된다. 전형적으로, 2가지 타입의 이동들, 즉 베이간(interbay) 이동 및 베이내(intrabay) 이동이 있다. 베이간 이동은 로트들(130)을 제조 설비의 베이들(미도 시) 간에 이송한다. 베이내 이동은 로트들(130)을 동일한 베이 내의 서로 다른 위치들로 이송한다. 따라서, 한 공정 툴(115)로부터 다른 베이의 다른 공정 툴(115)로의 로트(130)의 전형적인 이동은 적어도 3개의 이동들: 즉 제 1 공정 툴(115)의 포트로부터 그 툴의 베이 내의 스토커(stocker)(미도시)로의 베이내 이동; 상기 스토커로부터 제 2 공정 툴(115)과 동일한 베이에 있는 다른 스토커(미도시)로의 베이간 이동; 및 상기 다른 스토커로부터 제 2 공정 툴(115)의 포트로의 마지막 베이내 이동을 필요로 한다.

하지만, 부분 자동화 팹에서는, 공정 동작들의 단지 일부 만이 소프트웨어 에이젼트들(265)에 의해 스케줄링되고 제어된다. 따라서, 팹의 공정 툴들(115)의 서브 셋트 만이 소프트웨어 에이젼트들(265)의 제어하에 있고, 팹은 이러한 시스템의 완전한 제어하에 있지 않다. 소프트웨어 에이젼트들(265)에 의해 제어되는 공정 동작들은 "제어 공정 동작들"이라 부른다. 각 제어 공정 동작 직전에, "피더" 동작들의 시퀀스가 제어 공정 동작의 공정 시간의 구성가능한 배수(multiple)로부터 얻어질 수 있다. 피더 약속(552)과 같은 피더 약속들은 사전에 스케줄링되는 약속, 예를 들어 로트 약속(548)에 대한 TST를 결정하는 데에 이용된다. 보다 특정하게, 피더 약속들은, LSA가 사전에 스케줄링되고 실제 공정 툴(115)에 의한 피더 동작을 스케줄링한 시간에 아직 도달하지 않았을 때에 이용된다. 피더 약속들은 각 피더 동작들의 사이클 시간과 같은 계속 기간을 갖는 피더 동작들에 대한 공정 액티비티들을 나타내는 데에 이용된다.

하지만, 피더 동작에 있어서, 마지막 피더 동작을 수행하게 될 특정한 공정 툴(115)은 로트(130)가 마지막 피더 동작에서 공정을 시작할 때 까지 알려지지 않는다. 최대 이동 약속(553)과 같은 "최대 이동" 약속은 마지막 피더 공정 툴(115)로부터 제어 공정 툴(115)로의 이송 액티비티들을 나타낸다. 일 실시예에서, 최대 이동 약속의 계속 기간은 마지막 피더 공정 툴 스테이션(115)과 제어 공정 툴 스테이션(105) 간의 최악의 경우의 이동 시간에 의해 얻어진다. 마지막 피더 동작을 수행하는 실제 공정 툴(115)이 알려지면, 최대 이동 약속은 피더 공정 툴과 제어 공정 툴 사이에서, 이동 약속 또는 이동 약속들의 시퀀스에 의해 대체될 것이다.

주목할 사항으로서, 피더 및 최대 이동 약속들은 스케줄링 공정에 대한 제약들을 암시적으로 나타내는 것이 아니라 명시적으로 나타낸다. 명시적인 제약들은 다른 약속들의 스케줄링 및 예약에 직접 영향을 미치는 카렌다들 상의 약속들로서 표현된다. 이러한 명시적인 제약들의 예로는 이동, 로드, 언로드, 최대 이동 및 피더 약속들이 있지만, 이것들에만 한정되지는 않는다. 이러한 약속들은 로트 카렌다 상의 로트 약속들의 스케줄링을 명시적으로 제약한다. 암시적인 제약들은 카렌다 상의 약속들로서 표현되는 것이 아니라, 이들이 영향을 주는 약속들의 속성들로서 표현된다. 예를 들어, 머신 카렌다 상의 로트 공정 약속은 로딩, 이송 및 언로딩 제약들을 나타내는 속성들을 갖는데, 그 이유는 이러한 제약들이 머신 카렌다 상의 약속들에 의해 표현되지 않기 때문이다. 유사하게, 상기 설명한 UST 및 RUT처럼, 디스챠지 계속 기간 또한 암시적인 제약이다. UST 및 RUT처럼, 디스챠지 계속 기간은 어려운 제약이 아니다. 이에 따라, 다이내믹 EST에 영향을 주지 않지만, 시프팅은 제약하는데, 그 이유는 다음 배치 약속과 관련된 로딩 또는 언로딩이 디스챠지 와 겹칠 수 없기 때문이다.

일부 공정 동작들에 대해, 공정 툴(115)(예를 들어, 툴(T₂))은 로트(130)의 로딩 및 언로딩을 요구할 수 있다. 이러한 동작들에 대해, LSA(예를 들어, LSA들(521 내지 526))은 자기 자신의 카렌다(예를 들어, 로트 카렌다들(512 내지 517)) 상에 로트 로드 및 로트 언로드 약속들(예를 들어, 로드 및 언로드 약속들(560 내지 565, 583 내지 588))을 예약할 것이다. 이러한 로드 및 언로드 약속들은 RSA(예를 들어, RSA(527))에 의해 자신의 카렌다(예를 들어, 자원 카렌다(518)) 상에 스케줄링된 로딩 및 언로딩 약속들(예를 들어, 로드 및 언로드 약속들(567 내지 569, 592 내지 594))과 일치한다. 도 5에서, 툴(T₂)은 로딩을 요구하고, 자원(R₂)은 하기에서 보다 상세히 설명하는 방식으로 툴(T₂) 상에 로트들(L₅ 내지 L₁₀)을 로드시킨다. 결과적으로, 자원(R₂)의 자원 카렌다(518)에 대한 RSA(527)는 로드 약속들(567 내지 569) 및 언로드 약속들(592 내지 594)을 포함하는바, 여기서 자원(R₂)은 툴(T₂) 상에 로트들(L₅ 내지 L₁₀)을 로드시키도록 스케줄링된다. 주목할 사항으로서, 로트 카렌다들(512 내지 517) 각각은 로드 및 언로드 약속들(560 내지 565 및 583 내지 588)을 포함하는바, 이들은 자원 카렌다(518) 상의 로드 약속들(567 내지 569) 및 언로드 약속들(592 내지 594)과 대응한다. 또한 주목할 사항으로서, 툴(T₂)에 대한 머신 카렌다(511)는 어떠한 로드 또는 언로드 약속들도 포함하지 않지만, 로트 공정 약속은 암시적인 제약들을 나타내는 속성들을 갖는다.

PMSA(509)는 카렌다(530) 상에 2가지 종류의 약속들: 즉 PM 약속(552)과 같은 PM 약속들 및 Qual 약속(553)과 같은 독립적인 Qual들을 예약한다. PMSA(509)는 PM들 및 Qual들을 기회적으로, 하지만 스케줄링되어야 하는 알려진 제약들에 따라 스케줄링한다. 카렌다(530)는 툴(T₁)에 대해 스케줄링된 단지 1개의 PM 약속(552) 및 1개의 Qual 약속(553)을 나타낸다. 주목할 사항으로서, 머신 카렌다는 그 위에 예약된 대응하는 PM 및 Qual 약속들(537 내지 538)을 포함한다. 본 개시의 이득을 얻는 당업자라면 알 수 있는 바와 같이, 다수의 PM들 및 Qual들이 하나의 툴 상에서 수행될 수 있으며, 이에 따라 실제 실시예에서 머신 및 PM 카렌다들(501 및 593)은 하나의 툴에 대해 다수의 PM 및 Qual을 포함할 수 있다. 공정 툴(115)이 공정 흐름(300)에 다시 들어가기 전에, 일부 PM들에는 1개 또는 그 이상의 팔로우업 Qual들이 뒤따를 것이 요구된다. 이러한 환경들에서, 팔로우업 Qual들은 PM 약속 내에서 자동으로 스케줄링된다.

도시된 실시예에서, RSA들(예를 들어, RSA들(508, 527))은 이들이 대리하는 자원의 종류에 의해 특수화된다. 2가지 종류위 자원들: 즉, 공유 자원들 및 전용 자원들이 있다. 공유 자원들은 도 3에 도시한 레티클(320)과 같은 다수의 공정 툴들(115)에 의해 공유될 수 있는 자원들이다. 머신 로더들(미도시)과 같은 전용 자원들은 단일 공정 툴(115)과 함께 동작한다. 자원 카렌다들의 이러한 타입의 특수화는 상기 설명한 특수화된 에이젼트들의 이용에 의해 허용되는 단지 하나의 유익한 변형일 뿐이다.

RSA에 의해 예약되는 약속들의 타입들은 RSA가 나타내는 자원의 타입에 의존한다. 도 5에 도시한 자원(R₁)에 대한 공유 RSA(508)는 자기 자신의 자원 카렌다(503) 상에 적어도 2가지 종류의 약속들: 즉, 자원 소비 약속(550)과 같은 자원 소비 약속들 및 이동 약속들(543, 544)과 같은 이동 약속들을 예약한다. 자원(R₁)은 몇 개의 공정 툴들(115)(예를 들어, T₁)에 의해 공유되기 때문에, 이는 공정 툴들(115) 사이에서 이동할 필요가 있으며, 이에 따라 이동 약속들(543, 544)이다. 주목할 사항으로서, 이동들 자체는 또 다른 자원들(미도시)에 의해 수행될 수 있고, 레티클과 같은 공유 자원은 공정 툴에서 이용되지 않을 때 레티클 스토커와 같은 저장 위치로 이동할 수 있다. 전용 RSA(527)는 자신의 전용 공정 툴(115)(예를 들어, T₂)과 관련된 약속들 만을 스케줄링한다. 도시된 실시예에서, 전용 RSA(527)는 로(미도시)에 대한 머신 로딩 자원(미도시)을 나타낸다. 전용 RSA(527)는 카렌다(540) 상에 4가지 종류의 약속들: 즉 로드 약속들(567 내지 572); 챠지 약속(572); 디스챠지 약속(581); 및 언로드 약속들(592 내지 594)을 예약한다. 로드 약속들(567 내지 572), 챠지 약속(572), 디스챠지 약속(581) 및 언로드 약속들(592 내지 594)은 구현마다 특정되는바, 이에 대해서는 하기에서 보다 상세히 설명한다.

본 개시의 이득을 얻는 당업자라면 알 수 있는 바와 같이, 일부 공정 툴들(115)(예를 들어, T₂)은 다수의 로트들(130)이 한 배치에서 동시에 처리되는 로트 배치 공정 동작들을 수행한다. 이러한 공정 툴들(115)중 일부는 로드, 챠지, 디스 챠지 및 언로드 단계들을 이용한다. 도 5의 실시예에서, 툴(T₂)은 먼저 모든 배치 참가자들, 즉 로트들(130)을 툴 I/O 포트들(미도시)로부터 툴 내부 스토커(미도시)로 로드시킨다. 일반적으로, 이러한 타입의 공정 툴들(115)은 다수의 I/O 포트들을 갖고, 로드/언로드 동작들 또한 배치로 수행된다. 예를 들어, 툴(T₂)이 2개의 I/O 포트들을 갖고, 배치 공정 동작이 한 배치에서 6개의 최대수의 참가자들을 허용한다면, 3개의 배치 로드 동작들은 6개의 로트들(130)을 툴(T₂)의 내부 스토커 내로 로드시킬 것이 요구된다. 모든 배치 참가자들이 로드된 후, 툴(T₂)은 공정이 실제로 시작되기 전에 배치 참가자들을 내부 스토커로부터 로 튜브(미도시)로 이동시키기 위해 배치 챠지 동작을 수행한다. 툴(T₂)이 배치 공정 동작을 완료한 후, 이는 배치 참가자들을 튜브로부터 내부 스토커로 디스챠지시킨다. 마지막으로, 로트들(130)이 툴 I/O 포트들로 이동할 준비가 되면, 배치 언로드 동작들의 시퀀스가 수행된다.

툴 내부 이송 메커니즘으로 인해, 약속들은 이러한 종류의 자원 스케줄링 카렌다 상에서 겹칠 수 없다. 이러한 로드, 챠지, 디스챠지 및 언로드 액티비티들은 상호 배타적인 방식으로 수행된다. 즉, 이들은 동일한 자원을 이용하기 때문에 동시에 수행될 수 없다. 따라서, 로딩은 로트(130)를 머신 포트로부터 이 머신의 내부 스토커로 이동시킨다. 챠징은 웨이퍼들(135)을 내부 스토커로부터 가열(공정)을 위해 로 튜브로 이동시킨다. 디스챠징은 (냉각 이후) 로 튜브로부터 웨이퍼들(135)를 제거한 다음, 이들을 다시 내부 스토커로 이동시킨다. 언로딩은 로트(130)를 내 부 스토커로부터 머신 포트로 이동시킨다.

주목할 사항으로서, RSA(527)는 배치 약속(557)에 의해 머신 카렌다(511) 상에 나타나는 실제 공정과 관계되지 않는다. 하지만, 자원 카렌다(518) 상의 챠징 및 디스챠징 약속들(572, 581)과 머신 카렌다(511) 상의 배치 약속(557) 사이에는 관계가 있다. 보다 특정하게, 챠징은 공정이 시작될 때 시작되고, 디스챠징은 공정이 끝날 때 끝난다. 이러한 챠징 또는 디스챠징은 전형적으로 약 15분 걸리고, 공정은 전형적으로 4시간 또는 그 이상 걸린다. 머신 카렌다(511) 상에서, 배치는 로가 디스챠징을 완료할 때 까지 (챠징이 시작하기 전에) 시작 커맨드가 발행되는 시간으로부터 고려되는 "공정"이다. 주목할 사항으로서, MSA(520)는 로딩, 챠징, 디스챠징 또는 언로딩과 관계되지 않는데, 그 이유는 이들은 모두 자신의 자원 카렌다(518) 상에서 RSA(527)에 의해 추적되기 때문이다. 머신 카렌다(511)는 "공정"을 나타내는 배치 약속(557)을 포함하는바, 이는 다른 어떠한 배치도 툴(T₂) 상에서 "공정"될 수 없는 시간이다.

상기 설명한 바와 같이, 머신 카렌다(511) 상에서, 배치 약속은 실제로, 배치의 각 로트(130)에 대해 하나씩, 각 로트 공정 약속들인 참가자들을 포함한다. 한편, 로딩 및 언로딩 액티비티들은, 이들이 서로에 의해 또는, 챠징 또는 디스챠징에 의해 충돌하지 않는 한, "공정"과 동시에 이루어질 수 있다. 다른 배치가 "공정"되는 동안 로트들을 로딩 또는 언로딩하는 것은 로의 쓰루풋을 증가시키는 기술이다.

이러한 특정 타입의 로에 대해, 로트들(L₅ 내지 L₁₀)은 한번에 두개씩 로드되는데, 그 이유는 이것은 로트들(130)이 로드 또는 언로드될 수 있는 머신 I/O 포트들의 수이기 때문이다. 하지만, 로는 최대 6개의 로트들(130)을 런시킬 수 있으며, 이에 따라 배치의 로트들(130)의 수가 2개 이상이면, 로트들(130)은 2개의 로트들(130)의 서브 배치들로 로드된다. 따라서, 로트들(L₅, L₆)은 자원 카렌다(518) 상의 로드 약속(567) 동안 로드되고, 로트들(L₇, L₈)은 로드 약속(568) 동안 적재되며, 그리고 로트들(L₉, L₁₀)은 로드 약속(569) 동안 적재된다. 주목할 사항으로서, 자원 카렌다(518) 상의 로드 약속들(567 내지 569)은 로트 카렌다들(512 내지 517) 상에 대응하는 약속들을 갖는다. 보다 특정하게, 각 로드 약속(567 내지 569)은 2개의 로트들을 포함하기 때문에, 각 로드 약속들은 2개의 대응물들을 갖는다. 따라서, 로드 약속(567)은 로트 카렌다들(512, 513) 상에 대응물(560, 561)을 갖고; 로드 약속(568)은 로트 카렌다들(514, 515) 상에 대응물들(562, 563)을 가지며; 그리고 로드 약속(569)은 로트 카렌다들(516, 517) 상에 대응물들(564, 565)을 갖는다. 이에 따라, 6개의 로트들(130)(예를 들어, 로트들(L₅ 내지 L₁₀))을 갖는 배치는 자원 카렌다(예를 들어, 자원 카렌다(518)) 상에 3개의 서브 배치 로드 약속들(예를 들어, 로드 약속들(567 내지 569))을 갖는다. 또한 주목할 사항으로서, 도시된 실시예에서, 각 로드 약속(567 내지 569)은 실제로, 로드되고 있는 각 참가자 로트에 대한 자원 로트 로딩 약속을 포함하는 배치 로딩 약속이다.

챠징은 본 특정 로에서 동시에 모든 로트들(130)(6개의 최대수를 갖는다)에 대해 수행된다. 챠지 약속(572)은 챠징 배치를 나타내는바, 이는 실제로 배치의 각 참가자(예를 들어, 로트들(L₅ 내지 L₁₀))에 대한 참가자 챠지 약속(미도시)을 포함한다. 따라서, 각 로 런에 대해, 최대 6개의 참가자들을 갖는 1개의 챠지 약속(572)이 있을 것이다. 디스챠징 또한 동시에 모든 로트들(130)에 대해 수행된다. 디스챠징 약속(581)은 디스챠징 배치를 나타내고, 실제로 배치의 각 참가자(예를 들어, 로트들(L₅ 내지 L₁₀))에 대한 참가자 디스챠지 약속(미도시)을 포함한다. 각 로 런에 대해, 최대 6개의 참가자들을 갖는 1개의 디스챠지 약속(581)이 있을 것이다. 하지만, 상기 설명한 바와 같이, 개별적인 로트들(130)(예를 들어, 로트들(L₅ 내지 L₁₀))은 챠징 및 디스챠징과 관계되지 않는데, 이는 이러한 단계들이 공정 툴(예를 들어, 툴(T₂)) 내부에서 이루어지기 때문이다. 따라서, 챠지 및 디스챠지 약속들(572, 581)은 로트 카렌다들(512 내지 517) 상에 어떠한 대응물도 갖지 않는다. 로트들(L₅ 내지 L₁₀)은 대신에 로트 약속들(574 내지 579)에 대한 챠징 및 디스챠징 시간을 포함한다.

언로딩은 로딩의 반대이다. 로딩과 마찬가지로, 언로딩은 한번에 기껏해야 2개의 로트들(130)의 서브 배치들에서 수행된다. 따라서, 6개의 로트들(예를 들어, 로트들(L₅ 내지 L₁₀))을 갖는 배치는 자원 카렌다(예를 들어, 자원 카렌다(518)) 상에 3개의 서브 배치 언로드 약속들(예를 들어, 언로드 약속들(592 내지 594))을 갖 는다. 각 언로드 약속들(592 내지 594) 또한 로트 스케줄링 카렌다들(512 내지 517) 상에 2개의 대응 약속들(특정 서브 배치 언로드의 각 참가자에 대해 하나씩)을 갖는다. 언로드 약속(592)은 로트 카렌다들(516, 517) 상에 대응하는 언로드 약속들(588, 587)을 갖고; 언로드 약속(593)은 로트 카렌다들(514, 515) 상에 대응하는 언로드 약속들(585, 586)을 가지며; 그리고 언로드 약속(594)은 로트 카렌다들(512, 513) 상에 대응하는 언로드 약속들(583, 584)을 갖는다. 주목할 사항으로서, 언로딩 시퀀스는 로딩 시퀀스와 무관하다. 로딩 시퀀스는 주로 로트들(130)의 도달 시간(EST)에 의존하고, 언로딩 시퀀스는 로트(130)의 우선순위 또는 자신의 다음 약속 시간에 의존한다. 따라서, 도시된 실시예에서는 언로딩이 로딩과 반대 순서로 수행되지만, 반드시 이럴 필요는 없다. 또한, 주목할 사항으로서, 도시된 실시예에서, 각 언로드 약속(592 내지 594)은 실제로, 언로드되고 있는 각 참가자 로트에 대한 자원 로트 언로딩 약속을 포함하는 배치 언로딩 약속이다.

도 5에서, MSA들(506, 520), LSA들(507, 521 내지 526), RSA들(508, 527) 및 PMSA(509)의 상호 작용의 결과들은 다양한 카렌다들을 비교함으로써 확인할 수 있다. 로트 공정 약속(L₁)은 [t₁,t₂] 동안 머신 카렌다(501) 상에, 레티클 카렌다(540) 상에, 그리고 동일한 기간 동안 로트 카렌다(520) 상에 T₁으로서 스케줄링된다. 하지만, 주목할 사항으로서, MSA(506)는 셋업(S₁)을 고려하고, LSA(507)는 이 약속의 스케줄링시 이동(M₁)을 고려한다. 유사하게, PM은 툴(T₁)에 대해 머신 카렌 다(501) 상에 그리고 기간 [t₄,t₆] 동안 PM 카렌다(504) 상에 스케줄링되고, Qual은 기간 [t₆,t₈] 동안 머신 및 PM 카렌다들(501, 504) 상에 스케줄링된다. 로딩, 챠징, 디스챠징 및 언로딩 단계들을 요구하는 배치 공정 동작들에 대해, 로트 로드 약속 및 로트 언로드 약속은 로트 카렌다들(512 내지 517) 상에 스케줄링되고, 로트 카렌다 상의 것들과 같은 시간 간격을 갖는 배치 로드 약속 및 배치 언로드 약속은 로딩 자원 카렌다(518) 상에 스케줄링된다. 배치 로트 공정 약속은 [t₆,t₈] 동안 머신 카렌다(511) 상에 스케줄링되고, [t₆,t₆₁] 동안의 배치 챠지 약속 및 [t₇,t₈] 동안의 배치 디스챠지 약속은 로딩 자원 카렌다(518) 상에 스케줄링된다.

따라서, 도 3과 관련하여 상기 설명한 약속들은 각 스케줄링 에이젼트, 예를 들어 스케줄링 에이젼트들(305, 310 및 315)에 의해 유지되는 카렌다들, 예를 들어 카렌다들(345, 370, 385) 상에 예약된다. 하지만, 상기의 스케줄링 설명으로부터 명백한 바와 같이, 예약된 약속들은 새로운 약속들의 스케줄링을 수용할 수 있도록 변경되어야 한다. 예약된 약속들은 시프트, 범핑, 축소, 확장, 중단, 취소 및 재스케줄링될 수 있다. 이러한 변경들은 상황에 따라 소비자들, 제공자들, 또는 부차적인 자원들에 의해 개시될 수 있다.

예를 들어, 예약된 약속들은 시프트될 수 있다. 상기 설명한 바와 같이, 대부분의 약속들은 커미트먼트 윈도우를 갖는다. 약속들은 "스트링 위의 비드들(beads on a string)"로서 보여진다. 기존의 약속들은 필요에 따라 자신들의 각 커미트먼트 윈도우들 내에서 뒤 또는 앞으로 밀릴 수 있으며, 이에 따라 스케줄링 에 이젼트가 보다 효율적인 스케줄을 생성하고 갑작스런 이벤트들에 반응할 수 있는 유연성을 갖는 카렌다를 제공할 수 있게 된다. 도시된 실시예에서는, 논리를 단순화하기 위해, 약속들은 어느 방향으로든 다음 약속을 지나 시프트할 수 없다.

예를 들어, 도 6에 개념적으로 도시된 카렌다를 고려하자. 이 카렌다는 각각 3개의 로트들(LOT₁ 내지 LOT₃)에 대해 예약된 3개의 약속들(APP₁ 내지 APP ₃)을 갖는다. 주목할 사항으로서, 각 약속(APP₁ 내지 APP₃)은 대응하는 커미트먼트 윈도우(CW₁ 내지 CW₃) 내에서 각각 예약된다. 이 스케줄을 유지하는 제공자가 LOT₄에 대해 APP₄를 스케줄링하기를 원한다고 가정하자. 제시되는 약속 시간 슬롯 [TS₄,TE₄]은 예약된 약속(APP₂)에 대해 스케줄링된 약속 시간[TS₂,TE₂]과 충돌한다. 하지만, 약속(APP₂)은 자신의 커미트먼트 윈도우(CW₂) 내에 시프트하기 위한 충분한 공간을 갖기 때문에, 약속(APP₄)이 스케줄링될 수 있다. 본 특정 예에서, 약속(APP₂)이 자신의 커미트먼트 윈도우(CW₂) 내에 오른쪽으로 또는 보다 늦은 시간으로 시프트됨으로써, 약속(APP₄)이 스케줄링되고 예약될 수 있다.

구현에 따라, 이러한 종류의 시프팅에 대한 다양한 시도가 이루어질 수 있다. 예를 들어:

ㆍ 예약된 약속은, 이 약속이 스케줄링 갭 또는 왼쪽으로 시프트될 수 있는 다른 약속들에 의해 앞설 수 있는 경우, 및 이 약속을 보다 이른 시작 시간(TS)으 로 시프팅함으로써 생성되는 빈 시간 슬롯에 후보 약속을 스케줄링할 수 있는 경우, 보다 이른 시작 시간(TS)으로의 시프팅에 대해 고려될 수 있다.

ㆍ 예약된 약속(들)은 이 예약된 약속(들) 바로 앞의 스케줄에 어떠한 갭도 없거나 쓸 수 없는 갭이 있는 경우(즉, 후보 약속을 끼울 수 없다), 보다 늦은 시작 시간(TS)으로의 시프팅에 대해 고려될 수 있으며, 이러한 예약된 약속(들)이 보다 늦은 시간 시간(TS)으로 시프트된 후에는 후보 약속이 갭을 없앨 것이다.

ㆍ 스케줄 갭이 셋업을 앞서는 경우, 이 셋업은 보다 이른 시작 시간으로 시프트됨으로써, (동일한 셋업을 갖는) 새로운 약속이 이 동일한 셋업을 이용하는 예약된 약속의 바로 앞에 부가될 수 있게 된다.

ㆍ 어떠한 셋업이 동일한 셋업을 요구하는 예약된 약속을 바로 다음의 보다 이른 시작 시간으로 시프트되는 경우, 이 셋업은 제거될 수 있다.

ㆍ 어떠한 셋업이 동일한 타입의 셋업 다음으로 시프트되는 경우, 이 셋업은 제거될 수 있다.

또한, 시프팅은 단지 단일 예약 약속을 시프팅하는 것 보다 복잡해질 수 있다. 도 7은 이러한 상황을 나타내는바, 여기에서는 몇 개의 예약된 약속들이 "직렬" 방식으로 시프트되어, 새로운 약속(APP₅)의 스케줄링을 수용한다. 도 7에서는, 약속(APP₁)이 이미 예약된 시간에 약속(APP₅)을 스케줄링하고자 한다. 이 경우, 예약된 모든 약속들(APP₁ 내지 APP₄)의 커미트먼트 윈도우는 새로운 약속(APP₅)에 대한 시간 슬롯을 할당하기 위해 이 약속들을 "직렬" 방식으로 왼쪽(보다 이른 시작 시간)으로 시프트시킬 수 있을 만큼 충분히 넓다. "직렬 왼쪽 시프트(cascading left shift)" 및 "직렬 오른쪽 시프트(cascading right shift)" 이동들의 시퀀스를 결합시킴으로써 형성되는 보다 복잡하고 강력한 시프팅 루틴을 이용하여, 새로운 약속을 위해 카렌다 상에 시간 슬롯을 오픈시킨다.

공정 윈도우 및 커미트먼트 윈도우 외에, 각 약속은 약속의 특성에 따라 다른 속성들을 가질 수 있다. 예를 들어, 이동 약속은 속성들, 즉 이동의 소스 및 목적지를 나타내는 소스 위치 및 타겟 위치를 가질 것이다. 로트 공정 약속은 속성들, 즉 약속의 다이내믹한 가장 이른 시작 시간을 계산하는 데에 이용하게 될 이송 시작 시간 및 남아있는 이송 시간을 가질 것이다. 공정 동작에 로딩 동작이 포함되는 경우, 대응하는 로트 공정 약속은 2개의 여분의 속성들, 즉 로드 시작 시간 및 남아있는 로드 시간을 가질 것이다. 따라서, 이러한 로트 공정 약속의 다이내믹한 EST는 현재 시간 및 스태틱 EST와 함께 이러한 4개의 속성들로부터 얻어질 수 있다.

일부 약속들은 일부 동일한 특성들을 공유할 것이다. 예를 들어, 모든 약속들은 공정 윈도우 및 약속 ID를 갖고; 모든 로트 약속들은 로트의 레퍼런스를 가질 것이며; 모든 배치 약속들은 모든 배치 참가자들의 리스트를 가질 것이다. 도시된 실시예에서, 약속 클래스는 코드 유지 작업을 보다 용이하게 하고 보다 효율적이게 하는 계층 구조로 구성된다. 도 9A가 이러한 계층 구조를 도시한다.

도 9B는 도시된 실시예에서 약속들이 존재할 수 있는 상태도(900)이다. 어떠한 소정의 시간에서, 각 약속은 임시(tentative)(905), 준비안됨(910), 준비(915), 액티브(920), 공정(925), 거의 완료(930), 완료(935), 또는 중단(940)의 상태를 가질 것이다. 주목할 사항으로서, 도시된 실시예에서, PM들 및 Qual들은 또한 액티브 PM/Qual(945) 또는 공정 PM/Qual(950) 상태에 있을 수 있다. 카렌다들을 유지하는 스케줄링 에이젼트들은 특정한 이벤트가 발생할 때 약속 상태를 변경한다.

예를 들어, 로트 공정 약속이 최초로 생성될 때, 이는 "임시" 상태로 할당된다. 이 약속이 공정 툴 카렌다 상에 예약될 때, MSA는 약속 상태를 "임시"(905) 상태에서 "준비안됨"(910)으로 변경할 것이다. 로트(130)가 공정 툴(115)의 I/O 포트(미도시)에 도달하면, MSA는 공정 상태를 "준비"(915)로 변경할 것이다. 약속의 시작 시간에 도달하면, MSA는 약속 상태를 "액티브"(920)로 변경할 것이다. 공정 툴(115)의 장비 인터페이스로부터 로트(130)가 공정 툴(115) 상에서 공정을 실제로 시작했음을 나타내는 메세지를 수신한 후, MSA는 약속 상태를 "공정"(925)으로 변경한다. 공정 툴(115)의 타입에 따라, MSA는 약속 상태를 "공정"(925)으로부터 "거의 완료"(930)로 변경한다. 전형적으로, 이러한 변경은, MSA가 장비 인터페이스로부터 공정 툴(115)이 특정한 공정 단계에 도달했음을 나타내는 다른 메세지를 수신하는 경우에 이루어진다. 예를 들어, 공정 시간의 80%의 경과는 약속이 "거의 완료"임을 나타낸다. 로트(130)가 공정 툴(115) 상에서 자신의 공정을 완료하거나 또는 중단하면, MSA는 공정 상태를 "완료"(935) 또는 "중단"(940)으로 각각 변경한다.

이러한 약속 상태는 스케줄링 에이젼트들이 특정한 이벤트들에 대해 어떠한 종류의 응답을 취해야하는 지를 결정하는 것을 돕는다. 예를 들어, MSA가 공정 툴 (115)이 현재 다운되었음을 나타내는 머신 다운 이벤트(미도시)를 수신하고, 현재 약속이 "액티브"(920) 또는 "공정"(925) 상태에 있다면, MSA는 어떠한 행동을 취해야 한다. 도시된 실시예에서, MSA는 먼저 약속을 축소시킴으로써, 이 약속의 종료 시간이 상기 머신 다운 이벤트가 수신되었던 시간으로 설정되도록 할 것이다. 이후, MSA는 약속 상태를 "중단"(940)으로 변경하고, 이 중단된 약속 이후의 다운된 공정 툴(115)에 대한 모든 약속들을 취소하며, 이에 따라 다운타임 약속을 예약할 수 있다. 하지만, MSA가 머신 다운 이벤트를 수신할 때 "액티브"(920) 또는 "공정"(925) 상태의 어떠한 현재 약속도 없다면, MSA는 그의 카렌다 상의 미래의 모든 약속들을 취소하고 다운타임 약속을 예약할 것이다.

바람직하지 않은 약속 시프팅을 막기 위해, 도시된 실시예는 로킹 메커니즘(locking mechanism)을 이용한다. 일반적으로, 로트(130)가 소스 위치로부터 공정 툴(115)의 머신 포트로 자신의 마지막 이동을 시작할 때에는, 어떠한 약속을 취소하거나, 또는 이 약속을 오른쪽 또는 시간적으로 보다 늦게 시프트시킴으로써, 이 약속 앞에 새로운 약속을 점프시키는 것은 바람직하지 않다. 이것이 발생하는 것을 막기 위해, LSA(305)가 MSA(310)에게 머신 포트를 예약(reserve)할 것을 요구하면, MSA(310)는 로트(130)가 자신의 최종 이동을 시작할 때 로트 공정 약속을 "로트"시킨다. 하지만, 종종, 로크된 약속들은 시프트될 필요가 있다. 예를 들어, 특정한 공정 툴(115)에 대한 카렌다 상에 2개의 약속들이 예약되고, 제 1 약속이 공정 처리되는 동안, 제 2 약속을 위해 로트(130)가 공정 툴(115)의 포트로 이동하고 있다고 가정하자. 제 2 약속은 로크되는데, 그 이유는 로트가 공정 툴(115)로의 자신의 최종 이동 상태에 있기 때문이다. 제 1 약속이 오래 실행되어 확장되어야 하는 경우, 이 제 1 약속이 확장될 수 있도록 제 2 약속이 먼저 시프트된다. 따라서, 일반적으로 바람직하지 않다고 하더라도, 로크된 제 2 약속은 시프트된다. 이러한 경우들에서는, 로크된 약속들을 다루도록 특별히 설계된 어떠한 특별한 카렌다 시프트 루틴들을 이용한다. 로크된 약속들의 시프팅은 환경에 따라 에이젼트의 결정으로 수행된다. 상기 언급한 상황에서, 로크된 제 2 약속이 보다 이른 시작 시간을 갖는 어떠한 다른 곳으로 재스케줄링될 가능성은 없다.

상기 설명으로부터 명백한 바와 같이, 일부 약속들은 다른 카렌다들 상의 "대응" 약속들과 함께 스케줄링된다. "대응" 약속들은 동일 액티비티의 추진에 대해 다른 카렌다들 상에 예약된 약속들이다. 예를 들어, 도 3의 약속들(375a, 375b, 375c)은 공정 툴(115)에서 로트(130)를 공정하기 위한 "대응" 약속들이다. 예를 들어:

ㆍ 로드 약속 및 대응하는 로트 공정 약속은 각각 로트 스케줄링 카렌다 및 머신 스케줄링 카렌다 상에 나타날 것이며;

ㆍ PM 약속 및 대응하는 머신 PM 약속은 각각 PM 스케줄링 카렌다 및 머신 스케줄링 카렌다 상에 나타날 것이며; 그리고

ㆍ 공정 동작에 대해 공정 툴에 대한 로딩 동작이 요구되는 경우, 로트 로드 약속 및 대응하는 자원 로드 약속이 각각 로트 스케줄링 카렌다 및 로딩 자원 스케줄링 카렌다 상에 나타날 것이다.

이러한 대응하는 약속들은 "동기화"된다. 즉, 한 약속의 변경은 다른 약속의 변경을 야기시킴으로써, 이들은 동일한 특성들(예를 들어, 시작 시간, 종료 시간 등)을 가질 것이다. 도시된 실시예에서, 약속 변경들은 약속 상태의 변경, 약속의 공정 윈도우의 변경, 약속의 커미트먼트 윈도우의 변경, 이송 관련 변경, 로딩 관련 변경, 언로딩 관련 변경, 이송 위치 변경 및 배치 약속 관련 변경을 포함할 수 있다. 보다 특정하게, 약속 상태의 변경은 (도 9B에서 나타낸 바와 같이):

ㆍ "준비안됨"으로의 약속 상태의 변경;

ㆍ "준비"로의 약속 상태의 변경;

ㆍ "액티브"로의 약속 상태의 변경;

ㆍ "액티브 PM/Qual"으로의 약속 상태의 변경;

ㆍ "공정"으로의 약속 상태의 변경;

ㆍ "공정 PM/Qual"으로의 약속 상태의 변경;

ㆍ "거의 완료"로의 약속 상태의 변경;

ㆍ "완료"로의 약속 상태의 변경; 및

ㆍ "중단"으로의 약속 상태의 변경을 포함할 수 있다.

공정 윈도우의 변경은:

ㆍ 공정 윈도우의 시작 시간의 시프트;

ㆍ 공정 윈도우의 종료 시간의 시프트;

ㆍ 커미트먼트 윈도우 내에서, 왼쪽 또는 보다 이른 시간으로의 공정 윈도우의 시프트;

ㆍ커미트먼트 윈도우 내에서, 오른쪽 또는 보다 늦은 시간으로의 공정 윈도 우의 시프트;

ㆍ 공정 윈도우의 계속 기간의 설정;

ㆍ 공정 윈도우의 소비 간격의 축소;

ㆍ 공정 윈도우의 공정 간격의 축소;

ㆍ 공정 윈도우의 소비 간격의 확장; 및

ㆍ 공정 윈도우의 공정 간격의 확장을 포함할 수 있다.

커미트먼트 윈도우의 변경은:

ㆍ 커미트먼트 윈도우의 계속 기간의 갱신;

ㆍ 커미트먼트 윈도우의 시작 시간의 갱신; 및

ㆍ 커미트먼트 윈도우의 종료 시간의 갱신을 포함할 수 있다.

이송 관련 변경들은:

ㆍ 남아있는 이송 시간의 설정;

ㆍ 이송 시작 시간의 설정; 및

ㆍ 이송 시작 시간 및 남아있는 이송 시간 모두의 설정을 포함할 수 있다.

로딩 관련 변경들은:

ㆍ 남아있는 로드 시간의 설정;

ㆍ 로드 시작 시간의 설정; 및

ㆍ 남아있는 로드 시간 및 로드 시작 시간 모두의 설정을 포함할 수 있다.

언로딩 관련 변경들은:

ㆍ 남아있는 언로드 시간의 설정;

ㆍ 언로드 시작 시간의 설정; 및

ㆍ 남아있는 언로드 시간 및 언로드 시작 시간 모두의 설정을 포함할 수 있다.

이송 위치 관련 변경들은:

ㆍ 소스 위치의 설정; 및

ㆍ 타겟 위치의 설정을 포함할 수 있다.

배치 약속 관련 변경들은:

ㆍ 배치로부터 참가자를 취소;

ㆍ 참가자를 배치에 합류;

ㆍ 배치로부터 참가자를 제거;

ㆍ 배치 약속에 대해 커미트먼트 윈도우 변경;

ㆍ 배치 식별 번호의 설정;

ㆍ 배치 요건 설정; 및

ㆍ 배치에 합류시키기 위해 참가자 약속의 시프팅을 포함할 수 있다.

주목할 사항으로서, 모든 약속 타입들에 대해 반드시 모든 변경 타입들이 적용가능한 것은 아니다.

대응하는 약속들의 동기화를 유지하기 위해, 도시된 실시예는 도 11에서 완전하게 도시되는 약속 변경 통지 메커니즘을 이용한다. 도 11은 도 3의 LSA(305), 로트 카렌다(385), MSA(310) 및 머신 카렌다(370)와 관련된 메커니즘을 도시한다. 하지만, 주목할 사항으로서, 도 11에 도시된 메커니즘은 어떠한 카렌다들의 세트 및 공정 흐름(100)의 대응하는 약속들에 대해 확장될 수 있다.

각 카렌다(385, 370)는 각각 자신의 약속들에 대한 변경을 발행하는 변경 통지기(1105, 1110)를 갖는다. 제공자측 또는 소비자측중 어느 하나 상에 있는 대응하는 약속들 각각은 자신이 예약된 각 카렌다(385, 370)에 대한 각 변경 통지기(1105, 1110)와 관련하여 생성된다. 대응하는 약속을 유지하는 각 스케줄링 에이젼트들(305, 310)은 각각 "변경 청취기(change listener)"(1115, 1120)를 갖는다. 이러한 변경 청취기들(1115, 1120)은 다른측 상의 대응하는 약속에 속하는 변경 통지기들(1105, 1110)에 의해 발행되는 약속 변경들에 가입(subscribe)한다. 도 11에서, 약속 변경 청취기(1115, 1120)는 (각각 1122, 1124에서) 로트 약속(TOOL₁) 및 로트 공정 약속(LOT₁)에 가입 청취기들로서 등록한다.

변경 청취기(1115, 1120)가 다른측 상의 대응하는 약속에 대한 변경 이벤트를 수신하면, 이는 자신의 각각의 스케줄링 에이젼트(305, 310)로 하여금 대응하는 약속을 찾게 한 다음, 그 약속을 적절히 조정하게 함으로써, 결과적으로 제공자측 및 소비자측 상의 약속(들)이 항상 동기를 유지할 수 있게 된다. 하지만, 약속 변경을 수신하는 스케줄링 에이젼트(305, 310)는 다르게 반응할 필요가 있다. 이 경우, 스케줄링 에이젼트는 자신의 약속(들)에 다른 변경을 행하고 이러한 변경을 청취기들(1115, 1120)에게 발행한다.

보다 특정하게, 제공자(도 3의 공정 툴(115))가 자신의 스케줄링 에이젼트(예를 들어, MSA(310))를 통해 예약된 약속(예를 들어, 머신 카렌다(370) 상의 약속 (LOT₁))을 변경하면, 이는 각각의 약속 변경 통지기(예를 들어, 변경 통지기(1110))에게 통지한다. 제공자의 변경 통지기는 (도 11의 1135에서) (소비자의 가입 청취기를 포함하여) 자신의 가입 청취기들에게 "약속 변경 이벤트"를 발행한다. 소비자의 변경 청취기(예를 들어, 변경 청취기(1115))가 상기 약속 변경 이벤트를 수신하면, 이는 소비자의 스케줄링 에이젼트(예를 들어, LSA(305))로 하여금 자신의 각 카렌다(예를 들어, 로트 카렌다(385)) 상의 대응하는 약속(예를 들어, 로트 약속(TOOL₁))에 대해 동일한 변경을 행하게 한다. 도시된 실시예의 약속 변경 이벤트는 (예를 들어, 약속의 카피와 같은) 변경된 약속에 대한 정보, 약속의 구(old) 시작 시간, 및 약속 변경의 타입과 관련된 특정 방법의 이름을 포함한다. 소비자의 변경 통지기는 자신의 스케줄링 에이젼트에서 일치하는 방법 이름을 호출하는바, 스케줄링 에이젼트는 이 정보를 이용하여 대응하는 약속을 찾아, 소비자측에서 적절한 변경을 행한다.

약간 다른 변경 통지 메커니즘이 카렌다 기록기(logger)들 및 카렌다 "그래픽 사용자 인터페이스"("GUT") 디스플레이 툴들에 의해 이용된다. 도시된 실시예에서, 각 카렌다(예를 들어, 머신 카렌다(370))는 각각의 카렌다 기록기(예를 들어, 카렌다 기록기(1140))를 갖는바, 이러한 카렌다 기록기는 카렌다 상의 약속들에 대해 발생하는 모든 변경들을 기록(log)한다. 각 카렌다 기록기는 대응하는 카렌다 상의 모든 약속들(단지 1개는 아니다)에 대한 변경에 대해 가입한 약속 변경 청취기(예를 들어, 변경 청취기(1145))를 갖는다. 카렌다 기록기 및 카렌다 GUI(예를 들어, 카렌다 GUI(1150))는, 각 개별적인 약속에 직접 가입하지 않고, 이들이 청취하는 카렌다의 변경 청취기에 자신들의 청취기를 직접 등록한다. 이에 의해, 카렌다 기록기 및 카렌다 GUI가, 새로운 약속들의 예약을 포함하여, 카렌다 상의 모든 약속들에 대한 변경을 청취할 수 있게 된다.

카렌다 상의 하나의 약속 또는 약속들의 세트가 변경되면, 상기 설명한 바와 같이 변경 청취기가 통지를 받게 될 것이다. 그러면, 변경 청취기는 카렌다 기록기로 하여금 대응하는 변경 이벤트(들)을 기록하고 카렌다를 덤프하게 한다. 이러한 방식으로, 카렌다 기록 파일에 카렌다의 전체 히스토리가 기록될 수 있다. WFT들은 GUI 디스플레이 툴들의 세트를 이용하여 카렌다를 본다. 이 경우, 컴퓨터 스크린 상에 디스플레이되는 모든 카렌다는 자기 자신의 약속 변경 청취기를 갖는다. 카렌다 기록기의 경우에서와 같이, 이러한 변경 청취기 또한 디스플레이되는 카렌다 상의 모든 약속들의 변경에 가입한다. 카렌다 상의 어떤 것이 변경되면, 이 변경 청취기는 그 약속의 변경 청취기에 의해 통지를 받게 될 것이며, 이는 디스플레이된 카렌다의 리프레시를 자동적으로 야기시킬 것이다.

약속을 변경하는 하나의 공통적인 이유는 "이른 시작"의 장점을 이용하기 위해서이다. 예를 들어, 도 3의 MSA(310)가 자신의 스케줄을 실행하는 동안 아이들 시간에 직면하게 되면, 이 MSA(310)는 다음 약속을 보다 이른 시작 시간으로 시프트시킨 다음, 즉시 시작되게 할 것이다. 이러한 경우는 도 8A에 나타내었는바, 여기서 현재 시간(t_c)은 다음 약속(APP₁)에 대한 커미트먼트 윈도우(CW₁) 내에 있다. 다음 약속(APP₁)이 왼쪽 또는 보다 이른 시간으로 시프트됨으로써, 이 약속의 공정은 즉시 시작되거나, 또는 아마도 자신의 현재 시작 시간 보다 일찍 시작될 수 있을 것이다. 이에 의해, 공정 툴(115)의 아이들 시간을 피할 수 있다.

대안적인 실시예들중 하나에서, 다음 예약 약속이 현재 시간에서 시작되도록 시프트될 수 없다면, MSA(310)는 현재 시간 또는 보다 일찍 시작하는 커미트먼트 윈도우를 가질 수 있는 다른 어떠한 예약된 약속들을 찾을 것이다. 이러한 예약된 약속들중 하나가 다른 어떠한 예약된 약속들을 취소시키지 않으면서 즉시 시작되도록 이동할 수 있다면, 이 예약된 약속은 "점프 오버" 방식으로 이동할 것이며, 다른 예약된 약속들은 필요에 따라 시프트될 것이다. 도 8B가 이러한 방식을 나타내는바, 여기서 제공자가 아이들한 현재 시간(t_c)은 다음 예약된 약속(APP₁)의 커미트먼트 윈도우(CW₁) 바깥에 있지만, 제 3의 예약된 약속(APP₃)의 커미트먼트 윈도우(CW₃) 내에 있다. 이에 따라, 제 3 약속(APP₃)은 왼쪽 또는 보다 이른 시간으로 점프 오버되고, 약속들(APP₁ 및 APP₂)은 각각 "직렬" 방식으로 오른쪽 또는 보다 늦은 시간으로 시프트된다.

주목할 사항으로서, 다음 예약된 약속 이외의 약속이 시작 위치로의 이동에 대해 고려되는 경우에는, 셋업이 고려된다. 시작 위치로 이동하는 예약된 약속 이전 및 이후에, 셋업을 부가할 필요가 있다. 이러한 타입의 이동은, 여분의 셋업 시간의 합이 다음 약속의 가장 이른 시작 시간까지 남아있는 아이들 시간 보다 적을 경우에만 고려되어야 한다.

또한, 약속들은 자신의 계속 기간, 또는 앞선 약속의 계속 기간이 기대했던 것 보다 짧거나 또는 길 때에 종종 변경된다. 도 10A 및 도 10B는 이러한 2개의 상황들을 도시한다. 도 10A에서는, 로트 스케줄링 카렌다 상의 이동(M₃)이 확장되었는데, 이는 이송이 기대했던 것 보다 오래걸렸기 때문이다. 이에 따라, 이동들(M₄, M₅) 및 약속(APP₂)은 이러한 보다 긴 계속 기간을 수용할 수 있도록 오른쪽으로 시프트되었다. 주목할 사항으로서, 공정 약속(APP₂)의 시프팅은, 수용할 수 있는 경우(만일 수용할 수 없다면, MSA(310)는 약속을 시프트시키는 대신 이 약속을 취소할 수 있다), 머신 카렌다 상의 대응하는 약속(미도시)을 동일하게 시프트시킬 것이다. 도 10B에서는, 약속(APP₃)이 기대했던 것 보다 오래 걸려 확장되었으며, 이에 따라 약속들(APP₄ 및 APP₅)은 오른쪽으로 시프트되었다. 이러한 약속들(APP₄ 및 APP₅)의 시프팅은 각각의 로트 카렌다들 상의 대응하는 약속들의 동일한 시프트들을 야기시킨다. 주목할 사항으로서, 도 10A 및 도 10B에서, 예시된 변경들은 양쪽 모두의 환경들에서, 변경된 약속들에 대한 커미트먼트 윈도우들이 변경을 수용할 수 있을 정도로 충분히 넓었다는 것을 필수적으로 수반한다. 커미트먼트 윈도우들이 충분히 넓지 않다면, 일부 약속들은 취소되어야 한다.

바로 위에서 언급한 바와 같이, 예약된 약속들은 또한 취소될 수 있다. 로트(130)에 대한 약속 변경 청취자는, 예를 들어 공정 툴(115)이 예약된 약속을 자신 의 커미트먼트 윈도우 내에 더 이상 유지할 수 없을 경우, 공정 툴(115)의 변경 통지기로부터 "취소" 약속 변경 이벤트를 수신할 수 있다. LSA(305)가 변경 청취기를 통해 약속 취소 이벤트를 수신하면, 이는 자기 자신의 로트 카렌다(385)로부터 대응하는 로트 약속을 제거하고 공정 약속을 재스케줄링할 것이다.

스케줄링된 약속들 취소하는 하나의 공통의 이유는 "범핑"이다. 공정 툴(115)이 보다 높은 우선순위를 갖는 로트 또는 그 스케줄 뒤에 이미 있는 로트에 대해 새로운 비드(365)를 확인하는 것이 보다 유익하다. 이에 의해, 기존의 약속들이 요구되는 시간 간격을 충분히 클리어할 수 있도록 시프트될 수 없다면, 머신 카렌다(370) 상의 1개 또는 그 이상의 기존의 약속들은 취소된다. 배치 공정 툴 상에서, 예약된 배치 약속의 참가자는 동일한 이유로 배치로부터 "범핑"될 수 있다. 종종, 배치 약속은 심지어 기존의 참가자를 범핑함으로써 보다 긴급한 로트를 수용할 수 있도록 오른쪽 또는 보다 늦은 시간으로 시프트되어야 한다.

공정 툴(115) 또는 로트(130)가 약속이 취소될 것을 요구한다면, 전형적으로 단지 그 하나의 특정 약속 만이 취소된다. 약속 변경 통지 메커니즘때문에, 공정 툴(115) 및 로트(130) 모두는 자신들의 각 카렌다들(370, 385)로부터 약속을 제거할 것이다. 하지만, 일부 실시예들에서, 하나의 약속을 취소하게 되면, 이전에 예약된이후의 모든 약속들은 취소될 수 있다. 예를 들어, LSA가 사전에 예약된 다수의 로트 약속들을 가지고 있고, 하나의 중간 로트 약속이 취소된다면, 이후의 모든 약속들(이동, 로트 약속, 로드 및 언로드)은 취소된다. 마지막 로트 약속이 취소된다면, 그 공정 툴(115)을 리드하는 모든 이동 약속들, 및 그 로트 약속 이후의 가 능한 로트 로드 약속, 로트 언로드 약속 및 이동 약속은 취소될 수 있다. 이후, LSA는 취소된 공정 동작들에 대한 재스케줄링을 시작할 것이다. 반면, 머신 스케줄링 카렌다 상에서는, 범핑으로 인한 예약된 약속의 취소가 범핑된 약속 다음에 오는 모든 약속들을 반드시 취소시키지는 않는다. 새롭게 예약된 약속의 삽입에 의해 이후의 약속들에 필요 셋업을 제거 또는 변경한다면, 범핑 비드는 상기 새롭게 예약된 약속 다음에 오는 셋업 약속을 스케줄링할 필요가 있다.

주목할 사항으로서, 예약된 약속들이 시프트, 축소, 확장, 취소 및 재스케줄링될 때, 이러한 변경들은 공정 흐름 및 특히 카렌다들에 파문(ripple)을 일으킬 수 있다. 단일 소프트웨어 에이젼트에 의해 변경들이 이루어지지만, 각 변경된 약속은 다수의 카렌다들 상에 예약된 대응하는 약속들을 가질 수 있다. 결과적으로, 이러한 변경들이 다른 소프트웨어 에이젼트들에 전달됨으로써, 이 소프트웨어 에이젼트들이 바로 위에서 설명한 바와 같이 자신들의 각 카렌다들을 갱신할 수 있게 된다. 하지만, 다른 카렌다들 상의 대응하는 약속들이 변경되면, 통지가 억제됨으로써, 그 에이젼트에게 변경이 이루어졌음을 통지하지 않는다. 그렇지 않다면, 2개의 스케줄링 에이젼트들 간에는 변경 통지의 무한 루프가 형성될 것이다.

도시된 실시예에서는, 이러한 종류의 바람직하지 않은 변경 통지의 증식을 막기 위해, 변경 이벤트 등록 방식이 이용된다. 보다 구체적으로, MSA가 로트 약속에 대한 변경을 수신하면, 변경 이벤트가 머신 스케줄링 카렌다에 대한 리스트(미도시) 내에 등록된다. 이후에, MSA가 자신의 카렌다 상의 대응하는 로트 공정 약속에 대한 변경 통지를 전송할 준비가 되면, 이 MSA는 먼저 등록된 모든 변경 이벤트 들을 체크할 것이다. 이 경우, 일치하는 이벤트가 발견될 것이며, MSA는 이 이벤트를 LSA로부터 비롯된 반응적 변경 이벤트로서 해석할 것이다. 따라서, 머신측 상에서는 그 이상의 어떠한 행동도 요구되지 않으며, MSA는 단지 상기 일치하는 변경 이벤트를 리스트로부터 제거할 것이다. 하지만, 카렌다 기록기들 및 카렌다 GUI와 같은 비 에이젼트(non-agent) 약속 청취기들은 적절한 약속 변경들을 항상 통지받는다. 이는, 변경이 개시되었건, 반응적 변경이건 간에 상관없이 이루어지는데, 그 이유는 이러한 타입의 응용들의 전형적으로 단지 1개의 카렌다 만을 청취하기 때문이다.

상기 설명한 약속들의 변경 능력은, 공정 흐름, 예를 들어 도 1의 공정 흐름(100)의 효율성 및 효능을 개선하기 위해 보다 복잡한 방식으로 카렌다들을 관리하는 능력에 대해 단지 지엽적인 것이다. 본 발명의 카렌다링 기술에 의해 다양한 약속들에 대해 강요되는 구조의 힘은, 관련된 카렌다들이 비교적 혼합해질 때에 가장 분명해진다. 카렌다들이 비교적 혼합하지 않거나, 또는 카렌다링 기술이 비교적 원시적이라면, 스케줄링이 용이해진다. 예를 들어, 약속들은 "선착 우선(first come first served)"에 기초하여 스케줄링될 수 있다. 혼잡하지 않은 카렌다 상에서, 이는 큰 관심사가 아닌데, 그 이유는 많은 시간 및 많은 자원들이 있기때문에, 로트의 우선순위와 같은 고려 사항들이 덜 중요하기 때문이다. 충분한 공정 자원들이 있기 때문에, 상대적으로 문제가 거의 발생하지 않는다. 혼합한 카렌다들 상에서는, 이것이 더 이상 적용될 수 없다.

본 발명의 복잡한 카렌다링 기술은 공정 흐름(100)의 서로 다른 로트들(130) 의 우선순위 또는 중요도를 고려하여, PM들 및 Qual들의 기회적인 스케줄링을 허용하며, 다른 많은 강력한 카렌다 관리 성능들을 용이하게 한다. 이러한 성능들중 일부는 소정의 카렌다 상에 예약된 약속들이 새로운 약속을 예약하기 위한 적절한 슬롯을 생성하도록 관리될 수 있는 지의 여부를 결정하는 데에 유용하다. 실제로, 이러한 성능들중 일부는 시간 슬롯을 생성하기 위해, 예약된 약속들을 시프트, 범핑 또는 취소함으로써 이러한 예약된 약속들을 관리한다. 본원에서 설명되는 카렌다링 기술의 힘을 설명하기 위해, 이러한 몇 개의 성능들에 대해 하기에서 상세히 설명한다.

상기 설명한 바와 같이, 도시된 실시예에서, 다양한 소프트웨어 에이젼트들(265)은 객체 지향 프로그래밍 환경에서 "객체들"로서 구현된다. 관리 성능들은 소프트웨어 에이젼트들(265)인 객체들에 의해 호출되는 "방법들"을 통해 구현된다. 이러한 방법들은 또한 다른 방법들을 호출할 수 있다. 이러한 방법들중 일부는 제시되는 행동의 실행 가능성을 결정한다. 실제로 이러한 방법들중 일부는 제시되는 행동을 구현한다. 하지만, 이것들과 같은 세부 사항들은 구현 마다 특정되며, 실시예들에 따라 달라질 것이다. 예를 들어, 일부 실시예들은 실행가능성을 결정하고 동일한 방법 내에서 행동을 구현할 것을 선택할 수 있다. 실제로, 일부 실시예들은 OOP 기술 조차도 이용하지 않으며, 이에 따라 동일한 기능들을 수행하기 위한 대안적인 접근들이 이용된다. 이를 유념하여, 이제 카렌다 관리 성능들의 구현에 대해 설명한다.

도시된 실시예는 보다 강력한 일부 기술들에 대해 "기초적" 또는 "기본적"인 것으로 고려될 수 있는 다수의 관리 기술들을 이용한다. 이러한 기초적 기술들은 또한 카렌다 액세서(accessor) 방법, 카렌다 갱신 방법, 약속 카렌다 갱신 방법 및 약속 액세서 방법으로서 분류될 수 있다. 일 특정 실시예에서, 카렌다 액세서 방법은:

ㆍ 이전에 식별된 다수의 약속들을 얻고;

ㆍ 액티브한 약속을 얻고;

ㆍ 제 1 약속을 얻고;

ㆍ 마지막 약속을 얻고;

ㆍ 이전 약속을 얻고;

ㆍ 다음 약속을 얻고;

ㆍ 이전에 식별된 특정 약속을 얻고;

ㆍ 소정의 시간 후에 끝나는 제 1 약속을 얻고;

ㆍ 소정의 시간 후에 시작하는 제 1 약속을 얻고;

ㆍ 소정의 시간 이전에 끝나는 마지막 약속을 얻고;

ㆍ 소정의 시간 이전에 시작하는 마지막 약속을 얻고; 그리고

ㆍ 겹치는 약속들을 얻는 것을 포함한다.

기본적인 카렌다 갱신 방법은:

ㆍ 소정의 시간 이후에 모든 약속들을 취소하고; 그리고

ㆍ 필요한 경우, 셋업을 삽입하는 것을 포함한다.

기본적인 약속 갱신 방법은:

ㆍ 새로운 약속을 예약하고;

ㆍ 예약된 약속을 취소하고;

ㆍ 예약된 약속을 확장하고;

ㆍ 예약된 약속을 축소시키고;

ㆍ 예약된 약속을 왼쪽 또는 보다 이른 시간으로 시프트시키고;

ㆍ 예약된 약속을 오른쪽 또는 보다 늦은 시간으로 시프트시키고;

ㆍ 예약된 약속의 시간 시간을 시프트시키고;

ㆍ 예약된 약속의 종료 시간을 시프트시키고;

ㆍ 예약된 약속의 소비 간격을 축소시키고;

ㆍ 예약된 약속의 소비 간격을 확장하고;

ㆍ 예약된 약속의 공정 간격을 축소시키고;

ㆍ 예약된 약속의 공정 간격을 확장하고;

ㆍ 예약되고 로크된 약속을 왼쪽 또는 보다 이른 시간으로 시프트시키고;

ㆍ 약속이 새로운 셋업을 요구하지 않는 경우, 예약되고 로크된 약속을 왼쪽 또는 보다 이른 시간으로 시프트시키고;

ㆍ 약속이 새로운 셋업을 요구하는 경우, 예약되고 로크된 약속을 왼쪽 또는 보다 이른 시간으로 시프트시키고;

ㆍ 변경 청취기를 부가하고;

ㆍ 배치 약속의 식별 번호를 설정하고;

ㆍ 식별 번호를 설정하고; 그리고

ㆍ 약속을 로크시키는 것을 포함한다.

기본적인 약속 액세서 방법은:

ㆍ 약속의 계속 기간을 얻고;

ㆍ 약속의 시작 시간을 얻고;

ㆍ 약속의 종료 시간을 얻고;

ㆍ 약속의 공정 윈도우의 계속 기간을 얻고;

ㆍ 약속의 스태틱 EST를 얻고;

ㆍ 약속의 가장 이른 로드 시간을 얻고;

ㆍ 약속의 EST를 얻고;

ㆍ 약속의 가장 늦은 종료 시간을 얻고;

ㆍ 약속의 이송 시작 시간을 얻고;

ㆍ 약속의 남아있는 이송 시간을 얻고;

ㆍ 약속의 로드 시작 시간을 얻고;

ㆍ 약속의 남아있는 로드 시간을 얻고;

ㆍ 약속의 언로드 시작 시간을 얻고;

ㆍ 약속의 남아있는 언로드 시간을 얻고;

ㆍ 약속의 공정 계속 기간을 얻고;

ㆍ 약속의 공정 시작 시간을 얻고;

ㆍ 약속의 공정 종료 시간을 얻고;

ㆍ 약속의 커미트먼트 윈도우의 계속 기간을 얻고;

ㆍ 약속의 커미트먼트 윈도우의 시작 시간을 얻고;

ㆍ 약속의 커미트먼트 윈도우의 종료 시간을 얻고;

ㆍ 약속의 소비 간격의 계속 기간을 얻고;

ㆍ 약속의 소비 간격의 시작 시간을 얻고;

ㆍ 약속의 소비 간격의 종료 시간을 얻고;

ㆍ 변경 청취기를 얻고;

ㆍ 약속의 식별 번호를 얻고;

ㆍ 배치 약속의 식별 번호를 얻고;

ㆍ 약속이 로크되었는 지의 여부를 식별하고;

ㆍ 약속에 대해 셋업이 필요한 지의 여부를 식별하고;

ㆍ 약속에 대해 셋업이 필요한 지의 여부를 결정하고;

ㆍ 이전 셋업이 약속에 대한 셋업 요건과 호환성인 지의 여부를 결정하고;

ㆍ 약속에 대해 자원 참가자들을 식별하고;

ㆍ 왼쪽으로의 시프트의 실행 가능성을 결정하고;

ㆍ 어떠한 셋업도 요구하지 않는 로크된 약속이 왼쪽으로 시프트될 수 있는 지의 여부를 결정하고;

ㆍ 셋업을 요구하는 로크된 약속이 왼쪽으로 시프트될 수 있는 지의 여부를 결정하고;

ㆍ 오른쪽으로의 시프트의 실행 가능성을 결정하고;

ㆍ 로크된 약속이 오른쪽으로 시프트될 수 있는 지의 여부를 결정하고;

ㆍ 시작 시간이 시프트될 수 있는 지의 여부를 결정하고;

ㆍ 어떠한 셋업도 요구하지 않는 로크된 약속의 시작 시간이 시프트될 수 있는 지의 여부를 결정하고;

ㆍ 셋업을 요구하는 로크된 약속의 시작 시간이 시프트될 수 있는 지의 여부를 결정하고;

ㆍ 약속의 종료 시간이 시프트될 수 있는 지의 여부를 결정하고; 그리고

ㆍ 로크된 약속의 종료 시간이 시프트될 수 있는 지의 여부를 결정하는 것을 포함한다.

주목할 사항으로서, 모든 방법들이 모든 약속들, 또는 심지어 소정 타입의 모든 약속들에게 다 균일하게 적용되는 것은 아니다. 하지만, 도시된 실시예에서, 이러한 방법들은 이하에서 설명되는 보다 강력한 방법들을 구현하는 데에 필요한 기본적인 기능들을 총괄적으로 제공한다.

혼잡한 카렌다 상에 약속들을 스케줄링함에 있어서 하나의 중요한 작업은 카렌다 상에 슬롯들을 "오픈" 또는 "클리어"하는 능력이다. 카렌다 상의 혼잡성이 증가한다는 것은, 새로운 약속들을 예약하기 위한 충분한 언커미트된(uncommitted) 시간을 찾는 것이 더욱 어렵다는 것으로 해석된다. 어떠한 예약된 약속에 대한 카렌다 상의 커미트된 시간이 커미트먼트 윈도우에 의해 정의되고, 공정 윈도우들이 커미트먼트 윈도우 내에서 밀릴 수 있기 때문에, 새로운 약속들이 예약될 수 있는 슬롯들을 오픈 또는 클리어하도록 예약된 약속들을 조정하는 데에 있어서 어떠한 유연성이 존재하게 된다. 도시된 실시예는 슬롯들의 오프닝 및 슬롯들의 클리어링 을 포함하여 몇 개의 기술들을 이용한다.

슬롯을 오픈시키기 위해, 스케줄링 에이젼트는 openSlotFeasibility 방법을 호출함으로써 시작한다. 이 방법은 비드 발생 동안 광범위하게 이용되어, 서로 간에 충분한 시간을 갖지 않는 예약된 약속들 간에 슬롯을 오픈시키고자 시도함으로써 머신 카렌다 상의 빈 슬롯 비드들을 찾는다. 이는 또한 비드 확인 동안 이용되어, 카렌다 상에 이미 있는 약속들을 취소하는 대신 슬롯을 오픈시킴으로써 어떠한 약속이 예약될 수 있는 지의 여부를 결정한다. 이 방법은 지정된 시작 시간에서 시작하는 카렌다 상에서의 지정된 계속 기간을 갖는 슬롯을 오픈시킬 수 있는 실행 가능성을 결정한다. 프리 셋업(pre-setup) 또는 포스트 셋업(post-setup) 약속들이 요구되는 경우, 이 방법은 요구되는 계속 기간 외에 셋업 약속들을 충분히 수용할 수 있을 정도로 큰 슬롯을 오픈시킬 수 있는 실행 가능성을 결정한다. 이러한 openSlotFeasibility 방법은 입력들로서:

ㆍ 셋업을 제외한, 슬롯에 대해 요구되는 시작 시간;

ㆍ 셋업 시간을 포함하지 않는, 슬롯의 요구되는 계속 기간; 및

ㆍ 슬롯에 대해 요구되는 어떠한 셋업을 수신한다.

이러한 openSlotFeasibility 방법은 출력들로서:

ㆍ 슬롯을 오픈시키는 것이 실행가능한 지의 여부를 나타내는 불 논리 표시자(Boolean indicator);

ㆍ 실행가능한 슬롯에 대한 실제 슬롯 시작 시간(이는, 요구되는 경우, 셋업에 대한 시작 시간이 될 수 있다);

ㆍ 실행가능한 슬롯에 대한 실제 슬롯 종료 시간;

ㆍ 공정 시작 시간(이는 셋업이 요구되는 경우 슬롯 시작 시간 보다 늦을 수 있다);

ㆍ 셋업 시간의 순수 변경(net change); 및

ㆍ 실행가능한 슬롯을 오픈시키는 데에 필요한 약속 행동들의 리스트를 돌려준다.

상기 openSlotFeasibility 방법은 슬롯을 오픈시킬 수 있는 가능성을 결정하기 위해 2개의 다른 방법들, 즉 cascadeLeftShiftFeasibility 방법 및 cascadeRightShiftFeasibility 방법을 호출하는바, 이러한 방법들에 대해서는 하기에서 설명한다.

보다 구체적으로, openSlotFeasibility 방법은 요구되는 시작 시간 이전에 시작하는 마지막 약속("이전 약속(before appointment)") 및 요구되는 시작 시간 이후에 시작하는 제 1 약속("이후 약속(after appointment)")을 결정하고, 이들 사이에 요구되는 슬롯을 오픈시킬 수 있는 지의 여부를 결정한다. 먼저, 이 openSlotFeasibility 방법은 요구되는 시작 시간 이전에 셋업을 위해 시간이 할당되어야 하는 지의 여부를 결정한다. 슬롯이 셋업을 요구하고, 상기 "이전 약속"이 호환성 셋업을 갖지 않거나, 또는 어떠한 "이전 약속"도 갖지 않는 경우, 상기 openSlotFeasibility 방법은 요구되는 시작 시간에서 셋업 계속 기간을 뺌으로써, "확장된 슬롯"의 시작 시간을 계산한다. 이러한 "확장된 슬롯"의 시작 시간은 현재 시간과 비교된 다음, 현재 시간 보다 작으면, 현재 시간으로 리셋된다. "확장된 슬 롯"의 시작 시간이 "이전 약속"의 종료 시간 보다 이르면, 이 방법은 "이전 약속"의 종료 시간과 "확장된 슬롯"의 시작 시간 간의 차이를 계산함으로써 "이전 약속"이 왼쪽으로 시프트되어야 하는 원하는 왼쪽 시프트 계속 기간을 계산한다.

이후, 상기 openSlotFeasibility 방법은 cascadeLeftShiftFeasibility 방법을 호출하여, 상기 "이전 약속"이 원하는 왼쪽 시프트 계속 기간으로 왼쪽(보다 이른 시간)으로 시프트될 수 있는 지의 여부를 결정한다. 원하는 시프트를 실행할 수 있다면, "실행가능한 슬롯 시작 시간"은 확장된 슬롯의 시작 시간으로 설정된다. 원하는 시프트를 실행할 수 없다면, cascadeLeftShiftFeasibility로부터의 응답은 "이전 약속"이 시프트될 수 있는 실제 시간량을 나타내고, "실행가능한 슬롯 시작 시간"은 "이전 약속"의 종료 시간이 만일 이 이전 약속이 왼쪽으로 시프트되는 경우 가능한 실제 시간량이 될 수 있는 것으로 설정된다. 어떠한 "이전 약속"도 없거나, 이 "이전 약속"의 종료 시간이 현재 시간 이전이라면, 이 "이전 약속"이 왼쪽(보다 이른 시간)으로 시프트될 수 있는 지의 여부를 결정해야하는 어떠한 필요성도 없다.

이후, 상기 openSlotFeasibility 방법은, 적용할 수 있는 경우, "확장된 슬롯"의 시작 시간에 입력 슬롯 계속 기간 및 셋업 계속 기간을 부가하여, "실행가능한 슬롯 종료 시간"을 계산한다. 이 openSlotFeasibility 방법은 포스트 셋업이 슬롯 이후에 필요한 지의 여부를 결정한다. 슬롯 셋업과 다른 셋업을 요구하는 "이후 약속"이 있다면, openSlotFeasibility 방법은 "실행가능한 슬롯 종료 시간"에 포스트 셋업 계속 기간을 부가하여, 수정된 "실행가능한 슬롯 종료 시간"을 계산한다. 이후, openSlotFeasibility 방법은 수정된 "실행가능한 슬롯 종료 시간"과 "이후 약속"의 시작 시간을 비교하여, 이 "이후 약속"이 오른쪽(또는 보다 늦은 시간)으로 시프트되어야 하는 지의 여부를 결정한다. 시프트되어야 하는 "이후 약속"이 있다면, openSlotFeasibility 방법은 "실행가능한 슬롯 종료 시간"과 "이후 약속"의 시작 시간 간의 차이로서 원하는 오른쪽 시프트 계속 기간을 계산한다. 방법은 이후 cascadeRightShiftFeasibility 방법을 호출하여, "이후 약속"이 원하는 오른쪽 시프트 계속 기간으로 오른쪽으로 시프트될 수 있는 지의 여부를 결정한다. "이후 약속"이 원하는 오른쪽 시프트 계속 기간으로 오른쪽으로 시프트될 수 있다면, 방법은 셋업 시간의 순수 변경을 포함하는 실행가능한 결과를 돌려준다. 그렇지 않고, "이후 약속"이 원하는 오른쪽 시프트 계속 기간으로 시프트될 수 없다면, 이 openSlotFeasibility 방법은 끝나고, 실행불가능한 결과를 되돌려준다.

슬롯을 오픈시키는 것이 실행가능하고 이후 그렇게 하는 것이 바람직하다면, 슬롯은 오픈된다. 스케줄링 에이젼트는 2개의 방법들중 하나를 호출한다. 이러한 방법들중 첫 번째 방법은 openSlot 방법이다. 이 openSlot 방법은 지정된 시작 시간에서 시작하는 카렌다 상의 지정된 계속 기간을 갖는 슬롯을 오픈시킨다. 프리 셋업 또는 포스트 셋업 약속들이 요구되는 경우, 이 방법은 요구되는 계속 기간 외에 셋업 약속들을 수용할 수 있을 정도로 충분히 큰 슬롯을 오픈시킨다. 이러한 방법들중 두 번째 방법은 openSlotAndBookAppointment 방법이다. 이 openSlotAndBookAppointment 방법은 카렌다 상의 지정된 계속 기간을 갖는 지정된 시작 시간에서 시작하는 슬롯을 오픈시킨 다음, 약속을 예약한다. 프리 셋업 또는 포스트 셋업 약속들이 요구되는 경우, 이 방법은 셋업 약속들을 수용할 수 있을 정도로 충분히 큰 슬롯을 오픈시킨 다음, 요구되는 셋업 약속들을 예약한다. openSlot 방법 및 openSlotAndBookAppointment 방법은 모두 하기 설명되는 cascadeLeftShift 방법 및 cascadeRightShift 방법을 이용하여, 원하는 시작 시간 및 계속 기간을 갖는 카렌다 상의 슬롯을 오픈시킨다.

이제, openSlot 방법에 관련하여, 이는 입력들로서:

ㆍ 셋업을 제외한, 슬롯에 대한 요구되는 시작 시간;

ㆍ 슬롯에 대해 요구되는 셋업을 수신하고,

그리고, 슬롯이 성공적으로 오픈되었는 지의 여부를 나타내는 불 논리 표시자를 출력한다. openSlot 방법은, cascadeLeftShiftFeasibility 방법 대신 cascadeLeftShift 방법을 호출하고 cascadeRightShiftFeasibility 방법 대신 cascadeRightShift 방법을 호출하는 것을 제외하고는, openSlotFeasibility 방법과 동일한 논리를 이용한다. cascadeLeftShift 및 cascadeRightShift가 모두 성공적으로 수행된다면, openSlot 방법은 슬롯이 카렌다 상에 성공적으로 오픈되었음을 나타내는 불 논리 참을 되돌려준다. 그렇지 않고, cascadeLeftShift 또는 cascadeRightShift가 성공적으로 수행될 수 없다면, openSlot 방법은 슬롯이 오픈될 수 없음을 나타내는 불 논리 거짓을 되돌려준다.

이제, openSlotAndBookAppointment 방법과 관련하여, 이는 예약될 약속을 입력으로서 수신하여, 어떠한 출력도 되돌려주지 않는다. 이 openSlotAndBookAppointment 방법은 먼저 카렌다 상의 마지막 약속을 찾는다. 마지막 약속이 있고, 이 마지막 약속이 로트 공정 약속이고, 그리고 예약될 약속이 남아있는 이송 시간이 제로인 로트 공정 약속이라면, 이 openSlotAndBookAppointment 방법은 마지막 약속의 최초의 종료 시간을 저장한 다음, 이 마지막 약속이 취소될 수 있음을 나타내는 플래그를 설정한다. 이후, 이 openSlotAndBookAppointment 방법은 openSlot 방법을 호출하여, 만일 있는 경우, 약속의 계속 기간의 계속 기간 및 약속의 셋업 요건과 일치하는 셋업을 갖는, 약속 시작 시간에서 시작하는 카렌다 상의 슬롯을 오픈시킨다.

openSlot 방법이 수행된 후, openSlotAndBookAppointment 방법은 카렌다 상에 새로운 약속 및 요구되는 어떠한 프리 셋업 또는 포스트 셋업 약속들을 예약한다. 이 openSlotAndBookAppointment 방법은 이후 마지막 약속의 최초 종료 시간에 대해, 만일 있는 경우, 이 마지막 약속의 새로운 종료 시간을 체크한다. 마지막 약속이 보다 늦은 시간으로 시프트된다면, 이는 약속 계속 기간에 대한 시프트 계속 기간의 비율을 계산한 다음, 이 비율과 구성가능한 특성값을 비교한다. 계산된 비율이 특성값 보다 크다면, 마지막 약속은 취소되어야 하며, 이에 따라 openSlotAndBookAppointment 방법은 이 마지막 약속이 페널티 리펀드(penalty refund)를 얻어야 하는 지의 여부를 결정한다. 마지막 약속이 범핑 요금(이는 보통 리펀드가 불가능하다)을 지불했다면, openSlotAndBookAppointment 방법은 마지막 약속의 페널티 리펀드를 자신이 지불한 범핑 요금으로 설정하며, 그렇지 않다면 마지막 약속에 대한 페널티 리펀드는 제로로 설정된다.

마지막 약속이 취소되어야 한다면, openSlotAndBookAppointment 방법은 이 마지막 약속을 취소한다. 마지막 약속을 취소한 후, 필요하다면, openSlotAndBookAppointment 방법은 끝난다. 마지막 약속을 취소하는 이유는, 이것이 임계값을 넘어 시프트될 때, 이는 다른 머신 상의 보다 나은 약속을 찾을 수 있기 때문이다. 주목할 사항으로서, openSlotAndBookAppointment 방법이 실행되는 동안, 다른 어떠한 방법도 카렌다를 갱신할 수 없다.

openSlot 방법 및 openSlotAndBookAppointment 방법이 모두 카렌다 상의 슬롯을 오픈시키기는 하지만, 이들은 서로 다르게 이용된다. 비드를 확인할 때, MSA는 "비드 확인기"로서 알려진 헬퍼 클래스 객체를 호출한다. 이 비드 확인기는, openSlotFeasibility를 호출하여 실행가능한 것으로 이전에 알았던 빈 슬롯에 약속을 예약할 준비가 되면, openSlot 방법을 호출한다. 한편, MSA는 openSlotAndBookAppointment 방법을 직접 호출하여, 슬롯을 오픈한 다음 하나의 카렌다 동작으로 약속을 예약한다. 또한 주목할 사항으로서, openSlotAndBookAppointment 방법은 openSlot 방법을 호출하여 슬롯을 실제로 오픈시킨다.

카렌다 상의 슬롯들을 클리어하는 데에는 어떠한 논리를 이용하는바, 이는 카렌다 상의 슬롯들을 오픈시키는 것과 일부 사항들에서 유사하다. 슬롯을 클리어하기 위해, clearSlotFeasibility라 불리는 방법을 호출한다. 이 clearSlotFeasibility 방법은, 약속의 시간 간격과 겹치는 모든 약속들을 찾은 다음, 상기 겹치는 약속들을 요구되는 시간 간격 이전, 주위, 또는 이후로 순환적으 로 시프트시킴으로써 요구되는 슬롯이 클리어될 수 있는 지의 여부를 체크하여, 소정의 약속에 대한 슬롯을 클리어하는 실행 가능성을 결정한다. 프리 셋업 또는 포스트 셋업 약속들이 요구되는 경우, 방법은 요구되는 계속 기간 외에 셋업 약속 약속들을 수용할 수 있을 정도로 충분히 큰 슬롯을 클리어할 실행 가능성을 결정한다. 이는 클리어 슬롯 실행가능성이 결정된 가능한 약속을 입력으로서 수신한 다음:

ㆍ 슬롯을 클리어하는 것이 실행가능한 지의 여부를 나타내는 불 논리 표시자;

ㆍ 셋업 타입의 순수 변경;

ㆍ 슬롯을 클리어하기 위해 취소되어야 하는 겹치는 약속들의 리스트; 및

ㆍ 슬롯을 클리어하기 위해 요구되는 약속 행동들의 리스트를 출력한다.

보다 특정하게, clearSlotFeasibility 방법은 먼저 슬롯 시작 시간을 "가능한 약속" 시작 시간으로 설정하고, 슬롯 종료 시간을 "가능한 약속" 종료 시간으로 설정한다. 이후, clearSlotFeasibility 방법은 "가능한 약속"을 예약하기 위해 프리 셋업 그리고/또는 포스트 셋업 약속이 부가되어야 하는 지의 여부를 결정한다. "가능한 약속"이 셋업을 요구하면, 이는 약속 시작 시간 이전에 끝난 마지막 약속("프리 약속")을 결정한 다음, 이 "프리 약속" 셋업이 "가능한 약속"의 셋업 요건과 일치하는 지의 여부를 결정한다. 프리 셋업이 "가능한 약속"의 요구되는 셋업과 일치하지 않으면, 이는 "가능한 약속"의 시작 시간에서 요구되는 셋업 계속 기간을 뺌으로써 슬롯 시작 시간을 다시 계산한다.

이후, clearSlotFeasibility 방법은 "가능한 약속"의 종료 시간 이후에 시작하는 첫 번째 약속("포스트 약속")을 찾는다. 이 "포스트 약속"이 셋업 약속이 아니고, "가능한 약속" 셋업과 다른 포스트 셋업을 요구한다면, clearSlotFeasibility 방법은 "가능한 약속"의 종료 시간에 포스트 셋업 계속 기간을 더함으로써 슬롯 종료 시간을 다시 계산한다. 다음으로, clearSlotFeasibility 방법은 슬롯 시작 시간 및 슬롯 종료 시간에 의해 정의되는 시간 간격과 겹치는 모든 약속들을 찾는다. 어떠한 약속도 겹치지 않는 다면, 방법은 끝나고, 실행가능함을 나타내는 결과를 되돌려주며, 어떠한 취소도 필요하지 않다. 그렇지 않으면, clearSlotFeasibility 방법은 "이전 약속"을 마지막 겹치는 약속, 즉 가장 늦은 시작 시간과 겹치는 약속으로 설정하고, "가능한 약속", 겹치는 약속 및 "이전 약속"의 수집(collection)을 패스시키는 (바로 아래에서 설명되는) recurseClearSlot라 불리는 방법을 호출한다.

이 recurseClearSlot 방법은 먼저, "이전 약속"이 왼쪽(보다 이른 시간)으로충분히 멀리 시프트됨으로써 "가능한 약속"이 그 뒤에 예약될 수 있는 지의 여부를 결정한다. "가능한 약속"이 셋업 요건을 갖는 다면, 이 recurseClearSlot 방법은 "이전 약속"의 셋업 요건과 "가능한 약속"의 셋업 요건을 비교한다. "이전 약속"이 셋업 약속이면, recurseClearSlot 방법은 "이전 약속" 이전의 약속("앞 약속(previous appointment)")을 찾은 다음, 이 셋업 요건과 "가능한 약속"의 셋업 요건을 비교한다. "가능한 약속"이 셋업 요건을 갖고 셋업이 일치하지 않으면, recurseClearSlot 방법은 "가능한 약속"의 시작 시간에서 셋업 계속 기간을 뺌으로 써 "이전 약속"의 요구되는 종료 시간을 계산한다. "이전 약속"의 요구되는 종료 시간이 자신의 실제 종료 시간 보다 적다면, recurseClearSlot 방법은 cascadeLeftShiftFeasibility 방법을 호출하여, "이전 약속"이 왼쪽으로 충분히 시프트됨으로써 "가능한 약속"이 이 뒤에 예약될 수 있는 지의 여부를 결정한다. recurseClearSlot 방법은 "이전 약속"과 요구되는 왼쪽 시프트 계속 기간(이는 "이전 약속"의 종료 시간과 요구되는 종료 시간 간의 차이이다)을 갖는 cascadeLeftShiftFeasibility 방법을 호출한다. "이전 약속"의 종료 시간이 자신의 요구되는 종료 시간 보다 적다면, 이 "이전 약속"을 왼쪽으로 시프트시킬 필요가 없으며, recurseClearSlot 방법은 "이전 약속" 이후의 어떤 약속들이 오른쪽으로 시프트되어야 하는 지의 여부를 확인한다. "이전 약속"이 셋업 약속이고 어떠한 "앞 약속"도 없다면, 셋업 약속은 제거될 수 있으며, recurseClearSlot 방법은 cascadeLeftShiftFeasibility 방법이 실행가능한 것 처럼 동일한 것을 계속한다.

cascadeLeftShiftFeasibility 방법이 왼쪽 시프트가 실행 가능함을 나타내면, recurseClearSlot 방법은 "이전 약속" 이후의 다음 약속("이후 약속")을 찾는다. "이후 약속"이 "가능한 약속"과 다른 셋업 요건(포스트 셋업)을 갖는 다면, recurseClearSlot 방법은 "가능한 약속"의 종료 시간에 포스트 셋업 계속 기간을 더함으로써 "이후 약속"의 요구되는 시작 시간을 계산한다. "이후 약속"의 요구되는 시작 시간이 "이후 약속"의 시작 시간 보다 늦다면, recurseClearSlot 방법은 cascadeRightShiftFeasibility 방법을 호출하여, "이후 약속"이 오른쪽으로 시프트됨으로써 "가능한 약속"이 그 이전에 예약될 수 있는 지의 여부를 결정한다. recurseClearSlot 방법은 "이후 약속" 및 요구되는 오른쪽 시프트 계속 기간(이는 "이후 약속"의 요구되는 시작 시간과 이 "이후 약속"의 실제 시작 시간의 차이이다)을 이용하여 cascadeRightShiftFeasibility 방법을 호출한다. 이 cascadeRightShiftFeasibility 방법이 오른쪽 시프트가 실행가능함을 나타내면, recurseClearSlot 방법은 끝나고, 실행가능한 결과 및 부가되는 순수 셋업을 되돌려준다.

그렇지 않고, cascadeLeftShiftFeasibility 방법이 "이전 약속"이 요구되는 양 만큼 왼쪽으로 시프트될 수 없음을 나타내면, recurseClearSlot 방법은 "이전 약속"과 겹치는 약속이 있는 지의 여부를 확인하기 위한 체크를 한다. "이전 약속"과 겹치치는 어떤 약속도 없다면, recurseClearSlot 방법은 "가능한 약속"이 "이전 약속" 앞에 예약되기 위해서는 이 "이전 약속"이 오른쪽으로 얼마나 많이 시프트되어야 하는 지를 결정한다. "이전 약속"이 "가능한 약속"의 셋업과 다른 셋업을 요구하지 않는한, "이전 약속"의 요구되는 시작 시간은 "가능한 약속"의 종료 시간이며, 따라서 "이전 약속"의 요구되는 시작 시간은 "가능한 약속"의 종료 시간과 "이전 약속"의 셋업 계속 기간의 합이다. 이후, recurseClearSlot 방법은 "이전 약속" 및 요구되는 시프트 계속 기간(이는 "이전 약속"의 요구되는 시작 시간과 이 "이전 약속"의 실제 시작 시간 간의 차이이다)을 이용하여 cascadeRightShiftFeasibility 방법을 호출한다. 이 cascadeRightShiftFeasibility 방법이 오른쪽 시프트가 실행가능함을 나타내면, recurseClearSlot 방법은 끝나며, 실행가능한 결과 및 부가된 순수 셋업을 되돌려준다.

cascadeRightShiftFeasibility 방법이 호출되는 상기 2개의 경우들중 어느 하나에 있어서, 이 cascadeRightShiftFeasibility 방법이 오른쪽 시프트가 실행불가능함을 나타내면, "가능한 약속" 이전의 이러한 "이전 약속"을 이용하여 슬롯을 클리어하는 것은 실행이 불가능하며, 이에 따라 recurseClearSlot 방법은 "이전 약속"과 겹치는 약속이 있는 지의 여부를 결정한다. "이전 약속" 이전의 겹치는 약속("앞 약속")이 있으면, recurseClearSlot 방법은 자신을 호출하여 "앞 약속"을 새로운 "이전 약속"으로서 반복적으로 패스시키며, 다른 입력들(겹치는 약속의 수집 및 "가능한 약속")은 변경되지 않는다. "이전 약속" 이전에 어떠한 겹치는 약속도 없다면, recurseClearSlot 방법은 "이전 약속"의 요구되는 시작 시간을 계산하며, 이에 따라 "가능한 약속"이 그 앞에 예약될 수 있게 된다. 이 경우, "이전 약속"이 "가능한 약속"의 셋업과 다른 셋업을 요구하지 않는 한, "이전 약속"의 요구되는 시작 시간은 "가능한 약속"의 종료 시간이다. 따라서, "이전 약속"의 요구되는 시작 시간은 "가능한 약속"의 종료 시간과 "이전 약속"에 대한 셋업 계속 기간의 합이다.

이후, recurseClearSlot 방법은 요구되는 시프트 계속 기간(이는 "이전 약속"의 요구되는 시작 시간과 "이전 약속"의 실제 시작 시간의 차이이다)을 이용하여 "이전 약속"에 대해 cascadeRightShiftFeasibility 방법을 시도한다. 이 cascadeRightShiftFeasibility 방법이 오른쪽 시프트가 실행가능함을 나타내면, recurseClearSlot 방법은 끝나며, 실행가능한 결과 및 부가되는 순수 셋업을 되돌려준다. cascadeRightShiftFeasibility 방법이 오른쪽 시프트가 실행불가능함을 나 타내면, recurseClearSlot 방법은 끝나며, 실행불가능한 결과를 되돌려준다.

이러한 반복은, 실행가능한 결과가 발견되거나 또는 "이전 약속" 앞에 겹치는 어떠한 이전 약속도 없고, 이 "이전 약속"이 "가능한 약속"과 이 "가능한 약속" 직후에 요구되는 어떠한 포스트 셋업을 더한 것 이후에 시작하도록 시프트될 수 없을 때 까지 계속된다. recurseClearSlot 방법이 슬롯을 클리어하는 것이 실행가능함을 나타내면, clearSlotFeasibility 방법은 순수 셋업 변경 및 슬롯을 클리어하는 데에 요구되는 약속 행동들의 리스트를 돌려주며, 슬롯을 클리어하는 것이 실행가능함을 나타낸다. recurseClearSlot 방법이 슬롯을 클리어하는 것이 실행불가능함을 나타내면, clearSlotFeasibility 방법은 취소되어야 하는 겹치는 약속들의 리스트를 돌려주고, 슬롯을 클리어하는 것이 실행불가능함을 나타낸다.

clearSlotFeasibility 방법은 중요한 유틸리티를 가지고 있다. 상기 설명한 비드 확인기, 및 비드 발생기로서 알려진 MSA의 헬퍼 클래스의 다른 객체들이 이 방법을 이용한다. 비드 발생기는 이 방법을 이용하여, 잠재적인 비드를 위해 슬롯이 클리어될 수 있는 지의 여부를 결정한다. 비드 확인기는 이 방법을 이용하여, 새로운 약속을 예약하기 위해 슬롯이 클리어될 수 있는 지의 여부를 결정한다.

슬롯을 클리어하는 것이 실행가능하고 이렇게 하는 것이 바람직하다면, 슬롯은 클리어된다. 본 발명은 환경에 따라 3개의 방법들중 하나를 이용한다. 이러한 3개의 방법들은 clearSlot, clearSlotAndBookAppointment 및 forcedClearSlotAndBookAppointment이라 불린다. 이러한 각 방법들은, 지정된 약속과 겹치는 모든 가능한 약속들을 찾은 다음, 어떠한 약속들도 취소하지 않으면서 이러한 약속들을 지정된 약속 이전, 주위 또는 이후로 시프트시키고자 반복적으로 시도하는 클리어링 절차를 실행함으로써, 상기 지정된 약속에 대한 슬롯을 클리어한다. 슬롯이 시프팅에 의해 클리어될 수 없다면, 겹치는 약속들은 한번에 하나씩 취소되고, 반복적인 클리어링 절차가 각 취소 이후에 다시 한번 호출된다. 프리 셋업 또는 포스트 셋업 약속들이 요구된다면, 방법은 상기 지정된 약속의 계속 기간 외에 이러한 셋업 약속들을 충분히 수용할 수 있는 큰 슬롯을 클리어한다. 슬롯이 클리어될 수 있다면, clearSlotAndBookAppointment 방법이 시작되어 약속을 예약한다. forcedClearSlotAndBookAppointment 방법은 슬롯이 클리어되지 않을 것임을 고려하지 않는다. 본 특정 실시예에서, 이 방법은 항상 슬롯을 클리어하고 약속을 예약할 것이다.

이제, clearSlot 방법에 관련하여, 이 방법은 먼저 clearSlotFeasibility 방법에 대해 설명한 것과 같은 논리를 수행하여, 요구되는 슬롯이 겹치는 영역으로부터 약속들을 시프트 또는 블럭킹(blocking)함으로써 클리어될 수 있는 지의 여부를 결정한다. 약속들을 취소하지 않으면서 슬롯을 클리어할 수 있다면, recurseClearSlot 방법은 또한 슬롯을 클리어하기 위해 필요한 약속 행동들의 리스트를 돌려준다. 이러한 약속 행동들의 리스트는 영향을 받는 각 약속을 얼마나 많이 시프트해야 하는지 그리고 제거될 수 있는 셋업 약속들을 삭제해야하는 지의 여부에 대한 지시들을 포함한다. 이러한 약속 행동들은 또한 정렬됨으로써, 이 행동들은 각 행동이 순차적으로 수행될 때 어떠한 약속들이 카렌다 상에서 겹치지 않도록 하면서 수행될 수 있다. 주목할 사항으로서, clearSlot 방법을 호출하는 클라이 언트가 약속들 및 어떠한 프리 셋업 또는 포스트 셋업 약속들에 대한 예약을 담당하며, 따라서 이들의 약속 행동들은 리스트에 포함되지 않는다.

recurseClearSlot 방법이 슬롯을 클리어하는 것이 실행불가능함을 나타내면, clearSlot 방법은 약속 행동 수집의 행동들을 수행하고, 필요한 약속들을 실제적으로 시프트시키며, 불필요한 셋업 약속들을 제거한 다음, 슬롯의 클리어가 성공적으로 수행되었음을 나타내는 불 논리 참을 되돌려준다. recurseClearSlot 방법이 약속들을 취소하지 않으면서 슬롯을 클리어하는 것이 실행불가능함을 나타내면, 이 recurseClearSlot 방법은 겹치는 약속들의 리스트를 되돌려준다. 이후, clearSlot 방법은 먼저 셋업 약속이 아닌 겹치는 약속("겹치는 약속")을 얻은 다음, 이 "겹치는 약속", "가능한 약속" 및 겹치는 약속들의 수집을 패스시키는 cancelOverlappingAppointments라 불리는 방법을 호출한다.

이 cancelOverlappingAppointments 방법은 "겹치는 약속"을 취소한 다음, clearSlotFeasibility 방법에 대해 설명한 것과 동일한 논리를 다시 한번 수행하여, 요구되는 슬롯이, 만일 있는 경우, 새로운 블록킹 약속들을 겹치는 영역으로부터 시프트시킴으로써 클리어될 수 있는 지의 여부를 결정한다. 약속들을 취소하지 않으면서 슬롯을 클리어할 수 있다면, recurseClearSlot 방법은 또한 슬롯을 클리어하는 데에 요구되는 약속 행동들의 리스트를 돌려준다. 이러한 약속 행동들의 리스트는 영향을 받는 각 약속을 얼마나 많이 시프트해야하고 제거될 수 있는 셋업 약속을 삭제할 것인 지의 여부에 대한 지시들을 포함한다. 이러한 약속 행동들은 또한 정렬됨으로써, 이 행동들은 각 행동이 순차적으로 수행될 때 카렌다 상에서 어떠한 약속들도 겹치지 않게 하면서 수행될 수 있다.

recurseClearSlot 방법이 슬롯의 클리어가 실행가능함을 나타내거나, 더 이상의 겹치는 약속들이 없다면, cancelOverlappingAppointments 방법은 끝나며, clearSlot 방법에 대한 약속 행동들의 리스트를 돌려준다. recurseClearSlot 방법이 약속들을 취소하지 않으면서 슬롯의 클리어가 실행불가능함을 나타내면, 이 recurseClearSlot 방법은 cancelOverlappingAppointments 방법에 대한 겹치는 약속들의 새로운 리스트를 되돌려주며, 이 cancelOverlappingAppointments 방법은 먼저 겹치는 약속들의 새로운 리스트로부터 제 1의 겹치는 약속("겹치는 약속")을 얻은 다음, 자신을 다시 한번 반복적으로 호출한다. 이러한 반복은, recurseClearSlot 방법이 슬롯의 클리어가 실행가능함을 나타낼 때 까지, 또는 더 이상의 겹치는 약속들이 없을 때 까지 반복된다. cancelOverlappingAppointments 방법이 clearSlot 방법으로 되돌아가면, clearSlot 방법은, 만일 있는 경우, 약속 행동 수집의 행동들을 수행하고, 필요한 약속들을 실제적으로 시프트시키며, 불필요한 셋업 약속들을 제거한 다음, 슬롯의 클리어가 성공적으로 수행되었음을 나타내는 불 논리 참을 되돌려준다. 주목할 사항으로서, clearSlot 방법이 실행되는 동안, 다른 어떠한 방법들도 카렌다를 갱신하도록 허용되지 않는다.

clearSlotAndBookAppointment 방법은 1개의 부가적인 입력, 즉 취소될 것으로 기대되는 약속들의 수집을 갖는다. 이 clearSlotAndBookAppointment 방법은, 약속 취소를 처리하는 방법을 제외하고, clearSlot 방법과 동일한 모든 논리를 수행한다. 클라이언트가 입력 약속 수집의 각 약속들에 대한 페널티 리펀드의 설정을 담당한다. 어떠한 약속들을 취소하기 전에, 방법은 겹치는 약속들의 입력 리스트에 대해 겹치는 약속들의 실제 리스트를 체크한다. 실제 겹치는 약속 수집이 입력 약속 수집에 포함되지 않았던 어떠한 약속을 포함한다면, clearSlotAndBookAppointment 방법은 겹치는 약속들의 입력 리스트의 각 약속에 대해 페널티 리펀드를 제로로 리셋한 다음, 거짓을 돌려주면서 끝난다. clearSlotAndBookAppointment 방법이 성공적으로 슬롯을 클리어한다면, 이는 카렌다 상에 가능한 약속 및 어떠한 프리 셋업 또는 포스트 셋업 약속들을 예약하고, 취소되지 않았던 겹치는 약속들의 입력 리스트의 각 약속에 대한 페널티 리펀드를 제로로 리셋한다.

forcedClearSlotAndBookAppointment 방법은, 취소된 약속들에 대한 처리 및 카렌다 상의 마지막 약속과 관련된 일부 부가적인 논리를 제외하고, clearSlotAndBookAppointment 방법과 동일한 모든 논리를 수행한다. forcedClearSlotAndBookAppointment 방법은 슬롯을 클리어하는 데에 필요한 어떠한 약속들을, 비록 이들이 입력 약속 수집에 포함되지 않는 다고 할지라도, 취소한다. 클라이언트는 입력 약속 수집의 각 약속들에 대한 페널티 리펀드의 설정을 담당한다. 이 방법이 입력 약속 수집에 포함되지 않은 약속을 취소한다면, 이는 페널티 리펀드 계산기를 호출하여 페널티 리펀드를 계산한 다음, 이를 취소하기 이전의 약속에 리펀드를 설정한다. 이 방법이 입력 약속 수집에 포함되었던 약속을 취소하지 않는 다면, 이는 그 약속의 페널티 리펀드를 제로로 리셋시킨다.

forcedClearSlotAndBookAppointment 방법과 clearSlotAndBookAppointment 방 법 간의 다른 차이는, forcedClearSlotAndBookAppointment 방법이 openSlotAndBookAppointment 방법과 동일한 방식으로 카렌다 상의 마지막 약속을 처리한다는 것이다. 마지막 약속이 있고, 이 마지막 약속이 로트 공정 약속이며, 그리고 예약될 약속이 남아있는 이송 시간이 제로인 로트 공정 약속이라면, forcedClearSlotAndBookAppointment 방법은 이 마지막 약속의 최초의 종료 시간을 저장하고, 이 마지막 약속이 취소될 수 있음을 나타내는 플래그를 설정한다. 슬롯이 클리어되고, 새로운 약속 및 어떠한 프리 셋업 또는 포스트 셋업 약속들이 예약된 후, forcedClearSlotAndBookAppointment 방법은 마지막 약속의 최초의 종료 시간에 대해, 만일 있는 경우, 이 마지막 약속의 새로운 종료 시간을 체크한다.

마지막 약속이 보다 늦은 시간으로 시프트되었다면, 이는 약속 계속 기간에 대한 시프트 계속 기간의 비율을 계산한 다음, 이 비율을 구성가능한 특성값과 비교한다. 계산된 비율이 특성값 보다 크다면, 마지막 약속은 취소되어야 하며, 이에 따라 forcedClearSlotAndBookAppointment 방법은 이 마지막 약속이 페널티 리펀드를 얻어야하는 지의 여부를 결정한다. 마지막 약속이 범핑 요금(이는 보통 리펀드가 불가능하다)을 지불했다면, forcedClearSlotAndBookAppointment 방법은 마지막 약속의 페널티 리펀드를 자신이 지불한 범핑 요금과 같게 설정하며, 그렇지 않으면 마지막 약속에 대한 페널티 리펀드는 제로로 설정된다. 마지막 약속이 취소되어야 한다면, forcedClearSlotAndBookAppointment 방법은 이 마지막 약속을 취소한다. 이와같이 마지막 약속을 취소하는 이유는, 이것이 임계치를 넘어 시프트될 때, 다른 머신 상의 보다 나은 약속을 찾을 수 있기 때문이다.

상기 설명한 바와 같이, 에이젼트는 환경에 따라 clearSlot, clearSlotAndBookAppointment 또는 forcedClearSlotAndBookAppointment 방법을 이용한다. MSA는 clearSlot 방법을 직접 호출하여, 새로운 약속을 예약하기 위해 슬롯을 클리어한다. 하지만, MSA의 헬퍼 클래스 비드 확인기는 clearSlotAndBookAppointment 방법을 이용하여, 슬롯을 클리어하고 하나의 카렌다 동작으로 새로운 약속을 예약한다. 이 clearSlotAndBookAppointment 방법은 전형적으로, 카렌다 상에 이미 예약되어 있는 약속들을 범핑, 즉 취소할 것을 기대할 때에 이용된다. MSA의 헬퍼 클래스 비드 확인기는 forcedClearSlotAndBookAppointment 방법을 이용하여, 슬롯을 클리어하고 "오버라이드(override)" 비드 확인을 위해 하나의 카렌다 동작으로 약속을 예약한다. 이러한 상황에서, 약속이 예약되는데, 이는 대응하는 액티비티(포트에 캐리어 도달, PM 시작, Qual 시작, 머신 다운타임 시작 등)가 이미 시작되었음을 나타내는 이벤트가 검출되기 때문이다.

카렌다 상의 슬롯들을 오픈 및 클리어하기 위해 상기 설명한 방법들은 약속들을 실제로 이동 또는 시프트시키는 다른 방법들을 호출하는바, 이는 본원의 설명으로부터 명백하다. 이러한 방법들중 일부는 "당기기(pull)" 약속들이고, 일부는 "직렬 시프트"이며, 하나는 "점프 오버"이다. 이러한 기술들중 일부는 약속들을 왼쪽(즉, 보다 이른 시간) 및 오른쪽(즉, 보다 늦은 시간) 모두로 시프트시키는 데에 적용되며, 나머지 것들은 단지 한 방향으로만 동작한다. 일부는 반복적이고, 나머지 것들은 반복적이 아니다. 이제, 이러한 기술들중 일부에 대해 설명한다.

먼저, 카렌다 상에 예약된 다수의 약속들이 직렬 방식으로 동시에 시프트되는 "직렬 시프트"로서 알려진 강력한 기술을 고려하자. 따라서, 요구되는 경우, 그리고 가능한 경우, 제 1 약속은 카렌다 상에서 왼쪽 또는 오른쪽(보다 이른 시간 또는 보다 늦은 시간)으로 시프트된다. 이후, 시프트량을 증가시키기 위해 제 1 약속에 의한 시프트를 이용하여, 제 2 약속이 시프트된다. 이러한 제 2 약속이 제 1 약속 이전에 있느냐 아니면 이후에 있느냐는, 시프트가 왼쪽으로 되느냐 아니면 오른쪽으로 되느냐에 달려있다. 일련의 연속적인(하지만, 반드시 연속적일 필요는 없다) 약속들이 이러한 방식으로 연속적으로 시프트 또는 "직렬화"되어, 카렌다 상에 공간을 클리어한다.

이를 테면, 도시된 실시예에서 왼쪽으로 직렬 시프트시키기 위해, 카렌다에 대한 스케줄링 에이젼트는 먼저 지정된 약속에서 시작하여 지정된 시프트 시간량 만큼 약속들을 직렬 방식으로 왼쪽(또는 보다 이른 시간)으로 시프트시킬 수 있는 실행 가능성을 결정한다. 로크된 약속들은 시프트될 수 없는 것으로 고려된다. 이때에는 어떤 약속도 시프트되지 않는다. 이러한 시프트가 실행가능하다고 결정되면, 직렬 왼쪽 시프트 실행 가능성이 수행되는 환경에 따라, 약속들은 지정된 약속에서 시작하여 지정된 시간량 만큼 직렬 방식으로 왼쪽(또는 보다 이른 시간)으로 시프트될 수 있다.

보다 특정하게, 스케줄링 에이젼트는 직렬의 일부로서 시프트하기를 원하는카렌다 상의 제 1 약속 및 이 제 1 약속을 시프트하기를 원하는 시간량을 선택한다. 보다 기술적으로, 도시된 실시예에서, 스케줄링 에이젼트는 cascadeLeftShiftFeasibility라 불리는 방법을 호출한다. 이 방법은 상기 설명한 openSlotFeasibility 방법에 의해 호출되어, 다른 약속을 수용할 수 있을 정도로 충분히 큰 카렌다 상의 슬롯을 오픈시키기 위해 왼쪽으로 직렬 시프트를 실행할 수 있는 지를 결정한다. 이 cascadeLeftShiftFeasibility 방법의 입력은 시프트될 제 1 약속 및 시프트 계속 기간이다. 이 cascadeLeftShiftFeasibility 방법은, 시프트가 실행가능한지의 여부를 나타내는 불 논리; 약속의 시프트가 실제로 가능한 계속 기간; 시프트에 의해 요구되는 셋업 시간의 순수 변경; 제 1 블럭킹 약속(즉, 시프트될 수 없는 약속); 및 직렬 왼쪽 시프트를 수행하기 위해 필요한 약속 행동들의 리스트를 포함하는 응답을 공식화한다.

이러한 응답을 전개(develop)하기 위해, cascadeLeftShiftFeasibility 방법은 최초의 요구되는 시프트 계속 기간과 같은 요구되는 시프트 계속 기간을 갖는 제 1 약속에 대해 recurseLeftShift라 불리는 방법을 호출한다. 이 recurseLeftShift 방법은 이후 제 1 약속에 대해 canShiftLeft 방법을 호출하여, 이 약속이 자신의 다이내믹한 가장 이른 시작 시간("EST") 제약을 고려한 요구되는 양 만큼 왼쪽(또는 보다 이른 시간)으로 시프트될 수 있는 지의 여부를 결정한다. 제 1 약속이 요구되는 완전한 양 만큼 시프트될 수 없다면, 이는 "블럭킹" 약속으로서 지정되고, 이의 실제 왼쪽 시프트 계속 기간이 주목된다.

이후, recurseLeftShift 방법은 카렌다 상의 이전 약속을 찾은 다음, 이전 약속의 끝과 제 1 약속의 시작 간의 (아이들 또는 빈) 시간 갭의 양을 결정한다. 이 recurseLeftShift 방법은 이러한 이전 약속이 시프트될 수 있는 실제 계속 기간 으로부터 갭의 양을 뺀 다음, 만일 있는 경우, 제 1 약속이 자신의 실제 왼쪽 시프트 시간을 달성하기 위해 이전 약속이 시프트되어야 하는 수정된 양을 계산한다. 동일한 셋업을 이용하는 2개의 약속들 간에 연속적으로 끼워 넣어지기 때문에 제거될 수 있는 셋업 약속에 직면하는 경우에는, 셋업 계속 기간을 갭의 양으로 처리하여, 이전 약속이 시프트되어야 하는 수정된 양을 계산할 때 상기 셋업 계속 기간을 뺀다.

어떠한 이전 약속도 없거나, 이전 약속이 완료 상태이거나, 이 약속의 실제 시프트량이 제로이거나, 또는 요구되는 시프트량이 달성된다면, 이 recurseLeftShift 방법은 끝나고, 가능한 실제 왼쪽 시프트 계속 기간을 되돌려준다. 그렇지 않으면, 이 recurseLeftShift 방법은 자신을 반복적으로 호출하는바, 이때에는 이전 약속 및 이 이전 약속에 대해 계산했던 수정된 왼쪽 시프트 계속 기간을 이용한다. recurseLeftShift 방법이 돌아오면, 이는 실제 가능한 시프트량이 요구되는 시프트 계속 기간과 같을 경우에만 시프트가 실행가능함을 나타낸다

직렬 왼쪽 시프트가 가능하고 여전히 바람직하다면, cascadeLeftShift라 불리는 방법이 호출된다. 이 방법은, 자신의 카렌다 상에서 약속을 왼쪽으로 시프트시키는 MSA에 반응할 때 LSA들 및 PMSA들에 의해 호출된다. 이 cascadeLeftShift 방법은 왼쪽으로 시프트되어야하는 제 1 약속 및 요구되는 시프트 계속 기간을 입력들로서 수신한 다음, 직렬 왼쪽 시프트가 성공적으로 수행되었는 지의 여부를 나타내는 불 논리 표시자를 출력한다.

보다 특정하게, 이 cascadeLeftShift 방법은 cascadeLeftShiftFeasibility 방법에 의해 이전에 호출된 recurseLeftShift 방법을 호출한다. 이 recurseLeftShift 방법은 cascadeLeftShiftFeasibility 방법에 의해 호출될 때 상기에서 설명한 바와 같이 직렬 왼쪽 시프트를 정확하게 실행할 수 있는 가능성을 체크한다. 이 recurseLeftShift 방법은 또한 직렬 왼쪽 시프트를 수행하는 데에 요구되는 약속 행동들의 리스트를 돌려준다. 이러한 약속 행동들의 리스트는 영향을 받는 각 약속을 얼마나 많이 시프트시켜야하는지, 그리고 제거될 수 있는 셋업 약속을 삭제할 지의 여부에 대한 지시들을 포함한다. 이러한 약속 행동들은 또한 영향을 받는 가장 이른 약속에서 시작하여 정렬되며, 이에 따라 행동들은 각 행동이 순차적으로 수행될 때 카렌다 상에 어떠한 약속들도 겹치지 않게 하면서 수행될 수 있다. recurseLeftShift 방법이 직렬 왼쪽 시프트가 실행가능함을 나타내는 경우, cascadeLeftShift 방법은 약속 행동 수집의 행동들을 수행하고, 필요한 약속들을 실제로 시프트시키며, 불필요한 셋업 약속들을 제거한 다음, 시프트가 성공적으로 이루어졌는 지의 여부를 나타내는 불 논리 참을 돌려준다. recurseLeftShift 방법이 직렬 왼쪽 시프트가 실행이 불가능하다고 나타내면, 이 방법은 시프트가 수행될 수 없음을 나타내는 불 논리 거짓을 돌려준다.

직렬 시프트는 오른쪽에 대해서도 이루어질 수 있다. cascadeRightShiftFeasibility이라 불리는 방법이 openSlotFeasibility 방법에 의해 호출되어, 다른 약속을 충분히 수용할 수 있을 정도로 큰 카렌다 상의 슬롯을 오픈시키기 위해 직렬 오른쪽 시프트를 실행할 가능성을 결정한다. 이 cascadeRightShiftFeasibility 방법은 또한 MSA의 헬퍼 클래스 객체에 의해 호출되 어, 머신 카렌다가 자신의 약속을 보다 늦은 시간으로 시프트시키고자 하는 로트의 요구를 수용할 수 있는 지의 여부를 결정한다. 이 cascadeRightShiftFeasibility 방법은 지정된 약속에서 시작하여 지정된 시프트 시간량 만큼 약속들을 직렬 방식으로 오른쪽(또는 보다 늦은 시간)으로 시프트시킬 수 있는 실행 가능성을 결정한다. 로크된 약속은 시프트가 불가능한 것으로 여겨진다. 이 cascadeRightShiftFeasibility 방법은 입력으로서, 오른쪽으로 시프트되어야 하는 제 1 약속, 요구되는 시프트 계속 기간, 및 제 1 약속을 앞서는 약속의 셋업을 수신한다. 이는 시프트가 실행 가능한지의 여부를 나타내는 불 논리 표시자, 약속이 실제로 시프될 수 있는 시간 계속 기간, 셋업 시간의 순수 변경, 제 1 블럭킹 약속, 및 직렬 오른쪽 시프트를 수행하기 위해 요구되는 약속 행동들의 리스트로 구성되는 시프트 실행가능성 응답을 출력한다.

보다 구체적으로, cascadeRightShiftFeasibility 방법은 최초의 요구되는 시프트 계속 기간과 같은 요구되는 시프트 계속 기간을 갖는 제 1 약속에 대해 recurseRightShift라 불리는 방법을 호출한다. 이 recurseRightShift 방법은 약속에 대해 canShiftRight라 불리는 방법을 호출하여, 이 약속이 자신의 가장 늦은 배달 시간("LDT") 제약을 고려하여 요구되는 양 만큼 오른쪽(보다 늦은 시간)으로 시프트될 수 있는 지의 여부를 결정한다. 약속이 요구되는 완전한 양 만큼 시프트되지 못한다면, 이는 블럭킹 약속으로서 지정되고, 이의 실제 오른쪽 시프트 계속 기간이 주목된다. 이후, recurseRightShift 방법은 카렌다 상의 다음 약속을 찾은 다음, 이 약속의 끝과 다음 약속의 시작 간의 갭 시간의 양을 결정한다. 이후, 이 약 속이 시프트될 수 있는 실제 계속 기간으로부터 갭 양을 빼고, 만일 있는 경우, 이 약속이 자신의 실제 오른쪽 시프트 시간을 달성할 수 있도록 다음 약속이 시프트되어야 하는 수정된 양을 계산한다.

recurseRightShift 방법이 동일한 셋업을 이용하는 2개의 약속들 간에 연속적으로 끼워 넣어지기 때문에 제거될 수 있는 셋업 약속에 직면하는 경우에는, 셋업 계속 기간을 갭의 양으로 처리하고, 다음 약속이 시프트되어야 하는 수정된 양을 계산할 때 상기 셋업 계속 기간을 뺀다. 어떠한 다음 약속도 없거나, 이 약속의 실제 시프트량이 제로이거나, 또는 요구되는 시프트량이 달성된다면, 이 방법은 끝나고, 가능한 실제 오른쪽 시프트 계속 기간을 되돌려준다. 그렇지 않으면, 이 recurseRightShift 방법은 자신을 반복적으로 호출하는바, 이때에는 다음 약속 및 이 다음 약속에 대해 계산했던 수정된 오른쪽 시프트 계속 기간을 이용한다. 이 recurseRightShift 방법이 돌아오면, 이는 실제 가능한 시프트량이 요구되는 시프트 계속 기간과 같을 경우에만 시프트가 실행가능함을 나타낸다.

직렬 오른쪽 시프트가 실행가능하고 여전히 바람직하다면, 환경에 따라, 직렬 오른쪽 시프트를 수행하기 위한 3개의 방법들중 하나가 호출된다. cascadeRightShift라 불리는 방법은 지정된 약속에서 시작하여 지정된 시간 량 만큼 약속을 오른쪽(보다 늦은 시간)으로 직렬 방식으로 시프트시킨다. 로크된 약속은 이러한 cascadeRightShift 방법에 의해 시프트될 수 있는 것으로서 고려되지 않는다. cascadeLockedRightShift라 불리는 방법은 지정된 약속에서 시작하여 지정된 시간 량 만큼 약속들을 오른쪽(보다 늦은 시간)으로 직렬 방식으로 시프트시킨다. 로크된 약속은 이 방법의 LDT의 제약들 내에서 시프트가능한 것으로 고려된다. cascadeForcedRightShift라 불리는 방법은 지정된 약속에서 시작하여 지정된 시간 량 만큼 약속들을 오른쪽(보다 늦은 시간)으로 직렬 방식으로 시프트시킨다. 이 방법은 약속들이 로크되었을 지라도, 이들을 시프트시킨다. 약속의 LDT가 요구되는 계속 기간 만큼 이 약속이 오른쪽으로 시프트되는 것을 막는 다면, 이 방법은 요구되는 시프트를 달성하는 데에 필요한 시간 량 만큼 LDT를 증가시킨 다음, 약속을 시프트시킨다.

cascadeRightShift 방법은 입력으로서, 오른쪽으로 시프트되어야 하는 제 1 약속, 요구되는 시프트 계속 기간, 및 제 1 약속에 앞서는 약속의 셋업을 수신한다. 이 cascadeRightShift 방법은 시프트가 성공적으로 수행되었는 지의 여부를 나타내는 불 논리 표시자를 출력한다. 이 cascadeRightShift 방법은 recureRightShift 방법을 호출하고, cascadeRightShiftFeasibility 방법에 대해 상기 설명한 바와 같이 직렬 오른쪽 시프트를 정확하게 실행할 수 있는 가능성을 체크한다. recureRightShift 방법은 또한 직렬 오른쪽 시프트를 수행하는 데에 요구되는 약속 행동들의 리스트를 돌려준다. 이러한 약속 행동들의 리스트는 영향을 받는 각 약속을 얼마나 많이 시프트시켜야하는지, 그리고 제거될 수 있는 셋업 약속을 삭제할 것인 지의 여부에 대한 지시를 포함한다. 이러한 약속 행동들은 또한 영향을 받는 가장 마지막 약속에서 시작하여 정렬되며, 이에 따라 행동들은 각 행동이 순차적으로 수행될 때 카렌다 상에 어떠한 약속들도 겹치게 하지 않으면서 수행될 수 있다.

recurseRightShift 방법이 직렬 오른쪽 시프트가 실행가능함을 나타내면, cascadeRightShift 방법은 약속 행동 수집의 행동들을 수행하고, 필요한 약속들을 실제로 시프트시키며, 불필요한 셋업 약속들을 제거한 다음, 시프트가 성공적으로 이루어졌음을 나타내는 불 논리 참을 돌려준다. recurseRightShift 방법이 직렬 오른쪽 시프트가 실행불가능함을 나타내면, cascadeRightShift 방법은 시프트가 수행될 수 없음을 나타내는 불 논리 거짓을 돌려준다.

cascadeLockedRightShift 방법은 입력들로서, 시프트되어야 하는 제 1 약속, 요구되는 시프트 계속 기간 및 제 1 약속 이전의 약속의 셋업을 수신하고, 시프트가 성공적으로 수행되었는 지의 여부를 나타내는 불 논리 표시자를 출력한다. cascadeLockedRightShift 방법은, 이 cascadeLockedRightShift 방법이 약속이 로크되었는 지의 여부를 무시하고 그 LDT의 제약들 내에서 약속이 시프트가능한 것으로 고려하는 것을 제외하고는, cascadeRightShift 방법과 동일하다.

cascadeForcedRightShift 방법은 입력들로서, 오른쪽으로 시프트되어야 하는 제 1 약속 및 요구되는 시프트 계속 기간을 수신하고, 시프트가 성공적으로 수행되었는 지의 여부를 나타내는 불 논리를 출력한다. 이 cascadeForcedRightShift 방법은, 약속의 LDT가 요구되는 계속 기간 만큼 약속을 오른쪽으로 시프트시키는 것을 막는 경우, 요구되는 시프트를 달성하는 데에 필요한 시간 양 만큼 LDT를 증가시킨 다음 약속을 시프트시킨다는 것을 제외하고는, cascadeLockedRightShift 방법과 동일하다.

상기 설명한 바와 같이, cascadeRightShift 방법, cascadeLockedRightShift 방법 및 cascadeForcedRightShift 방법중 하나가 환경에 따라 호출된다. cascadeRightShift 방법 및 cascadeLockedRightShift 방법은, MSA가 자신의 카렌다 상에 로크되지 않은 약속 및 로크된 약속을 각각 시프트시키는 것에 응답할 때 로트 및 PMSA들에 의해 호출된다. MSA는 또한 자신의 헬퍼 클래스 객체들중 하나에서 이러한 방법들을 호출하여, 블럭킹 약속이 로크되지 않을 때와 그리고 로크될 때에 각각 약속을 오른쪽으로 시프트시키고자 하는 소비자의 요구를 수용할 수 있는 지의 여부를 결정한다. cascadeForcedRightShift 방법은 LSA에 의해 이용되는바, 그의 카렌다 상의 어떤 약속이 스케줄링된 종료 시간까지 완료되지 않았음에도 불구하고, 이후의 약속들을 취소하기에는 어떠한 시점(point)도 없기 때문에, 이 약속이 확장될 수 있도록 상기 이후의 약속들을 강제적으로 오른쪽으로 직렬 시프트시켜야 하는 상황에서 이용된다.

도시된 실시예는 또한 recurseCascadeRightShift라 불리는 방법을 포함한다. 로딩 RSA 및 MSA는 일련의 약속들을 오른쪽으로 시프트시킬 것을 요구하는 이벤트에 응답할 때에 이 방법을 호출한다. 이 recurseCascadeRightShift 방법은, 지정된 약속에서 시작하여 지정된 시간량 만큼 약속들을 직렬 방식으로 오른쪽(보다 늦은 시간)으로 어떻게 시프트시킬 것인 지를 결정할 때 까지 반복적으로 동작한다. 시프트가 실행이 불가능한 경우, 블럭킹 약속 또는 배치 약속의 블럭킹 참가자들은, 약속이 로크되지 않은 경우에는 취소되거나, 또는 약속이 로크된 경우에는 그의 커미트먼트 윈도우 종료 시간(LDT)이 증가된다. 이후, recurseCascadeRightShift 방법은, 요구되는 시프트 계속 기간을 달성할 때 까지 자신을 반복적으로 호출한다.

상기 recurseCascadeRightShift 방법은 입력으로서, 오른쪽으로 시프트되어야 하는 제 1 약속; 요구되는 시프트 계속 기간; 및 직렬 오른쪽 시프트를 달성하기 위해 수행되어야 하는, 약속 취소를 제외한, 약속 행동들의 리스트를 수신하며, 어떠한 출력도 돌려주지 않는다. 하지만, 이러한 약속 행동들의 입력 리스트는 처음에는 비지만, 약속들의 취소 또는 약속의 LDT의 증가 이외의 어떠한 행동들이 요구되는 경우 이후의 반복적인 호출들에 대해 갱신될 수 있다. 따라서, 약속 행동들의 리스트는 입력 및 출력 모두이다.

recurseCascadeRightShift 방법은 cascadeRightShiftFeasibility를 수행하여, 직렬 오른쪽 시프트가 실행가능한 지의 여부를 결정한다. 시프트가 실행가능하다면, recurseCascadeRightShift 방법은 끝나고, cascadeRightShiftFeasibility에 의해 제공되는 약속 행동들의 리스트를 되돌려준다. 시프트가 실행가능하지 않다면, recurseCascadeRightShift 방법은 cascadeRightShiftFeasibility에 의해 제공되는 블럭킹 약속을 얻은 다음, 이것이 배치 약속인지의 여부를 결정한다. 이 블럭킹 약속이 배치 약속이라면, 방법은 어떤 배치 참가자(들)이 배치 약속이 요구되는 양 만큼 시프트되지 못하게 막고 있는 지를 결정한다. 블럭킹 배치 참가자가 로크되지 않았다면, 이 블럭킹 배치 참가자는 취소된다. 블럭킹 배치 참가자가 로크되었다면, 방법은 블럭킹 참가자의 LDT를 증가시킴으로써, 배치 약속이 요구되는 양 만큼 시프트될 수 있게 된다. 유사하게, 블럭킹 약속이 배치 약속이 아니라면, 방법은 이 블럭킹 약속이 로크되지 않은 경우에는 이를 취소하거나, 또는 이 블럭킹 약속이 로크된 경우에는 이의 LDT를 요구되는 양 만큼 증가시킨다.

블럭킹 약속이 배치 약속인지의 여부에 상관없이, recurseCascadeRightShift 방법이 이 블럭킹 약속을 제거한 후, 이는 자신이 최초에 호출되었던 동일한 파라미터들을 이용하여 자기 자신을 다시 한번 반복적으로 호출한다. 따라서, 1개 이상의 블럭킹 약속이 있다면, 다음 블럭킹 약속을 찾은 다음, 이후의 반복적인 호출에 대해 제거(취소, 또는 요구되는 시프트를 가능하게 하도록 LDT를 증가)한다. 이러한 반복은, 모든 블럭킹 약속들이 제거된 다음, cascadeRightShiftFeasibility에게 마지막 호출에 의해 제공된 약속 행동들의 리스트를 되돌려줌으로써 방법이 끝날 때 까지 계속된다. 비록 이 방법이 약속을 취소함으로써 또는 그 LDT를 증가시킴으로써 모든 블럭킹 약속들을 제거하기는 하지만, 클라이언트는 직렬 오른쪽 시프트를 달성하기 위해, 자신에게 되돌려지는, 다른 모든 약속 행동들의 수행을 책임진다.

직렬 시프트에 대한 대안적인 다른 관리 기술은 약속, 또는 약속들의 체인을 소정의 양 만큼 왼쪽 또는 오른쪽으로 당기는 것이다. 약속들의 "체인"은 일련의 약속들로서, 이들 각각은 동일한 셋업을 갖는다. 이러한 약속들의 체인을 당길 때, 체인의 모든 약속들은 동일한 소정의 양 만큼 동일한 방향으로 당겨진다. 이러한 환경에서, 이러한 "당기기"는 1개 이상의 예약된 약속들을 단일의 소정 시간량 만큼 시프트시키거나, 또는 단일 약속의 경우에는 소정의 시간으로 시프트시키는 것을 의미한다.

단일 약속을 원하는 시작 시간으로 왼쪽으로 당기기 위해, 먼저 이러한 당기기가 실행가능한 지의 여부를 결정한다. 원하는 시작 시간 이후의 시작 시간을 갖 는 첫 번째 약속("제 1 약속")이 식별된다. 셋업 약속들은 배제되며, 이에 따라 원하는 시작 시간 이후의 가장 이른 시간의 약속이 셋업 약속이라면, 이는 스킵(skip)된다. 이렇게 되면, 이 셋업 약속 이후의 다음 약속이 "제 1 약속"이 된다. 이 방법이 "제 1 약속"을 찾지 못하면, 서치는 끝나며, 결과는 "널"이다. "제 1 약속"이 비호환성 셋업을 요구한다면, 원하는 시작 시간은 최초의 원하는 시간 시간에 셋업 계속 기간을 더함으로써 재계산된다. "제 1 약속"의 다이내믹한 가장 이른 시작 시간("EST")이 셋업 시간을 배제한 채 계산된 다음, 원하는 시작 시간과 비교된다. 더 늦은 원하는 시작 시간 및 다이내믹한 EST가 선택된다. 선택된 시간 및 원하는 시작 시간으로부터, 제시되는 당기기가 실행가능한 지의 여부를 결정한다. 약속이 로크되어 있는 지의 여부는 이러한 결정에 중요하지 않다. 즉, 당기기가 실행가능한 지의 여부를 결정하는 데에 있어서, 그 약속이 로크되어 있는 지의 여부는 무시한다.

보다 기술적으로, pullLeftFeasibility를 호출하여 이러한 결정을 수행한다. 이 pullLeftFeasibility는 입력으로서, 제 1 약속에 대한 원하는 시작 시간 및 이 원하는 시작 시간 앞의 셋업을 수신한다. 원하는 시작 시간과 다이내믹한 EST 간에 상기 설명한 바와 같은 결정이 이루어진다. 가장 늦은 원하는 시작 시간 및 다이내믹한 EST가 "제 1 약속"이 시작할 수 있는 가장 이른 시간으로서 되돌려진다. MSA는 자신의 헬퍼 클래스 객체들중 하나에서 pullLeftFeasibility 방법을 호출하여, 현재 액티브한 약속 바로 다음에 오는 아이들 시간을 제거 또는 감소시킬 수 있는 지의 여부를 결정한다.

약속을 왼쪽으로 당기는 것이 실행가능하고 또한 이렇게 하는 것이 바람직하다면, 방법은 pullLeft라 불리는 방법을 호출한다. MSA는 자신의 헬더 클래스 객체들중 하나로부터 pullLeft 방법을 호출하여, 약속들의 체인을 완료된 약속의 종료 시간 또는 거의 완료된 약속의 기대되는 종료 시간으로 왼쪽으로 당긴다. 이 pullLeft 방법은 입력으로서, 제 1 약속에 대한 원하는 시작 시간 및 이 원하는 시작 시간 앞의 셋업을 수신한다. 이 pullLeft 방법은 셋업 요건들을 고려하여, 약속들의 체인을 왼쪽(보다 이른 시간)으로 당긴다. 이는 1개 이상의 약속들을 왼쪽으로 시프트시키고 어떠한 불필요한 셋업 약속들을 제거함으로서 카렌다를 갱신한다. 체인의 모든 약속들은, 다음 약속이 왼쪽으로 보다 많이 시프트됨으로써 이것이 이전 약속 바로 다음에 시작하지 않는 한, 체인의 제 1 약속과 동일한 양 만큼 왼쪽으로 시프트된다. 이 약속은, 다이내믹한 EST의 제약들 내에서 로크된 약속들을 왼쪽으로 시프트시키는 것을 제외하고는, 하기 설명되는 pullLeftChain 방법과 유사하게 동작한다.

보다 특정하게, 이 pullLeft 방법은 pullLeftFeasibility 방법에 의해 되돌려지는 실제 시작 시간을 이용하여 호출된다. 이 pullLeft 방법은 이것이 약속들을 왼쪽으로 시프트시킬 때 약속이 로크되어 있는 지의 여부는 무시한다. 이 pullLeft 방법이 제 1 약속을 원하는 시작 시간으로 왼쪽으로 시프트시키고 어떠한 불필요한 셋업들을 제거한 후, 이는 부가적인 약속들을 제 1 약속 뒤로 시프트시키고자 시도함으로써 계속된다. 이러한 과정은, 왼쪽으로 시프트된 제 1 약속과 적어도 동일한 양 만큼 왼쪽으로 시프트될 수 없는 다른 셋업 또는 약속을 만날 때 까지 계속된 다.

이 pullLeft 방법은 원하는 시작 시간 이후에 시작하는 제 1 약속("다음 약속")을 찾음으로써 시작된다. 어떠한 "다음 약속"도 없으면, pullLeft 방법은 끝난다. "다음 약속"이 호환성 셋업을 갖는 셋업 약속이라면, 이 셋업 약속을 제거한 다음, "다음 약속"을 셋업 약속 이후의 다음 약속으로 리셋시킨다. pullLeft 방법은 "다음 약속"이 왼쪽으로 시프트되어야 하는 계속 기간("기초 계속 기간(base duration)")(이는 "다음 약속"의 시작 시간과 원하는 시작 시간 간의 차이이다)을 계산한 다음, 이 "기초 계속 기간"의 양 만큼 약속을 왼쪽으로 시프트시킨다.

이후, pullLeft 방법은 반복 루프를 시작하는바, 이는 상기 "다음 약속" 이후의 다음 약속을 얻은 다음, 이것이 왼쪽으로 충분히 시프트됨으로써 왼쪽으로 시프트되었던 마지막 약속("마지막 약속") 직후에 시작할 수 있는 지의 여부를 결정한다. 어떠한 "다음 약속"도 없거나, "다음 약속"이 셋업 약속이라면, 방법은 끝난다. 그렇지 않으면, 이 pullLeft 방법은 "마지막 약속" 바로 다음에 시작하기 위해 "다음 약속"이 왼쪽으로 시프트되어야 하는 시간량("인접 계속 기간")을 계산한 다음, 이 "다음 약속"이 "다음 약속"의 시작 시간과 "마지막 약속"의 새로운 종료 시간 간의 차이인 "인접 계속 기간" 만큼 왼쪽으로 시프트될 수 있는 지의 여부를 결정한다. "다음 약속"이 "인접 계속 기간" 만큼 시프트될 수 없다면, 이 방법은 "다음 약속"이 "기초 계속 기간" 만큼 왼쪽으로 시프트될 수 있는 지의 여부를 결정한다. "다음 약속"이 "인접 계속 기간" 또는 "기초 계속 기간"중 어느 하나 만큼 왼쪽으로 시프트될 수 있다면, 실제로 다음 약속은 실행가능한 계속 기간들중 보다 큰 것 만큼 왼쪽으로 시프트되고, "다음 약속"은 왼쪽으로 시프트된 마지막 약속 이후의 다음 약속으로 리셋되고, 이렇게 되면 이것이 새로운 "마지막 약속"이 되며, 과정을 다시 반복한다.

어떠한 "다음 약속"도 없거나, 또는 "다음 약속"이 셋업 약속이거나, 또는 "다음 약속"이 "인접 계속 기간" 또는 "기초 계속 기간" 만큼 왼쪽으로 시프트될 수 없다면, pullLeft 방법은 끝낼 준비를 한다. 마지막 단계는, "마지막 약속"이 실제로 왼쪽으로 시프트된 후에 셋업이 삽입되어야 하는지의 여부를 체크하는 것이다. (실제로 시프트된 "마지막 약속" 이후의) "다음 약속"이 셋업을 요구하고 이 셋업이 "마지막 약속"의 셋업과 호환가능하지 않거나, "마지막 약속"의 끝과 "다음 약속" 간의 시간량이 "다음 약속"에 대한 셋업 계속 기간 보다 크다면, 카렌다 상에 "다음 약속"의 바로 앞에 셋업 약속을 예약한다. 요구되는 어떠한 셋업을 예약한 후, pullLeft 방법은 끝난다.

약속들은 또한 체인들로 "당겨"질 수 있다. 이를 테면, 셋업들이 일반적으로 행해지고 시간 소모적인 머신 카렌다들에 대한 스케줄을 최적화하기 위해 pullLeftChain 방법을 이용한다. 이러한 타입의 카렌다의 갭을 채울 때, MSA는 약속들의 체인을 깨뜨리지 않고자 노력한다. 하지만, MSA는 먼저 pullLeftChainFeasibility 방법을 호출하여, 셋업들이 일반적으로 행해지고 시간 소모적인 머신 카렌다들 대한 스케줄이 최적화될 수 있는 지의 여부를 결정한다.

이 pullLeftChainFeasibility 방법은 체인을 깨뜨리지 않으면서 동일한 셋업을 공유하는 약속들의 체인이 왼쪽(보다 이른 시간)으로 당겨질 수 있는 시간량을 계산한다. 이 pullLeftChainFeasibility 방법은 로크된 약속은 시프트될 수 없다고 여긴다. 이는 입력으로서 체인의 제 1 약속을 수신한 다음, 체인을 깨뜨리지 않으면서 체인을 왼쪽으로 당길 수 있는 시간 계속 기간을 출력한다. 이 pullLeftChainFeasibility 방법은, 제 1 약속으로 시작하여, 이 제 1 약속 이후의 모든 약속들을 포함하는 약속들의 체인에 대해, 특정한 셋업 요건에 의존하는 더 이상의 약속들이 없을 때 까지 동작한다. 이는 체인의 모든 약속들의 왼쪽으로 시프트될 수 있는 최대 시간량을 돌려준다.

이 pullLeftChainFeasibility 방법은 먼저 "제 1 약속"이 셋업 약속인지의 여부를 결정하고, 셋업 약속이라면, 그 이후의 다음 약속을 얻는데, 이 약속이 "제 1 약속"이 된다. 어떠한 "제 1 약속"도 없다면, pullLeftChainFeasibility 방법은 끝나고 제로의 계속 기간을 돌려준다. 그렇지 않고, "제 1 약속"이 있다면, pullLeftChainFeasibility 방법은 이 "제 1 약속"이 왼쪽으로 시프트될 수 있는 최대 시간량을 결정하는바, 이러한 계속 기간이 "최소" 시프트 계속 기간이 된다.

이후, pullLeftChainFeasibility 방법은 반복 루프를 시작하는바, 이는 상기 "제 1 약속" 이후의 다음 약속("다음 약속")을 얻은 다음, 이 "다음 약속"이 상기 "최소" 시프트 계속 기간 만큼 시프트될 수 있는 지의 여부를 결정한다. 이 pullLeftChainFeasibility 방법은 "다음 약속"이 왼쪽으로 시프트될 수 있는 최대 시간량("최대" 시프트 계속 기간)을 결정한 다음, 이 "최대" 시프트 계속 기간과 "최소" 시프트 계속 기간의 현재값을 비교한다. "최대" 시프트 계속 기간이 "최소" 시프트 계속 기간의 현재값 보다 작다면, "최소" 시프트 계속 기간은 "최대" 시프 트 계속 기간과 같게 설정되고, 상기 "다음 약속" 이후의 약속(이것이 "다음 약속"이 된다)을 찾음으로써 방법을 다시 반복한다. 반복 루프의 어느 시점에서 어떠한 "다음 약속"도 없거나, "다음 약속"이 셋업 약속이거나, 또는 "다음 약속"이 셋업 요건을 갖지 않는 다면, 이 pullLeftChainFeasibility 방법은 끝나며, "최소" 시프트 계속 기간의 현재값과 같은 계속 기간을 돌려준다.

왼쪽으로 체인을 당기는 것이 실행가능하고 또한 바람직하다면, pullLeftChain 방법이 호출된다. 이 pullLeftChain 방법은 입력들로서, 이 방법의 결과로서 약속들의 체인이 시작되어야 하는 시간 및 시작 시간 이전의 셋업을 수신한다. 이 pullLeftChain 방법은 어떠한 출력도 돌려주지 않는다. 이 pullLeftChain 방법은 셋업 요건들을 고려하여 약속들의 체인을 왼쪽(보다 이른 시간)으로 당긴다. 이는 1개 이상의 약속들을 왼쪽으로 시프트시키고 어떠한 불필요한 셋업 약속들을 제거함으로써 카렌다를 갱신한다. 체인의 모든 약속들은, 약속이 왼쪽으로 보다 많이 시프트됨으로써 이것이 이전 약속 바로 다음에 시작될 수 있지 않는 한, 체인의 제 1 약속과 동일한 양 만큼 왼쪽으로 시프트된다. 이 방법은, 로크된 약속은 시프트될 수 없음을 고려하는 것을 제외하고는, pullLeft 방법과 매우 유사하다. 약속들의 체인을 왼쪽으로 당기기 위해, pullLeftChainFeasibility 방법에 의해 되돌려진 실제 시작 시간을 이용하여 pullLeftChain 방법을 호출한다. 이 pullLeftChain 방법은, 로크된 약속들을 시프트시키지 않는 것을 제외하고는, pullLeft 방법과 동일하게 동작한다. 어떠한 약속이 로크된다면, 이 약속은 시프트될 수 없는 것으로 고려된다.

약속들의 체인들은 또한 오른쪽으로 당겨질 수 있다. pullRightChain라 불리는 방법을 이용하여, 상기 설명한 pullLeftChain 방법과 유사한 방식으로, 셋업들이 일반적으로 행해지고 시간 소모적인 머신 카렌다들에 대한 스케줄을 최적화한다. 여기에서 또한, 이러한 타입의 카렌다의 갭을 채울 때, MSA는 약속들의 체인을 깨뜨리지 않고자 노력한다. 하지만, pullRightChainFeasibility라 불리는 방법이 먼저 호출되어, 셋업들이 일반적으로 행해지고 시간 소모적인 머신 카렌다들에 대한 스케줄이 최적화될 수 있는 지의 여부를 결정한다.

보다 특정하게, pullRightChainFeasibility 방법은 오른쪽으로 당겨질 약속들의 체인에 대한 가장 오른쪽 약속을 입력으로서 수신한 다음, 체인을 깨뜨리지 않으면서 약속의 체인이 오른쪽으로 당겨질 수 있는 시간량을 출력한다. 이 pullRightChainFeasibility 방법은 또한 지정된 약속에서 시작하는 약속들의 체인들이 동일한 셋업을 이용하는 약속들의 체인을 깨뜨리지 않으면서 오른쪽으로 당겨질 수 있는 계속 기간(시간량)을 계산한다. 이 방법은, 로크된 약속은 시프트될 수 없는 것으로 고려한다.

이 pullRightChainFeasibility 방법은 먼저 특정한 약속이 오른쪽으로 시프트될 수 있는 시간량을 결정하는바, 이 계속 기간은 약속 체인이 왼쪽으로 당겨질 수 있는 시간량인 "최소 계속 기간"에 대한 최초값이 된다. 이는 또한, 만일 있는 경우, 특정한 약속에 대한 셋업 요건을 결정한다. 이후, 반복 루프에 들어가는바, 이는 이전 약속을 얻은 다음, 체인이 끝났는 지의 여부, 또는 "이전 약속"이 시프트될 수 있는 지의 여부를 결정한다. 어떠한 "이전 약속"도 없거나, "이전 약속"이 셋업을 요구하지 않거나, 또는 "이전 약속"의 셋업 요건이 입력 약속의 셋업과 호환가능하지 않거나, 또는 "이전 약속"이 셋업 약속이라면, 체인은 깨지고, "최소 계속 기간"을 되돌림으로써 방법은 끝난다. 그렇지 않으면, pullRightChainFeasibility 방법은 "이전 약속"이 오른쪽으로 시프트될 수 있는 시간량을 결정하고, 이 새로운 계속 기간과 "최소 계속 기간"을 비교한다. 새로운 계속 기간이 "최소 계속 기간" 보다 적다면, 이 "최소 계속 기간"의 값이 새로운 계속 기간으로 설정된다. 필요에 따라, "최소 계속 기간"을 조정한 후, 구 "이전 약속" 바로 앞의 약속인 새로운 "이전 약속"을 얻음으로써 반복 루프를 다시 시작한다.

실행가능하고 또한 바람직하다면, pullRightChain 방법을 호출하여 체인을 오른쪽으로 당긴다. 이 pullRightChain 방법은 입력들로서, 오른쪽으로 당겨질 약속들의 체인의 가장 오른쪽 약속 및 이 방법의 결과로서 약속들의 체인이 끝나야 하는 시간을 수신한다. 이 pullRightChain 방법은 어떤 출력도 돌려주지 않는다. 이 pullRightChain 방법은, 약속들을 실제로 오른쪽으로 시프트시킨다는 것을 제외하고는, pullRightChainFeasibility 방법과 매우 유사하다.

이 pullRightChain 방법은 pullRightChainFeasibility 방법에 의해 돌려지는 계속 기간 보다 작거나 또는 같은 계속 기간을 이용하여 호출된다. 이 pullRightChain 방법은 먼저 지정된 약속이 지정된 시간에서 오른쪽으로 끝까지 시프트될 수 있는 지의 여부를 체크하고, 약속은, 자신이 지원할 수 있는, 지정된 시간 보다 적거나 또는 같은 가장 큰 종료 시간("새로운 종료 시간")을 되돌린다. 이 후, pullRightChain 방법은 "새로운 종료 시간"에서 끝까지 시프트시킨다. 이는, 만일 있는 경우, 지정된 약속에 대한 셋업 요건을 결정하고, 또는 약속의 "새로운 시작 시간"을 결정한다.

이후, pullRightChain 방법은 반복 루프에 들어가는바, 이는 이전 약속을 얻은 다음, 체인이 종료되었는 지의 여부, 또는 "이전 약속"이 시프트될 수 있는 지의 여부를 결정한다. "이전 약속"이 있고, 이 "이전 약속"이 셋업을 요구하며, 그리고 이 "이전 약속"의 셋업 요건이 입력 약속의 셋업과 호환가능하다면, 방법은 "이전 약속"이 "새로운 시작 시간"에서 오른쪽으로 끝까지 시프트될 수 있는 지의 여부를 체크한다. "이전 약속"은, 자신이 지원할 수 있는, "새로운 시작 시간" 보다 작거나 또는 같은 가장 큰 종료 시간("새로운 종료 시간")을 되돌리며, 이후 방법은 "이전 약속"을 "새로운 종료 시간"에서 끝까지 시프트시킨다. "이전 약속"이 셋업 약속이라면, 방법은 끝나며, 그렇지 않으면, "새로운 시작 시간"을 "이전 약속"의 새로운 시작 시간으로 설정한 다음, 구 "이전 약속" 바로 앞의 약속인 새로운 "이전 약속"을 얻음으로써 반복 루프를 다시 시작한다.

반복 루프를 중지시킬 수 있는 다른 하나의 조건이 있다. 어떠한 "이전 약속"도 없거나, "이전 약속"이 셋업을 요구하지 않거나, "이전 약속"의 셋업 요건이 입력 약속의 셋업과 호환가능하지 않다면, 체인이 깨지고, 방법은 끝낼 준비를 한다. "이전 약속"이 입력 약속의 셋업과 호환가능한 셋업 약속이라면, 이 셋업 약속은 "새로운 시작 시간"에서 끝까지 시프트된다. 그렇지 않으면, pllRightChain 방법이 끝난다.

다른 관리 기술들-"점프 오버"-은 슬롯을 오픈시키고 클리어하는 것과 관계되지 않는다. 이러한 점프 오버 기술은 도 8B에 도시되어 있는바, 이에 대해서는 상기에서 설명하였다. 도시된 실시예에서, jumpoverFeasibility라 불리는 방법은 점프 오버가 실행가능한 지의 여부를 결정하기 위해 호출되고, jump over라 불리는 방법은 실제로 점프 오버를 수행하기 위해 호출된다. 이러한 점프 오버 기술은, 아이들 시간 바로 다음의 약속이 이 아이들 시간을 없앨 수 있을 정도로 충분히 왼쪽 또는 보다 이른 시간으로 시프트될 수 없을 때, 머신 카렌다 상의 이러한 아이들 시간을 채운다. 이러한 환경에서, 머신 스케줄링 에이젼트는 보다 이른 시간에서 시작할 수 있도록 이후의 약속을 중간 약속들을 넘어 점프시킴으로써 아이들 시간을 채우는 것을 고려한다. 이제, 이러한 각 방법들에 대해 보다 상세히 설명한다.

이 jumpoverFeasibility 방법은 컷오프 시간 및 현재 셋업을 이용하여, 가장 이른 시간 시간이 컷오프 시간 이전에 있는 카렌다 상의 모든 약속들을 찾는다. 이후, jumpoverFeasibility 방법은 가능한 "점핑" 약속(들)을 그(그들)의 최초 위치로부터 일시적으로 제거한 다음, 가능한 시작 시간(들)을 최대의 원하는 시작 시간 및 EST로서 계산한다. 이후, jumpoverFeasibility 방법은 가능한 시작 시간을 이용하여, 원하는 시간 시간 이후 시작하는 현재 카렌다 상의 제 1 약속의 새로운 시작 시간을 결정한다. 이러한 jumpoverFeasibility 방법은 가장 이른 시작 시간이 컷오프 시간 이전에 있는 각 약속들에 대한 점핑을 평가한다.

jumpoverFeasibility 방법은 cascadeRightShiftFeasibility 방법을 호출하여, 이러한 제 1 약속이 이러한 새로운 시작 시간으로 시프트될 수 있는 지의 여부 를 결정한다. 실행가능한 경우, jumpoverFeasibility 방법은 이러한 "점프 오버" 행동으로 인한 순수 셋업 변경을 계산하여, jumpoverFeasibilityResponse를 생성한 다음, 이 응답을 jumpoverFeasibilityResponseCollection에 부가한다. jumpoverFeasibilityResponse는 하나의 "점핑" 약속에 관한 정보의 수집이고, jumpoverFeasibilityResponseCollection은 다양한 "점핑" 약속들에 대한 jumpoverFeasibilityResponse들이다. 직렬 오른쪽 시프트가 실행가능하지 않다면, 가능한 "점핑" 약속은 "점핑" 약속에 대한 후보자로서 선택되지 않을 것이다. cascadeRightShiftFeasibility 방법 이후, jumpoverFeasibility 방법은 일시적으로 제거된 약속을 카렌다 상에 다시 복구시킨다.

실행가능하고 또한 바람직하다면, jumpover 방법을 호출하여 점프 오버 행동을 실제로 수행한다. 이 jumpover 방법은 입력으로서, 특히 프리 셋업이 요구되는 경우 "점핑" 약속의 프리 셋업 약속 또는 "점핑" 약속의 새로운 시작 시간인 시작 시간, 및 현재 셋업을 수신한다. 이 jumpover 방법은 시작 시간, 현재 셋업 및 점핑 약속의 셋업을 이용하여 "점핑" 약속의 실제 시작 시간을 찾고, 또한 카렌다로부터 "점핑" 약속을 일시적으로 제거한다.

이후, jumpover 방법은 cascadeRightShift 방법을 호출하여, "점핑" 약속 및 가능한 포스트 셋업 약속에 대한 슬롯을 클리어한다. 이 cascadeRightShift 호출이 성공적이면, 이는 jumpForward라 불리는 방법을 호출하는바, 이는 점핑 약속을 시뮬레이트된 왼쪽 시프트를 이용하여 새로운 시작 시간에서 카렌다 내에 다시 넣는다. 그렇지 않고, cascadeRightShift 호출이 성공적이지 않으면, jumpover 방법은 cascadeRightShift 호출로부터 발견(catch)되는 예외를 규정하고, 일시적으로 제거된 약속을 다시 카렌다 내에 넣는다. cascadeRightShift 호출이 어떠한 예외도 규정하지 않지만, 거짓 값을 되돌린다면, jumpover 방법은 또한 OverlappingException을 규정할 것이다. 가장 좋은 점프 오버 약속은 실행가능한 모든 점프 오버 약속들 중에서 총 아이들 시간이 가장 작은 것이어야 한다. 총 아이들 시간은 현재 시간과 제 1 약속("점핑 약속")의 시작 시간 간의 계속 기간과 순수 셋업 계속 기간의 합이다.

이러한 카렌다 관리 기술들중 일부는 공정 흐름의 머신들의 용량 또는 성능의 변경에 관련된다. 예를 들어, MSA는, 전형적으로 다운되었던 챔버를 이제 이용할 수 있게 됨에 따라 머신의 쓰루풋이 증가했음을 검출했을 때 increaseThroughput이라 불리는 방법을 호출한다. 이 increaseThroughput 방법은 머신의 쓰루풋 비율의 증가에 응답하여 카렌다 상의 시작되지 않은 모든 공정 약속들을 축소시킨다. 약속을 축소시킬 때 마다, 이 방법은 다음의 약속들을 왼쪽(보다 이른 시간)으로 당기고자 시도한 다음, 축소시킨 마지막 약속 이후에 추가적인 공정 약속들이 있는 경우 자신을 반복적으로 호출한다.

보다 특정하게, increaseThroughput 방법은 입력들로서, 머신의 스루풋이 증가할 때의 시작 시간, 및 예를 들어 그 시작 시간에서 이용할 수 있는 챔버들의 수를 수신하며, 어떠한 출력도 되돌리지 않는다. 이 increaseThroughput 방법은, 지정된 시간 이후에 시작되며 공정을 시작하지 않은 제 1 공정 약속을 얻는다. 어떠한 공정 약속도 없다면, increaseThroughput 방법은 끝난다. 그렇지 않으면, increaseThroughput 방법은 로트 웨이퍼 카운트 및 공정 동작을 찾고, 소정의 머신에 대한 공정 시간 및 이용가능한 챔버들의 수를 얻는다. 이 increaseThroughput 방법은 시작 시간에 공정 시간을 더하여 약속의 새로운 종료 시간을 계산한 다음, 새로운 종료 시간에서 끝으로 이 약속을 축소시킨다.

이후, increaseThroughput 방법은 자신이 축소시킨 약속 이후의 다음 약속("다음 약속")을 얻으며, 어떠한 "다음 약속"도 없으면 방법은 끝난다. "다음 약속"이 있으면, 이 방법은 이 "다음 약속"에 대해 pullLeftChainFeasibility 방법을 호출한다. 이 pullLeftChainFeasibility 방법은 "다음 약속"에 대한 실행가능한 시프트 계속 기간을 되돌리는바, 이후 increaseThroughput 방법이 이를 "다음 약속"의 시작 시간으로부터 뺌으로써, "다음 약속"에 대한 가장 이른 시작 시간을 계산한다. "다음 약속"의 가장 이른 시작 시간이 축소된 약속의 새로운 종료 시간 보다 이르다면, "다음 약속"의 원하는 시작 시간은 축소된 약속의 새로운 종료 시간으로 설정되고, 그렇지 않으면, 원하는 시작 시간은 "다음 약속"에 대해 계산되었던 가장 이른 시작 시간으로 설정된다. "다음 약속"의 원하는 시작 시간이 실제 시작 시간 보다 이르다면, increaseThroughput 방법은 축소되었던 약속의 셋업 및 원하는 시작 시간을 이용하여 pullLeftChain 방법을 호출하다. 이후, increaseThroughput 방법은 축소된 약속의 새로운 종료 시간 및 이용가능한 챔버들의 동일 수를 이용하여 자신을 반복적으로 호출한다. 카렌다 상에 더 이상의 공정 약속들이 없으면, increaseThroughput 방법은 끝난다.

상기의 설명으로부터 명백한 바와 같이, 본 발명의 카렌다링 기술은 예약된 약속들을 나타내는 저장하는 것 이상의 기여를 한다. 이 카렌다링 기술은 전체 스케줄링 과정을 통해, 비드 발생, 비드 확인, 비드 요구, 약속 실행 및 반응적 스케줄링을 포함하는 기능을 제공한다. 예를 들어, openSlotFeasibility, openSlot, openSlotAndBookAppointment, clearSlotFeasibility 및 forcedClearSlotAndBookAppointment 방법들은 비드 확인 동안 호출되고; openSlotFeasibility 및 clearSlotFeasibility 방법들은 비드 발생 동안 호출되며, cascadeRightShiftFeasibility, cascadeLockedRightShiftFeasibility, pullLeftFeasibility, pullLeftChainFeasibility, cascadeRightShift, cascadeLockedRightShift, pullLeft, pullLeftChain 및 pullRightChain 방법들은 이전에 예약된 약속들을 변경하기 위해 호출된다. cascadeLeftShift, cascadeLockedRightShift 및 recurseCascadeRightShift 방법들은 반응적 스케줄링에 이용된다.

주목할 사항으로서, 본원의 상세한 설명의 일부는 컴퓨팅 시스템 또는 컴퓨팅 디바이스의 메모리 내의 데이터 비트들에 대한 동작들의 기호적인 표현들을 포함하는 소프트웨어 구현 프로세스의 측면에서 제시되었다. 이러한 설명들 및 표현들은 당업자가 자신의 작업 내용을 다른 당업자에게 가장 효율적으로 전달하기 위해 이용된 수단이다. 프로세스 및 동작은 물리적인 양의 물리적인 조작을 필요로 한다. 보통, 반드시 그런 것은 아니지만, 이러한 물리적인 양들은 저장, 전달, 결합, 비교 및 그렇지 않으면 조정될 수 있는 전기, 자기 또는 광학 신호들의 형태를 갖는다. 주로 공통 이용을 위해, 이러한 신호들을 비트들, 값들, 요소들, 심볼들, 기호들, 용어들, 숫자들 등으로서 설명하는 것이 종종 편리하다는 것이 입증되었다.

하지만, 이들 및 유사한 용어들 모두는 적절한 물리량들과 관련되어 이러한 물리량들에 적용된 단지 편리한 라벨들일 뿐 이라는 것을 염두해야한다. 특별하게 지정하지 않는한, 그렇지 않으면 명백한 것으로서, 본 개시 전체를 통해, 이러한 설명들은 어떠한 전자 디바이스의 저장 장치 내의 물리(전기, 자기 또는 광학)량들로서 표현된 데이터를 처리하고, 저장 장치, 또는 전송 또는 디스플레이 디바이스들 내의 물리량들로서 유사하게 표현되는 다른 데이터로 변환하는 전자 디바이스의 실행 및 프로세스들을 설명한다. 이러한 설명을 나타내는 용어들의 예로는 "프로세싱", "컴퓨팅", "계산", "결정", "디스플레잉" 등이 있지만, 오직 이것들로만 한정되지는 않는다.

또한 주목할 사항으로서, 본 발명의 소프트웨어 구현 양상들은 전형적으로 어떠한 형태의 프로그램 저장 매체 상에 엔코드되거나, 어떠한 타입의 전송 매체에 대해 구현된다. 프로그램 저장 매체는 자기적(예를 들어, 플로피 디스크 또는 하드 디스크)이거나, 광학적(예를 들어, 컴팩 디스크 판독 전용 메모리 또는 "CD ROM")일 수 있고, 판독 전용 또는 랜덤 액세스가 될 수 있다. 유사하게, 전송 매체는 꼬임쌍 와이어, 동축 케이블, 광섬유 또는 당업계에 알려진 어떠한 다른 적절한 전송 매체가 될 수 있다. 본 발명은 어떠한 소정의 구현의 이러한 양상들에 의해 제한되지 않는다.

따라서, 본 발명은 다양한 양상들에서 하기와 같은 실시예들 및 구현들을 포 함하지만, 이에 한정되지 않는다:

ㆍ 자율적인 에이젼트들, 카렌다들 및 약속들로 이루어지는 카렌다링 시스템, 여기서 각 에이젼트는 적어도 1개의 스케줄링 및 공정에 관하여 복수의 제조 도메인 엔티티들 각각을 대리하며; 각 카렌다는 상기 각 도메인 엔티티에 대한 스케줄링시 상기 에이젼트들중 하나에 의해 유지되며; 그리고 각 약속은 복수의 약속 상태들중 하나로 존재하고, 상기 제조 도메인 엔티티에 대해 상기 각 카렌다 상에 상기 에이젼트들에 의해 상기 제조 도메인 엔티티들을 대신하여 스케줄링된다;

ㆍ 커미트먼트 윈도우 내에 떠있는 공정 윈도우를 포함하는 약속들을 갖는 카렌다들의 이용, 여기서 커미트먼트 윈도우는 가장 이른 시작 시간 및 가장 늦은 배달 시간에 의해 정의되고, 상기 공정 윈도우는 커미트먼트 윈도우 내의 시작 시간 및 종료 시간에 의해 정의된다;

ㆍ 커미트먼트 윈도우 내에 떠있는 공정 윈도우를 포함하는 약속들을 갖는 카렌다들의 이용, 여기서 공정 윈도우는 적어도 하나의 로트가 공정을 위해 소비되는 제 1 간격(즉, "소비 간격") 및 소비되는 로트가 공정 처리되는 제 2 간격(즉, "공정 간격")을 포함한다;

ㆍ 임시 약속들을 예약함으로써 이건, 아니면 예약된 약속을 변경함으로써 이건 간에, 하기와 같은 몇 개의 강력한 카렌다 조정 기술들중 어느 것을 이용하여, 공정 흐름의 카렌다 상의 약속들의 조정:

ㆍ 카렌다 상의 임시 약속에 대한 슬롯을 오픈시킬 수 있는 실행 가능성을 결정하고, 실행가능한 슬롯을 오픈시키고, 그리고 오픈된 슬롯의 카렌다 상에 임시 약속을 예약하고;

ㆍ 카렌다 상의 임시 약속에 대한 슬롯을 클리어할 수 있는 실행 가능성을 결정하고, 실행가능한 슬롯을 클리어하고, 클리어된 슬롯의 카렌다 상에 시험 약속을 예약하고;

ㆍ 예약된 약속을 보다 이르게 예약된 약속에 대한 종료 시간까지 왼쪽으로 당기고;

ㆍ 예약된 약속들의 체인을 보다 이르게 예약된 약속에 대한 종료 시간까지 왼쪽으로 당기고;

ㆍ 예약된 약속들의 체인을 오른쪽으로 당기고;

ㆍ 다수의 예약된 약속들을 직렬로 왼쪽으로 시프트시키고; 그리고

ㆍ 다수의 예약된 약속들을 직렬로 오른쪽으로 시프트시킨다;

ㆍ 공정 흐름의 동일한 액티비티에 대해 서로 다른 제조 도메인 엔티티들의 서로 다른 에이젼트들에 의해 유지되는 서로 다른 카렌다들 상의 대응하는 약속들을 동기화시키고; 그리고

ㆍ 이전에 예약된 약속들의 존재에 의해 새로운 약속의 예약을 명시적으로 제약하고, 이전에 예약된 약속들의 적어도 하나의 속성에 의해 새로운 약속의 예약을 암시적으로 제약한다.

본 발명의 다른 양상들, 실시예들 및 구현들이 본 개시의 이득을 얻는 당업자에게 명백해질 것이다.

이제, 본 발명의 상세한 설명을 마무리한다. 상기 개시된 특정한 실시예들은 단지 예시적인 것으로서, 본 발명은 본원의 개시의 이득을 갖는 당업자들에게 명백한 다르지만 등가의 방법들로 변형 및 실행될 수 있다. 주목할 사항으로서, 또 다른 실시예들에서는, 설명되지 않은 다른 변형들이 이용될 수 있다. 예를 들어, 머신이 판매할 아이들 시간을 가지고 있다면, 이는 광고를 원하거나, 개별적인 머신들에 이용시 충족해야 하는 목적으로서 판매 분담액이 할당될 수 있다. 또한, 하기의 청구항들에서 정의되는 것 외에는, 본원에 개시된 구성 또는 설계의 세부 사항들에 대한 어떠한 한정도 의도되지 않는다. 따라서, 상기 개시된 특정 실시예들은 변경 또는 수정될 수 있으며, 이러한 모든 변경들은 본 발명의 범위 및 정신 내에 있는 것으로 간주된다. 따라서, 본원이 보호를 받고자 하는 바는 하기의 청구항들에서 설명된다.

Claims

컴퓨터 시스템에 의해 실행되는 카렌다에 약속(appointment)을 예약(booking)하는 프로그램이 수록된 컴퓨터 판독가능 매체로서,

상기 카렌다는 이벤트가 발생하게될 적어도 하나의 약속을 포함하고,

상기 약속은 서비스를 제공하기로 확약(commit)된 기간인 커미트먼트 윈도우(commitment window)기간과 상기 커미트먼트 윈도우 기간의 범위내에서 전후로 이동하는 공정 윈도우(processing window) 기간(402)를 가지며,

상기 공정 윈도우 기간(402)은 적어도 하나의 로트(130)가 공정에 들어가기 위해 소비되는 제 1 기간(406)과 상기 소비된 로트(130)가 공정에 들어가 처리되는 제 2 기간(408)을 포함하는 것을 특징으로 하는 컴퓨터 판독가능매체.
제 1 항에 있어서,

적어도 2개의 약속들에 대한 상기 커미트먼트 윈도우 기간들은 중복되는 것을 특징으로 하는 컴퓨터 판독가능매체.
삭제
제 1 항에 있어서,

적어도 2개의 공정 윈도우들(402)은 연속적으로 설정되는 것을 특징으로 하는 컴퓨터 판독가능매체.
삭제
제 1 항에 있어서,

상기 카렌다는 머신 카렌다(370), PM카렌다(318), 로트 카렌다(385) 및 자원 카렌다(345)인 것을 특징으로 하는 컴퓨터 판독가능매체.
컴퓨터 시스템에 의해 실행되는, 소프트웨어 카렌다에 약속(appointment)을 예약하는 방법으로서,

상기 컴퓨터 시스템이,

동일 카렌다 상에 예약된 다른 약속이 존재하는 경우에, 이 약속을 명시적으로 제약하는(explicitly constraining) 단계와; 그리고

동일 카렌다상의 다른 어느 약속과도 관련되지 않는 제약을 나타내는 속성을 1개 이상 가지는 약속을 암묵적으로 제약하는(implicitly constraining) 단계를 실행하며,

상기 약속을 명시적으로 제약하는 단계에서는, 약속의 예약이 금지되거나, 혹은 동일 카렌다 상에서 다른 약속이 예약되어 있는 것에 의한 시작 시간을 앞당기거나 늦추는 것이 금지되며,

상기 약속을 암묵적으로 제약하는 단계에서는, 적어도 1개의 속성에 관하여 약속의 예약 혹은 시프트가 금지되거나 혹은 약속과 다른 약속과의 분리가 금지되는 것을 특징으로 하는 방법.
제 7 항에 있어서,

새로운 약속의 예약을 명시적으로 제약하는 단계에서는,

약속을 해당 약속보다 먼저 예약된 약속과 중복을 피하기 위해 해당 약속의 시작 시간을 동일 카렌다상에서 보다 빠른 시작 시간으로 시프트 하는 것을 명시적으로 제약하거나 혹은 상기 약속을 해당 약속보다 후에 예약된 약속과의 중복을 피하기위해 해당 약속을 동일 카렌다상에서 늦은 시작 시간으로 시프트하는 것을 명시적으로 제약하는 것을 특징으로 하는 방법.
삭제
제 7 항에 있어서,

상기 약속을 암묵적으로 제약하는 단계는,

하역 지연 또는 배출 계속 기간을 나타내는 적어도 1개의 속성에 의해 약속의 시프트 또는 상기 약속과 이전 약속 간의 분리를 암묵적으로 제약하는 단계를 포함하는 것을 특징으로 하는 방법.
컴퓨터 시스템에 의해 실행되는, 소프트웨어 카렌다에 약속(appointment)를 예약하는 방법으로서,

상기 컴퓨터 시스템이,

제 1 카렌다 상에 제 1 약속을 예약하는 단계와;

제 2 카렌다 상에 상기 제 1 약속에 대응하는, 제 2 약속을 예약하는 단계와; 그리고

공정 흐름에서의 이벤트들에 응답하여, 상기 제 1 약속과 상기 제 2 약속 중 어느 한편의 약속의 변경을 상기 제 1 약속과 상기 제 2 약속 중 다른 한편의 약속에 반영시키는 단계를 포함하는 것을 특징으로 하는 방법.
제 11 항에 있어서,

상기 제 1 카렌다는 머신 카렌다(370)이고, 상기 제 1 약속은 로트 공정 약속이며, 상기 제 2 카렌다는 로트 카렌다(385)이고, 상기 제 2 약속은 로트 약속이며;

상기 제 1 카렌다는 자원 카렌다(345)이고, 상기 제 1 약속은 적재 로트 약속이며, 상기 제 2 카렌다는 로트 카렌다(385)이고, 상기 제 2 약속은 적재 약속이며;

상기 제 1 카렌다는 자원 카렌다(345)이고, 상기 제 1 약속은 하역 로트 약속이며, 상기 제 2 카렌다는 로트 카렌다(385)이고, 상기 제 2 약속은 하역 약속이며;

상기 제 1 카렌다는 PM 카렌다(318)이고, 상기 제 1 약속은 PM 약속이며, 상기 제 2 카렌다는 머신 카렌다(370)이고, 상기 제 2 약속은 머신 PM 약속이며;

상기 제 1 카렌다는 PM 카렌다(318)이고, 상기 제 1 약속은 Qual 약속이며, 상기 제 2 카렌다는 머신 카렌다(370)이고, 상기 제 2 약속은 머신 Qual 약속이며;

상기 제 1 카렌다는 PM 카렌다(318)이고, 상기 제 1 약속은 PM 약속이며, 상기 제 2 카렌다는 자원 카렌다(345)이고, 상기 제 2 약속은 자원 PM 약속이며;

상기 제 1 카렌다는 PM 카렌다(318)이고, 상기 제 1 약속은 Qual 약속이며, 상기 제 2 카렌다는 자원 카렌다(345)이고, 상기 제 2 약속은 자원 Qual 약속이며;

상기 제 1 카렌다는 머신 카렌다(370)이고, 상기 제 1 약속은 스케줄링되지 않은 다운타임 약속이며, 상기 제 2 카렌다는 자원 카렌다(345)이고, 상기 제 2 약속은 자원 다운타임 약속이며;

상기 제 1 카렌다는 머신 카렌다(370)이고, 상기 제 1 약속은 머신 배치 약속이며, 상기 제 2 카렌다는 자원 카렌다(345)이고, 상기 제 2 약속은 자원 투입 배치 약속 또는 자원 배출 배치 약속이며; 또는

상기 제 1 카렌다는 머신 카렌다(370)이고, 상기 제 1 약속은 로트 공정 약속이며, 상기 제 2 카렌다는 자원 카렌다(345)이고, 상기 제 2 약속은 투입 로트 약속 또는 배출 로트 약속인 것을 특징으로 하는 방법.
제 11 항에 있어서,

상기 제 1 및 제 2 약속들에 대해 변경들을 반영시키는 단계는:

상기 제 1 약속에 대한 변경을 방송하는 단계와;

상기 방송을 청취하는 단계와; 그리고

방송된 변경 이벤트를 청취하면, 그에 대응하는 변경을 상기 제 2 약속에 대해 개시하는 단계를 포함하는 것을 특징으로 하는 방법.
제 11 항에 있어서,

상기 변경 이후에, 상기 변경을 기록(log)하거나, 상기 카렌다의 내용을 기록하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 11 항에 있어서,

상기 제 1 및 제 2 약속들과는 다른, 제 3의 약속을 갖는 제 3 카렌다를 예약하고,

공정 흐름내의 이벤트에 응답하여, 상기 제 1 및 제 2의 약속에 대한 변경을 상기 제 3 약속에 반영하는 것을 더 포함하는 것을 특징으로 하는 방법.
컴퓨터 시스템이 포함된 제조 공정 흐름에서 소프트웨어 카렌다에 예약된 약속(appointment)의 상태(status)를 제어하는 방법으로서,

상기 컴퓨터 시스템 내부로부터 상기 제조 공정 흐름의 상태에서 발생하는 변경 이벤트를 방송(broadcast)하는 단계와;

상기 컴퓨터 시스템 내에서 상기 방송을 청취하는 단계와; 그리고

청취한 상기 변경 이벤트에 응답하여, 상기 컴퓨터 시스템이 상기 약속의 상태를 변경하는 단계를 포함하는 것을 특징으로 하는 방법.
제 16 항에 있어서,

상기 변경 이벤트를 방송하는 단계는 약속 변경 이벤트를 상기 컴퓨터 시스템내의 복수의 가입 청취기들에게 발행하는 것을 포함하는 것을 특징으로 하는 방법.
삭제
삭제
제 16 항에 있어서,

상기 제 1 약속에 동기하는 제 2 약속을 갖는 제 3 카렌다를 표시하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 16 항에 있어서,

상기 약속의 상태를 변경하는 단계는:

상기 약속의 최초 생성시 임시(905) 상태를 할당하는 단계와;

상기 약속이 예약될 때, 상기 임시(905) 상태에서 준비안됨(910) 상태로 변경하는 단계와;

상기 약속이 공정 준비가 될 때, 상기 준비안됨(910) 상태에서 준비(915) 상태로 변경하는 단계와;

상기 약속에 대한 시작 시간에 이르면, 상기 준비(915) 상태에서 액티브(920) 상태로 변경하는 단계와;

상기 공정이 시작되면, 상기 액티브(920) 상태에서 공정(925) 상태로 변경하는 단계와;

상기 공정이 거의 완료되면, 상기 공정(925) 상태에서 거의 완료(930) 상태로 변경하는 단계와;

상기 공정이 완료되면, 상기 거의 완료(930) 상태에서 완료 상태로 변경하는 단계와;

상기 약속이 취소되면, 상기 약속의 상태를 취소 상태로 변경하는 단계와; 그리고

상기 약속이 중단되면, 상기 약속의 상태를 중단(940) 상태로 변경하는 단계 중 하나를 포함하는 것을 특징으로 하는 방법.
제 16 항에 있어서,

상기 약속의 상태 변경은:

상기 약속은, 해당 약속이 생성되어 상기 카렌다에 예약되어 있지 않은 상태에서는 임시(905) 상태를 할당하고;

상기 약속을 상기 카렌다에 예약하면, 상기 임시(905) 상태에서 준비안됨(910) 상태로 변경하고;

상기 약속이 공정 준비가 되면, 상기 준비안됨(910) 상태에서 준비(915) 상태로 변경하고;

상기 약속에 대한 시작 시간에 이르면, 상기 준비(915) 상태에서 액티브(920) 상태로 변경하고;

상기 공정이 시작되면, 상기 액티브(920) 상태에서 공정(925) 상태로 변경하고;

상기 공정(925) 상태에서 액티브 PM/Qual(945) 상태로 변경하는 단계와;

상기 액티브 PM/Qual(945) 상태에서 공정 PM/Qual(950) 상태로 변경하는 단계와;

상기 공정 PM/Qual(950) 상태에서 완료 상태로 변경하는 단계와;

상기 약속이 취소되면, 상기 약속의 상태를 취소 상태로 변경하는 단계와; 그리고

상기 약속이 중단되면, 상기 약속의 상태를 중단(940) 상태로 변경하는 단계 중 하나를 포함하는 것을 특징으로 하는 방법.
반도체 제조를 위한 자동화된 공정 흐름에서의 카렌다링 시스템에 있어서,

제조 공정을 통하여 웨이퍼들의 로트들을 스케줄링 및 공정하는 복수의 자율적인 에이젼트들(265)과, 여기서 상기 각 에이젼트는 적어도 1개의 스케줄링 및 공정에 관하여 복수의 제조 도메인 엔티티들 각각을 대리하며;

복수의 카렌다들과, 여기서 상기 각 카렌다는 상기 각 도메인 엔티티에 대한 스케줄링시 상기 에이젼트들(265)중 하나에 의해 유지되며; 그리고

복수의 약속들을 포함하며, 상기 각 약속은 복수의 약속 상태들중 하나로 존재하고, 상기 제조 도메인 엔티티에 대해 상기 각 카렌다 상에 상기 에이젼트들에 의해 상기 제조 도메인 엔티티들을 대신하여 스케줄링되며,

상기 카렌다는 이벤트가 발생하게될 적어도 하나의 약속을 포함하고,

상기 약속은 서비스를 제공하기로 확약(commit)된 기간인 커미트먼트 윈도우(commitment window)기간과 상기 커미트먼트 윈도우 기간의 범위내에서 전후로 이동하는 공정 윈도우(processing window) 기간(402)를 가지며,

상기 공정 윈도우 기간(402)은 적어도 하나의 로트(130)가 공정에 들어가기 위해 소비되는 제 1 기간(406)과 상기 소비된 로트(130)가 공정에 들어가 처리되는 제 2 기간(408)을 포함하는 것을 특징으로 하는 카렌다링 시스템.
제 23 항에 있어서,

상기 복수의 에이젼트들(265)은, 로트를 스케줄링하는 에이젼트(305), 머신을 스케줄링하는 에이젼트(310), PM(preventive maintenance)을 스케줄링 하는 에이젼트(318) 및 자원을 스케줄링하는 에이젼트(315) 중 적어도 1개를 포함하는 것을 특징으로 하는 카렌다링 시스템.
제 23 항에 있어서,

상기 복수의 에이젼트들(265)은, 적어도 1개의 스케줄링 에이젼트 및 적어도 1개의 공정 에이젼트를 포함하는 것을 특징으로 하는 카렌다링 시스템.
제 23 항에 있어서,

상기 복수의 카렌다들은 로트를 카렌다링하는 로트 카렌다(385), 머신을 카렌다링하는 머신 카렌다(370), PM을 카렌다링하는 PM 카렌다(318) 및 자원을 카렌다링하는 자원 카렌다(345)를 포함하는 것을 특징으로 하는 카렌다링 시스템.
제 23 항에 있어서,

상기 복수의 약속들은 로트 카렌다링 약속, 머신 카렌다링 약속, PM 카렌다링 약속 및 자원 카렌다링 약속 중에서 적어도 1개를 포함하는 것을 특징으로 하는 카렌다링 시스템.
제 23 항에 있어서,

상기 복수의 약속 상태들은 시험적(905), 준비안됨(910), 준비(915), 액티브(920), 공정(925), 거의 완료(930), 완료(935), 액티브 PM/Qual(945), 공정 PM/Qual(950), 취소 및 중단(940)중에서 적어도 1개를 포함하는 것을 특징으로 하는 카렌다링 시스템.
컴퓨터 시스템에 의해 실행되는 소프트웨어 카렌다에 약속(appointment)을 예약(booking)하는 방법으로서,

상기 카렌다는 이벤트가 발생하게 될 적어도 하나의 약속을 포함하고,

상기 약속은 서비스를 제공하기로 확약(commit)된 기간인 커미트먼트 윈도우(commitment window)기간과 상기 커미트먼트 윈도우 기간의 범위내에서 전후로 이동하는 공정 윈도우(processing window) 기간(402)를 가지며,

상기 공정 윈도우 기간(402)은 적어도 하나의 로트(130)가 공정에 들어가기 위해 소비되는 제 1 기간(406)과 상기 소비된 로트(130)가 공정에 들어가 처리되는 제 2 기간(408)을 포함하는 것을 특징으로 하는 방법.
제 29 항에 있어서,

적어도 2개의 약속들에 대한 상기 커미트먼트 윈도우 기간들은 중복되는 것을 특징으로 하는 방법.
제 29 항에 있어서,

적어도 2개의 공정 윈도우들(402)은 연속적으로 설정되는 것을 특징으로 하는 방법.