IT 대장장이

1. 생성시 주의사항

(1) DB 생성시 주의사항 

① DB 명칭은 해당 서비스를 파악할 수 있도록 명명한다.

(2) USER 생성시 주의사항

① User ID는 유관 서비스를 파악할 수 있도록 명명한다.

② Password는 운용팀 DBA의 생성규칙을 따른다.

(3) 테이블 생성시 주의사항

① Table Column 길이의 합이 8K를 넘지 않도록 할 것

② Table 및 Column 이름은 일관성 있게 줄 것(Ex. tbl_, f_)

③ PK / FK Column은 고정길이 형식을 사용할 것(Ex. CHAR Type)

④ Trigger의 사용을 자제

⑤ Table의 소유자는 항상 'DBO'가 되도록 한다

(4) DataType 정의시 주의사항

① 컬럼에 필요한 데이터를 저장할 수 있는 데이터 타입 가운데 항상 가장 작은 데이터 타입을 선택한다.

② 컬럼에 저장되는 텍스트 데이터의 길이가 매우 가변적이라면 CHAR 대신 VARCHAR 데이터 타입을 사용하는 것이 좋다.

③ 16비트 문자(유니코드) 데이터를 저장할 계획이 아니라면 NVARCHAR 또는 NCHAR 데이터 타입을 사용하지 않는 것이 좋다.

④ 긴 문자열을 저장할 때, 문자열의 길이가 8000자 이하라면 TEXT 대신 VARCHAR 데이터 타입을 사용하는 편이 좋다.

⑤ 숫자만을 저장하는 컬럼은 VARCHAR 또는 CHAR 대신 INTEGER와 같은 숫자 데이터 타입을 사용하는 것이 좋다. 

(5) 인덱스 생성시 주의사항

① WHERE 절에서 많이 사용하는 경우 생성

② Covered Index인 경우 선택도가 좋은 조건(10%이하) 부터 순서대로 생성

③ 구간별 선택이 많은 컬럼인 경우 클러스터 인덱스 추전

④ PK정의시 넌클러스터 인덱스로 정의하되 ③항 조건이 만족하면 클러스터 인덱스로 생성

2. Query 작성시 주의사항

(1) 테이블의 모든 컬럼이 아닌 필요한 컬럼의 레코드만 반환한다.

- SELECT * 을 사용하는 것은 피한다.

- 사용하지 않는 데이터를 호출하는 것만으로도 이미 많은 부하가 생긴다.

- 특히 text 타입의 데이터를 호출하는 경우는 그 정도가 심해진다.

- Data Type의 byte가 적은 Column을 주로 사용하는 것이 좋다.

(2) 테이블의 전체 Row 수를 알고 싶다면 sys.sysindexes 테이블의 rows 컬럼을 이용하라.

- COUNT(특정 Column)으로 호출하는 경우가 있다. 이 경우 해당 컬럼의 NULL값을 제외한 COUNT를 가져오게 된다. 

- NULL값을 일일이 체크하면 호출 속도가 저하되게 된다. NULL을 체크해야 하는 경우가 아닌 대부분의 경우 COUNT(*)을 체크한다.

- COUNT(*)는 NULL값의 경우도 모두 Count에 추가하지만 그로 인해 성능의 저하가 많이 줄어든다.

- 그러나 SELECT COUNT(*)의 경우도 테이블을 스캔해서 전체 Row 수를 반환하기 때문에 큰 테이블에서는 시간이 오래 걸린다. 이 경우에는 sysindexs 시스템 테이블을 사용한다. 이 테이블의 rows 컬럼은 각 테이블의 총 Row 수를 값으로 가지고 있다.

(3) 단순 SELECT면 WITH NOLOCK 옵션을 사용한다.

(4) WHERE 절을 사용하여 쿼리의 결과셋을 제한한다.

- 이것은 성능에 가장 영향을 미치는 것으로 클라이언트에게 모든 결과가 아니라 꼭 필요한 결과만 반환하도록 한다. 이렇게하면 쓸모없는 네트웍 트래픽을 감소시킬 수 있으며 쿼리 성능도 향상된다.

