설비 PC 제어 프로그램 관리

산업용 설비 PC 제어 프로그램 관리하기

이글은 사이트를 개설하고 처음으로 쓴 글이다. 티스토리의 에디터가 변경이 되면서 폼이 마음에 들지 않아 수정/편집하여 다시 게시한다.  

 

 

반도체 제조 설비를 제작하는 회사에서 십여 년 근무하면서 국내에서 최초로 양산 라인에 설비를 제작 납품하는 귀한 경험을 하고 이후 디스플레이 화면 패널을 생산하는 제조 설비 분야에서 십수 년간 PC 제어 분야의 설계, 테스트, 셋업을 진행하면서 배운 노하우를 기록한다.

제어 프로그램은 자동으로 움직이는 장치 즉 사람의 개입없이 자동화되어 움직이는 설비등을 제어하는 프로그램으로 장치의 Controller 역할로 24시간 구동되며 문제 발생 시 빠른 문제 해결을 최우선으로 둔다. 이런 종류의 프로그램을 개발 혹은 패치하는 경우 도움이 될만한 내용을 기술해 본다.

 

1. 시작은 백업부터

백업에 무슨 할말이 더 필요하겠는가?
제어 프로그램에서 백업이 더 중요한 이유는 한 부분을 개선하는 경우 바로 문제가 발생하지 않고 새벽 2시에 문제가 발생하는 경우가 신속한 해결을 위해서다.
개선한 부분에 문제가 발생하는 경우 이전의 모듈 프로그램을 바로 원상 복구하여 설비를 운전 가능하게 만드는 것이 가장 중요하다.

 

2. 가장 단순하고 명료하게 기술하는 것이 좋다.

설비를 제어하기 위한 프로그램 코딩은 가장 단순하게 작성하는 것이 좋다.
우선 본인이 한참뒤에 다시 본다고 해도 해석하기 쉽고 다른 엔지니어가 인수인계하여 보더라도 해석이 쉽기 때문이다.
가장 단순하고 누가 봐도 명료하게 작성해야 모두가 쉽게 일처리가 가능하다.

 

3. 텍스트 파일 로그를 충실히 하라

가능한 많큼에 로그를 테스트 파일로 남겨라.
시간은 천분의 1초까지 표시한다.
로그의 저장 레벨을 지정하여 남길 수 있어야 하고 화면에서 이를 설정할 수 있도록 해야 한다.
일정 시간 혹은 사이즈가 초과하면 자동 삭제 기능을 가진다.
로그는 하나의 디렉토리에 모아야 관리가 쉽다.

<예>
 20150521_092732.342 [FNC_TMP] 프로세서 타이머를 설정 완료.
 20150521_092732.352 [FNC_RF]    RF제너레이터의 출력값 설정 완료.

 

3. 작업 History를 남겨라.

전에 이 작업을 진행한 기억이 나는 것 같은데...
이 코드는 왜 여기에 있지...
이 부분은 구동 되지 않는데 삭제해도 되나...
이런 고민을 해결해 준다.
여기에 더 중요한 것은 고객이 이런 히스토리를 요구한다는 것이다.
업데이트 리스트는 프로젝트 디렉터리에 텍스트로 추가하여 수시로 사용하는 것이 좋으며 가능하면 화면에서 바로 읽어 볼 수 있도록 처리하면 더욱 좋다.
소스코드의 일부에 혹은 별도의 파일로 프로젝트 안에 같이 포함되어야 한다.

<예>
2012.7.21     hivac      간혹 신호를 놓치는 경우가 있어 BCAC 기능 구현
                                         특정 센서의 신호를 놓치는 것 같은 현상이 있어 이를 보완 적용
20128.5        hivac      고객 요청으로 편의 기능 추가 (요청자 고객사 김아무개)

 

4. 고객 요청은 천천히 많은 경우의 수를 따져 봐라.

