KR100326745B1

KR100326745B1 - 통합오토메이션개발시스템및그통합방법

Info

Publication number: KR100326745B1
Application number: KR1019940009246A
Authority: KR
Inventors: 스티븐에프.무어; 토마스이.버드
Original assignee: 윌리엄 비. 켐플러; 텍사스 인스트루먼츠 인코포레이티드
Priority date: 1993-04-30
Filing date: 1994-04-29
Publication date: 2002-06-20
Also published as: KR940024605A; US5528503A; MY134707A; EP0622714A1; JPH07146844A; EP0622714B1; DE69429740T2; TW265499B; DE69429740D1

Abstract

제조 장치(24)를 제어하고 코디네이트하기 위한 통합 오토메이션 개발 시스템(10)은 복수의 서버 프로세스(14, 16, 22, 28, 34, 36)를 사용한다. 각 서버 프로세스는 ASCII 메시지를 수신하는 메시징 관리기(45), 수신된 ASCII 메시지를 평가하고 메시지내의 커맨드를 식별하는 인터프리터(43)를 구비한다. 서버 프로세스는, 커맨드를 수신하여 실행하는 커맨드 관리기(41)와, 이 커맨드 관리기(41)에 의한 커맨드 실행의 논리 흐름을 관리하는 논리 제어기(47)를 더 구비한다. 서버들은 큐 서버(34), 단말 서버(28) 및 다른 애플리케이션 전용 서버 프로세스 역할을 하게 하는 부가적인 커맨드(48)를 포함할 수 있다.

Description

통합 오토메이션 개발 시스템 및 그 통합 방법.

본 발명은 일반적으로 오토메이션 시스템 분야에 관한 것이다. 특히, 본 발명은 통합 오토메이션 개발 시스템(integrated automation development system) 및 방법에 관한 것이다.

오토메이션 태스크는 공통의 목표를 달성하기 위한 특성상 수많은 엔티티(entity)를 코디네이트하여 제어할 필요가 있다. 이와 같은 태스크는, 오토메이션 환경의 특성과 요구 조건들로 인해 복잡하다. 오토메이션 엔티티는 공장 설비, 근거리 통신망, 데이타 베이스 및 사용자 단말기와 같은 실체적인 것이거나, 혹은 데이타, 제어용 소프트웨어, 통신 메시지 및 프로토콜과 같은 추상적인 것일 수 있다.

오토메이션 통합에 있어서 제1 어려움은 통신이다. 통상적으로, 오토메이션 엔티티는 다른 오토메이션 엔티티와 직접 통신할 수 없으므로 엔티티간의 통신을 위한 인터페이스를 필요로 한다. 그러나, 엔티티(X와 Y)간의 통신 인터페이스(α), 엔티티(Y와 Z)간의 통신 인터페이스(β) 및 엔티티(Z와 X)간의 통신 인터페이스(γ)등을 공식화하는 것이 그 해결 방법이 아니라는 점은 명백하다. 이러한 시스템을 사용하면, 초기의 시스템 구성과 후속하는 재구성을 행하는데 있어서 곱절의 수고가 요구될 수도 있을 것이다.

또한 오토메이션 통합 태스크는 시스템의 빈번한 재구성 및 수정이 용이하여야만 한다. 종종 처리 라인이나 셀에 장치가 부가되거나 혹은 이들로부터 장치가 생략되어, 상기 오토메이션 처리 라인 혹은 셀이 빈번하게 재구성될 수도 있다. 따라서, 오토메이션 시스템은 이와 같은 변화를 용이하게 수용하여야 한다.

또한 오토메이션 시스템에 있어서 통상적으로, 많은 엔티티에 의해 수행되는태스크가 병렬로 수행된다는 것이다. 따라서, 오토메이션 시스템은 또한 이와 같은 요구 조건을 만족시키기 위해 병렬 처리를 수용하여야만 한다.

본 발명에 따르면, 종래 기술과 연관된 단점 및 문제점을 크게 없애거나 감소시키는 통합 오토메이션 시스템 및 방법이 제공된다.

본 발명의 한 특성에 따르면, 제조 장치를 제어하고 코디네이트하는 통합 오토메이션 개발 시스템은 복수의 서버 프로세스를 이용한다. 각각의 서버 프로세스는 ASCII 메시지를 수신하기 위한 메시징 관리기와 수신된 ASCII 메시지를 평가하고 메시지 내의 커맨드를 식별하기 위한 인터프리터를 포함한다. 상기 서버 프로세스는 커맨드를 수신하여 실행하기 위한 커맨드 관리기와 상기 커맨드 관리기에 의한 커맨드 실행의 논리 흐름을 관리하기 위한 논리 제어기를 더 구비한다. 서버들은 큐 서버, 단말 서버 및 다른 애플리케이션 전용 서버 프로세스의 역할을 하게 하는 애플리케이션 전용 부수적인 커맨드를 포함할 수 있다.

본 발명의 다른 특성에 따르면, 제조 장치를 제어하고 코디네이트하기 위한 오토메이션 개발 시스템의 통합 방법이 제공된다. 상기 방법은 다른 서버와 클라이언트 프로세스로부터 ASCII 메시지를 검사하여 수신하는 단계, 텍스트 베이스(text-based) 프로그래밍 언어로 표현된 적어도 한 개의 커맨드를 포함하는 수신된 ASCII 메시지를 평가하는 단계와 ASCII 메시지에서 커맨드를 식별하는 단계를 구비한다. 상기 커맨드는 실행되어 상기 서버 프로세스는 ASCII 메시지를 검사하는 단계로 복귀한다.

본 발명의 또 다른 특성에 따르면, 통합 오토메이션 개발 시스템은 커맨드를포함하는 메시지를 생성하기 위한 제어 클라이언트를 포함한다. 제조 장치에서 인터페이스 역할을 하는 장치 서버는 상기 제어 클라이언트 프로세스로부터 메시지를 수신하고, 메시지의 커맨드에 따라 지시된 대로 제조 장치를 제어하며, 그것에 응답하여 메시지를 발생한다. 상기 제어 클라이언트와 상기 장치 서버간의 메시지 루팅(routing)을 인에이블시키기 위한 큐 서버가 부가적으로 제공된다.

본 발명의 이해를 돕기 위해, 첨부하는 도면을 참조할 수 있다.

도면을 참조하면, 제1도는 본 발명에 따라 구성된 통합 오토메이션 개발 시스템(10) 및 방법의 실시예를 나타낸 도면이다. 도시된 바와 같이, 통합 오토메이션 개발 시스템(10)은 일반적으로 시스템 모듈을 규정하는 클라이언트-서버 모델과, 모듈간의 통신 방법에 기초하고 있다. 상기 시스템(10)은 클라이언트와 서버라는 일단의 협동하는 태스크로 구성되어 있다. 제1도에서, 그래픽 제어 클라이언트(14)는 SMS(반도체 제조 시스템) 서버(16), 장치 서버(22) 및 단말 서버(28)와 협동하여 동작한다. 또한, 부수적인 서버들인 큐(queue) 서버(34)와 시간 서버(36)는 시스템의 전체적인 기능에 필요한 태스크를 수행한다.

서버는 일반적으로 시스템의 실제 혹은 추상적인 오브젝트 또는 엔티티를 관리하고 제어한다. 서버는 커맨드의 요청에 응답함으로써 그 클라이언트에 높은 레벨의 메시징 인터페이스를 제공한다. 예를 들어, 장치 서버(22)는 공장의 장치(24)에 인터페이스를 제공하며, SMS 서버(16)는 공장의 호스트 시스템[반도체 제조 시스템(20)]에 인터페이스를 제공하며, 단말 서버(28)는 운영자 단말기(30)와 상기 단말기(30)에서 실행하는 애플리케이션 소프트웨어에 인터페이스를 제공한다.

다른 한편, 그래픽 제어 클라이언트(14)는 서버의 하부 오브젝트 혹은 엔티티의 기능을 액세스할 수 있도록 서버(16, 22 및 28)에 커맨드의 요청을 전달하는 시스템(10)내의 태스크이다. 따라서, 이들 서버를 통해 일단의 오브젝트를 코디네이트하고 제어함으로써 오토메이션이 달성된다. 상기 제어 오브젝트는 그 자체가 클라이언트 프로세스로서 구현되는 추상 엔티티이다.

일반적으로, 서버는 시스템 내에 높은 레벨의 오브젝트를 나타내는 다른 서버에 대한 사전 지식을 가지고 있지 않다. 예를 들어, 상기 장치 서버(22)는 공장 호스트 서버(16)에 커맨드를 전달해서는 안되는데, 그 이유는 이로 인해 특정 공장 호스트 서버(16) 및 그 커맨드 신택스에 대한 불필요한 의존성을 장치 서버(22)에 구축할 수도 있기 때문이다. 이와 같은 통합 행위는 그래픽 제어 클라이언트(14)와 같은 제어 클라이언트에 의해 처리되어야 한다.