(5) WHERE 조건문의 왼쪽은 되도록 변형되지 않은 순수한 column만을 선언하라. 

- WHERE name + '' = '조건' 과 같이 왼쪽 조건을 변형하지 말라. WHERE name = '' + '조건' 과 같이 오른쪽에 조건 선언을 하라.

- 조건 일치를 매 Row마다 확인할 때 왼쪽 조건을 변형하게 된다. 그만큼 부하가 눈에 띄게 증가한다.

(6) WHERE 조건이 최적인지 확인하라

- 우선 WHERE 조건이나 TABLE의 JOIN에 쓰이는 컬럼이 인덱스로 잡혔는지 확인하라. 잡혀있어야 JOIN 성능이나 필터링이 좋다.

- 여러 필터링 중에 예상되는 결과 레코드 수가 적은 것부터 WHERE 조건절에 써라(이건 SQL Server 2000부터는 SQL 실행계획이 알아서 해준다.) 

- 다만, 여러번의 쿼리를 통해 임시 테이블을 만들고, 조작해야 할 때는 SQL 작성자가 유의해서 작성해야 한다.

(7) 가능한한 HAVING절의 사용을 피한다. 

- Having절은 GROUP BY에 의한 결과를 제한할 때 사용한다. GROUP BY에 Having절을 사용하였을 경우 GROUP BY에 의해서 결과들을 모두 집계한 다음 Having절에 명시한 조건으로 맞지 않는 결과를 버리게 된다. 대부분의 경우 Having절의 필요없이 GROUP BY와 WHERE절만으로 원하는 결과를 얻을 수 있다.

(8) 가능한한 DISTINCT 문의 사용을 피한다.

- DISTINCT문을 사용할 경우 Sort에 따른 성능 하락이 있기 때문에 꼭 필요한 경우에만 사용한다. 

(9) 특정 레코드 존재 유무를 파악할 때 COUNT를 세지말고 EXISTS를 사용하라.

- COUNT는 모든 레코드 중 관련된 것을 필터링 한 후 COUNT 함수를 수행하지만, EXISTS는 필터링 시 하나라도 레코드가 있음을 인지했을 때, 반환한다. 테이블의 전체 레코드 수가 작을 때는 구별 안되지만, 많을 때는 EXISTS가 효과적이다.

(10) 처음 몇개의 Row만 필요하다면 TOP이나 SET ROWCOUNT문을 사용한다.

- 결과 전체가 아닌 일부분만 반환하기 때문에 네트웍 트래픽을 감소시킬수 있다. 

(11) 몇개 Row의 빠른 반환이 필요하다면 FAST number_rows 힌트를 사용한다.

- 이를 사용하면 n Row를 빠르게 얻을 수 있으며 이후 쿼리는 계속 실행되서 전체 결과를 만들어낸다.  

(12) JOIN을 사용하는 경우 INNER JOIN을 되도록 사용하라.

- 동일한 효과를 가지는 쿼리를 작성할 경우 INNER JOIN이 아닌 LEFT OUTER JOIN을 쓰는 경우가 있다.(습관적으로?) 확연히 속도가 차이가 나므로 INNER JOIN을 사용하는 것이 좋다.

(13) 서브 쿼리의 사용시 불필요한 SELECT 구문은 줄여라.

- SELECT가 해당 Row을 호출할 때마다 서브 쿼리에 있는 Address을 구하는 쿼리를 호출하기 때문이다. 출력하는 Row가 많으면 많을수록 서브 쿼리의 실행 횟수 또한 증가하게 되며 불필요한 부하를 가져온다.

(14) 가능한한 UNION 대신에 UNION ALL을 사용한다.

- UNION ALL이 UNION보다 훨씬 빠르다. 왜냐하면 UNION ALL은 Row의 중복검사를 하지않는 반면에 UNION은 중복행이 있건 없건간에 중복검사를 수행하기 때문이다. 

(15) VIEW 사용을 자제하라.

- 개발 편의상, 보안상 여러가지 이유로 VIEW는 참 좋은 개념이고, 사용할만한 가치가 있다. 다만 성능 상의 문제 때문에 자제하라는 것이다.

