본 발명은 실시예와 더불어 기술될 것이며, 본 발명의 원리와, 본 발명 및 그 여러 측면의 구현을 위해 필요한 관련 기능상의 설명을 예를 들어 설명하여 이해를 돕는다. 그러나, 본 발명의 시스템들 및 방법들은 상이한 구성과 형태로 구현 될 수 있으며, 다른 다양한 개조가 본 발명의 기술적 사상의 범위 내에서 가능하다.
1 부- 일반 시스템 개요
본 발명의 시스템들 및 방법들을 더 나은 이해를 위해, 도 1에 도시된 바와 같이, 예시적으로 알려진 공장 자동화(Factory Automation, FA) 시스템을 나타내는 간략화된 블록도[종종 컴퓨터 통합 제조(Computer Integrated Manufacturing, CIM) 시스템으로 불리움]을 고려하면, 본 발명의 시스템은 점선 불록(120)의 요약 형태를 보여주는데, 이는 본 발명의 장점을 설명하는데 도움을 준다. 더 자세히 설명하겠지만, 본 시스템(120)과, 그 구성 요소 및 방법은 신규한 것이며, FA 시스템의 나머지 부분은 개시를 목적으로 종래 기술 또는 공지된 것으로 간주된다. 공지된 FA 시스템의 더 자세한 블록도은 도 2에 도시되어 있으며, 본 발명의 시스템, 구성 요소 및 방법들을 구현하는 부분을 제외하고는 본 발명에 우선하거나 종래의 것으로써 간주될 수 있다.
도 1 및 2에 있어서, 공장 자동화 시스템은 IBM의 SiView 표준, 부룩스 오토메이션의 실시간 디스패쳐(real time dispatcher, RTD) 및, 무라타의 MCS와 같은 MES를 포함하는 기성품(off-the-shelf) 시스템을 사용하여 구현된다. 이러한 개별적인 시스템들을 함께 통합하기 위하여, 이러한 제품들은 호환가능 인터페이스를 제공하는 종래의 기술들을 사용하여 필요한 바와 같이 맞춤식으로 제작하여, 각 시스템은 다른 시스템들과 함께 적합한 통신을 할 수 있으며, 이로써 함께 작업을 할 수 있다. 이러한 3개의 시스템 또는 어플리케이션들 사이에서 메세지를 전달하는 것과 같은 통신을 인에이블하도록 사용되는 인터페이스는 산업-표준 통신 프로토콜이며, 오직 이해를 위해서만 이름이 언급될 필요가 있다. 이러한 인터페이스는 다음을 포함한다 : CORBA(Common Object Request Broker Architecture), HSMS(High Speed Message Service), MQSeries(widely-used IBM middleware). 이 통신 프로토콜들 및 인터페이스 모두는 반도체 제조 산업에서 IBM 및 다른 제조사 뿐만 아니라, 다른 산업, 다른 플랜트 및 공장들에서 광범위하게 사용된다.
도 1은 자동화된 IC 제조 설비와 같은 자동화된 공장을 위한 공장 자동화 시스템(30)의 간략화된 고 레벨 시스템 블록도이다. 도 1은 제조 설비의 자동화 시스템의 전형적인 주요 하위 시스템 및 장비 그룹을 도시한 것이며, 이것은 또한 연결된 본 발명의 문제 해결(issue resolution, ISR) 시스템을 도시한 것이다. 도 1은 또한 하위 시스템들 및 그룹들 및 ISR 시스템 사이의 일반적인 통신 데이터 흐름을 나타낸다. 전형적인 하위 시스템 및 그룹들이 지금 설명될 것이며, ISR 시스템의 설명이 뒤따를 것이다. 최상위 블록(32)은 호스트 시스템(또는 수퍼바이저)을 나타내는데, 이는 MES 하위 시스템(34)을 포함한다. 전형적인 자동화된 IC 제조 설비에서는, 또한 제조 설비에서 사용되는 생산 장비에 의해 실행되는 목표된 전체 운영들에 관련하여, MES 하위 시스템(34)로부터 어떤 커맨드 또는 명령들을 수신하는 생산 장비 제어(production equipment control, PEC) 하위시스템(36)이 존재한다. 이 PEC 하위시스템으로부터의 응답뿐만 아니라, 이러한 커맨드들은 라인(37)이 나타내는 알맞은 통신 경로를 전달한다. IC 제조 설비에서, 많은 다양한 타입의 생산 장비들이 존재하며, 블록 40에서 선택적으로 나타나는데, 그 동작은 수퍼바이저(32)에 의해 발행된 다양한 PEC 커맨드들에 의해 제어되고 동기화된다. 생산 장비의 개별적인 것[종종 툴(tool)이라 호칭됨]은 그 자신의 컴퓨터들 및/또는 마이크로프로세서-기반 제어기들을 포함하며, 이것들은 그 자신의 내부 운영을 제어하고, 만약 모든 것이 제조 설비의 다른 부분과 정보를 교환하지 않는다면, 대부분을 제어한다. 툴들은 일반적으로 포토리소그래픽 작동을 실행하기 위한 스텝퍼(stepper, 41), 이온 주입 장치(42), 메트롤로지 스테이션(metrology station, 43), 클리닝 스테이션(44), 및 타원(45)에 의해 나타나지만 도시되지 않은 다른 스테이션들(결합 스테이션을 포함함)과, 웨이퍼 연마 스테이션들, 다양한 테스트 스테이션들 및, 블록(46)에 의해 나타나는 다른 종래 툴들을 포함한다. 더 대형인 설비에 있어서, 동일성이 있는 툴들의 그룹들 또는 그 유사한 그룹들 또는 관련 툴들 또는 스테이션들은 다양한 베이들로 제공될 수 있다. 모든 이러한 툴들은 PEC 커맨드들을 적당한 라인들(47)을 통해 수신하고, 차례로 다양한 응답을 라인(48)들을 통해 제공한다. 에러 또는 문제 신호들은 라인(49)들을 통해 제공될 수 있다. 라인들(47 내지 49)은 설명을 위해 분리하여 도시된다. 실제로, 도 1 및 2의 이러한 그리고 다른 통신 라인들은 모두 하나 이상의 통신 버스들, 토큰 링들 또는 데이지(daisy) 체인들의 일부일 수 있거나, 어떤 다른 종래의 또는 적합한 형태로 구현될 수 있다. 환언하면, 여기서 묘사되는 다른 라인들과 같은 이러한 라인들은, 물리적인 와이어, 동축 케이블, 광 케이블들, 광 링크 및 무선 주파수 링크들 등의 통신 경로로서 폭넓게 간주되어야 한다.
자동화된 제조 설비(30)는 또한 보통 다수의 운반 장치들의 웨이퍼들 또는 다른 워크-인-프로세스(WIP)를 사용하는데, 이들의 움직임은 다양한 장치들, 스테이션들, 적재 장치(stocker)들 및 다양한 운반 메카니즘 사이의 운반 장치 운반 웨이퍼 또는 다른 WIP로서 추적되어야 한다. 운반 장치들은 SMIF 운반 장치들 또는 FOUP들(front opening unified pods)을 포함하는 공지된 또는 적합한 타입의 것이다. 어떤 적합한 저장(storage) 또는 선적(shipping) 컨테이너들은 FOSB들(front opening shipping boxes)을 포함하여 사용될 수도 있다. 다수의 개별적인 장치들은 바람직하게는, 포토리소그래피, 이온 주입, 메트롤로지, 클리닝, 본딩, 웨이퍼 연마, 테스팅 등과 같은 어떤 종류의 프로세스들에 전용하는 클러스터들 또는 베이들에 배치된다. 각각의 그러한 베이는 일반적으로 복수의 동일성 있거나, 관련된 툴 또는 다른 스테이션들을 구비한다. 적어도 4개의 타입의 자동화된 운반 장비가 툴들 또는 다른 스테이션들, 적재 장치들과 운반 메카니즘들 사이에서 자동으로 운반 장치를 운반하도록 사용된다. 이들 4개의 일반적인 종류의 자동화된 운반 장비들은 점선으로된 대형 블록(50)에서 블록들에 의해 나타내진다. 이 개별적인 베이들 내에는 다양한 베이 내(intrabay) 운반 장비가 블록(52)에 의해 선택적으로 나타내지며 배치되어 있다. 이 베이들 외부에는(종종 내부에도) 다양한 적재 장비가 블록(54)에 의해 선택적으로 나타내진다. 또한 전형적인 제조 설비는 다양한 적재들 및/또는 베이들 사이에서 블록(56)에 의해 선택적으로 나타내지는 다양한 베이-간 운반 장치를 구비할 것이다. 제조 설비는 또한 선택적으로 블록(58)에 의해 나타내지는 로봇들 또는 운반 차량을 사용할 수 있는데, 이들은 다양한 툴들 또는 다른 스테이션들, 적재 장치들, 운반 장치들 및 다른 장비들 사이에서 운반 장치들 또는 다른 객체들을 운반한다. 이러한 운반 장치 운반 또는 로봇들은 이에 제한되지는 않지만 레일-기반(rail-based) 오버헤드 운반 차량들(overhead transport vehicle) 및 셔틀-장착 피벗식 로봇 아암(shuttle-mounted pivoting robotic arm)을 포함하도록 설계될 수 있으며, 이는 3 개 이상의 독립적인 직교 좌표축을 따라 움직일 수 있는 것이다. 이러한 운반 로봇들 또는 차량들은(종종 오버헤드 운반, overhead transport, OHT들 및/또는 운반 로봇들로 호칭됨) 베이들 또는, 종종 FOUP들, FOSB들, 운반 장치들, 카세트들, 파드들(pods) 등 및 관련 툴들, 스테이션들 및 제조 설비 내의 다른 장비들의 효과적으로 정렬된 클러스터들(도시되지 않음) 주위 및 사이의 다른 객체들을 이동시키도록 사용된다.
다양한 위치의 생산 장비(40)는 정기적으로 그 관련 베이-간 운반 장비(52)와 통신하며, 이것은 통신 라인들(62)을 통해 발생할 수도 있다. SEMI(Semiconductor Equipment and Materials International organization)의 표준 E-84(강화 운반 장치 핸드오프 병렬 I/O 인터페이스 또는 PIO)는 종종 이러한 목적을 위해 사용된다. 유사하게는, 베이 내 운반 장비(52)는, 라인들(64)을 통해 적재 장비(54)와 정기적으로 통신한다. 유사하게는, 적재 장비(54)는 라인(66)을 통하여 베이-간 운반 장비(56)와 통신한다. 베이-간 운반 장비(56)는 라인들(68)을 통해서 운반 차량 로보틱 아암 또는 다른 종류의 운반 장비(58)와 함께 통신한다. 유사하게는, 만약 통신이 장비 블럭들(52) 및 블럭들(56 및 58) 사이에서 필요한 경우에는, 개별적으로 라인들(71 및 73)을 통해 제공될 수 있다. 유사하게는, 장비 블록들(54 및 58) 사이에서 필요한 어떤 통신이 라인들(75)을 통해서 발생할 수도 있다. 환언하면, 모든 이러한 라인들에 의해 보여지는 바와 같이, 어떤 두개 또는 그 이상의 생산 장비들 및 운반 장비들 사이에서 또는, 필요하다면 어떤 두개 이상의 운반 장비 사이에서 통신이 발생할 수 있다. SEMI(Semiconductor Equipment and Materials International organization) 또는 다른 알려진 또는 적합한 통신 프로토콜의 통신 표준 No.E84(강화 운반 장치 핸드오프 병렬 I/O 인터페이스 또는 PIO)가 라인들(47 내지 78)을 통해 통신을 구현하도록 목적된 것처럼 사용될 수 있다. 도 1(및 다른 도면들)에서 언급된 다른 라인들 또는 통신 경로들뿐만 아니라, 이러한 통신 라인들은 물리적으로, 전기 케이블들(예컨대, CAT5), 동축 케이블들, 섬유 광학 및/또는 적외선 시스템들, 및 숏-투-미디엄(short-to-medium) 범위 무선 통신 시스템 등을 포함하는 복수의 방법들로 구현될 수 있다.
자동화된 운반 장비(50)의 제어는 점선으로 된 블록(80)에 도시되어 있는 전용 제어기 세트에 의해 조종될 수 있다. 베이 내 운반 장비(52) 모두의 제어는 바람직하게는 전용 시스템 제어기들의 그룹(82)에 의해 처리된다. 예컨대, 베이 내 운반 장비의 모두에 대한 커맨드 및 제어 신호는, 블록(82)에 의해 나타나는 하나 이상의 베이 내 운반 시스템 제어기들을 통해 발송될 수 있다. 유사하게, 모든 적재 장비(54)의 제어는 하나 이상의 적재 시스템 제어기들(84)에 의해 발송되거나 처리될 수 있으며, 베이-간 운반 장비(56)의 제어는 하나 이상의 베이-간 운반 시스템 제어기들(86)에 의해 발송 또는 처리될 수 있다. 마지막으로, 모든 로봇 아암 운반들(58)의 제어는 하나 이상의 운반/로봇 시스템 제어기들(88)을 통해 발송된다. 운반 장비(52, 54, 56 및 58) 및 그들과 관련된 제어기들(82, 84, 86 및 88) 사이의 통신들은 통신 라인들(92, 94, 96 및 98)을 통해 개별적으로 발생한다.
무라타의 유용한 물류 제어 시스템(material control system, MCS)과 같이, 바람직하게는 통합 운반 제어 시스템(100)인, 자동화된 물류 처리 시스템(Automated Material Handling System, AMHS)은 도시된 바와 같이, 운반 제어기(80) 위에 위치하며, 라인들(102, 104, 106 및 108)을 통해 제어기(82, 84, 86 및 88)들의 그룹들과 통신한다. AMHS(100)는 통신 라인들(117)을 통해 호스트 시스템(32)로부터 커맨드들을 수신하며, 또한 지위 및 완료된 커맨드 정보를 라인들(118)을 통해 호스트 시스템으로 반환한다. 그러므로 설명된 장비 및 하위시스템들에서, 장비 및 하위 시스템들이, 에러 조건들, 문제 보고들 및 주목된 문제들로 구성된 다른 아이템들을 포함하고, 생산량 및 관련 정보를 포함하는 지위 정보를 제공하는 것이 일반적이다. 이 데이터는 통신 라인들(119)을 통해 AMHS(100) 및 호스트(32) 사이에서 전달될 수 있다. 일반적으로, 그러한 데이터는 호스트 시스템(32) 내에 수집되며, 다양한 그래픽 유저 인터페이스들, 모니터들, 및/또는 보고들을 통해서 근무자들이 사용 가능하게 된다. 이 데이터는 종종, 단순한 컴퓨터 파일들, 연속된 테이블, 스프레드시트, 또는 하나 이상의 적합한 관련 데이터베이스가 될 수 있는, 하나 이상의 적합한 로그들, 파일들 또는 데이터베이스들 상에 수집된다.
이러한 모든 정보를 수집하는 종래의 목적은, 어떤 이들이 보고를 원하거나, 일부 에러를 조사하려고 하거나, 머신 조건, 문제 또는 상태를 분석하고, 생산 부분 품질, 툴 및/또는 운반 장치 실행도 및 고장 시간에 관한 통계를 획득하거나, 주어진 운반 장치, 툴 또는 툴의 베이들과 같은 주어진 툴 또는 다른 장비에 관련되어 발생하는 다양한 에러 조건 또는 문제들에 관한 정보를 획득하려고 하는 경우에, 차후에 이것을 검사할 수 있기 위함이다. 또한 품질 제어 및 제품 생산 정보는 종종 웨이퍼 레벨 아래에서 수집되는데, 생산 및 생산 문제들은, 제조 설비에서 생산되는 IC 제품의 웨이퍼들 또는 칩들의 생산과 관련하여, 어떤 일이 언제, 발생할 수 있는지를 이해하려고 시도하면서 데이터를 때때로 분석하는 지원 근무자들에 의해 조사될 수 있다.
이러한 종래의 자동화 공장 시스템(30)에, 본 발명은, IC 제조 설비의 자동화 운영 동안 발생하는 적어도 복수의 종류의 에러 조건들, 문제들 및 다른 문제들을 자동으로 처리 및 해결하려는 시도에 도움을 주는 신규한 문제 해결 시스템[Issue Resolution(ISR) 시스템, 120)을 부가한다. 상세하게는, ISR 시스템(120)은 만약 완전한 복수가 가능하다면, 자동 해결에 민감한 것으로 이전에 식별된 문제에 주의하게 되어, 생산은 주목된 에러 조건, 문제 또는 다른 문제에도 불구하고 자동적으로 지속될 수 있다. 환언하면, 자동 운영이 서스팬드되거나 인터럽트되기 보다는, ISR 시스템(120)은 종종 자동으로 에러 조건 또는 다른 문제를 해결하거나, 통과시킬 수 있다. 문제 해결 시스템(120)은 문제 해결 관리(Issue Resolution Management, ISRM) 하위시스템(122) 및 문제 데이터베이스 및 수집(Issue Database and Collection, ISDAC) 하위 시스템(124)을 포함할 수 있는데, 이들 시스템들은 일반적으로 공장 자동화 시스템(30)의 나머지에 필요한 대로 상호접속 될 수 있다. ISR 시스템(120) 및 그 하위 시스템들 및 제조 설비 자동화 시스템(30)의 나머지 내부 및 사이의 예시적인 상호연결들이 도 1에 도시되어 있다. ISRM 시스템(122)은 또한 문제 해결 커맨드 센터(Issue Resolution Command Center, ISRCC, 126) 및 광 커맨드 메모리 요소(128)를 포함할 수 있다. ISRM 하위 시스템(122) 및 ISDAC 하위 시스템(124)은, 라인들(121 및 123)에 의해 보여지는 바와 같이, 바람직하게는 쌍방향 통신 및 데이터 전송을 사용한다.
ISDAC 하위시스템(124)은, 통신 라인들(129)을 직접 통하거나, 다른 라인들에 전달된 정보를 간접적으로 통하여 AMHS(100)로부터 에러 조건들, 문제들 및 제어 상태에 관한 정보를 획득할 수 있다. 상세하게는, 라인들(48, 49, 118 및 119)는 상태 및 에러 조건 정보를 호스트 시스템(32)에 제공하는데, 이 정보는 라인들(134)를 통하여 ISDAC 시스템(124)으로 전달될 수 있으며, 생산 장비 제어 시스템(36)으로부터의 에러 조건 정보와 관련된 정보이다. 유사하게, MES(34)는 라인들(134) 상의 상태 및 에러 조건 정보를 ISDAC 하위 시스템(124)에 제공할 수 있다. 이러한 기술 및/또는 다른 잘 알려진 기술들을 사용하여, 장비 및 워크피이스 상태(workpiece status), 에러 조건들, 문제들 및 다른 문제들에 관한 정보는, 관련 커맨드 정보와 함께, ISDAC 하위 시스템(124)의 데이터베이스에 수집될 수 있다.
문제 해결 관리 하위시스템(122)의 목적은 문제 해결 시스템(120)의 전반적인 운영을 제어하는 것이다. 이를 위한 한가지 방법은, 완전 복구를 포함하는 자동 해결이 가능한 에러 조건, 문제 또는 다른 문제가 언제 발생하는지를 결정하기 위해, ISDAC 하위 시스템(124)의 문제 데이터베이스에서 수집된 정보를 효과적으로 사용하는 것이다. ISRM 시스템(122)이 에러 조건 또는 다른 문제가 발생한 것을 인식한 경우, 보고되었고(플래그되었고) 그렇지 않다면 해결을 위해 허가된 에러 조건 또는 다른 문제를 해결하려는 시도가 필요하기 때문에, 문제 해결 커맨드 센터(ISRCC, 126)는 적당한 세트의 커맨드들을 호스트 시스템(32), 생산 장비(40), 및/또는 AMHS 시스템(100)으로 생성하도록 허가된다. 본 발명의 문제 해결 시스템(120) 및 부수적인 방법이 구현되는 예시적인 방법들이 아래에 상술된다.
2 부 - 구체적인 시스템 개요
도 2는 IC 반도체 칩 또는 다른 IC 제품들에 300 mm 실리콘 웨이퍼들을 처리하는데 사용되는 자동화된 IC 제조 설비를 위한 대표적인 공장 자동화 시스템을 도시한 더 자세한 블록도이다. 도 2의 시스템은 설명되는 바와 같이, 5개의 상이한 방법 중 하나 이상에 있어서, 본 발명의 시스템들 및 방법들을 사용할 수도 있다. 많은 당업자는 도 2에서 사용되는 약어의 의미와 다양한 하위시스템들, 하드웨어 및 소프트웨어 요소들 및 상호연결의 목적을 이해하거나 구별할 것이다. 그럼에도 불구하고, 도 2(및 다른 도면들)를 더 일반적으로 이해할 수 있도록 도시하여, 다음의 약어 해석 표를 제공한다.
[표 2]
약어 해석 표 약어 | 약어 의미(간단한 설명) |
AIX | IBM의 유닉스 운영 시스템(IBM's Unix Operating System) |
AMHS | 자동화된 물류 처리 시스템(automated material handling system) |
APF | AutoSimulation Inc. Productivity Family(RTD, Reporter, AutoSched Ap, 및 MES integration을 포함함) |
BOM | Bill of Material |
CIM system | 컴퓨터 통합 제조 시스템(computer integrated manufacturing system) |
CORBA | 공통 객체 요청 브로커 아키텍쳐(Common Object Request Broker Architecture) |
DCS | 데이터 수집 서버(Data Collection Server) |
EQP | 장비(equipment) |
FAS | 공장 자동화 시스템(Factory Automation System) |
FOUP | front opening unified pod |
HSMS | 고속 메세지 서비스(High Speed Message Service) |
MACS | 무라타 자동화 제어 시스템(Murata Automation Control System) |
MCS | 물류 제어 시스템(Material Control System) |
MES | 제조 실행 시스템(Manufacturing Execution System) |
MM | 물류 관리자(Material Manager, SiView MES의 일부) |
MQ ReqHdlr | MQ 요청 처리기(MQ 메세지들을 CORBA 메세지들로 변환함) |
MQ(Series) | 폭넓게 사용되는 IBM의 비지니스 통합 소프트웨어(미들웨어) |
MQ TxHdlr | MQ 트랜잭션 처리기(CORBA 메세지들을 MQ 메세지로 변환함) |
MSP | 머신 관리 프로그램(a/k/a 툴 어플리케이션 프로그램 = TAP, 셀 제어기, 툴 제어기, 등) |
MSPSA | MSP SiView 어댑터(CORBA 메세지들을 MQ 메세지들로 변환함) |
OHT | 오버헤드 운반(overhead transport) |
ReqHandr | 요청 처리기 |
RMACS | 원격 무라타 자동화 제어 시스템 |
RME | 레시피 관리 편집기(Recipe Management Editor) |
RMS | 레시피 관리 시스템(Recipe Management System) |
RTD | 실시간 디스패치(real time dispatch) |
RTD SvcMgr | RTD 서비스 관리자(RTD service manager) |
RXM | 레티클 트랜잭션 관리자(SiView 표준 요소) |
SAP | 많은 목적들을 위해 사용되는 SAP로부터의 공통 데이터베이스 |
SDD | SECS 데이터 디스퍼서(SECS data disperser) |
SECS | SEMI 장비 통신 표준(SEMI Equipment Communications Standard) |
SiView DCS | 데이터 수집 서버 - SiView 표준 요소 |
SiView MM | 물류 관리자 - SiView 표준 요소 |
SiView MQ | SiView의 MQ 시리즈 요소(트랜스미션/텍스트 커맨드들 및 다른 시스템들로부터의 요청을 처리하기 위함) |
SiView RXM | 레티클 트랜잭션 관리자 - SiView 표준 요소 |
SiView SM | 열거 관리자(Specification Manager) - SiView 표준 요소 |
SiView SPC | 통계적인 프로세스 제어 - SiView 표준 요소 |
SiView Std. | IBM의 신뢰가능 및 확장가능 MES 솔루션 |
SiView WBR | 베이 레티클 내(Within Bay Reticle) - SiView 표준 요소 |
SiView WBS | 베이 시스템 내(Within Bay System) - SiView 표준 요소 |
SiView XM |
트랜잭션 관리자 - SiView 표준 요소 |
SPC |
통계적인 프로세스 제어 |
TCS |
트랜스퍼 제어 시스템(Transfer Control System) |
TOM Client |
전체 순서 관리 클라이언트(Total Order Management Client) |
Tx |
트랜잭션 |
TxHandlr |
트랜잭션 처리기 |
WBR |
Within Bay Reticle |
WBS |
Within Bay System |
Win2k |
MS 윈도우즈 2000 |
WIP |
work in process |
WTDG |
워치독(Watchdog)(장비 상태 및 유용성 모니터링) |
XM |
트랜잭션 관리자(SiView 표준 요소) |
XMS |
트랜잭션 관리자 시스템 |
Xsite |
브룩스 자동화 방지 관리 소프트웨어 시스템(Brooks Automation Preventive Maintenance Software System) |
추가적으로, 도 2의 오른쪽 하단에는, 점선으로 된 박스 내에, 사용되는 통신 경로의 상이한 타입들로의 키가 도시되어 있다. 이전의 테이블 및 키들과 함께, 자동화된 IC 제조 설비에 대한 제어를 설계하는 당업자들은 모든 객체들 및 상호연결 관계들의 기능 및 목적을 이해해야 한다.
도 2의 박스들 일부의 오른쪽 코너 하단에는, AIX(IBM의 유닉스-기반 운영 시스템), 리눅스, 선 솔라리스, 및 윈2K(MS 윈도우즈 2000)와 같은, 운영 시스템(OS)이 나타나 있다. 이러한 개념은 동일한 박스들의 중앙 상단에 리스트된 특정한 어플리케이션들이 개별적으로 구동되는 예시적인 운영 시스템들을 나타낸다. 이러한 어플리케이션들 및 관련 운영 시스템들이 복수의 상이한 컴퓨터 하드웨어 시스템 상에서 구동되며, 공지된 방법으로 된, 기능들의 분리, 관리, 모듈 방식(modularity), 리던던시(redundancy) 및/또는 보안을 제공한다. 또한 제어되는 특정한 어플리케이션 또는 관련 장비들의 소비자, 사용자 또는 공급자에 의존하여, 일부 운영 시스템들은 도 2에 도시된 어플리케이션들 또는 시스템들에 대한 것들 보다 더 자주 사용될 수 있다. 유사하게는, 자동화 장비 및/또는 물류 처리 시스템들 및/또는 관련 제어 시스템들의 제조 설비 소유자들 또는 판매자들은, 어떤 통신 프로토콜들 또는 어떤 타입들의 통신 경로들[예컨대, 무선, 동축 케이블, 트위스티드 페어(twisted pair), 광]을 선호하며, 그러한 선택들은 종종 장소, 속도 요구 및 다른 알려진 인자에 의존한다.
도 2는 그러한 자동화 시스템 및 어플리케이션 및 그들 사이의 통신들의 예시적인 합성을 보여준다. 예컨대, MSPSA는 CORBA 메세지들을 MQ 시리즈 메세지들로 변환하는 MSP SiView 어댑터이고, SiView 트랜잭션 처리기는 CORBA 메세지들을 MQ 시리즈 메세지들로 변환하고, SiView MQ 요청 처리기는 MQ 메세지들을 CORBA 메세지들로 변환한다. 주어진 어플리케이션, 컴퓨터 시스템 또는 장비들을 위해 사용되거나, 그들과 통신하는 운영 시스템들 및/또는 통신 프로토콜들의 선택은 엔지니어들에게는 종종 실제적인 관심사가 될 수 있다. 그러나 그러한 선택들은 본 발명의 시스템들 및 방법들과 관련하여 중요하지 않으며, 이러한 운용 시스템들, 어플리케이션들, 장비, 제어 시스템들 및 통신 프로토콜들 및 경로들과 혼합하여 구현되고 사용된다. 더 나아가, 본 발명의 시스템들 및 방법들은 컴퓨터 기반 또는 전자/마이크로제어기 기반 자동화 시스템들 및, 자동화 제조 설비 또는 다른 자동화 생산 설비들에서 사용되는 자동화 장비의 광범위한 사용에 적용될 수 있다.
도 2에 도시된 바와 같이, SiView 표준 MES가 사용되는 경우, 그 MM(Material Manager, 물류 관리자)은 전체 제조 설비의 두뇌 또는 중앙 제어기이다. MM 기능을 중앙 제어기로써 취급하는 것은 IC 제조 산업의 대부분의 MES들에 의해 사용되는 통상의 패러다임이다. SiView MES는 XM, RXM, WBS 및 WBR 요소들과 같은 복수의 요소들(하위시스템들로 간주됨)로 구성된다. 여전히 다른 요소들이 앞선 표에서 "SiView 표준 요소"로 지정되어 도시되고 식별된다. 이렇게 명명된 4개의 요소들은 MES로부터 MCS로의 로직 흐름을 허가하고 제공한다. 도 2의 자동화 공장의 일 실시예에 있어서, 브룩스 RTD 서비스 관리자(RTD 디스패처)는 제조 설비 내의 모든 툴들 또는 장비들에 대한 자신의 로직 및 전용 규칙을 가질 수 있다. 디스패치 리스트, 또는 "신규한 것"의 리스트로써 보통 참조되는 것에서 툴들 사에서 구동되어야 하거나, 처리되어야 하는 제품들의 리스트들을 생성하는데 도움을 주기 위해서, 전용 규칙들 및 논리을 사용하는 것으로 알려져 있다. 알려진 방법으로 전용 프로그램 가능 로직을 사용하는 RTD는 스케줄들, 우선권들, 커미트 데이트(commit date) 등에 기반하여, 제조 설비 내의 모든 툴에 대한 프로세스 다음에 무엇이 있는지 MES에 알려준다. MES를 사용한 어떤 자동화된 제조 설비는, MES 또는 CIM 시스템의 어딘가에 상주하는 이 일반적인 종류의 스케줄링 및/또는 디스패칭 로직을 가지고 있기 때문에, 브룩스 RTD와 같은 오프 더 쉘프(off the shelf) RTD 시스템이 사용되는지 여부는 중요하지 않다. RTD 또는 디스패처는 MES의 일부로써 구축될 수 있으며, SiView 디스패처와 같은(도 2의 시스템은 사용되지 않거나 구현되지 않음), MES의 분리된 요소가 될 수도 있거나, 브룩스 자동화 RTD와 같이 제3 부분의 어플리케이션이 될 수도 있다. 스케줄러, 디스패처 또는 어떤 제품이 규칙들 또는 로직에 기반하여 자동화된 공장을 통해 다음으로 구동되는지를 선택하는 MES의 구상 또는 개념은, 어느 MES가 가상적으로 어떤 산업에서 사용되는지는 중요하지 않으므로, 여기서는 더 언급할 필요가 없다.
일단 제품들이 다음에 프로세스될 것이라고 선택되면, MES는 전달 요청(delivery request)을 보낸다. SiView MES의 경우에 있어서, 이러한 요청들은 장비 그룹들을 통상 담당하고, 장비 상태 및 유용성을 모니터링하는 "워치독(Watchdogs, WTDGs)"이라 불리는 분리된 프로그램들 또는 로직 요소들을 통해 구현된다. 적절한 워치독은 장비 로드 포트가 유용하다는 것을 확인하고, 또한 로드 요청 팬딩(Load Request pending) 및, RTD에 기반한 새로운 리스트가 MM에 전달 요청을 한다. 이러한 이벤트의 시퀀스는 도 3을 참조하여 이해하는 것이 좋은데, 도 3은 도 2의 공장 자동화 시스템의 완전 자동화 오토-3 디스패칭 동작의 트랜잭션 시퀀스를 도시한 통신 흐름도이다.
WTDG 로직이 전달 요청을 MM에게 전달하는 경우의 하나 이상의 불량 반환 코드들(bad return codes)이 이 상세한 설명의 3 부에 더 기술된다. 이것은, 어떤 이유에 의해 MES가 이 전달 요청에 대한 오류를 만났고, 이 전달 요청이 전달된 것처럼 완료될 수 없는 경우 발생한다. 이 경우, 운반 커맨드들이 MCS로 전달되지 않았기 때문에, 이 에러 조건에 관한 정보는 통상 MES 내, RTD 또는 스케줄러/디스패처 내에 포함된 모든 것이 되고, 문제가 존재함을 여전히 인식하지 못한다. 그러한 예에서, 불량 반환 코드들이 수신된 경우, 예컨대, 만약 그들이 효과적으로 초기 전달 요청 커맨드가 인터럽트 되었다는 것을 나타내는 경우, 본 발명의 문제 해결 시스템(120)은 작동을 하게된다. 아래에서 더 설명되겠지만, 도 5의 흐름도에 도시된 바와 같이, 전용 완전 자동 에러 복구 로직은, 보고된 에러 조건(들)을 처리하고 희망적으로 해결하기 위해, 기술 No.1 아래에 설명된 바와 같이, 도 2의 MES에 직접 구현될 수 있다. 또는 이러한 에러 복구 로직은 기술 No.2 아래에 설명된 바와 같이, 추가적인 요소로써 코딩될 수 있다.
실제적으로, 주어진 에러 조건, 문제 또는 다른 문제, 또는 하나 이상의 에러 조건 세트들, 문제들 또는 다른 문제들에 관하여, 본 발명의 ISR 시스템들 및 방법들을 구현하는 실제적인 기술들 또는 방법들이 다수 존재한다. 여기서 개시되는 접근들은 본 발명의 ISR 시스템들 및 방법들이, 하나 이상의 에러 조건들 세트들, 문제들 또는 다른 문제들을 처리하기 위하여, 필요한 만큼 5개의 후속하는 기술들(즉, 접근들) 중에 어느 하나를 사용함으로써 공장 자동화 시스템에서 논리적으로 구현될 수 있다.
기술 1 : ISR 시스템은 MM 요소에서와 같이, MES에서 직접 설계되고 구현될 수 있으므로, 그것은 MM 로직의 일부이다.
기술 2 : ISR 시스템은 새로운 하위 시스템, 구성 요소들의 세트 또는 MES 하위 요소들의 세트로서 구현될 수 있다. 따라서, 소비자에게는 구입하거나 임차하기 위한 선택적인 시스템으로써 제공될 수 있다.
기술 3 : 적어도 부분적으로, ISR 시스템은 WBS 또는 WBR과 같은 현존 하위 시스템 또는 MES의 구성 요소 내에서 논리적으로 설계될 수 있고 코딩될 수 있다. 여기 5 부에서 설명될, 그러한 하나의 접근은 SiView WBS에서 구현되는 ISR 시스템의 예이다. SiView와 같이 만약 MES가 모듈화되고, 전달 요청 커맨드가 성공적이지만, txXMTrasportJobCreateReq 요청(디스패칭/로딩 또는 언로딩)이 MCS 및 MES 사이에서 실패하는 경우, 이러한 접근은 특히 합리적이다. 이러한 접근은, 두개의 프로그램들 사이의 HSMS 프로토콜을 사용하여, WBS 및 MACS 사이에서 프로그램 되도록 허가할 수 있다. 이것은 또한, 4 부에 리스트되어 있는 에러들 또는 불량 반환 코드들을 해결하기 위해, WBS 또는 MES로부터 커맨드들을 수신하는 성능을 MCS가 구비하고 있다고 가정한다.
기술 4 : ISR 시스템은 사용자의 공장 자동화 시스템의 가능한 해결이 가능한 것으로 식별되는 특정한 조건들을 주소화하도록, 각 사용자에 의해 전체적으로 주문 생산된다. 예컨대, 여기서 설명된 예시적인 자동화 제조 설비에 있어서, MM MES에 의해 수신된 로트 전달 에러들(Lot Delivery Errors)은 3 부 및 4 부에서 설명될 것이지만, 에러 조건 및 실패한 반환 코드들에 기반하여, ISRM 하위시스템이라고 불리는, 자동화 에러 복구 어플리케이션으로 설계되고, 프로그램될 수 있다. 다시, 에러 처리의 일반적인 접근이 도 5의 흐름도에 나타나 있다.
기술 5 : 만약 올바른 데이터가 MES 및 MCS로부터 RTD, MES의 디스패처 또는 스케줄러 요소로 전달된다면, ISR 시스템은 RTD, 디스패처 또는 스케줄러 내에서 구현될 수 있다.
본 발명의 ISR 시스템들 및 방법들을 구현하기 위한 이러한 5가지 기술들 중 어느 하나 이상의 기술들이 단일 자동화 제조 설비의 전체 또는 일부에서 사용될 수 잇다. 예컨대, 에러 조건들의 상이한 타입들 또는 세트들이 전반적인 공장 자동화 시스템 내의 개별적인 ISR 시스템들에 의해 처리될 수 있다. 이러한 접근은 ISR 시스템으로 하여금 모듈화 되도록 하여, 에러 조건들이 제조 설비(30) 내의 어떤 영역 및 스테이션의 타입들, 툴들, 장비 또는 제어 시스템에 전용하는 로컬 ISR 시스템에 의해 처리될 수 있다.
3 부 - 가능한(SiView) MES 반환 코드들/에러 코드들 및 크로스 참조 표
SiView 표준 MES를 포함하는 모든 MES는 실패한 반환 코드들을 가지고 있는데, 이 코드들은 위에서 설명한 이유들에 대해, 전반적인 로직의 일부로써 설계되고 구현되는 에러 조건 코드들이다. 아래 표 3에 리스트된 것은, SiView 표준 MES에 의해 반환 가능한, 가능 반환 코드들 또는 에러 코드들의 설명을 위한 샘플들 또는 서브 세트이다. 이 리스트는 예시적인 것만을 위한 것이고, 모든 가능한 반환 코드를 포함시키려는 것을 의도하지 않으며, 오직 설명을 위해 참조된 문제들의 타입으로 제한된다. 이 리스트는, SiView MES의 환경으로, 본 발명의 시스템들 및 방법들에 따라서, 체크되고, 처리되고 해결되는 예시적인 SiView 표준 MES 반환 코드들를 식별하는데 제공된다. 표 3에서,[*],[**], 내지 [****]는, 런타임 동안 MES 또는 일부의 다른 CIM 시스템 내에서 규정되고 채워진 특정한 값을 참조한다. 표 3에서 사용되는 다양한 두문자들 또는 다른 축약어들은 또한 표 2에서도 규정된다. 다른 축약어는 자명한 것이다[예컨대, "eqp"는 장비(equipment); "ID"는 식별자(identification); "Mgr"는 관리자(manager); "Req"는 요청(request)을 의미함].
[표 3]
반환 코드/SiView 에러 코드 크로스 참조 표 반환 코드 | SiView 에러 코드 & 간략한 설명 |
904 | 000164E 카세트의 상태[사용 불가]가 유효하지 않음 |
905 | 000165E 카세트[***]의 운반 상태[**]가 유효하지 않거나, 운반 장치가 또 다른 운반 예약을 가짐 |
933 | 000185E 로트 03128Y27078.000 프로세스상태 프로세싱이 이 요청에 대해 유효하지 않음 |
958 | 000207E 레티클[****] 운반 상태[**]는 요청에 대해 유효하지 않음 |
1547 | 000244E XMS로부터의 응답이 없음 |
1425 | 000260E 카테고리[DispatchFailCode] 정보가 발견되지 않음 |
1437 | 000272E B323_APCMgr_SendAPCRunTimeCapability |
1468 | 000297E 로트[****]에 대한 프로세스 운영 정보 pdID가 발견되지 않으면, 기본 기록 정보를 체크하라 |
1488 | 000315E 레티클[****] 정보가 발견되지 않음 |
2037 | 000381E 시스템 에러가 발생함 |
2104 | 000385E TCS로부터 응답이 없음 |
946 | 000440E 상세한 포트 I01 포트 상태 |
534 | 000485E 머신이 현재 유용하지 않음 |
117 | 000499E 상세한 포트 I02 포트 그룹이 또 다른 프로세스 그룹 B를 위해 예약됨 |
324 | 000500E (*) 객체 잠금(locked) |
532 | 000558E 상세한 로트 03248GU3252.000는 현재 머신 상태에서 처리될 수 없음 |
979 | 000561E 로트가 방해를 받아 처리될 수 없음 |
329 | 000594E 카세트들이 업무 ID를 제어함 |
2830 | 000714E RTD로부터의 응답이 없었음. RTD 서버 관리자는 유용하지 않음 |
2831 | 000715E RTD 파라미터 Raw_eqp_id가 RTD 인터페이스 동의 파라미터에 존재하지 않음 |
| 000716E RTD 정보가 발견되지 않음 |
1912 | 000718E RTD Interface-Switch가 현재 OFF임 |
1913 | 000719E RTD 타임오버[1800] 헬스 체크 |
1917 | 000731E 파라미터 값이 리미터(Limiter) 범위를 벗어났음 |
2943 | 000739E RTD 인터페이스 라우트 ID 정보가 발견되지 않음 |
1920 | 000750E RTD 하위시스템이 몇몇의 에러를 반환했음. 디스패치 서버에 알려진 활성 스케줄러들 또는 TxWhatNextLotListInq가 없음 |
2848 | 000751E APC로부터의 응답이 없음. APC 서비스 관리자가 유용하지 않음 |
2948 | 000760E 장비 DS01이 이미 IO1 예약됨 |
623 | 000795E 로지컬 스크랩 웨이퍼들이 발견됨. 웨이퍼 소터 동작이 필요함 |
2109 | 000825E 외부 서버(TCS)로의 바인딩(binding)이 실패했음 |
2501 | 000826E 외부 서버(XMS)로의 바인딩이 실패했음 |
1923 | 000829E 외부 서버(RTD)로의 바인딩이 실패했음 |
2949 | 000841E 로트들 다음 운영 요청 운반 장치 카테고리[FOUP-CU-PEI] 및 로트들 현재 운반 장치 카테고리[FOUP-NonCu-PEI]가 매치되지 않음 |
1243 | 000874E 운반 장치-로트 조합이 이전 보고 후에 변함 |
4001 | 0004001E AMHS01로부터의 응답이 없음 |
4134 | 0004134E 운반 요청 운반 장치 카운트 및 수락된 운반 장치 운반 카운트가 매치되지 않음 |
4051 | 0004051E 운반 업무 팬딩(Transfer Job Pending) |
4191 | 0004191E 시스템 에러가 발생함 |
10113 | 0010113E APC 런타임 성능 에러 |
10501 | 0010501E MM이 MQWrapper로 바인드(bind)할 수 없음 |
11906 | 0011906E 장비[****] 레티클 파드 포트[임의의 포트]가 발견되지 않음 |
11925 | 0011925E 머신의 자동 유효가능 레티클 파드 포트가 없음 |
5408 | SiView MSP 어댑터 디스패치 에러 |
4 부 - MACS ACK RC 크로스 참조 표
MACS(무라타 자동화 제어 시스템) MCS를 포함하는 모든 MCS(물류 제어 시스템, Material Control System)는 실패한 반환 코드들 또는 에러 코드들을 그 전체 로직의 일부로서 설계되고 구현되도록 한다. 도 2의 공장 자동화 시스템을 사용하는 제조 설비와 같은 완전 자동화된 제조 설비에서, MACS MCS는, MES 또는, SiView와 같은 MCS는 WBS 및 WBR과 같은 MES의 일부 하위요소로부터 운반 전달 및 픽업 커맨드들[로드, 언로드, 운반 요청, 리라우트(reroute) 등]을 전달받는다. 이러한 커맨드들은 양호하거나 성공적인 반환 코드 또는, 에러 조건 또는 일부 소트의 다른 문제를 나타내는 실패한 반환 코드 중 어느 하나를 가지고 MCS에 의해 확인을 받을 것이다. SiView MES로 MACS에 의해 반환될 수 있는 샘플 또는 가능한 반환 코드들 또는 에러 코드들의 일부가 표 4에 리스트되어 있다. 이 리스트는 모든 반환 코드들을 포함하는 것을 의도하지 않으며, 본 발명의 문제 해결 시스템들 및 방법들은 오직 이러한 타입의 설명으로 제한되지 않는다. 오히려, 표 4는 도 2의 SiView MES 내의 본 발명의 문제 해결 시스템 및 관련 방법들의 구현을 통하여 체크되고, 처리되고, 해결될 수 있는 알려진 MACS 반환 코드들의 일부를 식별하도록 의도된 것이다.
[표 4]
표 4 - MACS 반환 코드 크로스 참조 표
반환 코드 | SiView 에러 코드 & 설명 |
-316 | Reject, 운반 장치 업무가 취소되고 있음 |
-315 | Reject, 운반 장치 업무가 리라우팅되고 있음 |
-314 | Reject, 운반 장치 업무의 상태가 속성 변경을 허가하지 않음 |
-311 | Reject, 운반 장치 업무는 운반 업무와 관련이 없음 |
-310 | Reject, 운반 장치가 또 다른 소유자에게 속함 |
-309 | Reject, ExpStopTime 위반 |
-308 | Reject, ExpStartTime 위반 |
-307 | Reject, 현재 장소로부터 새로운 목적지로의 라우트가 유용하지 않음 |
-306 | Reject, 새로운 목적지가 유용하지 않음 |
-305 | Reject, 새로운 목적지가 풀(full)임 |
-304 | Reject, 알려지지 않은 목적지 장소 |
-303 | Reject, 알려지지 않은 운반 장치 ID |
-302 | Reject, 알려지지 않은 TransferJobID |
-301 | Reject, 알려지지 않은 CarrierJobID |
-215 | Reject, 운반 장치가 알려지지 않은 상태에 있음 |
-214 | Reject, 장비 포트의 이전 업무에 대한 픽업 절차가 아직 완료되지 않음 |
-213 | Reject, 배치 운반, 적어도 하나의 요청이 거절되었음 |
-212 | Reject, 운반 장치가 또 다른 소유자에게 속함 |
-211 | Reject, ExpStopTime 위반 |
-210 | Reject, ExpStartTime 위반 |
-209 | Reject, 소스로부터 목적지로의 라우트가 유용하지 않음 |
-208 | Reject, 목적지가 유용하지 않음 |
-207 | Reject, 소스가 유용하지 않음 |
-206 | Reject, 목적지가 풀임 |
-205 | Reject, 알려지지 않은 목적지 장소 |
-204 | Reject, 알려지지 않은 소스 장소 |
-203 | Reject, CarrierID는 이미 다른 장소에 존재함 |
-202 | Reject, 알려지지 않은 CarrierID |
-201 | Reject, 복제된 TRJOBID |
-302 | S64F3으로부터의 MACS 리라우트(Reroute), 이것은 MACS로 전송된 복제 요청임 |
5 부- WBS를 사용한 자동 에러 복구 예
다음은 알려지지 않은 운반 장치 상태 응답을 체크하고, 처리하며, 그 응답으로부터의 복구를 자동화하기 위한, SiView 표준 WBS 요소에 대한 문제 결정 시스템을 구현하는데 사용되는 하나의 가능한 외부 설계 접근의 예이다. 이 기능 및 목적은 우선 요약되어 설명되면, 그 뒤 더 자세하게 살펴보기로 한다.
XM(SiView 표준 트랜잭션 관리자)은 운반 업무 요청(transport job request)인, TxTransportJobCreateReq를, 메세지를 HSMS/SECS S64F1으로써의 MACS로 전달하는 WBS(베이 시스템 내)로 전송한다. 어떤 에러 조건들 동안(아래에 더 상세하게 설명됨), MACS는 0이 아닌 TJRACK(Transport Job Request Acknowledgment)를 WBS로 반환할 것이다. 이 요청의 목적은 WBS가 정확하게 -215의 TJRACK에 반응하는 것인데, 이는 표 4에 나타난 것과 같이, "Reject, 운반 장치는 알려지지 않은 상태에 있음"에 상응하여, S64F21, 운반 장치 ID 유효성 보고에 응답한다.
자세한 기능 설명. -215의 TJRACK는, 운반 업무 요청이 진행된 운반 장치가, MACS가 운반 업무 요청을 실행하는 것을 금지하는 알려지지 않은 상태에 있다는 것을 나타내는 MACS 에러 코드이다. 조건들 중 하나가 만족되는 경우, 운반 장치는 알려지지 않은 상태에 진입한다.
1) 운반 장치 ID 판독이, MACS가 예상했던 운반 장치 ID와 일치하지 않는 경우.
2) SiView가 영이 아닌 CVALIDFLAG와 함께 운반 장치 ID 유효성 요청(S64F20)에 응답하거나, WBS가 S64F20을 MACS에 전달하는 것을 실패한 경우.
운반 장치로 하여금 알려지지 않은 상태에 차례로 진입하도록 하는 방금 기록된 에러 조건들을 발생시킬 수 있는 예시적인 상황은,
a) MACS 오버헤드 운반(overhead transport, OHT)은 주어진 순서로 툴로부터 운반 장치들을 픽업하는 것을 예상한다. 그러나, 툴은 다른 순서로 운반 장치들을 언로드한다. 차례로, 운반 장치 ID가 적재 입력 포트에서 판독되는 경우, MACS는 운반 장치 상에 존재할 것이라고 예상되는 운반 장치 ID가 실제적으로 운반 장치를 모두 판독한 운반 장치 ID와 동일하지 않다는 것을 발견한다.
b) 툴이 업무 완성을 SiView로 보고하기 전에, 사용자(예컨대, 서비스 기술자)는 툴로부터 운반 장치를 제거한다. 사용자는 그뒤, 운반 장치를 수동 적재 입력 포트에 위치시킨다. 운반 장치 ID 유효성 요청(S64F19)에 대한 MACS 요청이 있는 경우, SiView는 영이 아닌 CVALIDFLAG와 함께 MACS에 응답하는데, 이는 SiView는 운반 장치가 툴 상에 있고, 수동 적재 입력 포트 상에 있지 않다는 것을 예상하기 때문이다. 또는 WBS는 MACS 운반 장치 유효성 ID 요청, 즉 S64F19을 수신하거나, 이 요청에 응답하지 않는다.
상기 조건들이 충족되는 경우, 종래 복구는 사용자로 하여금, MACS 그래픽컬 사용자 인터페이스(GUI)를 사용하여 적합한 세트의 커맨드들을 수동으로 입력함으로써 알려지지 않은 상태로부터 운반 장치를 "릴리스(release)"하도록 요청한다. 본 발명의 시스템에 의하면, 이 솔루션은 MACS S64F21를 사용함으로써 WBS가 TJRACK를 수신한 후에, "릴리스" 커맨드를 자동적으로 생성한다.
자세한 기능 로직. SM은 WBS' FOManager(공장 운영 관리자)에게 운반 업무 생성 요청을 전달한다. FOManager의 TxTransportJobCreateReq 기능의 표준 설명이외에, 본 발명에 따른 기능은 추가적인 로직을 사용하는 "오버헤드(overhead)"이다. TxTransportJobCreateReq에 대한 로직은 TJRACK -215 에러를 리스트화하고, 이 에러에 응답하도록 재설계된다. TJRACK -215을 수신하자마자, FOManager TxTransportJobCreateReq는 MACS SiView 주 포트(primary port)로 S64F21를 전달한다. 그뒤 TxTransportJobCreateReq는 S64F22 응답을 대기한다. MACS로부터의 응답을 수신한 후에, TxTransportJobCreateReq은 그뒤 그 기능을 완료하고, SiView로 원본 TJRACK -215 및 S64F22 확인의 반환 코드를 반환한다(이 에러 복구 운영의 로직 시퀀스를 보여주는 아래의 표 6의 운영 흐름 섹션을 참조할 것).
[표 5]
기능 조건 표
체크 아이템 | 값(필수적) |
SiView 운반 장치 상태 | SiView 상의 운반 장치 상태가 유효하고, 알려짐 |
SiView 운반 운반 장치 업무 | 운반 업무는 현존하는 운반 업무을 구비하지 않음 - 즉, 운반 업무는 리라우트 요청이 아님 |
MACS 운반 장치 상태 | MACS 상의 운반 장치 상태는 알려지지 않은 상태임 |
MACS 운반 장치 ID | 운반 장치 ID는 MACS - 즉, 이것은 알려지지 않은 운반 장치 ID 에러가 아님 |
MACS 운반 장치 장소 | 운반 장치가 MACS의 제어 내에 있음 - 즉, 운반 장치가 물리적으로 MACS 시스템 밖에 있지 않음 |
자동화 지원. 그러므로, TJRACK -215의 반응은 완전히 자동화됨. 새로운 인터페이스가 XM 또는 MACS로부터 요청됨.
[표 6]
운영 흐름 표
SiView XM | ORB | WBS | HSMS | MACS |
| | | | |
TxTransportJob CreateReq | | | | |
| -> | Call TxTransportJobCreateReq | | |
| | Send S64F1 | -> | MACS가 운반 업무를 처리함 |
| | | | 요청을 생성함 |
| | Receive S64F2 | <- | 만약 업무를 처리할 수 있다면, MACS가 TJRACK = 0와 함께 반환됨. 만약 운반 장치 알려지지 않은 상태에 있는 경우, 운반 장치가 알려지지 않은 상태에 있는 경우, MACS가 TJRACK = -215와 함께 반환됨. 다른 경우, MACS가 TJRACK 에러 코드를 반환함. |
| | If(TJRACK == -215) { | | |
| | Send S64F21 | -> | MACS가 운반 장치를 "릴리스"함 |
|
|
Receive S64F22
|
<- |
그뒤 CVRACK = x와 함께 응답함 |
|
|
WBS Return message : TJRACK = -215 and CVRACK = x |
|
|
|
|
} |
|
|
|
|
Return response |
|
|
|
|
|
|
|
앞선 시퀀스에 있어서, 만약 -215 에러가 수신된다면, 상기에 개략된 로직은 자동화된 릴리스 커맨드에 응답한다.
도 5의 흐름도는 대형 제어 시스템의 일부로서, 본 발명의 에러 복구 방법들을 구현하기 위한 하나의 접근을 보여준다. 이 접근은, 문제 해결(ISR) 소프트웨어가 턴 온되거나, 인에이블되는 경우, 타원(500)에서 시작한다. 이것은 MES 또는 MAC의 나머지가 완전 오토3 모드에 있는 경우, 발생하도록 조작될 수 있다. 박스(510)에 나타나 있는 바와 같이, 반복하는 타이머는, ISR 소프트웨어 시스템이 턴 온되는 경우, 시작한다. 타이머는 5, 10, 15, 20, 30, 45, 60 또는 90 초들과 같은 적당한 주기, 또는 2 또는 3 분의 주기로 설정될 수 있다. 검토를 목적으로, 이러한 반복적인 타이머가 1 분으로 설정되고, ISR 소프트웨어의 이 특정한 부분이 로트 전달 에러(Lot Delivery Error, LDE) 메세지를 처리하도록 설정된다고 가정한다. 1 분이 종료되면(또는 타이머에 명기된 다른 시간 주기에서), ISR 소프트웨어는 큐(queue) 내에 새로운 LDE 에러 조건 메세지가 존재하는지 여부를 체크한다. 이 큐는 FIFO(first-in-first-out) 스택과 같은 적합한 방식으로 구현될 수 있는데, 이것은 ISR 시스템과 관련된 입력 버퍼의 일부일 수도 있고, ISR 시스템의 분리된 메모리 장소 내에 저장되어있을 수도 있다.
결정 블록(520)에 도시된 바와 같이, 만약 LDE 메세지가 존재하지 않는다면, 제어는 "아니오" 경로(525)를 통해 커넥터(505)로 루프 백(loop back)되고, 반복 타이머는 새로운 LED 메세지를 다시 체크하기 전에, 소프트웨어가 또 다른 시간(분, minute))을 대기하도록 만든다. 만약 그러한 에러 조건 메세지, 예컨대 MES MM 서버로부터 수신된 메세지가 존재하지 않는다면, 원하는 경우 그것이 어디로부터 비롯된 것인지를 결정하도록 분석될 수 있다. 이 메세지는 또한 분석될 수 있어서, 포함하거나 나타내는 에러 조건 데이터는, 다른 유사한 데이터와 함께 기록-유지 및/또는 가능한 장래 분석을 위해 ISR 소프트웨어에 의해 사용되거나, DB2 데이터베이스와 같은, 적당한 데이터베이스 내에 저장될 수 있다. 검토를 위해, 이러한 새로운 로트 전달 에러(Lot Delivery Error) 메세지가 TxDeliveryCassetteRequest의 결과로써 수신되었고, 이 메세지와 관련된 어떤 실패한 반환 코드(Return Code, RC)가 존재한다고 가정한다.
결정 블록(540)은 다음 단계로, 이 특정한 실패 반환 코드는 문제 해결 소프트웨어에 의해 인식되는 코드들 중 하나인지 여부를 결정하는 것이라는 것을 나타낸다. 만약 그것이 아니라면, ISR 소프트웨어는 제어를 경로(545)로 전달하고, 그뒤 커넥터 서클(505)로 루프 백되는데, 여기서 소프트웨어는 다 블록(510)에서 또다른 분(minute)을 대시한다. 만약 실패한 반환 코드가 인식되는 경우에, 제어는 블록(550)으로 전달되고, ISR 시스템은 일정하게 설정된 에러 복구 동작을 취하거나, 특정한 실패 반환 코드와 관련된 로직 시퀀스를 통하여 진행된다. 이 동작 또는 시퀀스는 하나 이상 시리즈로 된 동작들 또는 보정 커맨드가 될 수 있다. 또한, 툴 또는 제조 설비 고장 시간을 최소화 또는 제거하도록 시도할 수 있는 보정 커맨드들 또는 동작들의 몇몇 코스들이 될 수도 있다. 이러한 동작들 또는 보정 커맨드들이 완료된 후에, ISR 시스템 프로그램은 원(505)로의 경로(555)를 따르고, 블록(510)의 타이머는 또 다른 시간(miniute) 동안 활성화된다.
로트 전달 에러 메세지의 경우에 있어서, 공통 복구 또는 해결 동작들은 다음을 포함하지만, 이에 제한되지 않는다 :
1) 실패 로트를 자동적으로 홀드시킴, 또는
2) 실패 FOUP를 자동적으로 유용하지 않게 함, 및/또는
3) 수동 간섭을 위해 정당한 제조 설비 운영자들 또는 다른 지원 근무자를 호출하거나 이메일을 보내거나, 호출과 이메일을 모두 실행함.
로트를 자동적으로 홀드시키거나, FOUP/운반 장치를 유용하지 않게 하고, 바람직하게는 영향을 받거나, RTD 또는 디스패칭 로직과 같은, 이러한 상태 변화에 관해 알 필요가 있는 그러한 부분들에 동작 또는 단계 또는 다른 결과를 통신함으로써, 제조 설비 내의 다른 제어 소프트웨어가 실패 반환 코드를 유발했던(또는 실패 반환 코드와 관련된) 이러한 객체들을 통과시키는 것을 알게 된다(그리고 코드화 될 수 있음). 이러한 방법으로, MES는 자동 디스패치를 위한 새로운 리스트의 다음 로트로 이동할 수 있고, 완전 자동화 운영들을 계속 할 수 있다. 도 5는 ISR 시스템 구동의 일 예를 나타내지만, ISR 시스템은 아래에서 더 상세하게 설명하는 바와 같이, 즉시 구동되는 도 5의 프로그램 제어의 다양한 예들이 가능하도록 설계될 수 있다. 이러한 방법으로, 당업자들은 본 발명의 ISR 시스템이 다양하고 상이한 보고된 에러 조건들, 문제들 다른 문제들을 실질적으로 동시에 처리할 수 있다는 것을 이해할 것이다.
도 6은 도 1에 도시된 본 발명의 문제 해결(ISR) 시스템(120)을 구현하도록 사용될 수 있는 다양하고 상이한 가능 기술들의 하나를 나타낸다. 도 6의 하드웨어 및 소프트웨어 요소의 정렬은 도 5의 흐름도에 나타난 문제 해결 솔루션과 상응하며, 이 솔루션의 일반화된 접근을 구현하도록 사용될 수 있다. 도 1과 연결지어 이전에 언급한 바와 같이, ISR 시스템(120)은 문제 해결 관리(issue resolution management, ISRM) 하위시스템(122) 및, 문제 데이터 베이스 및 수집(issue database and collection, ISDAC) 하위시스템(124)을 포함할 수 있으며, 이들 모두는 일반적으로 공장 자동화 시스템(30)의 나머지로 필요한 만큼 상호접속될 수 있다. ISR 시스템(120) 및 그 하위시스템들 및 공장 자동화 시스템(30)의 나머지 내의 및/ 사이의 예시적인 상호접속이 도 1에 도시되어 있다. 도 6은 ISRM 시스템(122)의 예시적인 상세한 실시예와, 그들이 어떻게 동작하고, 서로 상호작용을 하는지를 설명하는 것을 목적으로 한다.
도 1 및 도 6에 도시되어 있는 바와 같이, ISRM 시스템(122)은 문제 해결 커맨드 센터(ISRCC, 126) 및 선택적인 커맨드 메모리 요소(128)를 포함할 수 있다. 도 6에 도시되어 있는 바와 같이, 구성 요소(128)는 만약 원한다면, ISRCC(126)의 일부가 될 수 있다. 도 1과 연결하여 설명하는 바와 같이, 이 문제 해결 시스템(120)은 ISDAC 하위시스템(124)을 포함할 수 있는데, 이 시스템은 에러 조건들, 문제들, 및 제어 상태에 관한 정보를 통신 경로들(129)을 통해 직접적으로, 또는 도 1에 도시된 다른 경로를 통한 정보를 통해 간접적으로 AMHS(100)로부터 수신하고 수집하는데, 이 다른 경로는 호스트 시스템(32), 생산 장비 제어(production equipment control, PEC) 하위시스템(34), 및 MES(36)으로(그리고 이들로부터) 상태 및 에러 조건 정보를 제공한다. 도 6의 상단에는, 이러한 정보가 블록들(606, 607 및 608)에서 ISRM 하위시스템(122)으로 전달되는 것이 도시되어 있다. 블록(606)은 통신 경로(616)상에 들어오는 에러 조건들, 문제 보고들 또는 다른 문제 요청 처리에 관한 수신 메세지를 나타낸다. 블록(607)은 에러 조건 확인들, 또는 경로(617)를 따라 전달된 다른 관련 에러 조건을 나타내는데, 이것은 ISR 시스템(120)이 하나 이상의 보고된 에러 조건들을 해결하도록 시도하는 경우에 도착할 수 있다. 블록(608)은 호스트(32), MES 하위시스템(34), 및 PEC 하위시스템(36)을 포함하여, IC 제조 설비(30) 내의 다른 제어 시스템들로부터 수신된, 시스템 및 장비 상태 메세지들을 나타낸다. 이러한 상태 메세지는 적당한 통신 경로(618)를 따라 ISR 시스템(120)으로 인입되는 것으로 나타난다.
도 6은, 시스템(122)이 자동화된 제조 설비(30) 내의 임의의 적당한 컴퓨터 시스템 상의 분리된 어플리케이션으로써 구동될 수 있는 독립적인 하위시스템으로써 설정될 수 있다는 것을 나타내기 위한, 대형 점선 박스 내의 문제 해결 관리(ISRM) 시스템(122)을 보여준다. 필요한 컴퓨터 하드웨어는 컴퓨터 제어 시스템(Computer control System, CCS, 600)에 의해 나타나는데, 그것은 자신의 내부 ROM 및 RAM 메모리, 하나 이상의 적당한 대형 저장 장치(mass storage devices, MSD들), 및 제조 설비(30)의 다른 부분들과 함께 통신하기 위한 적당한 입/출력(I/O) 장치와 함께 하나 이상의 중앙 처리 장치들(CPU)을 구비한다. 도 6의 상단 오른쪽 코너에 도시되어 있는 바와 같이, ISRM 하위시스템(122)은 문제 해결 수퍼바이저(issue resolution supervisor, ISR) 프로그램(SP, 605)을 선택적으로 포함하는데, 이것은 전체 시스템(122)의 운영을 바람직하게 통합한다. 시스템(600)은 또한 도 6의 오른쪽 하단에 도시되어 있는, 경로들(616, 617 및 618) 및, 하나 이상의 출력 버퍼들(691 및 692) 상의 수신 신호들 또는 메세지들을 수신하고 임시로 유지하기 위한 하나 이상의 적당한 입력 버퍼들(615)을 포함한다. 로그 버퍼(692)는 문제 저장 장소(698)에 전달되는 외부로 향하는 로그 메세지들(OB Log Msgs, 669)을 수신하는데, 이 문제 저장 장소는 ISDAC 하위시스템(124)의 일부일 수 있다. 저장 장소(698)는 컴퓨터 시스템(600)상의 하나 이상의 로컬 파일들 또는 데이터베이스들을 제공받거나, 또 다른 컴퓨터 시스템 상에 위치한 원격 저장 장치들 상의 파일들 또는 데이터베이스들이 될 수 있다.
도 6의 오른쪽 하단은 하나 이상의 외부 지향(outbound, OB) 자동 보정 커맨드(correction command, CC) 메세지들(690)이 도 6의 중앙 중간-사이즈의 점선 박스에 도시된, 문제 해결 커맨드 센터(ISRCC, 126)로부터 적당한 통신 경로(689(를 넘어 출력 버퍼(692)로 전달됨을 나타낸다. 그뒤, 적절한 통신 프로토콜(CORBA 또는 MQSeries)로 메세지들을 변환한 후 및 적절한 때에, 이러한 보정 커맨드 메세지들이 호스트 수퍼바이저(32) 또는 자동화된 물류 처리 시스템(AMHS, 100)과 같은 자동화된 제조 설비의 일부로의 적절한 통신 경로들을 통한다(경로 132 및 142에 의해 예시되는 바와 같이).
ISRM 하위시스템(122)은 또한 6개의 주요 소프트웨어 요소들을 포함할 수 있는데, 이 요소들은 간략하게 설명될 문제 리스트(675) 및 다른 부분들을 인식하는 것과 같이, 하나 이상의 하위요소들 및 다른 리스트들, 부분들 또는 하위요소들을 또한 구비할 수 있다. 이 6개의 주요 요소들은 제1 요소(610), 제2 요소(620), 제3 요소(630), 제4 요소(640), 제5 요소(650) 및 제6 요소(660)이며, 이들은 일반적으로 도시된 바와 같이, 신호 흐름의 관점에서 상호 접속될 수 있는 것이다. 수신 에러 조건(EC) 메세지들(606)은 입력 버퍼들(615)에서 수신되고 임시적으로 저장되는데, 여기서 수퍼바이저 프로그램(605)은 메세지들이 분석되고 만약 필요하다면 해석되도록 하며, 일반적으로 실패 반환 코드들일 수 있는 그러한 EC 메세지들이 제1 요소(610)로 전달되고, EC 또는 실패 반환 코드가 인식되는지 여부를 알도록 체크한다. 이것은 경로(674)에 의해 제시된 바와 같이, 인식된 문제 리스트에 대해 수신된 EC 또는 실패 반환 코드 또는 다른 문제 코드를 체크함으로써, 완료되고, 분리된 파일 또는 모듈(675)에서 유지될 수 있다. "인식된 문제"란 실패 반환 코드 또는 다른 코드화된 메세지를 현재 의미하며, 이를 위해 ISRM 시스템이 하나 이상의 보정 커맨드들 및/또는 다른 "문제 결정" 동작들을 제공하도록 프로그램되었는데, 이것들은 문제를 자동적으로 해결할 수 있고, 적어도 자동적으로 문제를 처리할 수 있어서, 자동화된 제조 설비의 나머지가 인간을 즉시 관여시킬 필요 없이, 생산을 계속할 수 있게 된다. 수신 실패 반환 코드가 리스트(675) 상에 있는 것으로 인식되었는지 여부를 나타내는 신호 경로(676)를 따라 적당한 응답이 전달된다. 그 뒤에, 제1 요소(610)는 경로(637)를 따라 필요한 대로, ISR-SP(605) 및/또는 다른 모듈들(620, 630, 640, 650 및/또는 660)에게 수신 에러 조건이 인식되었는지 여부에 관하여 알려준다.
만약 에러 조건이 인식되면, 그 뒤, 경로(636)에서, 신호가 제2 요소로 전달되고, 이는 문제 결정 커맨드 센터(126)의 일부이다. 확장 제2 요소(620)가 어떤지에 따라, 그것은 고유의 마스터 제어(master control, MC) 프로그램(624)을 구비할 수 있고, 그것은 제1 하위요소(621)에 의해 지시된 바와 같이, 2개 이상의 하위요소, 제2 하위요소(622), 경과(623) 및 N번째 하위요소(629)를 구비할 수 있다. 실제적으로, N은 ISR 시스템이 처리되도록 프로그램된 실패 반환 코드들과 같은 상이한 EC들을 처리하는데 필요한 만큼의 높은 수가 될 수 있다. 제조 설비 설비 운용을 책임지는 기술자들 및 엔지니어들은, 특히 어떤 종류의 자동화된 응답들이 임의의 주어진 EC, 문제 또는 다른 문제의 발생을 유발하는데 민감한지를 이해한 경우에, 보고된 에러 조건들(EC들), 문제들 또는 다른 문제들에 대한 자동 응답을 고안할 것이다. 그러므로, 간단한 ISR 시스템들은 단지 소수의 보고된 에러 조건 코드들 또는 다수의 보고된 에러 조건 코드들조차 처리하도록 기록된 코드들의 전용 라인들을 가지고 설계되고 구현될 수 있음에도 불구하고, ISR 시스템을 구성하는 제2 요소 및 다른 요소들 내의 더 많은 규정된 정제된 소프트웨어 구조들을 포함하도록, 본 발명의 ISR 시스템의 사이즈가 증가할 것으로 예상되는 곳에서는 유용할 수 있다. 그러한 정제는 도 6 및 도 7과 연결지어 도시되고 설명된다. 시간이 지나면, 다수의, 잠재적으로는 몇 천 개 이상의 반환 코드들이 궁극적으로 하나 이상의 인식된 문제 리스트들(675)에 추가될 수 있으며, 대형 자동화된 제조 설비와 함께 하나 이상의 문제 해결 시스템들(120)에 의해 처리될 수 있다.
이러한 관점에서, 만약 원한다면, 제2 요소(620)는 분리된 커맨드 메모리(128) 및 문제 해결 커맨드 센터(ISRCC) 시퀀서(685)를 구비할 수 있다. 메모리(128)는 자동화된 커맨들 또는 자동화된 커맨드된 동작들의 하나 이상의 저장된 코스들을 참조하여, 경로(682)를 통해 액세스된다. 통상 이러한 것들은, 보고된 특정한 에러 조건(EC), 문제 또는 다른 문제가 가능한 자동화된 해결을 위한 바람직한 후보자라는 것을 인식하자마자, 제조 설비 지원 근무자에 의해 일찍 기록되고, 테스트될 것이다. 각각의 그러한 코스에 대한 커맨드 및/또는 목적된 동작들의 저장된 리스트들은 통신 경로들(687 및 688)을 통해 메모리(128)로부터 시퀀서(685)로 필요한 만큼 순서대로 제공될 수 있다. 종종 코스는 시도되는 단일 커맨드 또는 단일 동작으로 구성될 수 있지만, 때때로 커맨드들 또는 동작들의 주어진 코스 내에서 시도되는 둘 이상의 단계들이 존재할 수 있다. 만약 제1 코스가 목적된 결과(예컨대, 보정, 치료, 교정 또는 보고된 에러 조건 분석)를 제공하는 것이 실패한다면, 그뒤, 만약 유용하다면, 또한 메모리(128)에 저장된 자동화된 보정 커맨드들 또는 커맨드된 동작의 제2 코스가 시도될 것이다. 만약 그러한 것들이 원하는 결과를 제공하는 것이 실패한다면, 원하는 결과가 생산되거나, 이러한 보고된 특정한 EC 또는 문제를 해결하도록 자동화 기반에서 시도되는 메모리(128) 내의 커맨드들 또는 동작들의 모든 유용한 코스들이 소진될 때까지, 만약 유용하다면, 메모리(128)에 또한 저장된 커맨드들 또는 보정 동작들의 제3 코스가 계속 시도될 수 있다.
어떤 에러 조건들, 문제들 또는 다른 문제들에 대하여, 하나의 가능한 자동화된 보정 동작은 적합한 출석 근무자(종종 운영자 또는 근무중인 서비스 기술자 또는 호출받은 엔지니어)로 하여금 어떤 적당한 수단에 의해 즉석 메세지를 자동으로 보내도록 하는 커맨드를 발행하는 것이다. 그러한 수단은 호출기, 셀 폰 또는, 무선-가능 개인 디지털 단말기(PalmPilot 또는 Blackberry와 같은)와 같은 다른 적당한 휴대용 무선 통신 장치를 포함할 수 있다. 메세지는 종합적으로 생성된 음성 메세지, 이메일 메세지, 또는 어떤 다른 적당한 통신 방법과 같은 짧은 텍스트 메세지, 코드화된 텍스트 메세지로써 전달될 수 있다. 이러한 종류의 메세지는 만약 원한다면, 보정 단계들의 시퀀스 내에 특정된 최후의 자동화된 커맨드들 또는 동작들 또는 그러한 동작들 중 하나가 될 수 있다. 종종 대부분의 경우, 그러한 메세지는 모든 다른 특정한 자동화된 커맨드들 또는 동작들이 성공 없이 시도되는 경우에 사용될 것이다. 또한, FOUP, 툴 또는 스테이션이 성공적으로 오프라인되거나, 자동적으로 자동화된 ISR 시스템에 의해 취급되는 경우에조차, 몇몇의 예에서, 근무자에게 문제 및, 취해질 보정 동작에 관해 주의를 주는 것이 바람직할 것이다.
상기의 요약에서 강조한 바와 같이, ISRM 시스템(122)은 항상 보고된 에러 조건 또는 다른 문제에 응답할 수 있는 것은 아니다. 시스템(122)은, 유용한 상태 정보를 통해, 보정 응답을 생산하는 것을 배제하는 어떤 시스템 또는 장비 상태가 존재한다는 것을 인식할 수 있고, 이러한 효과로의 메세지를 생성하는 것에 유용할 수 있다. 이러한 기능을 구현하는 하나의 방법은, ISRM 시스템(122)의 제2 요소(620)가 다음을 포함하는 것이다 : 자동화된 보정 동작이 현재 취해질 수 있는지 여부를 결정하기 위한 제1 하위요소(621) 및, 이 제1 하위요소와 통신하여, 자동화된 보정 동작이 현재 실행될 수 없다는 것을 또 다른 제어 시스템에 알려주기 위한 제2 하위요소(622). 만약 원한다면, 제2 하위요소(622)는 예컨대, 자동 모드에 있지 않은 제2 메세지 내에서 인식되는 적어도 하나의 장비 또는 다른 자동화와 같이, 제1 메세지 내에서 특정하게 인식되는 조건 때문에, 자동화된 보정 동작이 취해질 수 없다는 것을 제1 메세지를 통해 알려주도록 운영적으로 조절될 수 있다. 자동화는 예컨대, 툴, 스테이션, 운반 장치, 제어 시스템, 통신 장치, 링크 또는 시스템 또는 수퍼바이저 시스템이 될 수 있다. 이러한 상황은 예컨대, 지원 요원 또는 다른 원인이 문제의 장비 또는 다른 자동화를 자동 모드 밖으로 위치시키는 경우, 발생할 수 있다. 따라서, 만약 원한다면, ISRM 시스템(122)은 보정 동작을 오프라인된 장비 또는 다른 자동화가 요청된 자동 모드로 반환될 때까지 홀드하도록 할 수 있다. 이러한 기능은 제2 요소(622)의 마스터 제어(Master Control, MC, 624)로 기록될 수 있다. 경로(628) 상에 제공된 상태 정보 메세지들을 통해, 보정 동작을 홀드시키도록 하는 조건이 클리어된 것을 안 경우에, MC(624)는 만약 원한다면(즉, 프로그램된다면), 해결되지 않은 에러 조건을 클리어하도록 시도된 적합한 보정 커맨드들의 생성을 재-활성화할 수 있다.
더 나아가, 본 발명의 ISR 시스템은, 적당한 경우, 다양한 보고된 에러 조건들 또는 다른 문제들로의 미리 계획된 응답의 부분으로써, ISR 시스템 밖의 하나 이상의 제어 시스템으로, 그 자신의 보고된 메세지들을 전달할 수 있다. 하나의 그러한 보고 메세지는 에러 조건이 성공적으로 해결되었는지 여부이다. 다른 보고 메세지들은 문제 해결 노력의 상태를 주소화할 수 있다. 예컨대, 주어진 보고된 에러 조건들에 관하여, 그러한 상태 메세지들은 다음을 포함한다 :
(1) "인식되지 않은 EC(EC Not Recognized) - 어떠한 자동화된 ISR 응답도 유용하지 않음"(이 보고된 EC를 위해 SR 시스템으로 그 어떤 것도 아직 프로그램되지 않았음을 의미);
(2) "문제 인식 ; 클리어를 대기함(Issue Recognized;Awaiting Clearance)"(보고된 EC 또는 실패 RC(그러나 일부 다른 조건)가, 완전 자동 모드에 있지 않은 몇몇의 시스템 또는 장비들과 같이, 자동화된 ISR 응답이 실행되는 것을 예방하고 있다는 것을 ISR 시스템이 인식한다는 것을 의미함)
(3) "진행중인 자동 ISR 응답(Automated ISR Response in Progress)"(ISR 시스템이, 인식된 EC의 해결을 위해 운영됨을 의미함)
(4) "자동화된 ISR이 성공적으로 완료됨(Automated ISR Completed with Success)"(EC가 클리어되었거나, 그렇지 않다면, ISR 시스템에 의해 해결됨을 의미)
(5)"자동 ISR이 성공없이 완료됨(Automated ISR Completed without Success)"(ISR 시스템이 이러한 특정한 EC에 대한 자동화된 보정 커맨드들 및/또는 동작들의 미리-프로그램된 시퀀스들을 통해 진행되었음에도 불구하고, EC가 해결되지 않았음을 의미)
이러한 보고 메세지 각각은 필요한 경우 전달될 수 있다. 이러한 관점에서, 보고 메세지는[특정한 아이템(예컨대 제어 시스템, FOUP, 툴, 스테이션 또는 다른 장비)이 다운되거나 ISR 시스템에 의해 오프라인되었다는 메세지], 제조 설비 내의 MES, PEC 또는 다른 제어 시스템 또는 컴퓨터로 ISR 시스템에 의해 자동적으로 전달된다. 이 메세지는 만약 원한다면, 서비스 또는 다른 다음 동작이 근무자에 의해 요청되고, 영향을 받은 아이템이 관리 활동의 계획된 스케줄 상에 있다는 것을 지시할 수 있다. 이렇게 자동적으로 생성된 메세지는 특정한 상황의 우선권의 감지된 레벨을 나타내도록 미리 프로그램된 정보를 포함할 수 있다. ISR 시스템으로부터의 그러한 메세지는 또한 적합한 지원 근무자로의 무선 통신 시스템들을 통해, 원하는 경우 전달될 수 있다. 자동화된 공장 환경에서 무선 메세징 시스템을 구현하는 방법의 다양한 설명은 공동으로 출원되어 팬딩 중인 후카자와 등의 출원(특허출원 공개 번호 No.US 2002/019864, 공개일 2002, 12월 26일, 발명의 명칭, "Method and System for Wireless Remote Monitoring and Control of a Manufacturing Execution System,"으로 본 명세서에서는 참조로써 통합됨)에 기술되어 있다. 도 6의 다양한 요소들이 하나 이상의 이러한 메세징 작업들을 할당할 수 있다.
만약 원한다면, 도 7에 도시된 바와 같이, 복수의 제2 요소가 ISRM 시스템(122), 각각의 고유한 보고된 EC에 대한 하나 또는 다른 보고된 문제 내에서 제공될 수 있다. 도 6에 도시된 바와 같이, ISRCC(126)는 제2 요소(122)를 포함하는데, 이것은 다양한 하위요소를 포함할 수 있다. 그러한 하위요소는 경과들(623)에 의해 나타나는데, 가능한 보정 동작의 적어도 제1 및 제2 코스들을 제공하기 위한 것일 수 있으며, 반면에 하위요소(629)와 같은 또 다른 하위요소가 가능한 보정 동작의 제1 코스를 취하고, 보정 동작의 가능한 제2 코스를 취하고, 그 뒤 보정 동작의 제3 코스를 취하도록 명령하도록 조절될 수 있다. 보정 동작의 그러한 코스 각각은 하나 이상의 단계들 또는 동작들을 포함할 수 있으며, 동작의 특정한 코스 내의 이러한 단계들 또는 동작들은 어떠한 임시 포맷이 필요한 경우에도 실행될 수 있는데, 이는 시간 기반 또는 어떠한 시퀀스 또는 실질적인 병렬 형식 등에도 제한이 없다. 이러한 하위요소들(623 및 629)은 커맨드 메모리(128) 내에 저장된 정보에 접근하고, 외부지향 보정 커맨드들(690)을 발행하는 경우에 서비스 시퀀서(685)를 사용하도록 조정될 수 있다. 시퀀서(685)의 일은 특정한 임시 포맷 내의 각각의 미리 계획된 시퀀스를 실행하는 것으로, 이 포맷은 커맨드 메모리(128) 내에서 인식된 각각의 EC에 대한 엔트리들(entries)에 적합한 코드화된 형식으로 저장되는 것이 바람직하다. 만약 발행된 그 제1 커맨드 또는 동작이 원하는 문제-해결 결과로 귀착되지 않는 경우, 제2 요소는 내부 커맨드를 신호 경로(631)를 통해 시퀀서(685)로 발행하고, 그 시퀀서는 다음 자동화된 커맨드 또는 동작을 적합한 시간에 발행하도록 진행된다.
실제로, 상기 주목한 바와 같이, 일부 에러 복구 상황들은 2, 3, 4, 또는 그 이상의 가능한 동작의 보정 단계들 또는 코스들을 종종 어떤 시퀀스로 실행하는 단계를 포함한다. 그 경우에, 에러 조건은 단계들의 시퀀스의 말미(end)에 도달하기 전 해결될 수 있다. 이러한 문맥에서, 제3 요소(630)는 가장 최근 발행된 자동 보정 커맨드 또는 가장 최근 발행된 자동 보정 커맨들 또는 동작들의 코스가 보고된 에러 조건 또는 문제를 해결했는지 여부를 결정하도록 조정될 수 있다. 제2 요소(620)는 경로(656)를 통해 그 자신의 상태의 제3 요소(630)를 구별하고, 경로(632)를 통해 요소(630)에게 또 다른 보정 커맨드가 발행되었다는 것을 알린다. 3 내지 6번째 구성 요소들(630, 640, 650 및 660)은 모두 입력 버퍼들(615)로의 경로들(617 및 618) 상에 제공된 메세지들을 통해, 발행된 자동 보정 커맨드들 또는 동작들의 효과에 관한 정보를 제공할 수 있다. 그러한 정보는 다음을 포함한다 : 제어 시스템 상태; 툴, 스테이션 및/또는 장비 상태; 호스트 수퍼바이저(32), MES(34), PEC(36) 및/또는 AMHS(100)로부터의 보정 동작들 또는 동작들에 응답하여 반환된 메세지들 ; 등. 그러한 메세지들의 정보는 통신 경로(627)를 통해 제1 요소(610)로 분배될 수 있으며, 그 뒤 필요한 경우, 경로(637)를 통해 정보를 제2 내지 제6 요소로 전달한다. 이러한 방법으로, 제2 내지 제6 요소는 각각의 그러한 요소에 관하여 언급한 기능을 제공할 필요가 있다는 정보를 제공받는다.
제3 요소(630)는 자동화된 보정 동작이 에러 조건 또는 다른 문제를 해결할 것인지 여부를 나타내는 경로(657)를 통해 제1 메세지를 제공하도록 그 자신의 제1 하위요소를 포함할 수 있다. 이러한 메세지를 제3 요소(630)으로부터 수신함으로써, 제2 요소(620)는 또 다른 보정 커맨드 또는 동작을 발행하거나, 자동 보정 커맨드들 또는 동작의 다음의 미리 계획된 코스를 취하는 것이 필요한지 여부를 결정한다. 만약 원한다면, 시간 지연이 외부 제어 시스템들, 툴들, 스테이션들 또는 다른 장비를 주도록 제3 요소(630)에 제공되는데, 이 장비들은 자동 보정 커맨드를, 에러 조건 또는 다른 문제를 클리어하기 위해 작업하고, 하나 이상의 확인 메세지(607) 및 상태 메세지(608)를 통해 ISRM 시스템에 보고하기에 적합한 시간에 수신하여서, 희망하는 결과가 달성되었는지 여부가 결정될 수 있다. 만약 원한다면, 경로(632)는 제3 및 제5 요소(630 및 650)로의 ISRCC의 시퀀서(685) 사이에 제공되어, 언제 또 다른 자동 보정 커맨드가 발행되는지를 나타내고, 그 다음 단계를 취하기 전에 제3 및 제5 요소의 최대량이 기다린다는 것을 설명한다. 시퀀서(685)는 어드레스화된 특정한 EC와 관련된 모든 자동 보정 커맨드들이 시도되었는지 및/또는 더 이상 시도될 커맨드들이 없다는 사실을 알 것이다. 이것이 발생하는 경우, 시퀀서(685)는 요소(630 내지 660)로의 경로(668) 상을 따라 전달된다는 것을 알리도록 메세지를 생성한다. 이러한 방법으로, 요소들(630 내지 660)은 어떠한 큰 지연없이, 제2 요소(620)에 의해 현재 주소화된 인식 EC 에 관하여 취해진 더 이상의 보정 커맨드들 또는 동작들이 존재하지 않는다는 것을 알게 된다.
제5 요소(650)는 만약 원한다면, 어떤 특정한 자동 보정 동작 또는 커맨드가 보고된 EC 또는, 제2 요소(620)에 의해 현재 어드레스화된 실패 RC를 해결할지를 결정하도록 제공될 수 있다. 제5 요소(650)는 어떤 자동 보정 커맨드 또는 동작이 보고된 EC 또는 다른 요소에 의해 주소화된 다른 문제와 결합하여, 마지막에 발행되었는지를 주목함으로써 간단하게 이를 행할 수 있다. 또한, 제5 요소(650)는 경로(637)를 통해 제공된 확인 및 상태 데이터를 분석하도록 설정될 수 있고, 결정을 내리기 위해 최종 발행된 커맨드 또는 동작뿐만 아니라 그 데이터를 사용할 수도 있다. 어느 경우에나, 구성 요소(658)는 또한 제5 요소의 발견 또는 결정을 보고하는 메세지를 전달하는 하위요소를 포함할 수 있으며, 그런 메세지는 경로(666)를 통해 제4 및 제6 요소들(640 및 660)로 전송될 수 있다.
제3 요소(630)과 같이, 제5 요소(650)은 적당한 시간 지연 후, 또는 제2 요소(620)에 의한 동작의 동일한 코스의 많은 시도 또는 반복 후에 앞서 말한 기능들을 실행할 수 있다. 또한, 제5 요소(650)는 어떤 보정 커맨드 또는 동작 또는 어떤 보정 커맨드들 또는 동작들의 코스가 보고된 에러 조건 또는 어드레스화된 다른 문제를 해결했다고 나타나는지를 결정하는 기능들의 실행을 시작하기 전에, 제3 요소(630)이 그 결정을 내릴 때까지 단순히 대기할 수 있다. 만약 제3 및 제5 요소들이 깊게 관련되어 있다면, 이러한 요소들은 원한다면 단일한 조합형 요소들로서 조정될 수 있다
제4 요소(640)는, 보정 커맨드 시퀀스가 보고된 에러 조건 또는 다른 문제를 해결했는지 여부를 로그하는 ISRM 하위시스템(122)의 일부이다. 제6 요소(660)는, 만약 원한다면, 어떤 특정한 자동 보정 커맨드 또는 동작이 보고된 에러 조건 또는 다른 문제를 해결했다고 나타나는지를 로그하도록 제공될 수 있다. 구성요소들(640 및 660)은 경로(669)를 통해 외부로 향하는 로그 메세지들(O.B.Log Msgs)을 로그 버퍼(691)로 제공하는데, 그들은 때때로, 이전에 설명했던 로그된 문제 저장 장소(698)로 전달된다. 도시되지는 않았지만, 당업자는 그렇게 제4 및 제6 요소들로부터 외부로 향하는 메세지들이 또한 버퍼(691)에 의해 호스트 수퍼바이저(32)로, 자동화된 물류 처리 시스템(100)으로, 또는 필요한 다른 시스템으로 전달될 수 있다. 실제적으로, 커맨드 메모리(128)는 선택적으로 각 리스트된 엔트에 대한 데이터가 로드될 수 있는데, 이 엔트리는 제1, 제2, 제4 및/또는 제6 요소들로부터 외부로 향하는 메세지들을 수신할 수 있는 제조 설비(30) 내의 다른 제어 시스템들을 설명하는 것이다.
당업자들은 ISRM 하위시스템(122)의 어떤 주어진 요소 내의 어떤 주어진 기능이, 원한다면 하위요소로서 구현될 수 있다는 것을 이해할 것이다. 요소들(610 내지 660) 중 임의의 요소 내의 하위요소들은 제2 요소(620) 내에 도시된 바와 같이, 하위요소 박스들에 의해 나타날 수 있다. 그러나, 공간적인 한계와 도 6의 도면의 복잡도를 피하고자, 그러한 하위요소 박스들은 도시되지 않았지만 그곳에 존재하고 있는 것으로 이해되어야 한다.
당업자들은 제3, 제4, 제5 및 제6 요소들이 원한다면 하나의 조합형 요소로 통합될 수 있다는 것을 이해할 것이다. 또한, 만약 원한다면, 제3 및 제4 요소들이 하나의 조합형 요소로 통합될 수 있으며, 제5 및 제6 요소들이 또 하나의 조합형 요소로 통합될 수 있다. 또한 만약 원한다면, 제1 및 제2 요소들(610 및 620)이 하나의 조합형 요소로 통합될 수 있다. 마지막으로, ISRM 시스템의 제1 내지 제6 요소들(610 내지 660)의 기능이, 각각의 특정하거나 고유한 에러 조건, 실패 반환 코드, 문제 또는 어드레스화된 다른 문제를 위한 하나의 조합형 요소로 통합될 수 있다. 이러한 접근을 사용하여, 예컨대, 특정한 에러 조건 또는 실패 반환 코드의 도착이 ISRCC 수퍼바이저(605)로 하여금 특정한 EC, 실패 RC 또는 문제를 처리하도록 기록된 통합 조합형 요소를 야기하거나 호출하고 활성화하도록 할 것이다. 이러한 접근의 일 장점은, 어떤 주어진 보고된 에러 조건 또는 다른 문제의 도착이, 처음 도착할 에러 조건 또는 문제와 실질적으로 동일한 시간에 주소화될 필요가 있는 다른 보고된 에러 조건들, 문제들 또는 다른 문제들의 도착, 처리 및 디포지션(deposition)에 간섭하지 않는다.
도 7은 또 다른 ISRM 하위시스템(122')를 나타내고 있는데, 도 7에 도시된 것을 제외하고는 도 6의 ISRM 하위시스템(122)와 같다. 도 7의 실시예는 도 6에 도시된 구성 요소들(610 내지 660) 각각의 복수의 인스턴스들이 존재하거나, 제공될 수 있는 ISRM 하위시스템을 구현하고 설명하도록 구성되어 있다. 이러한 구성은 바람직하게는 각 요소의 인스턴스가 새롭게 도착한 특정한 보고 에러 조건에 전용되도록 사용된다. 도 7의 실시예에 있어서, 제1 요소(610)의 모든 인스턴스들은 브라킷(bracket, 610')에 의해 지정되는 것 반면에, 제1 요소의 개별적인 인스턴스들은(N이 존재하는) 블록(711), 블록(712) 및 블록들(713 내지 719)로서 지정된다. 조건 N은 임의의 필요한 수를 의미한다. N은 대형의 복잡한 IC 제조 설비 또는 자동화된 생산 설비 내의 몇몇의 또는 수백의 또는 수천 또는 그 이상까지 될 수 있다. 객체 지향 컴퓨터 시스템들에서와 같이, 주어진 요소, 통상 구동이 필요한 많은 인스턴스들이(컴퓨터 시스템들 제한 때문에 구동할 수 있는) 한번에 활성화될 것이다. 환언하면, 구동되는 임의의 주어진 요소의 실제적인 인스턴스들의 수는 ISRM 하위시스템(122')이 임의의 주어진 시간 지점에서 얼마나 비지(busy)한지에 달렸다.
제2 요소들(721 내지 729)의 세트(620')가 커맨드 메모의 활성 인스턴스들의 대응되는 수와 관련되어 도시되어 있으며, 각각 Mem EC-1 내지 Mem EC-N로 표시되어 있고, 브라킷(128')에 의해 선택적으로 식별된다. 유사하게는, 시퀀서(685)가 개별적으로 Seq EC-1 내지 Seq EC-N으로 표시된 복수의 인스턴스들과 함께 도시되어 있는데, 이들은 선택적으로 브라킷(685')에 의해 식별된다. 도 7의 라인들(631 및 682) 뒤의 점선으로된 라인들의 세트들은 제2 요소들의 개별적인 인스턴스들은 커맨드 메모리(128') 및 시퀀서(685')의 각각의 개별적인 인스턴스들과 통신한다.
유사하게는, 제3 요소들(731 내지 739)의 세트(630'), 및 제5 요소들(751 내지 759)의 세트(650') 각각은 제3 요소들의 활성 인스턴스들의 대응되는 수를 포함하는데, 이 요소들은 또한 사용을 위해 개별적으로 표시되고, 보고되고 인식된 에러 조건들 EC-1 내지 EC-N과 관련된다. 도면의 복잡도를 줄이기 위해, 굵은 라인들(632 및 668) 뒤에 도시된 복사된 각각의 통신 경로들은 도 7로부터 생략되었다. 마지막으로, 제4 요소들(741 내지 749)의 세트(640') 및 제6 요소들(761 내지 769)의 세트(650') 각각 제4 및 제6 요소들의 활성화들의 상응하는 수를 포함하는데, 이 요소들은 또한 편의를 위해, 보고되고 인식된 에러 조건들 EC-1 내지 EC-N와 관련된 인스턴스들과 함께 개별적으로 표시된다.
6 부 - 추가적인 어플리케이션들
해결 또는 복구 프로그램, 프로세스들 또는 에이젼트들의 상이한 타입들 : 상이한 종류의 장비 또는 대형 제조 시스템 내의 상이한 종류들의 트랜잭션들은 에러, 문제 또는 다른 문제로부터의 해결 또는 복구에 영향을 주도록, 실행되는 상이한 단계들을 필요로 할 수 있다. 따라서, 복수의 종류의 해결 또는 복구 프로그램들, 프로세스들 또는 에이젼트들을 구비하고, 각각이 자동화된 형식으로 특정한 종류 또는 클래스의 장비(툴들 운반들 또는 적재 장치들과 같은)와 관련된 해결 또는 복구 동작들을 실행하도록 구성되는 것이 유용할 수 있는데, 이는 그들 각각이 해결 또는 복구에 영향을 주기 위하여, 동작들 또는 명령들의 메세징 또는 커스텀(custom) 시퀀스를 특별한 처리에 있어서 필요로 할 수 있기 때문이다. 2개 이상의 상이한 해결 또는 복구 프로그램들, 프로세스들 및/또는 에이젼트들의 사용이란, 본 발명의 범위 내에서 하나 이상의 보고된 조건들을 주소화하는 것이다.
동기화 및 비동화된 사용들 : 본 발명에서 사용되는 문제 해결(ISR) 시스템 및 방법 및 임의의 해결 또는 복구 요소들은 동기적으로 사용될 수 있다. "동기적인 사용"이란, ISR 시스템이 어떤 해결 또는 복구 절차를 실행하거나 또는 실행하도록 시도하고, 긍정적인 확답이 프로세스 내의 앞선 단계로부터 반환될 때까지, 해결 또는 복구 프로세스 내의 단계들의 시퀀스로 다음 단계를 실행하도록 하는 하나 이상의 보정 커맨드들을 전달하지 않을 것을 의미한다. 또한, 복수의 복구 단계들 또는 명령들은 동시 발생적으로 ISR 시스템에 의해 전달될 수 있거나, 동일한 또는 상이한 제어 시스템, 툴, 장비 또는, 명령들이 직접 또는 간접적으로 전달되는 운반 장치에 의한 이전의 복구 단계들의 완로 또는 응답을 대기함이 없이, 시간 간격(timed interval)으로 전달될 수 있다. 이러한 것들은 본 발명의 해결 또는 복구 에이젼트들 또는 구성요소들의 "비동기적인 사용"의 특징의 예이다.
보고 & 예외 활동(Reporting & Exceptions Activity) : 도 6 및 7에 있어서, 문제 해결 커맨드들의 결과(또는 그 부족)들을 로그하기 위한 구성요소들 및 메모리의 정렬이 개시되어 있다. 이것은 또한 문제 해결 관리(ISR) 시스템을 위한 본 발명의 범위 내에 포함되는데, 이 시스템은 하나 이상의 하위프로그램들, 함수들, 클래스들, 객체들, 에이전트 프로그램들, 구성요소들 또는 다른 기능을 포함하고, 이들은 데이터 게더링(data gathering) 및/또는 통계의 형태를 적합한 컨테이너 또는 형태로 저장하기 위해 제공하며, 이것은 보고된 사건들 또는 문제들 및, 그러한 에러들, 문제들 및 다른 문제들에 응답한 활동에 관한 정보를 수집하기 위한 것이고, 관련 데이터베이스에 한정되지 않는다. 그러한 하위프로그램들, 함수들, 클래스들, 객체들, 에이전트들 또는 구성요소들은 트랜잭션 관리자들, 장비 관리자들, RTD 시스템 및 다른 시스템 및/또는 그 동작들에 관한 모니터들로부터 데이터를 수집할 수 있다. 그러한 데이터는 달성된 해결 및/또는 복구 결과들, 수행된 해결 또는 복구 동작들의 볼륨(volume) 및 타입, 보고된 문제를 수정하는데 사용되는 네스팅(nesting) 레벨들, 식별되고 착수되는 해결 및 복구 시도들의 수 등을 포함할 수 있다. 차례로 그러한 데이터를 보고하는 것은 의심할 나위 없이 다른 시스템들이 유용한 보고들을 참석 근무자들에 제공하는데 도움을 준다. 질문에 응답하여 제공될 수 있는 그러한 보고들은 또한 무엇이 발생했는지 결정하고, 장비 또는 어떤 알려진 문제들에 특별한 주의를 주는 순서를 결정하기 위해 근무자들에 의해 사용될 수 있다. 그들은 또한 보정 또는 예방적인 동작이 ISR 시스템이 응답하는 문제들에 관한 그 종료 시에 취해질 필요가 있는지 여부를 결정하도록 도움을 주는데 사용될 수 있다.
소프트웨어 코딩 구현들 : 객체-지향 프로그래밍(object-oriented programming, OOP) 기술을 사용하는 프로그램들로 주로 구성되는 런-타임 환경에서, ISRM 시스템이 하나의 구성요소로서 구현될 수 있고, 그 관련 에이전트 프로그램들, 예컨대, 데이터를 수집하거나 보고된 에러, 문제들 또는 다른 문제들의 사건 데이터베이스를 유지하는 프로그램들이 또한 하나의 구성요소로서 구현될 수 있다는 것을 이해해야 한다. 더 나아가, 그러한 에이전트들이 실행되는 경우, 효력 내의 에이전트들은 그러한 환경에서 객체들이 된다. 도 7과 연결지어 검토한 바와 같이, 만약 원한다면, 그러한 요소 또는 에이전트의 하나 이상의 인스턴스가 제공될 수 있다는 것을 이해해야 한다. 예컨대, 만약 상이한 시스템들, 어플리케이션들, 장비 또는 상이한 툴들이 시도된 해결 또는 복구를 구현하는 상이한 단계들을 요구하는 특정한 속성(attribute)들 또는 함수들을 구비한다면, 요청된 문제 해결 및/또는 복구 작업들을 처리하도록 특별하게 기록된 상이한 구성요소들 또는 해결 에이전트들을 제공하는 것이 유용할 수 있는데, 이 작업들은 특정한 시스템, 어플리케이션, 장비, 툴 또는 운반 장치, 또는 장비 또는 툴들 또는 운반 장치와 같은 특정한 클래스와 관련되는 것이다.
본 발명은 어떠한 예시적인 운영 시스템들 및/또는 컴퓨터 하드웨어 플랫폼들 상에서 구동되는, IBM의 표준 SiView MES, 브룩스 자동화 RTD 및 무라텍 MCS에 기반한 구현들에 관하여 기술되고 있다. 그러나, 당업자는 본 발명의 시스템들 및 방법들이 임의의 다른 알려진 또는 적당한 MES, RTD/디스패처 및/또는 MCS, 및 컴퓨터 운영 시스템들 및 하드웨어 플랫폼들에 관련한 다른 선택들을 가지고 사용될 수 있다. 필요한 모든 것은, 본 발명의 ISR 시스템들 및 방법들은 다양한 소프트웨어 기반 제어 시스템들(특히, MES, MCS/AMHS 및 PCS)과 함께 통합되도록 구성되어, 상기의 시도된 문제 해결 및 복구 함수들을 실행하는데 필요한 경우 커맨드 및 데이트를 생성하고, 수신하고, 허가하기 위해, 통합된 형식으로 필요한 경우 함께 구동할 수 있다.
당업자는 본 발명의 설명에 기반하여, 이미 동일한 것을 구현하는 방법을 이해하고 있으므로 본 발명의 시스템들 및 방법들은 더 이상 설명될 필요가 없다. 이 부분은 종래의 자동화된 제조 환경에 있어서 MES, RTD, PCS 및 MCS/AMHS, 및 그 유사한 소프트웨어 시스템 및 다른 관리 및 진단/에러 기록 소프트웨어 시스템들의 광범위한 사용을 위한 것이다. 또한 IC 제조 설비들 및 다른 대형 컴퓨터화된 제조 시스템들 및 설비들에서 데이터 및 제어 정보를 교환하는 다양한 통신 프로토콜 및 메세징 시스템들의 광범위한 이해 및 사용은 그 통신 프로세스들을 더 자세히 설명할 필요가 없게 만든다. 게다가, 산업 제어 시스템 소프트웨어 프로그램들, 공장 데이터 획득 프로그램들 및/또는 관리 및/또는 자동화 시스템 프로그램들 및/또는 구성요소들을 기록하는데 익숙한, 임의의 적당한 프로그래밍 접근 및/또는 다른 잘 알려진 통신들 및 데이터베이스 프로토콜들 및 소프트웨어 툴들이, 본 발명의 ISR 시스템 및 방법들을 구현하는데 사용될 수 있다. 이러한 프로그래밍 접근들은 관련 데이터베이스들 및 객체-지향 프로그래밍 요소들, 및 분배된 클라이언트/서버 계산 및 통신 기술을 사용하는 단계를 포함한다. 예컨대, 서번트(servant) 프로그램들이 어플리케이션 서버들 상에 제공되어, 적은 클라이언트들이, 제어되는 장비 및 툴들과 관련된 로컬 컴퓨팅 시스템 또는, 마이크로제어기들 상에서 사용될 수 있다. 이것은 본 발명의 ISR 시스템들 및 방법들을 구현하는데 필요한 소프트웨어이고, 효과적으로 코딩하는데 도움을 주는 방법이다. 두번째 예로서, 본 발명의 시스템들 및 방법들은 객체-지향 언어에 제한되지 않지만, 임의의 적당한 프로그래밍 언어들 또는 언어들의 세트로 된 프로그램들 또는 상관된(interrelated) 루틴들의 세트로서 기록될 수 있다. 더 나아가, 그러한 클라이언트 및 서버 프로그램들 및/또는 루틴들은 그 뒤, 운영 시스템, MES, RTD, MCS/AMHS 또는 자동화된 스케줄러/디스패처(이에 한정되지는 않음)를 포함하는 임의의 적당한 관리 소프트웨어 패키지의 제어 하에서 구동되도록 개발될 수 있다.
본 발명이, 본 발명의 블록도, 흐름도 및 요소들 또는 시스템들 및 단계들의 요소들을 참조함으로써 기술되어 왔다. 주지하는 바와 같이, 소프트웨어적으로 제공되는 적당한 프로그램 명령들이 본 발명의 교시(teaching)를 실행할 수 있는 시스템들을 형성하도록, 일반-목적의 컴퓨터들 및/또는 프로세서들을 프로그램된 컴퓨터들 및/또는 프로세서들로 전환하는데 사용된다.
펌웨어 & 다른 구현들 : 당업자들은, 만약 원한다면, 여기에 기술된 시스템들, 방법들 및 소프트웨어가 부분적으로 펌웨어(마이크로코드를 포함함) 또는 하드웨어로 구현될 수 있다는 것을 이해해야 한다. 따라서, 본 발명은 소프트웨어 및/또는 펌웨어, 또는 소프트웨어를 포함하는 실시예, 또는 하드웨어 및/또는 펌웨어의 조합의 실시예를 포함하는 실시예의 형태를 취할 수 있다. 더 나아가, 본 발명의 방법은 전적으로, 소프트웨어 상에서, 또는 소프트웨어, 하드웨어 및/또는 펌웨어 상에서 실행될 수 있다.
구현으로써의 실체적인 매체 : 또한, 본 발명의 구현을 위해 사용되는 소프트웨어 또는 다른 코딩이 플로피 디스켓, CD-ROM들, 하드 드라이브들, 스태틱(static) 또는 플래쉬 메모리, 게이트 어레이들, 또는 임의의 다른 컴퓨터 판독 저장 매체와 같은(반드시 이에 국한되는 것음 아님), 실체적인 매체에 구현된 컴퓨터 프로그램 코드의 적당한 형태로서 제공될 있다. 필요한 명령들을 포함하는, 그러한 컴퓨터 프로그램 코드 또는 다른 코드가 로드되어, 적당한 컴퓨터들/프로세서들에 의한 실행을 준비하는 경우에, 그러한 프로그램된 컴퓨터들/프로세서들이 본 발명을 실시하기 위한 장치가 될 것이다. 그러므로, 본 발명의 또 다른 실시예가 실체적인 매체 상에서 실시되는 경우, 그 실시예는 본 발명의 프로세스를 실행하기 위해 필요한 컴퓨터 프로그램 코드가 된다.
IC 제조 설비를 넘어서는 어플리케이션 : 지금까지의 기술은 자동화된 IC 제조 설비들에 초점을 맞추어 왔지만, 당업자들은 본 발명의 시스템들 및 방법들은, 더 넓은 관점에서, MES들 및/또는 자동화된 물류 처리 시스템들과 같은, 하나 이상의 관리 프로그램들(이 프로그램들은 이산적인 물리적 아이템들의 임의의 종류를 처리하는 것임)에 의해 통합되는 확장형 자동화를 사용하는 다른 자동화된 플랜트들에 적용될 수 있다. 그러한 플랜트들은 복수의 머신 센터들, 어셈블리 플랜트들, 자동화된 검사 설비들, 및 자동화된 파일링(filing), 패키징, 소팅(sorting) 및/또는 쉬핑(shipping) 플랜트들를 가진 공장들(이에 국한되지는 않지만)을 포함할 수 있다. 그러므로, 여기와 아래의 청구범위에 사용되는 바와 같이, 다음의 용어들이 다음의 의미들을 갖는다는 것을 이해해야 한다. 용어 "자동화된 공장" 및 "자동화된 제조 설비"는 테스팅 설비, 창고(warehouse) 및 배송 센터(distribution center)를 포함하는 임의의 공장을 포함하는 광범위한 개념으로 이해되어야 하고, 여기서 자동화된 장비(인간의 개입이 거의 없거나, 전혀 없는 자동화 제어 시스템들에 의한)는, 물리적인 아이템들 또는 물류와 같은 반복적인 기반에서, 전체적으로 또는 부분적으로, 수신하고(receive), 만들고(make), 조립하고(assemble), 처리하고(process), 정제하고(refine), 발송하고(route), 소트하고(sort), 테스트(test)하고 패키지(package)하는데 사용된다. 용어 "물리적 아이템들 또는 물류"는, 물리적으로 명시적이고, 그 궁극적인 목적으로의 여정의 부분으로서, 인간들 또는 자동화된 머신들에 의해 만들어지고, 조립되고, 처리되고, 취급되거나, 조종되는 이산적인 아이템들 또는 물류의 임의의 클래스 또는 클래스들을 포함하는 광범위한 개념으로 이해되어야 한다. 본 발명의 시스템들 및 방법들과 연결되어 사용되는 용어 "구성 요소(또는 요소)"는 반드시 이에 제한되지는 않지만, 모듈들, 루틴들, 하위루틴들, 클래스들, 객체들, 클라이언트/서버 프로그램들의 전부 또는 부분들, 및 에이전트 및/또는 프록시/스터브 소프트웨어를 포함한다. 임의의 요소의 전부 또는 일부들이, 프로그램된 게이트 어레이들(FPGA들) 또는 다른 하드웨어 및/또는 펌웨어의 형태(반드시 이것들에 제한되지는 않지만)를 포함하는, 어플리케이션 특정 통합 회로들(ASIC들)로서 전부 또는 일부로 구현될 수 있기 때문에, 용어 "구성 요소(요소)"는 광범위한 개념으로서, 그들을 또한 포함하는 것으로 이해되어야 한다.
그 이상의 개조/추가 : 앞선 상세한 설명은 본 발명의 예시적인 실시예는 상기 언급된 목적을 달성하는데 적합하다. 당업자는 본 발명의 기술적 사상 및 적합한 범위로부터 벗어나지 않고, 본 발명을 설명하기 위해 선택된 실시예들에 다양한 변경들 또는 추가들을 할 수 있다는 것을 이해해야 한다. 따라서, 본 발명의 보호범위는 첨부된 청구항들 및 그 청구항들의 모든 적당한 균등물들에 의해 정의되는 발명들의 확장으로 간주되어야 한다.