제2도와 관련하여, 서버(16, 22, 28, 34 및 36) 및 클라이언트(14)는 서버(40)라고 하는 일반적인 구조로서 표현될 수 있다. 각 서버(40)는, 서버 쉘(42)이라고 하는 기존의 소프트웨어 모듈에, 애플리케이션 전용 코드와 커맨드 관리기(48)를 추가함으로써 생성된다. 이와 같은 서버 쉘(42)은 고유의 애플리케이션 서버 및 클라이언트를 생성하기 위해 기동시에 텍스트 화일로 구성된 실행가능한 화일이다. 상기 서버 쉘(42)은 인터프리트된 텍스트 베이스 프로그래밍 언어로 표현되거나 또는 런 타임시에 스크립터 쉘 언어라고 불리우는 커맨드를 적재함으로써 또는 컴파일시에 C++ 커맨드를 링크시킴으로써 애플리케이션 프로그램으로 바람직하게 구성된다. 상기 서버 쉘(42)은 베이스 코드(44)와 공통 커맨드(46)라고 하는 두 개의 기초 형성블럭(two basic building blocks)를 포함하는 것이 바람직하다. 그래서, 새로운 애플리케이션 서버가 필요할 때, 그 구현은 애플리케이션 전용 코드를 형성하는 서버 쉘(42)로 시작한다.

제3도와 관련하여, 상기 서버 프로세스(40)는 여러 가지 주요 기능의 구성 요소를 갖는 것으로 도시되어 있다. 서버(40)는 서버 쉘(42)과 부가된 애플리케이션 전용 커맨드 및 코드 관리기(48)를 구비한다. 상기 서버 쉘(42)은 기본적인 태스크를 수행하는 많은 기능 모듈들을 자체적으로 포함한다. 상기 서버 쉘(42)은 커맨드에 대해 프로세스 수준의 운영 체제 역할을 하는 커맨드 관리기 또는 공통 커맨드 모듈(41)을 포함한다. 상기 커맨드 관리기(41)는 커맨드 요청의 실행을 관리하고 제어하며, 데이타 저장 및 이벤트 로깅(event logging)에 대해 편리함을 제공한다. 상기 서버 쉘(42)은 장치 서버(22), 단말 서버(28) 및 큐 서버(34)와 같은 실제의 애플리케이션 서버 혹은 클라이언트를 형성하기 위한 토대일 뿐이다. 상기 서버 쉘(42)은 특정한 애플리케이션의 개발을 용이하게 하는 커맨드를 포함한다. 이와 같이 구성함으로써 오토메이션 개발 시스템(10)의 모듈화 및 재구성이 용이하게 된다.

또한 상기 서버 쉘(42)은 런 타임시에 스크립트 언어에 새로운 커맨드를 생성하는 스크립트 또는 쉘과 같은 언어 인터프리터(43)를 포함한다. 상기 스크립트 언어는 일반적으로 UNIX 운영 체제 환경에 친숙한 사용자가 이해할 수 있는 높은 수준의 범용 쉘-형 코드일 수 있다. 상기 스크립트 언어는 콘디셔널부, 루핑 구성부, 표현 평가부 및 환경 변수부를 포함할 수 있다. 예를 들어 C++ 언어보다는 상기 스크립트 언어를 사용함으로써 스크립트 언어가 라인-대-라인으로 해석되기 때문에 실행하기 이전에 코드를 다시 컴파일하여 다시 링크할 필요가 없게 된다. 해석하는 동안, 상기 스크립트 언어 인터프리터(43)는 엔티티를 스크립트 언어로 반드시 끌어들여 서버에 의해 이해될 수 있으며 액세스될 수 있는 동적 변수 구조로 번역한다.

상기 서버 쉘(42)은 메시징 관리기(45)를 더 구비한다. 상기 메시징 관리기(45)는 메시지 신택스 검증 및 루팅과 같이 메시지 통신과 관련된 작업을 수행한다. 또한 상기 서버 쉘(42)은 서버(40)의 기초 제어 및 논리 흐름을 관리하기 위한 쉘 논리 제어기(47)를 제공한다. 부수적인 동적 변수 제어기(49)는 제4도에 도시된 동적 변수 구조의 기억 및 액세스를 감독하는 역할을 한다. 메시징 관리기(45), 쉘 서버 논리 제어기(47) 및 동적 변수 관리기의 역할은 이하에 보다 상세히 논의된다.

부가된 애플리케이션 전용 커맨드(48)는 서버 또는 서버가 서비스를 제공하는 오브젝트의 상태에 작용을 미치거나 혹은 변화시킨다. 또한 동일한 쉘 실행부로부터 시작된 서버는 런 타임 텍스트 세그먼트 혹은 코드를 공유함으로써 런 타임 메모리 사용을 줄인다. 예를 들어, 구성 화일을 동일한 단말 서버 쉘 실행부로 적재함으로써 생성되는 여덟개의 운영자 인터페이스는 런타임시에 단지 한개의 복사분의 실제 단말 서버 쉘 코드만을 사용한다. 각 프로세스는 메모리에 개별적인 데이타 영역을 유지할 수 있으나, 메모리에 실행가능한 코드의 동일한 코드 블럭을 사용한다.

제4도와 관련하여, 예시적인 동적 변수 데이타 구조가 도시되어 있다. 서버(40)에서, 커맨드는 동적 기호로 된 텍스트 변이의 내부 계층 전체를 통해 데이타를 공유한다. 규칙에 따르면, 상기 서버(40)의 상태는 이와 같은 변수로 정의되어 있다. 그리하여 통합 오토메이션 개발 시스템(10)의 프로그래밍은 주로 동적 변수를 조작하고 메시지를 전달하는 것으로 구성되어 있다. 흔히 알고리즘의 복잡성은 그 하부 데이타의 구조에 달려있다. 상기 동적 변수(49)를 사용함으로써 개발하는 사람은 명확한 알고리즘을 갖는 데이타 표현도를 작성할 수 있다. 다음은 스크립트 언어로 표현된 동적 변수의 예이다.

상기 예는 제4도에 그래픽으로 도시되어 있다. 예를 들어, 동적 변수 구조(49)는 서버의 이름이 "EQUIPA"이며, 모니터되고 기록된 일부의 온도 또는 3개의 지점(LOCA,LOCB 및 LOCC)에서의 "TEMP" 측정값을 갖는 다는 것을 보여준다. 또한, 동적 변수(49)의 상태는, 상기 장치 서버가 그 "SYS>PROTOCOL" 동적 변수의 값으로서 SECS(SEMI 장치 통신 표준) 포맷의 메시지를 처리할 수 있다는 것을 알려준다. 그래서, 동적 변수(49)는 용이하게 액세스할 수 있는 각 서버 프로세서(40)에 대해 질서 정연하고 계층적인 데이타 또는 값의 구성을 제공한다는 것을 알 수 있다.

제5도와 관련하여, 클라이언트와 서버간의 통신 방법이 도시되어 있다. 클라이언트(52)는 자원(62)에게 특정한 작업을 수행할 것을 요구한다. 상기 클라이언트(52)는 응답 및 선택적인 데이타 메시지(58 또는 60)에 응신하는 서버(54)에 커맨드 요청 메시지(56)를 보냄으로써 이와 같은 요구를 통신하다. 모든 메시지는 판독할 수 있는 ASCII 스트링으로 구성되어 있다. 데이타 메시지(60)는 커맨드 또는 응답 중 어느 것도 아닌 메시지로 정의되어 있다. 상기 데이타 메시지는 커맨드 메시지(56)에 대한 응신(58)이 전달된 후 클라이언트(52)에 데이타를 전달하는 데 사용된다. 그리하여 상기 서버(54)는 자원 혹은 오브젝트(62)에 대한 인터페이스를 나타낸다. 이와 같은 커맨드 중심의 교환은 오토메이션 개발 시스템(10)의 모든 행위를 관할한다. 그래서, 인입 메시지의 결과로서 동작은 자원(62)에서 또는 자원에 의해 발생한다. 모든 인입 메시지는 우선 메시지 큐에 기억된다. 메시지는 FIFO(선입선출)에 따라 큐로부터 판독된다. 시스템(10)내에서 메시지 큐의 관리는 큐 서버(34)에 의해 수행되며, 그 세부 내용은 이하에 설명되어 있다.

