Benefits, Savings & Doubts
Setup
Configuration
System Integration & Migration
Troubleshooting
Operation & Applications
Availability & Compliance
현대의 자동화 시스템은 단순한 구성(configuration) 및 모니터링 기능만으로는 충분하지 않습니다. 이러한 이유로 최근 몇 년간 소프트웨어 인프라는 자동화 시스템을 선택할 때 점점 더 중요한 기준이 되고 있습니다. 다양한 애플리케이션이 서로 연동되어야 하기 때문에, 개방형 소프트웨어 아키텍처(open software architecture)의 중요성은 더욱 커지고 있습니다.
29.1 서론 및 개요(Introduction & Overview)
Software 소프트웨어
소프트웨어는 운영자 디스플레이(operator display) 역할을 할 뿐만 아니라, 고급 제어(advanced control), 데이터 로깅(data logging), 보고서(report) 등의 기능도 수행합니다.
29.1.1 자동화 소프트웨어(Automation Software)
플랜트의 다양한 사용자들은 서로 다른 정보를 필요로 합니다. 소프트웨어는 정보 아키텍처(information architecture)의 핵심 요소로서, 운영자에게는 공정 변수(process variable)의 측정값을 표시하고, 관리자에게는 주요 성능 지표(key performance indexes)를 계산하여 제공합니다. 표준 소프트웨어 인터페이스는 애플리케이션 간 데이터 교환을 가능하게 합니다.
개방형 소프트웨어 아키텍처에는 여러 기술이 포함됩니다(그림 29-1 참조). 클라이언트-서버(client-server) 구조에서는 클라이언트 애플리케이션이 데이터베이스나 하드웨어 소스와 같은 서버 애플리케이션으로부터 데이터를 표시합니다. 기본적인 클라이언트-서버 인터페이스는 Microsoft의 컴포넌트 오브젝트 모델(Component Object Model, COM)을 기반으로 하며, 네트워크 컴퓨터 간에는 분산 COM(Distributed COM, DCOM)으로 확장됩니다.
공정 변수와 같은 실시간 자동화 시스템 데이터를 보다 쉽게 탐색하고 교환할 수 있도록, OPC 재단(OPC Foundation)은 공정 제어용 OLE 데이터 접근 기술인 OPC-DA(OLE for Process Control-Data Access)를 개발했습니다. 일부 소프트웨어, 특히 자동화가 아닌 일반 소프트웨어는 여전히 Windows의 오래된 기술인 DDE(Dynamic Data Exchange)를 사용하여 실시간 데이터를 교환하지만, OPC에 비해 속도나 사용 편의성이 떨어집니다. 알람 및 이벤트는 OPC-A&E(OPC Alarms and Events)의 구독(subscription) 및 필터(filter) 기술을 통해 애플리케이션 간에 전달됩니다. 데이터베이스 엔진(database engines)은 구성 정보 및 플랜트의 이력 데이터를 저장하는 데 사용됩니다.
하위 수준에서는 SQL(Structured Query Language)을 기반으로 데이터베이스 인터페이스가 구성되지만, 대부분의 애플리케이션은 ODBC(Open DataBase Connectivity), OLE_DB(OLE for DataBase), 또는 ADO(ActiveX Data Objects)와 같은 상위 인터페이스를 사용하여 데이터를 저장하고 검색합니다. 이력 데이터에 대한 접근을 용이하게 하기 위해, 프로세스 히스토리언(process historians)은 OPC-HDA(OPC-Historical Data Access)를 사용하여 데이터를 탐색하고 집계(aggregation)할 수 있도록 지원합니다.
서로 다른 애플리케이션 프로토콜을 사용하는 이더넷 제어 네트워크 기반의 메인 제어 시스템과 패키지 유닛(package unit)처럼 호환되지 않는 하위 시스템을 통합해야 할 경우, OPC-DX(OPC-Data eXchange) 기술을 사용하여 한 시스템이 다른 시스템에 데이터를 기록할 수 있습니다.
DCOM은 방화벽과 호환되지 않기 때문에, 자동화 시스템 외부로 정보를 전달하기 위해 웹 기술(Web technologies)이 사용됩니다. HTTP(HyperText Transfer Protocol)는 인터넷에서 방화벽과 호환되는 전송 프로토콜로, 이러한 작업에 적합합니다. 인터넷에서 데이터를 교환하기 위한 기본 형식으로는 HTML(HyperText Markup Language)과 XML(eXtensible Markup Language)이 일반적으로 사용됩니다.
이를 기반으로 OPC 재단은 방화벽을 통해 실시간 데이터를 통신할 수 있도록 OPC-XML-DA를 개발했으며, 이는 제어 시스템에서 기업 전체로 데이터를 전달할 수 있도록 해줍니다. 단, DCOM에 비해 성능은 낮습니다. 향후 출시될 OPC-UA(OPC-Unified Architecture)는 실시간 및 이력 데이터뿐만 아니라 알람과 이벤트에 대해서도 빠르고 방화벽 친화적인 인터페이스를 제공할 예정입니다.
시동(start-up), 셧다운(shutdown), 배치 작업(batch operations)과 같은 복잡한 시퀀스는 스크립트(script)로 프로그래밍하는 것이 가장 효과적입니다. VBA(Visual Basic for Applications)는 많은 자동화 애플리케이션에서 사용되는 스크립트 언어입니다.
ActiveX는 Windows 컨트롤(예: 버튼)뿐만 아니라 펌프와 같은 애니메이션 심볼(animated symbols)을 포함할 수 있는 구성 요소 기술(component technology)이며, 이는 OLE 컨테이너(OLE containers)로 구성된 그래픽에 포함될 수 있습니다. OLE 자동화(OLE Automation)를 지원하는 애플리케이션은 Excel 스프레드시트와 같은 다른 애플리케이션을 그래픽에 포함시키는 것이 가능합니다.
소프트웨어는 데이터를 종이에 기록하는 대신 디지털 방식으로 저장함으로써 데이터의 무결성(data integrity)을 보장합니다.
OPC와 같은 개방형 인터페이스(open interfaces)는 시스템에 따라 다양한 수준으로 지원됩니다. 개방형 시스템(open systems)은 OPC를 중심으로 완전히 구축되는 반면, 독점 시스템(proprietary systems)은 OPC를 외부 수평 통합 인터페이스(horizontal integration interface)로만 제한적으로 사용하는 경우가 많으며, 그 외에는 일체형(monolithic) 소프트웨어로 구성되어 있습니다.
29.1.2 소프트웨어 계층 구조(Software Hierarchy)
자동화 수준의 소프트웨어는 실시간에 가까운 낮은 데이터량(low volumes of data near real-time)을 처리하며, 긴밀하게 통합된(tightly integrated) 특성을 가집니다. 반면, 기업 수준의 소프트웨어는 느슨하게 결합된(loose coupling) 구조로, 거래 기반 데이터(transaction-based data)의 대량(high volumes)을 처리합니다.
29.1.3 자동화 소프트웨어의 역사(History of Automation Software)
과거에는 서로 다른 애플리케이션 간에 데이터를 교환하려면 별도의 드라이버(custom drivers)를 개발해야 했습니다. 사용자는 하드웨어와 다양한 소프트웨어 애플리케이션을 자유롭게 조합하여 선택할 수 없다는 점에 불만을 느꼈고, 제조업체는 끊임없이 새로운 드라이버를 개발해야 하는 데에 어려움을 겪었습니다. 이러한 문제를 해결하기 위해 OPC 재단(OPC Foundation)이 설립되었습니다.
보편화된 Windows 플랫폼과 OPC 인터페이스 덕분에 애플리케이션 간의 연결성(application connectivity)은 훨씬 수월해졌습니다.
29.1.4 소프트웨어 아키텍처의 발전(Evolution of Software Architecture)
기존의 분산 제어 시스템(legacy distributed control systems, DCS)은 독점적인 일체형 소프트웨어(monolithic software)를 사용했으며, 타사 애플리케이션이 기존 소프트웨어를 대체하는 것이 불가능했습니다. 반면, PLC와 HMI를 결합한 “PLC+HMI” 솔루션은 개방형이었지만, 구성 작업이 매우 복잡하고 시간이 많이 소요되었습니다.
현재는 OPC 인터페이스를 통해 개방적이고 사용이 간편한 연결성을 제공받을 수 있습니다.
29.2 이점, 비용 절감 및 의문점(Benefits, Savings & Doubts)
개방형 소프트웨어 아키텍처는 자본 지출(CAPEX)과 운영 지출(OPEX) 모두에서 비용 절감을 가능하게 합니다.
29.2.1 소프트웨어 표준을 통한 이점 실현(Realizing Benefits from Software Standards)
OPC 인터페이스는 다양한 자동화 애플리케이션의 개발을 촉진하였으며, 이들 애플리케이션은 모든 종류의 하드웨어와 함께 작동할 수 있습니다(그림 29-2 참조). 필요한 모든 애플리케이션은 공급업체에 관계없이 조합하여 완전한 솔루션을 구성할 수 있으며, 향후 필요에 따라 추가하는 것도 가능합니다.
브리징 소프트웨어(bridging software)는 하위 시스템(subsystems)과 패키지 유닛(package units)의 수평 통합(horizontal integration)을 가능하게 합니다. 클라이언트 및 서버 제품에 대한 테스트와 인증(certification)을 통해 고품질의 연결성(connectivity)이 보장됩니다.
OPC의 사용 편의성과 성능 덕분에 모든 관련 데이터에 접근하는 것이 가능해졌으며, 이를 통해 시스템은 더 많은 기능을 수행할 수 있게 되었습니다. 시기적절하지 못한 수동 데이터 수집은 제거되었고, 웹 기술(web technologies)을 통해 방화벽을 거쳐 기업 수준(enterprise level)까지 안전하게 연결할 수 있습니다.
모든 클라이언트 애플리케이션은 OPC 서버의 태그(tags)에 단일 통합 데이터베이스(single integrated database)에서와 동일한 이름으로 접근합니다. OPC 클라이언트와 서버는 드라이버를 사용하거나 레지스터를 태그에 매핑할 필요 없이 “플러그인(plug-in)” 방식으로 데이터를 공유합니다. 클라이언트에서는 서버의 태그를 포인트 앤 클릭(point and click) 방식으로 선택하며, 모든 클라이언트는 동일한 방식으로 구성된 동일한 데이터를 확인할 수 있습니다.
소프트웨어 인터페이스는 데이터 전송에 있어 사람의 개입을 제거함으로써, 데이터 판독 및 재입력 오류를 방지합니다.
29.2.2 자본 지출(CAPEX) 절감(Reducing Capital Expenditure)
OPC는 수많은 드라이버를 개별적으로 개발할 필요가 없게 하여 소프트웨어 비용을 절감시켰습니다. 독점 인터페이스를 제거함으로써 시장 기반의 소프트웨어 가격이 가능해졌습니다. 긴밀하게 통합된 애플리케이션은 더 이상 일체형 DCS(monolithic DCS)를 의미하지 않으며, OPC 기반 소프트웨어를 통해 동일한 통합을 달성할 수 있습니다. 호환성을 위해 불필요한 기능에 비용을 지불하는 대신, OPC를 통해 다양한 애플리케이션 중에서 작업에 적합한 솔루션을 선택할 수 있습니다. SQL 서버 기반의 제조 인텔리전스 시스템(Manufacturing Intelligence System, MIS)은 저비용으로 구축 가능하며, 경우에 따라 MES나 ERP를 대체할 수도 있습니다.
OPC는 통합 작업의 노력과 비용을 줄여주며, 맞춤형 드라이버 개발 비용도 제거합니다. OPC는 사용이 매우 간편하고 다양한 애플리케이션에서 동일한 방식으로 작동하므로 교육 비용도 절감됩니다. OPC 문제 해결 도구(troubleshooting tools)는 여러 공급업체로부터 시장 가격으로, 또는 무료로 제공되기도 합니다.
OPC의 투명성(transparency)은 신규 프로젝트 팀이 기존 팀의 작업을 쉽게 인수하여 확장 시점에 이어받을 수 있도록 해줍니다. OPC는 일체형 소프트웨어를 제거하므로, 용량 요구가 증가하거나 기능이 변경될 때 애플리케이션을 하나씩 교체하는 것이 가능해집니다.
29.2.3 운영 지출(OPEX) 절감(Reducing Operational Expenditure)
개방형 인터페이스(open interfaces)를 통해 서로 다른 하드웨어 및 데이터베이스로부터 데이터를 통합할 수 있습니다. 이후 새로운 소프트웨어를 추가하여 제어 및 실행을 개선할 수 있으며, 일부 운영자는 다른 업무로 재배치할 수 있습니다.
실제 상태 데이터(actual condition data)를 기반으로 예측 유지보수(predictive maintenance)를 수행하면 비용을 절감할 수 있으며, 기술자는 실제 문제 해결에 더 많은 시간을 할애할 수 있습니다. 공급업체에 대한 의존도가 낮아지면 시장 기반의 서비스 가격이 가능해집니다.
기존 시스템(legacy systems)의 유지관리 비용이 높아지고 어려워지는 상황에서, OPC는 운영자 워크스테이션, 프린터 등과 같은 구성 요소를 단계적으로 교체할 수 있는 마이그레이션(migration)을 지원합니다.
29.2.4 소프트웨어 관련 우려 사항 해소(Software Concerns Addressed)
보안(security)은 여러 방법으로 확보할 수 있습니다. 우선, 제어 시스템을 기업 네트워크에 연결해야 할 필요가 있는 경우에만 연결하도록 합니다. 네트워크 보안은 DMZ(De-Militarized Zone) 방화벽 솔루션을 통해 구현하고, 소프트웨어 보안은 다양한 권한 수준(authorization levels)과 비밀번호 인증(password authentication)을 통해 확보합니다.
OPC 기반의 새로운 시스템을 적용하는 것이 반드시 기존 시스템을 방해하는 것은 아닙니다. 기존 DCS용 OPC 서버를 활용하면 새로운 시스템과 기존 시스템이 공존할 수 있어 마이그레이션을 원활하게 진행할 수 있습니다.
OPC의 성능은 문제가 되지 않습니다. COM/DCOM은 텍스트가 아닌 바이너리(binary) 방식으로 작동하므로 우수한 성능을 보장합니다.
기술의 노후화에 대한 걱정은 필요하지 않습니다. 개방형 인터페이스를 유지하고 최신 제품을 사용함으로써 기술의 노후화를 방지할 수 있습니다.
가용성(availability)도 문제가 되지 않습니다. OPC는 이중화(redundancy)를 통해 가용성을 확보할 수 있으며, 소프트웨어는 장애 허용 서버(fault-tolerant servers)에서 실행될 수 있습니다.
다른 운영 체제와의 통합도 가능합니다. OPC-XML-DA 및 향후 출시될 OPC-UA는 Windows가 아닌 플랫폼과의 통합을 가능하게 합니다.
29.3 설정(Setup)
오늘날 소프트웨어 설치는 매우 간편해졌지만, 라이선스 관리뿐만 아니라 방화벽과 도메인을 넘는 네트워크 구성에도 주의를 기울여야 합니다.
29.3.1 애플리케이션 실행(Application Execution)
OPC 서버는 일반적으로 항상 실행되어야 하며, NT 서비스(NT service)로 실행되거나 전원 켜짐 시 자동으로 시작 및 로그인되도록 설정됩니다.
29.3.2 시스템 네트워킹(System Networking)
자동화 시스템 내에서는 DCOM 기반 OPC가 사용됩니다. 기업 시스템이나 인터넷/인트라넷과의 연결은 방화벽을 통해 이루어지며, 이때는 웹 기술(Web technologies)을 인터페이스로 사용합니다. 외부 연결은 네트워크의 원격 액세스 서버(remote access server, RAS)에 전화 접속(dialing in)하는 방식으로도 가능합니다.
또 다른 다중 사용자 옵션으로는 터미널 서버 방식(terminal server scheme)이 있으며, 이는 단순한 컴퓨터 또는 “씬 클라이언트(thin clients)”를 단말기로 사용하고, 모든 처리는 고성능 서버에서 수행하는 방식입니다. 터미널 서버 방식은 중앙 집중형 구조이므로, 가용성(availability) 및 성능(performance) 측면에서 문제가 발생할 수 있습니다.
29.3.3 DCOM 설정(DCOM Setup)
Windows 네트워크 접근 보안은 워크그룹(workgroup) 또는 도메인(domain) 방식으로 설정할 수 있습니다. 워크그룹은 컴퓨터 수가 매우 적은 시스템에만 적합하며, 인증(authentication) 및 권한 부여(authorization)는 운영자(operator), 관리자(administrator) 등 사용자 역할별 그룹을 생성하여 구성하는 것이 가장 효과적입니다.
OPC 클라이언트와 서버가 서로 다른 컴퓨터에 위치한 경우, Windows DCOM 및 방화벽 설정을 클라이언트와 서버 모두에서 수정해야 접근이 가능합니다. 먼저 컴퓨터 전체에 대한 기본 설정을 수행한 후, 관련 구성 요소에 대해 속성(properties), 보안(security), 프로토콜(protocols)을 사용자 정의로 설정합니다.
일반적으로 DCOM 연결은 자동화 시스템 외부에서는 사용되지 않지만, OPC를 방화벽을 통해 전달하거나 지연(latency)이 있는 매체를 통해 연결해야 할 경우에는 터널링 소프트웨어(tunneling software)를 사용할 수 있습니다. 이때는 타임아웃(timeout) 및 재시도 시간(retry times) 조정, 단일 포트(single port) 사용, 웹 기술로의 래핑(wrapping) 등의 옵션을 활용할 수 있습니다.
29.3.4 라이선스(License)
대부분의 자동화 소프트웨어는 소프트 키(soft key) 또는 하드 키(hard key)를 사용하여 라이선스를 제어합니다. 소프트 키는 소프트웨어에 입력하는 문자열이며, 설치 시 소프트웨어를 통해 얻은 기기 고유 코드(machine-specific code)를 기반으로 제조업체로부터 발급받습니다. 하드 키는 컴퓨터 포트에 연결하는 하드웨어 장치입니다. 라이선스 키는 사용할 수 있는 기능, 태그 수(tag count) 등을 제어합니다. 소프트 키는 특정 기기에 종속되므로, 고장난 기기에서 새 기기로 변경하는 것이 간단하지 않을 수 있습니다.
Figure 29-3: Manually Configured Generic Modbus OPC Server (Screenshot: ICONICS Modbus OPC server)
29.4 구성(Configuration)
OPC는 클라이언트 측에서 사용하기에 간편합니다. 서버는 애플리케이션에 특화된 태그들을 제공할 수 있도록 구성되어야 합니다.
29.4.1 실시간 데이터 인터페이스 (OPC-DA 및 DDE)
이상적으로는 OPC-DA 서버가 해당 하드웨어에 native로 탑재되어 있으며, 장비 구성 도구를 통해 모든 태그가 서버에 자동으로 설정됩니다. 예를 들어, 특정 PLC 제어 전략 빌더(control strategy builder)는 제어 전략에 따라 계층적으로 구성된 태그 목록을 자동으로 설정합니다. native 서버가 없는 경우에는 범용 프로토콜 서버를 사용할 수 있지만, 이 경우에는 수동 설정이 필요합니다. 예를 들어, Modbus 서버(modbus server)는 포트와 레지스터를 수동으로 구성해야 합니다. 저울에서 사용하는 프로토콜처럼 드물지만 단순한 프로토콜의 경우에는 범용 서버를 설정할 수 있습니다. 구형 소프트웨어는 OPC-DA 대신 DDE(dynamic data exchange)를 사용하며, 대부분 반자동 방식으로 구성됩니다.
29.4.2 이력 데이터베이스 인터페이스 (OPC-HDA)
개방형 시스템의 트렌드 로거 애플리케이션은 OPC-DA를 통해 실시간 데이터를 수집하여 데이터베이스에 기록하는 동시에, 클라이언트에게 OPC-HDA(historical data access)를 통해 접근을 제공합니다. OPC-HDA는 독점적인 historian 애플리케이션(historian application)에 대한 개방형 인터페이스로도 활용될 수 있습니다.
29.4.3 실시간 알람 및 이벤트 (OPC-A&E)
OPC-A&E(alarms & events)는 일부 용어 사용에 있어 특이점이 있으며, 예를 들어 우선순위(priority)를 심각도(severity)라고 표현합니다. 알람은 condition, 이벤트는 occurrence라고 부릅니다. 개방형 시스템의 알람 생성기는 OPC-DA를 통해 실시간 데이터를 수집하고 이를 trip 수준과 비교하며, 동시에 OPC-A&E를 활용하여 source와 priority를 기준으로 설정된 필터 조건에 따라 클라이언트에 알람과 이벤트를 전달합니다. OPC-A&E 서버(opc-a&e server)는 이러한 보고 기능을 지원하는 네트워크로부터 알람과 이벤트를 수집할 수도 있습니다.
이력 알람 및 이벤트(historical alarms and events)에 대해서는 OPC 인터페이스가 존재하지 않으며, 대신 OLE_DB와 같은 방식으로 인터페이스를 제공할 수 있습니다.
29.4.4 OPC 마샬링(OPC marshalling)
다양한 애플리케이션의 요구를 충족시키기 위한 정교한 OPC 소프트웨어(opc software)가 존재합니다. OPC-DA 서버(opc-da servers)를 사용하는 서브시스템 및 패키지 유닛 간의 수평적 통합을 위해, 한 서버의 데이터를 다른 서버로 전달하는 bridge 애플리케이션(bridge application)이 사용됩니다. 이를 달성하는 또 다른 방법으로는 아직 널리 사용되지는 않았지만, 한 서버가 다른 서버에 직접 데이터를 기록할 수 있도록 하는 OPC-DX 기술(opc-dx technology)이 있습니다. 또한 소프트웨어는 여러 클라이언트가 공유할 수 있는 global 변수(global variables)를 제공합니다. 애플리케이션은 여러 태그를 기반으로 scaling 및 arithmetic과 같은 수학적 기능을 수행할 수 있으며, 마지막으로 funnel 역할을 하여 여러 서버의 데이터를 집계하여 제한된 수의 서버만 지원하는 클라이언트에 제공할 수 있습니다.
29.5 시스템 통합 및 마이그레이션(System Integration & Migration)
플랜트에 설치된 기존 제어 시스템은 일반적으로 독점적이며 연결성이 거의 없거나 전혀 없습니다. 장기적인 목표는 기존 DCS를 교체하는 것이지만, 단기적으로는 실현이 어려울 수 있습니다.
29.5.1 자동화 시스템의 공존 및 마이그레이션(Automation System Coexistence & Migration)
플랜트가 확장될 시점에는 기존 제어 시스템 모델이 새로운 시스템과 호환되지 않는 경우가 많습니다. 많은 기존 DCS에 대해 OPC 서버가 제공되므로, 새로운 시스템과의 공존이 가능하며, 워크스테이션을 교체하는 1단계 마이그레이션도 가능합니다. OPC를 사용하면 기존 하드웨어와 신규 하드웨어의 데이터를 동일한 클라이언트 그래픽에서 함께 표시할 수 있습니다.
29.5.2 프로그래밍(Programming)
과거에는 시스템 통합자가 시스템을 통합하기 위해 특수 소프트웨어를 작성해야 하는 경우가 많았습니다. 예를 들어, PLC나 저울이 DCS와 통신할 수 있도록 디바이스 드라이버를 작성하거나, 고급 공정 제어 소프트웨어가 DCS와 통신할 수 있도록 하는 작업이 포함되었을 수 있습니다. 그 외에도 배치 제어(batch control)나 통계적 공정 제어(statistical process control)를 위한 소프트웨어를 작성하는 경우도 있었습니다.
오늘날에는 OPC 덕분에 대부분의 애플리케이션이 상호 호환되므로 특수 드라이버가 더 이상 필요하지 않습니다. 또한 필요한 다양한 종류의 애플리케이션은 대부분 OPC를 지원하는 공급업체로부터 제공받을 수 있습니다. 게다가 대부분의 운전원 시각화 소프트웨어(operator visualization software)는 내장된 VBA 스크립팅(VBA scripting)을 포함하고 있어 비교적 고급 기능을 수행할 수 있으며, 모든 OPC 데이터에 접근할 수 있습니다.
드물게 시스템 통합자가 실제로 소프트웨어를 작성해야 하는 경우에는 최상의 연결성을 위해 시중 소프트웨어에서 사용되는 핵심 기술을 지원해야 합니다. 여기에는 해당되는 OPC의 다양한 형식(flavor)과 ODBC가 포함되며, 소프트웨어는 ActiveX 컴포넌트(component) 또는 OLE 자동화 컨테이너(OLE automation container)여야 합니다. 결과적으로 C++ 또는 C# 프로그래밍 언어와 Visual Studio 개발 환경을 사용하게 됩니다.
29.6 문제 해결(Troubleshooting)
소프트웨어는 고유한 문제들을 가지고 있습니다.
29.6.1 DCOM 문제 해결(DCOM Troubleshooting)
DCOM 구성은 지침을 체계적으로 따르지 않으면 거의 확실히 잘못 설정됩니다. 발생할 수 있는 문제로는 OPC 서버가 시작되지 않거나, 데이터를 제공하지 않거나, 여러 인스턴스로 실행되는 경우가 있습니다. 보안상의 이유로 오류 메시지가 표시되지 않습니다. DCOM 설정 및 문제 해결을 지원하는 도구들이 제공됩니다.
29.6.2 OPC 문제 해결(OPC Troubleshooting)
모든 OPC 태그에는 상태(status)가 포함되어 있어 DCOM 설정이 완료되면 OPC 문제 해결이 간단해집니다. 서버 구성 오류와 같은 문제는 쉽게 감지할 수 있습니다. 중지된 OPC 서버는 자동으로 다시 시작되며, 클라이언트가 OPC 서버를 사용하지 않으면 서버는 자동으로 종료됩니다.
OPC는 필수 기능과 선택 기능을 모두 포함하고 있으므로, 단순한 클라이언트와 서버는 고급 클라이언트 및 서버와 동일하게 동작하지 않을 수 있지만, 최소한의 기능은 보장됩니다. OPC 문제 해결을 지원하는 도구들이 제공됩니다(도표 29-4 참조).
29.6.3 기타 문제(Other Troubles)
자동화 시스템은 매우 긴 미션 타임(mission time)을 가지며, 수년간 중단 없이 운영됩니다. 새로운 소프트웨어를 설치하면 중요한 파일이 최신 버전으로 대체되어 장애가 발생할 수 있습니다. 설계가 미흡한 애플리케이션은 사용하지 않는 메모리를 해제하지 않아 결국 장애로 이어질 수 있습니다.
29.7 운전 및 애플리케이션(Operation & Applications)
자동화를 위해 특별히 설계된 다양한 소프트웨어와 하드웨어가 제공되고 있습니다. 이러한 애플리케이션과 플랫폼은 운영 비용 절감과 효율성 향상을 통해 비용 절감 효과를 가져올 수 있습니다.
29.7.1 자동화 수준 소프트웨어(Automation Level Software)
OPC 덕분에 제어 시스템에 다양한 소프트웨어 애플리케이션을 쉽게 추가할 수 있게 되었습니다. 핵심 애플리케이션 중 하나는 그래픽, 알람, 트렌드, 보고 기능 등을 포함하는 운전원 시각화 소프트웨어(operator visualization software)입니다. 이 애플리케이션은 일반적으로 SCADA(supervisory control and data acquisition) 또는 HMI(human-machine interface) 소프트웨어라고 불립니다.
HMI의 트렌드 기능을 넘어서는 대규모 데이터 수집은 PIMS(process information management system), 즉 historian 소프트웨어(historian software)를 통해 수행됩니다. APC(advanced process control) 소프트웨어는 여러 제약 조건을 고려하여 복수의 종속 변수들을 제어합니다. RTO(real-time optimization) 소프트웨어는 APC를 위한 최적 운전 지점을 결정합니다. 추정 측정 소프트웨어(inferential measurement software)는 직접 측정할 수 없는 값을 단순한 측정을 기반으로 추정합니다. 운전원 교육 소프트웨어(operator training software)는 공정을 시뮬레이션하여 위험 없이 교육을 가능하게 합니다. 알람 관리 소프트웨어(alarm management software)는 운전원을 방해할 수 있는 불필요한 알람을 우선순위에 따라 필터링합니다. 멀티미디어 알람 소프트웨어(multimedia alarming software)는 모바일 메시지나 인터넷 등을 통해 알람을 통보합니다. 자동 조정 소프트웨어(auto-tuning software)는 PID 제어기(PID controllers)를 조정합니다(도표 29-5 참조). 배치 실행 소프트웨어(batch execution software)는 복수의 스트림, 레시피, 처리 장비를 관리합니다. SPC(statistical process control) 소프트웨어는 공정 변동의 특수 원인을 감지합니다. 그 외에도 탱크 팜 관리(tank farm management), 파이프라인 누출 감지(pipeline leak detection), 제어(control), 연산(computing) 등을 위한 다양한 특화 애플리케이션이 제공됩니다.
Figure 29-4: OPC Server Diagnostics (Screenshot: SMAR SYSTEM302)
29.7.2 데이터 서버(Data Servers)
여러 서드파티 업체들이 기존 DCS를 위한 OPC 서버를 전문적으로 개발하고 있어, 구형 시스템과 신형 시스템의 공존이 가능합니다. OPC 서버는 FOUNDATION Fieldbus, PROFIBUS, Modbus 등 모든 주요 산업 네트워크 및 인터페이스에 대해 제공됩니다. 이더넷 스위치 관리(ethernet switch management) 및 Windows 작업 관리자(windows task manager)를 위한 특수 OPC 서버도 존재합니다. DDE 서버 및 클라이언트를 위한 OPC 게이트웨이도 존재합니다. 바코드 스캐너(barcode scanners)나 저울(weighing scales)에서 사용되는 단순한 프로토콜을 위한 범용 서버도 구성할 수 있습니다. 테스트용으로 다양한 파형을 생성하는 OPC 서버 시뮬레이터도 있습니다.
29.7.3 산업용 컴퓨터 주변장치(Industrial Computer Peripherals)
산업 환경의 열악한 조건에서도 사용할 수 있도록 제작된 다양한 산업용 디스플레이, 터치스크린, 키보드, 마우스 및 터치패드 등의 포인팅 장치가 제공됩니다. 패널 장착형 디스플레이(panel-mounted displays), 다중 화면(multiple screens), 위험 지역용 디스플레이(hazardous area screens), 위생 환경용 디스플레이(display for sanitary conditions) 등 다양한 솔루션이 제공됩니다. 제어실을 위한 제어 센터 콘솔(control center consoles) 및 디스플레이 월(display walls)도 제공됩니다.
Figure 29-5: OPC-Based Auto-Tuning Software (Courtesy ExperTune)
29.8 가용성 및 규정 준수(Availability & Compliance)
대부분의 산업에서는 높은 플랜트 가용성이 필수적입니다. 제약 산업에서는 전자 기록에 대한 규정 준수가 요구됩니다.
29.8.1 가용성(Availability)
중대형 제어 시스템은 일반적으로 이더넷 LAN을 통해 네트워크로 연결된 복수의 워크스테이션과 서버를 포함합니다. 일반적인 스타 토폴로지(star topology) 대신 특수 스위치를 기반으로 한 링 토폴로지(ring topology)를 사용하면 일정 수준까지 더 높은 가용성을 확보할 수 있습니다. 그러나 링 토폴로지에도 여전히 단일 장애 지점(single point of failure)이 존재합니다. 가장 높은 수준의 가용성은 모든 스위치를 이중화하고 모든 장치에 이중 이더넷 포트(dual ethernet ports)를 제공하는 완전한 LAN 이중화(full LAN redundancy)를 통해 달성할 수 있습니다.
가용성은 또한 RAID(redundant array of inexpensive disks) 기반의 하드디스크, 이중화된 전원 공급 장치(redundant power sources), 무정전 전원 장치(UPS), 플랜트 현장에 적합하도록 강화된 산업용 컴퓨터(industrial computers hardened for the plant floor)를 통해 더욱 향상시킬 수 있습니다.
이중화된 OPC 서버(redundant OPC servers)를 사용하는 경우, 각 워크스테이션에 설치된 이중화 관리 소프트웨어(redundancy management software)는 주(primary) 및 보조(secondary) 서버로부터 데이터를 수신하며, OPC 클라이언트가 데이터를 수신하는 단일 지점으로 작동합니다.
배치 실행(batch execution)과 같은 특정 애플리케이션은 이중화 방식으로 구현하기가 쉽지 않습니다. 이러한 경우에는 내부적으로 이중화 아키텍처를 갖춘 장애 허용 서버(fault tolerant server)를 사용하는 것이 더 유리할 수 있습니다.
29.8.2 21CFR11 전자 기록 및 전자 서명(21CFR11 Electronic Records and Electronic Signatures)
소프트웨어를 사용하는 주요 목적 중 하나는 수작업 기록을 전자 데이터 저장 방식으로 대체하는 것입니다. 미국 식품의약국(FDA)의 규정인 21CFR11을 준수하기 위해서는, 시스템이 해당 기록에 대해 이름과 비밀번호 또는 생체 인식 식별자(biometric identifier)로 구성된 전자 서명(electronic signature)을 제공해야 합니다(도표 29-6 참조).
현장 규정 준수는 제3자를 통해 검증할 수 있으며, 사용 중인 소프트웨어가 21CFR11 요구사항을 충족하는 내장 기능을 갖추고 있다면 검증 과정이 크게 간소화됩니다. 보안 기능은 무단 사용을 방지하며, 감사 추적(audit trail)은 모든 활동을 기록합니다.
그 외 요구사항으로는 알람 확인 기록(alarm acknowledgement), 수동 순서(manual sequences)의 강제 실행, 변경 이력 관리(revision controls) 등이 포함됩니다. 많은 21CFR11 요구사항은 소프트웨어만으로는 완전히 충족할 수 없습니다.
Figure 29-6: Electronic Signature (Screenshot: GE Fanuc iFix)