- (5)번 WHERE 조건절 관련해서 언급했듯이, 결과 레코드가 가장 작게 가져오는(HIT RATIO 가 높은) 문장이 먼저 실행되어야 하는데, VIEW를 먼저 가져오는 작업이 그 뒤에 실행되는 WHERE 조건절보다 더 많은 결과를 가져오게 하는 것이 대부분이므로, 성능에는 불리할 수 밖에 없다.

- 또한 여러 개의 테이블이 조인되는 경우 인덱스 사용에 제약이 많다. 물론 INDEXED VIEW가 있어서 어느정도 성능에는 효과가 있지만, 관련 테이블 변경 시 문제가 발생한다.

(16) 커서 및 임시 테이블의 사용을 최대한 자제하라. 

- 커서보다는 임시 테이블을 사용하는 것이 성능에 좋고, 임시 테이블보다는 테이블 변수를 사용하는 것이 성능에 좋다. 

- 커서의 경우 내부적으로는 임시 테이블을 사용하지만 임시 테이블을 쓴다고 부하가 더 발생하는 것이 아니다. 오히려 커서의 부가적 기능 때문에 서버 자원을 더 낭비하게 된다.

- 커서로 처리할 수 있는 것은 모두 임시 테이블이나 테이블 변수로도 처리가 가능하므로 되도록 커서를 쓰지 않는다.

- 만약 커서를 반드시 사용해야 한다면 클라이언트 측 커서를 사용하고, 서버의 커서를 사용할 때에는 가능한 작은 결과 셋을 가져오도록 한다. 

- 커서를 다 사용한 후에는 그냥 닫지만(close) 말고 반드시 해제(deallocate) 시켜야 한다. 

(17) 가능한한 트리거 대신에 제약조건을 사용한다. 

- 제약조건은 트리거보다 성능면에서 훨씬 효율적이다. 따라서 가능한한 제약조건을 사용한다. 

(18) Table Hints를 사용해라.

- IGNORE_CONSTRAINT, IGNORE_TRIGGERS, NOWAIT, PAGELOCK, TABLELOCK, ROWLOCK, UPDLOCK, XLOCK, FASTFIRSTROW 등 여러 가지가 있다. 일반적인 쿼리문에 적절한 Table Hint를 사용해서, 성능을 높힐 수 있다.

(19) 저장 프로시저를 사용하라. 

- 저장 프로시저는 복잡한 SQL문을 단순화 시켜주고, 보안 문제를 해결해주며 더 나아가 빠른 성능의 매개변수, 출력 매개변수, 리턴 값을 사용할 수 있다. 

- 저장 프로시저는 실행 계획이 Plan 캐쉬에 캐싱된다. 즉, 한번 컴파일되면 이것이 캐쉬에 저장되고, 재사용이 되면 될수록 재컴파일이 필요없기에 효율이 올라간다.

(20) SET NOCOUNT ON/OFF를 사용해라.

- 저장 프로시저의 경우 결과 셋으로 보내는 게 아니라, 내부적으로 중간 단계에서 사용하기 위해 조회를 수행하는 경우가 많다. 이 때 SET NOCOUNT ON을 지정하고 수행해야 Client에게 조회 결과가 전달되지 않는다. 최종 결과만을 Client에 보내기 위해서 SET NOCOUNT OFF를 설정한 후, 최종 결과 조회 문을 실행해야한다. 이렇게 하는 것이 쓸데 없는 정보로 인한 네트웍 트래픽 증가를 방지할 수 있다.

(21) 되도록 한꺼번에 SQL 문장을 실행하라.

- Connection Pool 이 있어, Connection Resource에 의한 성능 저하는 별로 없겠지만, 계속된 Network Round-Trip은 성능에 많은 영향을 미친다. 되도록 한꺼번에 요청하고, 반환받아 Round-Trip을 최소화 해야 한다.

(22) 다른 서버에서 정보를 가져 올 경우 연결된 서버를 이용할 때 4-part name방식 말고 OPENQUERY를 사용하라.

① 4-part name 방식