제6도와 관련하여, 대체가능한 통신 방법(70)이 도시되어 있다. 클라이언트(72)는 커맨드(76)를 보냄으로써 서버(74)와 통신하며, 서버(74)는 응답 메시지(58) 혹은 데이타 메시지(60)(제5도)일 수 있는 응답(78)으로 응신한다. 상기 서버(74)는 요구된 태스크 클라이언트(72)를 수행하기 위한 자원(80)을 가질 수 있거나 또는 커맨드(86)를 수신하고 이에 따라 응답(88) 또는 자원(84)에 의해 수행된 적당한 행위로 응신하는 다른 서버(82)에 대한 클라이언트로서 역할을 할 수 있다. 부수적으로, 상기 서버(74)는 또한 서버에 의해 사용된 메시지 프로토콜을 사용하지 않는 엔티티 또는 서브시스템의 인터페이스를 가질 수 있다.

서버 쉘의 기본 기능을 설명하였지만, 서버 쉘에 따라 구성되는 임의의 서버를 논의하는 것이 바람직하다. 예를 들어, 상기 큐 서버(34)는 오토메이션 개발 시스템의 동작에 중요한 서버이다. 시스템(10) 내의 모든 클라이언트 및 서버 프로세스간의 통신에 투명성을 제공하기 위해, 상기 서버(34)는 이름붙여진 메시지 큐의 표를 관리하며, 통합 오토메이션 개발 시스템(10)내의 통신을 감독한다. 상기 큐 서버(34)는 보다 높은 수준의 통신을 수행하기 위해 프로세스를 인에이블시키는 저수준 메시지 인터페이스를 클라이언트와 서버 프로세스에 제공한다.

큐 서버의 주요한 기능은 시간 서버(36)와 SMS 서버(16)와 같은 ASCII 이름을 UNIX 혹은 유사한 운영 체제와 같은 운영 체제로서 지정된 큐 식별 번호 또는 키와 연관시키는 것이다. 이렇게 함으로써 시스템의 서버들은 큐 식별 번호 대신에 공지된 이름을 사용하여 상호 가리킬 수 있다. 단지 큐 서버(34)만이 큐 이름의 표와 그에 대응하는 운영 체제의 큐 식별 번호를 저장할 필요가 있다.

제7도와 관련하여, 메시징 프로토콜은 서버 A(90)와 서버 B(91)로 도시되어 있다. 상기 서버(A와 B) 모두는 화살표(92와 93)로 도시된 바와 같이 기동시에 큐 서버(34)를 체크인하거나 등록한다. 다음에 상기 큐 서버(34)는 프로세스 또는 서버 이름을 표에 기록하고, 필요하다면 큐 ID 또는 식별 번호를 각 서버(90과 91)에 지정한다. 또한, 상기 큐 서버(34)는 이미 존재하지 않는다면 각 서버 프로세스(90과 91)에 대한 큐(94와 95)를 생성한 후, 화살표(96과 97)로 도시한 바와 같이, 새로이 시작된 프로세스(90과 91)로 큐의 식별 번호를 반환한다. 이때 상기 새로운 프로세스 A(90)와 B(91)는 메시지를 수신하는 데 각각의 큐(94와 95)를 사용한다. 따라서, 큐 식별 번호의 사용은 시스템에 투명하다.

예를 들어, 서버 A(90)가 서버 B(91)로 메시지를 전달하기를 원할 때, 서버 A(90)는 화살표(98)로 도시한 바와 같이, 서버 B의 큐 이름을 제공함으로써 서버 B의 큐 ID를 큐 서버(34)에 요구한다. 다음에 상기 큐 서버(34)는 그 표에서 서버 B의 이름을 참조하여 화살표(99)로 도시한 바와 같이 서버 A(90)에 이에 대응하는 큐 ID를 반환한다. 다음에 서버 A(90)는 서버 B의 큐 ID를 사용하여 화살표(100)로 도시한 바와 같이 서버 B의 큐(95)에 메시지를 전달한다. 각각 서버 프로세스는 다른 프로세스로 메시지가 보내져야만 할 때마다 큐 서버(34)에게 요구할 필요가 없도록 바람직하게 다른 서버 프로세스의 이름 및 이에 대응하는 ID정보를 국소표에 유지한다.

서버가 종료할 때 프로세스가 큐 서버(34)에게 시스템(10)으로부터 그 큐를 삭제할 것을 요청하지 않는 한, 상기 큐 서버(34)는 다음에 사용하기 위해 그 표에 큐 이름과 ID를 유지할 것이다. 이것은 여전히 다른 프로세스가 그 큐에 메시지를 위치시키게 하면서 프로세스가 일시적으로 종료하는 것을 가능케 한다. 프로세스가 다시 시작되어 큐 서버와 함께 체크 인할 때, 프로세스에게는 기존의 큐 ID가 지정된다. 다음에 상기 프로세스는 다운되는 동안에 큐에 축적된 임의의 메시지를 판독하여 응답한다. 그래서, 종료할 때 오로지 수명이 짧은 클라이언트만이 그 큐를 제거하는 것이 바람직하다.

큐 서버(34)가 시스템(10)의 모든 서버와 클라이언트에 대한 큐 관리를 제공하기 때문에, 임의의 다른 프로세스가 시작되기 전에 백그라운드 프로세스로서 실행되어야만 한다. 상기 큐 서버(34)는 커맨드 라인상에 적당한 커맨드를 입력함으로써 수동으로 시작될 수 있지만, CPU가 시작되거나 재부팅될 때마다 큐 서버(34)가 오토메이션으로 시작되는 것이 바람직하다.

제2도 및 제7도 이외에 제8도와 관련하여, 커맨드 메시지 프로세싱에 대한 기초 흐름도가 도시되어 있다. 가상적으로 시스템(10)의 모든 동작이 메시지 중심이기 때문에, 예를 들어 서버 B(91)는 블럭(101)에 도시된 바와 같이 우선 그 큐(95)를 검사하여 메시지를 검출한다. 상기 메시지는 동작을 일으키기 위해 클라이언트 또는 다른 서버로부터 나온 커맨드를 포함한다. 서버 B(91)의 서버 쉘(42)은 블럭(103과 104)에 도시된 바와 같이, 상기 메시지를 필드로 디코드하여 파싱(parsing)하며, 커맨드 리스트(102)에서 메시지에 지정된 커맨드를 찾는다. 상기 커맨드 리스트(102)는 그 서버가 수행할 수 있는 모든 커맨드 혹은 동작을 표현한다.

더욱이, 상기 커맨드 리스트(102)는 그 파라메타를 포함하는 커맨드의 정확한 구문과 지정된 커맨드의 작업을 수행하는 코드 위치를 지정한다. 그래서, 상기 서버 쉘(42)은 필요하다면 블럭(105)에 도시된 바와 같이 메시지의 커맨드 구문을 검증한다. 상술한 바와 같이, 통합 오토메이션 시스템(10)에 사용된 메시지는 잘 정의된 유연성 포맷의 판독가능한 ASCII 스트링으로 구성되어 있다. 다음에 상기 서버 쉘(42)은 이름 또는 특수한 루팅 파라메타에 기초한 커맨드 코드로 메시지를 루팅한다. 상기 커맨드 코드는 블럭(106)에 도시된 바와같이 메시지를 입력으로 사용하여 실행된다. 코드가 실행된 후, 서버 쉘(42)은 블럭(107)에 도시한 바와 같이 필요하다면 응답 메시지를 발생한다. 상기 응답 메시지는 클라이언트에 의해 전달된 커맨드 메시지에 대한 응답으로서 서버에 의해 클라이언트로 반환된 메시지이다.

서버(54)와 클라이언트(52) 간의 메시지는 큐 이름에 따라 루팅된다. 상기 큐 서버(34)(제1도에서)는 큐 이름 연관성을 관리하며, 다른 모든 클라이언트(52)와 서버(54)에 의해 사용되어 상호 메시지를 전달한다. 서버(54)내에서, 메시지는 커맨드 이름 또는 메시지 구문에 의해 루팅된다. 서버(54)가 커맨드 메시지를 수신할 때, 취해진 행위는 주어진 커맨드 이름에 근거한다.

메시지 콘텍스트 혹은 "ctxt="는 클라이언트(52)로부터 커맨드 메시지에 놓인 고유의 명칭이다. 상기 메시지 콘텍스트 식별자는 서버(54)에 의해 보존되어, 결과로 나타나는 임의의 응답 혹은 데이타 메시지로 반환되어야 한다. 응답 및 데이타 메시지의 메시지 콘텍스트는 만약 한 개 이상의 서버(54)로 몇 개의 유사한 커맨드가 전달되었더라도 클라이언트(52)로 하여금 들어오는 결과를 식별하게 한다.

상술된 바와 같이, 오토메이션 개발 시스템(10)의 모든 메시지는 바람직하게 ASCII 텍스트 스트링이다. 상기 텍스트 스트링은 스트링 포맷으로 표현될 수 있는 임의의 데이타를 포함할 수 있다. 메시지의 각 데이타 항목은 SPACES, LINEFEEDS, CARRIAGE RETURNS 및 TABS을 포함하는 공백으로 구분되어 있다. 상기 데이타 항목은 파라메타 또는 필드로 태그된 것과 태그되지 않은 것의 두 가지로 구분되는 데, 태그된 파라메타는 등호 또는 =로 구분된 태그와 데이타 혹은 값으로 구성되어 있으며, 태그되지 않은 파라메타는 등호를 포함하지 않은 데이타 항목이다.