고객은 단순하다. 당장 필요한 기능 혹은 문제가 되는 것만 요구한다.
이것으로 다른 문제가 발생 가능성이 있는지 또 다른 기능도 필요한지 따져봐야 한다.
새로운 버전을 만들지 아니면 옵션 처리 할 것인지 판단하라.
버전이 많아지면 작업량이 기하급수적으로 늘어난다.

 

5. 레시피, 파라미터, 로그파일은 실행코드와 분리하라.

레시피, 파라미터등은 설비마다 별도로 유지해야 한다.
제어 프로그램과 별도의 디렉터리로 유지하여 업데이트하는 경우 간섭이 되어서는 안 된다.
작업내용을 확산 적용하는 경우 레시피, 파라미터가 이동/삭제/변경되지 않아야 한다.
별도의 디렉터리로 관리되면 편리하며 수시로 백업하였다가 PC 교체 같은 작업에서 프로젝트 복사하고
레시피, 파라미터 디렉터리 복사하면 된다.
그리고 로그 파일은 백업이나 작업 시 수시로 삭제하게 된다. 사용자 화면에 로그 위치를 지정하게 구성하면 가장 좋다. 그렇지 못한 경우에는 다른 드라이브에 고정으로 지정하는 것이 유리하다.

 

6. IO는 지연/반복 체크를 기본으로 한다.

I/O (혹은 Tag, Channel로 불리기도 함)는 설비를 제어하기 위하여 신호를 주고받는 것을 말하며 보통의 신호는 즉시 확인되지만 장치에 따라서는 시간이 지연되는 현상이 있어 반복 체크를 기본으로 한다.
Socket통신, DeviceNet, ACS 통신은 수십 msec 정도가 필요하며 Serial 통신은 수백 msec의 시간이 필요하다.
검증된 함수를 만들어 사용하면 좋다.

<예>
// RF를 켠다.
OUTPUT_SIGNAL ( RF_Output_Switch, TURN_ON );

//해당 채널의 값이 TURN_ON이 아니면 100 msec 대기후 3회까지 체크한다.
bool bIsOk = SIGNAL_CHECK  ( RF_Output_Status, TURN_ON, 100, 3 );
if(bIsOk)
{
    // 정상
}
else
{
    // 알람처리
}

 

7. 알람이나 메시지는 명료하게 뛰워야 한다.

경고, 알람은 간단하고 명확하게 발생시켜야 한다.
한 개의 문제로 여러 개의 알람이 발생하면 사용자는 물론이고 나 까지도 해석에 어려움을 겪게 된다.
Alarm ID, Alarm name은 기본이고 alarm에 대한 부가 설명을 사용자가 추가할 수 있으면 금상첨화이다.

 

8. SERIAL 통신을 사용하는 경우

RS-232/485 같은 시리얼 통신의 경우 매우 느린 통신 방식이나 가장 선호하는 방식이기도 하다. 요즘은 많은 장치가 이더넷을 지원하지만.. (이더넷을 통한 socket 통신)
장치 여러 개를 RS-485를 이용하여 5개의 장치와 통신하는 경우 장치당 5개의  상태값을 읽어 사용하면 총 25개의 채널을 사용하게 된다. 통신 속도가 채널당 50 msec라고 하면 채널 하나당 업데이트 속도가 1.25초에 이르게 된다.
업데이트 속도를 높이기 위해 폴링 방식을 개선하게 되는데

1. 중요한 채널 5회당 덜 중요한 채널 1회씩으로 비율 업데이트 (Ratio update)_
2. 동작하는 경우에만 혹은 값이 변경된 경우 변경업데이트 (Change Of Status)
3. 통신 포트 수를 늘리고 포트당 장치를 2~3개 이내로 구성하여 포트당 채널수를 줄여 속도를 높이는 방법이 있다.