- 성능이 나쁘고, 자주 사용하지 않는다.

- 쿼리 작성이 간단하다.

- INSERT, UPDATE, DELETE 문장을 보통 쿼리문과 비슷하게 사용한다.

② OPENQUERY 방식

- 성능이 나쁘지 않고, 자주 사용한다.

- 쿼리를 문자열로 조합하기 복잡하다.

- OPENQUERY 내의 문자열은 완성된 형태의 문자열만 가능하며, 변수는 받을 수 없다.

3. Tuning

(1) MSSQL을 사용하는 경우 예상 실행 계획을 자주 확인하라.

- MSSQL은 쿼리분석기에서 쿼리를 테스트 하기 편하다. 좋은 기능 중 하나가 예상 실행 계획인데 해당 쿼리가 성능상 어떤 장단점을 가지고 있는지 보기 쉽게 아이콘(그래픽 실행 계획 아이콘)으로 표시해준다.

- 실행 계획의 내용은 버릴것이 없으므로 꼼꼼히 따져봐야 한다. 

- 튜닝의 시작은 성능 분석이다.

(2) Index를 타는지 항상 체크하라.

- Index를 활용하지 않은 검색은 데이터가 많으면 많을수록 성능은 급격히 떨어진다. 게시판 schema를 잘못 짠 경우 이런 현상이 발생하는데 이에 대한 점검을 늘 해야한다.

- 흔히 오해하기 쉬운 것 중 하나가 WHERE 조건절은 필요한 Column만 존재해야 한다는 의식이다. WHERE 조건절에는 Clustered Index Seek를 타기 위한 Column이 우선 존재해야 하고 그 후에 원하는 데이터를 얻기 위한 조건절이 존재해야 한다. 조건 자체가 Clustered Index Column이면 제일 좋다.

- 조건절에 Index에 해당하는 Column들이 존재하는 경우 우선적으로 해당 조건을 만족하는 행을 호출한 후 나머지 조건에 대해 만족하는 행을 다시 호출하게 된다.

(3) Clustered Index Seek를 항상 체크하라.

- Clustered Index Scan을 타는 것 만으로도 속도는 향상이 되지만 완전하진 않다. Clustered Index Column의 일정 구간을 타는 Seek여야 대량으로 증가하는 Data에 대한 부하를 감당할 수 있다. 이를 위해 Index의 구간 체크를 해야 한다.

- 만약 검색하는 Column이 Clustered Index Column인 경우는 단방향 WHERE 조건문으로도 Index Scan이 성립이 된다.

자신의 Column에서 그대로 찾아서 시작 지점부터 끝까지 Index를 타면 되기 때문이다.

- 하지만 일반 Non Clustered Index의 경우는 Clustered를 찾기 위해 해당 Column의 Clustered Index 정보를 호출해야 하는 부담이 생긴다. 왜냐하면 결국 호출을 하기 위해서는 해당 데이터의 위치를 찾아야 하고 이 위치를 가장 밀도있게 알고 있는 Clustered Index에서 해당 데이터의 위치를 찾아 가져오기 때문이다.(바로 찾게 되면 Clustered Index보다 범위가 크기 때문에 중간에 Clustered Index를 통해 찾는다.) 결국 구간 체크가 아닌 Non Clustered Index의 단방향 WHERE 조건문은 Clustered 의 전체 스캔을 하게 되는 결과를 가져온다.

산업 모니터링에 관한 다른 Contents도 확인 하세요. 

0.  DBMS의 탄생이유

1) 데이터의 독립성

데이터베이스 사이즈를 늘리거나 성능 향상을 위해 데이터 파일을 늘리거나 새롭게 추가하더라도 관련된 응용 프로그램을 수정할 필요가 없다.

2) 데이터의 무결성

여러 경로를 통해 잘못된 데이터가 발생하는 경우의 수를 방지하는 기능으로 데이터의 유효성 검사를 통해 데이터의 무결성을 구현하게 된다.

3) 데이터의 보안성

인가된 사용자들만 데이터베이스나 데이터베이스 내의 자원에 접근할 수 있도록 계정 관리 또는 접근 권한을 설정함으로써 모든 데이터에 보안을 구현할 수 있다.