모든 오토메이션 개발 시스템(10)의 메시지는 "fr"로 태그된 파라메타로 시작하여야 한다. 다른 말로, "fr="은 임의의 메시지의 첫번째 세 문자이어야 한다.이것은 고정된 위치를 가져야만 하는 메시지의 유일한 데이타이다. 상기 "fr" 태그는 메시지의 송신자를 식별하며, 또한 다른 메시지 포맷을 이해하여야 하는 서버 내의 오토메이션 개발 시스템 메시지로 메시지를 식별한다.

모든 메시지 루팅 정보는 메시지의 텍스트 안에 포함되어 있다. 상기 "fr="과 "to="로 태그된 파라메타는 서버(54)와 클라이언트(52)간의 통신에 대한 루팅 정보를 명시하며, "do="와 "ctxt="로 태그된 파라메타는 서버내의 특정한 코드 블럭으로 메시지를 루팅한다. 요약하면, 예약된 태그 이름과 그 기능은 아래와 같다.

제9도와 관련하여, 커맨드 메시지 프로세싱의 서버 논리를 나타내는 개략화된 순서도가 도시되어 있다. 서버(54)는 임의의 클라이언트 태스크(52)에서 들어오는 커맨드 메시지에 응답하여야 한다. 상기 서버(54)는 클라이언트(52)가 커맨드를보낸다는 것에 대해 이전에 알지 못한다. 들어오는 커맨드 메시지는 "fr=" 태그로서 명시된 송신하는 클라이언트 태스크의 이름을 포함한다. 그래서, 서버는 런타임 이전에 알려지지 않은 이름붙여진 태스크에 응답할 수 있어야만 한다. 이것은 이름 붙여진 큐를 관리하는 큐 서버(34)(제1도)와 통신함으로써 수행된다. 서버(54)와 클라이언트(52)는 시스템(10)이 알 수 있도록 기동시 큐 서버와 함께 그 이름을 등록하여야 한다. 이것은 블럭(122)에 체크인으로 도시되어 있다. 만약 상기 체크인이 성공적이지 못하였다면, 서버는 블럭(126)으로 빠져나가 메시지를 수신할 수 없게 된다. 만약 상기 체크인이 성공적이었다면, 임의의 클라이언트로부터 들어오는 커맨드 메시지를 대기하는 블럭(128)으로 실행이 계속된다.

블럭(130)에 도시된 바와 같이, 서버(54)가 응답 메시지 또는 데이타 메시지를 클라이언트(52)로 반환함으로써 커맨드 메시지에 응답할 때, 상기 서버는 만약 클라이언트로부터 커맨드 메시지에 콘텍스트가 주어졌다면 메시지 콘텍스트를 보존하여야 한다. 다음에 상기 서버(54)는 블럭(132)에 도시된 바와 같이 그 커맨드 리스트를 참조하여 커맨드를 실행할 것인지를 판단한다. 만약 상기 커맨드를 커맨드 리스트에서 찾을 수 없다면, 이때 블럭(138)에 도시한 바와 같이 에러 응답 메시지가 생성된다. 또한 블럭(134과 136)에 도시된 바와 같이 커맨드가 실행되어 응답이 생성된다. 다음에 블럭(130)에 보존되어 있던 상기 커맨드 콘텍스트는 생성된 응답 메시지에 포함되어 있으며, 블럭(140과 142)에 도시된 바와 같이 메시지가 전달된다. 또한 응답 메시지가 필요하지 않는 경우도 있다. 예를 들어, 만약 서버(54)가 태그되지 않은 파라메타 "noreply"를 포함하는 커맨드 메시지를 수신한다면, 상기서버는 커맨드를 정상적으로 처리하여야 하지만, 상기 커맨드 메시지에 대한 응답 메시지를 발생하여서는 안된다. 상기 서버(54)는 블럭(144과 146)에 도시한 바와 같이 빠져나갈 때까지 커맨드 메시지를 대기하며, 커맨드를 실행하여 응답 메시지를 반환하는 루프에서 대기한다.

제7도는 서버 논리 제어 흐름도의 세부 표현도이다. 모든 서버(54)는 처음에 시작되면[블럭(160)] 임의의 동작을 수행한다. 이와 같은 동작으로 일부 서로 다르지만 유사한 애플리케이션을 위해 실행가능한 화일이 사용될 수 있게 함으로써 서로 다른 버젼의 서버를 다시 컴파일하는데 있어서 중복하는 코드의 양과 소비 시간을 줄일 수 있다. 블럭(162)에 도시된 바와 같이, 사용자가 지정한 커맨드를 포함하여 모든 서버의 공통 커맨드(46)(제2도)는 기동시에 생성된다. 이와 같은 커맨드는 기동 직후 생성되기 때문에, 서버 쉘 커맨드 라인으로부터 또는 기동 화일의 임의의 지점에서 호출될 수 있다. 또한 이것으로 커맨드 리스트가 생성되었다.

블럭(164)에 도시한 바와 같이, 서버 쉘은 서버가 잘 빠져나갈 수 있도록 서버 쉘에 의해 인터셉트되는 사전 지정된 신호용 소프트웨어 트랩(software traps for pre-specified signals)을 설정한다. 단계적인 출구는 서버 개발자 혹은 서버 쉘에 의해 정의된 임의의 출구 코드를 서버가 실행하는 출구이다. 더욱이, 서버는 클라이언트로부터 출구 커맨드를 수신할 때 단계적으로 출구를 수행한다.

블럭(166)에서, 쉘 동적 변수가 생성된다. 서버 쉘(42)에 따라 형성된 각 서버(54)는 선정된 몇몇의 동적 변수를 포함한다. 상기 동적 변수는 서버의 커맨드 라인 인수가 처리되기 전에 초기화되며, 그래서 그 값은 필요하다면 커맨드-라인-커맨드에 의해 또는 기동 파일에 의해 무시될 수 있다. 바람직하게, 초기화되는 상기 동적 변수들은 프로세스의 커맨드 라인 이름으로부터 파생된 서버의 이름 즉, 프로세스가 시작되는 디렉토리의 경로를 포함하는 현재의 작업 디렉토리; 서버 쉘에게 화일내 임의의 기동 커맨드를 실행하도록 알리기 위해 커맨드 라인에 설정될 수 있는 시작 화일명 변수; 및 상기 서버가 형성되는 서버 쉘의 버젼을 반영하기 위한 서버 쉘 버젼 번호이다.

통합 오토메이션 개발 시스템 서버는 또한 몇 가지 디폴트 로그(도시되어 있지 않음)를 포함한다. 상기 로그의 이름 및 속성은 블럭(168)에 도시된 바와 같이 지정된다. 바람직하게, 화일명과 디폴트 속성은 커맨드-라인-커맨드로 또는 기동 커맨드로서 재설정될 수 있다. 다음에 블럭(170)에서, 서버 프로세스가 시작되어 커맨드가 실행될 때 운영 체제 커맨드 라인상에 한 개 이상의 커맨드가 입력될 수 있다. 만약 커맨드-라인-커맨드에 어떤 에러가 존재한다면, 블럭(172와 174)에 도시한 바와 같이 서버가 빠져나간다.

블럭(176)에서, 서버 쉘은 메시징을 인에이블시키기 위해 큐 서버와 함께 체크인한다. 체크인 프로세스는 제7도에 도시되어 있다. 서버 이름에 의해 메시지가 관리되고 루팅되기 때문에, 각 서버는 시스템(10)에 대해 유일하여야 한다. 만약 큐 서버가 실행하지 않거나 또는 어떤 이유로 인해 체크인이 실패한다면, 블럭(178과 180)에 도시된 바와 같이 에러 메시지가 프린트되어 디스플레이되고 서버는 종료할 것이다.

블럭(182)에 도시된 바와 같이, 만약 srv_init라고 이름붙여진 커맨드가 존재한다면, 이 때 호출된다. 상기 srv_init 커맨드는 위치에 특정하며 서버에 특정한 초기화 후크(hook) 커맨드이다. 일반적으로, 오토메이션 개발 시스템 서버(54)는 클라이언트에 의해 호출될 수 있는 사용자가 지정한 커맨드를 서버 쉘(42)에 부가함으로써 생성될 수 있다. 사용자에 의해 지정된 커맨드는 들어오는 커맨드 메시지의 결과에 따라 처리되며 서버 쉘 제어 논리에 영향을 미치지 않는다. 그러나, 특정한 유형의 커맨드는 서버 개발자가 제어 순서도의 선정된 장소에 서버 쉘 제어 논리에 코드를 부가하기 위한 방편으로 제공될 수 있다. 디폴트로, 이와 같은 커맨드는 아무런 동작도 수행하지 않으며, 서버 실행에 아무런 영향도 미치지 않는다. 이와 같이 장소에 특정한 커맨드 또는 후크 커맨드는 제7도 내지 제10도에 점선 또는 사선으로 도시되어 있다.

