KR930006222B1 - 프로그램 가능한 논리제어기에 관한 개량 - Google Patents

Abstract

내용 없음.

Description

프로그램 가능한 논리제어기에 관한 개량

제1a도는 본 발명에 따른 기계 또는 공정동작을 제어하기 위한 프로그램 가능한 제어기를 보여주는 도면.

제1b도는 본 발명이 응용되는 간단한 장치 및 그 장치의 제어를 위한 도면.

제1c도는 제1b도의 장치 및 제어용 제어기에 대한 래더도.

제2a도는 엘리베이터의 여러가지 동작의 상태 및 상태 사이에서 천이가 일어나게 하는 조건의 상태도.

제2b도는 제2a도에서 상태도의 동작상태에 대응하는 문의 블록도.

제2c도는 프로그램 코드구조를 강조한 도면.

제2d도는 보다 복잡한 상태도.

제3a도는 프로그램 루프 포인터를 나타낸 도면.

제3b도는 타스크 테이블.

제3c도는 타스크 테이블 포인터를 나타낸 도면.

제4도는 무한 루프형태로 표시된 트레이스 테이블의 논리를 표현하는 도면.

제5도는 시작 프로그램 이라고 호칭되는 서브루틴의 개략 블록도.

제6도는 제1오퍼레이터 서브루틴의 개략 블록도.

제7도는 p코드 포인터 전진의 서브루틴의 개략 블록도.

제8도는 타스크 테이블 레지스터 전진의 서브루틴의 개략 블록도.

제9도는 다음 오퍼레이터의 서브루틴의 개략 블록도.

제10도는 고우 투 서브루틴의 개략 블록도.

제11도는 시작 서브루틴의 개략 블록도.

제12도는 고우 서브루틴의 개략 블록도.

제13도는 리턴 서브루틴의 개략 블록도.

제14도는 히스토리 기억 서브루틴의 개략 블록도.

제15도는 히스토리 표시로 호칭될 디버킹 루틴의 개략 블록도.

제16도는 라인표시 디버킹 루틴의 개략 블록도.

제17도는 프로그램 상태 표시의 디버킹 루틴의 개략 블록도.

제18도는 루프 표시의 디버킹 루틴의 개략 블록도.

제19도는 발견된 루프의 디버킹 루틴의 개략 블록도.

본 발명은 기계 및/또는 공정의 동작상태를 제어하는 유한상태 응용 프로그램을 처리하기 위한 프로그램 가능한 제어기에 관한 것이다.

본 발명은 또한 유한상태 응용 프로그램의 진단을 쉽게할 수 있는 기계 및/또는 공정을 디버깅 하는 것에 관한 것이다.

1960년대에, 공업용 기계 또는 공정의 동작을 제어하는 전자 릴레이를 사용한 릴레이 제어 시스템을 대체하기 위해 프로그램 가능한 제어기가 개발되었다.

이들 프로그램 가능한 제어기는 회로들이 실제로는 컴퓨터내의 프로그램인데도 마치 제어기가 릴레이회로를 포함한 것과 같이 작업하도록 설계 되었다. 이들 프로그램 가능한 제어기에 의해 에뮬레이트(emulate)되는 릴레이 회로 설계는 그들의 일반적인 외관으로 인하여 래더도(ladder diagram)로 불리운다.

이 래더도는 출력 또는 작동이 입력 또는 조건의 상태에 직접 의존하는 경우에 조합 논리제어 프로그램을 설계하는데 우수하다. 그러나 순차 제어문제에 대해서는 제어동작이 시간 종속으로 되며, 래더도 방법이 조잡하여 설계 및 장애점 측정(fault-find)이 곤란하게 된다. 그 예로서, 로이드(Lloyd)이 콘트롤 엔지니어링(1985.10)지에 실린 "Graphical Fundtional Charts Programming for Programmable Controllers"를 참조할 수 있다.

래더도를 에뮬레이트 하기 위하여는 프로그래머가 소프트웨어 명령형태 또는 텍스트형의 그래픽 형태로 부울(Boolean)식의 긴 리스트를 연결하여야 한다. 각 명령은 내부 또는 외부신호를 제어한다. 이러한 시스템에서 디버깅 또는 장애점 측정은 통상 예기치 않은 조건이 관찰되어 예기치 않은 조건을 야기할 수 있었던 요인의 몇몇 또는 모든 가능한 조합을 직관적으로 조사해야 하는 것을 포함하고 있다. 래더도의 모든 것은 각 스캔사이클 마다 스캔되므로 어느 부분의 문제를 포함하지 않는 것으로서 제거하는 것이 가능하지 않다.

래더도 제어기의 다른 결점은 예기치 않았던 조건의 원인을 판단하기 위하여 문제의 원인에 관한 정보를 기록하는 것이 바람직하다. 그러나 래더도 시스템은 시스템 변수에서 관련 및 무관한 변화 사이를 구별할 매커니즘을 갖지 않으며, 이것은 분석하고 분류하는데 어려운 비실용적으로 많은 양의 데이터를 기억시킬 필요가 있게 된다.

더우기 래더도 제어기는 프로그램 작성을 조잡하게 한다. 이러한 특성으로 인하여 래더도는 이해하는 것이 어렵다. 또한, 래더도는 더 넓은 매크로 기능, 특히 순차 기능을 제공하도록 설계된 것을 명료하게 보여 주지 않는다. 그들이 보여주는 것은 결과적으로 그 기능성을 제공하는 회로이다. 오랫동안 래더도와 친숙하지 않은 기계 설계 및 제조 엔지니어들은 그들의 기계 또는 공정용 제어시스템을 용이하게 개발할 수 없었다. 대신 그들은 그들의 제어시스템의 프로그램을 작성하기 위하여 전문 제어 엔지니어링에게 전적으로 의존하지 않으면 안되었다.

프로그램 가능한 제어기를 간단히 하기 위한 노력으로서 엔지니어들이 "상태도(state diagrams)"를 에뮬레이트하기 위하여 고급 언어를 사용할 수 있는 시스템이 개발되었다. 상태도는 동작상태 그리고 기계 또는 공정에 있어서 동작상태 정도를 변화시키는 조건들의 그래픽 표현이다. 그래픽 형태에서 상태도는 상호 접속 아아크를 가진 일련의 노우드이다. 각 노우드는 특정한 동작상태를 표시하며 각 접속 아아크는 상태의 상황이 변하도록 하는 천이함수를 표시한다. 상태도는 엔지니어에게 모든 유형이 용이하게 설계되고 이해되기 쉽게한다. 그러나 상태도를 에뮬레이트 하는 현시스템은 프로그래밍과 디버깅이 어렵다.

이러한 시스템의 일예는 미합중국 특허 제4,562,529호로 드루몬드(Drummond)에게 특허되어 공개되었다. 드루몬드는 "상태논리변수"를 사용하여 기계 또는 공정의 동작상태를 제어하기 위한 방법 및 장치에 대해 논하고 있다.

"상태논리변수"는 기계 또는 공정의 각 동작상태를 특정하게 표시한다.

"상태논리변수"는 진 또는 거짓(TRUE 또는 FALSE) 2치중 단지 하나만 될수 있다. 진(TURE)은 상태가 액티브(active)인 것을 의미하고 거짓(FALSE)은 상태가 인액티브(inactive)인 것을 의미한다. 이러한 동작상태 제어방법을 사용하는 드루몬드 시스템은 래더도 제어기와 매우 유사하게 동작하는 것으로서 개시된다. 드루몬드의 방법과 장치에 있어서는 몇가지 문제가 존재한다.

첫째 전체 유한 상태 응용 프로그램은 드루몬드 시스템이 "상태논리변수"를 적절히 처리하기 위하여 주기적으로 스캔닝 되어야만 한다. 상태를 변화시키는데 필요한 상태변수를 정하기 위해서 또는 상태 의존 동작을 수행하기 위해서 드루몬드는 상태변수를 포함하는 많은 표현을 평가해야 했다. 그의 연구는 이것을 행하는 간편법을 다루고 있으나, 그 방법은 아직도 비능률적이고 전부 통털어 없어져 괜찮은 것이다.

둘째, 상태도는 예물레이트 하기 위해 드루몬드 제어기를 프로그램 하는 것은 번거로운 과정이다. 드루몬드에 있어서 개시된 언어로는 상태도를 용이하게 프로그램 코드로 변화시킬 수 없다. 이것은 "상태논리변수"의 상태를 정하는 조건문은 특정 프로그램 코드의 영역에 삽입될 수 없고 좌변에 상태변수항의 명시적인 포함을 요구하기 때문에 그렇다. 추가하여, 코드에 있는 사실상의 모든 문장은 상태 지정을 해야 할것인지 어떤지 또는 동작을 수행해야 될것인지 어떤지를 결정하기 위해서 "상태논리변수"가 평가될 것을 요구한다. 그 결과 단순한 기능을 수행하기 위해서도 많은 여분의 코드를 작성해야 한다.

마지막으로 유한상태 응용 프로그램에 있는 각 문장은 상태논리 변수의 상태를 평가하기 위해 각 스캔마다 스캔되어야 하므로, 시스템은 대단히 비효율적으로 동작한다. 이 결점은 처리능력을 심하게 제한하고 디버 그 목적을 위한 시스템 액티비티 정보의 기록을 제한한다. 또한 드루몬드는 동시에 제어될 다수의 운영작업을 트레이스하기 위한 적합한 해결법 또는 구조를 개시하고 있지 않다.

프랑스 규격 NF C 03-190에 기초를 둔 상업적으로 이용 가능한 GRAFCET 시스템에 대해서도 또한 유의 해야할 것이다. GRAFCET는 상태도를 어느 시점에서 단 하나에 액티브 상태를 갖는데 한정하지 않으며, 그래서 GRAFCET 상태도에 있어서는 한 액티브상태의 동일성을 안다는 것이 그 시간에 있어 그 상태도에 관련된 조건 및 동작을 전체적으로 정해주는 것은 아니다. 이것은 프로그램 디버깅중 상당한 단점이 된다.

그래서 PLC는 종래부터 래더도로 알려진 수단, 또는 균등수단에 의해 프로그램 되어 왔다. 언어에 자꾸 더많은 기능성이 부가됨에 따라(이용 가능한 래더도 기호 및 구조의 형태로), 프로그래밍에의 기초적 접근을 변경시킴에 의해서 단지 어드레스될 수 있는 래더도에는 제한이 있는 것이 명백해 졌다. 이것은 PLC가 플렉시블 오토메이션 스키마에서 기계를 제어하는데 사용될 때는 특히 현저하다. 그런 스키마 기능은, 수행되는 액티비티 및 시퀀스를 진행시키는 기능에 관해서, 또한 PLC가 동일한 시간에 많은 본질적으로 독립적인 순차 공정을 제어할 능력에 관해서, 복잡하고도 유연한 방법으로 제어기가 기계를 순차적으로 제어하는 제어기의 능력에 크게 좌우된다.

그런 일은 래더도 PLC로 될수 있고 행해진다. 그러나 그런 프로그램은 기록된 명세서 또는 플로우차트의 형태일 수 있는 시퀀스 정의로부터 래더도를 발생하도록 하기위해 번역 과정을 필요로 한다. 래더도를 검사할때 수행되는 기능은 분명하지 않고 프로그램을 디버깅하는 과정은 번거롭다. 명세서 또는 플로우차트에 있는 정보의 대부분은 기능적 요건이 그들 요건을 만족하는 릴레이 회로로 변환시키는 번역 과정에서 상실하거나 불명확하게 된다.

지난 몇년에 있어서 이러한 상태를 개선하는데 대해 많은 관심이 집중되었다. 그런 프로그램의 발생, 디버깅, 및 이해를 향상시킬 목적으로 시퀀싱 방법이 개발되어 왔다. 프랑스 GRAFCET의 노력은 괄목할만했고 유용한 방법이라고 국제적으로 인정을 받았다. 관련된 프랑스 및 서독 규격이 존재한다. 표준 플로우 차트를 사용하여 시퀀스를 기재하는 GRAFCET 방법의 변경방법을 사용하는 몇가지 PLC가 시판되고 있다. 그러나 제어시스템 프로그래밍의 최적 형태에 도달하기 위한 어드레싱에는 또다른 문제가 있고 이들은 현재 공지된 어떤 시스템에 의해서도 어드레스도지 않는다.

어드레싱 호출을 필요로 하는 문제는 다음 것들의 개선을 요구한다.

- 프로그램 구조 및 형태

- 적합성에 중점을 둔다.

- 복잡한 시스템의 이해를 간략화 한다.

- 고도의 기능에 적합하게 한다.

- 변화의 최소화

- 긍정적 부작용(side-effects)의 회피

- 하드웨어의 가격

- 광범위한 사람들에게는 설명적이고 사용자에게는 친숙하다.

- 최소화되는 훈련

- 디버깅에 의해 최대지원

본 발명의 상기한 단점을 감소 또는 제거하는 제어방법 및 장치를 제공하고자 하며, 제어, 제조 및 설계 엔지니어에 의해 보다 용이하고 자유스럽게 사용될 수 있는 것이다.

다음은 본 명세서에 기재된 발명의 특성을 보다 충분히 이해하도록 독자를 돕기 위한, 용어의 기초적 설명이다.

1. "동작의 상태"는 기계 또는 공정에 있어 유한시간 간격동안 존재하는 조건과 동작의 특정조합을 의미하며, 단지 기계 또는 공정의 신호 또는 값의 서브세트(subset)는 특정한 정해진 값에 있다.

기계 또는 공정의 "동작의 상태"는 현재 기계 또는 공정이 수행하는 특정 다스크(task) 또는 타스크의 서브세트로 생각될 수 있다.

2. "제어기"는 "동작상태"를 식별하는 수단을 포함하여, 공정이나 기계 또는 액티비에 걸쳐 제어를 행하는 장치를 의미한다. 이 목적을 위해서 제어기는 기계 또는 공정의 값과 상태변화를 계속 통보받아야 한다.

3. "프로그램상태"는 "동작의 상태"를 평가, 유지 및 제어하는데 사용되는 프로그램 코드의 하나 또는 복수의 문의 특정 블록을 의미한다.

4. "기계" 또는 "공정(처리)"란 용어는 한 특정 동작상태에서 다음 동작상태로 실시간으로 진행하는 시스템이다. 제어기는 기계나 공저응로 부터 신호를 판독하고, 기계나 공정의 동작을 모니터하고 자신의 정보상태에 의해 필요한 동작 상태를 트레이스하여, 응용 프로그램에 들어 있는 알고리즘에 기초하여 필요한 출력신호를 제공하여 기계를 필요한 동작상태에 옮겨 놓는다.

5. "멀티타스킹(multi-tasking)이란 용어는 하나의 제어기에 의해 별개의 프로그램 또는 같은 프로그램에 들어 있는 별개의 업무를 비동시적으로 실행하되, 그들 모두가 서로 동시적으로 실행되고 있는 것처럼 보이게 하는 방법을 의미한다. 상태(state)의 개념이란, 기계 또는 기계의 선택사용이 특정상태에 있다는 것이며, 상태가 단지 어떤 형태의 상태적 경계분리(delimiting)문장 또는 수단을 가진 프로그램내에서 어떤 인접 블록내에 정의 되도록 프로그램을 구성할 수 있게 하는 것이다. 이로부터 특정상태가 존재할 때는 그 루프에 관련된 프로그램의 오직 가능한 관련 부분이 상태를 정의하는 블록이라고 말할 수 있게 된다. 각 루프에서 액티브 상태에 정의된 것외에는 이 종류의 출력이 시스템에서 존재하지 않은 경우는 출력의 한종류가 언어의 일부로 제공된다.

이 종류의 출력은 모우터나 밸브를 작동하는데 흔히 사용된다.

따라서, 상태는 존재하는 동안은 현실적인 출력을 생산한다는 의미에서 존재한다고 말할 수 있으며 이들 출력은 상태만의 함수이고, 즉 이들은 바로 상태의 존재만을 조건으로 액티브 된다.

시스템에 존재하는 다른 조건에 의거하여 이들 출력의 자격이 결정되게 하는 것이 유리할지 모르지만, 이것은 시스템의 임의적 연장이 될 것이다. 한 상태에서 액티브로 되고 다른 상태에서 인액티브로 될수 있는, 예컨대 디스플레이나 레지스터를 구동하는데 사용되는 종류의 출력을 제공하는 것도 장점이 수 있다는 것을 유의해야 할것이다.

프로그램의 흐름을 제어하기 위해 "브레이크(break)상태" 및 "포즈(pause)상태"와 같은 서브클래스가 제공되는 것은 명시적 상태형식 문의 존재이다.

따라서 제어 액티비티를 디버깅하고 이해하는 것은 다음과 같이 "상태구조"에 의거할 수 있다.

- 존재하는 상태 및 상태가 어떤 주제어 기능을 제공하는가를 식별하는것.

예컨대 상태가 몇가지 출력을 액티브로 하고, 어떤 타이밍을 행하고, 입력을 묻고, 인쇄하고 끝으로 다른 상태로 변경시킬 것인가를 결정하지만, 그것은 어떤 매크로 기능을 수행한다고 말할 수도 있다 ; 예컨대 엘리베이터용 제어기는 상기한 바와같은 애티브성으로 구성되어 있는, "한층 위로 올라가라"와 같은 매크로 기능을 수행하는 상태를 가질 수 있는데 위에서 언급한 것과 같이 액티브하게 구성된다. 따라서 이 상태는 우리 시스템에서는 단일어 기호명으로 GoUpOneFloor(한층위로 올라가라)로 부를수 있으며, 이것은 프로그램에 구조를 제공하는 매크로기능을 수행하는데 필요한 하위 동작을 생각할 필요없이 대강의 이해를 제공한다.

- 전에 존재하였던 여러상태를 통해서 궁극적으로 기재의 전체적 현존 상태에 이르는 제어흐름의 조사,(즉 트레이싱(tracing)),

- 특정 상태에 도달될때까지 제어의 흐름을 가능하게 하는것, 즉 브레이크 상태로써, 그 단계에 대한 액티브의 이어지는 진단으로써 트래핑하는것, 또는 포즈상태로써 특정한 루프를 중지시키는것.

따라서 루프, 프로그램, 그룹, 프로그램등이 어떤 상태에 있고, 그 상태가 애매하지 않게 정의되기 이전이고, 존재한다고 또는 존재하지 않는다고 말할 수 있으나 검출 및/또는 기록은 될수 있는 함수하고 말할 수 있다는 것은 아주 유리하다는 것을 알수 있다.

트레이싱이 효과적이기 위해서는 상태 및 루프의 개념이 둘다 존재해야 한다.