<예>
//
while( 1 )
{
    n++;
    // 출력할 값이 있는지 확인하고 있으면 출력 함수 실행
    CheckOutput_DoIt();

    // 장체에서 값을 읽어 온다.
    RS232_INPUT_UPDATE ( RF_OutputPower_SI,   RF_POWER   );
    RS232_INPUT_UPDATE ( RF_OutputReflect_SI,  RF_REFLECT );
    RS232_INPUT_UPDATE ( RF_OutputStatus_SI,   RF_STATUS  );
    if( n > 10 )
    {
        // 비교적 덜 중요한 채널.
        RS232_INPUT_UPDATE ( RF_WaterFlow_SI, RF_WaterFlow );
        n = 0;
    }

    // 장치마다 바로 통신을 시도하면 문제가 발행하는 경우 딜레이를 둔다.
    Sleep(50);
}

 

9. 채널명에 많은 정보를 포함하라.

규칙을 가지고 있다면 그것을 따른다. 윈도우 환경이라면 보통 오름차순으로 정렬되므로 다음과 같은 방법도 고려해 본다.
동일한 장치가 여러 개인 경우 1,2,3등 번호를 매기고 거기에 RF장치의 특정기능값과 Analog Output을 표시하여 실수를 최소화할 수 있도록 한다.
설비 제어에서는 실제 I/O 채널과 가상으로 값을 저장하는 채널의 구분이 상당히 주요하게 작용한다. 이에 대한 표기도 마련되어야 한다. 채널명 뒤의 마지막 분류에 지정된 단어를 사용하여 이것들을 분류하기도 한다.
예전에는 채널에 글자수 제한 등이 있어 많은 내용을 포함하지 못하였으나 이제는 넉넉히 표현할 수 있으므로 충분한 내용을 포함해야 할 것이다.

<예>
제1분류_제2분류_제3분류
PM1_RfSetPower_AO
TM_VacPressure_AI

AO    Analog Output
DI      Digital Input
XI      여러 개의 비트를 조합하여 값을 표현하는 경우(조합된 채널)
RCP   Recipe Cconfig Parameter (Recipe Value)
CFG   Config Parameter (상하안치, 반복 횟수 등 사용자가 변경 가능한 값)
SYS   설비 전체에 해당하는 파라미터를 정의하는 경우 사용

 

10. 코드 내의 주석은 다다익선

두말하면 잔소리
나를 위해 다음에 이 프로그램으로 고생할 인간을 위해...

 

11. 구동에 필요한 프로그램은 프로젝트와 같이 움직여야 한다.

제어프로그램의 동작에 필요한 각종 라이브러리는 반드시 해당 프로젝트 디렉터리에 위치시킨다.
PC 포맷등으로 재 설치가 필요한 경우 이러한 라이브러리가 다른 위치에 있으면 백업 시 실수로 해당 라이브러리를 놓칠 경우가 있다.
다시 해당 장치 공급사에서 드라이버, 라이브러리 등을 다운로드하여 사용해야 한다. 시간이 어느 정도 경과 후 에는 버전도 확인해야 한다. 현장에서는 인터넷도 연결이 되지 않는다. 백업은 늦어지고 불만은 높아지고..
PC셋업용 드라이버, 장치 관련 드라이버, 유틸리티 등은 프로젝트 디렉터리에 같이 보관한다.

OS를 다시 설치하게 되면
1. 필요한 디바이스 드라이버 (VGA, Etherner 등)
2. 디바이스 드라이버 (디바이스넷, 멀티포트, SCANNER 드라이버 등)
3. 개발툴, 데이터베이스, 매뉴얼 등
4. 프로젝트 프로그램
5. 각종 다큐멘트

 

12. 함수화 소형화

모든 기능을 하나의 함수 포함하면 차후 해석에 어려움을 겪게 된다.
가능하면 기능들을 통합하고 함수화 하여 특정 기능만 수행하도록 분산한다.

<예>
if ( GetDoorStatus( "CH01" ) == DOOR_CLOSED )
{
    ALARM_POST( 358, "DOOR NOT OPEN");
}

 