만약 기동 화일명을 포함하는 동적 변수가 커맨드 라인상에 또는 srv_init 커맨드에 의해 설정되어 있다면, 블럭(184)에 도시된 바와 같이, 서버 쉘은 동적 변수에 의해 붙여진 기동 화일의 현재 작업 디렉토리를 참조한다. 다음에 블럭(186과 188)에 도시된 바와 같이, 아무것도 남아있지 않을 때까지 커맨드가 화일로부터 판독되어 실행된다.

서버내의 모든 화일 액세스는 서버의 현재 작업 디렉토리와 관련하여 수행된다. 현재의 작업 디렉토리는 서버가 시작되었던 디렉토리로 디폴트한다. 그러나, 현재의 작업 디렉토리는 CWD 동적 변수를 커맨드-라인-커맨드, srv_init 커맨드 또는 기동 화일의 커맨드로 설정함으로써 다른 디렉토리로 설정될 수 있다. 기동 화일을 적재한 후, 필요하다면 상기 서버 쉘은 블럭(190)에 도시된 바와 같이 CWD 동적 변수에 의해 지정된 디렉토리를 일치시키기 위해 실제의 작업 디렉토리를 바꾼다. 만약 상기 서버 쉘이 지정된 디렉토리로 바꿀 수 없다면, 블럭(192와 194)에 도시된 바와 같이, 서버는 종료하여 에러 메시지를 로그한다.

일단 서버가 그 초기화 프로세스를 완료하면, 블럭(196)에 도시한 바와 같이, 서버는 큐로부터 메시지를 판독하여 처리한 다음, 다른 메시지를 판독하기 위해 반환하는 루프로 들어간다. 제8도 내지 제10도는 메시지 처리 루프의 제어 논리를 도시한다.

제11도에서, 블럭(200)은 제7도에 도시된 초기화 프로세스를 나타낸다. 만약 서버 쉘이 메시지를 대기하는 동안 커맨드에 의해 발생된 경고 신호가 수신된다면, 블럭(202과 204)에 도시된 바와 같이 후크 커맨드(srv_alarm)가 호출된다. 다음에 서버 쉘은 블럭(206)에 도시된 바와 같이 큐를 체크함으로써 메시지를 계속 대기한다. 이 때, 만약 경고 신호가 수신된다면, srv_alarm 후크 커맨드가 호출되는 블럭(204)으로 복귀한다. 그렇지 않고, 만약 블럭(210)에 도시된 바와 같이 큐에 아무런 메시지도 존재하지 않는다면, 블럭(212)에 도시된 바와같이 srv_rcverr 후크 커맨드가 호출된다. 디폴트로, 상기 서버 쉘은 큐에 도달하기 위해 메시지를 무한정 대기한다. 메시지가 도달하면, 개발은 계속되며 가능하다면 메시지가 처리된다.

그러나, 만약 서버가 메시지를 영원히 기다려서는 안된다는 것을 명시하는 동적 변수가 정의되어 있다면, 서버는 메시지 큐를 한번 더 검사하고, 만약 메시지가 대기하고 있었다면 수신된 메시지를 처리한다. 만약 그렇지 않다면, 상기 서버쉘은 srv_rcverr 후크 커맨드를 호출하려 시도한다. 이와 같은 프로시져는 서버로 하여금 단말 서버(28)(제1도)와 같은 메시지 큐 이외의 장치를 차단하는 데 사용된다. 만약 상기 동적 변수가 정의되어 있지 않으며 큐로부터 메시지를 판독하려 시도하는 동안 에러가 발생한다면, 상기 서버 쉘은 srv_rcverr를 호출하며, 만약 존재한다면 에러 로그로 메시지를 로그하며, 만약 빠져나갔다면 다른 메시지를 대기하기 위해 복귀한다. 바람직하게, 만약 특정한 수의 에러가 발생한다면 서버 쉘이 에러 로그에 메시지를 기록하여 종료하도록 대비될 수 있다.

다음에, 만약 블럭(210)에 도시된 바와 같이 메시지가 수신된다면, 상기 메시지는 그 메시지가 정확한 오토메이션 개발 시스템 포맷인 지를 판단하도록 검사된다. 정확한 메시지 포맷은 바람직하게 태그"fr"로 시작하는 메시지로 정의되어 있다. 블럭(214)에서 만약 인입 메시지가 비-오토메이션 개발 시스템 메시지로 결정되어 있다면, 그것은 제12도에서 계속되며, 이하에 설명되는 블럭(216)에서 비-표준 포맷 메시지로 취급되어 처리된다. 만약 메시지가 정확한 포맷이라면, 서버 쉘은 블럭(218)에 도시된 바와 같이 메시지에서 "to" 태그를 찾는다. 만약 메시지에 "to" 태그가 존재하지만 "to" 파라메타의 값이 수신 서버의 이름과 일치하지 않는다면, 이때 상기 서버 쉘은 블럭(220과 222)에 도시된 바와 같이 정의된 경우에 후크 커맨드 srv_baddr을 호출한다. 만약 "to" 태그값이 서버 이름과 동일하거나 또는 정의된 srv_baddr 후크가 존재하지 않는다면, 이때 메시지는 정상적으로 처리된다. 상기 srv_baddr 후크 커맨드는 다른 CPU의 서버로 루팅하기 위해 큐 서버(34)(제1도)에 의해 사용된다.

메시지를 처리하기 위해, 메시지는 블럭(224)에 도시된 바와 같이 태그되고 태그되지 않은 파라메타로 파싱된다. 파싱은 C++ 언어로 작성된 커맨드와 스크립트 언어가 메시지 파라메타를 액세스할 수 있게 된다. 만약 인용 부호가 일치하지 않아 메시지를 파싱하는 동안 에러가 발생한다면, 블럭(226과 228)에 도시한 바와 같이 에러를 가리키는 응답 메시지가 클라이언트로 반환된다. 이때 만약 정의되어 있다면, 블럭(230)에 도시한 바와 같이 서버 쉘은 후크 커맨드(srv_parseerr)를 호출한다.

만약 메시지 파싱이 에러없이 완료되었고 인입 메시지에서 "reply" 태그를 찾을 수 있다면, 블럭(234)에 도시한 바와 같이 응답 메시지로 취급된다. 만약 상기 메시지가 "ctxt" 파라메타도 포함하고 있다면, 이때 상기 서버 쉘은 일치하는 콘텍스트값을 갖는 엔트리를 찾기 위해 대기 리스트를 참조한다. 만약 엔트리가 발견되면, 블럭(240)에 도시한 바와 같이, 상기 엔트리와 연관된 커맨드가 호출된다. 만약 메시지에 "ctxt" 파라메타가 존재하지 않거나 혹은 메시지의 "ctxt"가 대기 리스트에 존재하지 않는다면, 상기 서버 쉘은 블럭(238)에 도시된 바와 같이 존재하는 경우, 후크 커맨드(srv_reply)를 호출한다. 만약 존재하지 않는다면, 메시지내의 커맨드를 실행하지 않고 메시지가 버려진다.

커맨드 메시지는 "do" 태그이지만, "reply" 태그가 아닌 것을 포함하는 메시지로 정의되어 있다. 그래서, 만약 블럭(234)에서 "reply" 태그가 아닌 것이 발견되면, 이때 서버 쉘은 블럭(242)에 도시한 바와 같이 "do" 태그 및 파라메타를 참조한다. 만약 "do" 태그 및 파라메타가 존재하면, 이때 그것은 커맨드 메시지이며,그 처리는 블럭(244)과 제13도에 도시되어 있다. 커맨드 메시지 처리는 제13도와 관련하여 이하에 상세히 설명되어 있다.

만약 메시지가 "do" 혹은 "reply" 태그를 포함하고 있지 않다면, 그것은 데이타 메시지로 간주된다. 데이타 메시지의 처리는 블럭(246)에 도시되어 있다. 서버 쉘은 메시지에서 "ctxt" 파라메타를 참조하여 블럭(248)에 도시한 바와 같이 동일한 콘텍스트 파라메타를 갖는 엔트리에 대한 대기 리스트를 검사한다. 만약 메시지가 "ctxt" 태그를 가지고 있지 않거나 또는 대기 리스트에 존재하지 않는 "ctxt" 태그를 포함하고 있다면, 이때 서버 쉘은 블럭(250)에 도시한 바와 같이 존재하는 경우에 후크 커맨드(srv_data)를 호출한다. 만약 srv_data 커맨드가 존재하지 않는다면, 메시지는 버려져 무시된다. 만약 일치하는 콘텍스트값을 갖는 엔트리가 발견되면, 블럭(252)에 도시한 바와 같이 상기 엔트리와 연관된 커맨드가 실행된다.