간단하게 말하면, 본 발명의 바람직한 실시예는 하나 또는 그 이상의 상태도를 에뮬레이트하고 적어도 하나의 기계 또는 공정의 동작상태를 제어하기 위한 프로그램된 제어기를 포함한다. 제어기는 복수개의 블록문으로 되어 있는 응용 프로그램을 수행한다.

이들 블록문의 각각은 실행될때 기계 또는 공정의 한동작상태에 대응하는 내부제어 또는 상태를 형성하는 프로그램 상태이다. 문의 각 블록은 그중의 한 문이 정해진 과도(천이)조건이 만족되면 액티브 블록인 현존 블록을 대체할 수 있는 다음 블록의 문 및 기계나 공정에 의해 대응 동작상태 동안 취해질 동작을 형성한다. 프로그램 상태들은 전체 기계 또는 공정에 대한 또는 기계나 공정의 일부분에 대한 독립된 순차 제어 계획을 나타내는 하나 또는 다수의 프로그램 루프로 조직된다. 각 프로그램 루프는 사실상 상태도를 에뮬레이트한다.

제어기는 동시에 하나 또는 다수의 프로그램 루프를 액티브로 할수 있으나, 각 프로그램 루프는 프로그램 루프내의 한 프로그램 상태만 액티브되게 할수 있다. 액티브용 프로그램 루프와 관련된 액티브 프로그램 상태를 트레이스하기 위해, 변수가 각 액티브 프로그램 루프에 관련지어진다. 그 변수는 액티브 프로그램 상태의 식별자 또는 액티브 프로그램 상태의 시작의 어드레스를 기억한다. 변수는 또한 어느 액티브 프로그램 루프내에 특정 프로그램 상태가 존재하는가를 지시하는 식별자를 갖고 있다. 제어기는 또한 액티브 프로그램 루프에 대한 변수들을 기억하는 타스크 테이블을 갖고 있다. 타스크 테이블은 제어기가 몇가지 액티브 프로그램 루프를 비동기적으로 수행할 수 있게 하며 그것은 액티브 프로그램 루프의 실행순서를 결정한다. 기본적으로, 타스크테이블은 프로그램 루프의 전체에 대해 트레이스하며, 그 프로그램 상태를 액티브로 하여 각 프로그램 상태의 순서 및 시퀀스를 처리한다.

유한상태 응용 프로그램의 "디버깅"을 용이하게 하기 위한 방법과 장치가 또한 제공된다. 액티브 프로그램 상태 각각의 액티비티에 관한 정보를 기록하기 위한 수단이 제공된다. 특히, 제어기는 각 프로그램 상태의 순서의 발생 및 프로그램 상태의 각 발생에 따른 조건의 히스토리를 트레이스한다. 프로그래머가 기록된 정보를 평가할 수 있도록 표시수단이 또한 제공된다.

명백히, 본 발명은 제어, 제조 또는 기계 설계기사가 상태도를 나타내는 고급 수준의 응용 프로그램을 설계하고 보다 자유롭게 이해할 수 있도록 한다.

본 발명의 특별한 설계 이점은 프로그래머가 특정 동작상태에 관련된 모든 프로그램문을 인접 프로그램 코드의 세그먼트 또는 문블록으로 구성할 수 있고, 문의 어떤 것도 어떤 다른 동작상태와는 관련이 없다는 것이다. 이렇게하여 프로그래머는 다른 동작상태의 어느것에 대해서도 염려할 필요없이 각 동작상태에 의존하는 여러 모든 조건들을 구분할 수 있다. 이 과정은 "상태논리변수"를 제거하고, 조직적이고 구조화된 포맷으로 프로그램하는 기술을 용이하게 한다.

더우기, 전체 상태도 구조를 표시하는 프로그램 루프는 구분된 코드를 프로그램상태 블록내에 포함된 "조건부 GOTO 문" 또는 그런 종류의 것과 단순히 연결함으로써 용이하게 코드로 설계된다.

본 발명은 응용 프로그램에 있는 모든 문이 특정 동작상태가 제어될 필요가 있을 때마다 스캔될 필요가 없다는 점에서 종래기술 보다 더 효율적이다. 그 대신에 액티브되어 있는 특정 동작상태와 관련된 특정 프로그램상태에 있는 문들만이 스캔된다. 이 기술은 제어기가 매우 신속히 처리할 수 있게하고 본 발명이 동시에 복수개의 타스크를 보다 효율적으로 처리할 수 있게 한다. 본 발며의 바람직한 실시예는 또한 동시에 수행될 여러 시퀀스의 타스크를 트레이스 하고, 및/또는 타스크의 각 시퀀스가 수행될 순서를 결정하기 위한 타스크 테이블도 갖고 있다.

마지막으로, 이 응용 프로그램은 프로그램 상태로써 설계되기 때문에, 예기치 않은 사건의 원인의 위치결정이 훨씬 용이하게 되어 있다.

각 액티브 프로그램 상태가 일어나는 순서를 일어나는대로 기록하고, 각 프로그램상태에서 다음 상태로 일어나는 천이에 책임이 있는 또는 프로그램 상태의 최초 액티브 상태에 책임이 있는 하나 또는 다수의 조건을 기록하는 수단이 제공되어 있다. 각 프로그램상태의 발생의 디스플레이(표시)를 분석함으로써, 또한 천이가 일어나게 하는 조건문을 분석함으로써 분석자는 프로그램에 있어 예기치 않은 사건의 위치 및 원인을 신속하게 알수 있다.

언어 해석기(interpreter)소프트웨어의 설명 및 구현을 생각하기 전에 언어가 기초하는 원리에 대해 설명하고 본 발명에 의해 어떻게 프로그램이 구성되는가 하는 예를 들어 보겠다.

루프-상태구조는, 복합 시스템에서 제어에 대한 복잡하게 변하는 요건의 간단한 운영을 가능하게 하는 언어 시스템의 제일 중요한 특징이다.

간단한 개념은 다음과 같다. 건설현장에서 바닥판을 올리고 내리는데 사용될수 있는 엘리베이터를 생각하자. 상부 및 지면에서 Up 버튼이나 Down 버튼을 누른다. "정지", "상승" 또는 "하강"상태에 있다고 말할 수 있으나 어떤 한시점에서는 단지 한가지 상태에만 있다.

그의 동작은 제1b도에 있는 상태도의 도움으로 설명될 수 있다.

유의할 점은 다음과 같다.

- 번호 및 명칭이 원안에 포함되어 있는 상태.

- 조건이 어느 상태를 어느상태로 변하게 하는가를 표시하는, 원호옆에 용어로 정의되고 표시되어 있는 천이 조건.

- 관련이 있는 것을 최소화하고 정의 하는 상태도 기술방법. 예컨대 "상승"에 있어서는, "Down 버튼" 1 또는 2에서 일어나는 것은 전혀 관련이 없는 것이다.

- 마찬가지로, 모든 관련 액티브가 관련이 있는 상태와 관련되어 표시되는 방법, 예컨대 "하강"에 있어 "모우터를 하강으로 작동하시오".

- 엘리베이터의 동작이 이해될 수 있는 용이성. 예컨대 만약 엘리베이터가 정지되고 상승버튼(1)이 눌러져 있으면 상승하며, 단, 하강하고 있고 상승버튼(1)이 눌러져 있으면 그것을 무시한다.

상기 상태도에 기능적으로 대응하는 고급 언어를 사용하는 프로그램은 다음과 같다.

정지됨(Stopped)

브레이크 온되어 있음(Brake on)

Up 버튼(1)이 온 되거나 Up 버튼(2)이 온되면 Going Up(상승)에 가시오(If Upbuttonl on or UpButton2 on goto GoingUp)

Down 버튼(1)이 온되거나 Down 버튼(2)이 온되면 Going Down(하강)에 가시오(If DownButtonl on or DownButton2 on goto GoingDown)

상승(GoingUp)

상승 모우터 온되어 있음(UpMotor on)

Up 버튼(1)이 오프되어 있고 Up 버튼(2)이 오프되어 있으면 "정지됨"에 가시오(If UpButtonl off and UpButton2 off goto Stopped).

하강(GoingDown)

하강 모우터 온되어 있음(DownMotor on)

Down 버튼(1)이 오프되어 있고 Down 버튼(2)이 오프되어 있으면 "정지됨"에 가시오(If Down Buttonl off and DownButton2 off goto Stopped)

이 프로그램에서 생략된 유일한 부분은 특정변수에 특정 명칭을 배정하는 즉 Up 버튼(1)을 예컨대 입력단자(21)에 연결된 것으로 정의하는 정의문이다. 래더도(ladder diagrm)는 제1c도에 도시된 바와같다.

래더도에 있어서