13. 모니터링 프로그램이 가장 중요하다.

설비제어 프로그램에서 가장 중요한 요소 중에 하나가 모니터링이다.
제어 프로그램은 계속 사용하는 부분이라 예상한 대로 상당 시간 동안 구동 된다.
문제는 항상 예상치 못한 곳에서 예상하지 못한 시간에 발생한다. 
이러한 예외 사항을 감지하여 알려주는 부분이 모니터링이다.
온도를 감시하는 모니터링에서는 기준치를 중심으로 상한치, 하한치를 두어 이를 벗어나는 경우 사용자에게 점검을 알리는 것이 가장 중요하다.
상하한치는 경고 부분과 알람 부분으로 나누어 관리하는 것이 좋다.
경고는 의미 그대로 경고만 알리고 동작은 계속하는 것이다. 경고 항목이 정상화되면 해당 경고는 클리어한다. (History에는 계속 남겨두어 사용자가 점검할 수 있도록 해야 한다.)
전에 없던 경고가 계속 발생한다면 해당 장치를 점검하게 유도하는 하는 것이다.

<예>
항상 모니터링
     설비에 공급되는 에어(Air)의 공급압력
    공정에 사용되는 공정용 가스의 입력단에 압력
    펌프의 동작여부 와 배기단 압력
     챔버를 가열하는 히터의 알람을 위한 모니터링 상, 하한치

공정 중 모니터링     
     공정 가스(Gas)의 적정 흐름의 유무
     공정 중 챔버의 압력 추이
     RF 출력 중 출력값의 적정치

 

14. 채널을 적극 활용하라

채널은 신호를 주고받는 IO를 말하며 tag 혹은 channel 등으로 불린다.
값을 전달하기 위하여 혹은 flag 역할을 하는 변수의 경우 저장 기능이 있는 설비 제어용 채널을 이용하는 것이 좋다.
내부 변수를 사용하면 설비가 가동 중인 경우 디버그 등이 불가하여 값의 확인이 어렵다. 하지만 채널을 이용하는 경우 로그를 남기기도 쉬울뿐더러 실시간 값을 감시할 수 있어 효율적으로 모니터링이 가능하다.
윈도우 운영체계를 사용하는 경우 윈도우 메시지를 사용해야 하는 경우도 있지만 채널을 사용하는 것을 추천한다.

 

15.  타이밍 잇슈 (TIMING ISSUE)

설비 제어 프로그램을 만들다 보면 아주 작은 시간 차이로 기대하지 않은 부작용이 발생한다.
이런 종류의 문제를 timing issue라 칭한다.
우선 아래와 같이 프로그램하면 무조건 알람이다.

// RF를 켠다.
SET_RF_SWITCH ( "ON" );

// RF 상태값을 가져온다.
bool nRfStat = GetRfOnOffStatus( "RF01" );

if ( nRfStat == RF_STATUS_ON )
{
    // OK !!!
}
else
{
    // ALARM
}

장치를 켜고 끄기 위하여 장치와의 통신이 필요하고 이것이 전용 스캐너를 이용하여 읽는다고 해도 원하는 결과를 얻는데 수십 msec, 시리얼 장치인 경우에는 수백 msec의 시간이 경과 후 상태를 받아 볼 수 있다.
Sleep을 추가, Time-out을 지정하고 이 시간 안에 값이 회신되지 않는 경우를 알람으로 처리하여야 한다.
특히 이송 로봇을 시리얼 통신으로 사용하는 경우 로봇에 명령을 하달 후에 움직임을 확인하고 다음 명령을 하달하여야 한다. 로봇이 같이 동작을 2회 한다면 이건 사고이다.
로봇의 핸드 위에 물체가 있고 없고에 따라 자체 인터락을 구현한 로봇도 있고 명령의 수신여부를 확인하여 알려주는 기능이 포함된 것을 사용하는 것도 좋은 방법이다.

