산업용 설비 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 기능 구현
                              특정 센서의 신호를 놓치는것 같은 현상이 있어 구동전 Before Check, After Check 기능을 구현하여 적용

------------   ---------   --------------------------------------------------------------------------------------------------------------------

20128.5       hivac       고객 요청으로 편의 기능 추가 (요청자 고객사 김아무개)dfsdf

------------   ---------   --------------------------------------------------------------------------------------------------------------------

                     

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

고객은 당장 필요한 기능 혹은 문제가 되는 것만 요구한다.

이것으로 다른 문제가 발생 가능성이 있는지 또 다른 기능도 필요한지 따져봐야 한다.

새로운 버젼을 만들지 아니면 옵션 처리 할것인지 판단하라.

버젼이 많아지면 작업량이 기하급수적으로 늘어난다.

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

레시피, 파라미터등은 설비마다 별도로 유지해야 한다.

제어 프로그램과 별도의 디렉토리로 유지하여 업데이트 하는 경우 간섭이 되어서는 안된다.

작업내용을 확산 적용하는 경우 레시피, 파라미터가 이동/삭제/변경 되지 않아야 한다.

별도의 디렉토리로 관려되면 편리하며 수시로 백업 하였다가 PC 교체 같은 작업에서 프로젝트 복사하고 

레시피, 파라미터 디렉토리 복사하면 된다. 

그리고 로그 파일은 백업이나 작업시 수시로 삭제하게 된다. 사용자 화면에 로그 위치를 지정하게 구성하면 가장 좋다. 그렇지 못한 경우에는 다른 드라이브에 고정으로 지정 하는것이 유리하다.

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

IO는 설비를 제어하기 위하여 신호를 주고 받는 것을 말하며 보통의 신호는 즉시 확인되지만 장치에 따라서는 시간이 지연되는 현상이 있어 반복 체크를 기본으로 한다.

검증된 함수를 만들어 사용하면 좋다.

 

<예>

 

// 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. 알람이나 메세지는 명료하게 뛰워야 한다.

경고, 알람은 간단하고 명확하게 발생 시켜야 한다. 한개의 문제로 여러개의 알람이 발생하면 사용자는 물론이고 나 까지도 해석에 어려움을 격게 된다.

 

 

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

RS-232/485 같은 시리얼 통신의 경우 매우 느린 통신 방식이나 가장 선호하는 방식이기도 하다. 요즘은 많은 장치가 이더넷을 지원 하지만..

 

장치 여러개를 RS-485를 이용하여 5개의 장치와 통신하는경우 장치당 5개의  상태값을 읽어 사용하면 총 25개의 채널을 사용 하게 된다. 통신 속도가 채널당 50 msec라고 하면 채널 하나 당 업데이트 속도가 1.25초에 이르게 된다.

 

업데이트 속도를 높이기 위해 폴링 방식을 개선하게 되는데 

 

1. 중요한 채널 5회당 덜 중요한 채널 1회 씩으로 비율업데이트

2. 동작하는 경우에만 혹은 값이 변경된 경우 변경업데이트

3. 통신 포트 수를 늘리고 포트당 장치를 2~3개 이내로 구성하여 포트당 채널수를 줄여 속도를 높이는 방법이 있다. 

 

<예>

// 

while(1)

{

    n=n+1;

    // 출력할 값이 있는지 확인하고 있으면 출력 함수 실행

    IsOutputDoIt();

 

    // 장체에서 값을 읽어 온다. 
    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_Version_Value, RF_VERSION );

        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. 모니터링 프로그램이 가장 중요하다.

설비제어 프로그램에서 가장 중요한 요소중에 하나가 모니터링 이다.

제어 프로그램은 계속 사용하는 부분이라 예상한 대로 상당 시간 동안 구동 된다. 

 

문제는 항상 예상치 못한 곳에서 예상하지 못한 시간에 발생한다. 이러한 예외 사항을 감지하여 알려주는 부분이 모니터링이다.

 

온도를 감시하는 모니터링에서는 기준치를 중심으로 상한치, 하한치를 두어 이를 벗어나는 경우 사용자에게 점검을 알리는 것이 가장 중요하다.

 

상하한치는 경고 부분과 알람 부분으로 나누어 관리하는 것이 좋다. 경고는 의미 그대로 경고만 알리고 동작은 계속하는 것이다. 전에 없던 경고가 계속 발생한다면 해당 장치를 점검하게 유도하는 하는 것이다. 

 

<예>

항상 모니터링 

  설비에 공급되는 에어(Air)의 공급압력

 

공정중 모니터링   

  챔버를 가열하는 히터의 알람을 위한 모니터링 상,하한치

  공정 개스(Gas)의 적정 흐름의 유무

  

 

14. 채널을 적극 활용하라

 

값을 전달하기 위하여 혹은 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();

if(IsBusy)

{

    // Log등 이력을 남긴다.

}

else

{

    // Alarm

}

 

// 로봇이 GET 명령을 완료하였는가?

Wait_Robot_Completed_With_Timeout();

 

 

16. SIMULATION 코드를 구성하라

 

Simulation code를 준비해야 한다. 

기존 제어코드 외에 I/O 변화를 감지하여 가능하면 실제처럼 동작하게 처리하는것이 가장 좋은 방법이다. 이렇게 되면 수정된 코드를 설비에 직접 적용하지 않아도 의도한 대로 구동되는지 아니면 오류가 있는지 확인 가능하다.

 설비가 Auto mode로 전환되는 경우에는 simulation mode가 자동 해지 되거나 simulation mode에서는 Auto mode로 전환되지 않도록 해야 한다. 

<예>

 

// 시물레이션 코드

if ( _SIMULATION_MODE_ )

{

    // 로봇 옵션에 따라 해당 값을 변경한 후 리턴한다.

    return true;

}

 

// 로봇에게 GET명령을 하달 하기전에 인터락 확인 

Robot_Get(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.) 의미는 유사한다.

 

설비는 폴링의 성능에 좌우 되기도 한다. 로봇에 구동 명령을 내렸으나 상태값이 늦어 지면 상태값을 묻고 묻고 또 묻고 해야 한다. 로봇의 경우 웨이퍼 반송의 핵심이므로 문제가 발생하면 설비 고장으로 이어져 생산에 차질이 발생하기 때문이다.