4) 데이터의 일관성

관된 정보를 논리적은 구조로 관리함으로써 어떤 하나의 데이터만 변경했을 경우 발생할 수 있는 데이터의 불일치성을 배제할 수 있다.

또한 작업 중 일부 데이터만 변경되어 나머지 데이터와 일치하지 않는 경우의 수를 배제할 수 있다.

5) 데이터 중복 최소화

데이터베이스는 데이터를 통합해서 관리함으로써 파일 시스템의 단점 중 하나인 자료의 중복과 데이터의 중복성 문제를 해결할 수 있다.

6) 파일처리 시스템의 문제점

•  중복 : 파일처리시스템은 각 파일마다 필요한 데이터를 각각 가지고 있어야 하므로 전체적인 시간과 노력, 경제비용에 있어서 효율이 없다.
•  비일관성 : 데이터에 변경사항이 조금만 있어도 각 파일에서 해당되는 데이터를 모두 변경해야 하므로 수정에 문제가 있고, 한꺼번에 수정이 되지 않으면 데이터값이 서로 틀리게 되는 문제점이 있다.
•  응용 프로그램 개발 문제 : 기존의 파일 시스템은 파일 용도에만 맞춰서 제작되기 때문에 다른 프로그램을 만들때는 다시 데이터베이스 작업을 해야 한다는 문제가 있다
•  데이터 추가 및 검색의 문제 : 데이터가 여러 파일에 산재하고 또 그 파일마다 데이터베이스 양식이 다르기 때문에 일률적인 검색이나 단순 추가 작업이 어렵다.

1. ERD, Table Design. 

2. Query (Group, Join)

•    Select Group, Join (조인과 Grouping으로 많은 의미있는 Data를 구할 수 있다.) 
•     ex) Alarm 통계. (가장 많이 발생한 설비, 날짜별, 등급별 Alarm 갯수....)
•    Delete top 1000, 반복문 : 많은 Data를 삭제할 경우. 
•    Delete, Drop, Truncate

3. 관리(MDF, LDF, ndf, Services), Backup, Restore.

•    Database를 다른서버로 이전시 빠른 방법. 

4.  SP, function

•  자주 사용하는 Query를 Function또는 Stored Procedure를 사용하면 시간을 줄일 수 있다. 
•  개발자들이 개발한 SP, Function을 공유 한다. 
•   View, SP, Function의 이름을 만들때, Rule을 가지고 한다. 
•   Ex) VW_table명_용도, SP_Data종류_용도, FN_Data종류_용도. 
•   VW_UserInfo_JoinEmail

5.  Trigger

•    Trigger는 insert, Delete가 일어날때 Data를 실시간으로 처리 할 수 있다. 
•    Trigger를 이용하여 Remote서버에 Data를 쓰거나 하지 않는다. DB접속이 끊어질 경우, 전체가 Rollback된다. 
•    Trigger를 이용하여 다른 table에 insert할 경우, 해당 Table은 가능하면 Key등의 제한이 없어야 좋다. 예상하지 못한 Data가 들어와 제약 조건에 해당되면 Rollback된다. 

6. 외부연결(Linked Server)

•     Excel도 연결하여, DB Table로 Conversion가능 하다. 
•     다른 서버의 Data도 같은 DB의 data처럼 사용 가능 하다. (View, Join등등)

7.  View

•    다른 형태로 Logging하지 않아도, 기존 Logging Data를 이용하여 사용자에게 필요한 Data를 만든다. 
•    Select Join, Group등을 이용하여 만든다. 

8. Jobs

•    제작한 SP등을 Job을 통해서 실행 한다. 
•    Ex)매10분마다 Alarm 갯수를 확인 하여, 이전 1시간 동안 평균보다 30% 이상 발생하면 Alarm발생. 
•    Ex) 매 10분마다 Logging Table을 확인 하여, 최종 Logging시간이 현재 시간보다 5분 늦으면 Logging안되는 것으로 판단 Alarm 발생. 
•    Ex) 통신두절 Alarm이 10분동안 5건 이상이면, 통신 관련 issue 발생으로 판단 Alarm 발생. 
•    Ex) SMS Alarm과 Logging Alarm의 갯수가 다르면, Alarm발생. 