<예>
// 로봇에게 GET명령을 하달하기 전에 인터락 확인
Robot_Get_Ready( station, hand );

// 로봇에게 GET명령을 하달한다.
Robot_Get( station, hand );

// 로봇이 움직였는가를 확인한다. 타임아웃 이내에 움직임이 없으면 알람.
bool IsBusy = Wait_Robot_Busy_With_Timeout( 1000 );
if( IsBusy )
{
    // Log 등 이력을 남긴다.
}
else
{
    // Alarm
}

// 로봇이 GET 명령을 완료하였는가?
// 7초 이내에 완료 신호가 없으면 알람을 발생시킨다.
Wait_Robot_Completed_With_Timeout( 7000 );

 

16. SIMULATION 코드를 구성하라

Simulation code를 준비해야 한다.
기존 제어코드 외에 I/O 변화를 감지하여 가능하면 실제처럼 동작하게 처리하는 것이 가장 좋은 방법이다. 이렇게 되면 수정된 코드를 설비에 직접 적용하지 않아도 의도한 대로 구동되는지 아니면 오류가 있는지 확인 가능하다.
설비가 Auto mode로 전환되는 경우에는 simulation mode가 자동 해지 되거나 simulation mode에서는 Auto mode로 전환되지 않도록 해야 한다.

<예>
로봇의 PICK(GET) 함수를 다음과 같이 작성하는 경우 초입에 시뮬레이션 코드를 삽입하여 실제 설비가 없는 상태에서
수정된 코드의 테스트가 가능하도록 해야 한다.
 
// 시뮬레이션 코드
if ( _SIMULATION_MODE_ )
{
    // 로봇 옵션에 따라 해당 값을 변경한 후 리턴한다.
   sleep(100);
    return true;
}

// 로봇에게 GET명령을 하달하기 전에 인터락 확인
Robot_Get_Ready(station, hand);

// 로봇에게 GET명령을 하달한다.
Robot_Get(station, hand);

// 로봇이 움직였는가를 확인한다. 타임아웃 이내에 움직임이 없으면 알람.
bool IsBusy = Wait_Robot_Busy_With_Timeout();
if(IsBusy = false)
{
    // Alarm 발생
    return;
}

// 정상종료
return true;

 

17. 장치 드라이버는 실시간으로 구성하라

장치 제어 드라이버 프로그램은 시간 지연이 발생하면 안 된다. 
필요하다면 sequence program(장비 운영을 제어하는 프로그램)에 넣기를 권장한다.
드라이버에서 지연이 발생한다는 것은 전체 시스템에 부하를 줄 뿐 아니라 내가 원하는 sequence를 운영하는데 지연이 발생한다.

 

18. Polling

장치에서 필요한 값을 실시간으로 계속 얻어 오는 프로그램 기능을 폴링(Polling)이라고 한다. 설비 메이커마다 다른 이름으로 불리기는 하나 (Sampling, scanning, refresh.) 의미는 유사한다.
설비는 폴링의 성능에 좌우되기도 한다. 로봇에 구동 명령을 내렸으나 상태값이 늦어지면 상태값을 묻고 묻고 또 묻고 해야 한다. 로봇의 경우 웨이퍼 반송의 핵심이므로 문제가 발생하면 설비 고장으로 이어져 생산에 차질이 발생하기 때문이다.

 

19. 화면에 버전 정보를 표시하라

요즘의 고객사에서 강제하기도 하지만 사용자가 보는 화면에 Software version을 표시해야 한다.
본의 아니게 계속 수정 작업이 이루어진다. 고객요청, 버그, 기능개선, TACT(ST) 단축 등으로 말이다. 
Application 이름과 수정날짜, 수정된 대표 항목등을 표시하면 좋다.
3번 항목의 history와 연계하여 표시하면 좋다. 자사만의 know-how가 필요하다.

<예>
ETCH_PROCESS_20150519_ResuceTACT_Ver27