서버 쉘은 클라이언트에서 나오는 출구 신호 또는 "exit" 커맨드로 종료될 때까지 메시지의 처리를 계속한다. 상기 출구 커맨드는 바람직하게 서버 쉘내의 출구 플래그를 세트시킨다. 상기 출구 플래그는 블럭(254)에 도시된 바와 같이 각 메시지 처리 루프의 끝단에서 검사된다. 만약 세트되어 있다면, 블럭(256)에 도시한 바와 같이, 상기 서버 쉘은 srv_exit 후크 커맨드를 호출한 후 종료한다.

제12도와 관련하여, 비-표준 포맷 메시지의 처리(216)가 도시되어 있다. 비-표준 포맷 메시지가 수신되면, 서버 쉘은 메시지의 처리 방법을 결정하기 위해 바람직하게 SYS>PROTOCOL(제4도에 도시되어 있음)와 같은 특정한 동적 변수를 검사한다. 상기 SYS>PROTOCOL 동적 변수는 블럭(260과 264)에 도시한 바와 같이 메시지가SECS(반도체 장치 통신 표준) 포맷 또는 ASCII 포맷이라는 것을 가리킬 수 있다. 만약 상기 변수가 존재하지 않거나 또는 값을 가지고 있지 않다면, 블럭(268)에 도시한 바와 같이 메시지는 후크 커맨드(srv_msg)로 보내진다. 만약 srv_msg가 존재하지 않는다면, 상기 메시지는 버려져 무시된다.

만약 SYS>PROTOCOL 동적 변수가 SECS로 설정되어 있다면, 이때 서버 쉘은 후크 커맨드(sxdecode)를 호출하여 상기 메시지를 처리한다. sxdecode 후크 커맨드는 SECS 메시지로부터 데이타를 발췌하여 동적 변수에 기억시킨다. 만약 SYS>PROTOCOL 동적 변수가 ASCII로 설정되어 있다면, 서버 쉘은 메시지를 처리하기 위해 cut 후크 커맨드를 실행한다. 상기 cut 커맨드는 ASCII 메시지로부터 데이타를 발췌하여 발췌된 데이타를 동적 변수에 기억시킨다. 두 가지예에서, SECS와 ASCII 메시지의 포맷은 미리 정의되어야만 한다. 또한 두 커맨드는 SECS와 ASCII 메시지 처리를 위한 장치 서버 쉘에 정의되어 있다.

비-표준 포맷 메시지가 sxdecode 또는 cut에 의해 디코드된 후, 블럭(270)에 도시한 바와 같이 서버 쉘은 메시지를 처리하기 위한 커맨드로 보내는 엔트리에 대한 대기 리스트를 검사한다. 만약 엔트리가 발견되면, 블럭(272)에 도시한 바와 같이 이에 대응하는 커맨드가 호출된다. 만약 아무런 콘텍스트 엔트리도 발견되지 않고 srv_msg가 정의되어 있다면, 블럭(268)에 도시한 바와 같이 메시지를 처리하기 위해 srv_msg가 호출된다. 그 후 실행은 제11도의 블럭(254)으로 복귀한다.

만약 표준 포맷 메시지가 "do" 태그를 포함하고 있지만 "reply" 태그를 포함하고 있지 않다면, 커맨드 메시지로 간주된다. 제13도와 관련하여, 커맨드 메시지처리(244)가 도시되어 있다. 서버 쉘은 바람직하게 "do" 태그가 실행될 커맨드를 식별한다고 가정한다. 서버 쉘은 블럭(280)에 도시한 바와 같이 그 이름이 "do" 태그의 값과 일치하는 커맨드에 대한 서버의 커맨드 리스트를 참조한다. 만약 서버의 커맨드 리스트에서 커맨드가 발견되지 않는다면, 서버 쉘은 블럭(282와 284)에 도시한 바와 같이 후크 커맨드(srv_command)를 실행할 것이다. 만약 srv_command이 존재하지 않는다면, 서버 쉘은 블럭(286)에 도시한 바와 같이 클라이언트에 에러 응답 메시지를 작성하여 보낼 것이다.

만약 "do" 태그에 의해 식별된 커맨드가 커맨드 리스트에서 발견되지 않는다면, 블럭(288)에 도시한 바와 같이 커맨드 리스트에 기억된 신택스 스트링에 대해 커맨드 메시지의 구문이 검사된다. 그러나, 만약 인입 메시지에 태그되지 않은 파라메타 "nosyntax"가 존재하거나 또는 동적 변수 nosyntax가 존재한다면, 이때 신택스 검사는 수행되지 않는다. 만약 신택스 에러가 검출된다면, 블럭(290과 286)에 도시한 바와 같이 서버 쉘에 의해 클라이언트로 에러 응답 메시지가 반환되고 커맨드는 실행되지 않는다.

만약 커맨드 메시지 구문이 정확하다면, 블럭(292)에 도시한 바와 같이 서버 쉘은 커맨드 코드를 호출한다. 상기 커맨드 코드는 C++ 혹은 스크립트 언어로 작성될 수 있다. C++ 커맨드가 호출될 때, 커맨드에 부속되어 있는 이전에 컴파일된 C++ 함수가 호출된다. 스크립트 언어 커맨드가 호출될 때, 상기 스크립트 언어 코드는 라인-대-라인으로 해석된다.

C++ 혹은 스크립트로 작성되었는 가에 대해서는, 커맨드 코드는 정수값과 선택적인 스트링 데이타를 반환하여야만 한다. 반환된 정수와 스트링 데이타는 클라이언트로 반환되는 응답 메시지를 작성하는 데 사용되곤 한다. 만약 커맨드를 호출한 커맨드 메시지가 "noreply" 파라메타를 포함하고 있다면, 이때 블럭(294)에 도시한 바와 같이 응답은 필요하지 않으며 클라이언트로 응답이 전달되지 않는다. 상기 "noreply" 파라메타는 특정 커맨드의 성공적인 완료가 클라이언트에 대해 중요할 때 사용된다. 만약 응답이 필요하며 커맨드를 호출한 커맨드 메시지가 "ctxt" 파라메타를 포함하고 있다면, 서버 쉘은 콘텍스트 태그와 그 결과로 나타나는 응답 메시지의 값을 포함한다. 다음에 실행은 제11도의 블럭(254)로 복귀한다.

또한 오토메이션 개발 시스템(10)에는 오토메이션 개발 시스템(10)에 의해 생성되지 않은 엔티티와 통신하기 위한 규정이 제공되어 있다. 큐 서버가 큐들을 제어하지 못하기 때문에, 상기 큐에 어떤 이름을 지정하여야할 것인지 대해 알려져야만 한다. 그리하여, 큐 서버는 선정된 큐 및 그에 대응하는 키의 명칭 혹은 ID를 기록하는 고정된 키 표 또는 화일과 체크인한 서버의 큐 명칭 및 키를 기록하는 오토메이션 큐 표를 유지한다. 일단 한 개의 키 표에 큐 키가 등록되고 나면, 시스템내의 임의의 다른 큐와 같은 이름으로 참조될 수 있다.

더욱이 상기 큐 서버는 개별적인 CPU 상의 클라이언트와 서버간에 메시지의 송신과 수신을 지원한다. 각 CPU는 각각 큐 서버와 네트 서버라고 불리우는 부수적인 프로세스를 갖는 개별적인 오토메이션 개발 시스템상에서 동작할 수 있다. 상기 큐 서버는 네트워크를 통해 다른 CPU로 메시지를 전달하는 데 사용되는 한편, 상기 네트 서버는 네트워크로부터 메시지를 수신하여 목적지 프로세스로 전달하는 데 사용된다.

제14도는 분산된 메시지를 전달하는 프로세스를 예시한다. CPU1상에서 동작하는 서버 A는 CPU2상에서 동작하는 서버 B로 메시지를 전송하기를 원한다 :

1. 서버 A는 블럭(301)에 도시한 바와 같이 서버 B의 큐 ID를 큐 서버에 요청한다.

2. 큐 서버가 오토메이션 큐의 리스트에서 서버 B를 찾지 못하기 때문에, 고정 키 화일에서 찾는다.

3. 큐 서버는 고정 키 화일에서 서버 B를 찾아 화살표(302)로 도시한 바와 같이 예를 들어 9657이라는 큐 서버의 큐 값을 갖는 키를 서버 A로 보낸다.

4. 서버 A는 화살표(303)으로 도시한 바와 같이 큐(9657)로 메시지를 보낸다.