9. Email(Alarm or Warning)

•    DB에 Logging 되는 Data를 이용하여 Alarm을 생성하여 Email, Text알람전송. 

10. DB 이중화 (이게 왜 필요한지, 어떻게 사용되는지)

• MSSQL Standard Edition CAL Version. (Core version과 비교하여 구매)
• MSSQL Clustering으로 Virture IP를 사용. 접속자는 이중화를 신경 쓰지 않아도 된다. 
• Window 이중화와 함께 설치 해야 함

11. Sqler.com

산업 모니터링에 관한 다른 Contents도 확인 하세요. 

0) 왜 HMI로 개발하는가?

• 아래 내용을 쉽고, 빠르게 구현 하기 위한 전용 프로그램. 
• HMI는 이러한 정보를 그래프, 차트 또는 그 밖에 읽고 이해하기 쉬운 시각적 형태로 나타냅니다.
• 사용자는 HMI를 통해 시설 내 장비의 모든 성능 정보를 한 곳에서 확인할 수 있어 플랜트 운영에 대한 가시성을 향상시킬 수 있습니다.
• 운영자는 HMI를 사용하여 알람 확인 및 관리를 통해 문제 발생 시, 신속하게 대응가능. 
• SCADA(Supervisory Control and Data Acquisition) 시스템이 PLC(Programmable Logic Controllers) 및 입출력 센서와 통신하여 장치 운영에 대한 정보를 확보하면, 해당 정보가 HMI에 표시된다.

1) Tag, Tag의 종류, Tag속성. 

• Tag란
  • 모든 Data는 Address를 가진다. PLC의 Data는 Address를 가진다. 
  • Address는 Data를 저장하는 주소일뿐 다른 정보를 알 수 없다. 
  • 해당 주소의 Data를 개발자와 사용자가 인식 가능 하게 만들어 주는 것이 Tag이다. 
  • 그러므로 Tag의 이름을 만들때는 Rule을 가지고 만들고, 유일성을 가져야 한다.
• Tag의 종류. 
  • Digital, Analog, String Tag가 있다. 
  • Digital의 0 or 1의 값을 가지기 때문에, Alarm On/Off, Valve의 On/Off, 상태의 On/Off를 나타낸다. 
  • Analog값은 연속적인 Value를 나타내기 때문에, 온도, 압력, 무게 등을 나태낸다. 
  • String값은 Text를 보여주기 때문에, 설비명, barcode등을 표현한다. 

3) Tag Mapping. 

• Drawing한 그림은 움직이지 않고, 고정된 그림. 
• Tag의 값은 변화하는 Data. 
• 변화하는 Tag값을 시각적으로 표현하기 위해서는 Drawing에 입히는 과정으로, 
• 이를 통해서 Monitoring화면의 값이 변하고, 상태가 색깔로 표시되고, 무게나 Level이 표시된다. 
• Tag가 Mapping되기 전에는 아래와 같은 화면만 보여진다. 
• 아래 그림의 ####.#에 압력을 나타내는 Tag(예, EqpA_PT1)가 Mapping되면, 해당 Tag가 가진 값이 실시간으로 보여지게 된다. 

4) 통신 (interface)

• 대부분의 HMI는 기본적으로 OPC, Modbus통신을 지원한다. 
• OPC, Modbus를 지원하는 PLC나 Controller의 경우 별도의 개발 없이 HMI와 직접 통신이 가능하여, 해당 Controller에 있는 메모리 값을 가져올 수 있다. 
• HMI에 Data를 가져온 이후에는 Tag이름을 호출하여 해당 Data를 가져올 수 있다. 

5) Script

• 다른 프로그램과 다른 점은, 이미 등록된 Tag의 값, Tag의 이름들을 별도의 변수 지정없이도 바로 변수처럼 사용하여 프로그램밍이 가능하다. 
• 제공되는 함수 등을 이용하여, 해당 HMI에서만 동작하는 프로그램을 개발 할 수 있다. 
• 라이브러리 등을 만들어서 재사용도 가능하다. 