-][는 상기 개접점이고,

-]/[는 상기 폐접점이고,

-( )는 릴레이 코일이다.

비록 회로동작은 비교적 이해하기 용이하지만 그것이 실제 기능적으로 되는 것은 추론하기가 훨씬 어렵다는 것을 유의하라. 어떤 한시점에 있어 관련이 있는 구조는 전연 나타나 있지 않다.

3상태 대신 100상태를 가진 상태도도 여전히 3상태와 같은 간단한 상태를 갖고 있고 각각이 차례로 이해될 수 있을 것이다. 100개의 단을 가진 래더도는 사실 악몽과 같다고 할수 있겠다.

우리의 루프-상태 구조의 원리는 다음과 같다.

- 프로그램은 기계의 각 부분에 대한 독립적 순차 제어 계획을 표시하는(하나) 또는 하나 이상의 별개의 루프들로 조직된다. 루프는 나머지 프로그램과는 독립적으로 처리될 수도 있고, 또는 플래그등을 통해 다른 루프와 핸드셰이크(handshake)하고 동기화될 수도 있다.

- 루프들은 상태의 시퀀스로 이루어진다.

즉, 루프는 사실상 입력에 의존하는/의존하지 않는 출력을 가진 상태 기계를 나타내는 상태도이다.

-각 상태기계 즉 루프는 루프가 액티브한 어떤 시점에서 액티비티인 오직 하나의 상태를 갖는다. 루프가 액티브하지 않으면 그 루프에는 액티브한 상태는 없다. 따라서 액티브 루프는 그 값이 그 시점에 있어 액티비티 상태의 번호/명칭인 상태변수를 소유한다고 말할 수 있다. 이것은 액세스될 수 있으며 핸드셰이킹, 진단등에 사용될 수 있다.

이것은 또한 관찰자에게 프로그램의 특정부분을 특정 목적을 위해 관련이 있는 것으로 집중적으로 비쳐주고 어떤 다른 부분이 관련이 있을 가능성을 배제하는 메카니즘이다. 이 배제성은 그것이 "여기를 보고, 아무 다른 곳도 보지말라"고 말하게 때문에 극히 중요하다.

- 각 루프에서 액티비티 상태에서 정의된 것이 외에는 이 종류의 어떤 출력도 시스템에서 존재하지 않을 경우는 출력의 한종류가 언어의 일부로 제공된다. 이 형의 출력은 전형적으로 모우터나 밸브를 작동하는데 사용된다. 따라서 상태는 또한 상태가 존재하는 동안 그것이 현실적 출력을 발생한다는 의미에서 존재한다고 말할 수 있고, 이들 출력은 상태만의 함수이며, 즉 이 출력은 바로 상태의 존재를 조건으로 액티브된다.

언어에 의한 출력 설정문은 효과적으로 "이 상태에 있는 동안의 이 출력은 발생하고 이 상태가 인액티브하면 사라진다"고 말하고, 그것은 "이 출력을 발생하라"고는 말하지 않으며, 다시 출력을 발생중지하기 위한 어떤 추가문도 필요로 하지 않는다.

- 천이 조건은 인액티브로 되게 하는 상태의 함수이다.

그들 조건은 "이 상태로 부터 다른 상태로 액티브 상태를 바꾸라"라고 말하는데, 여기에서 다른 상태 "goto"문의 매개 변수로 주어진다. 따라서 이들은 이들이 부분을 이루는 상태블록에 나타난다.

- 상태블록은 상태문으로 시작하고 다음 상태문에서 끝나는 프로그램의 인정하는 세그먼트이다. 그들은 그 상태에 관련된 모든 코드를 포함하고 어떤 다른 것에 관련된 것은 포함하지 않는다.

그러므로

- 기계의 한부분에 대해, 단지 하나의 루프가 관련되며,

- 부분의 시퀀싱에 있어서 특정한 시점에서 그 기계부분에 대해 그 루프의 한 상태만이 관련된다는 것을 알수 있다.

따라서, 한상태를 나타내는 세그먼트, 아마도 예를들면 2000중에서 10라인에 프로그램을 집중시키고 그것이 관련되는 유일한 부분임을 확인할 수 있다.

이것을 하기 위하여 관심의 대상이 되는 문제 또는 다른 사건과 관련된-이것은 단지 물러적 관련임-기계의 부분과 문제가 발생하는 시퀀스에서의 점을 단지 구하는 것이 필요하다. 트랩핑과 트레이싱은 이것이 프로그램으로 부터 명백하지 않으면, 그 시퀀스에 있어서 시간 포인트를 결정하는 수단을 제공한다. 트랩핑과 트레이싱의 명세는 본 발명자의 다른 특허 명세서에 기재되어 있다. 문서화는 그래프형태와는 반대로 텍스트 형태의 프로그램에 의해 쉽게 할수 있다.

제1a도는 상태도를 에뮬레이트하기 위해, 프로그램된 제어기(10)를 형성하는 프로그램 가능한 제어기와 컴퓨터 프로그램을 묘사한다. 유한상태 응용 프로그램은 프로그램된 제어기(10)의 메모리부분(10A)의 (14)에 기억된다. 중앙처리장치(CPU)(70)는 유한상태 응용 프로그램("응용 프로그램"에 대한 수학적 및 논리적 기능을 수행한다. 타스크테이블 또는 포인터 세트(69)는 액티브 프로그램 루프를 트레이스한다. 트레이스테이블(72)은 응용 프로그램의 액티브에 대한 일시적인 히스토리를 포함한다. 프로그램 가능한 제어기는 사용자가 응용 프로그램에서 에러를 쉽게 찾아낼 수 있게 하는 디버킹 모니터(74)가 장치되어 있다. 트레이스 테이블(72), 타스크 테이블(68) 및 디버그모니터(74)는 모두 메모리(10A)에 기억된다. 프로그램 가능 제어기의 잡다한 특징들을 제어하는 다른 운영체제 소프트웨어(76)에 기억된다. 터미날(80)은 제어기의 사용자가 응용 프로그램을 프로그램하고 터미날(80)상의 시스템을 디버그할 수 있도록 제공된다.

제1a도는 엘리베이터(12)와 같은 기계 또는 공정에 연결된 프로그램 제어기(10)를 나타낸다. 프로그램된 제어기(10)는 엘리베이터(12)의 동작을 제어하기 위해 (14)에서 응용 프로그램에 에뮬레이트한다. 유한상태 응용 프로그램은 상태도를 대표하는 고급 프로그램이다(제2a도 참조). 상태도는 제어할 특정기계 또는 공정의 동작의 상태도로 나타낸 표현이다. 프로그래머는 유한상태 응용 프로그램을 먼저 디자인하고, 둘째로 상태도를 에뮬레이트하고 기계 또는 공정에 의해 수행될 각 타스크 또는 동작의 발생의 명령과 순서를 제어하기 위해 제어기상에서 그것을 처리함으로써, 상태도에 의해 나타낸 기계 또는 공정을 제어한다.

프로그램된 제어기(10)의 간단한 응용은 엘리베이터(12)의 동작을 감시하고, 평가하고, 제어하는 것이다. 엘리베이터(12)는 기억 모우터 브레이크(16), 풀리(20) 및 엘리베이터실(18)로 구성된다. 엘리베이터의 기본원리는 엘리베이터의 단지하나의 동작상태만이 어느 한시점에서 액티브될 수 있다는 것이다. 엘리베이터 동작상태는 "정지" "상승" 또는 "하강"이다.

엘리베이터실(18)내의 버튼(22)은 엘리베이터가 한동작의 상태로 부터 다른 동작의 상태로 변화하게 한다. 예를들어, "Up"버튼이 폐쇄되고 "Down"버튼이 열리면, 엘리베이터실(18)은 상승한다.

"Dowm"버튼이 폐쇄되고 "Up"버튼이 열리면 엘리베이터실(18)은 하강한다.

"Up"버튼이 "하강"중에 눌려지거나 "Down"버튼이 "상승"중에 눌려지면 엘리베이터실(18)은 정지한다. 제2a도는 한상태로 부터 다른 상태로 변화를 일으키는 조건과 이들 동작상태의 그래프적 표현 즉 상태도이다.

특히 상태도는 상호연결 아아크(30,32,34,36)가 일련의 노우드(24,26,28)를 나타내고 있다. 각각의 노우드는 특정한 동작의 상태를 나타내고 각각의 연결 아아크는 특정상태의 상황에 변화를 야기시킬 수 있는 조건이나 천이 기능을 나타낸다.

특히, 제2a도의 상태도는 각각 "상승", "정지" 및 "하강"의 동작상태를 나타내는 노우드(24,26,28)를 갖고 있다. 상태에 영향을 미치는 조건은 노우드 사이의 아아크 콘넥터(30,32,34,36)이다. 각각의 아아크는 그 자신의 천이 조건의 세트인 원래의 지정상태를 형성한다. 아아크(32)는 스위치 조건과 동작(42)을 가진다 :

"UP"버튼이 온이고 "Down"버튼이 오프이면 엘리베이터(18)의 상태는 상승으로 간다. 아아크(30)는 스위치 조건 및 작용 콘넥터(38)을 가진다 :

"UP"버튼이 오프되고 "Down" 버튼이 온되면 엘리베이터실(18)의 상태는 정지로 간다.

나머지 조건과 동작은 제2a도로 부터 식별될 수 있다.

제2a도의 상태도를 나타내는 응용 프로그램은 다음과 같다.

"상승"

"UP" 모우터 온

"UP" 버튼이 오프되고 "Down" 버튼이 온이면, "정지"로 간다.

"정지"

브레이크온

"UP"버튼이 온이고 "Down"버튼이 오프이면, "상승"으로 간다.

"UP" 버튼이 오프이고 "Down" 버튼이 온이면, "하강"으로 간다.

"하강"

"Down" 모우터 온

"Down" 버튼이 오프 또는 "UP" 버튼이 온이면 "정지"로 간다.

상기 3블록의 문장은 프로그램 상태로 불리우고 각각의 불록은 엘리베이터(12)의 특정한 동작의 상태 및 상태도(제2a도)에서 특정한 노우드에 대응한다. 각각의 프로그램 상태는 상태 구절 문장인 "상승" "정지" 또는 "하강"을 구성되는데, 이는 한 프로그램 상태의 끝과 새로운 프로그램 상태의 시작을 제어기에 알린다. 상태 구절 문장은 아무것으로도 구성되지 않는, 동작을 야기할 수 있는 또는 현재 처리중인 또는 액티브 프로그램 상태로 부터 다른 프로그램 상태로 천이가 발생하도록 할수 있는 하나 이상의 복합 문장으로 구성되는 일련의 문장이 뒤따른다. 복합 문장은 조건부와 동작부로 구성된다.

조건부가 만족되면, 동작부는 실행된다. 동작부가 GOTO, GOSUB 또는 RETURN 문장을 포함하는 경우에는 새로운 프로그램 상태로의 천이가 발생하다. 동작부가 START 문장을 포함하면 새로운 프로그램 루프가 추가되는 새로운 액티브 상태로써 개시된다. 다르게 설명하면, 복합 문장은 프로그램 상태변화 또는 개시가 무엇이며 현재 액티브 동작의 상태중에 기계 또는 공정에 의해서 취해질 동작의 형식을 결정하게 된다. 모든 상기의 세개의 프로그램 상태는 프로그램 상태를 동일한 상태도에서 다른 프로그램 상태로 처리를 옮기게 하는 "GOTO"를 포함하는 복합 문장을 가진다.

특정한 동작의 상태와 관련된 모든 문장들을 단 하나의 연속적인 부분 코드의 세그먼트로 모음으로써, 이 시스템은 이들 문장만을 스캔하여 기계 또는 공정의 동작상태에 의해 요구되는 동작을 개시하고 특별한 세트의 조건이 하나의 새로운 동작상태를 개시하기 위하여 만족되었는가를 결정할 수 있다. 반면에, 상기한 드로몬드 시스템은 응용 프로그램에서 모든 문장을 평가하여 상태 액티비티를 변화할 것인가를 또는 동작을 실행할 것인가를 결정하고, 이 과정에서 많은 상태 변수를 평가해야 한다.

프로그램내의 구조상의 차이는 본 발명의 상태 변수를 평가할 필요성을 제거함으로써 훨신 더 효율적으로 동작하게 하는 것을 가능하게 한다. 제2b 및 c도는 프로그램 상태의 도면이다. 이 두도면에서 블록(48)은 프로그램 상태 "상승"에 대한 코드의 시퀀스를 의미하고, 블록(50)은 프로그램상태 "정지"에 대한 코드의 시퀀스 의미하며, 블록(52)은 프로그램 상태 "하강"에 대한 코드의 시퀀스를 나타낸다.

아아크(54,56,58,60)(제2a 및 c도)는 상태도(제2a도)의 아아크(30,32,34,36)에 해당한다. 아아크(54,56,58,60)은 응용 프로그램내의 액티브 한 흐름이 복합 문장에 의해서 어떻게 영향을 받을 수 있는가를 도시하고 있다.

제2b도의 아아크(58)는 하기의 복합 문장 :

""UP"버튼이 오프 또는 "Down"버튼이 온이며, "정지"로, "명령"의 조건부가 참이면, "상승" 프로그램 상태로 부터 "정지"프로그램 상태로의 전이(transition)바 발생한다."비슷하게 아아크(60)는 하기의 복합문장, ""UP" 버튼이 오프되고 "Down"버튼이 온이면, "하강"으로 명령"의 조건부가 참이면, "정지"프로그램 상태로 부터 "하강"프로그램 상태로의 전이가 발생한다.

프로그램 상태 "상승" "정지" 및 "하강" 사이의 연결은 논리적으로 프로그램 루프(46)를 생성한다.

프로그램 루프(46)은 엘리베이터(12)에 의해서 수행되는 동작의 시퀀스를 제어한다. 바람직한 실시로는 한 프로그램 루프는 어느 한 때에 단지 하나의 엑티브 프로그램 상태를 가질 수 있다. 이러한 방식으로 제어기는 타스크의 개별적인 계획의 순차적인 처리를 트레이스 할 수 있다. 제2b도내의 프로그램 루프(46)는 프로그램 실행과 디버깅에 관련된 알고리즘을 더 효율적으로 하고 시스템의 모호성을 감소시키기 위하여 한순간에 단지 하나의 액티비티 프로그램 상태를 갖는 특징을 나타내고 있다.

보다 복잡한 기계에 있어서, 단일 프로그램 루프는 그 기계 또는 공정의 특정한 독립된 서브파트의 제어만을 나타내게 된다. 통상 복수 프로그램 루프가 복잡한 기계 또는 공정의 여러개의 서브-파트를 독립적으로 제어하는데 필요로 된다.

제2d도는 복수개의 상태도(62,64,66)으로 표시되는 보다 복잡한 기계를 도시한다. 각각의 상태도는 하나의 프로그램 루프가 기계 또는 공정의 한 부분에 대한 순차적인 제어 계획을 묘사하는 것을 나타내고 있다. 본 발명은 한 기계의 가설적 3개의 서브-파트를 비동시적으로 제어하는 프로그램 루프를 진행시키는 도면에 에뮬레이트 한다(멀티플 타스킹라고도 칭함).

하나의 특정한 프로그램 루프는 나머지 프로그램 루프와 독립적으로 처리될 수 있고 또는 플레그와 같은 어떤 편리한 메커니즘이나, 다른 루프에서 액티브 상태의 값을 시험하는 "M 상태에서 N 루프인 경우"형식의 문장은 사용하는 다른 프로그램 루프와 핸드세이크하거나 동기할 수 있다. 이러한 제어기의 멀티 타스킹 능력은 프로그래머에게는 대체로 용이한 일이며 운영 체제와 언어는 이를 구현하는 간단한 수단을 제공하여 준다.

프로그램 루프내의 프로그램 상태의 실행을 용이하게 하기 위하여, 바람직한 실시예는 각각의 액티브 프로그램 루프에 대해 프로그램 루프-레코드를 제공한다.

제3a도에 있어서, 프로그램 루프-레코드(90)는 단순 변수를 보관하는 피일드(92,94)를 갖는다. 제1단순 변수(92)는 프로그램 루프의 식별자이다.

제2단순 변수(94)는 액티브 프로그램 상태의 식별자 또는 메로리에서 액티브 프로그램 상태의 시작 어드레스이다. 프로그램 상태의 어드레스 또는 식별자는 용이하게 다른 것으로 전환될 수 있다.

포인터(90)의 잔류부분(96)은 프로그램 루프에 대한 보다 덜 중요한 다른 상태 정보를 포함한다. 프로그램 루프 레코드(90)의 실제 목적은 특정한 프로그램 루프내에서 어느 프로그램 상태가 어느 한 시점에서 액티브인가를 추적하는 것이다. 특정한 프로그램 루프가 액티브되면, 프로그램 루프 레코드(90)는 그 루프와 관련이 있게 된다. 여러가지 프로그램 상태가 프로그램 루프내에서 액티브될때, 단순 변수(94)는 새로운 프로그램상태 어드레스 또는 식별자로써 오버라이트된다. 프로그램 루프 레코드(90)는 어떤 상태가 제2프로그램 루프에서 액티브인지를 결정하기 위해 제2프로그램 루프에게 문의 함으로써 핸드셰이크 하는 것을 가능하게 한다. 더우기, 프로그램 루프 레코드(9)는 프로그램머가 액티브 프로그램 상태를 디스플레이하거나 수정하도록 터미널(80)에 의해서 액세스될 수 있다.

바람직한 실시예에 있어서, 프로그램 루프 레코드는 모두 메모리(10A)(제1a도) 내에 저장된 제3b도의 타스크 테이블에 저장된다.

타스크 테이블을 주로 동시에 여러개의 프로그램 루프 모두를 처리하는 것을 기능하게 하는 기능을 한다. 프로그램 루프 레코드는 타스크 테이블내에 포장되어 모든 논-엠프티(non-empty) 레코드는 테이블의 시작에 있고 이들은 그들의 각각의 프로그램 루프 식별자(제3a도의 92)의 숫자 순으로 배열된다.

제3b도에 있어서, 타스크 테이블내의 제1프로그램 루프 레코드(100)는 가장 낮은 루프 식별자(예로 1)를 갖고 그래서 스캐닝은 프로그램 루프의 숫자 순으로 발생하여 각 프로그램 루프에서 액티브 상태만을 스켄 및 처리하고 상태 블록에서 나타나는 순서대로 각 액티브 상태에서 각 문장을 스캔하고 처리하기 때문에 프로그램 스텐중에 스텐될 첫번째의 것이다.

루프 레코드(102)는 테이블내에 두번째로 가장 낮은 루프 식별자를 갖고 이것은 두번째로 처리된다. 루프 레코드(104)는 이와 관련된 세번째로 가장 낮은 루프 식별자(3)를 갖고 이것은 세번째로 처리된다. 루프 레코드(106)는 다음으로 가장 낮은 식별자(34)를 갖고 이것은 네번째로 처리된다.

또한 타스크 테이블과 관련된 것은 액티브 프로그램 루프의 실행을 현재 제어하고 있는 프로그램 루프레코드를 가리키는 타스크 테이블 레지스터(112)(제3c도)이다. 타스크 테이블내의 프로그램 루프를 스켄하고 처리하기 위하여, 제어기는 타스크 테이블 레지스터(112) 속에 액티브 프로그램 루프 레코드(90)의 어드레스를 기입한다.

제어기가 레코드(100)과 관련된 프로그램 루프를 실행할때, 프로그램 루프(100)와 관련된 프로그램 상태내의 단지 한 블록의 문장만이 실행되거나 액티브된다. 그 다음에 제어기는 다음 프로그램 루프(2)를 처리하고 이와 관련된 한 프로그램 상태만 처리될 것이다. 제어기는 모든 액티브 프로그램 루프에 대하여 이 절차를 반복한다. 이 타스크 테이블 레지스터가 루프 식별자와 관련된 제로(0)를 갖는 프로그램 루프 레코드(108)(제4d도)를 가리킬때, 제어기는 프로그램 루프 레코드에 도달하였다는 경보를 받는다.

이것은 발생할때, 제어기의 운영 체제는 타스크 테이블 레지스터를 타스크 테이블의 상부로 다시 가리키게 하고 그 테이블내의 제1프로그램 루프의 다음 프로그램 상태를 실행한다. 이 절차는 터미날 인터럽트 등이 발생하지 않는다면, 끝이 없는 공정이다.

단지 몇개의 라인의 프로그램 코드가 각각의 프로그램 상태를 위해 처리되기 때문에, 제어기는 한 프로그램 루프에서 다음으로 매우 빨리 접프할 수 있다. 이런식으로, 제어기는 동시에 모든 복수 프로그램 루프 또는 타스크를 처리하는 것처럼 보인다.

프로그램 루프가 액티브되는 것을 보여주기 위하여, 제어기는 액티브 프로그램 루프에 프로그램 루프 레코드를 지정하게 되고 타스크 테이블 속으로 새로운 프로그램 루프 레코드(제3a도의 90)를 삽입하게 된다.

이 시스템은 새로운 프로그램 루프 식별자(제3a도의 92)의 수치를 평가하여 그 수치에 해당하는 타스크 테이블 내에 숫자 순으로 재위치에 프로그램 루프 포인터를 맞춘다. 예를들어, 수치가 34 보다 더 크다면, 새로운 포인터는 타스크 테이블(제3b도)에서 레코드(108)를 대체할 것이다.

그러나, 새로운 프로그램 루프 식별자가(3)과 (34) 사이에 있다면, 프로그램 루프 포인터(108)는 (106)에 있는 포인터와 교환되고 새로운 프로그램 루프 포인터가(106)에 삽입될 것이다. 타스크 테이블의 본 실시예는 타스크 테이블내에 최대로 31개의 프로그램 루프 포인터를 가질 수 있기 때문에 새로운 포인터를 위해 이용 가능한 공간이 있는지를 확실히 하기 위해 타스크 테이블의 내용이 평가되어야만 한다. 이 제어기 타스크 테이블이 용량에 도달하거나 타스크 테이블에서 오우버플로우 조건이 발생하면 프로그래머에게 알리게 된다.

제4도에 있어서, 트레이스 테이블(82)의 논리적 표현은 제어기(제1도)의 메모리부(10A)에 저장된다. 트레이스 테이블은 랩(wrap) 주변의 "무한 테이프" 저장 버퍼로서의 기능을 하도록 만들어진 메모리내의 선형 테이블이다. 트레이스 테이블(82)은 항공기 비행 레코더와 아주 유사하게 작동한다.

항공기 비행 레코더는 비행기가 "추락(crashes)"하기 직전에 비행기에 발생한 것의 "플레이백(playback)"을 제공한다. 마찬가지는 테이블은 조사를 요하는 사건직전에 기계 또는 공정상태에 발생하는 것을 기록한다. 다른 말로 설명하면, 플레이백은 그 시각직전에 제어에 의해서 어떤 결정이 내려졌는가를 정확히 알아 내는데 사용될 수 있다.

트레이스 테이블 레지스터(84)는 트레이스 테이블(84)내의 마지막으로 기록된 위치의 어드레스를 저장한다.

제4도는 트레이스 테이블(82)내에 채워질 최종 위치로서 레코드(79)를 가리키는 레지스터(84)를 보여준다.

이 트레이스 테이블이 (86)에 채워졌을때, 이 시스템은 새로운 데이타를 게속하여 저장하고 낡은 데이타를 오버라이트할 것이다. 다음은 유한상태 응용 프로그램을 치리하고 유한상태 응용 프로그램에서 예기치 않은 조건의 진단을 용이하게 하기 위한 바람직한 실시예의 상세한 설명이다.

제5도 내지 제13도는 프로그램 가능한 제어기와 함께 응용 프로그램의 처리를 제어하는 루틴을 나타내는 흐름도이다.

특히, 제5도에서, 루틴 시작 프로그램(START PROGRAM)은 여러가지 포인터와 프로그램 가능한 제어기의 테이블을 초기화한다.

제6도에 있어서, 루틴 제1오퍼레이터는 프로그램 상태의 제1문장을 평가한다.

제7도에서, p-코드 포인터 전진(ADBVANCE P-CODE POINTER)는 표준 응용 프로그램 포인터(p-코드 포인터)를 제어한다.

이 포인터는 제어기에 의해서 실행되고 있는 현재 문장의 메모리내의 어드레스를 가리킨다. 제8도의 타스크 테이블 레지스터 전진은 타스크 테이블 레지스터가 어느 레코드를 지시하는 가에 영향을 미친다.

제9도의 루우틴에 있어서, 다음 오퍼레이터는 프로그램 상태의 제1문장외의 모든 문장을 평가한다.

제10도의 고우투(GOTO)는 발생하는 프로그램 루프내에서 액티브 상태로 변화시킨다. 시작(START)는 상태의 변화를 개시하거나, 시작 문장에서 정하여준 루프내에 한 액티브 상태를 설정한다.

제12도의 고우서브(GOSUB)와 제13도의 리턴(RETURN)은 서브루틴 호출을 제공하고 상태 레벨에서 동작하는 리턴 기능을 제공한다.

제5도에는 시작 프로그램(START PROGRAM)을 위한 플로우 블록도가 도시되어 있다. 이 루틴은 프로그램 제어기를 초기화한다. 특히, 블록(122)에서, 제어기는 타스크 테이블(제4b도), 타스크 테이블 레지스터(루프 프린터(제4c도), 및 p-코드 포인터를 초기화한다.

타스크 테이블은 메모리에서 제1액티브 프로그램 루프를 가리키는 프로그램 루프로써 초기화 된다. 또한 프로그램 루프 레코드는 그 프로그램 루프내에서 제1프로그램 상태에 초기화된다.

p-코드 포인터는 제1액티브 프로그램 상태 즉 제1문장의 시작 어드레스로써 초기화된다. 시스템은 이제 제1액티브 루프를 처리할 준비가 되어 있다. 블록(124)에서, 시스템은 제1오퍼레이터를 호출하여 p-포인터에 의해서 가리켜진 제1문장을 평가한다.

제6도의 블록도는 루틴 제1오퍼레이터를 묘사한다. 블록(128)에서 제어기는 p-코드 포인터에 의해 가르켜진 문장의 형식을 분석한다.

만나게 되는 제1문장은 문장, "포즈" 문장, 또는 문장 서술형 문장이다.

형 문장은 프로그램 상태의 시작을 상징하는 프로그램 상태의 경계분리(delimiter)이다. 포즈 문장은 또한 그 자신의 프로그램 루프를 중지하지만 다른 액티브 프로그램 루프의 처리를 가능하게 한다.

상태 문장은 전 시스템이 기동하는 것을 중지하게 하고 프로그래머에게 제어기가 처리를 중단하였다는 것을 알리기 위하여 모니터로 복귀하게 한다.

상태 문장을(130)에서 만나면 제어기(132)에서 p-코드 포인터 전진 루틴에 입력되어 프로그램 상태내에서 p-코드 포인터 전진으로써 다음 문장 어드레스를 가리킨다. 프로그램 상태내에서 만나는 문장이(134)의 포즈상태 문장인 경우에는 시스템은 (136)에서 타스크 테이블 레지스터 전진 루틴에 들어가서 처리를 다음 액티브 프로그램 루프까지 전진시킨다.

만나는 문장이 상태형이면,(138)에서 고우투 모니터(GO TO MONITOR) 루틴에 들어간 고우투 모니터는 터미널상에 메세지를 위치시켜 문장이 도달되고 프로그램 코드의 실행이 정지되었다는 것을 프로그램 가능한 제어기의 사용자에게 알린다.

제7도에는 p-코드 포인터 전진 루틴의 상세한 블록도가 도시되어 있다. 블록(142)에서, p-코드 포인터는 액티브 프로그램 상태에서 다음 문장으로 증가된다. 제어기는 (144)에서 다음 오퍼레이터 루틴에 들어감으로써 다음 문장을 처리한다. 포즈상태 문장이 제1오퍼레이타(제6도)에 의해서 만나면, 다스크 테이블 레지스터 전진 루우틴에 들어간다.

이 루우틴의 목적은 현재의 루프를 무시하고 다음 프로그램 루프의 처리로 전환하는 것이다. 제8도는 이 루틴의 상세한 블록도를 나타낸다.

블록(148)에서, 타스크 테이블 레지스터는 그 타스크 테이블에서 다음 프로그램 루프 포인터의 어드레스로 전진된다.

블록(150)에서 제1오퍼레이터 루틴에 들어가서 타스크 테이블내에서 다음 프로그램루프의 액티브 프로그램 루프를 처리한다.

상태형 문장은 (128)에서 만나면 (제6도), 제어기 p-코드 포인터 전진(142)(제8도) 루틴으로 진행한다.

상기 언급한 바와같이, 이 루틴은 p-코드 포인터를 프로그램 상태내의 다음 문장으로 전진시키고 나서 (144)에서 다음 오퍼레이터 루틴에 들어간다. 프로그램 상태의 제1문장은 항상 제1오퍼레이터에 의해서 평가된다.

제9도는 다음 오퍼레이터 루틴의 개략적인 블록도이다. 이 루틴의 목적은 제1문장외의 프로그램 상태내의 단순 문장형태를 평가하는 것이다.

블록(154)에서, 제어기는 p-코드 포인터에 의해서 가르켜지는 다음 명령을 읽는다. 만나는 다음 문장이 상태문장, 포즈상태문장, 또는 브레이크상태 문장인 경우에는 상태 블록의 끝에 도달되었기 때문에 제어기는 (158)에서 타스크 테이블 레지스터 전진 루틴(제9도)에 들어간다.

만나는 문장이 상기 셋중의 하나가 아닌 경우에는 제어기는 그 문장이 (160)에서 고우터(GOTO) 문장인지를 평가한다.

그 문장이 고우투 문장이면, (162)에서 고우투 루틴에 들어간다. 이 루틴은 보다 상세히 하기에서 논의된다.

문장이 고우투 문장이 아닌 경우에는, 제어기는 블록(164)에 진행하여 그 문장이 시작 문장인지를 결정한다.

이 문장이 시작문장이면, 제어기는(166)에서 시작루틴에 들어간다.

이 루틴에 대해서는 간단히 설명한다.

이 문장이 시작문장이 아닌 경우에는 제어기는 블록(168)에 진행하여 그 문장이 고우서브(GOSUB) 문장인지를 결정한다. 그것이 고우서브 문장이면, 제어기는 (170)에서 고우서브 루틴에 들어간다.

이 문장이 고우서브 문장이 아닌 경우에는 제어기는 그 문장이 (172)에서 리턴 문장인지를 결정한다. 그것이 리턴문장이면, 제어기는 (174)에서 리턴 루틴에 들어간다.

문장이 GOTO, START, GOSUB 또는 RETURN형이 아니면, 제어기는 블록(174)에 진행하여 문장을 정상제어 문장으로 평가한다.

정상 제어문장은 프로그램 상태의 상황에 영향을 미치지 않으며, 다른 말로 말하면, 프로그램 상태는 상태가 통용시에 또는 다른 프로그램 루프에서 액티브하게 변화하면서 처리를 계속한다.

반면에, GOTO, STAT, GOSB 및 RETURN 문의 형식은 모두 프로그램 상태의 상황 및/ 또는 대응 액티브 프로그램 루프에 강력하게 영향을 미친다. 전술한 바와 같이 이러한 형식의 문장들은 일집합의 조건이 만족되면 특정한 프로그램 상태의 상황에 영향을 미친다.

제어기가 (176)에서 정상 제어문(제9도)을 일단 평가하면, 그것은 P-코드 포인터 전진 루틴에 들어가서 액티브 프로그램 상태에서 다음 문장을 평가한다.

제10도는 고우투(GOTO)라 불리는 루틴의 블록도이다. 고우투 루틴은 특정한 집합의 조건들이 만족되는지 결정하고 그렇다면 고우투 문장내에 지정된 새로운 값에 현재 처리되고 있는 루프에서 동작상태를 변화시켜 타스크 테이블내에서 다음 프로그램 루프로 처리를 진행시킨다.

고우투(GOTO)는 기본적인 상태변화 기능을 제공하여 참인 액티브 상태의 천이 조건을 새로이 특정된 상태가 현재의 액티브 상태 대신에 액티브 되도록 한다. 고우투 문장이 한 상태에서 실시되면, 어떤 문장도 그 상태에서 처리되지 않는다.

제10도의 블록(182)에서 제어기는 복합 고우투 문장의 조건부를 평가로 부터 결과되는 조건 플래그 상황을 평가한다.

복합 고우투 문장내의 조건의 집합이 만족되지 못하면, 제어기는 (184)에서 P-코드 포인터 전진 루틴에 들어간다.

조건이 만족되면 제어기는 (186)에서 히스토리 기억(STORE HISTORY) 서브루틴을 호출 한다. 히스토리 기억은 "결정포인트" 어드레스와 프로그램 루프 식별자를 처리되고 있는 현재 루프의 트레이스 테이블(제3도) 속에 저장한다.

결정포인트는 제어기가 고우투 문장을 포함한 복합 문장의 조건부가 옳다는 것을 알게된 프로그램내의 단순문장의 어드레스(23-23)이다.

블록(118)에서, 타스크 테이블내의 현재 프로그램 루프 레코드는 업데이트되어 단순 변수(94)(제3a도)는 새로운 프로그램 상태 어드레스를 가리킨다. 블록(190)에서 타스크 테이블 레지스터 전진이 호출되어 타스크 테이블 레지스터를 업데이트하고 그래서 그것은 타스크 테이블내의 다음 프로그램 루프 포인터를 가리킨다.

제11도는 시작(START) 서부루틴의 블록도이다. 시작의 목적은 시작 문장내에 특정된 상태에서 어떤 다른 프로그램 루프의 처리를 개시하는 것이다. 비교하면, 고우투 서브루틴은 단지 현재의 프로그램 루우틴내에 저장된 다음 상태까지 처리를 진행할 수 있다.

제11도의 블록(194)에서 복합 시작문자의 조건부의 평가로 부터 결과되는 조건 플래크 상황을 평가한다. 조건 플래그가 거짓이면, 제어기는 (196)에서 p-코드 포인터 전진 루틴에 들어간다. 조건이 참이면, 제어기는 블록(198)에 진행하여 히스토리 기억 서브루친을 처리한다. 히스토리 기억은 현루프에 대해서 결정포인트와 프로그램 루프 식별자의 어드레스를 세이브한다. 블록(200)에서 제어기는 특정된 프로그램 루프가 현재 액티브 상태로 되어 타스크 테이블에 저장되어 있는지의 여부를 결정한다.

프로그램 루프가 이미 액티브 상태로 되었다면, 블록(202)에서 제어장치는 프로그램 루프 포인터(제4a도)의 단순 변수에 현재 저장된 어드레스를 액티브될 신프로그램 상태의 어드레스로써 오버라이트한다.

그러나 프로그램 루프가 현재 액티브 상태가 아니면, 시스템은 (204)에 있는 타스크 테이블내로 신프로그램 루프 레코드를 슬로트할 것이다.

새로운 프로그램 루프 레코드는 프로그램 루프식별자의 수치를 통해서 타스크 테이블에서 숫자순서로 위치될 것이다. 블록(206)에서, 새로운 프로그램 상태의 어드레스는 프로그램 루프 레코드로 기입될 것이다. 블록(202)에서, 제어장치는 p-코드 포인터 전진 루틴으로 들어가서 다음 문으로 진행할 것이다.

제12도는 고우서브(GOSUB)에 대한 블록도이다. 고우서브는 액티브 프로그램 루프의 처리에 영향을 준다. 이 루틴은 신상태가 현 프로그램 루프에서 액티브되는 것과 신상황(status) 정보가 세이브되는 것을 가능하게 하므로 대응하는 리턴문은 고우서브문에 후속하는 다음 문에서 고우서브 문을 포함하는 상태로 제어를 리턴시킬 수 있다. 이것은 상태 레베에서 서브루틴 후출 및 리턴 기능을 제공한다.

제10도 (평가로 부터 유래한 조건 플래그상황)의 블록(210)을 참조하면, 복합 고우서브 문장의 조건부(의 평가로 부터 결과되는 조건 플래그 상황)이 평가된다. 조건이 만족되지 않았다면, 제어기는 (214)에서 p-코드 포인터 전진에 들어갈 것이다. 그러나 조건문이 만족되면, 제어기는 (216)에서 히스토리 기억 서브루틴을 호출할 것이다. 이 서브루틴은 트레이스 테이블에 있는 결정포인트와 프로그램 루프 식별자 모두를 세이브 할 것이다.

블록(218)에서, 제어기는 대응하는 리턴문이 사용하기 위해서 p-코드 포인터에 기억된 현(PRESENT) 어드레서, 현재 액티브 프로그램 상태의 어드레스, 및 다른 필요한 상황정보를 메모리에 일시적으로 세이브할 것이다. 블록(220)에서, 신프로그램 상태의 어드레스는 프로그램 루프 레코드(90)(제4a도)의 단순변수(94)로 기입될 것이고, 이 어드레스는 또한 p-코드 포인터에 저장될 것이다. 제어기는 (220)에서 제1오퍼레이터 루틴에 들어감으로써 신프로그램 상태에서 액티브 동작을 시작할 것이다.

제13도는 리턴 루틴의 상세한 개략 블록도이다. 이 리턴문의 목적은 제어기가 고우서브문을 포함하는 프로그램 상태로 복귀하도록 하는 것이다. 환언하면, 고우서브 루틴(GOSUBROUTINE)(제12도)에 의해 호출된 특정된 프로그램 상태 또는 상태도의 실행이 완료되면, 제어기는 고우서브가 실행되었을때 액티브이었던 구 프로그램 상태로 제어를 복귀시킬 것이다. 이것은 고우서브 루틴에 의해 기억된 상황치(status values)가 복원될 것을 요구한다.

제13도를 참조하면, 블록(224)에서, 제어기는 복합 리턴문의 조건부의 평가로 부터 결과되는 조건 플래그 상황을 평가한다. 조건이 만족되지 않았다면, 제어기는 블록(226)에서 p-코드 포인터 전진 루틴에 들어 갈것이다.

그러나, 조건이 만족되면, 제어기는 블록(222)에서 히스토리 기억을 호출할 것이다. 이 루틴은 그것이 발생된 결정포인트 및 루프식별자의 어드레스를 세이브한다. 블록(230)에서, 제어장치는 고우서브의 블록(218)에서 세이브된 값들을 복원(재저장) 할것이다(제12도를 보시오).

블록(232)에서 p-코드 포인터 전진에 들어가서 구 프로그램 상태에서 처리를 계속한다.

제14, 15, 16, 17 및 18도는 응용 프로그램의 디버깅을 용이하게 하는 프로그램의 블록도이다. 특히, 제14도는 트레이스테이블(제4도)을 정보로써 업데이팅(갱신)하는 서브루틴이고, 고우트, 스타트, 고우서브 및 리턴 루틴에 의해 후출되는 히스터리 기억의 블록도이다.

나머지 도면은 근본적으로 프로그래머가 자신의 명령으로써 트레이스테이블, 타스크테이블 또는 프로그램 상태 자체에 기억된 정보를 관찰할 수 있게 하는 서브루틴 유틸리티의 다이아그램이다.

특히, 제15도는 터미날(80)에서 트레이스테이블에 기억된 정보를 디스플레이하는 히스토리 표시(DISPLAY HISTORY)라 불리우는 서브루틴의 블록도이다.

제16 및 17도는 각각 라인표시(DISPLAY LINE) 및 프로그램 상태표시(DISPLAY PROFRAM STATE) 서브루틴이다.

이들 서브루틴은 특정 프로그램 상태의 문을 표시하는 것을 담당하고 예를들어 제어기가 상태 변화를 초래한 고우투, 고우서브, 스타트 또는 리턴 문을 실행하는 것을 결정하는 결정포인트가 프로그램 상태내에서 어디에 있었던가를 예시한다.

제18도 및 19도는 각각 타스크테이블에 기억된 액티브 프로그램 상태 및 관련 액티브 프로그램 루프를 표시하는 루프표시 및 발결된 루프(DISPLY LOOP AND FOUND LOOP)이다. 히스토리 기억은 프로그램 상태의 상황이 변화할 때마다 호출된다. 히스토리 기억은 고우투(제10도의 186), 고우서브(제12도의 216), 시작(제11도의 198) 및 리턴(제13도의 228) 서브루틴에서 호출된다.

상술한 바와같이 히스토리 기억은 처리되고 있는 프로그램 루프의 루프식별자 및 액티브 프로그램 상태에 있어서의 결정포인트의 어드레스를 트레이스 테이블로 필수적으로 세이브한다.

제14도의 블록(236)에서, 트레이스 테이블 포인터(84)(제3도)에 기억된 어드레스가 평가된다. 트레이스 테이블 포인터에 의해 가리켜지는 어드레스가 트레이스테이블의 끝에 있으면, 트레이스테이블 포인터는 블록(240)에서 트레이스테이블 처음에 자동적으로 설정될 것이다.

이 단계는 트레이스테이블이 무한 루프인 것처럼 보이게 한다.

이 포인터가 트레이스 테이블의 끝에 있든지 없든지, 결정포인트의 어드레스는 트레이스테이블 포인터에 의해 가리켜진 레코드로 기입될 것이다.

그 밖에 블록(244)에서 제어기는 또한 처리되고 있는 루프의 프로그램 루프 식별자를 레코드로 세이브 할것이다.

블록(248)에서, 제어기는 호출루틴으로 복귀할 것이다.

히스토리표시 서브루틴은 프로그래머가 응용 프로그램이 처리되는 동안에 발생된 프로그램 상태의 히스토리를 평가할 수 있게 한다.

프로그래머는 트레이스 테이블에 의해 기억된 것의 표시를 보기를 원할때, 이 프로그램을 시작한다.

이 서브-루틴은 이축 테이블(Two axis table)에 있는 트레이스테이블의 내용을 표시한다. 수평축은 트레이스테이블에서 엔트리를 만든 고우투, 고우서브, 리턴 또는 시작문에 대응하는 프로그램상태 및 프로그램 루프식별자를 제시한다. 수직축은 가장 최신 상태를 상부에 두어 프로그램 상태 및 프로그램 루프의 순차배열을 나타낸다. 히스토리 표시는 터미날(80)(제1도)에서 사용자에 의해 직접 개시되는 서브루틴이다. 히스토리 표시의 전형적인 프린트-아웃은 다음과 같다.

DISPLAY HISTORY

ACTIVE ACTIVE

PROGRAM PROGRAM LOOPS

STATES 1 5 10 15 20

; 히스토리 테이블을 표시하시오.

; 프로그램 상태 및 루프식별자

0 2 2 ; 라인 0은 탈출상태 2(루프 1)을 나타낸다.

1 3 1 ; 라인 1은 탈출상태 3(루프 1)을 나타낸다.

2 2 1 ; 라인 2은 탈출상태 2를 나타낸다.

3 3 3 ; 라인 3은 탈출상태 3을 나타낸다.

4 2 1 ; 라인 4는 탈출상태 2를 나타낸다.

5 200 2 ; 라인 5는 탈출상태 200(루프 2)를 나타낸다.

6 1 1 ; 라인 6은 탈출상태 1을 나타낸다.

7 1 1 ; 라인 7은 시작된 루프 2(oldest)를 나타낸다.

8종료 ; 트레이스테이블에는 더 이상 엔트리가 없다.

명령 DISPLAY HISTORY(히스토리 표시)가 스크린 상에 제일 처음 나타나게 되는 것을 주목한다.

둘째로 ACTIVE PROGRAM STATES("액티브 프로그램 상태") 및 ACTIVE PROGRAM LOOPS("액티브 프로그램 루프")라는 단어가 상부에 있다. 이들 문밑의 두 열은 각가 액티브 프로그램 상태 및 액티브 프로그램 루프를 각각 가리킨다. 짧은 주석은 각 라인을 설명하기 위해 오른쪽에 있는 이사양(specification)에 마련된다. 마지막으로 상태 변경을 일으킨 프로그램 상태는 라인 50에 나타나게 된다. 프로그램 루프(2)의 프로그램 상태(2)는 변경을 하는 마지막 것이다. 변경을 일으키는 제1프로그램 상태 및 그것이 상주하는 프로그램 루프는 라인 7상에 나타나게 된다. 라인8은 트레이스테이블의 종료를 나타낸다. 응용 프로그램에서 액티브의 예상된 흐름을 변경하는 예기치 않은 조건이 발생하면 프로그래머는 처리과정중에 발생된 프로그램상태의 시퀀스를 봄으로써 예기치 않은 조건이 어느 프로그램 상태에서 생겼는가를 쉽게 좁힐 수 있다. 예를들어 프로그램 상태(3)은 응용 프로그램에 있어서 루프 1(표의 라인 3)에서 발생되지 않았어야 한다고 가정한다. 예기치 않은 조건이 프로그램 상태(2)의 상황을 프로그램상태(3)으로 변경시키는 루프(1)의 전 상태로 프로그램상태(2)에서 발생시켰음에 틀림없다. 프로그래머는 프로그램상태(2) 및 라인표시(제16도)를 호출하여 프로그램상태(2)를 프로그램 상태(3)로 변경시킨 조건을 보다 면밀히 분석할 수 있다. 이 프로그램은 간략하게 기술된 것이다.

제15도는 히스토리 표시를 참조하면, 블록(252)에서, 제어기는 상술한 것처럼 스크린의 상부에 나타내는 헤더(header)를 인쇄한다. 이어서, 블록(254)에서, 트레이스테이블의 복사 및 트레이스테이블 포인터의 복사가 버퍼내로 기억된다. 트레이스테이블 및 트레이스테이블 포인터를 버퍼에 위치 시킴으로써, 히스토리 표시에 대한 요구가 있을때 트레이스테이블에 기억된 것에 관한 스냅 샷(snap shot)이 얻어지며, 주 트레이스테이블의 업데이팅이 계속 허용되는 동안 필요한 동안 만큼 변경되지 않은채 남아 있는다. 이 단계가 있는 이유는 트레이스테이블이 다이나믹하게 변경하는 표이고 요청이 되는 때에 표의 상황이 분석의 목적으로 요구되지만 이 표는 지속적으로 업데이팅되고 있는 것이다. 블럭(256)에서 시스템은 기억된 최종 레코드의 트레이스테이블 포인터 에 기억된 어드레스를 얻을 것이다. 블록(258)에서, 제어기는 이 어드레스를 평가하여 버퍼가 비어 있는지의 여부를 결정한다. 버퍼가 비어 있으면, 종료문이 인쇄되고 제어기는 블록(260)에서 최초의 처리로 복귀한다. 버퍼가 비어 있지 않으면, 트레이스테이블을 평가하여, 그것이 블록(262)에서 버퍼의 끝을 가리키는지 여부를 결정한다. 포인터가 버퍼의 끝에 있으면, 트레이스테이블 포인터는 블록(164)의 버퍼의 처음에 세트된다. 이와같은 방법으로 제어기는 트레이스테이블이 무한 루프인 것처럼 트레이스테이블의 내용을 처리한다. 트레이스테이블 포인터가 버퍼의 끝에 있는지 없는지에 관계없이, 루프 식별자 및 상태 어드레스는 블록(266)에서 버퍼로 부터 얻어진다. 결정 포인트 어드레스는 프로그램 상태의 상태 구절문에 앞서 기억된 프로그램 상태번호를 위치시키는데 있어서 시작점으로서 사용될 것이다. 블록(268)에서, 프로그램 상태번호 및 프로그램 루프식별 자들은 상술한 것처럼 그것들의 각각의 열에 인쇄될 것이다. 블록(270)에서, 트레이스테이블 포인터는 버퍼에서 다음 레코드로 증분되고, 루틴은 블록(258)에서 처리를 계속할 것이다. 모든 프로그램상태, 트레이스테이블에 기억된 대응하는 프로그램 루프가 인쇄될때까지 프로그램은 루프(271)을 반복할 것이다.

상기 예에 있어서, 프로그래머는 프로그램상태(3)가 발생하지 않았어야 한다는 것을 안다. 그는 또한 히스토리 표시의 라인 4상에서 프로그램상태(2)동안에 예기치 않은 조건이 발생된 것을 안다. 프로그래머는 라인표시 서브루틴을 호출하여서 프로그램상태(2)에서 발생한 것을 보다 면밀하게 분석할 수 있고 무엇이 프로그램상태를 프로그램상태 (3)로 변경되게 하였는가를 정확히 결정할 수 있다. 라인표시는 프로그램상태의 문의 리스팅을 발생하고 프로그램상태의 상황을 변경시키는 결정이 행해지는 프로그램상태내의 상태를 지시한다.

제16도를 참조하면, 라인표시 서브루틴에 대한 상세한 블록도가 도시되어 있다. 이 프로그램은 터미날(80)(제1도)로 부터 호출을 통해 프로그래머에 의해 직접 개시된다. 블록(274)에서, 프로그래머는 그가 확장(expand)하기를 원하는 히스토리 표시에 대한 프린트 아웃의 라인을 지정할 것이다. 예컨대 그는 라인 4에서 라인 3까지 발생된 것에 관심을 갖고 있기 때문에, 프로그래머는 라인표시를 통해서 라인 4를 확장할 것이다. 블록(274)에서 히스토리 표시의 원하는 라인 숫자는 변수 "라인계수(Line Count)"와 동일하게 설정된다. 블록(276)에서, 제어기는 선택된 라인번호 2번호의 유효한 범위내에 취하여지는 지의 여부를 판단할 것이다. 유효범위내에서 취해지지 않으면, 제어기는 블록(278)에서의 그것의 정상처리로 리턴 할 것이다. 라인숫자가 유효한 범위내에 있다고 가정하면, 라인 7에 대한 데이타를 포함하는 트레이스테이블에 있는 최종 데이타 엔트리는 블록(280)에서 트레이스 테이블 포인터에 의해 포인트될 것이다. 다음에 트레이스테이블 포인터는 블록(290)에서 하나씩 증분된다. 블록(292)에서, 제어기는 트레이스테이블 포인터가 트레이스테이블 버터의 끝을 포인트하는지의 여부를 결정할 것이다. 그렇다면, 트레이스테이블 포인터는 블록(292)에서 트레이스테이블의 처음에 세트될 것이다. 트레이스테이블 포인터가 버퍼의 끝을 포인트하거나 또는 않거나에 관계없이, 제어기는 블록(294)에서 그것이 제로인지의 여부를 판단하기 위해서 "라인계수"를 평가할 것이다. "라인계수"가 제로와 같다면, 원하는 프로그램상태는 커버되지 않았으며, 블록(296)에서 프로그램상태 표시에 들어갈 것이다.

"라인계수"가 제로와 같지 않다면, "라인계수"는 하나씩 감소되고 트레이스테이블 포인터는 블록(290)에서 하나씩 증분된다. 루프(301)은 "라인계수"가 블록(296)에서 제로와 같아질때까지 반복되고, 지정된 라인이 발견된다.

제17도는 프로그램 상태표시 루틴의 상세한 블록도이다. 블록(304)에서, 제어기는 트레이스테이블 포인터에 의해 가리켜지는 레코드가 비었는지의 여부를 판단할 것이다. 레코드가 비어있으면, 시스템은 터미날(80)에서 요구된 라인이 타당하지 않다는 문을 인쇄하고 (306)에서 정상처리로 복귀할 것이다. 레코드가 비어있지 않다고 가정하면, 제어기는 트레이스테이블로 부터 결정 포인트의 어드레스를 추출할 것이고 (308)에서 결정 포인트를 포함하고 프로그램 상태에 대한 시작 어드레스를 결정할 것이다. 블록(310)에서, 제어기는 프로그램 상태의 한 단순문에 대한 택수트를 인쇄할 것이다. 블록(312)에서 제어기는 프린트된 문의 어드레스를 트레이스테이블에 기억된 결정 포인트 어드레스를 비교하여 그것이 프로그램의 결정 포인트에 도달했는지의 여부를 알아 보기 위해서 검사할 것이다. 결정 포인트에 도달되면"** 결정 포인트(DECISION POINT)**"상태가 블록(314)에서 인쇄될 것이다. 제어기는 블록(316)에서 프로그램 상태의 다음 문으로 갈것이다. 블록(318)에서, 제어기는 다음 문이 상태구절문 ; 상태문 ; 포즈상태문 또는 블레이크 상태문 인지의 여부를 판단할 것이다. 만일 이들 3문중의 어느 하나를 만나게 되면 제어기는 상태블록의 끝이 도달되었기 때문에 블록(320)에서 정상처리로 복귀할 것이다. 만일 이들 문의 어느것도 만나지 않으면, 처리단계는 프로그램 상태의 모든 문이 인쇄될때까지 루프(322)를 통해 계속될 것이다.

제18도는 루프표시(DISPLAY LOOP)의 블록도이다. 루프표시는 타스크 테이블의 내용을 표시하기 위한 서브루틴이다. 이하의 전형적인 화면표시를 참조하면 루프 식별자는 횡측에 나타나며 각각의 프로그램 루프내에 있는 액티브 프로그램은 프로그램 루프 식별자 각각의 아래에 수직으로 나타난다. 다음은 루프표시를 위한 출력의 전형적인 화면표시이다.

LOOP.

Program Loop (프로그램 루프)

Identifiers (식별자) 1 2 3 4 5 … 30 31

Program State(프로그램상태)

Identifiers (식별자) 201 19 1

제18도의 블록(324)에서, 제어기는 위에서 보여준 바와같이 화면표시의 제1라인에서 보이는 것처럼 루프 식별자를 인쇄하도록 명령받는다. 블록(326)은 타스크 테이블 레지스터를 타스크 테이블에 있는 제1프로그램 루프 프린터에 설정한다. "루프계수"라고 불리우는 변수는 블록(328)에서 0이 되도록 세트된다 "루프계수"는 블록(330)에서 하나씩 증가한다. 제어기는 "루프계수"가 타스크 테이블에 기억될 수 있는 프로그램 루프의 최대치에 1을 더한 것과 동일한가를 결정한다. 만일 이 조건이 참이면 제어기는 블록(334)에서 원래의 처리과정으로 리턴한다. 만일 루프계수가 프로그램 루프의 최대수 더하기 1과 같지 않으면, 제어기는 관련 타스크 테이블 레코드로 부터 루프 식별자를 취하게 된다. 블록(338)에서 루프 식별자는 0과 같은가를 결정하기 위하여 검사된다. 만일 프로그램 루프 식별자가 0과 같으면 시스템은 블록(340)에서 정상처리 과정으로 리턴하고 루프식별자가 "루프계수"와 동일하면 서브루틴의 발견된 루프(LOOP FOUND)가 블록(344)에서 호출된다. 만일 프로그램 루프 식별자가 "루프계수"와 동일하지 아니하면 제어기는 블록(348)에서 다음 루프 위치로 스크린을 가로질러서 탭(tab) 할 것이다. "루프계수"는 블록(350)에서 하나씩 증가하며 블록(328) 다음의 블록은 더 이상의 액티브 프로그램 루프가 타스크 테이블에 없을 때까지 반복한다.

제19도는 발견된 루프(FOUND LOOP)의 서브루틴에 대한 상세 블록도이다. 블록(354)에서 프로그램 포인터내에 저장된 액티브 프로그램 상태의 시작 어드레스는 액세스된다. 프로그램 상태 번호는 프로그램 상태내의 상태 구절문에 미리 저장된 값에서 부터 취하여진다. 블록(356)에서 타스크 테이블 포인터는 다음 프로그램 루프 포인터에서 증가하고 제어기는 제18도의 (364)에서 루프표시 루틴으로 리턴한다.

본 발명은 예시적인 바람직한 실시예로서 설명되어지지만 거기에만 한정되는 것은 아니다. 당해 기술분야의 기술자는 본 발명의 본질적인 정신이나 범위에서 벗어나지 아니하면서 다수의 추가적인 개선이 이루어질 수 있는 것을 알수 있다. 예를들면, 다른 많은 소프트웨어 기술과 다른 많은 소프트웨어 언어가 개시된 발명을 구현하는데 적합할 것이다. 그러나 본 발명의 실제적인 응용의 설명에 있어서, 본 발명을 유효하게 하는 것이 효율적이며 해석기는 의사코드(P code) 또는 중간코드를 수행하기 위하여 사용된다. 해석기는 응용 프로그램이 장치 또는 공정의 일부의 동작을 정하는 하나 또는 그 이상의 상태도의 형태로서 본질적으로 작성될 수 있게 하며, 이로써 어떤 개별적인 상태라고 유한시간 주기동안 장치 또는 공정으로 전송될 출력신호와 다른 데이타를 정한다.

이하의 해석기는 RCA 1802 마이크로 프로세서를 사용하고, 250 A.D. Inc.의 크로스어셈블러를 사용하여 어셈블된다. 해석기는 다음 사항이 있는 응용 프로그램을 실행하는데 사용된다.

1) 타스크 테이블, 즉, 각 루프에서 액티브 상태를 나타내고 루프변수를 포함하는 테이블,

2) 표시된 경우, 프로그램 실행에서의 상태변화가 트레이스되는 것을 가능하게 하는 트레이스 테이블.

해석기는 다음과 같이 설명된다 :

이하와 같은 COSINT를 위해 레지스터가 할당된다.

; R0 사용안함

; R1 인터럽트

; R2 D 스택 ptr

; R3 프로그램 계수기

; R4 호출명령 ptr

; R5 리턴명령 ptr

; R6 호출용 링크

; R7 POP 명령 ptr

; R8 Mocro 호출 ptr

; R9 리턴 어드레스 스택 ptr

; RF P 코드에 위치(points)

; RE 타스크 테이블에 위치

; RD 데이타 페이지에 위치

; RC 결정포인트 어드레스

; RB 트레이스 테이블에 위치

; RA 데이타 페이지에 위치

; X RF에 정상적으로 세트됨

; DF 조건 플래그로서 사용됨

; X, DF 상기 특정의 것과 다른 액션에 의해 영향을 받을 경우, 정상값을 보존하기 위하여 보호하여야 함.

상기한 해석기 코드(interpriter code)를 사용함으로서, 응용 프로그램 코드가 실행된다.

본 발명은 다음 사항을 실행가능하게 한다.

1. 프로그램내에서 "트랩(traps)" 혹은 "브레이크 포인트" 혹은 "홀트(halts)를 세트시킬 수 있고, 모니터로 부터 프로그램을 실행, 혹은 멈출 수 있을 것.

유한한 상태 형태의 언어로 쓰여진 제어 프로그램은 모니터 프로그램으로 부터 실행 또는 멈추어질 수 있다. 제어 프로그램 또는 그것의 부분(부분들)은, 제어 프로그램 자체내의 명령에 의해서 혹은 멈추어질 수 있다. 다음 보기의 이러한 기능을 수행하는 명령들로는 : 포즈상태(PAUSE STATE)제어가 이루어져 특수한 상태로 될때 혹은 홀트에 대하여 특수한 루프를 야기시킨다. 브레이크상태(BREAK STATE)제어가 이루어져 특수한 상태로 될때 전체 프로그램을 실행중지시키고, "온라인"혹은 "오프라인"모우드중의 하나의 모우드로 모니터로 돌려 보낸다.

홀드(HLAT) 조건명령으로서 그것후에 모든 명령으로 하여금 무시될 수 있는 상태로 한다.

2. 선택적으로 혹은 딴 방법으로 프로그램의 상태변경의 히스토리 상태를 기록할 수 있고 이것들을 나타낼 수 있을것 : 프로그램은 히스토리의 기억단계내에 있는 것으로 한다 :

상태를 변경하는 결정에 영향을 미칠 수 있는 각각의 명령의 실행동안(천이 기능의 어떠한 부분), 일시적인 기록이 프로그램내의 위치에 보존된다. 그러한 때에 천이 기능이 참이되고 제어가 이루어져 다른 상태로 되고, 일시적인 정보 및 특수 루프를 확인하는 정보는 히스토리 변경 테이블로 옮겨간다.(TT트레이스 테이블)

이러한 예가 해석기 코드에서 MORE, IIFOG 및 STOREHIST에 도시되어 진다.

3. 히스토리 변경 및 변경을 야기시키는 작용을 나타냄 :

이것은 인쇄되거나 편리한 형태로 나타나는 트레이스 테이블 혹은 타스크 테이블의 내용만을 단순하게 요구한다. 하기의 예들은 그러한 세가지 방법으로 나타내고 있다.

첫째 방법은 타스크 테이블로 부터 요구되는 정보를 유도함으로서 모든 액티브 루프내에 있는 현재 액티브 상태의 식별자를 나타내는 것이다.

둘째 방법은 트레이스 테이블의 내용을 2축 테이블로서 나타내는 것이다. 수직축이 시간변화의 순서를 나타내는 반면, 수평축은 변경이 발생하는 루프를 나타내는 것이다.

셋째 방법은 둘째 방법에 선택된 테이블의 라인중 어느 하나에서 발생되는 변경상태와 그 변경에 의한 경우 또는 경우들이 프로그램이 관련부분을 리스팅하고 그 리스팅내에서 상태변경에 대한 결정이 종료되는 포인트를 지시하는 것을 표시한다.

[실시예 1]

다음의 목록은 단지 설명을 위한 것이지 본 발명의 한계를 정하는 것으로서 해석하지 말것을 명확히 이해하여야 한다.

상기 프로그램에서 발생된 코드는 모니터의 감시에 따른 멀티-타스킹 제어프로그램 해석기에 의해 해석된다.

좌측열은 우측의 데이타가 제어기 메모리내에 저장되어지는 메모리 주소를 나타내고 있다. 다음의 코드를 P-코드(Program Code)라고 부르기로 한다.(명확성을 더하기 위하여, 프로그램은 상관 데이타에 가까운 주석으로서 반복된다.)

다음의 단락은 고급언어로 기록된 프로그램이 어떻게 구성하는가를 보여주고 있다. 프로그램의 기능적인 구조는 다음과 같이 정해질 수 있다.

-프로그램은 하나 혹은 그 이상의 프로그램(논리) 루프로 구성된다.

-루프는 하나 혹은 그 이상의 상태로 구성되며, 한 시점에서는 한번만이 액트브될수 있다.

루프를 구성하는 상태들의 집합은 프로그램에서 시작(start), 재시작(restart)등의 루프를 시작하는 상태들인 스타트, 리스타트 등의 루프 초기화 문장과 그들 상태 내의 '고우투','고우서브'등의 상태변경 문장에 의해 함축된다.

-상태는 문리스트가 뒤따르는 상태 구절문으로 구성된다.

-문리스트 제로, 하나 혹은 그 이상의 복합문으로 구성된다.

-복합문은 임의의 조건부 및 동작부로 구성된다. 조건부의 부재는 참 조건을 의미하고 동작부는 무조건 실행된다.

-조건부는 시작부분, 한기의 항(term)(혹은 오퍼레이터에 의하여 연결된 그 이상의 항), 및 다음 동작부(action part)에서 종결되는 것으로 구성되는 부울식이다.

-시작부분은 래더도, 및 고급언어로 '이프(if)'문인 파워버스에의 연결과 동일한 기능을 제공한다.

-항은 하나의 조건문(혹은 'and'오퍼레이터에 의하여 연결된 하나 이상의 조건문)으로 구성된다.

-동작부는 하나 혹은 그 이상의 실행동작문으로 구성된다.

다음의 다이어그램은 복합문의 구조를 보여준다.

이 다이어그램에서 문은 '입력(10)이 온이거나 입력(11)이 오프이고 타이머(3)가 23시간 단위보다 크거나 같게 설정되었다면, 출력(14)은 온이고, 출력(17)은 온이다'을 의미한다.

조건부의 평가방법 및 동작부의 실행은 다음과 같다.

-문은 판독되는 순서대로 평가된다.

-'if'는 부울조건 플래그를 1에 설정하며 이 플레그는 그것이 진행되면서 평가의 실행 레코드와, 완전히 진행되었을 때 그 결과의 레코드로 사용된다.

-조건문이 평가되어 0이면 이 플래그는 0으로 설정된다.

-'and'오퍼레이터는 다음 조건문의 다음 평가로 진행할 뿐이다.

-'or'오퍼레이터는 조건플래그를 조사한다.

-플래그가 1이면, 전체 조건부는 참 값으로 되어야 하며 평가의 나머지는 스킵된다.

-플래그가 0이면, 선행항은 모두 거짓이어야 하며, 그래서 플래그는 1로 설정되고 평가는 다음 항으로 진행한다.

-동작문이 판독될때 조건플래그가 진실이면 동작문이 실행되고 그 기능을 수행한다.

이 방법은 조건부에서 중괄호의 사용을 허용하지 않으며, 조건부는 래더도의 다수의 렁(rung)에 상당하며, 각각은 어떤수 또는 직렬접속된 입력변수로 구성되며, 전체는 렁이 액츄에이터에 접속되는 점에서 병렬로 접속되나 다른 점에서 병렬접속이 없다 병렬접속이 입력변수의 평가를 적게할 수 있을지라도 이는 평가될 필요조건을 허용한다. 그러나 이 방법은 참값 평가의 결과를 입력하는 레코딩의 매우 간단한 함축된 방법을 제공하며 그 결정에 따라 액션리스트를 실행하도록 한다.

이것은 진행되고 있는 프로그램을 나타내는 P코드에 포인터를 유지시키므로써 성취되며 이것은 어쨋든 필요하다. 1조건 플래그를 검출하는 어떤 'or'는 그것을 수정하기전에 그 포인터의 값을 세이브하고 동작부로 스킵한다. 우리는 조건부에서 선택적 또는 보호한 경로가 없이 '렁'을 완료하였기 때문에 이 세이브된 포인터 값은 진실을 평가하도록 발견된 처음 렁의 끝을 지시해야 한다. 이것은 '결정포이트(decision point)'이라고 호칭하며, 디버깅(debugging)하는데 사용된다. 평가가 마지막항의 끝까지 진행하면, 즉 마지막 'or' 오퍼레이터를 지나면, 이 위치는 마지막 항이 진실조건을 산출하는 한 결정 포인트가 되거나 또는 동작문의 위치가 이 경우에 마찬가지로 이바지할 수 있다.

대체로 복합문은 조건을 연산하는 래더도와 렁과 동등하며 이 조건이 진실이라면 약간의 동작을 수행한다. 이에 정의된 이부분의 상세한 구조는 주로 용이한 레코딩이라는 관점을 나타내며 임의의 하나의 특정상태 변화의 트레이스에서 결정 포인트를 인쇄한다. 프로그램 루프상태 구조는 에러없는 프로그램의 용이한 설계와 그들 프로그램을 이해하는 관점에서 매우 큰이점을 산출하는 구조이기 때문에 중요한 것이다. 또한 다른 관점에서 볼때 명백하듯이 프로그램은 제1도 부터 액티브될 수 있는 하나 이상의 가능한 액티브 상태도와 함께 상태 1액티브를 자동으로 시작하는 하나의 액티브 상태도(logical loop)로 구성되며, 그후에 임의의 상태도가 임의의 다른 것을 액티브 시키거나 액티브시키지 않을 수 있다는 것이다.

모든 가능한 액티브 상태도를 설명하는 코드가 모든 시간에서 프로그램의 보디(body)내에 존재하나 상태도는 실행되지 않으며, 그 결과 상태도가 그 상태중 하나의 의하여 그 상태의 트랙을 계속해서 유지하는 루프변수로 액티브될때까지 기능적으로 인액티브하며 정시에 임의의 한포인트에서 그 상태도로 액티브한다. 시스템 소프트웨어는 할당이 행해졌는지 루프가 인액티브 했는지를 결정할 수 있는 변수와 코드를 갖고 있다. (부호보다는)숫자변수 명칭을 사용하는 프로그램의 일례가 아래에 도시되어 있다. 이 프로그램은 아무것도 "실행"하지 않으나, 단지 그 구조를 설명하려는 것이 목적이다.

리스팅 1.

상기 프로그램에서, 어떤 상태에 있는 모든 문이 하나의 인접한 블록으로 순차적으로 처리되는 방법으로 부터 생기는 시스템의 타임 시퀀싱 능력에 대한 흥미있는 일례가 있다. 메세지의 일부는 상태 20에서 인쇄되며, 나머지는 상태 30에서 인쇄된다. 이는 이것 이외의 다른 루프에 의해서 랜덤한 인쇄가 되지 않는 적절한 기술이다.

그러나 다른 루프가 "Hold state entered at"과 "@ Hrs."사이에서 인쇄할 수 있는 상태를 가진다면, 이 기술은 문제점을 야기할 수 있다. 그 문제를 우회하는 방법은 간단하며, 모든 관련 프린트문과 함께 단일상태에 놓기만하면되고 운영체제 해석기는 모두를 함께 처리하는 것을 보장할 것이며 프린터가 준비상태가 되면 인터럽트 루틴에 의해서 한번에 하나씩 프린터에 다운로드될 문자를 프린터버퍼에 놓으므로서 제어기능의 홀드-업(hold-up)을 회피한다. 기능저인 구조는 프로그램의 리스팅으로 부터 명백하듯이 그 구조가 상이한 점에 주목해야 한다. 리스팅은 루프와 존재를 직접 보여주지 않으며 프로그램 리스팅은 복합문… 동작문의 상세한 설명을 포함하는 하나 이상의 상태 리스팅만으로 이루어진다. 루프정보도 물론 거기에 있으며, 'start'문, 및 goto, gosub문등에서 발견될 수 있다.

실례 프로그램에서 제3문, 즉 'start loop 2 with state 200'은 시작문의 실행이후에 상태가 그 루프의 다음 스캔에서 루프 2에서 액티브되도록 정한다. 다른 'start'문은 통상적으로 프로그램에서 사용되는 모든 다른 루프에 대하여 초기 상태를 정하는데 사용될 수 있다. 본 시스템에서 루프라는 단어는 2가지 상이한 의미가 있음을 주목해야 하는데, 루프라는 단어는 '논리루프'와 '물리루프'로 표시되며 분류할 수 있다.

대체로 그 차이점은, 예를들어 MSDOS(마이크로 소프트(Microsoft))상의 상표에서의 '논리장치'와 '물리장치'의 차이가 동일하며, 즉 프로그램은 라인 프린터가 있는 곳에 관계없이 '이론적'라인 프린터상에서의 인쇄에 관해 고려하나, 어떤 단계에서는 전체 소프트웨어가 이론적인 라인 프린터상에서의 인쇄에 관해 고려하나, 어떤 단계에서는 전체 소프트웨어가 이론적인 라인 프린터와, 예컨데 장치가 프로그램을 실행하는 시스템의 하드웨어에서 어떤 특정 어드레스 또는 장소 실제로 존재한다는 사실 사이를 연결시켜야 한다. 유사하게, 본 프로그램은 대부분의 실제적인 시스템에서 다이어그램에서의 제1액티브인 그 상태는 기계 또는 처리 사이클을 매시간 마다 다시 액티브되게 할 것이기 때문에 항이된 루프 및 효과적인 상태도가(논리) 루프의 항으로 설계되어 있다. 따라서 처리 액티비티는 시작한 곳에 복귀하는 일련의 상태를 통해 전형적인 사이클을 이루며 그결과 '루프'를 트래버스한다.

프로세서가 원하는 방법으로 프로그램을 실행하는 것을 가능하게 하기 위해서는 논리루프를 물리루프에 할당해야 한다. 이것은 루프변수 n에 m을 직접 기억하거나 다른 간접 기준의 포인터를 기억하여 상태 m을 루프변수 n과 관련시키는 시작문 'start loop n with state m'을 사용하는 것으로 구성되어 있다. 하나 이상의 시작문을 실행한 후 상태기준으로 초기화된 1개 이상의 물리루프변수를 가지며 시스템 소프트웨어는 차례로 이들을 판독하고, 상태를 처리하고, goto, gosub문등에 응답하여 기준을 변경하고, 기계/공정을 제어하는데 필요한 액티비티를 수행한다. 그외에 주목할 점은 프로그램 형태의 일부에 있어서 논리루프는, 보다 큰 서브프로그램 블럭을 가진 관련 상태 블럭등의 임의의 수단에 의하지 않고 start, goto, gosub 문등에 의해 결정된다. 'Loop Blocks'을 초기상태로써 정하고, 'start loop block 3'과 같은 문을 사용하는 것도 물론 가능하다.

현재의 방법은 사용에 있어서 양호한 융통성과 용이함을 제공한다고 생각된다. 상이한 선택적 제어임무를 수행할때 동일한 물리루프(한번에 하는)와 관련된 상이한 논리루프를 갖는 것이 가끔 바람직하다는 것도 주목해야 한다. 통상적으로 루프라는 단어의 정확한 의미는 문맥으로 부터 명백하며 따라서 이 단어는 통상적으로 '논리' 또는 '물리'라는 단어를 붙여 구분하지 않는다. 어느 상태가 어느 루프의 일부를 형성하는가에 관한 상세 및 루프에서 여러 상태 사이의 상호접속은 상태에서 상태변경명령 즉 goto 또는 gosub/returns을 통해 네트워크를 따라 감으로써 용이하게 결정될 수 있다.

본 실례에서는 상태 1에서 시작하는 루프 1은 상태 1이 goto 2, 및 goto 20문을 포함하기 때문에 그안에 상태 2와 20을 가지고 있음을 볼수 있다. goto문등을 거쳐 상태 2 및 20을 따라가서 전 네트워크를 발견할 수 있다. 통상적으로 프로그래머는 상태의 상세한 설명전에 네트워크의 구조를 미리 정한다. 유틸리티 프로그램은 통상적으로 임의의 루프 네트워크 구조를 수록하도록 사용되는데 인위적인 검사라기 보다는 필수적이어야 한다. 루프의 기능구조는 임의의 하나의 루프와 관련된 코드의 인접한 블럭을 형성하도록 이의 제한문을 갖지 않고 프로그램내에서 짜여지게 됨을 상술한 것으로 부터 알수 있다. 그러나 상태의 인접블럭을 사용하는 루프를 코드로 하기 위해서는, 즉 수치범위를 루프 2에 대해서는 200-299, 루프 3에 대해서는 300-399, 루프 4에 대해서는 400-499등으로 나타내기 위해서는 양호한 프로그래밍 실무에 고려될 수 있다. 이것은 공정이 상태의 네트워크에 의해서 표현된다는 의미에서 루프가 상이한 시점에서 상이한 공정을 제어할 수 있는 메커니즘을 제공한다는 것을 또한 유의해야 한다. 이것은 기계의 부분품이 요구조건에 의한 다수의 상이한 부품의 하나를 이루는 곳에서 발생할 수 있다. 특정부분이 요구될때 특정루프는 그 부품의 형성을 제어하는 상태 네트워크에 대한 시작상태에서 시작된다. 만약 상이한 부품이 요구되면, 동일한 루프가 그 상이한 부품의 형성을 제어하는 상이한 상태 네트워크에 대한 시작상태에서 시작된다. 이런 방법에 있어서, 프로그램은 액티비티의 상이한 서브클래스들이 상이한 상태 네트워크에 의하여 제어되도록 짜여질 수 있고, 그리하여 프로그램을 모듈화하고 임의의 특정 상황하에서 관련 있는 프로그램 코드의 범위를 최소화하여 기계의 작동을 간단히 이해할 수 있게 된다.

이것은 시스템내에 존재하는 입력변수와 상태의 모든 조합중에서 매우 적은 단순화된 조합만이 기계의 실제운전에 중요하다는 것과 또한 어느 시점에서나 그들 적은 것중에서 단지 일부만이 중요하다는 원리를 설명하고 있다.

이 언어에 있어서의 정상적인 프로그래밍, 특히 시퀀싱은 종종 모든 동작문(고우투, 고우서브, 등과 같은 상태변환문과 다른)으로 유도하고, 무조건적으로 되고, 그리하여 시스템내에서 만들어진 결정은 주로 상태의 변화에 관하여 언급되어진다는 것을 주목해야 한다는 것이 관련된다. 출력을 온하는 것과 같은 액티비티를 제한하는 조건의 결핍은 시스템이 특수한 상태에 있을 때 무엇이 발생한 것인가에 관한 고정도의 확실성으로 유도됨으로써 시스템이 에견될 수 있다. 만일 출력이 값도 알려지지 않고 명백하게 후에도 측정될 수 없는 입력에 의하여 조건되어 질지라도 발생한 것에 대하여 사용자는 걱정할 필요가 없다. 상태의 내용이 복합문의 리스트이기 때문에 어떠한 상태가 래더도를 표현한다고 말할 수 있으며, 복합문의 각각은 조건부와 동작부로 구성되어 있다는 것을 또한 유의하여야 한다. 이것으로 부터 상태변화에서 실제로 래더의 인액티브는 상태가 인액티브인 것과 동등하며 래더도의 액티브 상태가 액티브하게 되었다는 것과 동등하다는 것을 나타내 주고 있다는 것은 당연한 결과이다. 그러나 이것은 상태 및 조건부 고우투문과 같은 추상적 개념을 사용하는 고급방법으로 행하여지며 종속래더의 다양한 가로대에 대한 접촉으로 부터 마스터 릴레이 접촉 혹은 연결을 가능하게 하는것 같은 어떠한 외부부재의 조작을 포함하지 않는다는 것과, 부가적으로 고우투문에 의한 하나의 상태의 액티비티는 이러한 액티브성이 그러한 루프에 대하여 가변성 있는 루프내에 걸려있는 값을 고쳐 쓰는 것을 포함하고 있기 때문에 시스템 레벨에서 고우투문을 계속 액티브로 하기 위한 상태의 가능성을 방해한다. 이것으로 부터 단지 상태 1(어떠한 상태변화 동작문을 구비하고 있지 않음)을 포함하고 상태 1이 복합문 리스트를 포함하고 있는 프로그램은 실제로 래더도 형상인 PLC의 함께 사용되는 것처럼 래더도와 동등한 기능을 보유한다. 비록 이와같은 프로그래밍의 방법이 더욱 강한 상태-루프구조가 유용할때는 정상적으로 사용되지 않지만 그것이 시스템 입력에 의하여 조건되어지는 출력을 구비하는 상태까지에 대한 래더도의 관계를 지시하기 때문에 동등함이 주목된다. 래더도 기능은 다수의 상태도를 구비한 프로그램의 보조기능인 상태도의 보조기능이고, 이러한 상태도는 그것들이 '시작루프 … 상태를 구비하고… '형태의 문으로 시작되었는가에 의하여 액티브인가 아닌가가 된다. (본 시스템에 있어 그것들은 무시(override)되고, 포즈되고, 정지될 수도 있다) 루프가 시스템 모니터로 부터 루프시작 상태번호 혹은 테이블 구동시스템의 사전배치에 의하여 프로그램 자체내의 문과 다른 방법에 의하여 시작되어 질수 있다는 것은 가치가 없는 것이다.

또한 물리적 루프는 특수한 상태도와 직접적으로 동등하지 않다. 그것들은 프로그램에 의하여 필적된 여러 종류의 상태도의 구조에 의하여 액티브상태의 값을 수용하고, 상태도가 루프에 의하여 제어된다는 것을 규정하는 시스템 변수, 리스트의 부재들이다. 여기서 특수한 상태도는 그것이 시작된 시작문에 의존하는 특수한 루프를 통하여 제어된다(혹은 '리턴' 문과 만나질 때까지 다른 '서브상태로' 로 바뀌는 후속의 고우 서브문). 루트 변수는 메모리내에 정적으로 배치되거나 혹은 동적으로 배치된다.

상기에서 '루프 2' 는 물리적 루프 2 혹은 루프변수 2에 저장된 액티브상태의 값에 속하게 된다. 본 언어에서 '루프 2 취함' 은 루프변수(2)를 사용하는 물리적 루프(2)에 의하여 제어되는 상태도내에서 액티브상태의 변호를 얻는다는 것을 뜻한다. 루프하는 말은 상태도 즉, 논리적인 루프를 의미하는 것으로 막연히 사용되어 졌으며, 어떠한 물리적 루프도 다른 시점에서 다른 상태도의 예뮬레이션을 제어하는데 사용되어질 수 있다. 정학한 의미는 문맥으로 부터 결정되어져야 한다. 동일한 항이 2가지의 다른 그러나 연관된 개념으로 사용되어진 이유는 이것이 프로그램 기능의 직관적인 이해에 도움이 되기 때문이다.

보아온 것처럼, 각각의 액티브상태는 각각의 스캔을 처리하고, '시작' 같은 문은 각각의 스캐캔의 처리를 필요로 하지 않는다. 프로그래밍에의 접근에 의존하려면 다음과 같은 문들을 처리하는 것이 필요하다.

상태를 액티브한 후에 최근 스캔내에서

혹은 포함된 복합문의 조건부분이 참이 되거나 참값인 상태를 통하여 최초의 스캔을 포함하는 각각의 시간후의 최초의 스캔내에서, 그러한 처리는 부가적인 상태조건을 함께 처리하는 동등한 래더와 유사하며, 각각의 스캔을 반복적으로 출발시키는 타이머를 피하며, 그리하여 (0)에 고정되고, 각각의 스캔의 인쇄된 메시지의 연속적인 반복을 피할 수 있다. 대부분의 문들은 '출력 22는 본 상태내에 있다'는 의미의 'op 22 on'과 같은 문을 제외하고 이러한 방식의 처리를 요구한다. 이것은 출력이 상태가 비활성화 되었을 때 자동적으로 비활성화 되기 위하여 각각의 스캔을 기제로화된(pre--zeroed) 배열에 반복적을 삽입하는 것을 필요로 한다.

[상징적인 변수들]

리스트(1)와 동일한 상징적인 변수들을 사용하는 프로그램이 하기 리스트(2)에 나타나 있다. 상태(1)는 루프, 상태등을 한정하는 문들의 리스트를 구비하고 있다는 것에 주목하여야 한다. 이것들은 특수한 형태의 새로운 변수명이 프로그램 기입중에 마주치어, 자동적으로 변수의 특수한 형태를 위하여 다음의 자유로운 숫자를 배치시킬 때에 자동시스템에 의하여 수동으로 혹은 자동으로 삽입되어질 수 있다. 이러한 한정문들은 상태(1) 내에 있을 수 있으며 그렇지 않은면(분리된 블록내에 있게 됨)(도시된 바와같이) 감추어지거나 명백하게 된다. 주목할 가장 커다란 점은 본 프로그램은 사용자에 대한 친절함이 없다는 것이며, 그리고 크게는 독자가 기계를 이해하던가 혹은 자체를 처리해야 한다면 스스로의 설명과 논평이 필요하다는 것이다. 본문의 동일함은 이것이 'if','or','and', 오퍼레이터, 복합문, 조건부분, 동작문 등등의 위치를 지시하는 정보를 전달하고, 기능적으로 관련되 문들의 그룹으로 프로그램을 갈라놓아 이해를 쉽게 한다는것 또한 주목되어져야 한다.

본 프로그램은 관련문을 통하여 평가하고 작동하는 것을 반복적으로 스캔하는 방식으로써 표준 PLC와 유사한 방법으로 프로세서에 의하여 처리된다. 더욱 상세한게는 다른 것이다. 스캔은 다시 액티브상태내에 포함된 문만을 포함한다. 이 상태는 루프변수에의 관련부호에 의하여 결정된다. 프로세서는 리스트에 있는 제1루프변수를 판독하고 그 루프를 위한 액티브상태의 시작이 프로그램내에 있는 이것으로 부터 결정된다. 이것은 그 상태로 가고 다음 상태를 제한하는 문에 도달할때까지 상태내에 있는 문을 처리한다. 이것은 프로그램 리스팅내에 있는 다음 상태의 시작이며 처리되는 현상태의 끝을 표시한다. 프로세서는 교대로 다음 루브변수로 가서 처리과정을 반복한다. 그리고 액티브상태를 가지는 루프변수가 완전한 리스트를 통하여 반복된다. 이 액티비티는 다양한 PLC에 공통인 오우버헤드 액티비티와 함께 소정의 스캔을 형성한다. 스캔은 연속적으로 반복한다. Goto, restart, return, gosub문은 처리되었을때 즉각 루프변수의 값을 바꾸며, 그 상태내의 문의 처리는 이를 발생하고 프로세서가 리스트에 있는 다음 상태, 즉 문은 상태가 그 스캔에서 처리되지 아니하는 Goto문을 통과하는 상태를 처리하기 위하여 이송된다. 다음 스캔에서 물론 이것은 스웹인(swap in)되는 새로운 상태내에 있는 문을 처리하고 중복기입된 구성태는 액티브되지 않거나 또는 처리되지 아니한다. 어떤 상태내의 처리문의 순서는 프로그램 리스팅과 동일한 순서이며 루프는 숫자 순서로 부터 위로 올라가면서 스캔된다.

멀티타스킹 운영체제(MTOS)는 공지의 실시간 소프트웨어를 위한 기초로서 사용되어진다. 이것들은 주의를 요하는 다른 타스크에 처리시간을 나누어 쓴다는 점에서 본 시스템과 유사한다. 또한 다른 루프내에 있는 다른 액티브상태와 동일하게 본 시스템은 작동한다. 그러나 MTOS는 본 발명의 Next로 완전히 가기 전에 각 액티브상태를 처리하는 스캔루프의 순서에 의하여 부여된 그들의 타스크상의 처리에 엄격한 순위를 반드시 요구하는 것은 아니다. MOTS는 보통 타스크 시간배치, 다스크 우선위치, 인터럽트등에 의하여 한 타스크에서 다른 타스크로 프로세스를 스웹할 수 있다. 이것은 타스크처리의 설계적인 순서와 이븐(even)문이 프로그래머가 필요하다고 간주하는 프로그램의 주요부분이나 하드웨어를 제어하도록 하는 기구가 제공되어져 있을지라도 응용 프로그램을 작성하는 프로그램머에 알려진 필요가 없음을 의미한다. 기계제어나 처리공정제어에 있어서, 처리공정 순서를 정확히 아는 것이나 시스템 입력으로의 처리되는 반응시간이 적절하도록 예측하거나 보장하는 것은 매우 유용하다. 기계장치는 특히 빠른 응답을 요구하고 PLC와 함께 프로그램의 1회의 완전한 스캔을 위한 시간을 정하는 것이 보통이며, 이것은 1 내지 20밀리 초의 단위가 된다. 본 운영체제는 모든 필요한 액티비티가 항상 충분히 빨리 수행될 수 있는 시간을 보장하는 방법을 제공한다.

본 언어의 구조는 한 스캔이 모든 액티브상태를 한꺼번에 처리하는데 필요한 시간이 걸리게(그러나 비액티브상태는 어느것도 처리되지 아니함)하고 예상가능한 어떤 부가적인 시스템 오우버헤드를 보장한다. 이것은 예상가능한 스캔타임을 제공하고, 비액티브상태는 처리되지 아니하므로, 스캔타임은 짧고, 또는 반대로 보아서 특정 스캔타임은 본 시스템을 사용함으로써 이루어질 수 있고, 모든 문이 모든 스캔마다 스캔되는 래더논리와 같은 시스템에 의하여 이루어질 수 있는것보다 저전력소비, 저비용 프로세서가 수행될 수 있다. 모든 스캔마다 모든 래더도의 문장을 스캐닝하는 것을 피하는 표준 PLC를 위한 방식이 있으나 이것들은 본 시스템 처럼 편리한 것은 아니라는 점을 주의하여야 한다. 루프구조와의 액티브상태의 스웹인, 아웃은 프로그래머에게 MTOS와 유사한 편리성을 제공하나 이것은 완전히 예측가능한 것이다. 프로그래머는 상태가 어떤 상태로 처리되는 긴시간을 소요하지 않도록 코딩하거나 시간이 오래 걸리는 처리가, 센시티브상태가 액티브하는 동안, 한 루프내에서 일어날 수 있게 보장하기 위하여 다른 루프를 검사하기 위한 루프변수를 사용함에 의하여 반응시간을 제어할 수 있다. 본 시스템은 매우 간단한 형태로서 필요한 편리성을 제공한다.

부가적으로, 각 액티브상태내의 문리스트가 리스트내의 문순서로서 처리되어지듯이, 또한 모든 문이 다음 루프로 가기전에 처리되듯이, 프로그래머는 모든 필요한 동작이 시작된 센시티브 동작의 리스트를 한꺼번에 수행하도록 보장하는 매우 간단한 방식을 가지며 다른 어떤 상태와 연관된 어떤 동작도 끼어들지 아니한다. 이것이 중요한 경우의 예는 글로우벌 변수를 사용하거나, 또는 텍스트의 블록을 기입할 경우, 또는 터미날에는 핸드세이킹 동작이 포함된 경우에 가능하다. MTOS와 같은 다른 기술을 사용하여 이것이 가능하나, 고수준의 언어내에서 내장된 본 구성은 이것을 수행하는 고도의 간단한 방식을 취하고 있다. 프로그래머의 입장에서의 간단성 뿐만 아니라, 시스템 소프트웨어 또는 하드웨어의 관점에서 보아서도 간단하며, 이것은 또한 기계 또는 공정을 제어하는 경제적인 수단으로 해석된다.

응용 프로그램은 중간코드나 'p-코드'로서 저장된다. 해석 프로그램은 본 시스템 소프트웨어의 일부이며 이 p코드를 취하며 이것을 필요한 평가나 동작, 오우버헤드 동작을 수행하도록 해석한다. 그러한 소프트웨어 기술의 자세한 것은 공지의 것이며 표준기술이 전체를 일관하여 사용된다.

응용 프로그램이 루프변수로 접근할 수 있고 어느 상태가 어떠한 루프내에서 액티브인가 하는 정보를 사용하거나 결정하도록 하는 편리성이 제공된다. 위에서 보인 Get loop와 같은 문은 전형적인 그 예이다.

이런 형태의 문에 관해 기술하면, 모든 문에 대한 p코드는 코드에 대한 일반적인 2개의 카테고리로 구성된다.

첫째, 사용될 서어비스 루틴을 선택하기 위하여 해석기에 문형을 정의하는 오퍼레이터를 구성하는 하나이상의 바이트가 사용된다.

둘째, 필요한 선택 데이타가 선택적으로 사용된다. 흥미 있는 문의 형태(예로서 도시된)는

루프초기화문

'start loop 3 with state 200'

시작루프에 대한 p코드는 오퍼레이터, 루프참조 및 상태참조로 구성된다. 루프참조는 종래예는 타스크테이블내의 루프데이타의 시작의 어드레스일 수 있다. 상태참조는 종래예는 프로그램 p코드의 상대 어드레스일 수 있다. 서비스루틴은 다음을 포함한다.

원스테스트(이전 응용에서의 ONCE TEST 루틴참조) 및 필요시 나머지를 스킵

타스크테이블에서의 정확한 루프위치의 루프변수로서 상태 어드레스를 전달

필요한 원스테스트플래그를 세트

결정 포인트 데이터를 세이브

다음 오퍼레이터를 처리하도록 탈출

'restart 3000'

상기와 유사한 상태 3000에서 루프 1 시작

적절한 제로 플래그, 레지스터등

결정 포인트 데이타 세이브

스캔의 시작으로 탈출

상태 변경문

'goto 201'

새로운 상태 어드레스를 현재 처리되는 루프에 대한 타스크테이블의 루프변수로 전달

원스플래그 클리어

결정점 데이타 세이브

다음 루프처리로 탈출

'gosub 5000'

리턴문에 의한 사용을 위해 타스크테이블에서의 세이브 영역에서 리턴되어야할 다음 오퍼레이터의 어드레스 및 상태의 어드레스 세이브를 제외하고 코드로서 원스테스트

원스테스트 플래그 및 마스크 세이브

결정 포인트 데이타 세이브

다음 루프로 탈출

'return'

호출문의 나머지를 처리할 수 있는 세이브테이블로 부터 세이브된 어드레스를 취함

원스테스트 및 마스크 재기억

결정 포인트 데이타 세이브

조건플래그 세트

호출문의 나머지 처리로 탈출

상기 두 문장은 원스오운리문(once only statemeuts) 즉 시작루프 및 고우서브이다. 그들이 하는 것에 의한 성질에 의한 모든 기타 3기능, 즉 그들은 그들이 나타나는 루프의 액티브상태를 변화하게 한다. 그들이 이것을 하기 때문에 그들은 루프를 통하여 다음 스캔에 대해 실행하지 않는다. 따라서 그들은 원스테스트 루틴을 참조할 필요는 없으며 원스오운리문으로서 클래스될 수 없다. 고우서브가 이런 필요성이 있는 이유는 서브루틴으로 부터 리턴후에 그 자신의 루프를 변경하지만 호출문은 다수 스캔을 위하여 기능하게 다시 액티브되며, 스캔마다 서부루틴을 호출하는 것은 부적절하지만 'once per state activation'을 기초로 이를 호출하고, 서브루틴으로 부터 리턴은 상태 액티베이션으로서 계수되지 않으며, 에지 액티베이션(edge activation basis)는 논리적이기 때문이다.

once only statement. 대부분의 문은 원스오운리문이다. 아래 설명은 에지 액티베이트 혹은 필요한 상태 액티베이션형마다 일단 실행될 수 있는 기타 에이다.

'start timer 5'

'increment register 17'

-상태 액티베이션 마다 오직 한번 혹은 조건이 참일때, 타이머를 시작하거나 레지스터를 증가하는 것이 바람직한 이유는 쉽게 명백해질 것이다. 예를들면, 매스캔마다 타임머를 시작하는 것은 그 상태중에 실행되지 않고 0로 리세트하는 대신에 리세트를 유지하는 것이며 경과한 시간을 계수하는 점을 허용한다.

-이 문의 실행은 최후에 타이머오우버플로우(8비트에 대해 255비트의)에 고정될때 까지 인터럽트 루우틴에 의한 시간인터벌마다 한번 계수되는 적정타이머를 0으로 기입하는 것보다는 적정 레지스터에 기억된 수에 1을 더한다.

-Once only operation

-소오스 코드에 있어 ONCETEST 루틴은 그기능(그 상태가 액티브하고 조건부가 참)이 참이될때 마다 그 기능을 실행하는 루틴을 어떻게 향상시키는가를 보여준다. 일단 한번 동작을 제공하는 간단한 방법이 있다. 이는 루프당 단일 부울 플래그를 갖고 있음을 의미한다. 이 플래그는 그 루프에 액티브상태를 변경시키는 어떤 루틴에 의해 세트된다. 그것은 다음 루프처리로 이동하기 전에 그 루프를 통하여 제1스캔의 종단에서 리세트되며 루프를 통한 매스캔의 종단에서 용이하도록 하는 것이다. 그러므로 새로운 액티브상태를 통한 제1스캔중에는 단지 참이다. 오직한번 문에 대한 서비스 루틴에 의해 이용되며, 이들은 플래그가 참이면 그들의 기능을 실행한다. 이 기술의 유효한 값은 단순화된 해석기와 언어에 있어서의 더 좋은 유연성 사이의 트레이드-오프(trade-off)에 좌우된다.

-어떤 상태하에서는 오직 한번 루틴으로 하여금 매스캔마다의 그의 기능실행을 반복하게 할수 있듯이 이점일 수도 있다. 예를들면 상태가 디액티베이트 될때까지 타이머를 리세트로 유지하는 것과 자동적으로 이를 해제하는 것이다. 이 목적을 위하여, 다음 즉, 후속 문에서 "end repeat"문까지를 실행하는 해석기에 의해 실행되는 "repeat"문이 구비되어, 반복문을 위한 서비스 루틴에 대해 대체 엔트리 포인트를 선택하는 해석기에 의해 실행될 수 있는 매스캔을 실행하기 위하여 엔트리포인트는 ONCETEST 및 제1스캔플래그를 무시한다.

-매스캔문, 이의 제1예에는 출력문이 있다.

-"op 45 on"

이 문은 "출력 45는 문이 나타나는 상태가 액티브이며 그것에 가해지는 어느조건에 부합될때 온이다"를 의미한다. 출력은 상태가 디액티브베이트일때 자동적으로 오프된다. "출력 45온"은 의미하는 것이 아니며 후에 기타문을 오프하지 않는다. 이는 출력맵의 모든 비트를 각 스캔의 초기에서 0로 세트하고 상태가 액티브하고 조건부가 참인 각 스캔에 대하여 맵의 적정비트를 세트한 문에 대한 서비스 루틴을 제공함에 의하여 이루어진다.

-복합문

-정의

정의문의 클래스가 변수 혹은 상수에 대해 제공된다.

이들은 수동으로 프로그램에 삽입, 변경, 혹은 새명칭이 인정될때 자동적으로 삽입된다. 이들은 "define state 5=thisstate" 형태이며, 기본적으로는 그 명칭과 변수/상수의 수치는 관련되며 프로그램의 일부로서 기억된 심블테이블에 해당한다. 프로그램 실행중 아무것도 하지 않으며 단지 스킵되므로 해석기를 특별히 늦게 하는 것이 아니고 프린트 루틴에 의하여 프로그램 리스팅 동안에 사용된다.

-문은 어떤 특정상태가 어떤 정의된 루프내에서 액티브인가 아닌가를 테스트하기 위해 제공될 수 있다. 이는 의문점이 있는 루프에 대한 루프변수로 가서 액티브한 상태에 대한 코드의 어드레스일 수 있는 루프참조를 추출하는 것을 포함하며, 만일 상태 p 코드로 간다면 p 코드의 제2 및 제3바이트로 기억될 수 있는 상태번호를 추출한다. 비교가 이루어진다. 문은 변수항에 의하여 비교 되어야하며 다음의 형태로될 수 있다.

-Get loop 3

If egual to 315

Goto 350

또는 If state in loop 3

Goto 350

명확하게 부가적으로 기술하면 아래 챠트는 더 상세히 기술된 루틴 및 제어기를 실용적인 장치로 만드는데 필요한 별도의 지지 루틴의 일부를 도시한다. 또한 동일목적을 위하여 부가하여 기술하면 소오스 코드는 특정 마이크로프로세서의 키이루틴을 실행하기 위해 설명되었다. 이 후속챠트는 정확하지는 않지만 근접하게 기술된 소오스 코드이며, 코드 및 크로스참조의 이해를 돕기 위하여 소오스 코드의 테이블에 유사하게 명명된 엔트리 및 탈출 포인트를 사용한다.

[단순화된 챠트]

아래 챠트는 기술된 새로운 스캔닝방법의 실행을 위한 제어흐름을 도시한다.

상기 플로우챠트는 아래 데이타구조 및 가정에 좌우된다.

1. 적어도 하나 이상의 상태블록의 리스트로 구성된 p코드에 바람직하게 되고 기타형에 가능하게 기억된 프로그램.

2. 블록의 시작의 한계를 정하는 상태문 혹은 유사한 한계를 정하는 수단, 액티브 상태 및 루프의 제어를 포함한 수행될 제어행동을 정의할 하나 이상의 문, 및 다음 상태블록의 시작에서 혹은 기타 편리한 경계분리 기호에서의 끝으로 구성되는 각 상태블록.

3. 수행될 절차 타스크의 리스트에 반대로 상태가 액티브인 동안에 극복할 정상조건을 정의할 수 있는 이용 가능한 적어도 일부의 문, 예를들면, "op 10 on"은 "출력 10이 온"임을 뜻하고, "출력 10이 턴온되는" 것을 뜻하지 않는다(후에 기타 문에 의하여 오프가 된다) 출력 10은 상태가 인액티브일때 자동적으로 오프됨을 주지하라. 반복의 스케닝 및 기타 지지되는 특정한 연산체계는 이 특징을 제공하는 언어로서 조합되는 것에 주목하라.

4. 상태가 액티브일때 오직 한번 동작할 수 있고, 액티브를 유지하는 동안 그 상태를 통하여 후속 스캔의 실행을 자동적으로 스킵할 수 있는 적어도 일부의 문.

5. 액티브 혹은 인액티브일 수 있고 루프번호를 액티브 상태와 관련짓는 루프변수의 리스트, 여기서 상기 루프번호의 수순은 상기 액티브 상태의 스캔닝수를 제어한다.

6. 어떤 상태가 그 루프에서 평가될 필요가 없이 문장이 나타나는 루프의 액티브 상태를 변경하기 위해 필요한 평가로 부터 작동될 수 있는 Goto문과, 이 작동이 발생하도록 하는 프로그램 구조.

7. 루프 변수를 액티브하게 하고 포인터로 하여금 루프변수의 액티브 상태블록으로 로우드하는 시작문.

8. 서술된 바와같은 상태레벨에서 동작하는 고우 서브/리턴문.

모든 드루몬드의 기본 클레임에서는 1. 단지 즉시 한세트의 액티브상태 2. 액티브가 된 세트는 나머지세트를 인액티브로 만드는 등, 루프를 액티브 및 인액티브로 형성할 수 있고, 후자의 경우에 있어서는 반대로 액티브상태를 그와 동일한 세트의 어떤 다른 액티브상태로 형성함이 없이도 인액티브 상태로 만들 수 있음에 주목하라.

해석기 루틴을 상세하게 기술한 플로우챠트 라벨과 변수명은 대문자(CAPITALS)로 표시되었다. 프로그램은 스타트인터(STARTINTER)에서 시작한다. 플로우챠트는 알고리즘의 본질적인 요소를 상세히 설명한다. 이것들은 가령 레지스터 같은 프로그램 리스팅에 포함된 하우스 키핑 액티비티(house-keeping activities)만을 설명하는 것이다. 왜냐하면 이 액티비티는 특정분야에 한정된 실행이기 때문이다.

일단 액션을 수행하는데 필요한 조건이 참이라는 결정이 이루어지면, 조건문의 잔여항을 계속 평가할 필요가 없으며 그 이유는 그것들이 문전체의 유효한 결과에 영향을 끼치지 않기 때문이다. 이 상황은 "or"형 문은 만나고, 문이 판독될때 조건플래그가 참일때 발생한다.

예로서 문에서 "if ip 5 on, and ip 6 on, or ip 7 on, set op 66 on" 만약 양쪽입력(5,6)이 온일때, 문 "set op 66 on" 은 입력(7)의 상태에 상관없이 실행되며, 따라서 입력(7)의 평가(및 다음에 오는 임의의 다른 조건 평가문)는 스킵된다. 이를 위한 특정 알로리즘이 다음과 같이 제공된다.

이 알고리즘은 코드화된 오퍼레이터에 의존하며 따라서 이들 바이너리값은 각각의 엔트리가 존재하는 점프테이블에 있는 어드레스의 로우 바이트와 같거나, 테이블에 있는 점프 어드레스를 계산하기 위한 오프세트와 동일할 수 있다.

서비스 루틴부 예

문 "세트 op"(출력세트) 또는 "세트 플래그"을 실행하는 루틴문은 p코드로서 메모리에 기억되고 이들 문은 3연속 바이트로서 편리하게 기억될 수 있다.

바이트 1-문의 종류를 표시하는 오퍼레이터, 이 경우에 "세트 op" 또는 "세트 프래그"를 의미한다.

2-이 출력/플래그를 포함하는 바이트를 갖는 메모리에 내부출력 또는 플래그램에 있는 어드레스

3-실제 출력/플래그를 선택하는 마스크 동일 루틴은 양 플래그 및 출력용으로 사용될 수 있으며, 바이트(1)는 동일하며, 어드레스는 변수가 출력 또는 플래그 인지를 결정하는 것에 주의하라.

임의의 1 상태의 처리동안, 2 상태형 오퍼레이터가 상태블록의 시작과 끝에서 한번씩 판독되고 처리되는 것에 주의하라. 상태블록의 시작에서 발견된 상태형 오퍼레이터는 상기 챠트에 도시한 것처럼 처리된다(TRPST 전후의 대략 15라인 참조). 블록의 끝에서 발견된 오퍼레이터는 하기와 같이 처리된다. 그것들은 이 상태동안 처리의 끝이 간단히 표시하며 다음 루프에서 액티브한 상태로 처리단계를 전달한다. 블록의 끝에서 오퍼레이터는 사실프로그램 리스팅에 있는 라인의 다음 상태 블록인 제1오퍼레이터이다.

상태형 오퍼레이터는 상태, 포즈상태, 및 브레이크상태를 포함한다.

"Goto"

"goto"용 코드는 다음 상태 어드레스 오퍼레이터이다.

(즉 메모리에 있는 p 코드의 새로운 상태블록의 시작에서의 상태 오퍼레이터의 어드레스)

"endless tape" 기억버퍼 주변의 랩으로서 메모리에 있는 선형 테이블인 트레이스 테이블을 사용함.

위치설정에 사용된 마지막/다음의 포인터는 개개의 포인터 변수로 세이브된다. 일단 테이블이 채워지면, 구 데이타는 선데이타에 의해 중복 기입된다.

주의 : 실행에 있어서, 트레이스인에이블 플래그는 루프번호의 최상비트로 인코드되어 기어된다. 이것은 8비트로 인코드된 7FH 루프이상으로 실행할 수 없기 때문이다. 개개의 변수가 사용될 수 있다. 이 변수는 "디스에이블된 루프의 트레이싱"을 위하여 사용된다.

"Remark"

"remark"용 p 코드는 오퍼레이터, 프로그램내 다음 오퍼레이터의 어드레스, 주석문자 자스티링(다음 오퍼레이터)

이 명령은 다음을 이해함에 의해 보다 쉽게 이해될 것이다.

타스크테이블은 레코드의 배열로서 일부는 데이타를 보유하여 시작된 액티브 루프를 표시하며, 일부는 비어있어 시작되지 않은 루프를 나타낸다. 모든 비지 않은 레코드가 테이블의 시작에 채워지고 레코드에 있는 루프변수값의 번호로 정리된다는 점에서 배열은 동적이다. 배열에 새로운 루프 레코드의 삽입은 채워진 배열안에 번호로 그것을 삽입하는 것을 포함하며, 필요하다면 이것이 허락하는 배열을 높은 순서적 루프로 하향이동 된다.

각 레코드는 루프레코드이며 다음의 간단한 변수를 갖는 필드를 가진다. TTLOOP-루프번호는 레코드를 표시하며, 또한 액티브상태가 스캔된 순서로 결정된다. 루프번호는 상호 배타적이다. 실제 표현에 있어서, 루프번호는 모두 127 보다 작다. 8비트 변수의 7비트로서 루프번호를 기억하며, '루프 트레이스 디스에이블 플래그'로서 8번째 비트를 사용한다(STOREHIST 참조).

양 루프번호 및 플래그는 TTLOOP에 기입된다. TTSTATE-루프용 액티브상태 어드레스, 즉 액티브상태용 프로그램상태 블록의 시작을 규정하는 상태 오퍼레이터용 프로그램 코드의 메모리에 있는 어드레스.

TTONCE-이것은 원스페스트(ONCETEST)에 의해 사용된 원스플래그(ONCEFLAG) 변수이다. TTACCUM-루프용 레지스터를 전송하는 중간결과 및 데이타 수식데이터를 이용하는 문에 의해 사용된다.

TTEXTEN-TTACCUM을 위해 확장

TTSTATESTR

TTONCESTR

TTRTNAD-'gosub' 및 'ruturn'문에 의해 사용되도록 각각 TTSTATE, TTONCE 및 p코드포인터로부터 정보를 보존하기 위한 3변수 'start'용 p코드는 오퍼레이터, 루프번호 새로운 상태 어드레스이다.

Claims (32)

1. 유한상태 응용 프로그램(14)을 실행하고 상기 프로그램의 디버깅을 용이하게 하는 프로그램된 제어기(10)에 있어서, 상기 유한상태 응용 프로그램은 하나 이상의 프로그램 루프(46)를 구비하는데, 각각의 상기 프로그램 루프는 상태도를 에뮬레이트하고 하나이상의 블록문(48,50,52)을 가지며, 각각의 블럭문이 상기 제어기(10)에 의해 실행된 경우를 프로그램 상태로 하고, 하나 이상의 조건 또는 동작이 단지 상기 프로그램 상태를 발생시킬 경우에 각각의 프로그램 상태를 액티브되게 하며 (a) 상기 프로그램된 제어기는, 실행을 위해 액티브되는 적어도 하나의 상기 프로그램 루플를 이네이블하는 수단(68,10A) 및 소정의 사간에서 실행되도록 액티브되는 소정의 액티브 프로그램 루프내에서 상기 블록중 하나의 블록만을 이네이블하는 수단(68,10A)과 (b) 상기 발생된 각각의 상기 프로그램 상태가 이후에 표시되도록 기록하는 수단(82,10A)과 (c) 각각의 상기 프로그램 상태의 발생을 야기하는 상기 하나 이상의 조건 또는 동작을 이후에 표시하기 위해 기록하는 수단(82,10A)을 포함한 것을 특징으로 하는 프로그램된 제어기.
2. 제1항에 있어서, 각각의 액티브 프로그램 루프에서 한번에 하나의 상태만이 액티브될 수 있으며, 그 액티브 상태는 액티브 상태 블럭을 지시하는 변수(94) 값이 기억장소에 의해 지시되며, 그 변수는 상태 액티비티를 지시하기 위해 할당된 것을 특징으로 하는 프로그램된 제어기.
3. 제1항 또는 제2항에 있어서, 상기 이네이블 수단은 적어도 하나의 상기 변수(100,102,104,106,110)를 구비하며, 상기 적어도 하나의 변수 각각은 액티브 블록의 처음 식별자(94)를 기억하기 위한 상기 적어도 하나의 액티브 프로그램 루프에 결합되며, 상기 변수 액티브 블록을 포함한 액티브 프로그램 루프를 지시하기위한 식별자(92)를 포함한 것을 특징으로 하는 프로그램된 제어기.
4. 제1항 또는 제2항에 있어서, 복수의 상기 액티브 프로그램 루프의 멀티타스팅을 용이하게 하고 상기 액티브 프로그램 루프의 실행 시퀀스를 제어하기 위한 상기 적어도 하나의 액티브 프로그램 루프에 결합된 각각의 상기 변수를 기억하는 수단(68,10A)을 추가로 포함한 것을 특징으로 하는 프로그램된 제어기.
5. 제1항 또는 제2항에 있어서, 상기 발생된 각각의 상기 프로그램상태를 이후에 표시하기 위한 상기 기록수단(82,10A)은, 적어도 하나의 제2변수 각각이 프로그램 상태로의 변경을 지시하는 식별자를 기록하기 위해 사용된 적어도 하나의 제2변수(70,71,72)를 포함한 것을 특징으로 하는 프로그램된 제어기.
6. 제5항에 있어서, 프로그램 상태를 발생시키는 상기 조건 또는 동작은 프로그램 상태의 변경을 야기하는 상기 조건 또는 동작이 실행되도록 문자의 식별자를 기억하는 상기 제2변수(70,71,72)에 의해 지시된 것을 특징으로 하는 프로그램된 제어기.
7. 제5항에 있어서, 상기 제2변수는 상기 문장을 포함한 액티브 프로그램 루프를 지시하는 것을 특징으로 하는 프로그램된 제어기.
8. 제5항에 있어서, 상기 제2변수를 기억하는 수단을 추가로 포함하며, 상기 기억수단이 트레이스 테이블(82)을 포함한 것을 특징으로 하는 프로그램된 제어기.
9. 제1항 또는 제2항에 있어서, 상기 유한상태 응용 프로그램은 조건부 및 동작부로 구성된 복합문을 추가로 구비하는데, 상기 조건부는 하나 이상의 간단한 조건 평가문으로 구성되며 소정의 시스템 조건이 참 또는 거짓인지의 여부를 각각 평가하여, 상기 조건부가 동작부내에 포함된 동작을 실행시킬지의 여부를 결정하도록 하는 것을 특징으로 하는 프로그램된 제어기.
10. 제9항에 있어서, 구문 규칙이 문장용 상기 유한상태 응용 프로그램에 제공되며, 각각의 상기 프로그램 상태의 발생을 야기하는 상기 하나 이상의 조건 또는 동작의 기록이 상태 액티비티의 조건부 선택 복합문을 참값으로 취하는 결정인 유한상태 응용 프로그램의 기록위치를 포함하는 경우, 상기 정보가 모든 필요한 정보를 형성하여 유한상태 응용 프로그램의 문맥이 판독될때 상태 액티비티로의 천이를 야기하는 프로그램 상태에서 문장의 조건부의 항을 특정하여 결정하는 것을 특징으로 하는 프로그램된 제어기.
11. 제9항에 있어서, 각각의 상기 프로그램 상태를 발생시키는 상기 하나 이상의 조건 또는 동작의 기록은 복합문의 조건부를 참값으로 취하는 결정에서 유한상태 응용 프로그램의 간단한 조건 평가문에 대한 기록장소를 포함한 것을 특징으로 하는 프로그램된 제어기.
12. 제9항에 있어서, 각각의 상기 프로그램 상태를 발생시키는 상기 하나 이상의 조건 도는 동작의 기록은 상태 액티비티에서 발생된 천이 시간을 포함한 것을 특징으로 하는 프로그램된 제어기.
13. 제9항에 있어서, 디버깅 기능은 자동적으로 제공되므로, 상기 유한상태 응용 프로그램을 실행하는 동안 시스템 서비스로서 사용자가 간섭할 필요없이 상기 프로그램된 제어기에 의해 사용되며, 상기 프로그램된 제어기의 실행범위내에서 상기 디버깅 기능이 초기화되는 것을 특징으로 하는 프로그램된 제어기.
14. 제13항에 있어서, 상기 프로그램된 제어기가 프로그램 상태를 브레이크 상태로 전환하는 수단을 가지며, 액티브 상태로 될 경우 디버깅 및 조사공정이 초기화될 수 있도록 사전설정된 디버깅 기능으로 하여금 상기 유한상태 응용 프로그램을 발생시켜 정지되게 하는 것을 특징으로 하는 프로그램된 제어기.
15. 제13항에 있어서, 상기 프로그램된 제어기는 선택적 조건문(HALT)를 프로그램 상태로 삽입하는 수단을 가지며, 상기 HALT문이 실행될 경우, 사전설정된 디버그, 기능으로 하여금 별도의 프로그램 처리루프를 제외한 프로그램 상태를 포함한 프로그램 처리루프에 정지명령을 발생하는 것을 특징으로 하는 프로그램된 제어기.
16. 제13항에 있어서, 상기 프로그램된 제어기는 프로그램 상태를 포즈상태(PAUSESTATE)로 전환하는 수단을 가지며, 액티브될 경우, 사정설정된 디버그 기능으로 하여금 별도의 프로그램 처리루프를 제외하고 발생하는 프로그램 상태에서 프로그램의 처리루프에서 정지명령을 발생하는 것을 특징으로 하는 프로그램된 제어기.
17. 제1항 또는 2항에 있어서, 소정의 특별한 프로그램 상태가 상태 종속의 결정문을 취할 목적으로 액티브되거나, 상태 종속문에 나타나는 프로그램 루프에서 프로그램 상태의 액티비티에 좌우되는 상태 종속 액티비티를 실행하는지의 여부를 평가할 필요를 제거하는 프로그램 구조수단을 포함한 것을 특징으로 하는 프로그램된 제어기.
18. 제17항에 있어서, 상기 프로그램 구조수단은 규칙을 포함하며, 특별한 프로그램 상태에 좌우되는 상태 종속 평가 또는 동작을 포함한 모든 문장이 상기 특별한 프로그램 상태에 대한 블록내에서 수집되며, 상기 특별한 프로그램 상태의 블록에 나타난 문장들만을 실행하는 실행수단은 시스템내에서 액티브되어, 특별한 프로그램 상태가 액티브인지의 여부를 평가할 필요는 제거되는데, 이는 액티브 프로그램 블록만이 액티브 프로그램 루프내에에서 상기 변수(100,102,104,106,110)와 결합됨에 따라 프로그램 블록이 변수(100,102,104,106,110)와 결합되지 않은 프로그램 루프내에서 인액티브된다는 사실에 의한 것임을 특징으로 하는 프로그램된 제어기.
19. 제1항 또는 제2항에 있어서, 상기 유한상태 응용 프로그램은 의사코드 해석 프로그램에 의해 실행된 의사코드에 기억되는 것을 특징으로 하는 프로그램된 제어기.
20. 제1항 또는 제2항에 있어서, 문장블록을 구분하는 경계분리수단을 가지며, 상기 경계분리수단이 각각의 블록문에 상태 식별자를 결합하는 상태문으로 구성된 것을 특징으로 하는 프로그램된 제어기.
21. 의사코드에 기억된 유한상태 응용 프로그램(14)을 실행하고, 의사코드 해석 프로그램에 의해 실행되며 상기 프로그램의 디버깅을 용이하게 하는 프로그램된 제어기(10)에 있어서, 상기 유한상태 응용 프로그램은 하나 이상의 프로그램 루프(46)를 구비하는데, 각각의 상기 프로그램 루프는 상태도를 에뮬레이트하며 하나 이상의 블록문(48,50,52)을 가지며, 상기 제어기(10)에 의해 각각의 블록이 실행될때를 프로그램 상태로 하고, 단지 하나 이상의 조건 또는 동작이 상기 프로그램 상태를 발생하게 하는 경우에만 각각의 프로그램 상태를 액티브로 하며, 상기 프로그램된 제어기는 실행을 위해 액티브도는 적어도 하나의 상기 프로그램 루프를 이네이블하는 수단(68,10A) 및 소정의 시간에서 실행되도록 액티브되는 소정의 액티브 프로그램 루프내에서 상기 블록중 하나의 블록만을 이네이블 하는 수단(68,10A)를 포함한 것을 특징으로 하는 프로그램된 제어기.
22. 제21항에 있어서, 상기 발생된 각각의 상기 프로그램 상태가 이후에 표시되도록 기록하는 수단(82,10A)를 포함한 것을 특징으로 하는 프로그램된 제어기.
23. 제21항 또는 제22항에 있어서, 각각의 상기 프로그램 상태의 발생을 야기하는 상기 하나 이상의 조건 또는 동작을 이후에 표시하기 위해 기록하는 수단(82,10A)를 포함한 것을 특징으로 하는 프로그램된 제어기.
24. 제21항 또는 22항에 있어서, 상기 처리될 제1프로그램 상태의 블록을 지시하는 변수값을 제1초기화 면수로 부터 취하여 상기 유한상태 응용 프로그램을 진행시키는 것으로서, 상기 제1상태 블록을 처리하고, 제1상태 블록을 처리함으로써 수정이 명령될 경우 다른 변수인 상기 저장된 값을 수정하고, 현재 상태블록 액티비티네 대한 소정의 요구된 기록을 유지하고, 양호한 순서와 한가지로 반복처리하는 각각의 액티브 상태블록으로 구성된 유한 상태 응용 프로그램을 처리하는 것을 특징으로 하는 프로그램된 제어기.
25. 제21항 또는 제22항에 있어서, 블록문을 경계분리하는 경계분리수단을 가지며, 상기 경계분리수단은 각각 블록에 상태 식별자를 결합하는 상태문으로 구성된 것을 특징으로 하는 프로그램된 제어기.
26. 제21항 또는 제22항에 있어서, 각각의 액티브 프로그램 루프에서 한번에 하나의 상태만이 액티브될 수 있으며, 그 액티브 상태는 그 액티브 상내블록을 지시하는 변수(94) 값의 기억장소에 의해 지시되며, 상태 액티비티가 지시되도록 상기 변수가 할당된 것을 특징으로 하는 프로그램된 제어기.
27. 제21항 또는 제22항에 있어서, 상기 이네이블 수단은 적어도 하나의 상기 변수(100,102,104,106,110)를 구비하는데, 각각의 상기 적어도 하나의 변수는 액티브 블록의 처음 식멱자(94)를 기억하는 적어도 하나의 액티브 프로그램 루프에 결합되고, 상기 변수는 액티브 블록을 포함한 액티브 프로그램 루프를 지시하는 식별자(92)를 포함한 것을 특징으로 하는 프로그램된 제어기.
28. 제21항 또는 제22항에 있어서, 복수의 상기 액티브 프로그램 루프의 멀티타스킹을 용이하게 하고 상기 액티브 프로그램 루프의 실행 시퀀스를 제어하기 위해 상기 적어도 하나의 액티브 프로그램 루프에 결합된 각각의 상기 변수를 기억하는 수단(68,10A)를 추가로 포함한 것을 특징으로 하는 프로그램된 제어기.
29. 제21항 또는 제22항에 있어서, 상기 발생된 각각의 상기 프로그램 상태를 이후에 표시하기 위한 상기 기록수단(82,10A)은 적어도 하나의 제2변수(70,71,72)를 구비하는데, 각각의 상기 적어도 하나의 제2변수는 프로그램 상태의 변경을 지시하는 식별자를 기록하기 위해 사용되는 것을 특징으로 하는 프로그램된 제어기.
30. 제29항에 있어서, 프로그램 상태를 발생하도록 하는 상기 조건 또는 동작은 프로그램 상태의 변경을 발생하기 위해 상기 조건 또는 동작이 실행된 문장의 식별자를 기억하는 상기 제2변수에 의해 지시된 것을 특징으로 하는 프로그램된 제어기.
31. 제29항에 있어서, 상기 제2변수는 상기 문장을 포함된 액티브 프로그램 루프를 지시하는 것을 특징으로 하는 프로그램된 제어기.
32. 제21항 또는 제22항에 있어서, 상기 제2변수를 기억하는 수단을 추가로 구비하는데, 상기 기억수단은 트레이스 테이블(82)을 포함함 것을 특징으로 하는 프로그램된 제어기.

Images