5. CPU1상의 큐 서버는 서버 A로부터 메시지를 수신하지만, "to" 태그가 그 큐 값과 일치하지 않는다는 것을 알린다.

6. 큐 서버는 서버 B에 대한 루팅 표를 참조한다. 상기 루팅 표는 바람직하게 프로세스와 프로세스가 빠져나가는 원격 머신의 이름을 포함하는 동적 변수 구조이다.

7. 큐 서버는 서버 B와 서버 B의 CPU 이름을 루팅 표에서 찾아, 화살표(304)로 도시한 바와 같이 네트워크를 통해 서버 A로부터 CPU2로 메시지를 전달한다.

8. CPU2상의 네트 프로세스는 화살표(305)로 도시한 바와 같이 네트워크로 부터 메시지를 수신한다.

9. 네트 프로세스는 화살표(306)로 도시한 바와 같이 CPU2의 큐 서버와 함께 서버 A를 등록한다.

10. 네트 프로세스는 CPU2의 큐 서버에게 서버 B의 큐 ID를 요청한다. 큐 서버는 화살표(307)로 도시한 바와 같이 체크인 될 때 서버 B에게 지정되어 있던 5003과 같은 큐ID를 반환한다.

11. 네트 프로세스는 화살표(308)로 도시한 바와 같이 서버 B로 메시지를 보낸다.

12. 서버 B는 국소 프로세스로부터 보내진 메시지를 수신하다.

큐 서버(34)외에, 또한 통합 오토메이션 개발 시스템(10)은 서버와 클라이언트에 대해 시간에 특정하거나 또는 시간에 종속하는 행위를 코디네이트하기 위해 시간 서버(36)(제1도)를 필요로 할 수 있다. 예를 들어, 타이머는 매 24시간마다 유지 보수 커맨드 메시지를 보내거나 또는 30초마다 "timeout" 메시지를 보내는 데 사용될 수 있다. 상기 시간 서버는 클럭 또는 시간 유지 장치에 서버가 연결되어 있다. 또한 상기 시간 서버는 큐 서버와 같이 백 그라운드로 실행되어야 한다.

장치 서버(22)(제1도)는 특정 유형의 제조 장치에의 서버 인터페이스를 정의하는 방법 또는 서버 커맨드를 제공한다. 상기 장치 서버는 서버 쉘이 모든 코드혹은 커맨드 이외에 제조 장치와 인터페이스하는 데 필요한 기능을 제공하는 부수적인 커맨드들을 포함한다. 장치 서버를 정의하고 사용하게 하는 장치 서버 커맨드 이외에, 또한 상기 장치 서버는 제조 장치로부터 수신된 SECS와 ASCII 메시지를 처리하는 상술된 sxdecode와 cut라고 하는 두 개의 특수한 커맨드를 정의한다. 더욱이 상기 장치서버는 바람직하게 장치로부터의 데이타 로깅을 제공한다.

장치 서버에 의해 서비스된 각 장치에는 독특한 SECS 식별 번호 또는 ID가 지정되어야 한다. SECS 장치는 장치에서 나오고 장치로 들어가는 모든 메시지에 상기 ID가 놓여질 것을 요구하며, 그래서 상기 장치 서버는 들어오는 SECS 메시지를 구분하고 식별하는 데 상기 ID를 사용한다. 상기 장치 서버는 SECS 메시지를 루팅하고, 디코딩하며, 인코딩 및 전달하기 위한 일부 커맨드를 포함한다. 보다 상세한 SECS 메시지 포맷에 대한 설명은 관련되는 SECS 문서를 참조한다.

제1도의 그래픽 제어 클라이언트는 순차적 기능 도표 또는 SFC 표기법을 사용하는 오토메이션 제어 서버로 구현될 수 있다. 상기 SFC 표기법은 국제 전자 기술 위원회에 의해 정의된 바와 같이 제어 시스템의 그래픽 표현에 대한 국제적 표준에서 나온 것이다. 이때 상기 그래픽 제어 클라이언트(14)는 오토메이션 개발 시스템의 제어 흐름을 제공하고 정의한다. 이것은 제어 응용을 정의하고 디버깅하는 커맨드를 제공한다. 이때 상기 제어 애플리케이션 정의는 응용을 실행하기 위해 시스템의 서버와 클라이언트를 코디네이트하는 데 사용된다.

또한 데이타베이스와 같은 다른 엔티티와의 인터페이스 기능을 수행할 수 있도록 통합 오토메이션 개발 시스템(10)에서 다른 서버 프로세스가 구현될 수 있다. 서버는 시스템의 잘못된 코딩을 검출할 수 있도록 임의의 동작과 기능을 모니터하는 디버그 서버, 시스템의 모든 다른 서버에 커맨드 라인의 인터페이스를 개발자에게 제공하는 대화 서버 및 SFC 편집 능력을 제공하는 SFC 편집기와 같이 통합이 용이하도록 구현될 수 있다. 상술된 바와 같이, 상기 모든 서버는, 서버 쉘(42)(제2도)의 기본 코드 및 커맨드에 애플리케이션 전용 커맨드를 부가함으로써, 기본적인 논리 흐름 제어, 메시징 관리, 커맨드 관리, 스크립트 해석 및 동적 변수 관리가 적절하게 되도록 구현된다. 이에 따라, 오토메이션 통합이 더욱 용이하게 구현되며, 그 구현 및 변형이 보다 신속하게 행해질 수 있다.

비록 본 발명이 상세하게 설명되었을지라도, 첨부하는 특허청구의 범위로서 한정된 바와같이 본 발명의 정신과 범위를 벗어나지 않고 다양한 변화, 대체 및 변형이 있을 수 있다는 것을 알아야 한다.

제1도는 본 발명의 실시예에 대한 개략화된 시스템 블럭도.

제2도는 서버 쉘 모듈 실시예의 구성 요소를 나타내는 도면.

제3도는 메인 서버 구성 요소의 개략도.

제4도는 동적 변수의 데이타 구조를 나타내는 개략도.

제5도는 메시지에 근거한 통신 프로토콜의 개략도.

제6도는 메시지에 근거한 통신 프로토콜의 다른 개략도.

제7도는 메시지에 근거한 통신 프로세스의 개략화된 데이타 흐름도.

제8도는 커맨드 메시지를 처리하는 개략화된 순서도.

제9도는 기본 서버 제어 흐름의 개략화된 순서도.

제10도는 서버 초기화의 개략화된 순서도.

제11도는 서버 메시지 처리의 개략화된 순서도.

제12도는 서버의 비-표준 메시지 처리의 개략화된 순서도.

제13도는 서버 커맨드 메시지 처리의 개략화된 순서도.

제14도는 분산 메시지 통신의 개략화된 데이타 흐름도.

도면의 주요부분에 대한 부호의 설명

10 : 통합 오토메이션 개발 시스템

14 : 그래픽 제어 클라이언트

16 : SMS 서버

22 : 장치 서버

28 : 단말 서버

34 : 큐 서버

36 : 시간 서버

40, 54, 74 : 서버

41 : 커맨드 관리기

42 : 서버 쉘

43 : 스크립트 언어 인터프리터

45 : 메시징 관리기

47 : 쉘 논리 제어기

48 : 애플리케이션 전용 커맨드 관리기

49 : 동적 변수 관리기

52, 72 : 클라이언트

62, 80 : 자원

Claims

복수의 서버 프로세스를 구비하여 제조 장치를 제어하고 코디네이트하기 위한 통합 오토메이션 개발 시스템(integrated automation development system)에 있어서,

각각의 상기 서버 프로세스는,

상기 복수의 서버 프로세스로부터 ASCII 메시지를 수신하기 위한 메시징 관리기(messaging manager);

텍스트 베이스(text-based) 프로그래밍 언어로 표시된 커맨드를 포함하는 상기 수신된 ASCII 메시지를, 상기 여러 서버 프로세스에 대해 평가하여, 상기 ASCII 메시지 내의 상기 커맨드를 식별하기 위한 인터프리터(interpreter);

상기 커맨드를 수신하여 실행하기 위한 커맨드 관리기; 및

상기 커맨드 관리기에 의한 상기 커맨드 실행의 논리 흐름을 관리하기 위한 논리 제어기

를 포함하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제1항에 있어서,

상기 인터프리터는, 상기 수신된 ASCII 메시지 내의 동적 변수(dynamic variables)를 식별하며,

상기 동적 변수는, 계층적으로(hierarchically) 구조화되고, 상기 커맨드 관리기에 의한 커맨드의 실행 동안에 데이타값을 기억시키는 데에 사용되거나 혹은 커맨드의 실행을 위해 상기 커맨드 관리기에 의해 요구되는 데이타값을 제공하는 데에 사용되는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제1항에 있어서,

상기 논리 제어기는,