산업 모니터링에 관한 다른 Contents도 확인 하세요. 

1. PLC의 개요. 

   (Programmable Logic Controller)

2. PLC와 다른 산업 PC와의 다른점. 

     PLC의 기능이 날로 발전함에 따라 산업용 컴퓨터와 기능적인

    측면에서 차별성이 줄어들고 있다.

3. PLC와 Relay 제어반의 비교. 

4. 제조사별 PLC종류. 

- MITSUBISHI : MELSEC A-Series, Q-Series, FX-Series

- AB(ALLEN-BRADLEY), 

- Siemens

- Omron PLC

-. 기타 : MOORE, TRICONEX, MODICON, SIEMENS, HIBRAIN, TEXAS INST, HIMA, FESTO, GE, FANUC 등이 있다.

5. PLC의 구성.

Omron PLC 기준으로 설명한다. 다른 PLC의 경우도 비슷한 구성을 가지고 있다. 

PLC의 경우 확장성과 Maintenance의 편리함을 위해서 기능별로 모듈화 되어 있다. 

CPU를 제외한 대부분의 모듈은 다른 Backup및 Restore없이 고장난 부분의 모듈만 교체 하면 된다. 

CPU의 경우는 교체후 Program Download 및 별도의 Setting이 필요하다. 

6. A접점, B접점. (Normal Close, Normal Open.)

  A접점, B접점은 우리나라와 일본만 사용하는 용어인듯 하다. Normal Open, Normal   Close가 이해하기 용이한듯 하다. 

  A접점은 평소에는 Normal Open되어 있다가 사용자 필요시 Close하는 경우. (대부분의 Digital 신호가 A접점을 사용)

B접점은 평소에는 Close되어 있다가, 필요시 Open하는 경우.                                  (안전관련된 부분은 B접점 사용)

Limit스위치의 경우 충돌 방지 장치로 전원이 Off되었을때, Open되어 Alarm발생 및 동작하게 되어 있다. Sensor의 전원이 꺼져도 안전에는 문제가 없다. 

7. And/OR.

   래더에서 직렬로 연결된 것은 프로그램의 And개념. 병렬로 연결된 것은 프로그램의 Or개념. 

   PB1과 MC1 스위치는 OR. 

   PB1, MC2, 는 And 조건. 

   원형 MC1과 MC2는 결과이기 때문에 And/OR조건에 속하지 않는다. 

8. 시퀀스 회로. (자기 유지)

 PLC프로그램의 기본.

한번의 신호만으로 해당 동작을 유지 하게 하는기능. 

Switch와 달리 Push Button의 경우 누를때만 회로가 Close된다. Push button에서 손을 떼면 다시 복귀되어 회로는 Open된다. 

위쪽 MC1, MC2 Switch가 자기유지에 해당된다. 

9. 시퀀스 회로. (인터락)

안전장치

2번째 MC2, MC1이 인터락에 해당된다. MC1, MC2는 동시에 동작 할 수 없다. 

산업 모니터링에 관한 다른 Contents도 확인 하세요. 

산업 현장의 모니터링 프로그램 작업은 다른 IT분야와 차이점을 가지고 있다. 

Industrial monitoring programming is so different with other IT programming.  

1. 산업 현장의 특징을 이해 해야 한다. 
   • 모니터링을 하는 현장에 대한 이해가 필요하다. 
2. Low Level의 파트 특성 및 프로그램에 대해서도 이해해야 한다. 
   • Sensor, 전장 Controller, PLC, Network 등에 대한 이해가 있어야 한다. 
3. High Level의 프로그램에 대해서도 이해해야 한다. 
   • Web 프로그램, Database, Server, Windows 등에 대한 이해가 필요 하다. 
4. 전반적인 Interface에 대한 이해를 높여야 한다.
   • 시스템 전반에 대한 이해가 있어야 한다. 
   • 시스템간 연결에 대한 이해가 필요한다. 

이런 특성을 고려하여 Beginner 는 아래와 같은 Contents에 대한 학습이 요구된다.