입력되는 메시지에 대해 체크하고, 상기 메시지를 파싱(parsing)하며, 상기 메시지 내의 커맨드를 찾아내고, 상기 커맨드의 신택스(syntax)를 체크하고, 상기 커맨드를 실행하고, 응답 메시지를 발생시키도록, 상기 커맨드 관리기에게 지시하며,

상기 논리 제어기는 또한, 상기 응답 메시지를 보내도록 상기 메시징 관리기에게 지시하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제1항에 있어서,

상기 각 서버 프로세스는 메시지를 수신하기 위한 메시지 큐(queue)를 더 포함하며,

상기 논리 제어기는, 들어오는 메시지에 대한 상기 메시지 큐를 체크하고, 상기 메시지를 파싱하며, 상기 메시지의 포맷을 식별하고, 상기 메시지의 상기 식별된 메시지 포맷에 따라 상기 메시지를 처리하고, 메시지에 대한 상기 메시지 큐를 계속해서 체크하도록, 상기 커맨드 관리기에게 지시하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제1항에 있어서,

상기 커맨드 관리기는 애플리케이션 전용(application-specific) 커맨드를 실행하기 위한 애플리케이션 전용 커맨드 관리기로서, 상기 제조 장치를 제어하고 상기 제조 장치와의 인터페이싱을 행하며,

상기 논리 제어기는, 들어오는 메시지에 대한 체크를 행하고, 상기 메시지를 파싱하며, 상기 메시지의 포맷을 SECS 메시지로 식별하고, 상기 SECS 메시지를 처리하고, 메시지에 대한 체크를 계속해서 행하도록, 상기 애플리케이션 전용 커맨드 관리기에게 지시하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제1항에 있어서,

상기 커맨드 관리기는, 애플리케이션 전용 커맨드를 실행하기 위한 애플리케이션 전용 커맨드 관리기로서, 상기 서버 프로세스간의 메시지 루팅(routing)을 관리하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제6항에 있어서,

상기 애플리케이션 전용 커맨드 관리기는, 기존의 서버 프로세스 명칭과 이에 대응하는 메시지 큐 어드레스의 리스트를 유지하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제1항에 있어서,

상기 애플리케이션 전용 커맨드 관리기는, 사용자 단말기와의 인터페이싱을 행하기 위한 애플리케이션 전용 커맨드를 실행하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제1항에 있어서,

상기 애플리케이션 전용 커맨드 관리기는 호스트 제조 컴퓨터 시스템과의 인터페이싱을 행하기 위한 애플리케이션 전용 커맨드를 실행하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제조 장치를 제어하고 코디네이트하기 위한 통합 오토메이션 개발 시스템에 있어서,

메시지를 생성하기 위한 제어 클라이언트;

상기 제조 장치에 결합되어, 상기 제어 클라이언트로부터 상기 메시지를 수신하고, 상기 메시지의 지시에 따라 상기 제조 장치를 제어하며, 이에 따라 응답 메시지를 발생시키는 복수의 장치 서버;

개발자 인터페이스 단말기에 결합되어, 개발자 입력을 수신하고 시스템 상태를 디스플레이하며 메시지를 발생 및 수신하는 단말 서버; 및

상기 제어 클라이언트, 장치 서버 및 단말 서버간의 상기 메시지의 루팅을인에이블시키기위한 큐 서버

를 포함하며,

상기 제어 클라이언트, 상기 장치 서버, 상기 단말 서버 및 상기 큐 서버 각각은,

상기 복수의 장치 서버로부터 ASCII 메시지를 수신하기 위한 메시징 관리기;

텍스트 베이스 프로그래밍 언어로 표현되어 있는 커맨드를 갖는 상기 수신된 ASCII 메시지를, 상기 장치 서버의 변수에 대해 평가하여, 상기 ASCII 메시지 내의 상기 커맨드를 식별하는 인터프리터;

상기 커맨드를 수신하여 실행하는 커맨드 관리기; 및

상기 커맨드 관리기에 의한 상기 커맨드 실행의 논리 흐름을 관리하기 위한 논리 제어기를 포함하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제10항에 있어서,

상기 인터프리터는 상기 수신된 ASCII 메시지 내의 동적 변수를 식별하며,

상기 동적 변수는, 계층적으로 구조화되고, 상기 커맨드 관리기에 의한 커맨드의 실행 동안에 데이타값을 기억시키는 데에 사용되거나 혹은 커맨드의 실행을 위해 상기 커맨드 관리기에 의해 요구되는 데이타값을 제공하는 데에 사용되는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제10항에 있어서,

상기 논리 제어기는,

입력되는 메시지에 대해 체크하고, 상기 메시지를 파싱(parsing)하며, 상기 메시지 내의 커맨드를 찾아내고, 상기 커맨드의 신택스(syntax)를 체크하고, 상기 커맨드를 실행하고, 응답 메시지를 발생시키도록, 상기 커맨드 관리기에게 지시하며,

상기 논리 제어기는 또한, 상기 응답 메시지를 보내도록 상기 메시징 관리기에게 지시하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제10항에 있어서,

상기 제어 클라이언트, 상기 장치 서버, 상기 단말 서버 및 상기 큐 서버 각각은, 메시지를 수신하기 위한 메시지 큐를 더 포함하며,

상기 논리 제어기는, 들어오는 메시지에 대한 상기 메시지 큐를 체크하고, 상기 메시지를 파싱하며, 상기 메시지의 포맷을 식별하고, 상기 메시지의 상기 식별된 메시지 포맷에 따라 상기 메시지를 처리하고, 메시지에 대한 상기 메시지 큐를 계속해서 체크하도록, 상기 커맨드 관리기에게 지시하는 것을 특징으로 하는 통합 오토메이션 개발 시스템.
제조 장치를 제어하고 코디네이트하며, 복수의 서버 프로세스를 구비한 오토메이션 개발 시스템을 통합하는 방법에 있어서,

다른 서버 프로세스로부터의 ASCII 메시지를 체크 및 수신하는 단계;

텍스트 베이스 프로그래밍 언어로 표현된 하나 이상의 커맨드를 포함하는 상기 수신된 ASCII 메시지를, 서버 프로세스의 변수에 대해 평가하고, 상기 ASCII 메시지 내의 상기 커맨드를 식별하는 단계;

상기 커맨드를 실행하는 단계; 및

추가적인 ASCII 메시지에 대한 체크를 계속해서 행하는 단계

를 포함하는 것을 특징으로 하는 오토메이션 개발 시스템의 통합 방법.
제14항에 있어서,

상기 ASCII 메시지 내의 동적 변수를 식별하는 단계;

상기 동적 변수를 계층적으로 구조화하는 단계; 및

상기 동적 변수를 사용하여 커맨드의 실행 동안에 데이타 값을 기억하거나, 혹은 커맨드의 실행에 필요한 값을 공급하는 단계

를 더 포함하는 것을 특징으로 하는 오토메이션 개발 시스템의 통합 방법.
제14항에 있어서,

상기 ASCII 메시지를 파싱하는 단계;

상기 ASCII 메시지 내의 커맨드를 찾아내는 단계;

상기 커맨드의 신택스를 체크하는 단계;

상기 커맨드를 실행하는 단계;

응답 메시지를 발생하는 단계; 및

상기 응답 메시지를 적절한 목적지로 보내는 단계

를 더 포함하는 것을 특징으로 하는 오토메이션 개발 시스템의 통합 방법.
제14항에 있어서,

들어오는 메시지에 대한 메시지 큐를 체크하는 단계;

상기 메시지를 파싱하는 단계;

상기 메시지의 포맷을 식별하는 단계;

상기 식별된 메시지 포맷에 따라 상기 메시지를 처리하는 단계; 및

상기 메시지에 대한 메시지 큐를 계속해서 체크하는 단계

를 더 포함하는 것을 특징으로 하는 오토메이션 개발 시스템의 통합 방법.
제14항에 있어서,

상기 제조 장치를 제어하고 상기 제조 장치와의 인터페이싱을 행하기 위한 애플리케이션 전용 커맨드를 실행하는 단계;

들어오는 메시지에 대한 체크를 행하는 단계;

상기 메시지를 파싱하는 단계;

상기 메시지의 포맷을 SECS 메시지로 식별하는 단계,

상기 SECS 메시지를 처리하는 단계; 및

메시지에 대한 체크를 계속해서 행하는 단계

를 더 포함하는 것을 특징으로 하는 오토메이션 개발 시스템의 통합 방법.
제14항에 있어서,

상기 서버 프로세스간의 메시지 루팅을 관리하기 위한 애플리케이션 전용 커맨드를 실행하는 단계; 및

기존의 서버 프로세스 명칭과, 이에 대응하는 메시지 큐 어드레스의 리스트를 유지하는 단계

를 더 포함하는 것을 특징으로 하는 오토메이션 개발 시스템의 통합 방법.